Hi. There are other standard names that call for a separate attribute or variable that provides context. The attributes (at the moment) are all standard CF attributes (cell_methods, flag_meanings, comment, etc). I'd love to get feedback from the community about whether or not a directionality attribute would need to described as a "standard" CF attribute.
I'll be glad to rework the definitions to make them directionality-agnostic when I get back next week. Grace and peace, Jim [image: 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 o: +1 828 271 4900 *Connect with us on Facebook for climate <http://www.facebook.com/NOAANCEIclimate> and ocean and geophysics <http://www.facebook.com/NOAANCEIoceangeo> information, and follow us on Twitter at @NOAANCEIclimate <http://www.twitter.com/NOAANCEIclimate>and @NOAANCEIocngeo <http://www.twitter.com/NOAANCEIocngeo>.* On Sat, Aug 4, 2018 at 3:45 AM Lowry, Roy K. <r...@bodc.ac.uk> wrote: > Dear Nan, > > > So are we returning to the wording in Alison's original definitions (e.g. > yaw normally clockwise facing front) before you with my support asked for > the ambiguity be removed? Or do you want to go even further with no mention > of sign convention at all? > > > I would also question whether a Standard Name definition is the place to > specify the mechanism to be used for the description of a sign convention > as it has wider implications than the parameters currently under > discussion. Would it not be more appropriate for this to be considered an > enhancement to CF and written into the Conventions document? If so, it > should it not be the subject of a GitHub ticket? > > > Cheers, Roy. > > > I have now retired but will continue to be active through an Emeritus > Fellowship using this e-mail address. > > > ------------------------------ > *From:* CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Nan > Galbraith <ngalbra...@whoi.edu> > *Sent:* 04 August 2018 02:18 > *To:* cf-metadata@cgd.ucar.edu > *Subject:* Re: [CF-metadata] Platform Heave > > Thanks, Jim. > > > 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. > > This is the approach I'd prefer as well. > > - Nan > > > Quoting Jim Biard <jbi...@cicsnc.org>: > > > 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 > <https://en.wikipedia.org/wiki/Aircraft_principal_axes> > Aircraft principal axes - Wikipedia > <https://en.wikipedia.org/wiki/Aircraft_principal_axes> > en.wikipedia.org > Normal axis, or yaw axis — an axis drawn from top to bottom, and > perpendicular to the other two axes.Parallel to the fuselage station.; > Transverse axis, lateral axis, or pitch axis — an axis running from the > pilot's left to right in piloted aircraft, and parallel to the wings of a > winged aircraft. > > > >>>> > >>>> > >>>> 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 <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 <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 > ------------------------------ > This message (and any attachments) is for the recipient only. NERC is > subject to the Freedom of Information Act 2000 and the contents of this > email and any reply you make may be disclosed by NERC unless it is exempt > from release under the Act. Any material supplied to NERC may be stored in > an electronic records management system. > ------------------------------ > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >
_______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata