-
Notifications
You must be signed in to change notification settings - Fork 17
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
Comments
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.
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
This is a use case that sounds very common yet the Geolocation API does not cater for this properly. Yes you can poll for |
Related, known interop issues with |
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). |
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). |
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) |
I believe this is a new requirement from @blairmacintyre we're not tracking yet:
@blairmacintyre feel free to open a new issue for this if you feel this should be evaluated for inclusion to the new API. |
Can we close this in favor of the "uber Issue" #25? |
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.
The text was updated successfully, but these errors were encountered: