RE: altitude measurement

On the original question, for the reasons stated in my related email, a single value of altitude should be sufficient.

On the topic of multiple sources, I've previously discussed the problems with the OMTP approach [1].  My point, in synopsis, is that the "how" isn't just irrelevant, it's harmful.  For one, it's reminiscent of the classic problem of the man with two watches.  Personally, I don't care how the problem is resolved, but there is no reason to bother applications with the complicated details.  Max is right to remind us of the dangers of complication.

Cheers,
Martin

> -----Original Message-----
> From: public-geolocation-request@w3.org [mailto:public-geolocation-
> request@w3.org] On Behalf Of Max Froumentin
> Sent: Monday, 29 December 2008 7:46 PM
> To: Kruessel, Steffen
> Cc: public-geolocation@w3.org
> Subject: Re: altitude measurement
> 
> 
> "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.
> 
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

Received on Sunday, 4 January 2009 23:48:58 UTC