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
--
*******************************************************
* Nan Galbraith Information Systems Specialist *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 (508) 289-2444 *
*******************************************************
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
