Nan,

I didn't go to the lengths of making new regularized definitions before I wrote that list. I was thinking in terms of making the clockwise/anticlockwise call based on the right hand rule and the unit vector for each axis. For roll, for example, if the X unit vector faces forward, the "right side down" roll is actually anticlockwise - that is, it is in the direction that your right hand fingers curl if you grab the unit vector in your hand with your thumb pointing in the same direction as the unit vector. That definition is independent of observer location and look direction. My definitions for all the direction values are following that same convention.

Accurate knowledge of the sign of roll, pitch, and yaw is critical in the satellite and aircraft world. The look angles for remote sensors are affected by these values. I get it that not all systems care about the signed values, so that reason and for backward compatibility I suggested that we could change the definitions to avoid declaring which direction is positive, make the direction attribute optional, and say that users should be careful about assuming the directionality for variables lacking the attribute.

Grace and peace,

Jim

On 8/3/18 2:03 PM, Nan Galbraith wrote:
Hi Roy -

Yes,  I've been looking at that page quite a bit lately, and I think it backs up
what I'm saying.

If you are standing on that fuselage (may we never), facing forward, the red roll arrow is showing a clockwise motion, with right side moving downward. If you were facing aft, the arrow would be anticlockwise, but the right side would
be rising.

So, 'roll: "clockwise" for positive right side up and "anticlockwise" for positive right side down'    - is backwards in either case. I'm not disputing anything except
the term 'clockwise'  in this phrase.

Thanks - Nan

On 8/3/18 1:43 PM, Lowry, Roy K. wrote:

Hi Nan,


Whilst I appreciate the limitations of Wikipedia as an authoritative source have a look at https://en.wikipedia.org/wiki/Aircraft_principal_axes


Cheers, Roy.


------------------------------------------------------------------------
*From:* Nan Galbraith <ngalbra...@whoi.edu>
*Sent:* 03 August 2018 18:23
*To:* Jim Biard; Lowry, Roy K.; kke...@ou.edu
*Subject:* Re: [CF-metadata] Platform Heave (pitch, roll)
Hi Jim, Roy and Ken -

I'm skipping the list because this is a minor point and ... and I may be
missing
something obvious.

It's hard not to think of these terms as they apply to ships. In that
environment,
we'd use the convention of the observer facing forward; therefore roll
would be
clockwise if the right side were going down, not up. I'm supposing that
would
also apply to aircraft.

Cheers - Nan



> If we declare that X is positive forward, that Y is positive left,
> that Z is positive up, and that we use the right-hand rule for angle
> directions, the direction attribute values could be:
>
>   * roll: "clockwise" for positive right side up and "anticlockwise"
>     for positive right side down.
>   * pitch: "clockwise" for positive nose up and "anticlockwise" for
>     positive nose down.
>   * yaw: "clockwise" for positive nose right and "anticlockwise" for
>     positive nose left.
>   * surge: "positive" for positive forward and "negative" for
>     positive backward.
>   * sway: "positive" for positive left and "negative" for positive right. >   * heave: "positive" for positive up and "negative" for positive down.
>


>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *From:* CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of
>>> Jim Biard <jbi...@cicsnc.org>
>>> *Sent:* 03 August 2018 15:41
>>> *To:* cf-metadata@cgd.ucar.edu
>>> *Subject:* Re: [CF-metadata] Platform Heave
>>>
>>> I freely admit that I picked direction on sway arbitrarily. In my
>>> experience, part of the variation that arises in the definitions of
>>> the different motions arises from different thoughts about their
>>> use, particularly whether someone is thinking the values are used to
>>> transform into the platform body frame vs transform from it. Or
>>> maybe they just aren't worrying about consistency. Like as not,
>>> choices have often been made in attempts to make the values have the
>>> signed-ness that felt right to people, and we can't keep to
>>> conventions like the right hand rule and make it all work
>>> consistently. We want a positive pitch to be nose up. We want a
>>> positive yaw to be nose right. We want positive heave to be up. My
>>> natural tendency is to think of "roll right" as positive and "sway
>>> right" as positive, but that isn't what other people think of.
>>>
>>> As I read what I wrote, I realize I didn't use a consistent approach
>>> to position and look direction when assigning clockwise and
>>> anticlockwise to roll, pitch, and yaw. I need to regularize that.
>>>
>>> Reading the Conventions about vertical coordinates, it says they
>>> must all have a "positive" attribute with a value of "up" or "down".
>>> I don't see a problem with having the definitions back off of
>>> declaring a specific directionality and add an attribute declaring
>>> directionality. We could call the attribute "direction" so as not to
>>> step on the "positive" attribute, and say that if the attribute is
>>> not present that the user should not assume which direction is correct.
>>>
>>> If we declare that X is positive forward, that Y is positive left,
>>> that Z is positive up, and that we use the right-hand rule for angle
>>> directions, the direction attribute values could be:
>>>
>>>   * roll: "clockwise" for positive right side up and "anticlockwise"
>>>     for positive right side down.
>>>   * pitch: "clockwise" for positive nose up and "anticlockwise" for
>>>     positive nose down.
>>>   * yaw: "clockwise" for positive nose right and "anticlockwise" for
>>>     positive nose left.
>>>   * surge: "positive" for positive forward and "negative" for
>>>     positive backward.
>>>   * sway: "positive" for positive left and "negative" for positive
>>> right.
>>>   * heave: "positive" for positive up and "negative" for positive down.
>>>
>>> Thoughts?
>>>
>>> BTW, I'll be out until August 13.
>>>
>>> Grace and peace,
>>>
>>> Jim
>>>



--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc>         *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org <mailto:jbi...@cicsnc.org>
o: +1 828 271 4900

/Connect with us on Facebook for climate <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics <https://www.facebook.com/NOAANCEIoceangeo> information, and follow us on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /



--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc>         *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org <mailto:jbi...@cicsnc.org>
o: +1 828 271 4900

/Connect with us on Facebook for climate <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics <https://www.facebook.com/NOAANCEIoceangeo> information, and follow us on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /


_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Reply via email to