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
>>>>>>>>>>>
--
*******************************************************
* Nan Galbraith Information Systems Specialist *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 (508) 289-2444 *
*******************************************************
Received on Tue Sep 11 2018 - 08:53:58 BST
