RE: Position Heading Questions?

Fair point.

I think that will continue to disagree on the "very different" point.  Conceptually, I see that orientation is another aspect of position.

Let us instead look at the alternative: a separate "physical-orientation" working group with a new draft.  Our would you instead recommend that it be punted to "v2".  My view is that the cost/benefit of this feature is demonstrably favourable.  Arguably, there are better use cases for orientation than other features in the current work.

Cheers,
Martin

> -----Original Message-----
> From: Andrei Popescu [mailto:andreip@google.com]
> Sent: Monday, 17 November 2008 8:29 AM
> To: Thomson, Martin
> Cc: Greg Bolsinga; public-geolocation
> Subject: Re: Position Heading Questions?
> 
> Hi Martin,
> 
> On Mon, Nov 17, 2008 at 2:05 PM, Thomson, Martin
> <Martin.Thomson@andrew.com> 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.
> 
> Andrei

------------------------------------------------------------------------------------------------
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, 17 November 2008 17:14:37 UTC