Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Developer-set constraints on latency/accuracy of initial reading #2

Open
markafoltz opened this issue Oct 5, 2017 · 9 comments
Open

Comments

@markafoltz
Copy link

The Geolocation API allows the caller to pass a timeout and maxAge constraints, which asks the browser to get a fresh position if it can within the timeout, otherwise it returns a cached position that is no older than maxAge.

The use case here, I suppose, is where the reading is optional and we don't want to block rendering of content waiting for a result. For example, the page may be able to fall back to a user setting or ask for ads without geotargeting if it can't get a reading in time.

It seems like there is a use case for "get me the best position you can within X ms that is no older than Y ms".

A related constraint is "return me a position as soon as the accuracy is within Z meters." A page that only requires metro-level accuracy for weather, store location or ad targeting would be willing to trade off accuracy for lower latency.

Elaborating specific use cases here might help sort through the alternatives.

@anssiko
Copy link
Member

anssiko commented Oct 9, 2017

Thanks for the good use cases!

Now that we are redesigning the Geolocation API on top of the Generic Sensor API I'd like us to start with a use cases first approach rather than just port the old API over as is -- this is exactly the type of input we need to do that.

It seems like there is a use case for "get me the best position you can within X ms that is no older than Y ms".

This use case seems pretty clear and valuable. We should perhaps look at how the Geolocation API is currently used in the wild before porting over timeout and maximumAge as is, to see if there are API ergonomics issues that could be improved.

A related constraint is "return me a position as soon as the accuracy is within Z meters." A page that only requires metro-level accuracy for weather, store location or ad targeting would be willing to trade off accuracy for lower latency.

This is a use case that sounds very common yet the Geolocation API does not cater for this properly. Yes you can poll for accuracy and altitudeAccuracy, but that is not very efficient or ergonomic if you're just interested in a one-shot geolocation reading. Furthermore, the highAccuracy flag is just a hint, and as such has known interop issues.

@anssiko
Copy link
Member

anssiko commented Oct 31, 2017

Related, known interop issues with maximumAge and timeout across major browsers: https://bugs.chromium.org/p/chromium/issues/detail?id=769231#c8

@anssiko
Copy link
Member

anssiko commented Jan 30, 2018

WebXR use cases discussed in #12 and #7 seem relevant to this discussion.

The WebXR use cases represent another end of the use cases spectrum (cf. the initial use case in https://github.com/WICG/geolocation-sensor/issues/2#issue-263204881) with very strict latency/accuracy requirements.

It seems the developer-set constraints model could be generalized to cater to that end of the spectrum too.

Concretely, the constraints would inform the implementation and allow it to pick the location source(s) that satisfy the constraints. For example, for navigation use cases a GPS might be a feasible implementation strategy, while in order to satisfy the stricter requirements of WebXR the implementation might use GPS and Orientation Sensor fusion to provide more precise geolocation (at the expense of battery consumption).

cc @blairmacintyre

@blairmacintyre
Copy link

For example, for navigation use cases a GPS might be a feasible implementation strategy, while in order to satisfy the stricter requirements of WebXR the implementation might use GPS and Orientation Sensor fusion to provide more precise geolocation (at the expense of battery consumption).

If there is a WebXR implementation in the browser, I was thinking of the inverse: if a page is using it, it is already potentially doing a lot of work (in the native AR/VR platform) to do high precision location/orientation pose estimation. So, leveraging that knowledge internally might yield high precision with less battery consumption (i.e., relative to using the AR/VR platform APIs PLUS using the separate sensors).

@blairmacintyre
Copy link

A related constraint is "return me a position as soon as the accuracy is within Z meters." A page that only requires metro-level accuracy for weather, store location or ad targeting would be willing to trade off accuracy for lower latency.

I've found myself wanting that, where I wanted to avoid initial poor quality pose estimates. Coupled with that might be either a timeout, or perhaps some sort of notification that the requested accuracy is not available (e.g., 1-2m accuracy but position is being determined by crude wifi triangulation)

@anssiko
Copy link
Member

anssiko commented Feb 19, 2018

@anssiko
Copy link
Member

anssiko commented Feb 19, 2018

I believe this is a new requirement from @blairmacintyre we're not tracking yet:

notification that the requested accuracy is not available

@blairmacintyre feel free to open a new issue for this if you feel this should be evaluated for inclusion to the new API.

@blairmacintyre
Copy link

@anssiko I opened an issue #15

@tomayac
Copy link
Contributor

tomayac commented Sep 26, 2018

Can we close this in favor of the "uber Issue" #25?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants