Dear Nan and Jim,
It was me, on my own volition, who raised concerns about the use of nautical terms to try and make the concepts domain-independent. However, 'port' is such an elegant way of saying 'left when facing forward' that I don't think we should resist it. Saw a nice definition for port - 'The side of a platform that is on the left when one is facing forward.'
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-bounces at cgd.ucar.edu> on behalf of Jim Biard <jbiard at cicsnc.org>
Sent: 11 September 2018 16:37
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave
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><mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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 1
0: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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 d
own. 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> <mailto: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 whic
h 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> <mailto: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 at
tribute 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 per
pendicular 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 pla
tform 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. Ori
entation 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 i
s "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 direc
tionality 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 directionalit
y 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 unspe
cified 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 @NOAANCEIocngeo<https://twitter.com/NOAANCEIocngeo>.
________________________________
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.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20180911/7ee85e01/attachment-0001.html>
Received on Tue Sep 11 2018 - 10:13:42 BST
