Nan,
That was my concern. As I have thought about it, we can make it clear in
the definition text. I'll generate those later this week.
Jim
On 9/11/18 10:53 AM, Nan Galbraith wrote:
> I agree completely. Thanks to all for keeping at it with this topic.
>
> ?* platform_roll_starboard_down
> ?* platform_yaw_fore_starboard
> ?* platform_pitch_fore_up
> ?* platform_surge_fore
> ?* platform_sway _port
> ?* platform_heave_up
>
> There was some concern expressed about using port and starboard, because
> satellite folks don't normally use those terms. I was unable to figure
> out exactly
> who raised this point, the thread is long and sometimes my mail client
> makes the
> sender of each message a little obscure.
>
> I'm assuming even satellites have a 'front' - ADCPs don't, really,
> except by some
> obscure convention set by the vendors - so presumably people will be
> able to figure
> out which side is which, and these terms will be OK.
>
> - Nan
>
>
> On 9/7/18 4:07 AM, Lowry, Roy K. wrote:
>>
>> Good point,
>>
>>
>> So you'd prefer platform_roll_starboard_down and so on?
>>
>>
>> Cheers, Roy.
>>
>>
>> ------------------------------------------------------------------------
>> *From:* John Graybeal <jbgraybeal at mindspring.com>
>> *Sent:* 07 September 2018 03:29
>> *Subject:* Re: [CF-metadata] Platform Heave
>> Sorry if I missed a point, but joining the motion to platform_ will
>> be much more findable. Platform roll for example is a really common
>> expression.
>>
>> John
>>
>> On Sep 6, 2018, at 08:22, Lowry, Roy K. <rkl at bodc.ac.uk
>> <mailto:rkl at bodc.ac.uk>> wrote:
>>
>>> Dear Jim,
>>>
>>>
>>> Looking good to me.
>>>
>>>
>>> Cheers, Roy.
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *From:* CF-metadata <cf-metadata-bounces at cgd.ucar.edu
>>> <mailto:cf-metadata-bounces at cgd.ucar.edu>> on behalf of Jim Biard
>>> <jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>>
>>> *Sent:* 05 September 2018 17:38
>>> *Subject:* Re: [CF-metadata] Platform Heave
>>>
>>> Roy, Jonathan,
>>>
>>> I expect that surge, sway, and heave may well not have any
>>> "alternate direction" representations in the wild, but I recall that
>>> we found that the same is not true of pitch, roll, and yaw.
>>>
>>> Should we define the "canonical" set in such a fashion that the sign
>>> convention is explicit and wait for people to request the others?
>>>
>>> I guess that would be:
>>>
>>> ? * platform_starboard_down_roll
>>> ? * platform_fore_starboard_yaw
>>> ? * platform_fore_up_pitch
>>> ? * platform_fore_surge
>>> ? * platform_port_sway
>>> ? * platform_up_heave
>>>
>>> Is that what we want?
>>>
>>> Grace and peace,
>>>
>>> Jim
>>>
>>> On 9/5/18 12:10 PM, Jonathan Gregory wrote:
>>>>
>>>> Dear Roy OK, yes. I agree with that too! We should not provide
>>>> standard names for there is no use case yet. However, it's a good
>>>> idea for foresee how this may be done, so that a neat solution is
>>>> readily available when the day comes. Best wishes and thanks
>>>> Jonathan On Wed, Sep 05, 2018 at 04:07:26PM +0000, Lowry, Roy K.
>>>> wrote:
>>>>>
>>>>> Date: Wed, 5 Sep 2018 16:07:26 +0000 From: "Lowry, Roy K."
>>>>> <rkl at bodc.ac.uk> <mailto:rkl at bodc.ac.uk> Subject: Re:
>>>>> [CF-metadata] Platform Heave Dear Jonathan, This isn't a desire to
>>>>> mandate, it's just an attempt to prevent the creation of six
>>>>> unnecessary Standard Names for sign conventions based on my
>>>>> knowledge and researches of oceanographic data that don't exist.
>>>>> Should anybody come up with a single example of the opposite sign
>>>>> convention in heave/sway/surge from any other domain then the
>>>>> additional Standard Names will obviously need setting up. Anybody
>>>>> know of any??? It also goes without saying the 'normal'
>>>>> conventions should leave the door open - for example 'upward
>>>>> heave' leaves the door open for a future 'downward heave'. This
>>>>> follows another principle of CF Standard Names which is that
>>>>> Standard Names should only set up when there is a demonstrable use
>>>>> case and not just in case a use case arises. Cheers, Roy. From:
>>>>> CF-metadata <cf-metadata-bounces at cgd.ucar.edu>
>>>>> <mailto:cf-metadata-bounces at cgd.ucar.edu> on behalf of Jonathan
>>>>> Gregory <j.m.gregory at reading.ac.uk>
>>>>> <mailto:j.m.gregory at reading.ac.uk> Sent: 05 September 2018 16:26
>>>>> Subject: Re: [CF-metadata] Platform Heave Dear Jim and Roy In
>>>>> general, we want CF to be able to describe the datasets that users
>>>>> want to describe, rather than mandating particular choices.
>>>>> Projects that use CF can do that, of course, like CMIP6 does,
>>>>> which prescribes the standard_names of the quantities to be
>>>>> submitted. Best wishes Jonathan
>>>>>>
>>>>>> Date: Wed, 5 Sep 2018 09:32:37 -0400 From: Jim Biard
>>>>>> <jbiard at cicsnc.org> <mailto:jbiard at cicsnc.org> Subject: Re:
>>>>>> [CF-metadata] Platform Heave
>>>>>> Roy, Good point! However (of course there has to be a 'but'!),
>>>>>> are we OK with forcing people to modify their data to match our
>>>>>> convention? Are there other situations where a standard name
>>>>>> requires a certain representation? The existing datasets that
>>>>>> people have mentioned are history, but they are also indicative
>>>>>> of different sign conventions out there "in the wild". Grace and
>>>>>> peace, Jim On 9/5/18 4:22 AM, Lowry, Roy K. wrote:
>>>>>>>
>>>>>>> Dear Jim, I think maybe you're doing more work than necessary. I
>>>>>>> see the work falling into three parts. 1) Revision of the
>>>>>>> definitions of heave/heave rate that are part of a new Standard
>>>>>>> Name that has yet to be accepted. 2) Creation of new Standard
>>>>>>> Names for Ken for sway/sway rate and surge/surge rate 3) Upgrade
>>>>>>> to the definitions of the existing Standard Names for pitch,
>>>>>>> roll and yaw. How about hard-wiring direction conventions for
>>>>>>> cases (1) and (2) - heave positive up, surge positive forwards
>>>>>>> and sway to match Ken's data sets? As these are new Standard
>>>>>>> Names they cannot be out in the wild with the opposite direction
>>>>>>> convention. We would then need to deprecate the three existing
>>>>>>> Standard Names and replace them with six new ones. One other
>>>>>>> thought that is occupying my mind is whether the rate parameters
>>>>>>> are scalars or vectors? Any thoughts? Cheers, Roy. *From:*
>>>>>>> CF-metadata <cf-metadata-bounces at cgd.ucar.edu>
>>>>>>> <mailto:cf-metadata-bounces at cgd.ucar.edu> on behalf of Jim Biard
>>>>>>> <jbiard at cicsnc.org> <mailto:jbiard at cicsnc.org> *Sent:* 04
>>>>>>> September 2018 16:36 *Subject:* Re: [CF-metadata] Platform Heave
>>>>>>> Jonathan, Two out of three of Nan's "most intuitive" rotations
>>>>>>> (pitch and yaw) are clockwise rather than anticlockwise if the
>>>>>>> unit vectors are X-fore, Y-port, and Z-up, which form a
>>>>>>> right-hand coordinate system. This is part of why you will see
>>>>>>> examples where the unit vectors are defined as X-fore,
>>>>>>> Y-starboard, and Z-down. This orientation of the unit vectors
>>>>>>> makes yaw to starboard, pitch up, and roll starboard down all
>>>>>>> anticlockwise rotations, but it points the Z unit vector down,
>>>>>>> which is, for most people, rather counter-intuitive. And this is
>>>>>>> why we are trying to define things in terms that don't require
>>>>>>> specification of unit vector directions. I'm going to try to
>>>>>>> continue down that path and avoid calling out
>>>>>>> clockwise/anticlockwise. Grace and peace, Jim On 9/4/18 10:18
>>>>>>> AM, Jonathan Gregory wrote:
>>>>>>>>
>>>>>>>> Dear Jim
>>>>>>>>>
>>>>>>>>> If that's the general consensus, then we can go that general
>>>>>>>>> direction. I'll prepare pairs of everything.
>>>>>>>>
>>>>>>>> Thank you for your flexibility.
>>>>>>>>>
>>>>>>>>> Regarding Nan's suggestions for names - I'm not a "ship
>>>>>>>>> person" so starboard and port are unfamiliar terms that I have
>>>>>>>>> to constantly check myself on. I dislike putting them in the
>>>>>>>>> names. I don't see them in regular use in the satellite
>>>>>>>>> domain. The same goes for bow as far as usage outside of the
>>>>>>>>> ship domain. Airplanes have noses. Satellites have ... I don't
>>>>>>>>> know if there is even a name, as there is no need for a
>>>>>>>>> leading edge. I'll struggle to find something, and then we can
>>>>>>>>> wrangle over it.
>>>>>>>>
>>>>>>>> I agree with you - it would be better to have something generic
>>>>>>>> and self- explanatory, even if it diverges from familiar
>>>>>>>> terminology.
>>>>>>>>>
>>>>>>>>> I think the "most intuitive" way to represent the angles - and
>>>>>>>>> most consistent as well, in my view - is clockwise rotations
>>>>>>>>> around the unit vectors. This makes positive yaw to starboard,
>>>>>>>>> positive pitch nose up, and positive roll starboard up. But we
>>>>>>>>> are talking about having both signs represented in names, so I
>>>>>>>>> guess that is moot.
>>>>>>>>
>>>>>>>> I agree with this too. For describing polygonal bounds, we say
>>>>>>>> that the vertices should be traversed anticlockwise as seen
>>>>>>>> from above. That is a positive direction of rotation around the
>>>>>>>> vertical axis, since longitude- latitude-upward is a
>>>>>>>> right-handed coordinate system. I suppose this is the yaw
>>>>>>>> rotation - but is that the opposite sign from yours? Best
>>>>>>>> wishes Jonathan
>>>>>>>>>
>>>>>>>>> On 9/3/18 12:51 PM, Jonathan Gregory wrote:
>>>>>>>>>>
>>>>>>>>>> Dear Roy and Nan I agree that if there are existing names
>>>>>>>>>> whose sign convention is undefined we can't retrospectively
>>>>>>>>>> define it. I think those ones ought to be deprecated, though,
>>>>>>>>>> in favour of new ones with signs indicated. Best wishes
>>>>>>>>>> Jonathan ----- Forwarded message from Nan
>>>>>>>>>> Galbraith<ngalbraith at whoi.edu> <mailto:ngalbraith at whoi.edu>-----
>>>>>>>>>>>
>>>>>>>>>>> Date: Sun, 02 Sep 2018 11:57:33 -0400
>>>>>>>>>> From: Nan Galbraith<ngalbraith at whoi.edu>
>>>>>>>>>> <mailto:ngalbraith at whoi.edu>
>>>>>>>>>>> ?I second Roy's suggestion; existing names have undefined
>>>>>>>>>>> directionality, and new names have explicit directions. This
>>>>>>>>>>> seems like the only way to move forward. If there's a
>>>>>>>>>>> difference of opinion on which direction should be in the
>>>>>>>>>>> new name, we can easily create a pair for each term. What
>>>>>>>>>>> would the explicit names be? Some of the terms in the thread
>>>>>>>>>>> below use 'right' and 'left' where 'port' and 'starboard'
>>>>>>>>>>> might be more clear, since, as Roy points out, left and
>>>>>>>>>>> right can be taken as 'looking forwards from the platform or
>>>>>>>>>>> looking at the front of the platform.' I also agree that
>>>>>>>>>>> these are the most intuitive way to represent these
>>>>>>>>>>> angles/motions:
>>>>>>>>>>>>
>>>>>>>>>>>> heave positive up pitch positive bow up yaw positive to
>>>>>>>>>>>> starboard roll positive starboard side down
>>>>>>>>>>>
>>>>>>>>>>> Would the names be something like heave_up, pitch_bow_up,
>>>>>>>>>>> yaw_to_starboard, and roll_to_starboard? We do need to
>>>>>>>>>>> differentiate these from the exiting names. Regards - Nan
>>>>>>>>>>> Quoting "Lowry, Roy K."<rkl at bodc.ac.uk>
>>>>>>>>>>> <mailto:rkl at bodc.ac.uk> <mailto:rkl at bodc.ac.uk>
>>>>>>>>>>> <mailto:rkl at bodc.ac.uk>:
>>>>>>>>>>>>
>>>>>>>>>>>> Dear Jim, From my researches into existing oceanographic
>>>>>>>>>>>> data sets (SeaDataCloud holdings plus EU glider data
>>>>>>>>>>>> projects), covering heave, pitch, roll and yaw. I haven't
>>>>>>>>>>>> discovered a single deviation from the conventions:
>>>>>>>>>>>> heave positive up Pitch positive bow/nose up yaw positive
>>>>>>>>>>>> to starboard roll starboard side down I have yet to find
>>>>>>>>>>>> any data sets, other than those described by Ken in these
>>>>>>>>>>>> discussions, in my searches containing surge or sway. The
>>>>>>>>>>>> only ambiguity I have found in the wider domain of Google
>>>>>>>>>>>> is where the concept of 'positive clockwise' has been used
>>>>>>>>>>>> without specifying whether the observer is looking forwards
>>>>>>>>>>>> from the platform or looking at the front of the platform.
>>>>>>>>>>>> This isn't helped by the multitude of bidirectional vectors
>>>>>>>>>>>> (arrows at each end) in illustrative diagrams. Might our
>>>>>>>>>>>> lives be made easier if we adopted a set of conventions,
>>>>>>>>>>>> state them explicitly in the Standard Names as Jonathan
>>>>>>>>>>>> suggests leaving room in the unlikely - in my view at least
>>>>>>>>>>>> - event of Standard Names for the opposite convention being
>>>>>>>>>>>> required? Cheers, Roy. From: CF-metadata on behalf of Jim
>>>>>>>>>>>> Biard<jbiard at cicsnc.org> <mailto:jbiard at cicsnc.org>
>>>>>>>>>>>> Sent: 31 August 2018 14:38 ?Jonathan, That's only part of
>>>>>>>>>>>> the issue. Here are the issues as I see them. * There is no
>>>>>>>>>>>> single sign convention being followed in existing datasets
>>>>>>>>>>>> "in the wild". * There is a long-standing convention for
>>>>>>>>>>>> vertical coordinates using the attribute positive rather
>>>>>>>>>>>> than having pairs of standard names for height_positive_up,
>>>>>>>>>>>> height_positive_down, etc. The suggested solution is
>>>>>>>>>>>> corollary, and the positive attribute could be used instead
>>>>>>>>>>>> of adding a new attribute named direction with a suitable
>>>>>>>>>>>> expansion of possible valid values. * In order to cover all
>>>>>>>>>>>> bases, we'd need three versions for each standard name
>>>>>>>>>>>> (e.g. - platform_roll, platform_roll_clockwise,
>>>>>>>>>>>> platform_roll_anticlockwise - or similar names) * Having
>>>>>>>>>>>> three different versions of each standard name will lead to
>>>>>>>>>>>> new possibilities for getting things wrong by picking the
>>>>>>>>>>>> wrong version. * Semantically, there is only one concept in
>>>>>>>>>>>> each case. If I am searching for roll variables and I have
>>>>>>>>>>>> multiple names that mean roll, I must expand my search to
>>>>>>>>>>>> include all variants. This is a small example, but there
>>>>>>>>>>>> are other examples of this problem that are definitely not
>>>>>>>>>>>> trivial and defeat one of the goals for using standard
>>>>>>>>>>>> names - being able to find like quantities across datasets,
>>>>>>>>>>>> particularly using automated techniques rather than human
>>>>>>>>>>>> eyes. Grace and peace, Jim On 8/31/18 8:52 AM, Jonathan
>>>>>>>>>>>> Gregory wrote: Dear all I haven't been following this
>>>>>>>>>>>> discussion, so please excuse me if I've missed the point. I
>>>>>>>>>>>> think you are suggesting introducing a new attribute to
>>>>>>>>>>>> indicate the positive sense of various new quantities for
>>>>>>>>>>>> platform orientation - is that right? To do that would not
>>>>>>>>>>>> be consistent with other standard names, which (where
>>>>>>>>>>>> relevant) all have the positive sense indicate in the
>>>>>>>>>>>> standard name itself. That's why there are many pairs of
>>>>>>>>>>>> standard names for upward/downward, in particular. The
>>>>>>>>>>>> reason for doing this is to make it impossible to name the
>>>>>>>>>>>> quantity without indicating its sign convention, whereas a
>>>>>>>>>>>> separate attribute can be omitted, and probably sometimes
>>>>>>>>>>>> will. It also opens new possibilities for getting things
>>>>>>>>>>>> wrong, by putting illegal values in it. Therefore I would
>>>>>>>>>>>> argue for the same approach here, both because I think it's
>>>>>>>>>>>> less error-prone, and for consistency with other CF
>>>>>>>>>>>> standard names. I'm sure the objection occurs to you that
>>>>>>>>>>>> this means more standard names. That's true, but it's only
>>>>>>>>>>>> twice as many, I believe, since each of the quantities has
>>>>>>>>>>>> only two possible senses.
>>>>>>>>>>> Best wishes Jonathan
>>>>>>>>>>>> ----- Forwarded message from Kenneth Kehoe <kkehoe at ou.edu>
>>>>>>>>>>>> <mailto:kkehoe at ou.edu> <mailto:kkehoe at ou.edu>
>>>>>>>>>>>> <mailto:kkehoe at ou.edu>
>>>>>>>>>>>> Date: Thu, 30 Aug 2018 12:05:44 -0600
>>>>>>>>>>>> From: Kenneth Kehoe<kkehoe at ou.edu> <mailto:kkehoe at ou.edu>
>>>>>>>>>>>> Subject: Re: [CF-metadata] Platform Heave
>>>>>>>>>>>> I think we should keep things simple as Ethan suggests
>>>>>>>>>>>> below. But since the proposed attribute "direction" is
>>>>>>>>>>>> defined as indicating the positive direction we don't need
>>>>>>>>>>>> to include the word positive. The terms would then be:
>>>>>>>>>>>> roll: "right_side_up" and "right_side_down" pitch:
>>>>>>>>>>>> "nose_up" and "nose_down" yaw: "nose_right" and "nose_left"
>>>>>>>>>>>> surge: "forward" and "backward" sway: "left" and "right"
>>>>>>>>>>>> heave: "up" and "down" It would be nice to be more explicit
>>>>>>>>>>>> in the netCDF file and require less on the standard_name
>>>>>>>>>>>> definition so I would suggest we use the original proposed
>>>>>>>>>>>> attribute name of "positive_direction" with the above
>>>>>>>>>>>> allowed values. Or if we don't want to add a new attribute
>>>>>>>>>>>> we could use the existing "positive" attribute and expand
>>>>>>>>>>>> its allowed use. I've proposed this in the past and it was
>>>>>>>>>>>> decided to not expand the definition. I think the concern
>>>>>>>>>>>> for not expanding positive was the requirement of only
>>>>>>>>>>>> using that attribute on coordinate variables. For the
>>>>>>>>>>>> coordinate variable the only allowable values are up and
>>>>>>>>>>>> down. But for this use those values would only be attached
>>>>>>>>>>>> to a variable, not a coordinate variable. Since we are
>>>>>>>>>>>> creating an attribute to define the positive direction I
>>>>>>>>>>>> would like to add radial definition of "toward" and "away".
>>>>>>>>>>>> But I think we can simplify this a bit further. If we
>>>>>>>>>>>> define the point of reference that is moving in the
>>>>>>>>>>>> standard name then we don't need to put the point of
>>>>>>>>>>>> reference in the positive (or direction or
>>>>>>>>>>>> positive_direction) attribute. For example the pitch
>>>>>>>>>>>> standard_name would indicate the location of reference of
>>>>>>>>>>>> the nose. This would then reduce the list of possible
>>>>>>>>>>>> options to: roll: "up" and "down" pitch: "up" and "down"
>>>>>>>>>>>> yaw: "right" and "left" surge: "forward" and "backward"
>>>>>>>>>>>> sway: "left" and "right" heave: "up" and "down" If we could
>>>>>>>>>>>> use the current attribute of "positive" that has up and
>>>>>>>>>>>> down already defined then we only need to to add "right",
>>>>>>>>>>>> "left", "forward", "backward", "toward", "away". Easy! Ken
>>>>>>>>>>>> On 2018-8-29 13:54, Ethan Davis wrote: Hey Jim, How about
>>>>>>>>>>>> removing one layer of terminology by using your definitions
>>>>>>>>>>>> for the allowed values of "direction": roll:
>>>>>>>>>>>> "positive_right_side_up" and "positive_right_side_down".
>>>>>>>>>>>> pitch: "positive_nose_up" and "positive_nose_down". yaw:
>>>>>>>>>>>> "positive_nose_right" and "positive_nose_left". surge:
>>>>>>>>>>>> "positive_forward" and "positive_backward". sway:
>>>>>>>>>>>> "positive_left" and "positive_right". heave: "positive_up"
>>>>>>>>>>>> and "positive_down". Cheers, Ethan On Wed, Aug 29, 2018 at
>>>>>>>>>>>> 12:02 PM Jim Biard <jbiard at cicsnc.org
>>>>>>>>>>>> <mailto:jbiard at cicsnc.org>>wrote: John, There are a variety
>>>>>>>>>>>> of conventions for defining roll, pitch, and yaw out there.
>>>>>>>>>>>> This is why we are avoiding a specific one. Others have
>>>>>>>>>>>> searched existing datasets that are using earlier versions
>>>>>>>>>>>> of these standard names (or not using standard names) and
>>>>>>>>>>>> found that they don't all follow the same convention.
>>>>>>>>>>>> Ethan, We purposely aren't answering that question directly
>>>>>>>>>>>> because of the issue above. I believe that I have
>>>>>>>>>>>> consistently followed the convention in which clockwise and
>>>>>>>>>>>> anticlockwise are rotational directions around a unit
>>>>>>>>>>>> vector facing the observer, where the X unit vector is in
>>>>>>>>>>>> the nominally forward direction, the Z axis is in the local
>>>>>>>>>>>> up direction, and the Y axis unit vector is "Z cross X",
>>>>>>>>>>>> which forms a right-handed coordinate system. The terms are
>>>>>>>>>>>> meaningful and accurate using that convention, but the
>>>>>>>>>>>> names could be "alpha" and "beta" or "dog" and "cat" as
>>>>>>>>>>>> long as they are used correctly. This whole topic is
>>>>>>>>>>>> fraught with competing conventions, so we are attempting to
>>>>>>>>>>>> avoid declaring that only one of them is valid, with it's
>>>>>>>>>>>> corresponding requirement that everyone follow that one
>>>>>>>>>>>> sign convention. In fact, we could reword things to remove
>>>>>>>>>>>> naming the axes X, Y, and Z, and perhaps we should. I know
>>>>>>>>>>>> of satellite platforms that define their Y axis unit vector
>>>>>>>>>>>> as pointing forward and the Z axis unit vector as pointing
>>>>>>>>>>>> down. Thoughts? Grace and peace, Jim On 8/29/18 1:32 PM,
>>>>>>>>>>>> John Helly wrote: Perhaps one should refer to the
>>>>>>>>>>>> discipline of hydrostatics for help with this? This paper,
>>>>>>>>>>>> pulled from a quick search, has a diagram referencing the
>>>>>>>>>>>> platforms' frame of reference with respect to its center of
>>>>>>>>>>>> gravity. Sorry if this comment is retrograd...
>>>>>>>>>>>> J. On 8/29/18 10:09, Ethan Davis wrote: Hi Jim, all, I'm a
>>>>>>>>>>>> bit confused by the "clockwise" and "anticlockwise". You
>>>>>>>>>>>> mention the orientation of the observer but not the
>>>>>>>>>>>> location/orientation of the clock. My assumptions (not sure
>>>>>>>>>>>> why) for the clock: for roll, the observer (who is facing
>>>>>>>>>>>> forward) would be facing the clock; for pitch, the observer
>>>>>>>>>>>> would look right to see the clock; and for yaw, the
>>>>>>>>>>>> observer would look down to see the clock. That works for
>>>>>>>>>>>> your definitions of pitch and yaw, but is backwards for
>>>>>>>>>>>> roll. Does "clockwise" add, in some way, another degree of
>>>>>>>>>>>> freedom to the definition? Does that degree of freedom need
>>>>>>>>>>>> to be nailed down in the definitions? Or other terms used
>>>>>>>>>>>> instead? I don't have any good suggestions other than
>>>>>>>>>>>> "positive" and "negative". Cheers, Ethan On Wed, Aug 29,
>>>>>>>>>>>> 2018 at 9:03 AM Jim Biard<jbiard at cicsnc.org>
>>>>>>>>>>>> <mailto:jbiard at cicsnc.org> wrote: Hi. I've finally gotten
>>>>>>>>>>>> back to this topic! The definitions below call out an
>>>>>>>>>>>> attribute named "direction" that is used to specify the
>>>>>>>>>>>> direction for positive values of the different quantities.
>>>>>>>>>>>> We may need to add a definition for the attribute to the
>>>>>>>>>>>> Conventions. The values and meanings for the direction
>>>>>>>>>>>> attribute are: 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. And here are the standard
>>>>>>>>>>>> name definitions: platform_roll: Platform is a structure or
>>>>>>>>>>>> vehicle that serves as a base for mounting sensors.
>>>>>>>>>>>> Platforms include, but are not limited to, satellites,
>>>>>>>>>>>> aeroplanes, ships, buoys, ground stations, and masts. Roll
>>>>>>>>>>>> is a rotation about an axis (the X axis) that is
>>>>>>>>>>>> perpendicular to the local vertical axis (the Z axis) and
>>>>>>>>>>>> is coplanar with the nominal forward motion direction of
>>>>>>>>>>>> the platform. Roll is relative to the ?at rest? rotation of
>>>>>>>>>>>> the platform with respect to the X axis. The ?at rest?
>>>>>>>>>>>> rotation of the platform may change over time. The
>>>>>>>>>>>> direction for positive values of roll is specified by an
>>>>>>>>>>>> attribute named direction. The value of the direction
>>>>>>>>>>>> attribute is "clockwise" if positive values of roll
>>>>>>>>>>>> represent the right side of the platform rising as viewed
>>>>>>>>>>>> by an observer on top of the platform facing forward. The
>>>>>>>>>>>> value of the direction attribute is "anticlockwise" if
>>>>>>>>>>>> positive values of roll represent the right side of the
>>>>>>>>>>>> platform falling. The directionality of roll values is
>>>>>>>>>>>> unspecified if no direction attribute is present.
>>>>>>>>>>>> platform_pitch: Platform is a structure or vehicle that
>>>>>>>>>>>> serves as a base for mounting sensors. Platforms include,
>>>>>>>>>>>> but are not limited to, satellites, aeroplanes, ships,
>>>>>>>>>>>> buoys, ground stations, and masts. Pitch is a rotation
>>>>>>>>>>>> about an axis (the Y axis) that is perpendicular to both
>>>>>>>>>>>> the local vertical axis (the Z axis) and the nominal
>>>>>>>>>>>> forward motion direction of the platform. Pitch is relative
>>>>>>>>>>>> to the ?at rest? rotation of the platform with respect to
>>>>>>>>>>>> the Y axis. The ?at rest? rotation of the platform may
>>>>>>>>>>>> change over time. The direction for positive values of
>>>>>>>>>>>> pitch is specified by an attribute named direction. The
>>>>>>>>>>>> value of the direction attribute is "clockwise" if positive
>>>>>>>>>>>> values of pitch represent the front of the platform rising
>>>>>>>>>>>> as viewed by an observer on top of the platform facing
>>>>>>>>>>>> forward. The value of the direction attribute is
>>>>>>>>>>>> "anticlockwise" if positive values of pitch represent the
>>>>>>>>>>>> front of the platform falling. The directionality of pitch
>>>>>>>>>>>> values is unspecified if no direction attribute is present.
>>>>>>>>>>>> platform_yaw: Platform is a structure or vehicle that
>>>>>>>>>>>> serves as a base for mounting sensors. Platforms include,
>>>>>>>>>>>> but are not limited to, satellites, aeroplanes, ships,
>>>>>>>>>>>> buoys, ground stations, and masts. Yaw is a rotation about
>>>>>>>>>>>> the local vertical axis (the Z axis). Yaw is relative to
>>>>>>>>>>>> the ?at rest? rotation of the platform with respect to the
>>>>>>>>>>>> Z axis. The ?at rest? rotation of the platform may change
>>>>>>>>>>>> over time. The direction for positive values of yaw is
>>>>>>>>>>>> specified by an attribute named direction. The value of the
>>>>>>>>>>>> direction attribute is "clockwise" if positive values of
>>>>>>>>>>>> yaw represent the front of the platform moving to the right
>>>>>>>>>>>> as viewed by an observer on top of the platform facing
>>>>>>>>>>>> forward. The value of the direction attribute is
>>>>>>>>>>>> "anticlockwise" if positive values of yaw represent the
>>>>>>>>>>>> front of the platform moving to the left. The
>>>>>>>>>>>> directionality of yaw values is unspecified if no direction
>>>>>>>>>>>> attribute is present. platform_surge: Platform is a
>>>>>>>>>>>> structure or vehicle that serves as a base for mounting
>>>>>>>>>>>> sensors. Platforms include, but are not limited to,
>>>>>>>>>>>> satellites, aeroplanes, ships, buoys, ground stations, and
>>>>>>>>>>>> masts. Surge is a displacement along an axis (the X axis)
>>>>>>>>>>>> that is perpendicular to the local vertical axis (the Z
>>>>>>>>>>>> axis) and is coplanar with the nominal forward motion
>>>>>>>>>>>> direction of the platform. Surge is relative to the ?at
>>>>>>>>>>>> rest? position of the platform with respect to the X axis.
>>>>>>>>>>>> The ?at rest? position of the platform may change over
>>>>>>>>>>>> time. The direction for positive values of surge is
>>>>>>>>>>>> specified by an attribute named direction. The value of the
>>>>>>>>>>>> direction attribute is "positive" if positive values of
>>>>>>>>>>>> surge represent the platform moving forward as viewed by an
>>>>>>>>>>>> observer on top of the platform facing forward. The value
>>>>>>>>>>>> of the direction attribute is "negative" if positive values
>>>>>>>>>>>> of surge represent the platform moving backward. The
>>>>>>>>>>>> directionality of surge values is unspecified if no
>>>>>>>>>>>> direction attribute is present. platform_sway: Platform is
>>>>>>>>>>>> a structure or vehicle that serves as a base for mounting
>>>>>>>>>>>> sensors. Platforms include, but are not limited to,
>>>>>>>>>>>> satellites, aeroplanes, ships, buoys, ground stations, and
>>>>>>>>>>>> masts. Sway is a displacement along an axis (the Y axis)
>>>>>>>>>>>> that is perpendicular to both the local vertical axis (the
>>>>>>>>>>>> Z axis) and the nominal forward motion direction of the
>>>>>>>>>>>> platform. Sway is relative to the ?at rest? position of the
>>>>>>>>>>>> platform with respect to the Y axis. The ?at rest? position
>>>>>>>>>>>> of the platform may change over time. The direction for
>>>>>>>>>>>> positive values of sway is specified by an attribute named
>>>>>>>>>>>> direction. The value of the direction attribute is
>>>>>>>>>>>> "positive" if positive values of sway represent the
>>>>>>>>>>>> platform moving left as viewed by an observer on top of the
>>>>>>>>>>>> platform facing forward. The value of the direction
>>>>>>>>>>>> attribute is "negative" if positive values of sway
>>>>>>>>>>>> represent the platform moving right. The directionality of
>>>>>>>>>>>> sway values is unspecified if no direction attribute is
>>>>>>>>>>>> present. platform_heave: Platform is a structure or vehicle
>>>>>>>>>>>> that serves as a base for mounting sensors. Platforms
>>>>>>>>>>>> include, but are not limited to, satellites, aeroplanes,
>>>>>>>>>>>> ships, buoys, ground stations, and masts. Heave is a
>>>>>>>>>>>> displacement along the local vertical axis (the Z axis).
>>>>>>>>>>>> Heave is relative to the ?at rest? position of the platform
>>>>>>>>>>>> with respect to the Z axis. The ?at rest? position of the
>>>>>>>>>>>> platform may change over time. The direction for positive
>>>>>>>>>>>> values of heave is specified by an attribute named
>>>>>>>>>>>> direction. The value of the direction attribute is
>>>>>>>>>>>> "positive" if positive values of heave represent the
>>>>>>>>>>>> platform moving up as viewed by an observer on top of the
>>>>>>>>>>>> platform facing forward. The value of the direction
>>>>>>>>>>>> attribute is "negative" if positive values of heave
>>>>>>>>>>>> represent the platform moving down. The directionality of
>>>>>>>>>>>> heave values is unspecified if no direction attribute is
>>>>>>>>>>>> present. platform_course: Platform is a structure or
>>>>>>>>>>>> vehicle that serves as a base for mounting sensors.
>>>>>>>>>>>> Platforms include, but are not limited to, satellites,
>>>>>>>>>>>> aeroplanes, ships, buoys, ground stations, and masts.
>>>>>>>>>>>> Course is the clockwise angle with respect to North of the
>>>>>>>>>>>> nominal forward motion direction of the platform.
>>>>>>>>>>>> platform_orientation: Platform is a structure or vehicle
>>>>>>>>>>>> that serves as a base for mounting sensors. Platforms
>>>>>>>>>>>> include, but are not limited to, satellites, aeroplanes,
>>>>>>>>>>>> ships, buoys, ground stations, and masts. Orientation is
>>>>>>>>>>>> the clockwise angle with respect to North of the
>>>>>>>>>>>> longitudinal (front-to-back) axis of the platform, which
>>>>>>>>>>>> may be different than the platform course (see
>>>>>>>>>>>> platform_course). platform_roll_rate: Platform is a
>>>>>>>>>>>> structure or vehicle that serves as a base for mounting
>>>>>>>>>>>> sensors. Platforms include, but are not limited to,
>>>>>>>>>>>> satellites, aeroplanes, ships, buoys, ground stations, and
>>>>>>>>>>>> masts. Roll rate is the rate of rotation about an axis (the
>>>>>>>>>>>> X axis) that is perpendicular to the local vertical axis
>>>>>>>>>>>> (the Z axis) and is coplanar with the nominal forward
>>>>>>>>>>>> motion direction of the platform. Roll rate might not
>>>>>>>>>>>> include changes in the ?at rest? rotation of the platform,
>>>>>>>>>>>> which may change over time. The direction for positive
>>>>>>>>>>>> values of roll rate is specified by an attribute named
>>>>>>>>>>>> direction. The value of the direction attribute is
>>>>>>>>>>>> "clockwise" if positive values of roll rate represent the
>>>>>>>>>>>> right side of the platform rising as viewed by an observer
>>>>>>>>>>>> on top of the platform facing forward. The value of the
>>>>>>>>>>>> direction attribute is "anticlockwise" if positive values
>>>>>>>>>>>> of roll rate represent the right side of the platform
>>>>>>>>>>>> falling. The directionality of roll rate values is
>>>>>>>>>>>> unspecified if no direction attribute is present.
>>>>>>>>>>>> platform_pitch_rate: Platform is a structure or vehicle
>>>>>>>>>>>> that serves as a base for mounting sensors. Platforms
>>>>>>>>>>>> include, but are not limited to, satellites, aeroplanes,
>>>>>>>>>>>> ships, buoys, ground stations, and masts. Pitch rate is the
>>>>>>>>>>>> rate of rotation about an axis (the Y axis) that is
>>>>>>>>>>>> perpendicular to both the local vertical axis (the Z axis)
>>>>>>>>>>>> and the nominal forward motion direction of the platform.
>>>>>>>>>>>> Pitch rate might not include changes in the ?at rest?
>>>>>>>>>>>> rotation of the platform, which may change over time. The
>>>>>>>>>>>> direction for positive values of pitch rate is specified by
>>>>>>>>>>>> an attribute named direction. The value of the direction
>>>>>>>>>>>> attribute is "clockwise" if positive values of pitch rate
>>>>>>>>>>>> represent the front of the platform rising as viewed by an
>>>>>>>>>>>> observer on top of the platform facing forward. The value
>>>>>>>>>>>> of the direction attribute is "anticlockwise" if positive
>>>>>>>>>>>> values of pitch rate represent the front of the platform
>>>>>>>>>>>> falling. The directionality of pitch rate values is
>>>>>>>>>>>> unspecified if no direction attribute is present.
>>>>>>>>>>>> platform_yaw_rate: Platform is a structure or vehicle that
>>>>>>>>>>>> serves as a base for mounting sensors. Platforms include,
>>>>>>>>>>>> but are not limited to, satellites, aeroplanes, ships,
>>>>>>>>>>>> buoys, ground stations, and masts. Yaw rate is the rate of
>>>>>>>>>>>> rotation about the local vertical axis (the Z axis). Yaw
>>>>>>>>>>>> rate might not include changes in the ?at rest? rotation of
>>>>>>>>>>>> the platform, which may change over time. The direction for
>>>>>>>>>>>> positive values of yaw rate is specified by an attribute
>>>>>>>>>>>> named direction. The value of the direction attribute is
>>>>>>>>>>>> "clockwise" if positive values of yaw rate represent the
>>>>>>>>>>>> front of the platform moving to the right as viewed by an
>>>>>>>>>>>> observer on top of the platform facing forward. The value
>>>>>>>>>>>> of the direction attribute is "anticlockwise" if positive
>>>>>>>>>>>> values of yaw rate represent the front of the platform
>>>>>>>>>>>> moving to the left. The directionality of yaw rate values
>>>>>>>>>>>> is unspecified if no direction attribute is present.
>>>>>>>>>>>> platform_surge_rate: Platform is a structure or vehicle
>>>>>>>>>>>> that serves as a base for mounting sensors. Platforms
>>>>>>>>>>>> include, but are not limited to, satellites, aeroplanes,
>>>>>>>>>>>> ships, buoys, ground stations, and masts. Surge rate is the
>>>>>>>>>>>> rate of displacement along an axis (the X axis) that is
>>>>>>>>>>>> perpendicular to the local vertical axis (the Z axis) and
>>>>>>>>>>>> is coplanar with the nominal forward motion direction of
>>>>>>>>>>>> the platform. Surge rate might not include changes in the
>>>>>>>>>>>> ?at rest? position of the platform, which may change over
>>>>>>>>>>>> time. The direction for positive values of surge rate is
>>>>>>>>>>>> specified by an attribute named direction. The value of the
>>>>>>>>>>>> direction attribute is "positive" if positive values of
>>>>>>>>>>>> surge rate represent the platform moving forward as viewed
>>>>>>>>>>>> by an observer on top of the platform facing forward. The
>>>>>>>>>>>> value of the direction attribute is "negative" if positive
>>>>>>>>>>>> values of surge rate represent the platform moving
>>>>>>>>>>>> backward. The directionality of surge rate values is
>>>>>>>>>>>> unspecified if no direction attribute is present.
>>>>>>>>>>>> platform_sway_rate: Platform is a structure or vehicle that
>>>>>>>>>>>> serves as a base for mounting sensors. Platforms include,
>>>>>>>>>>>> but are not limited to, satellites, aeroplanes, ships,
>>>>>>>>>>>> buoys, ground stations, and masts. Sway rate is the rate of
>>>>>>>>>>>> displacement along an axis (the Y axis) that is
>>>>>>>>>>>> perpendicular to both the local vertical axis (the Z axis)
>>>>>>>>>>>> and the nominal forward motion direction of the platform.
>>>>>>>>>>>> Sway rate might not include changes in the ?at rest?
>>>>>>>>>>>> position of the platform, which may change over time. The
>>>>>>>>>>>> direction for positive values of sway rate is specified by
>>>>>>>>>>>> an attribute named direction. The value of the direction
>>>>>>>>>>>> attribute is "positive" if positive values of sway rate
>>>>>>>>>>>> represent the platform moving left as viewed by an observer
>>>>>>>>>>>> on top of the platform facing forward. The value of the
>>>>>>>>>>>> direction attribute is "negative" if positive values of
>>>>>>>>>>>> sway rate represent the platform moving right. The
>>>>>>>>>>>> directionality of sway rate values is unspecified if no
>>>>>>>>>>>> direction attribute is present. platform_heave_rate:
>>>>>>>>>>>> Platform is a structure or vehicle that serves as a base
>>>>>>>>>>>> for mounting sensors. Platforms include, but are not
>>>>>>>>>>>> limited to, satellites, aeroplanes, ships, buoys, ground
>>>>>>>>>>>> stations, and masts. Heave rate is the rate of displacement
>>>>>>>>>>>> along the local vertical axis (the Z axis). Heave rate
>>>>>>>>>>>> might not include changes in the ?at rest? position of the
>>>>>>>>>>>> platform, which may change over time. The direction for
>>>>>>>>>>>> positive values of heave rate is specified by an attribute
>>>>>>>>>>>> named direction. The value of the direction attribute is
>>>>>>>>>>>> "positive" if positive values of heave rate represent the
>>>>>>>>>>>> platform moving up as viewed by an observer on top of the
>>>>>>>>>>>> platform facing forward. The value of the direction
>>>>>>>>>>>> attribute is "negative" if positive values of heave rate
>>>>>>>>>>>> represent the platform moving down. The directionality of
>>>>>>>>>>>> heave rate values is unspecified if no direction attribute
>>>>>>>>>>>> is present. 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: jbiard at cicsnc.org <mailto:jbiard at 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 _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
_at_NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20180911/4801169e/attachment-0001.html>
Received on Tue Sep 11 2018 - 09:37:06 BST
