RE: Orientation event draft

Hi Steve,

The new draft with the diagrams is a great help.  Comments inline.

> > I don't like attribute names theta, phi and gamma.
> > Could we have something more describing.
> Do you have any suggestions? One possibility is roll, pitch and yaw,
> as used in aviation. However, this is potentially confusing, as in
> aviation, the x axis (about which roll is performed) runs along the
> long axis of the body, whereas here the A axis is perpendicular to
> this.

The names might be a little ...generic, but I agree, unless someone has a better idea, this should suffice.

Interesting to note that in other specifications, names aren't always necessary.  Values are specified in an array, and that's it.

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.

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.

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):

 Up[x] = cos(latitude).cos(longitude)
 Up[y] = cos(latitude).sin(longitude)
 Up[z] = sin(latitude)

The other vectors are similarly defined.

One virtue of this scheme is that the three vectors are guaranteed to be orthogonal.  

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.

> > "Implementations that are unable to provide all three angles must set
> the values of the unknown
> > angles to null"
> > That is strange. The type of the property is double. That kind of
> properties don't usually give
> > suddenly non-numeric values.
> There is precedent for this in the Geolocation spec.

Unknown and null fit reasonably well.  Though I suspect that implementations will be forced to substitute zero.
 
> > 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.

> > Could you also describe rotation a little more clearly.  Clockwise
> when viewed along an axis isn't
> > sufficiently clear.  From the examples, I would assume that this is
> when values on the axis
> > increase in the direction the viewer is facing.
> Correct. The spec says 'Positive rotation around an axis is defined as
> clockwise when viewed along the positive direction of the axis.'

Right hand rotation is well understood.  Using that terminology would be helpful.

It's unfortunate that this doesn't fit with the established convention of orientation - Northing to Easting - usually described as being clockwise (when viewed from above, opposite to the convention to adopt).  The direction you describe the subject as facing (along the positive direction of the axis) is counter-intuitive.

The diagrams help a lot here, but the description could easily be misinterpreted.  The note that you've added is the best clue.

--Martin

Received on Wednesday, 21 April 2010 23:06:04 UTC