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