[whatwg] Geolocation API Proposal

[Aaron Boodman]

Hi Vlad, thanks for the reply.

On Mon, Mar 17, 2008 at 9:31 PM, Vladimir Vukicevic <vladimir at pobox.com> wrote:
>  So, some feedback on the proposal... overall, I think that this API should
> be kept as simple as possible.  To that end, I would suggest:

I agree with the sentiment :)

>  - remove Address from Position; a separate API/spec/web service/whichever
> can be used to turn a Position into an Address, without the awkward
> "requestAddress" boolean flag or similar.  I think this also removes the
> awkward gersLocationProviderUrls?  (If I'm understanding right, these are
> the services that would convert position->address?)

Address was included because it can be a lot more efficient to do both
of these at the same time in one request than doing two separate
requests.

However, now that you bring it up, I think it might be more common to
only need to reverse geocode once, not continuously. So maybe that is
a point in favor of splitting the two functions apart.

The _gearsLocationProviderUrls is actually the services that convert
the "location signals" that the device has access to (cell ids, nearby
wifi nodes, etc) to a position. We expect that most UAs won't want to
allow applications to modify this list, but it's something that's
important to us, so we are OK with it as an extension.

>  - altitude/horizontalAccuracy/verticalAccuracy should probably use -1 if
> not available (using null can be awkward, since it'll become 0 in some
> contexts)

Altitude can be negative, so -1 won't do in that case. It would work
for the others, though, so we could just make altitude be zero and
verticalAccuracy be -1 in the case where vertical information is
unavailable. I'll make this change since others have expressed concern
with returning null from a numeric field.

>  - Geolocation.lastPosition should, IMO, be the only interface here
> (probably Geolocation.position).  It already has a timestamp, so apps can
> determine when the fix is.  There's no need for watchPosition/clear given
> that we have setInterval/setTimeout already.  An updateInterval can be added
> with the minimum interval between position updates, as a hint to
> applications how often it should be updating.

The reason for having an explicit watch/clear is for battery usage. We
don't want to have this thing running all the time just in case an
author asks for it. Having getPosition(), watchPosition() and
clearWatch() is intended to make it more apparent that the API starts
an expensive process and consumes resources.

Another reason for having getPosition() is that one of the major use
cases is getting the current location. For example, to find nearby
restaurants. With only lastPosition and no way to force an update, it
would be awkward to implement this kind of feature. You'd have to
first set updateInterval to the delay you're willing to wait, then
setTimeout() that long, then check the value.

Another design goal was to allow multiple javascript functions within
the same context to use the API without colliding with one another.
Having a single mutable updateInterval property would conflict with
this goal (although a workaround could be to create instance of the
geolocation object).

>  - I understand the desire for optionally obtaining a high accuracy fix; I
> would have that be a separate method for that.  For that, I can see a
> callback based interface would make sense, as acquiring the fix would take
> time.

Ok, there is also a need to get a default accuracy fix on demand, so I
will leave that part as is for now unless there are other issues.

>  - I would move heading/speed off into a separate Direction interface,
> though I don't have a strong opinion about that

I don't have a strong opinion about these properties. Other people had
asked that I add them so implementors didn't have to extend the spec
in undefined ways.

Thanks,

- a