- 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>
"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: http://www.w3.org/TR/2006/CR-DPF-20061019/#sec-layout 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. Max. > > 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