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.

Received on Monday, 5 January 2009 00:09:09 UTC