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 <[email protected]>
*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. <[email protected]
<mailto:[email protected]>> wrote:
Dear Jim,
Looking good to me.
Cheers, Roy.
------------------------------------------------------------------------
*From:* CF-metadata <[email protected]
<mailto:[email protected]>> on behalf of Jim Biard
<[email protected] <mailto:[email protected]>>
*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."
<[email protected]> <mailto:[email protected]> 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 <[email protected]>
<mailto:[email protected]> on behalf of Jonathan
Gregory <[email protected]>
<mailto:[email protected]> 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
<[email protected]> <mailto:[email protected]> 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 <[email protected]>
<mailto:[email protected]> on behalf of Jim Biard
<[email protected]> <mailto:[email protected]> *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<[email protected]> <mailto:[email protected]>-----
Date: Sun, 02 Sep 2018 11:57:33 -0400
From: Nan Galbraith<[email protected]>
<mailto:[email protected]>
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."<[email protected]>
<mailto:[email protected]> <mailto:[email protected]>
<mailto:[email protected]>:
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<[email protected]> <mailto:[email protected]>
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 <[email protected]>
<mailto:[email protected]> <mailto:[email protected]>
<mailto:[email protected]>
Date: Thu, 30 Aug 2018 12:05:44 -0600
From: Kenneth Kehoe<[email protected]> <mailto:[email protected]>
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 <[email protected]
<mailto:[email protected]>>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<[email protected]>
<mailto:[email protected]> 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: [email protected] <mailto:[email protected]>
o: +1 828 271 4900
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
@NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
