(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?
The accuracy and 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 Coordinates interface.
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.?
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.
