- From: Kruessel, Steffen <Steffen.Kruessel@fokus.fraunhofer.de>
- Date: Tue, 23 Dec 2008 09:37:40 +0100
- To: <public-geolocation@w3.org>
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