Support GPS and network location sources

[reillyeon]

The specification contains the following,

Note: An implementation can use multiple location information sources to acquire geolocation information, and this specification is agnostic with respect to those sources.

I want to expand on that with some observations from Chrome's implementation of the legacy Geolocation API. Broadly, two information sources are available: GPS and network location. GPS is implemented locally to the device and may take a long time to achieve a lock on the visible satellites. In contrast network location can collect the local information it needs relatively quickly (nearby WiFi access points) and then sends a request to a remote server. The server will respond with an estimated location based on the set of access points seen or fall back to IP-based location if there are none. This means that network location can respond very quickly but there is a desire to avoid making frequent requests to the server, especially if it is unlikely that the device has moved.

This causes trouble with the legacy Geolocation API because sites are incentivized to set maximumAge to a small value in order to force the GPS hardware to be woken up to return a recent location fix. When network location is being used, however, it is likely that the old data is still accurate. We recently had a bug where location requests would actually fail because maximumAge was set to a small enough value that the results of the last server-based query could not be used but timeout was too short for the site to wait until we had satisfied our rate limiting requirements and made another request.

Any new location API should be aware of the characteristics of these two, very different, location sources and encourage developers to write their code in a way that is compatible with either.

[anssiko]

@reillyeon, thanks for sharing your implementation findings! It seems the right abstraction to go about this might be to allow a web developer to set constraints on latency/accuracy as discussed in #2. WDYT?

I think developers should not need to ask for a specific information source directly if they can express their requirements in terms of latency and/or accuracy or other such concepts. This is to future-proof the API.

[reillyeon]

I think that accuracy should be a hint but it is likely useful for the application to receive locations updates with less accuracy than what they indicated they desired. I am not certain how useful a deadline is. For that I think we need to do more research into the capabilities provided by various platforms and thus whether or not this is a knob we can effectively communicate to the system. I understand the usefulness of a maximum age parameter but I am concerned as explained above that it is not compatible with the realities of the location sources available.

[anssiko]

Right, more research needed before we decide on the knobs to expose.

[tomayac]

I merge this into #25, where (desired) accuracy is being discussed, too, and add the latency bits to the issue.