Revisit and evaluate existing use cases and requirements

[anssiko]

We should revisit the Geolocation API use cases and requirements through the lens of web developer and implementer feedback, and see that the modernized API addresses the requirements that are still considered valid. And of course, consider new use cases.

The Geolocation API work started over 9 years ago, so I expect new use cases have since come up especially considering the platform capabilities have also evolved.

[blairmacintyre]

Here's a question: is it perhaps worth considering not being so tightly coupled to the (implicit) assumption that the geolocation API is driven by GPS?

For example, the API is designed assuming low frequency reports (even high end GPS doesn't exceed 20-30 reports/sec do they?), the "heading" and "speed" are directly tied to these capabilities in GPS receivers (which I think are fairly inaccurate/useless if you aren't in a vehicle because they are derived from the GPS reports), and so on.

I'm coming at this from a mobile AR perspective: I want a geolocation API that includes position and orientation, and can report at a high rate. Now, it may very well be that we don't want to satisfy all use cases here: it may be that we just want to provide the low resolution, low frequency position here, as opposed to full pose.

At the very least, if we can make sure that this API (and other sensor APIs) report their values using accurate time stamps that correspond to the time stamps on APIs like WebXR (not just in the type, but by trying to ensure they really do align as much as possible), we might be able to get the best of both worlds. And, for orientation (in addition to position), if the high precision orientation / position we get from WebXR can be aligned with the world (at least orientation), then aligning position might be trivial for apps.

[anssiko]

Here's a question: is it perhaps worth considering not being so tightly coupled to the (implicit) assumption that the geolocation API is driven by GPS?

You are absolutely correct. That's why the spec explicitly states: "Note: An implementation can use multiple location information sources to acquire geolocation information, and this specification is agnostic with respect to those sources."

Your WebXR use cases in #12 make a strong case for maintaining this agnosticism as well as for developing the proposal #2 further to allow the web developer set constraints on latency/accuracy.

At the very least, if we can make sure that this API (and other sensor APIs) report their values using accurate time stamps that correspond to the time stamps on APIs like WebXR

Discussed in #12.

[anssiko]

Related: geofencing use cases #17

[tomayac]

(I have just formally self-assigned this to me and will work on it before TPAC.)