RE: altitude measurement

Hi there

I guess this discussion should face a much more generic problem, which
is not only relevant for altitude measurements, but also for longitude,
latitude, speed and heading. Just to give an example, imagine a device
that has a built-in GPS receiver as well as a built-in compass. How
could you tell, which method to use for the calculation of heading (same
could be true for speed and acceleration sensors etc.).

Within the BONDI initiative of OMTP (http://www.omtp.org/bondi), they
propose so called Location Providers for the explicit selection of
localization methods/hardware as one way to face this problem. There can
be multiple providers that all provide different (or the same, but,
e.g., with a higher accuracy) location information. Probably, we should
discuss this issue more generically in this group. Any thoughts?

Best Regards
Steffen

-----Original Message-----
From: public-geolocation-request@w3.org
[mailto:public-geolocation-request@w3.org] On Behalf Of Erik Wilde
Sent: Monday, December 22, 2008 9:42 PM
To: public-geolocation@w3.org
Subject: altitude measurement


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 Wednesday, 24 December 2008 12:41:20 UTC