Re: Position Heading Questions?

Hi Martin,

On Mon, Nov 17, 2008 at 2:05 PM, Thomson, Martin
<> wrote:
> Hi Andrei,
> So providing access to a compass for the purposes of correctly orienting a map isn't a valid use case?

It is a valid use case, of course.

> Most of the use cases for device orientation also rely upon location.  The example I like is that of pointing my device at a building or billboard.  It also works nicely when you are navigating.

I certainly agree that orientation and location often need to be used
together to satisfy use cases like the ones you mention.

> To say that it isn't valid to include it because it isn't acquired in the same way is disingenuous.

It sure is, but that's not what I said.

> You seem to be assuming that speed is just the first derivative of position, which is strictly true, but doesn't always reflect the measurement method.  Speed can be obtained in different ways - teensy gyroscopes and the like are quite good for inertial positioning, but they only measure acceleration directly, so location is not natural to these devices (they need a bootstrap position to do that and errors accumulate etc...).  But they are great at measuring speed.  Would you also advocate taking speed out?

Certainly not.

> You really need to substantiate claims like "doesn't fit the current abstraction" and "completely foreign".  I don't buy the watchPosition() argument - if the position changes (any element) you get a notification.  If there was an orientation element, that would have to be included.

I didn't mean to imply that the reason why I think it should not be
included is that orientation is acquired differently. I just think
that orientation, as a concept (and regardless of how it is
implemented), is very different to position. So I think questioning
whether it belongs in this API is absolutely valid. But sure, I
understand it's useful for many use cases, so let's see what others
think. However, you made a very good point in your earlier email: it's
very easy and tempting to try to throw in features to make certain use
cases easier to implement, but we have to draw the line somewhere and
settle for the set of features that are really important.


Received on Monday, 17 November 2008 14:30:00 UTC