GeolocationSensor API extends the
Sensor interface [GENERIC-SENSOR] to provide information about the geolocation of the hosting device.
The feature set of the
GeolocationSensor is similar to that of the Geolocation API [GEOLOCATION-API], but it is surfaced through a modern API that is consistent across contemporary sensor APIs, improves security and privacy, and is extensible. The API aims to be polyfillable on top of the existing Geolocation API.
We’d like to incubate this proposal in WICG before the expected migration to the Device and Sensor Working Group for formal standardization.
(This API follows the lead of the first batch of sensors based on the Generic Sensor API that are now shipping as an Origin Trial in Chrome. See the Web Fundamentals article for more information.)
I think this is a good idea, generally, we should do it
Btw, why the split between accuracy and altitudeAccuracy. Maybe the former property needs a prefix? Do all GPS’s only give one acceuracy value for lat/long? or will some separate then between lat and long?
altitudeAccuracy attribute names are inherited from the
Coordinates interface of the Geolocation API. We should investigate further how web developers use (or would like to use!) accuracy data, what are the capabilities of contemporary hardware that provide accuracy data, and what is exposed through platform APIs.
This is definitely an opportunity to modernize the API if we don’t feel strongly about retaining backwards compatibility with the
Have you considered adding rotation information to this API? If you had that it could help provide a basis for delivering some world-scale AR use cases.
Also, any consideration to how to provide location information in places where GPS isn’t available or reliable? For example, indoors, underground cave, etc.?
Thanks for your comments.
For more advanced rotation information required by world-scale AR use cases, you might want to use the low-level motion sensors Accelerometer, Gyroscope, and Magnetometer based on the Generic Sensor API instead. These APIs are already available in Chrome as experimental features, see the related article for more information.
The heading attribute inherits its semantics from the Geolocation API and represents the direction of travel in degrees counting clockwise relative to the true north. It caters for simpler use cases such as navigation that need to orientate the map with the direction of travel. It might also work for some very basic world-scale AR use cases.
The proposed Geolocation Sensor specification is agnostic with respect to location information sources, as noted in the specification:
Note: An implementation can use multiple location information sources to acquire geolocation information, and this specification is agnostic with respect to those sources.
That is to say, an implementation can choose the most appropriate means to acquire location, e.g. use GPS outdoors and switch to some other indoor positioning mechanism when indoors, or use any combination of the available mechanisms. These are implementation details, and as such out of scope for this specification.
What needs to be investigated further (contributions welcome!) is whether to provide means for the web developer to provide a hint on the preferred geolocation accuracy that the implementation could then use to choose the most appropriate location information source. This is noted in a related spec issue.
The Geolocation Sensor specification has migrated to WICG GitHub:
Discussion on the specification has moved to GitHub issues: