- From: Erik Wilde <dret@berkeley.edu>
- Date: Mon, 22 Dec 2008 12:42:06 -0800
- To: "public-geolocation@w3.org" <public-geolocation@w3.org>
hello. this is my second comment regarding the altitude. "The altitude attribute denotes the height of the position, specified in meters above the [WGS84] ellipsoid. If the implementation cannot provide altitude information, the value of this attribute must be null." an implementation may be able to provide more than one value, and this is important information. the WGS84 mentioned here (which should have an additional EGM96 flag, as mentioned earlier) could be complemented by a barometric measurement. both are valid measurements, and both are important values which should be available. for example, when i am hiking i have access to both barometric and GPS altitudes. both are relevant for me, and i make an informed decision (mostly based on weather, but also on additional knowledge such as the latest calibration of the barometer) when to give preference to what. i still don't understand how the API would be supposed to make such a decision and just give me "the altitude". there is no such value if we are not assuming an ideal world. assuming that the API has some built-in magic that will be able to come up with the "best estimate" eliminates the possibility to make a choice based on important observations (such as the weather) which the API cannot do. i do understand that nobody is interested in complicating the API unnecessarily, and i understand that. but then again, there is important information that will have to be thrown away with the current API design. asked the other way around: if a device has GPS altitude measurements and barometric altitude, and an API implementor would ask us how to come up with the "one true value" that has to be exposed in the API, what advice could we give him better than "well, that's your problem"? cheers, dret.
Received on Monday, 22 December 2008 20:42:53 UTC