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

Re: altitude measurement

From: Max Froumentin <maxfro@opera.com>
Date: Mon, 29 Dec 2008 09:45:54 +0100
To: "Kruessel\, Steffen" <Steffen.Kruessel@fokus.fraunhofer.de>
Cc: <public-geolocation@w3.org>
Message-ID: <m2myefxtbx.fsf@kaos.intern.opera.no>

"Kruessel, Steffen" <Steffen.Kruessel@fokus.fraunhofer.de> writes:

> 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?

W3C's DCCI specification hit the same problem of selecting one specific
provider, and avoided it by introducing a hierarchical structure of
properties, which lets the user select the provider. An illustration of
it can be shown in this figure from an old draft:


That hierarchy of properties, modelled as a pseudo-DOM, is the main
cause of people finding DCCI too complex for implementers, as well as
for users.


> 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 Monday, 29 December 2008 16:28:12 UTC

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