RE: altitude measurement

Hi Martin

As you said, the question of having multiple sources of data or not depends on the circumstances and therefore also on the application developer, who needs to decide if the single "best effort" value is appropriate or if the application "knows" which data source would fit best (or which can be combined respectively). I propose to have different modes for location data requests. The one is the best-effort-short, which looks for a single value that was gathered somehow, while the other request allows the specification of the concrete source in order to use all exposable information (something like a filter).

I'm willing to bet that Web developers ARE (in some cases) interested in managing everything and DO NOT want to rely on a single scalar. But as I said, this heavily relies on the scenario/application.

Greets
Steffen

-----Original Message-----
From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] 
Sent: Monday, January 05, 2009 3:43 AM
To: Erik Wilde
Cc: Max Froumentin; Kruessel, Steffen; public-geolocation@w3.org
Subject: 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 Wednesday, 7 January 2009 18:00:26 UTC