RE: altitude measurement

If the specification gets into the topic of resolving differences from multiple sources of data, then it will never be finished.  The answer depends on circumstance to a large extent.  Better to leave that up to those who need to resolve these problems: the people who do the measuring.  Better that than lump web developers with the mess.

The problem with additional information is that you then need further information to help people make use of the mess.  At a minimum you need to provide information on how to interpret each so that those who are only interested in the answer can make use of it.

Your hiking example is a good example of a person having to compensate for a shortcoming in technology - the GPS gives you altitude relative to the ellipsoid, not "sea level"; the barometric altimeter is affected by weather.  You compensate for each in your own fashion, and multiple sources are used for redundancy - to compensate for any potential errors.  In doing so you apply a fair amount of additional knowledge.

I'm willing to bet that web developers aren't interested in managing all that complexity for what could be a single scalar.

Cheers,
Martin

> -----Original Message-----
> From: Erik Wilde [mailto:dret@berkeley.edu]
> Sent: Monday, 5 January 2009 11:08 AM
> To: Thomson, Martin
> Cc: Max Froumentin; Kruessel, Steffen; public-geolocation@w3.org
> Subject: Re: altitude measurement
> 
> hello martin.
> 
> > 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.
> 
> i do agree that complexity can be a problem and can complicate a
> technology to the point where it's not very usable anymore. on the
> other
> hand, it's not always the best approach to just make things as simple
> as
> possible, they should just be as simple as reasonably possible. in very
> many cases, this is one of the really hard design questions...
> 
> i do not have a perfect answer for how to deal with various location
> sources, but i think that if the API decides to not include any
> capabilities for that, at least there should be some kind of idea of
> how
> implementors might solve their problem of coming up with the "one true
> location". what strategy should they use if they do have multiple
> measurements and the API only lets them expose one set of values? i am
> really curious. regarding the two watches: for altitude, for example,
> barometric and GPS altitude are rather different measurement methods,
> and like i said, when i go hiking, i appreciate to have both values
> available so that i can make a decision based on information that the
> devices just don't have. having a device that would just give me one
> value would dimish the usability quite a bit.
> 
> 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 Monday, 5 January 2009 02:43:55 UTC