W3C home > Mailing lists > Public > public-geolocation@w3.org > December 2008

altitude measurement

From: Erik Wilde <dret@berkeley.edu>
Date: Mon, 22 Dec 2008 12:42:06 -0800
Message-ID: <494FFB9E.8090601@berkeley.edu>
To: "public-geolocation@w3.org" <public-geolocation@w3.org>


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 


Received on Monday, 22 December 2008 20:42:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:53 UTC