RE: Orientation event draft

Hi Steve,

Some comments inline.

> > I have a recommendation on x, y and z though.  In this case, we do
> have
> > names.  These should instead be labelled, East, North and Up.
> OK, I'll add these names. Though I think we should keep the labels
> x,y,z too.
> 
> > I also have a problem with the use of magnetic north.  I understand
> the
> > limitations of the measurement devices, but there are other ways of
> defining
> > cardinal directions that are more directly compatible with
> geolocation.
> Yes, you're right, we should use True North (the direction towards the
> North Pole, which lies on the line of 90 latitude for the datum in
> use) for the WGS84 datum (the datum used by Geolocation). Geolocation
> uses True North as the reference for its heading property.

That's great, thanks.

> > Rather than defining "Up" to be the tangent to the gravipotential
> surface, you can define up in terms of location (as a vector in
> > WGS84 Cartesian coordinates):
> I think that rather than defining up to be the direction of the vector
> from the WGS84 origin as you suggest, I think it's more common to use
> the direction perpendicular to the ground for these local coordinates.
> Though we should clarify the spec to say that the ground should be
> taken to be tangent to the local surface of the WGS84 spheroid.

What I described wasn't the vector through the centre of the spheroid - it IS the vector tangential to the local surface.

I have a brief description of this (PDF attached).

> > The drawback is that in order to measure this you need to know the
> relationship between magnetic north and these.  Note also that
> > magnetic north moves.  You also need to know the relationship of the
> gravipotential surface with East and North - the EGM (Earth
> > Gravipotential Model) provides that.
> Yes, it's true that these definitions require significant computation
> to obtain the required values from the sensor data. Though we don't
> require a particular level of accuracy and for many applications, the
> obvious approximations (magnetic north == true north, gravity is
> parallel to the Up axis) will suffice.

It's not so much the computation, it's more the contextual information.  The more recent high resolution EGM models are pretty large.

Absolutely - I hate to suggest it, but the idea of a "magnetic" tag makes some sense.  For those applications that care about the extra precision, it might be worth the additional bit (and increase of API surface area).

> > Though I suspect that implementations will be forced to substitute
> zero.
> Why do you think this?

Only that for those devices that lack the full 3 axis orientation, apps might exist that assume or require it.  It's not a big deal.  Let that be a decision for app makers to make.  Using null seems the best approach.

> >> > Would I be right in assuming that 0, 0, 0 orientation equates to a
> device with the screen facing
> >> > up and the top of the screen toward north?
> >> Yes
> > But you still have to assume this.  An explicit statement might seem
> a little redundant, but that small effort will pay you back.
> The spec states that 'The transformation from the Earth frame to the
> device frame is expressed in terms of 3 rotations', so at (0, 0, 0)
> the frames are aligned by definition. It also says 'Starting with the
> two frames aligned, the rotations are applied in the following
> order:'. Can you suggest how you'd like to add further clarification?

No, I missed that.  It's good.
 
> > Right hand rotation is well understood.  Using that terminology would
> be helpful.
> OK, I'll add that terminology.

Cheers,
Martin


> 
> Steve
> 
> --
> Google UK Limited
> Registered Office: Belgrave House, 76 Buckingham Palace Road, London
> SW1W 9TQ
> Registered in England Number: 3977902