Re: [CF-metadata] Platform Heave

[Kehoe, Kenneth E.]

I second Jim's thanks. Long discussion with a good outcome. The reason for this 
listserv!

Ken


On 2018-10-9 08:11, Jim Biard wrote:

Alison, Roy, Nan, (and the rest of you)

Thanks for all the hard work!

Jim

On 10/9/18 10:06 AM, Alison Pamment - UKRI STFC wrote:

Dear Roy,

Many thanks for checking through all the text.

We seem to have reached full consensus in this discussion, so all the platform 
names are accepted and will be included in the 15th October standard name table 
update. Altogether this will result in the addition of 28 new names, 3 aliases 
and 17 updated definitions. For the full list, please see the following link to 
the standard names editor: 
http://cfeditor.ceda.ac.uk/proposals/1?status=active=platform=+and+display=Filter.

I agree that we can always do further work to improve names and definitions, 
but also that now is the time to draw this particular discussion to a close. 
Thank you again to all those who submitted comments - these names are very much 
the result of community effort.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: 
alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

From: Lowry, Roy K. 
Sent: 07 October 2018 17:05
To: Pamment, Alison (STFC,RAL,RALSP) 
; CF-metadata 
(cf-metadata@cgd.ucar.edu) 

Subject: Re: Platform Heave

Dear Alison,

I have read through the definitions and can see no errors.

As always when doing this, one sees possible 'improvements' but these are not 
critical and so are best kept to myself or we will never reach end game with 
this proposal.

Cheers, Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata on behalf of Alison Pamment - UKRI STFC
Sent: 03 October 2018 18:10
To: CF-metadata (mailto:cf-metadata@cgd.ucar.edu)
Subject: [CF-metadata] Platform Heave
Dear Jim, Roy, Nan, Jonathan, et al.,

I have drawn together what I hope is the final list for the platform names.

We seem to be agreed on the need to have triplets of names to cope with 
opposite sign conventions and the case where the sign convention is unknown. 
I've followed Roy's comment 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020540.html
 regarding cross-referencing in the definitions, i.e. adding the statement to 
only choose the unsigned names if the convention is truly unknown. I plan to 
create aliases for some of the existing names as follows:
platform_yaw_angle -> platform_yaw
platform_pictch_angle -> platform_pitch
platform_roll_angle > platform_roll
to make them consistent with the new names. In addition to Jim's 12th September 
proposals 
(http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html),
 new names for platform_sway, platform_sway_rate, platform_surge and 
platform_surge_rate are needed to provide complete triplets of names for all 
the quantities.

The definitions of the new quantities are all based on Jim's text, with the 
'platform' description moved to the end. 'Instrument' has been added to the 
list of platforms as I think this was requested by Nan earlier in the 
discussion. (I think we can regard an 'instrument' as a way to mount one or 
more 'sensors'). The definitions of all existing platform names will be updated 
for consistency.

On a grammatical point, I noticed that the definitions of yaw/pitch/roll/surge 
rate in Jim's message all said "Yaw/pitch/roll/surge rate *might not* include 
changes to the "at rest" position of the platform ..." whereas the definitions 
of sway/heave rate said "Sway/heave rate *may not* include changes to the "at 
rest" position of the platform ...". I have changed all the definitions to say 
"might not" 

Re: [CF-metadata] Platform Heave

[Jim Biard]

Alison, Roy, Nan, (and the rest of you)

Thanks for all the hard work!

Jim


On 10/9/18 10:06 AM, Alison Pamment - UKRI STFC wrote:

Dear Roy,

Many thanks for checking through all the text.

We seem to have reached full consensus in this discussion, so all the platform names are accepted and will 
be included in the 15th October standard name table update. Altogether this will result in the addition of 
28 new names, 3 aliases and 17 updated definitions. For the full list, please see the following link to the 
standard names editor: 
http://cfeditor.ceda.ac.uk/proposals/1?status=active=platform=+and+display=Filter.

I agree that we can always do further work to improve names and definitions, 
but also that now is the time to draw this particular discussion to a close. 
Thank you again to all those who submitted comments - these names are very much 
the result of community effort.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

From: Lowry, Roy K. 
Sent: 07 October 2018 17:05
To: Pamment, Alison (STFC,RAL,RALSP) ; CF-metadata 
(cf-metadata@cgd.ucar.edu) 
Subject: Re: Platform Heave

Dear Alison,

I have read through the definitions and can see no errors.

As always when doing this, one sees possible 'improvements' but these are not 
critical and so are best kept to myself or we will never reach end game with 
this proposal.

Cheers, Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata on behalf of Alison Pamment - UKRI STFC
Sent: 03 October 2018 18:10
To: CF-metadata (mailto:cf-metadata@cgd.ucar.edu)
Subject: [CF-metadata] Platform Heave
Dear Jim, Roy, Nan, Jonathan, et al.,

I have drawn together what I hope is the final list for the platform names.

We seem to be agreed on the need to have triplets of names to cope with 
opposite sign conventions and the case where the sign convention is unknown. 
I've followed Roy's comment 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020540.html regarding 
cross-referencing in the definitions, i.e. adding the statement to only choose 
the unsigned names if the convention is truly unknown. I plan to create aliases 
for some of the existing names as follows:
platform_yaw_angle -> platform_yaw
platform_pictch_angle -> platform_pitch
platform_roll_angle > platform_roll
to make them consistent with the new names. In addition to Jim's 12th September 
proposals (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html), 
new names for platform_sway, platform_sway_rate, platform_surge and 
platform_surge_rate are needed to provide complete triplets of names for all 
the quantities.

The definitions of the new quantities are all based on Jim's text, with the 
'platform' description moved to the end. 'Instrument' has been added to the 
list of platforms as I think this was requested by Nan earlier in the 
discussion. (I think we can regard an 'instrument' as a way to mount one or 
more 'sensors'). The definitions of all existing platform names will be updated 
for consistency.

On a grammatical point, I noticed that the definitions of yaw/pitch/roll/surge rate in Jim's message all said "Yaw/pitch/roll/surge rate *might 
not* include changes to the "at rest" position of the platform ..." whereas the definitions of sway/heave rate said "Sway/heave 
rate *may not* include changes to the "at rest" position of the platform ...". I have changed all the definitions to say "might 
not" instead of "may not" as I think the latter could sound like we are prohibiting the inclusion of changes to the "at 
rest" position, which I don't think is the intention. Please correct me if this is wrong!

I have added all the names into the standard names editor: 
http://cfeditor.ceda.ac.uk/proposals/1?status=active=platform=+and+display=Filter.
 To save copying and pasting all the text into this message, please use the link to check through the full 
list. N.B. You can refine the filters to view smaller subsets of names together, e.g., 'platform_sway'. If 
no objections or suggestions for further changes are received, the names will be accepted in their current 
form and published on 15th October.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data Archival Email: 
mailto:alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

___
CF-metadata mailing list
mailto:CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 

Re: [CF-metadata] Platform Heave

[Alison Pamment - UKRI STFC]

Dear Roy,

Many thanks for checking through all the text.

We seem to have reached full consensus in this discussion, so all the platform 
names are accepted and will be included in the 15th October standard name table 
update. Altogether this will result in the addition of 28 new names, 3 aliases 
and 17 updated definitions. For the full list, please see the following link to 
the standard names editor: 
http://cfeditor.ceda.ac.uk/proposals/1?status=active=platform=+and+display=Filter.

I agree that we can always do further work to improve names and definitions, 
but also that now is the time to draw this particular discussion to a close. 
Thank you again to all those who submitted comments - these names are very much 
the result of community effort.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory 
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

From: Lowry, Roy K.  
Sent: 07 October 2018 17:05
To: Pamment, Alison (STFC,RAL,RALSP) ; CF-metadata 
(cf-metadata@cgd.ucar.edu) 
Subject: Re: Platform Heave

Dear Alison,

I have read through the definitions and can see no errors.

As always when doing this, one sees possible 'improvements' but these are not 
critical and so are best kept to myself or we will never reach end game with 
this proposal.

Cheers, Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata on behalf of Alison Pamment - UKRI STFC 
Sent: 03 October 2018 18:10
To: CF-metadata (mailto:cf-metadata@cgd.ucar.edu)
Subject: [CF-metadata] Platform Heave 
Dear Jim, Roy, Nan, Jonathan, et al.,

I have drawn together what I hope is the final list for the platform names.

We seem to be agreed on the need to have triplets of names to cope with 
opposite sign conventions and the case where the sign convention is unknown. 
I've followed Roy's comment 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020540.html regarding 
cross-referencing in the definitions, i.e. adding the statement to only choose 
the unsigned names if the convention is truly unknown. I plan to create aliases 
for some of the existing names as follows:
platform_yaw_angle -> platform_yaw
platform_pictch_angle -> platform_pitch
platform_roll_angle > platform_roll
to make them consistent with the new names. In addition to Jim's 12th September 
proposals (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html), 
new names for platform_sway, platform_sway_rate, platform_surge and 
platform_surge_rate are needed to provide complete triplets of names for all 
the quantities.

The definitions of the new quantities are all based on Jim's text, with the 
'platform' description moved to the end. 'Instrument' has been added to the 
list of platforms as I think this was requested by Nan earlier in the 
discussion. (I think we can regard an 'instrument' as a way to mount one or 
more 'sensors'). The definitions of all existing platform names will be updated 
for consistency.

On a grammatical point, I noticed that the definitions of yaw/pitch/roll/surge 
rate in Jim's message all said "Yaw/pitch/roll/surge rate *might not* include 
changes to the "at rest" position of the platform ..." whereas the definitions 
of sway/heave rate said "Sway/heave rate *may not* include changes to the "at 
rest" position of the platform ...". I have changed all the definitions to say 
"might not" instead of "may not" as I think the latter could sound like we are 
prohibiting the inclusion of changes to the "at rest" position, which I don't 
think is the intention. Please correct me if this is wrong!

I have added all the names into the standard names editor: 
http://cfeditor.ceda.ac.uk/proposals/1?status=active=platform=+and+display=Filter.
 To save copying and pasting all the text into this message, please use the 
link to check through the full list. N.B. You can refine the filters to view 
smaller subsets of names together, e.g., 'platform_sway'. If no objections or 
suggestions for further changes are received, the names will be accepted in 
their current form and published on 15th October.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data Archival Email: 
mailto:alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory 
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

___
CF-metadata mailing list
mailto:CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

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 

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Alison,


I have read through the definitions and can see no errors.


As always when doing this, one sees possible 'improvements' but these are not 
critical and so are best kept to myself or we will never reach end game with 
this proposal.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 03 October 2018 18:10
To: CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: [CF-metadata] Platform Heave

Dear Jim, Roy, Nan, Jonathan, et al.,

I have drawn together what I hope is the final list for the platform names.

We seem to be agreed on the need to have triplets of names to cope with 
opposite sign conventions and the case where the sign convention is unknown. 
I've followed Roy's comment 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020540.html regarding 
cross-referencing in the definitions, i.e. adding the statement to only choose 
the unsigned names if the convention is truly unknown. I plan to create aliases 
for some of the existing names as follows:
platform_yaw_angle -> platform_yaw
platform_pictch_angle -> platform_pitch
platform_roll_angle > platform_roll
to make them consistent with the new names. In addition to Jim's 12th September 
proposals (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html), 
new names for platform_sway, platform_sway_rate, platform_surge and 
platform_surge_rate are needed to provide complete triplets of names for all 
the quantities.

The definitions of the new quantities are all based on Jim's text, with the 
'platform' description moved to the end. 'Instrument' has been added to the 
list of platforms as I think this was requested by Nan earlier in the 
discussion. (I think we can regard an 'instrument' as a way to mount one or 
more 'sensors'). The definitions of all existing platform names will be updated 
for consistency.

On a grammatical point, I noticed that the definitions of yaw/pitch/roll/surge 
rate in Jim's message all said "Yaw/pitch/roll/surge rate *might not* include 
changes to the "at rest" position of the platform ..." whereas the definitions 
of sway/heave rate said "Sway/heave rate *may not* include changes to the "at 
rest" position of the platform ...". I have changed all the definitions to say 
"might not" instead of "may not" as I think the latter could sound like we are 
prohibiting the inclusion of changes to the "at rest" position, which I don't 
think is the intention. Please correct me if this is wrong!

I have added all the names into the standard names editor: 
http://cfeditor.ceda.ac.uk/proposals/1?status=active=platform=+and+display=Filter.
 To save copying and pasting all the text into this message, please use the 
link to check through the full list. N.B. You can refine the filters to view 
smaller subsets of names together, e.g., 'platform_sway'. If no objections or 
suggestions for further changes are received, the names will be accepted in 
their current form and published on 15th October.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

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.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Platform Heave

[Alison Pamment - UKRI STFC]

Dear Jim, Nan, Roy,

Thank you all for the quick responses.

Nan, you are correct that platform_id and platform_name are listed in the 
editor simply to update the description of 'platform' in their definitions. 
Sorry if that wasn't clear. There are several other 'under discussion' names in 
the list, purely because of the platform text:
angle_of_rotation_from_solar_azimuth_to_platform_azimuth;
platform_azimuth_angle;
platform_speed_wrt_air;
platform_speed_wrt_ground;
platform_speed_wrt_sea_water;
platform_view_angle;
platform_zenith_angle;
relative_platform_azimuth_angle.

The standard names platform_id and platform_name were introduced in V25 of the 
standard name table (July 2013) so they are not new. They were originally 
proposed in CF trac #37 as station_wmo_id and station_description. Later on it 
was agreed that the names should be generalized to say 'platform' so that they 
could be used for any observing location, not just wmo stations. The trac 
ticket was under discussion for a long time and there was concern that some 
data may have been written with the original versions of the names, so they 
have been retained as aliases of the later versions. The names and aliases do 
both appear in the standard name table in the usual way.

Jim, as you say, I included 'instrument' as a type of platform because Nan 
requested this in the original platform heave discussion 
(http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020195.html). Nan wrote
> Also, not to get too far into the weeds, but many of the platform terms are 
> important for instruments like ADCPs, so I'd just like to confirm that these 
> definitions - and the names themselves - can be used to describe instruments, 
> not just vehicles 'e.g.  aeroplane, ship or satellite'.   We already use pitch
> roll and yaw for these instruments on surface moorings, and I hope (and 
> assume) this is legal.

Roy, many thanks for offering to review the definitions. It's always good to 
have someone check them over thoroughly before publication.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory 
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.


-Original Message-
From: CF-metadata  On Behalf Of Nan Galbraith
Sent: 03 October 2018 20:25
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Thanks, Alison! I haven't read through all of these yet, but based on 
your email and
reading the ones I'm especially interested in, it looks great. I do have 
a quick question,
though.

I see  that platform_id and platform_name are 'under discussion', and 
reference this
thread as the 'CF mailing list link'.  Are they just on the the standard 
names editor
list because the definitions will have the description of platform 
updated (and moved
to the end), or are these actually changing in some other way?

Also, I looked at the standard name table and found these:

/platform_id//
//alias: station_wmo_id//
//Standard names for "platform" describe the motion and orientation of 
the vehicle from which
observations are made. Platforms include, but are not limited to, 
satellites, aeroplanes, ships,
instruments and buoys.  A variable with the standard name of platform_id 
contains strings
which help to identify the platform from which an observation was made. 
For example, this
may be a WMO station identification number. //

//platform_name//
//alias: station_description//
//Standard names for "platform" describe the motion and orientation of 
the vehicle from which
observations are made. Platforms include, but are not limited to, 
satellites, aeroplanes, ships,
instruments and buoys. A variable with the standard name of 
platform_name contains strings
which help to identify the platform from which an observation was made. 
For example, this
may be a geographical place name such as "South Pole" or the name of a 
meteorological
observing station./

I'm curious why they have aliases, especially since those aliases are 
not in the standard name
table.  Will those be removed when these definitions are updated? Also, 
has there been any
discussion about updating these (or the guidance for them) in any way, 
or are they purposely
left vague?

I don't want to take this thread off into another direction, I'm just 
curious about these terms.

Thanks again -
Nan

On 10/3/18 1:10 PM, Alison Pamment - UKRI STFC wrote:
> Dear Jim, Roy, Nan, Jonathan, et al.,
>
> I have drawn together what I hope is the final list for the platform names.
>
> We seem to be agreed on the need to have triplets of names to cope with 
> opposite sign conventions and the case where the sign convention is unknown. 
> I've followed Roy's comment 
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020540.html regarding 
> cross-

Re: [CF-metadata] Platform Heave

[Jim Biard]

Thanks Roy!

On 10/3/18 5:03 PM, Lowry, Roy K. wrote:


Dear Jim,


Currents are measured by attaching one or more current meters along a 
rope suspended in the water body known as the mooring. Established 
practice is to call the current meters the instruments and the 
mooring the platform. As current meters have developed, some have been 
fitted with orientation sensors. Nan's concern, which  I share, was to 
be sure that orientation data from current meters (which everybody in 
oceanography I know thinks of as instruments) were covered by the new 
Standard Name definitions.



There are other examples I can think of where oceanographic equipment 
commonly regarded as instruments measure orientation and/or motion 
relative to a local CRS.



Cheers, Roy


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.





*From:* CF-metadata  on behalf of 
Jim Biard 

*Sent:* 03 October 2018 20:38
*To:* cf-metadata@cgd.ucar.edu
*Subject:* Re: [CF-metadata] Platform Heave

Alison,

It all looks good to me. I must confess that I didn't give the 
definitions a super-careful reading.


I have a question, but I don't want it to derail anything. I'd just 
like to understand the thought.


We have included instrument as a type of platform per Nan's request, 
but in the areas I have worked in an instrument is always mounted on 
something, so I don't consider it to be an example of a platform. I'd 
consider the thing the instrument is mounted on as the platform. Is it 
common in other disciplines to think of instruments as free-standing 
(or floating or flying)?


Grace and peace,

Jim


On 10/3/18 1:10 PM, Alison Pamment - UKRI STFC wrote:

Dear Jim, Roy, Nan, Jonathan, et al.,

I have drawn together what I hope is the final list for the platform names.

We seem to be agreed on the need to have triplets of names to cope with 
opposite sign conventions and the case where the sign convention is unknown. 
I've followed Roy's 
commenthttp://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020540.html  
regarding cross-referencing in the definitions, i.e. adding the statement to 
only choose the unsigned names if the convention is truly unknown. I plan to 
create aliases for some of the existing names as follows:
platform_yaw_angle -> platform_yaw
platform_pictch_angle -> platform_pitch
platform_roll_angle > platform_roll
to make them consistent with the new names. In addition to Jim's 12th September 
proposals (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html), 
new names for platform_sway, platform_sway_rate, platform_surge and 
platform_surge_rate are needed to provide complete triplets of names for all 
the quantities.

The definitions of the new quantities are all based on Jim's text, with the 
'platform' description moved to the end. 'Instrument' has been added to the 
list of platforms as I think this was requested by Nan earlier in the 
discussion. (I think we can regard an 'instrument' as a way to mount one or 
more 'sensors'). The definitions of all existing platform names will be updated 
for consistency.

On a grammatical point, I noticed that the definitions of yaw/pitch/roll/surge rate in Jim's message all said "Yaw/pitch/roll/surge rate *might 
not* include changes to the "at rest" position of the platform ..." whereas the definitions of sway/heave rate said "Sway/heave 
rate *may not* include changes to the "at rest" position of the platform ...". I have changed all the definitions to say "might 
not" instead of "may not" as I think the latter could sound like we are prohibiting the inclusion of changes to the "at 
rest" position, which I don't think is the intention. Please correct me if this is wrong!

I have added all the names into the standard names 
editor:http://cfeditor.ceda.ac.uk/proposals/1?status=active=platform=+and+display=Filter.
 To save copying and pasting all the text into this message, please use the link to check through the full 
list. N.B. You can refine the filters to view smaller subsets of names together, e.g., 'platform_sway'. If 
no objections or suggestions for further changes are received, the names will be accepted in their current 
form and published on 15th October.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail:alison.pamm...@stfc.ac.uk 
<mailto:alison.pamm...@stfc.ac.uk>
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu <mailto:CF-metadata@cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


--
CICS-NC <http://www.cicsnc.org/>Visit us on
Facebook <http://www.facebook.com/cics

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Jim,


Currents are measured by attaching one or more current meters along a rope 
suspended in the water body known as the mooring. Established practice is to 
call the current meters the instruments and the mooring the platform. As 
current meters have developed, some have been fitted with orientation sensors.  
Nan's concern, which  I share, was to be sure that orientation data from 
current meters (which everybody in oceanography I know thinks of as 
instruments) were covered by the new Standard Name definitions.


There are other examples I can think of where oceanographic equipment commonly 
regarded as instruments measure orientation and/or motion relative to a local 
CRS.


Cheers, Roy


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 03 October 2018 20:38
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Alison,

It all looks good to me. I must confess that I didn't give the definitions a 
super-careful reading.

I have a question, but I don't want it to derail anything. I'd just like to 
understand the thought.

We have included instrument as a type of platform per Nan's request, but in the 
areas I have worked in an instrument is always mounted on something, so I don't 
consider it to be an example of a platform. I'd consider the thing the 
instrument is mounted on as the platform. Is it common in other disciplines to 
think of instruments as free-standing (or floating or flying)?

Grace and peace,

Jim

On 10/3/18 1:10 PM, Alison Pamment - UKRI STFC wrote:

Dear Jim, Roy, Nan, Jonathan, et al.,

I have drawn together what I hope is the final list for the platform names.

We seem to be agreed on the need to have triplets of names to cope with 
opposite sign conventions and the case where the sign convention is unknown. 
I've followed Roy's comment 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020540.html regarding 
cross-referencing in the definitions, i.e. adding the statement to only choose 
the unsigned names if the convention is truly unknown. I plan to create aliases 
for some of the existing names as follows:
platform_yaw_angle -> platform_yaw
platform_pictch_angle -> platform_pitch
platform_roll_angle > platform_roll
to make them consistent with the new names. In addition to Jim's 12th September 
proposals (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html), 
new names for platform_sway, platform_sway_rate, platform_surge and 
platform_surge_rate are needed to provide complete triplets of names for all 
the quantities.

The definitions of the new quantities are all based on Jim's text, with the 
'platform' description moved to the end. 'Instrument' has been added to the 
list of platforms as I think this was requested by Nan earlier in the 
discussion. (I think we can regard an 'instrument' as a way to mount one or 
more 'sensors'). The definitions of all existing platform names will be updated 
for consistency.

On a grammatical point, I noticed that the definitions of yaw/pitch/roll/surge 
rate in Jim's message all said "Yaw/pitch/roll/surge rate *might not* include 
changes to the "at rest" position of the platform ..." whereas the definitions 
of sway/heave rate said "Sway/heave rate *may not* include changes to the "at 
rest" position of the platform ...". I have changed all the definitions to say 
"might not" instead of "may not" as I think the latter could sound like we are 
prohibiting the inclusion of changes to the "at rest" position, which I don't 
think is the intention. Please correct me if this is wrong!

I have added all the names into the standard names editor: 
http://cfeditor.ceda.ac.uk/proposals/1?status=active=platform=+and+display=Filter.
 To save copying and pasting all the text into this message, please use the 
link to check through the full list. N.B. You can refine the filters to view 
smaller subsets of names together, e.g., 'platform_sway'. If no objections or 
suggestions for further changes are received, the names will be accepted in 
their current form and published on 15th October.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: 
alison.pamm...@stfc.ac.uk<mailto:alison.pamm...@stfc.ac.uk>
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu<mailto:CF-metadata@cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


--
[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.or

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Alison,


I'll give these a final careful read through early next week.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 03 October 2018 18:10
To: CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: [CF-metadata] Platform Heave

Dear Jim, Roy, Nan, Jonathan, et al.,

I have drawn together what I hope is the final list for the platform names.

We seem to be agreed on the need to have triplets of names to cope with 
opposite sign conventions and the case where the sign convention is unknown. 
I've followed Roy's comment 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020540.html regarding 
cross-referencing in the definitions, i.e. adding the statement to only choose 
the unsigned names if the convention is truly unknown. I plan to create aliases 
for some of the existing names as follows:
platform_yaw_angle -> platform_yaw
platform_pictch_angle -> platform_pitch
platform_roll_angle > platform_roll
to make them consistent with the new names. In addition to Jim's 12th September 
proposals (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html), 
new names for platform_sway, platform_sway_rate, platform_surge and 
platform_surge_rate are needed to provide complete triplets of names for all 
the quantities.

The definitions of the new quantities are all based on Jim's text, with the 
'platform' description moved to the end. 'Instrument' has been added to the 
list of platforms as I think this was requested by Nan earlier in the 
discussion. (I think we can regard an 'instrument' as a way to mount one or 
more 'sensors'). The definitions of all existing platform names will be updated 
for consistency.

On a grammatical point, I noticed that the definitions of yaw/pitch/roll/surge 
rate in Jim's message all said "Yaw/pitch/roll/surge rate *might not* include 
changes to the "at rest" position of the platform ..." whereas the definitions 
of sway/heave rate said "Sway/heave rate *may not* include changes to the "at 
rest" position of the platform ...". I have changed all the definitions to say 
"might not" instead of "may not" as I think the latter could sound like we are 
prohibiting the inclusion of changes to the "at rest" position, which I don't 
think is the intention. Please correct me if this is wrong!

I have added all the names into the standard names editor: 
http://cfeditor.ceda.ac.uk/proposals/1?status=active=platform=+and+display=Filter.
 To save copying and pasting all the text into this message, please use the 
link to check through the full list. N.B. You can refine the filters to view 
smaller subsets of names together, e.g., 'platform_sway'. If no objections or 
suggestions for further changes are received, the names will be accepted in 
their current form and published on 15th October.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

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.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Platform Heave

[Jim Biard]

Alison,

It all looks good to me. I must confess that I didn't give the 
definitions a super-careful reading.


I have a question, but I don't want it to derail anything. I'd just like 
to understand the thought.


We have included instrument as a type of platform per Nan's request, but 
in the areas I have worked in an instrument is always mounted on 
something, so I don't consider it to be an example of a platform. I'd 
consider the thing the instrument is mounted on as the platform. Is it 
common in other disciplines to think of instruments as free-standing (or 
floating or flying)?


Grace and peace,

Jim


On 10/3/18 1:10 PM, Alison Pamment - UKRI STFC wrote:

Dear Jim, Roy, Nan, Jonathan, et al.,

I have drawn together what I hope is the final list for the platform names.

We seem to be agreed on the need to have triplets of names to cope with 
opposite sign conventions and the case where the sign convention is unknown. 
I've followed Roy's comment 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020540.html regarding 
cross-referencing in the definitions, i.e. adding the statement to only choose 
the unsigned names if the convention is truly unknown. I plan to create aliases 
for some of the existing names as follows:
platform_yaw_angle -> platform_yaw
platform_pictch_angle -> platform_pitch
platform_roll_angle > platform_roll
to make them consistent with the new names. In addition to Jim's 12th September 
proposals (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html), 
new names for platform_sway, platform_sway_rate, platform_surge and 
platform_surge_rate are needed to provide complete triplets of names for all 
the quantities.

The definitions of the new quantities are all based on Jim's text, with the 
'platform' description moved to the end. 'Instrument' has been added to the 
list of platforms as I think this was requested by Nan earlier in the 
discussion. (I think we can regard an 'instrument' as a way to mount one or 
more 'sensors'). The definitions of all existing platform names will be updated 
for consistency.

On a grammatical point, I noticed that the definitions of yaw/pitch/roll/surge rate in Jim's message all said "Yaw/pitch/roll/surge rate *might 
not* include changes to the "at rest" position of the platform ..." whereas the definitions of sway/heave rate said "Sway/heave 
rate *may not* include changes to the "at rest" position of the platform ...". I have changed all the definitions to say "might 
not" instead of "may not" as I think the latter could sound like we are prohibiting the inclusion of changes to the "at 
rest" position, which I don't think is the intention. Please correct me if this is wrong!

I have added all the names into the standard names editor: 
http://cfeditor.ceda.ac.uk/proposals/1?status=active=platform=+and+display=Filter.
 To save copying and pasting all the text into this message, please use the link to check through the full 
list. N.B. You can refine the filters to view smaller subsets of names together, e.g., 'platform_sway'. If 
no objections or suggestions for further changes are received, the names will be accepted in their current 
form and published on 15th October.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


--
CICS-NC  Visit us on
Facebook  *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC 
North Carolina State University 
NOAA National Centers for Environmental Information 
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org 
o: +1 828 271 4900

/Connect with us on Facebook for climate 
 and ocean and geophysics 
 information, and follow us 
on Twitter at @NOAANCEIclimate  and 
@NOAANCEIocngeo . /



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Platform Heave

[Nan Galbraith]

Thanks, Alison! I haven't read through all of these yet, but based on 
your email and
reading the ones I'm especially interested in, it looks great. I do have 
a quick question,

though.

I see  that platform_id and platform_name are 'under discussion', and 
reference this
thread as the 'CF mailing list link'.  Are they just on the the standard 
names editor
list because the definitions will have the description of platform 
updated (and moved

to the end), or are these actually changing in some other way?

Also, I looked at the standard name table and found these:

/platform_id//
//alias: station_wmo_id//
//Standard names for "platform" describe the motion and orientation of 
the vehicle from which
observations are made. Platforms include, but are not limited to, 
satellites, aeroplanes, ships,
instruments and buoys.  A variable with the standard name of platform_id 
contains strings
which help to identify the platform from which an observation was made. 
For example, this

may be a WMO station identification number. //

//platform_name//
//alias: station_description//
//Standard names for "platform" describe the motion and orientation of 
the vehicle from which
observations are made. Platforms include, but are not limited to, 
satellites, aeroplanes, ships,
instruments and buoys. A variable with the standard name of 
platform_name contains strings
which help to identify the platform from which an observation was made. 
For example, this
may be a geographical place name such as "South Pole" or the name of a 
meteorological

observing station./

I'm curious why they have aliases, especially since those aliases are 
not in the standard name
table.  Will those be removed when these definitions are updated? Also, 
has there been any
discussion about updating these (or the guidance for them) in any way, 
or are they purposely

left vague?

I don't want to take this thread off into another direction, I'm just 
curious about these terms.


Thanks again -
Nan

On 10/3/18 1:10 PM, Alison Pamment - UKRI STFC wrote:

Dear Jim, Roy, Nan, Jonathan, et al.,

I have drawn together what I hope is the final list for the platform names.

We seem to be agreed on the need to have triplets of names to cope with 
opposite sign conventions and the case where the sign convention is unknown. 
I've followed Roy's comment 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020540.html regarding 
cross-referencing in the definitions, i.e. adding the statement to only choose 
the unsigned names if the convention is truly unknown. I plan to create aliases 
for some of the existing names as follows:
platform_yaw_angle -> platform_yaw
platform_pictch_angle -> platform_pitch
platform_roll_angle > platform_roll
to make them consistent with the new names. In addition to Jim's 12th September 
proposals (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html), 
new names for platform_sway, platform_sway_rate, platform_surge and 
platform_surge_rate are needed to provide complete triplets of names for all 
the quantities.

The definitions of the new quantities are all based on Jim's text, with the 
'platform' description moved to the end. 'Instrument' has been added to the 
list of platforms as I think this was requested by Nan earlier in the 
discussion. (I think we can regard an 'instrument' as a way to mount one or 
more 'sensors'). The definitions of all existing platform names will be updated 
for consistency.

On a grammatical point, I noticed that the definitions of yaw/pitch/roll/surge rate in Jim's message all said "Yaw/pitch/roll/surge rate *might 
not* include changes to the "at rest" position of the platform ..." whereas the definitions of sway/heave rate said "Sway/heave 
rate *may not* include changes to the "at rest" position of the platform ...". I have changed all the definitions to say "might 
not" instead of "may not" as I think the latter could sound like we are prohibiting the inclusion of changes to the "at 
rest" position, which I don't think is the intention. Please correct me if this is wrong!

I have added all the names into the standard names editor: 
http://cfeditor.ceda.ac.uk/proposals/1?status=active=platform=+and+display=Filter.
 To save copying and pasting all the text into this message, please use the link to check through the full 
list. N.B. You can refine the filters to view smaller subsets of names together, e.g., 'platform_sway'. If 
no objections or suggestions for further changes are received, the names will be accepted in their current 
form and published on 15th October.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Jonathan,


I totally agree that creation of new unsigned datasets should be strongly 
discouraged, but disagree with the deprecation and creation of new Standard 
Names for two reasons.


First, the creation of the new names is more likely to encourage the new data 
sets without the sign convention - new names give the impression that they are 
acceptable. Adding the cross-referencing text to the existing Standard Name 
definitions, making it clear that their use is not best practice seems a much 
better strategy to me.


Secondly, it causes the pain of going through and editing existing file stock 
for very little gain. Remember the number of files affected could easily run 
into thousands and significant workload results from overheads such as version 
management.


Cheers, Roy.



I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 20 September 2018 16:16
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Dear Alison

If it's necessary to have names for unsigned quantities because it's really
not known, then I agree we should, but I think we ought strongly to discourage
recording of data without a sign convention. Maybe we could introduce new
names (with the existing ones as aliases) that explicitly say "unknown sign"
in them, in some way, with definitions that say they shouldn't be used if the
sign is known.

Best wishes

Jonathan

- Forwarded message from Alison Pamment - UKRI STFC 
 -

> Date: Thu, 20 Sep 2018 14:59:51 +
> From: Alison Pamment - UKRI STFC 
> To: "r...@bodc.ac.uk" , "cf-metadata@cgd.ucar.edu"
>, "ngalbra...@whoi.edu"
>
> Subject: Re: [CF-metadata] Platform Heave
>
> Dear Nan and Roy,
>
> In fact I had neglected to consider the case when the sign is unknown or 
> unrecorded. I am used to thinking about model data, where the sign of a 
> quantity is always known, but I appreciate that things may be different in 
> the world of observations! Nan's suggestion of retaining the current names 
> and also adding the pairs of new signed names would cover all possibilities 
> and fits within the existing schema for the standard name table. (If we go 
> down this route then I think we should still create aliases for the existing 
> names to remove the word 'angle' for consistency with the new names).
>
> As you both point out, the definitions could be written to cross-reference 
> the signed and unsigned names so that CF users are directed to the most 
> appropriate name for their data. The appropriate NVS mappings could certainly 
> also be created.
>
> I agree with Roy that we should allow for signed (and unsigned) rates, again 
> with appropriate cross-references in the definitions.
>
> Do others support the idea of having triplets of names in this way?
>
> Best wishes,
> Alison
>
> --
> Alison Pamment Tel: +44 1235 778065
> NCAS/Centre for Environmental Data ArchivalEmail: 
> alison.pamm...@stfc.ac.uk
> STFC Rutherford Appleton Laboratory
> R25, 2.22
> Harwell Oxford, Didcot, OX11 0QX, U.K.
>
> From: CF-metadata  On Behalf Of Lowry, Roy 
> K.
> Sent: 20 September 2018 15:38
> To: cf-metadata@cgd.ucar.edu; ngalbra...@whoi.edu
> Subject: Re: [CF-metadata] Platform Heave
>
> Hi Nan,
>
> My understanding is that Alison was proposing leaving the existing 
> pitch/roll/yaw/heave in place, but with a note in the definitions that 
> direction isn't specified. New direction-specific names would then be added 
> and linked to the existing names as aliases (in the CF XML) or NarrowMatch 
> mappings (in NVS). This requires a change in the definition of 'alias' in the 
> CF Convention, which seems to have strong support.
>
> This is exactly what you want!
>
> Regarding the heave rates, I don't agree. In my view, if the quantities are 
> explicitly signed then names for explicitly signed quantity rate vectors 
> should also be available.
>
> Cheers, Roy.
>
> I have now retired but will continue to be active through an Emeritus 
> Fellowship using this e-mail address.
>
> ________________
> From: CF-metadata <mailto:cf-metadata-boun...@cgd.ucar.edu> on behalf of Nan 
> Galbraith <mailto:ngalbra...@whoi.edu>
> Sent: 20 September 2018 15:11
> To: mailto:cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Platform Heave
>
> Thank you, Alison. This all looks good.
>
> With regards to your last point, about the existing names
> heave/yaw/pitch/roll  (and their rates),
> I'm not sure why we need to deprecate anything or even create these
> aliases. There may 

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

Dear Alison

If it's necessary to have names for unsigned quantities because it's really
not known, then I agree we should, but I think we ought strongly to discourage
recording of data without a sign convention. Maybe we could introduce new
names (with the existing ones as aliases) that explicitly say "unknown sign"
in them, in some way, with definitions that say they shouldn't be used if the
sign is known.

Best wishes

Jonathan

- Forwarded message from Alison Pamment - UKRI STFC 
 -

> Date: Thu, 20 Sep 2018 14:59:51 +
> From: Alison Pamment - UKRI STFC 
> To: "r...@bodc.ac.uk" , "cf-metadata@cgd.ucar.edu"
>   , "ngalbra...@whoi.edu"
>   
> Subject: Re: [CF-metadata] Platform Heave
> 
> Dear Nan and Roy,
> 
> In fact I had neglected to consider the case when the sign is unknown or 
> unrecorded. I am used to thinking about model data, where the sign of a 
> quantity is always known, but I appreciate that things may be different in 
> the world of observations! Nan's suggestion of retaining the current names 
> and also adding the pairs of new signed names would cover all possibilities 
> and fits within the existing schema for the standard name table. (If we go 
> down this route then I think we should still create aliases for the existing 
> names to remove the word 'angle' for consistency with the new names).
> 
> As you both point out, the definitions could be written to cross-reference 
> the signed and unsigned names so that CF users are directed to the most 
> appropriate name for their data. The appropriate NVS mappings could certainly 
> also be created.
> 
> I agree with Roy that we should allow for signed (and unsigned) rates, again 
> with appropriate cross-references in the definitions.
> 
> Do others support the idea of having triplets of names in this way?
> 
> Best wishes,
> Alison
> 
> --
> Alison Pamment Tel: +44 1235 778065
> NCAS/Centre for Environmental Data ArchivalEmail: 
> alison.pamm...@stfc.ac.uk
> STFC Rutherford Appleton Laboratory 
> R25, 2.22
> Harwell Oxford, Didcot, OX11 0QX, U.K.
> 
> From: CF-metadata  On Behalf Of Lowry, Roy 
> K.
> Sent: 20 September 2018 15:38
> To: cf-metadata@cgd.ucar.edu; ngalbra...@whoi.edu
> Subject: Re: [CF-metadata] Platform Heave
> 
> Hi Nan,
> 
> My understanding is that Alison was proposing leaving the existing 
> pitch/roll/yaw/heave in place, but with a note in the definitions that 
> direction isn't specified. New direction-specific names would then be added 
> and linked to the existing names as aliases (in the CF XML) or NarrowMatch 
> mappings (in NVS). This requires a change in the definition of 'alias' in the 
> CF Convention, which seems to have strong support.
> 
> This is exactly what you want!
> 
> Regarding the heave rates, I don't agree. In my view, if the quantities are 
> explicitly signed then names for explicitly signed quantity rate vectors 
> should also be available.
> 
> Cheers, Roy.
> 
> I have now retired but will continue to be active through an Emeritus 
> Fellowship using this e-mail address.
> 
> ________________
> From: CF-metadata <mailto:cf-metadata-boun...@cgd.ucar.edu> on behalf of Nan 
> Galbraith <mailto:ngalbra...@whoi.edu>
> Sent: 20 September 2018 15:11
> To: mailto:cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Platform Heave 
>  
> Thank you, Alison. This all looks good.
> 
> With regards to your last point, about the existing names 
> heave/yaw/pitch/roll  (and their rates),
> I'm not sure why we need to deprecate anything or even create these 
> aliases. There may be cases
> where the magnitude of e.g. heave is important, but doesn't really even 
> need to be signed - or
> can't be signed because the heave distance or rate is provided by an 
> instrument and the 'sense' of
> the heave is not included.
> 
> Can't we just leave the existing (unsigned) names as they are, adding a 
> sentence about using the
> direction-specific names when direction is known?
> 
> Also, do we need both platform_heave_rate_up and 
> platform_heave_rate_down, or is heave_rate
> sufficient? This also applies to most or all of the rates ... sorry I 
> haven't looked at all of them
> to check how many pairs could be combined.
> 
> Last, thanks for clarifying the issue of order of terms in the 
> definitions. When using the
> html search function and looking for the difference between say 
> platform_course and
> platform_orientation, it is *much* easier (for a human, at least) if the 
> definition of the
> quantity comes first. Not everyone uses the standard name table 

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Thanks Alison,


I'd obviously misread/misunderstood your last message.  The 'triplet' method 
when narrowing the meaning of a Standard Name does help those of us who hold 
large file stocks of historical data, some of which has very poor metadata by 
present-day standards, but still has value.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: Alison Pamment - UKRI STFC 
Sent: 20 September 2018 15:59
To: Lowry, Roy K.; cf-metadata@cgd.ucar.edu; ngalbra...@whoi.edu
Subject: RE: [CF-metadata] Platform Heave

Dear Nan and Roy,

In fact I had neglected to consider the case when the sign is unknown or 
unrecorded. I am used to thinking about model data, where the sign of a 
quantity is always known, but I appreciate that things may be different in the 
world of observations! Nan's suggestion of retaining the current names and also 
adding the pairs of new signed names would cover all possibilities and fits 
within the existing schema for the standard name table. (If we go down this 
route then I think we should still create aliases for the existing names to 
remove the word 'angle' for consistency with the new names).

As you both point out, the definitions could be written to cross-reference the 
signed and unsigned names so that CF users are directed to the most appropriate 
name for their data. The appropriate NVS mappings could certainly also be 
created.

I agree with Roy that we should allow for signed (and unsigned) rates, again 
with appropriate cross-references in the definitions.

Do others support the idea of having triplets of names in this way?

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

From: CF-metadata  On Behalf Of Lowry, Roy K.
Sent: 20 September 2018 15:38
To: cf-metadata@cgd.ucar.edu; ngalbra...@whoi.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Nan,

My understanding is that Alison was proposing leaving the existing 
pitch/roll/yaw/heave in place, but with a note in the definitions that 
direction isn't specified. New direction-specific names would then be added and 
linked to the existing names as aliases (in the CF XML) or NarrowMatch mappings 
(in NVS). This requires a change in the definition of 'alias' in the CF 
Convention, which seems to have strong support.

This is exactly what you want!

Regarding the heave rates, I don't agree. In my view, if the quantities are 
explicitly signed then names for explicitly signed quantity rate vectors should 
also be available.

Cheers, Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata <mailto:cf-metadata-boun...@cgd.ucar.edu> on behalf of Nan 
Galbraith <mailto:ngalbra...@whoi.edu>
Sent: 20 September 2018 15:11
To: mailto:cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Thank you, Alison. This all looks good.

With regards to your last point, about the existing names
heave/yaw/pitch/roll  (and their rates),
I'm not sure why we need to deprecate anything or even create these
aliases. There may be cases
where the magnitude of e.g. heave is important, but doesn't really even
need to be signed - or
can't be signed because the heave distance or rate is provided by an
instrument and the 'sense' of
the heave is not included.

Can't we just leave the existing (unsigned) names as they are, adding a
sentence about using the
direction-specific names when direction is known?

Also, do we need both platform_heave_rate_up and
platform_heave_rate_down, or is heave_rate
sufficient? This also applies to most or all of the rates ... sorry I
haven't looked at all of them
to check how many pairs could be combined.

Last, thanks for clarifying the issue of order of terms in the
definitions. When using the
html search function and looking for the difference between say
platform_course and
platform_orientation, it is *much* easier (for a human, at least) if the
definition of the
quantity comes first. Not everyone uses the standard name table this
way, I know, but for
those who do this is really helpful.

Thanks for bringing this together!

- Nan



On 9/20/18 4:35 AM, Lowry, Roy K. wrote:
>
> Dear Alison,
>
>
> Your proposal is a much better solution than deprecating the original
> Standard Name and so has full support of Gwen and I.
>
>
> Cheers, Roy.
>
>
> I have now retired but will continue to be active through an Emeritus
> Fellowship using this e-mail address.
>
>
>
> 
> *From:* Alison Pamment - UKRI STFC <mailto:alison.pamm...@stfc.ac.uk>
> 

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Apologies Nan,


It was me who had misunderstood Alison's proposal!


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: Alison Pamment - UKRI STFC 
Sent: 20 September 2018 15:59
To: Lowry, Roy K.; cf-metadata@cgd.ucar.edu; ngalbra...@whoi.edu
Subject: RE: [CF-metadata] Platform Heave

Dear Nan and Roy,

In fact I had neglected to consider the case when the sign is unknown or 
unrecorded. I am used to thinking about model data, where the sign of a 
quantity is always known, but I appreciate that things may be different in the 
world of observations! Nan's suggestion of retaining the current names and also 
adding the pairs of new signed names would cover all possibilities and fits 
within the existing schema for the standard name table. (If we go down this 
route then I think we should still create aliases for the existing names to 
remove the word 'angle' for consistency with the new names).

As you both point out, the definitions could be written to cross-reference the 
signed and unsigned names so that CF users are directed to the most appropriate 
name for their data. The appropriate NVS mappings could certainly also be 
created.

I agree with Roy that we should allow for signed (and unsigned) rates, again 
with appropriate cross-references in the definitions.

Do others support the idea of having triplets of names in this way?

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

From: CF-metadata  On Behalf Of Lowry, Roy K.
Sent: 20 September 2018 15:38
To: cf-metadata@cgd.ucar.edu; ngalbra...@whoi.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Nan,

My understanding is that Alison was proposing leaving the existing 
pitch/roll/yaw/heave in place, but with a note in the definitions that 
direction isn't specified. New direction-specific names would then be added and 
linked to the existing names as aliases (in the CF XML) or NarrowMatch mappings 
(in NVS). This requires a change in the definition of 'alias' in the CF 
Convention, which seems to have strong support.

This is exactly what you want!

Regarding the heave rates, I don't agree. In my view, if the quantities are 
explicitly signed then names for explicitly signed quantity rate vectors should 
also be available.

Cheers, Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata <mailto:cf-metadata-boun...@cgd.ucar.edu> on behalf of Nan 
Galbraith <mailto:ngalbra...@whoi.edu>
Sent: 20 September 2018 15:11
To: mailto:cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Thank you, Alison. This all looks good.

With regards to your last point, about the existing names
heave/yaw/pitch/roll  (and their rates),
I'm not sure why we need to deprecate anything or even create these
aliases. There may be cases
where the magnitude of e.g. heave is important, but doesn't really even
need to be signed - or
can't be signed because the heave distance or rate is provided by an
instrument and the 'sense' of
the heave is not included.

Can't we just leave the existing (unsigned) names as they are, adding a
sentence about using the
direction-specific names when direction is known?

Also, do we need both platform_heave_rate_up and
platform_heave_rate_down, or is heave_rate
sufficient? This also applies to most or all of the rates ... sorry I
haven't looked at all of them
to check how many pairs could be combined.

Last, thanks for clarifying the issue of order of terms in the
definitions. When using the
html search function and looking for the difference between say
platform_course and
platform_orientation, it is *much* easier (for a human, at least) if the
definition of the
quantity comes first. Not everyone uses the standard name table this
way, I know, but for
those who do this is really helpful.

Thanks for bringing this together!

- Nan



On 9/20/18 4:35 AM, Lowry, Roy K. wrote:
>
> Dear Alison,
>
>
> Your proposal is a much better solution than deprecating the original
> Standard Name and so has full support of Gwen and I.
>
>
> Cheers, Roy.
>
>
> I have now retired but will continue to be active through an Emeritus
> Fellowship using this e-mail address.
>
>
>
> 
> *From:* Alison Pamment - UKRI STFC <mailto:alison.pamm...@stfc.ac.uk>
> *Sent:* 19 September 2018 19:04
> *To:* Lowry, Roy K.; Jim Biard; mailto:cf-metadata@cgd.ucar.edu
> *Subject:* RE: [CF-metadata] Platform Heave
> Dear Jim et al.,
>
> Thank you again for all the work on these n

Re: [CF-metadata] Platform Heave

[Alison Pamment - UKRI STFC]

Dear Nan and Roy,

In fact I had neglected to consider the case when the sign is unknown or 
unrecorded. I am used to thinking about model data, where the sign of a 
quantity is always known, but I appreciate that things may be different in the 
world of observations! Nan's suggestion of retaining the current names and also 
adding the pairs of new signed names would cover all possibilities and fits 
within the existing schema for the standard name table. (If we go down this 
route then I think we should still create aliases for the existing names to 
remove the word 'angle' for consistency with the new names).

As you both point out, the definitions could be written to cross-reference the 
signed and unsigned names so that CF users are directed to the most appropriate 
name for their data. The appropriate NVS mappings could certainly also be 
created.

I agree with Roy that we should allow for signed (and unsigned) rates, again 
with appropriate cross-references in the definitions.

Do others support the idea of having triplets of names in this way?

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory 
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

From: CF-metadata  On Behalf Of Lowry, Roy K.
Sent: 20 September 2018 15:38
To: cf-metadata@cgd.ucar.edu; ngalbra...@whoi.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Nan,

My understanding is that Alison was proposing leaving the existing 
pitch/roll/yaw/heave in place, but with a note in the definitions that 
direction isn't specified. New direction-specific names would then be added and 
linked to the existing names as aliases (in the CF XML) or NarrowMatch mappings 
(in NVS). This requires a change in the definition of 'alias' in the CF 
Convention, which seems to have strong support.

This is exactly what you want!

Regarding the heave rates, I don't agree. In my view, if the quantities are 
explicitly signed then names for explicitly signed quantity rate vectors should 
also be available.

Cheers, Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata <mailto:cf-metadata-boun...@cgd.ucar.edu> on behalf of Nan 
Galbraith <mailto:ngalbra...@whoi.edu>
Sent: 20 September 2018 15:11
To: mailto:cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave 
 
Thank you, Alison. This all looks good.

With regards to your last point, about the existing names 
heave/yaw/pitch/roll  (and their rates),
I'm not sure why we need to deprecate anything or even create these 
aliases. There may be cases
where the magnitude of e.g. heave is important, but doesn't really even 
need to be signed - or
can't be signed because the heave distance or rate is provided by an 
instrument and the 'sense' of
the heave is not included.

Can't we just leave the existing (unsigned) names as they are, adding a 
sentence about using the
direction-specific names when direction is known?

Also, do we need both platform_heave_rate_up and 
platform_heave_rate_down, or is heave_rate
sufficient? This also applies to most or all of the rates ... sorry I 
haven't looked at all of them
to check how many pairs could be combined.

Last, thanks for clarifying the issue of order of terms in the 
definitions. When using the
html search function and looking for the difference between say 
platform_course and
platform_orientation, it is *much* easier (for a human, at least) if the 
definition of the
quantity comes first. Not everyone uses the standard name table this 
way, I know, but for
those who do this is really helpful.

Thanks for bringing this together!

- Nan



On 9/20/18 4:35 AM, Lowry, Roy K. wrote:
>
> Dear Alison,
>
>
> Your proposal is a much better solution than deprecating the original 
> Standard Name and so has full support of Gwen and I.
>
>
> Cheers, Roy.
>
>
> I have now retired but will continue to be active through an Emeritus 
> Fellowship using this e-mail address.
>
>
>
> 
> *From:* Alison Pamment - UKRI STFC <mailto:alison.pamm...@stfc.ac.uk>
> *Sent:* 19 September 2018 19:04
> *To:* Lowry, Roy K.; Jim Biard; mailto:cf-metadata@cgd.ucar.edu
> *Subject:* RE: [CF-metadata] Platform Heave
> Dear Jim et al.,
>
> Thank you again for all the work on these names and their definitions. 
> I have now caught up with all the comments in the discussion and I 
> think the names as written most recently by Jim in 
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html are 
> looking very good. All the recent comments seem to indicate unanimous 
> support (with a couple of minor corrections to the yaw definition

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Nan,


My understanding is that Alison was proposing leaving the existing 
pitch/roll/yaw/heave in place, but with a note in the definitions that 
direction isn't specified. New direction-specific names would then be added and 
linked to the existing names as aliases (in the CF XML) or NarrowMatch mappings 
(in NVS). This requires a change in the definition of 'alias' in the CF 
Convention, which seems to have strong support.


This is exactly what you want!


Regarding the heave rates, I don't agree. In my view, if the quantities are 
explicitly signed then names for explicitly signed quantity rate vectors should 
also be available.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Nan Galbraith 

Sent: 20 September 2018 15:11
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Thank you, Alison. This all looks good.

With regards to your last point, about the existing names
heave/yaw/pitch/roll  (and their rates),
I'm not sure why we need to deprecate anything or even create these
aliases. There may be cases
where the magnitude of e.g. heave is important, but doesn't really even
need to be signed - or
can't be signed because the heave distance or rate is provided by an
instrument and the 'sense' of
the heave is not included.

Can't we just leave the existing (unsigned) names as they are, adding a
sentence about using the
direction-specific names when direction is known?

Also, do we need both platform_heave_rate_up and
platform_heave_rate_down, or is heave_rate
sufficient? This also applies to most or all of the rates ... sorry I
haven't looked at all of them
to check how many pairs could be combined.

Last, thanks for clarifying the issue of order of terms in the
definitions. When using the
html search function and looking for the difference between say
platform_course and
platform_orientation, it is *much* easier (for a human, at least) if the
definition of the
quantity comes first. Not everyone uses the standard name table this
way, I know, but for
those who do this is really helpful.

Thanks for bringing this together!

- Nan



On 9/20/18 4:35 AM, Lowry, Roy K. wrote:
>
> Dear Alison,
>
>
> Your proposal is a much better solution than deprecating the original
> Standard Name and so has full support of Gwen and I.
>
>
> Cheers, Roy.
>
>
> I have now retired but will continue to be active through an Emeritus
> Fellowship using this e-mail address.
>
>
>
> 
> *From:* Alison Pamment - UKRI STFC 
> *Sent:* 19 September 2018 19:04
> *To:* Lowry, Roy K.; Jim Biard; cf-metadata@cgd.ucar.edu
> *Subject:* RE: [CF-metadata] Platform Heave
> Dear Jim et al.,
>
> Thank you again for all the work on these names and their definitions.
> I have now caught up with all the comments in the discussion and I
> think the names as written most recently by Jim in
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html are
> looking very good. All the recent comments seem to indicate unanimous
> support (with a couple of minor corrections to the yaw definition text).
>
> The definitions are great and using pairs of names is a neat solution
> to all the questions regarding reference frames and sign conventions.
> There has been some discussion of the order of the sentences in the
> definition, i.e. whether the quantity can be described first, followed
> by the general description of 'platform'. Jim pointed out that in many
> standard name definitions the sentences are ordered in the same way as
> the components of the name itself. Often I have constructed them that
> way because it gives some logical structure to the text, rather than
> just adding the sentences in some random order. However, there is no
> hard and fast rule and sometimes we do adjust the order of the
> sentences so that the text flows more naturally. For example, we
> recently added a lot of new names for sea surface wave spectra, such
> as sea_surface_primary_swell_wave_directional_spread, in which the
> first sentence of each definition summarizes the meaning of the
> quantity as a whole before going into further detail about the
> individual terms. I don't see any problem about reordering the
> platform definitions in the way Nan has suggested, e.g.
> platform_yaw_fore_starboard: Yaw is a rotation about the local
> vertical axis. Yaw is relative to the "at rest" rotation of the
> platform with respect to the axis of rotation. The "at rest" rotation
> of the platform may change over time. "Fore starboard" indicates that
> positive values of yaw represent the front of the platform moving to
> the right as viewed by 

Re: [CF-metadata] Platform Heave

[Nan Galbraith]

Thank you, Alison. This all looks good.

With regards to your last point, about the existing names 
heave/yaw/pitch/roll  (and their rates),
I'm not sure why we need to deprecate anything or even create these 
aliases. There may be cases
where the magnitude of e.g. heave is important, but doesn't really even 
need to be signed - or
can't be signed because the heave distance or rate is provided by an 
instrument and the 'sense' of

the heave is not included.

Can't we just leave the existing (unsigned) names as they are, adding a 
sentence about using the

direction-specific names when direction is known?

Also, do we need both platform_heave_rate_up and 
platform_heave_rate_down, or is heave_rate
sufficient? This also applies to most or all of the rates ... sorry I 
haven't looked at all of them

to check how many pairs could be combined.

Last, thanks for clarifying the issue of order of terms in the 
definitions. When using the
html search function and looking for the difference between say 
platform_course and
platform_orientation, it is *much* easier (for a human, at least) if the 
definition of the
quantity comes first. Not everyone uses the standard name table this 
way, I know, but for

those who do this is really helpful.

Thanks for bringing this together!

- Nan



On 9/20/18 4:35 AM, Lowry, Roy K. wrote:


Dear Alison,


Your proposal is a much better solution than deprecating the original 
Standard Name and so has full support of Gwen and I.



Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.





*From:* Alison Pamment - UKRI STFC 
*Sent:* 19 September 2018 19:04
*To:* Lowry, Roy K.; Jim Biard; cf-metadata@cgd.ucar.edu
*Subject:* RE: [CF-metadata] Platform Heave
Dear Jim et al.,

Thank you again for all the work on these names and their definitions. 
I have now caught up with all the comments in the discussion and I 
think the names as written most recently by Jim in 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html are 
looking very good. All the recent comments seem to indicate unanimous 
support (with a couple of minor corrections to the yaw definition text).


The definitions are great and using pairs of names is a neat solution 
to all the questions regarding reference frames and sign conventions. 
There has been some discussion of the order of the sentences in the 
definition, i.e. whether the quantity can be described first, followed 
by the general description of 'platform'. Jim pointed out that in many 
standard name definitions the sentences are ordered in the same way as 
the components of the name itself. Often I have constructed them that 
way because it gives some logical structure to the text, rather than 
just adding the sentences in some random order. However, there is no 
hard and fast rule and sometimes we do adjust the order of the 
sentences so that the text flows more naturally. For example, we 
recently added a lot of new names for sea surface wave spectra, such 
as sea_surface_primary_swell_wave_directional_spread, in which the 
first sentence of each definition summarizes the meaning of the 
quantity as a whole before going into further detail about the 
individual terms. I don't see any problem about reordering the 
platform definitions in the way Nan has suggested, e.g.
platform_yaw_fore_starboard: Yaw is a rotation about the local 
vertical axis. Yaw is relative to the "at rest" rotation of the 
platform with respect to the axis of rotation. The "at rest" rotation 
of the platform may change over time. "Fore starboard" indicates that 
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. 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.
Unless anyone objects, I will write the definitions this way round 
when I add them to the standard name table.


There is another (technical) point that I need to raise before 
formally accepting these names. Some of the names are new, e.g. the 
surge and sway quantities, so there is no problem about adding pairs 
of these names straight into the table as new entries. During the 
discussion it was mentioned that 'heave' would also be new. In fact, I 
added names platform_heave and platform_heave_rate to the standard 
name table in V58 on 7th August with definitions that I thought we had 
agreed at that point. (This was just before I went on leave and it 
didn't get announced on the list, so I'll post details of that update 
separately.) For the heave names and the existing yaw/pitch/roll names 
we now want to introduce pairs of names to allow for the possible use 
of opposing sign conventions and this raises a qu

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Alison,


Your proposal is a much better solution than deprecating the original Standard 
Name and so has full support of Gwen and I.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: Alison Pamment - UKRI STFC 
Sent: 19 September 2018 19:04
To: Lowry, Roy K.; Jim Biard; cf-metadata@cgd.ucar.edu
Subject: RE: [CF-metadata] Platform Heave

Dear Jim et al.,

Thank you again for all the work on these names and their definitions. I have 
now caught up with all the comments in the discussion and I think the names as 
written most recently by Jim in 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html are looking 
very good. All the recent comments seem to indicate unanimous support (with a 
couple of minor corrections to the yaw definition text).

The definitions are great and using pairs of names is a neat solution to all 
the questions regarding reference frames and sign conventions. There has been 
some discussion of the order of the sentences in the definition, i.e. whether 
the quantity can be described first, followed by the general description of 
'platform'. Jim pointed out that in many standard name definitions the 
sentences are ordered in the same way as the components of the name itself. 
Often I have constructed them that way because it gives some logical structure 
to the text, rather than just adding the sentences in some random order. 
However, there is no hard and fast rule and sometimes we do adjust the order of 
the sentences so that the text flows more naturally. For example, we recently 
added a lot of new names for sea surface wave spectra, such as 
sea_surface_primary_swell_wave_directional_spread, in which the first sentence 
of each definition summarizes the meaning of the quantity as a whole before 
going into further detail about the individual terms. I don't see any problem 
about reordering the platform definitions in the way Nan has suggested, e.g.
platform_yaw_fore_starboard: Yaw is a rotation about the local vertical axis. 
Yaw is relative to the "at rest" rotation of the platform with respect to the 
axis of rotation. The "at rest" rotation of the platform may change over time. 
"Fore starboard" indicates that 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. 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.
Unless anyone objects, I will write the definitions this way round when I add 
them to the standard name table.

There is another (technical) point that I need to raise before formally 
accepting these names. Some of the names are new, e.g. the surge and sway 
quantities, so there is no problem about adding pairs of these names straight 
into the table as new entries. During the discussion it was mentioned that 
'heave' would also be new. In fact, I added names platform_heave and 
platform_heave_rate to the standard name table in V58 on 7th August with 
definitions that I thought we had agreed at that point. (This was just before I 
went on leave and it didn't get announced on the list, so I'll post details of 
that update separately.) For the heave names and the existing yaw/pitch/roll 
names we now want to introduce pairs of names to allow for the possible use of 
opposing sign conventions and this raises a question about how to construct the 
aliases.

We had a similar case some years ago in which it was realised that the existing 
name surface_carbon_dioxide_mole_flux gave no indication of its sign 
convention. There was some discussion over whether existing data sets might 
treat the upward flux as positive and downwards as negative, or vice versa. 
There was no real way of answering this question, so to avoid invalidating any 
existing data, I added two new names 
surface_downward_mole_flux_of_carbon_dioxide and 
surface_downward_mole_flux_of_carbon_dioxide and listed 
surface_carbon_dioxide_mole_flux as the alias of both. The definitions of the 
new terms both contain the sentences 'The standard name 
surface_carbon_dioxide_mole_flux is deprecated because it does not specify in 
which direction the flux is positive. Any data having the standard name 
surface_carbon_dioxide_mole_flux should be examined carefully to determine 
which sign convention was used.' This seemed like a pragmatic approach to 
solving the problem of adding a pair of new names while not making any 
assumptions about the sign conventions already in use. I would argue that a 
similar approach would also make sense for the heave/yaw/pitch/roll names, 
e.g., platform_yaw_fore_starboard and platform_yaw_fore_port would both have an 
alias of platform_yaw_angle and an explanatory senten

Re: [CF-metadata] Platform Heave

[Taylor, Karl E.]

Dear all,

I also vote in favor of the proposed change to the convention to allow 
an alias to apply to more than one existing standard name (at least in 
the case where the the new names are in some way more specific than the 
original).

best regards,
Karl

On 9/19/18 11:57 AM, Jonathan Gregory wrote:
> Dear all
>
> I agree in applauding the hard work and excellent results of Jim and others.
> Thanks! I also agree with Alison's proposal to change the convention to allow
> an alias to apply to more than one existing standard name.
>
> Best wishes
>
> Jonathan
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

Dear all

I agree in applauding the hard work and excellent results of Jim and others.
Thanks! I also agree with Alison's proposal to change the convention to allow
an alias to apply to more than one existing standard name.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Platform Heave

[Jim Biard]

why this should be allowed, so as to cope with cases like the ones currently 
under discussion, and therefore we should change the schema. Do others agree 
with this approach, or does anyone have a better idea?

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

From: CF-metadata  On Behalf Of Lowry, Roy K.
Sent: 13 September 2018 20:11
To: Jim Biard ; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Jim,

Interesting article that answers some of my questions about what we've been 
defining here in terms of platform-local axes and 'real world' co-ordinate 
reference systems.

Cheers, Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata on behalf of Jim Biard
Sent: 13 September 2018 19:39
To: mailto:cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave
I only just located this wikipedia article. It describes the different axes 
conventions that are in common use and the differences between them.

https://en.wikipedia.org/wiki/Axes_conventions

https://en.wikipedia.org/wiki/Axes_conventions
en.wikipedia.org
In ballistics and flight dynamics, axes conventions are standardized ways of 
establishing the location and orientation of coordinate axes for use as a frame 
of reference.Mobile objects are normally tracked from an external frame 
considered fixed. Other frames can be defined on those mobile objects to deal 
with relative positions for other objects.


On 9/13/18 12:15 PM, Lowry, Roy K. wrote:
Hi John,

Your Q2 has been discussed at length. The local vertical axis is indeed local 
to the platform, as are the axes running front to back and left to right.

Your eagle eyes have indeed spotted something I missed in the yaw definition ' 
'Yaw is a rotation about the axis of rotation' should I think read 'Yaw is a 
rotation about the local vertical axis'.

I HATE 'smart' quotes and Microsoft's mission to make every quote smart through 
auto-correction!

Cheers, Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata on behalf of John Graybeal
Sent: 13 September 2018 16:38
To: CF Metadata List
Subject: Re: [CF-metadata] Platform Heave
It's a brilliant effort, if I may say. I've been following and appreciating it 
(wanted it for a long time!) and I think it is very close.

If I may say so, it deserves a bit of time for everyone to catch up, before 
enshrinement. I have two questions I'd like to ask, and one editing nit.

Question 1: The last version I found is enclosed, but I can't tell if it is the 
last version. (Please note the long tails of the emails make it extremely 
time-consuming to find the content when trying to catch up. Hence I have sent 
this without the long tail.)

This version does not seem to address Nan's suggestion to put the platform 
description after the roll/pitch/etc description, which I also like. Still, I 
can see advantages both ways.

Question 2: The one concern I have, sorry if you dealt with it thoroughly, is about the expression in each 
definition that reads something like "Roll is a rotation about an axis that is perpendicular to the 
local vertical axis and is coplanar with the nominal forward motion direction of the platform." I may be 
mis-remembering, but from my airplane navigation days my understanding is that the role is around the axis 
that points out the front of the airplane. If the airplane is pitched up, the roll is around the pitched-up 
vector; if the airplane is yawing to the right, the roll is around the actual direction, not the travel 
direction. This is important at small scales when dealing with the spherical coordinate math necessary to 
point telescopes; it's important at large scales if you imagine a fighter jet flying vertically up or down, 
and executing a roll (the roll axis is definitely not perpendicular to the local vertical axis in this case, 
unless you mean "platform local", which I believe is how it is defined and I'm pretty sure is how 
it is measured by the accelerometers). I believe that satellites work the same way also-once they define 
'front', the measurements and calculations for roll are all around where front is, and similar patterns apply 
for pitch (measured relative to a line perpendicular to front-back axis directly through the wings) and yaw 
(measured around an axis vertical to the airplane local-note that the definitions for yaw include "Yaw 
is a rotation about the axis of rotation", and appear to have lost the description of what the axis of 
rotation *is*.

I cite Wikipedia as my authority, not just because it matches my 

Re: [CF-metadata] Platform Heave

[Alison Pamment - UKRI STFC]

and therefore we should change the schema. Do others agree 
with this approach, or does anyone have a better idea?

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory 
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

From: CF-metadata  On Behalf Of Lowry, Roy K.
Sent: 13 September 2018 20:11
To: Jim Biard ; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Jim,

Interesting article that answers some of my questions about what we've been 
defining here in terms of platform-local axes and 'real world' co-ordinate 
reference systems.

Cheers, Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata on behalf of Jim Biard 
Sent: 13 September 2018 19:39
To: mailto:cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave 
I only just located this wikipedia article. It describes the different axes 
conventions that are in common use and the differences between them.

https://en.wikipedia.org/wiki/Axes_conventions

https://en.wikipedia.org/wiki/Axes_conventions
en.wikipedia.org
In ballistics and flight dynamics, axes conventions are standardized ways of 
establishing the location and orientation of coordinate axes for use as a frame 
of reference.Mobile objects are normally tracked from an external frame 
considered fixed. Other frames can be defined on those mobile objects to deal 
with relative positions for other objects.


On 9/13/18 12:15 PM, Lowry, Roy K. wrote:
Hi John,

Your Q2 has been discussed at length. The local vertical axis is indeed local 
to the platform, as are the axes running front to back and left to right.

Your eagle eyes have indeed spotted something I missed in the yaw definition ' 
'Yaw is a rotation about the axis of rotation' should I think read 'Yaw is a 
rotation about the local vertical axis'.

I HATE 'smart' quotes and Microsoft's mission to make every quote smart through 
auto-correction!

Cheers, Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata on behalf of John Graybeal 
Sent: 13 September 2018 16:38
To: CF Metadata List
Subject: Re: [CF-metadata] Platform Heave 
It's a brilliant effort, if I may say. I've been following and appreciating it 
(wanted it for a long time!) and I think it is very close.

If I may say so, it deserves a bit of time for everyone to catch up, before 
enshrinement. I have two questions I'd like to ask, and one editing nit.

Question 1: The last version I found is enclosed, but I can't tell if it is the 
last version. (Please note the long tails of the emails make it extremely 
time-consuming to find the content when trying to catch up. Hence I have sent 
this without the long tail.)

This version does not seem to address Nan's suggestion to put the platform 
description after the roll/pitch/etc description, which I also like. Still, I 
can see advantages both ways.

Question 2: The one concern I have, sorry if you dealt with it thoroughly, is 
about the expression in each definition that reads something like "Roll is a 
rotation about an axis that is perpendicular to the local vertical axis and is 
coplanar with the nominal forward motion direction of the platform." I may be 
mis-remembering, but from my airplane navigation days my understanding is that 
the role is around the axis that points out the front of the airplane. If the 
airplane is pitched up, the roll is around the pitched-up vector; if the 
airplane is yawing to the right, the roll is around the actual direction, not 
the travel direction. This is important at small scales when dealing with the 
spherical coordinate math necessary to point telescopes; it's important at 
large scales if you imagine a fighter jet flying vertically up or down, and 
executing a roll (the roll axis is definitely not perpendicular to the local 
vertical axis in this case, unless you mean "platform local", which I be
 lieve is how it is defined and I'm pretty sure is how it is measured by the 
accelerometers). I believe that satellites work the same way also-once they 
define 'front', the measurements and calculations for roll are all around where 
front is, and similar patterns apply for pitch (measured relative to a line 
perpendicular to front-back axis directly through the wings) and yaw (measured 
around an axis vertical to the airplane local-note that the definitions for yaw 
include "Yaw is a rotation about the axis of rotation", and appear to have lost 
the description of what the axis of rotation *is*.

I cite Wikipedia as my authority, not just because it matches my memory but 
also because it is footnoted, and refers to both airplanes and sate

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Jim,


Interesting article that answers some of my questions about what we've been 
defining here in terms of platform-local axes and 'real world' co-ordinate 
reference systems.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 13 September 2018 19:39
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


I only just located this wikipedia article. It describes the different axes 
conventions that are in common use and the differences between them.


https://en.wikipedia.org/wiki/Axes_conventions

[https://upload.wikimedia.org/wikipedia/commons/thumb/6/67/Plane.svg/1200px-Plane.svg.png]<https://en.wikipedia.org/wiki/Axes_conventions>

Axes conventions - Wikipedia<https://en.wikipedia.org/wiki/Axes_conventions>
en.wikipedia.org
In ballistics and flight dynamics, axes conventions are standardized ways of 
establishing the location and orientation of coordinate axes for use as a frame 
of reference.Mobile objects are normally tracked from an external frame 
considered fixed. Other frames can be defined on those mobile objects to deal 
with relative positions for other objects.




On 9/13/18 12:15 PM, Lowry, Roy K. wrote:

Hi John,


Your Q2 has been discussed at length. The local vertical axis is indeed local 
to the platform, as are the axes running front to back and left to right.


Your eagle eyes have indeed spotted something I missed in the yaw definition ' 
'Yaw is a rotation about the axis of rotation' should I think read 'Yaw is a 
rotation about the local vertical axis'.


I HATE 'smart' quotes and Microsoft's mission to make every quote smart through 
auto-correction!


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of John Graybeal 
<mailto:jbgrayb...@mindspring.com>
Sent: 13 September 2018 16:38
To: CF Metadata List
Subject: Re: [CF-metadata] Platform Heave

It’s a brilliant effort, if I may say. I’ve been following and appreciating it 
(wanted it for a long time!) and I think it is very close.

If I may say so, it deserves a bit of time for everyone to catch up, before 
enshrinement.  I have two questions I’d like to ask, and one editing nit.

Question 1: The last version I found is enclosed, but I can’t tell if it is the 
last version. (Please note the long tails of the emails make it extremely 
time-consuming to find the content when trying to catch up. Hence I have sent 
this without the long tail.)

This version does not seem to address Nan’s suggestion to put the platform 
description after the roll/pitch/etc description, which I also like. Still, I 
can see advantages both ways.

Question 2: The one concern I have, sorry if you dealt with it thoroughly, is 
about the expression in each definition that reads something like "Roll is a 
rotation about an axis that is perpendicular to the local vertical axis and is 
coplanar with the nominal forward motion direction of the platform.”  I may be 
mis-remembering, but from my airplane navigation days my understanding is that 
the role is around the axis that points out the front of the airplane. If the 
airplane is pitched up, the roll is around the pitched-up vector; if the 
airplane is yawing to the right, the roll is around the actual direction, not 
the travel direction.  This is important at small scales when dealing with the 
spherical coordinate math necessary to point telescopes; it’s important at 
large scales if you imagine a fighter jet flying vertically up or down, and 
executing a roll (the roll axis is definitely not perpendicular to the local 
vertical axis in this case, unless you mean “platform local”, which I believe 
is how it is defined and I’m pretty sure is how it is measured by the 
accelerometers).  I believe that satellites work the same way also—once they 
define ‘front’, the measurements and calculations for roll are all around where 
front is, and similar patterns apply for pitch (measured relative to a line 
perpendicular to front-back axis directly through the wings) and yaw (measured 
around an axis vertical to the airplane local—note that the definitions for yaw 
include "Yaw is a rotation about the axis of rotation”, and appear to have lost 
the description of what the axis of rotation *is*.

I cite Wikipedia as my authority, not just because it matches my memory but 
also because it is footnoted, and refers to both airplanes and satellites using 
this reference frame.

Finally, my editing nit is that these definitions have replaced smart 
apostrophes with question marks, I assume dumb apostrophes are the order of the 
day.

John



platform_roll_starboard_down: Platform is a structure or vehicle that serves as 
a ba

Re: [CF-metadata] Platform Heave

[Jim Biard]

I only just located this wikipedia article. It describes the different 
axes conventions that are in common use and the differences between them.



https://en.wikipedia.org/wiki/Axes_conventions


On 9/13/18 12:15 PM, Lowry, Roy K. wrote:


Hi John,


Your Q2 has been discussed at length. The local vertical axis is 
indeed local to the platform, as are the axes running front to back 
and left to right.



Your eagle eyes have indeed spotted something I missed in the yaw 
definition ' 'Yaw is a rotation about the axis of rotation' should I 
think read 'Yaw is a rotation about the local vertical axis'.



I HATE 'smart' quotes and Microsoft's mission to make every quote 
smart through auto-correction!



Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.





*From:* CF-metadata  on behalf of 
John Graybeal 

*Sent:* 13 September 2018 16:38
*To:* CF Metadata List
*Subject:* Re: [CF-metadata] Platform Heave
It’s a brilliant effort, if I may say. I’ve been following and 
appreciating it (wanted it for a long time!) and I think it is very close.


If I may say so, it deserves a bit of time for everyone to catch up, 
before enshrinement.  I have two questions I’d like to ask, and one 
editing nit.


Question 1: The last version I found is enclosed, but I can’t tell if 
it is the last version. (Please note the long tails of the emails make 
it extremely time-consuming to find the content when trying to catch 
up. Hence I have sent this without the long tail.)


This version does not seem to address Nan’s suggestion to put the 
platform description after the roll/pitch/etc description, which I 
also like. Still, I can see advantages both ways.


Question 2: The one concern I have, sorry if you dealt with it 
thoroughly, is about the expression in each definition that reads 
something like "Roll is a rotation about an axis that is perpendicular 
to the local vertical axis and is coplanar with the nominal forward 
motion direction of the platform.”  I may be mis-remembering, but from 
my airplane navigation days my understanding is that the role is 
around the axis that points out the front of the airplane. If the 
airplane is pitched up, the roll is around the pitched-up vector; if 
the airplane is yawing to the right, the roll is around the actual 
direction, not the travel direction.  This is important at small 
scales when dealing with the spherical coordinate math necessary to 
point telescopes; it’s important at large scales if you imagine a 
fighter jet flying vertically up or down, and executing a roll (the 
roll axis is definitely not perpendicular to the local vertical axis 
in this case, unless you mean “platform local”, which I believe is how 
it is defined and I’m pretty sure is how it is measured by the 
accelerometers).  I believe that satellites work the same way 
also—once they define ‘front’, the measurements and calculations for 
roll are all around where front is, and similar patterns apply for 
pitch (measured relative to a line perpendicular to front-back axis 
directly through the wings) and yaw (measured around an axis vertical 
to the airplane local—note that the definitions for yaw include "Yaw 
is a rotation about the axis of rotation”, and appear to have lost the 
description of what the axis of rotation *is*.


I cite Wikipedia as my authority, not just because it matches my 
memory but also because it is footnoted, and refers to both airplanes 
and satellites using this reference frame.


Finally, my editing nit is that these definitions have replaced smart 
apostrophes with question marks, I assume dumb apostrophes are the 
order of the day.


John



platform_roll_starboard_down: 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 that is perpendicular to the 
local vertical 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 axis of rotation. The ?at rest? 
rotation of the platform may change over time. "Starboard down" 
indicates that positive values of roll represent the right side of the 
platform falling as viewed by an observer on top of the platform 
facing forward.


platform_roll_starboard_up: 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 that is perpendicular to the 
local vertical 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 axis of rotation. The

Re: [CF-metadata] Platform Heave

[Jim Biard]

And regarding the question marks - they started as ASCII full quotes. I 
have no idea how they got translated into question marks. I blame 
unicode for everything. ;-)



On 9/13/18 12:15 PM, Lowry, Roy K. wrote:


Hi John,


Your Q2 has been discussed at length. The local vertical axis is 
indeed local to the platform, as are the axes running front to back 
and left to right.



Your eagle eyes have indeed spotted something I missed in the yaw 
definition ' 'Yaw is a rotation about the axis of rotation' should I 
think read 'Yaw is a rotation about the local vertical axis'.



I HATE 'smart' quotes and Microsoft's mission to make every quote 
smart through auto-correction!



Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.





*From:* CF-metadata  on behalf of 
John Graybeal 

*Sent:* 13 September 2018 16:38
*To:* CF Metadata List
*Subject:* Re: [CF-metadata] Platform Heave
It’s a brilliant effort, if I may say. I’ve been following and 
appreciating it (wanted it for a long time!) and I think it is very close.


If I may say so, it deserves a bit of time for everyone to catch up, 
before enshrinement.  I have two questions I’d like to ask, and one 
editing nit.


Question 1: The last version I found is enclosed, but I can’t tell if 
it is the last version. (Please note the long tails of the emails make 
it extremely time-consuming to find the content when trying to catch 
up. Hence I have sent this without the long tail.)


This version does not seem to address Nan’s suggestion to put the 
platform description after the roll/pitch/etc description, which I 
also like. Still, I can see advantages both ways.


Question 2: The one concern I have, sorry if you dealt with it 
thoroughly, is about the expression in each definition that reads 
something like "Roll is a rotation about an axis that is perpendicular 
to the local vertical axis and is coplanar with the nominal forward 
motion direction of the platform.”  I may be mis-remembering, but from 
my airplane navigation days my understanding is that the role is 
around the axis that points out the front of the airplane. If the 
airplane is pitched up, the roll is around the pitched-up vector; if 
the airplane is yawing to the right, the roll is around the actual 
direction, not the travel direction.  This is important at small 
scales when dealing with the spherical coordinate math necessary to 
point telescopes; it’s important at large scales if you imagine a 
fighter jet flying vertically up or down, and executing a roll (the 
roll axis is definitely not perpendicular to the local vertical axis 
in this case, unless you mean “platform local”, which I believe is how 
it is defined and I’m pretty sure is how it is measured by the 
accelerometers).  I believe that satellites work the same way 
also—once they define ‘front’, the measurements and calculations for 
roll are all around where front is, and similar patterns apply for 
pitch (measured relative to a line perpendicular to front-back axis 
directly through the wings) and yaw (measured around an axis vertical 
to the airplane local—note that the definitions for yaw include "Yaw 
is a rotation about the axis of rotation”, and appear to have lost the 
description of what the axis of rotation *is*.


I cite Wikipedia as my authority, not just because it matches my 
memory but also because it is footnoted, and refers to both airplanes 
and satellites using this reference frame.


Finally, my editing nit is that these definitions have replaced smart 
apostrophes with question marks, I assume dumb apostrophes are the 
order of the day.


John



platform_roll_starboard_down: 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 that is perpendicular to the 
local vertical 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 axis of rotation. The ?at rest? 
rotation of the platform may change over time. "Starboard down" 
indicates that positive values of roll represent the right side of the 
platform falling as viewed by an observer on top of the platform 
facing forward.


platform_roll_starboard_up: 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 that is perpendicular to the 
local vertical 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 axis of rotation. The ?at rest? 
rotation of the

Re: [CF-metadata] Platform Heave

[Jim Biard]

Hi.


Good catch, Jonathan! I botched the yaw definitions. It should be 'about 
the local vertical axis'.



I defined each rotation in isolation, as I found it difficult to deal 
with all of the different issues AND find language that would be clear 
as to which axis is being referred to. The direction in relation to an 
extrinsic coordinate system of a given body or motion frame axis after a 
rotation about some other axis is dependent on the order of application. 
If you follow a roll-pitch-yaw sequence, then yaw is not around the 
local vertical axis, nor is pitch around an axis perpendicular to the 
local vertical axis. Likewise, if you follow a yaw-pitch-roll sequence, 
the pitch axis is not perpendicular to the nominal forward motion axis, 
nor is the roll axis perpendicular to the local vertical axis.



If people think it's important to note that these definitions are 
describing the rotations in isolation, I'm happy for someone to take a 
stab at that verbiage.



Grace and peace,


Jim


On 9/13/18 12:15 PM, Lowry, Roy K. wrote:


Hi John,


Your Q2 has been discussed at length. The local vertical axis is 
indeed local to the platform, as are the axes running front to back 
and left to right.



Your eagle eyes have indeed spotted something I missed in the yaw 
definition ' 'Yaw is a rotation about the axis of rotation' should I 
think read 'Yaw is a rotation about the local vertical axis'.



I HATE 'smart' quotes and Microsoft's mission to make every quote 
smart through auto-correction!



Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.





*From:* CF-metadata  on behalf of 
John Graybeal 

*Sent:* 13 September 2018 16:38
*To:* CF Metadata List
*Subject:* Re: [CF-metadata] Platform Heave
It’s a brilliant effort, if I may say. I’ve been following and 
appreciating it (wanted it for a long time!) and I think it is very close.


If I may say so, it deserves a bit of time for everyone to catch up, 
before enshrinement.  I have two questions I’d like to ask, and one 
editing nit.


Question 1: The last version I found is enclosed, but I can’t tell if 
it is the last version. (Please note the long tails of the emails make 
it extremely time-consuming to find the content when trying to catch 
up. Hence I have sent this without the long tail.)


This version does not seem to address Nan’s suggestion to put the 
platform description after the roll/pitch/etc description, which I 
also like. Still, I can see advantages both ways.


Question 2: The one concern I have, sorry if you dealt with it 
thoroughly, is about the expression in each definition that reads 
something like "Roll is a rotation about an axis that is perpendicular 
to the local vertical axis and is coplanar with the nominal forward 
motion direction of the platform.”  I may be mis-remembering, but from 
my airplane navigation days my understanding is that the role is 
around the axis that points out the front of the airplane. If the 
airplane is pitched up, the roll is around the pitched-up vector; if 
the airplane is yawing to the right, the roll is around the actual 
direction, not the travel direction.  This is important at small 
scales when dealing with the spherical coordinate math necessary to 
point telescopes; it’s important at large scales if you imagine a 
fighter jet flying vertically up or down, and executing a roll (the 
roll axis is definitely not perpendicular to the local vertical axis 
in this case, unless you mean “platform local”, which I believe is how 
it is defined and I’m pretty sure is how it is measured by the 
accelerometers).  I believe that satellites work the same way 
also—once they define ‘front’, the measurements and calculations for 
roll are all around where front is, and similar patterns apply for 
pitch (measured relative to a line perpendicular to front-back axis 
directly through the wings) and yaw (measured around an axis vertical 
to the airplane local—note that the definitions for yaw include "Yaw 
is a rotation about the axis of rotation”, and appear to have lost the 
description of what the axis of rotation *is*.


I cite Wikipedia as my authority, not just because it matches my 
memory but also because it is footnoted, and refers to both airplanes 
and satellites using this reference frame.


Finally, my editing nit is that these definitions have replaced smart 
apostrophes with question marks, I assume dumb apostrophes are the 
order of the day.


John



platform_roll_starboard_down: 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 that is perpendicular to the 
local vertical axis and is coplanar with the nominal forward motion 
direction of the platform. Roll i

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi John,


Your Q2 has been discussed at length. The local vertical axis is indeed local 
to the platform, as are the axes running front to back and left to right.


Your eagle eyes have indeed spotted something I missed in the yaw definition ' 
'Yaw is a rotation about the axis of rotation' should I think read 'Yaw is a 
rotation about the local vertical axis'.


I HATE 'smart' quotes and Microsoft's mission to make every quote smart through 
auto-correction!


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of John Graybeal 

Sent: 13 September 2018 16:38
To: CF Metadata List
Subject: Re: [CF-metadata] Platform Heave

It’s a brilliant effort, if I may say. I’ve been following and appreciating it 
(wanted it for a long time!) and I think it is very close.

If I may say so, it deserves a bit of time for everyone to catch up, before 
enshrinement.  I have two questions I’d like to ask, and one editing nit.

Question 1: The last version I found is enclosed, but I can’t tell if it is the 
last version. (Please note the long tails of the emails make it extremely 
time-consuming to find the content when trying to catch up. Hence I have sent 
this without the long tail.)

This version does not seem to address Nan’s suggestion to put the platform 
description after the roll/pitch/etc description, which I also like. Still, I 
can see advantages both ways.

Question 2: The one concern I have, sorry if you dealt with it thoroughly, is 
about the expression in each definition that reads something like "Roll is a 
rotation about an axis that is perpendicular to the local vertical axis and is 
coplanar with the nominal forward motion direction of the platform.”  I may be 
mis-remembering, but from my airplane navigation days my understanding is that 
the role is around the axis that points out the front of the airplane. If the 
airplane is pitched up, the roll is around the pitched-up vector; if the 
airplane is yawing to the right, the roll is around the actual direction, not 
the travel direction.  This is important at small scales when dealing with the 
spherical coordinate math necessary to point telescopes; it’s important at 
large scales if you imagine a fighter jet flying vertically up or down, and 
executing a roll (the roll axis is definitely not perpendicular to the local 
vertical axis in this case, unless you mean “platform local”, which I believe 
is how it is defined and I’m pretty sure is how it is measured by the 
accelerometers).  I believe that satellites work the same way also—once they 
define ‘front’, the measurements and calculations for roll are all around where 
front is, and similar patterns apply for pitch (measured relative to a line 
perpendicular to front-back axis directly through the wings) and yaw (measured 
around an axis vertical to the airplane local—note that the definitions for yaw 
include "Yaw is a rotation about the axis of rotation”, and appear to have lost 
the description of what the axis of rotation *is*.

I cite Wikipedia as my authority, not just because it matches my memory but 
also because it is footnoted, and refers to both airplanes and satellites using 
this reference frame.

Finally, my editing nit is that these definitions have replaced smart 
apostrophes with question marks, I assume dumb apostrophes are the order of the 
day.

John



platform_roll_starboard_down: 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 that is perpendicular to the local vertical 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 axis of 
rotation. The ?at rest? rotation of the platform may change over time. 
"Starboard down" indicates that positive values of roll represent the right 
side of the platform falling as viewed by an observer on top of the platform 
facing forward.

platform_roll_starboard_up: 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 that is perpendicular to the local vertical 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 axis of 
rotation. The ?at rest? rotation of the platform may change over time. 
"Starboard up" indicates that positive values of roll represent the right side 
of the platform rising as viewed by an observer on top of the platform facing 
forward.

platform_roll_rate_starboard_down: Platform is a structure or 

Re: [CF-metadata] Platform Heave

[John Graybeal]

It’s a brilliant effort, if I may say. I’ve been following and appreciating it 
(wanted it for a long time!) and I think it is very close.

If I may say so, it deserves a bit of time for everyone to catch up, before 
enshrinement.  I have two questions I’d like to ask, and one editing nit.

Question 1: The last version I found is enclosed, but I can’t tell if it is the 
last version. (Please note the long tails of the emails make it extremely 
time-consuming to find the content when trying to catch up. Hence I have sent 
this without the long tail.)

This version does not seem to address Nan’s suggestion to put the platform 
description after the roll/pitch/etc description, which I also like. Still, I 
can see advantages both ways.

Question 2: The one concern I have, sorry if you dealt with it thoroughly, is 
about the expression in each definition that reads something like "Roll is a 
rotation about an axis that is perpendicular to the local vertical axis and is 
coplanar with the nominal forward motion direction of the platform.”  I may be 
mis-remembering, but from my airplane navigation days my understanding is that 
the role is around the axis that points out the front of the airplane. If the 
airplane is pitched up, the roll is around the pitched-up vector; if the 
airplane is yawing to the right, the roll is around the actual direction, not 
the travel direction.  This is important at small scales when dealing with the 
spherical coordinate math necessary to point telescopes; it’s important at 
large scales if you imagine a fighter jet flying vertically up or down, and 
executing a roll (the roll axis is definitely not perpendicular to the local 
vertical axis in this case, unless you mean “platform local”, which I believe 
is how it is defined and I’m pretty sure is how it is measured by the 
accelerometers).  I believe that satellites work the same way also—once they 
define ‘front’, the measurements and calculations for roll are all around where 
front is, and similar patterns apply for pitch (measured relative to a line 
perpendicular to front-back axis directly through the wings) and yaw (measured 
around an axis vertical to the airplane local—note that the definitions for yaw 
include "Yaw is a rotation about the axis of rotation”, and appear to have lost 
the description of what the axis of rotation *is*.

I cite Wikipedia as my authority, not just because it matches my memory but 
also because it is footnoted, and refers to both airplanes and satellites using 
this reference frame.

Finally, my editing nit is that these definitions have replaced smart 
apostrophes with question marks, I assume dumb apostrophes are the order of the 
day.

John



platform_roll_starboard_down: 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 that is perpendicular to the local vertical 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 axis of 
rotation. The ?at rest? rotation of the platform may change over time. 
"Starboard down" indicates that positive values of roll represent the right 
side of the platform falling as viewed by an observer on top of the platform 
facing forward. 

platform_roll_starboard_up: 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 that is perpendicular to the local vertical 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 axis of 
rotation. The ?at rest? rotation of the platform may change over time. 
"Starboard up" indicates that positive values of roll represent the right side 
of the platform rising as viewed by an observer on top of the platform facing 
forward. 

platform_roll_rate_starboard_down: 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 that is perpendicular to the local 
vertical axis and is coplanar with the nominal forward motion direction of the 
platform. Roll rate might not include changes to the ?at rest? rotation of the 
platform with respect to the axis of rotation, which may change over time. 
"Starboard down" indicates that positive values of roll rate represent the 
right side of the platform falling as viewed by an observer on top of the 
platform facing forward. 

platform_roll_rate_starboard_up: Platform is a structure or vehicle that serves 
as a base for mounting sensors. Platforms include, but are 

Re: [CF-metadata] Platform Heave

[Kenneth Kehoe]

alues of sway rate represent the 
platform moving left as viewed by an observer on top of the platform 
facing forward.


platform_sway_rate_starboard: 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 a displacement along an axis 
that is perpendicular to both the local vertical axis and the 
nominal forward motion direction of the platform. Sway rate may not 
include changes to the ?at rest? position of the platform with 
respect to the axis of displacement, which may change over time. 
"Starboard" indicates that positive values of sway rate represent 
the platform moving right as viewed by an observer on top of the 
platform facing forward.


platform_heave_up: 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. Heave 
is relative to the ?at rest? position of the platform with respect 
to the axis of displacement. The ?at rest? position of the platform 
may change over time. "Up" indicates that positive values of heave 
represent the platform moving up as viewed by an observer on top of 
the platform facing forward.


platform_heave_down: 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. 
Heave is relative to the ?at rest? position of the platform with 
respect to the axis of displacement. The ?at rest? position of the 
platform may change over time. "Down" indicates that positive values 
of heave represent the platform moving down as viewed by an observer 
on top of the platform facing forward.


platform_heave_rate_up: 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. Heave rate may not include changes to the 
?at rest? position of the platform with respect to the axis of 
displacement, which may change over time. "Up" indicates that 
positive values of heave rate represent the platform moving up as 
viewed by an observer on top of the platform facing forward.


platform_heave_rate_down: 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. Heave rate may not include changes to the 
?at rest? position of the platform with respect to the axis of 
displacement, which may change over time. "Down" indicates that 
positive values of heave rate represent the platform moving down as 
viewed by an observer on top of the platform facing forward.


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).



On 9/11/18 12:13 PM, Lowry, Roy K. wrote:


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  on behalf of 
Jim Biard 

*Sent:* 11 September 2018 16:37
*To:* cf-metadata@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 

Re: [CF-metadata] Platform Heave

[Nan Galbraith]

s that is 
perpendicular to both the local vertical axis and the nominal forward 
motion direction of the platform. Sway rate may not include changes 
to the ?at rest? position of the platform with respect to the axis of 
displacement, which may change over time. "Starboard" indicates that 
positive values of sway rate represent the platform moving right as 
viewed by an observer on top of the platform facing forward.


platform_heave_up: 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. Heave is 
relative to the ?at rest? position of the platform with respect to 
the axis of displacement. The ?at rest? position of the platform may 
change over time. "Up" indicates that positive values of heave 
represent the platform moving up as viewed by an observer on top of 
the platform facing forward.


platform_heave_down: 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. 
Heave is relative to the ?at rest? position of the platform with 
respect to the axis of displacement. The ?at rest? position of the 
platform may change over time. "Down" indicates that positive values 
of heave represent the platform moving down as viewed by an observer 
on top of the platform facing forward.


platform_heave_rate_up: 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. Heave rate may not include changes to the ?at rest? 
position of the platform with respect to the axis of displacement, 
which may change over time. "Up" indicates that positive values of 
heave rate represent the platform moving up as viewed by an observer 
on top of the platform facing forward.


platform_heave_rate_down: 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. Heave rate may not include changes to the ?at rest? 
position of the platform with respect to the axis of displacement, 
which may change over time. "Down" indicates that positive values of 
heave rate represent the platform moving down as viewed by an 
observer on top of the platform facing forward.


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).



On 9/11/18 12:13 PM, Lowry, Roy K. wrote:


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  on behalf of 
Jim Biard 

*Sent:* 11 September 2018 16:37
*To:* cf-metadata@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

Re: [CF-metadata] Platform Heave

[Nan Galbraith]

 
the platform facing forward.


platform_heave_down: 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.  
Heave is relative to the ?at rest? position of the platform with  
respect to the axis of displacement. The ?at rest? position of the  
platform may change over time. "Down" indicates that positive values  
of heave represent the platform moving down as viewed by an observer  
on top of the platform facing forward.


platform_heave_rate_up: 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. Heave rate may not include changes to the  
?at rest? position of the platform with respect to the axis of  
displacement, which may change over time. "Up" indicates that  
positive values of heave rate represent the platform moving up as  
viewed by an observer on top of the platform facing forward.


platform_heave_rate_down: 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. Heave rate may not include changes to the  
?at rest? position of the platform with respect to the axis of  
displacement, which may change over time. "Down" indicates that  
positive values of heave rate represent the platform moving down as  
viewed by an observer on top of the platform facing forward.


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).



On 9/11/18 12:13 PM, Lowry, Roy K. wrote:


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  on behalf of  
Jim Biard 

*Sent:* 11 September 2018 16:37
*To:* cf-metadata@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   
<mailto:jbgrayb...@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. <mailto:r...@bodc.ac.uk> <mailto:r...@bodc.ac.uk>  
<mailto:r...@bodc.ac.uk>> wrote:



Dear Ji

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

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  on behalf of Jim Biard 

Sent: 11 September 2018 16:37
To: cf-metadata@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 
<mailto:jbgrayb...@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. 
mailto:r...@bodc.ac.uk> 
<mailto:r...@bodc.ac.uk><mailto:r...@bodc.ac.uk>> wrote:

Dear Jim,


Looking good to me.


Cheers, Roy.



*From:* CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu> 
<mailto:cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu>>
 on behalf of Jim Biard mailto:jbi...@cicsnc.org> 
<mailto:jbi...@cicsnc.org><mailto:jbi...@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 +, 
Lowry, Roy K. wrote:

Date: Wed, 5 Sep 2018 16:07:26 + From: "Lowry, Roy K." 
<mailto:r...@bodc.ac.uk> 
<mailto:r...@bodc.ac.uk><mailto:r...@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 
<mailto:cf-metadata-boun...@cgd.ucar.edu> 
<mailto:cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu>
 on behalf of Jonathan Gregory 
<mailto:j.m.greg...@reading.ac.uk> 
<mailto:j.m.greg...@reading.ac.uk><mailto

Re: [CF-metadata] Platform Heave

[Jim Biard]

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 
*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. <mailto:r...@bodc.ac.uk>> wrote:



Dear Jim,


Looking good to me.


Cheers, Roy.


 

*From:* CF-metadata <mailto:cf-metadata-boun...@cgd.ucar.edu>> on behalf of Jim Biard 
mailto:jbi...@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 +, Lowry, Roy K. 
wrote:


Date: Wed, 5 Sep 2018 16:07:26 + From: "Lowry, Roy K." 
 <mailto:r...@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  
<mailto:cf-metadata-boun...@cgd.ucar.edu> on behalf of Jonathan 
Gregory  
<mailto:j.m.greg...@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 
 <mailto:jbi...@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

Re: [CF-metadata] Platform Heave

[Nan Galbraith]

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 
*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. <mailto:r...@bodc.ac.uk>> wrote:



Dear Jim,


Looking good to me.


Cheers, Roy.



*From:* CF-metadata <mailto:cf-metadata-boun...@cgd.ucar.edu>> on behalf of Jim Biard 
mailto:jbi...@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 +, Lowry, Roy K. wrote:


Date: Wed, 5 Sep 2018 16:07:26 + From: "Lowry, Roy K." 
 <mailto:r...@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  
<mailto:cf-metadata-boun...@cgd.ucar.edu> on behalf of Jonathan 
Gregory  
<mailto:j.m.greg...@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  <mailto:jbi...@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 exist

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

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 +, Lowry, Roy K. wrote:
> Date: Wed, 5 Sep 2018 16:07:26 +
> From: "Lowry, Roy K." 
> To: Jonathan Gregory ,
>  "cf-metadata@cgd.ucar.edu" 
> 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.
> 
> 
> I have now retired but will continue to be active through an Emeritus 
> Fellowship using this e-mail address.
> 
> 
> 
> From: CF-metadata  on behalf of Jonathan 
> Gregory 
> Sent: 05 September 2018 16:26
> To: cf-metadata@cgd.ucar.edu
> 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
> 
> ----- Forwarded message from Jim Biard  -
> 
> > Date: Wed, 5 Sep 2018 09:32:37 -0400
> > From: Jim Biard 
> > To: "cf-metadata@cgd.ucar.edu" 
> > Subject: Re: [CF-metadata] Platform Heave
> > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
> >Gecko/20100101 Thunderbird/52.9.1
> >
> > 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.
> > >
> > >
> > >I have now retired but will continue to be active through an
> > >Emeritus Fellowship using this e-mail address.
> > >
> > >
> > >
> > >
> > >*From:* CF-metadata  on behalf
> > >of Jim Biard 
> > >*Sent:* 04 September 2018 16:36
> > >*To:* cf-metadata@cgd.ucar.edu
> &

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

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

- Forwarded message from Jim Biard  -

> Date: Wed, 5 Sep 2018 09:32:37 -0400
> From: Jim Biard 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] Platform Heave
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
>   Gecko/20100101 Thunderbird/52.9.1
> 
> 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.
> >
> >
> >I have now retired but will continue to be active through an
> >Emeritus Fellowship using this e-mail address.
> >
> >
> >
> >
> >*From:* CF-metadata  on behalf
> >of Jim Biard 
> >*Sent:* 04 September 2018 16:36
> >*To:* cf-metadata@cgd.ucar.edu
> >*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

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

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.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 04 September 2018 16:36
To: cf-metadata@cgd.ucar.edu
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 
<mailto:ngalbra...@whoi.edu> -



Date: Sun, 02 Sep 2018 11:57:33 -0400
From: Nan Galbraith <mailto:ngalbra...@whoi.edu>
To: "Lowry, Roy K." <mailto:r...@bodc.ac.uk>
Cc: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave
User-Agent: Internet Messaging Program (IMP) H4 (5.0.23)

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

Re: [CF-metadata] Platform Heave

[Jim Biard]

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  -


Date: Sun, 02 Sep 2018 11:57:33 -0400
From: Nan Galbraith 
To: "Lowry, Roy K." 
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave
User-Agent: Internet Messaging Program (IMP) H4 (5.0.23)

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." :


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.


I have now retired but will

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

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  -
> >
> >>Date: Sun, 02 Sep 2018 11:57:33 -0400
> >>From: Nan Galbraith 
> >>To: "Lowry, Roy K." 
> >>Cc: cf-metadata@cgd.ucar.edu
> >>Subject: Re: [CF-metadata] Platform Heave
> >>User-Agent: Internet Messaging Program (IMP) H4 (5.0.23)
> >>
> >>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." :
> >>
> >>>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 l

Re: [CF-metadata] Platform Heave

[Jim Biard]

Hi.

If that's the general consensus, then we can go that general direction. 
I'll prepare pairs of everything.


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 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.


Grace and peace,

Jim


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  -


Date: Sun, 02 Sep 2018 11:57:33 -0400
From: Nan Galbraith 
To: "Lowry, Roy K." 
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave
User-Agent: Internet Messaging Program (IMP) H4 (5.0.23)

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." :


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.


I have now retired but will continue to be active through an
Emeritus Fellowship using this e-mail address.



From: CF-metadata  on behalf of
Jim Biard 
Sent: 31 August 2018 14:38
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


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 

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

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  -

> Date: Sun, 02 Sep 2018 11:57:33 -0400
> From: Nan Galbraith 
> To: "Lowry, Roy K." 
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Platform Heave
> User-Agent: Internet Messaging Program (IMP) H4 (5.0.23)
> 
> 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." :
> 
> >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.
> >
> >
> >I have now retired but will continue to be active through an
> >Emeritus Fellowship using this e-mail address.
> >
> >
> >
> >From: CF-metadata  on behalf of
> >Jim Biard 
> >Sent: 31 August 2018 14:38
> >To: cf-metadata@cgd.ucar.edu
> >Subject: Re: [CF-metadata] Platform Heave
> >
> >
> >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, particula

Re: [CF-metadata] Platform Heave

[Nan Galbraith]

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." :


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.


I have now retired but will continue to be active through an  
Emeritus Fellowship using this e-mail address.




From: CF-metadata  on behalf of  
Jim Biard 

Sent: 31 August 2018 14:38
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


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  
<mailto:kke...@ou.e

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Jonathan,


I appreciate that you haven't been following this debate so I thought I'd point 
out that the proposal is a mixture of new Standard Names and upgrades to 
definitions of existing Standard Names for pitch, roll and yaw.  To my thinking 
whatever is done shouldn't change the semantics of the existing names.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 31 August 2018 13:52
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

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  -

> Date: Thu, 30 Aug 2018 12:05:44 -0600
> From: Kenneth Kehoe 
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Platform Heave
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0)
>Gecko/20100101 Thunderbird/60.0
>
> 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".

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

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 startboard

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.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 31 August 2018 14:38
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


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 
<mailto:kke...@ou.edu> -



Date: Thu, 30 Aug 2018 12:05:44 -0600
From: Kenneth Kehoe <mailto:kke...@ou.edu>
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0)
Gecko/20100101 Thunderbird/60.0

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

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

Dear Jim

Thanks for your email.

>  * There is no single sign convention being followed in existing
>datasets "in the wild".

I am not surprised. That's similar with other quantities. I agree that we have
to be able to describe the quantities people wish to use. CF doesn't try to
dictate what quantities people should use. That is why we have standard names
of surface_downward_sensible_heat_flux and surface_upward_sensible_heat_flux,
to mention just one of many examples, since both are in use.

>  * 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.

That is not a CF use of the positive attribute. In CF, the positive attribute
is for vertical coordinate variables, mainly for the convenience of programs
which want to know which way up to plot them, without needing to work it out
from any other information that might be given. In addition, any variable with
the positive attribute is interpreted as a vertical coordinate variable. This
is a convention which CF took over from the older COARDS netCDF convention.

All standard names indicate their sign convention in the name itself, and the
positive attribute is not a CF attribute of data variables.

>  * 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.

I don't think there ought to be a standard name for the version without the
sign convention i.e. platform_roll in your example. That would be like having
a standard name for sensible_heat_flux without the sign convention. Unless
the unsigned quantity is something distinct, there are only two in each case.

Picking the wrong version can be done either way. If you have one standard
name for both conventions you might pick the wrong value of the sign-convention
attribute.  That's the same sort of mistake as using the wrong standard name. 
But if you have a separate attribute, further kinds of mistake can arise, of
omitting it altogether, or giving it an invalid value for your standard name.

>  * 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.

This is no different from any of the many other cases where there are semantic
elements in common in groups of standard names. You may remember I gave a talk
at the meeting in Reading about why standard names group lots of different
semantic elements into one string. The sign convention is one of these. I think
these new platform standard names ought to be handled in the same way as we
have done for all other signed quantities in the standard name table.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Platform Heave

[Jim Biard]

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  -


Date: Thu, 30 Aug 2018 12:05:44 -0600
From: Kenneth Kehoe 
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0)
Gecko/20100101 Thunderbird/60.0

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

Re: [CF-metadata] Platform Heave

[Jonathan Gregory]

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  -

> Date: Thu, 30 Aug 2018 12:05:44 -0600
> From: Kenneth Kehoe 
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Platform Heave
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0)
>   Gecko/20100101 Thunderbird/60.0
> 
> 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  ><mailto:jbi...@cicsnc.org>> wrote:
> >
> >John,
> >
> >There are a variety of conventi

Re: [CF-metadata] Platform Heave

[Kenneth Kehoe]

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 > 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
retrograde.

https://www.hindawi.com/journals/mpe/2010/934714/



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 

Re: [CF-metadata] Platform Heave

[Jim Biard]

I'm OK with that.
[image: CICS-NC] Visit us on
Facebook  *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC  
North Carolina State University  
NOAA National Centers for Environmental Information  
*formerly NOAA’s National Climatic Data Center*
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900

*Connect with us on Facebook for climate
 and ocean and geophysics
 information, and follow us on
Twitter at @NOAANCEIclimate
and @NOAANCEIocngeo
.*



On Wed, Aug 29, 2018 at 3:54 PM 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  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 retrograde.
>>
>> https://www.hindawi.com/journals/mpe/2010/934714/
>>
>> 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  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 

Re: [CF-metadata] Platform Heave

[Ethan Davis]

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  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 retrograde.
>
> https://www.hindawi.com/journals/mpe/2010/934714/
>
> 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  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 

Re: [CF-metadata] Platform Heave

[Jim Biard]

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 retrograde.


https://www.hindawi.com/journals/mpe/2010/934714/

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 > 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
  

Re: [CF-metadata] Platform Heave

[John Helly]

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 retrograde.

https://www.hindawi.com/journals/mpe/2010/934714/

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  > 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
> 

Re: [CF-metadata] Platform Heave

[Ethan Davis]

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  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 

Re: [CF-metadata] Platform Heave

[Jim Biard]

e 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


On 8/6/18 12:11 PM, Kenneth Kehoe wrote:

Roy,

I am specifically asking for platform_sway and platform_surge.

Thanks,

Ken



On 2018-8-6 10:02, Lowry, Roy K. wrote:


Hi Jim,


One other thing to think on is the set of 'rate' Standard Names, or 
are you happy with my prefix from the yaw example added on to your 
definitions.



And finally are we intending to propose platform_sway and 
platform_surge as new Standard Names in addition to platform_heave 
which started this discussion even though nobody has specifically 
asked for them?



Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.





*From:* CF-metadata  on behalf of 
Jim Biard 

*Sent:* 06 August 2018 16:47
*To:* CF Metadata List; Jonathan Gregory
*Subject:* Re: [CF-metadata] Platform Heave
Hi.

There are other standard names that call for a separate attribute or 
variable that provides context. The attributes (at the moment) are 
all standard CF attributes (cell_method

Re: [CF-metadata] Platform Heave

[Kenneth Kehoe]

Roy,

I am specifically asking for platform_sway and platform_surge.

Thanks,

Ken



On 2018-8-6 10:02, Lowry, Roy K. wrote:


Hi Jim,


One other thing to think on is the set of 'rate' Standard Names, or 
are you happy with my prefix from the yaw example added on to your 
definitions.



And finally are we intending to propose platform_sway and 
platform_surge as new Standard Names in addition to platform_heave 
which started this discussion even though nobody has specifically 
asked for them?



Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.





*From:* CF-metadata  on behalf of 
Jim Biard 

*Sent:* 06 August 2018 16:47
*To:* CF Metadata List; Jonathan Gregory
*Subject:* Re: [CF-metadata] Platform Heave
Hi.

There are other standard names that call for a separate attribute or 
variable that provides context. The attributes (at the moment) are all 
standard CF attributes (cell_methods, flag_meanings, comment, etc). 
I'd love to get feedback from the community about whether or not a 
directionality attribute would need to described as a "standard" CF 
attribute.


I'll be glad to rework the definitions to make them 
directionality-agnostic when I get back next week.


Grace and peace,

Jim

CICS-NC 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cicsnc.org_=DwMF-g=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk=Vm7o2ZGxPkkqRuPs8nVMVQ=uVfoFv-LtZ2x4jvCcYtHX-YLw4uUnDgUjlQ0IOZ9PxQ=x34l51xPXmgH-aUwvSrR2s1BvnegDR9v5TUvmlkuC08=>Visit 
us on
Facebook 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_cicsnc=DwMF-g=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk=Vm7o2ZGxPkkqRuPs8nVMVQ=uVfoFv-LtZ2x4jvCcYtHX-YLw4uUnDgUjlQ0IOZ9PxQ=ms-RsdZkI8VABhdzIF3uemXo55CtII0rsdo8p0EYXwM=> 
	*Jim Biard*

*Research Scholar*
Cooperative Institute for Climate and Satellites NC 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__cicsnc.org_=DwMF-g=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk=Vm7o2ZGxPkkqRuPs8nVMVQ=uVfoFv-LtZ2x4jvCcYtHX-YLw4uUnDgUjlQ0IOZ9PxQ=dULLQNwecP3zJLjL5xmrBdaMifj8CGxHQVPkkTbgRRs=>
North Carolina State University 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__ncsu.edu_=DwMF-g=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk=Vm7o2ZGxPkkqRuPs8nVMVQ=uVfoFv-LtZ2x4jvCcYtHX-YLw4uUnDgUjlQ0IOZ9PxQ=pc9bIRFh1dbwzMr31a0uZZsN9rtfZQW3CJ6up_ZoctU=>
NOAA National Centers for Environmental Information 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__ncdc.noaa.gov_=DwMF-g=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk=Vm7o2ZGxPkkqRuPs8nVMVQ=uVfoFv-LtZ2x4jvCcYtHX-YLw4uUnDgUjlQ0IOZ9PxQ=W7I_Xw3TkOaJnM-fY_w1EGSZp2wCuNP2eAzOeeh4MPM=>

/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org <mailto:jbi...@cicsnc.org>
o: +1 828 271 4900

/Connect with us on Facebook for climate 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_NOAANCEIclimate=DwMF-g=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk=Vm7o2ZGxPkkqRuPs8nVMVQ=uVfoFv-LtZ2x4jvCcYtHX-YLw4uUnDgUjlQ0IOZ9PxQ=NW1KhxgkoSaNb9uaszNGr_sx0r-XF6FmCUYw7xwaxNA=> and 
ocean and geophysics 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_NOAANCEIoceangeo=DwMF-g=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk=Vm7o2ZGxPkkqRuPs8nVMVQ=uVfoFv-LtZ2x4jvCcYtHX-YLw4uUnDgUjlQ0IOZ9PxQ=Wx80mh4fB0mOGx5gusz4LetEt4drrQlVeK3qWuqbKyM=> information, 
and follow us on Twitter at @NOAANCEIclimate 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_NOAANCEIclimate=DwMF-g=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk=Vm7o2ZGxPkkqRuPs8nVMVQ=uVfoFv-LtZ2x4jvCcYtHX-YLw4uUnDgUjlQ0IOZ9PxQ=uXUzJCfCczRpiT3Na_BRexKN49eJJ2XmdDofSG3SEf8=>and 
@NOAANCEIocngeo 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_NOAANCEIocngeo=DwMF-g=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk=Vm7o2ZGxPkkqRuPs8nVMVQ=uVfoFv-LtZ2x4jvCcYtHX-YLw4uUnDgUjlQ0IOZ9PxQ=Vli9eQ3qepClRhnPQrHBQdUsozDl_01mX3zx0S-g-rw=>.//


/



On Sat, Aug 4, 2018 at 3:45 AM Lowry, Roy K. <mailto:r...@bodc.ac.uk>> wrote:


Dear Nan,


So are we returning to the wording in Alison's original
definitions (e.g. yaw normally clockwise facing front) before
you with my support asked for the ambiguity be removed? Or do you
want to go even further with no mention of sign convention at all?


I would also question whether a Standard Name definition is the
place to specify the mechanism to be used for the description of a
sign convention as it has wider implications than the parameters
currently under discussion. Would it not be more appropriate for
this to be considered an enhancement to CF and written into the
Conventions document? If so, it should it not be the subject of a
GitHub ticket?


Cheers, Roy.


I have now retired but will con

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Jim,


One other thing to think on is the set of 'rate' Standard Names, or are you 
happy with my prefix from the yaw example added on to your definitions.


And finally are we intending to propose platform_sway and platform_surge as new 
Standard Names in addition to platform_heave which started this discussion even 
though nobody has specifically asked for them?


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 06 August 2018 16:47
To: CF Metadata List; Jonathan Gregory
Subject: Re: [CF-metadata] Platform Heave

Hi.

There are other standard names that call for a separate attribute or variable 
that provides context. The attributes (at the moment) are all standard CF 
attributes (cell_methods, flag_meanings, comment, etc). I'd love to get 
feedback from the community about whether or not a directionality attribute 
would need to described as a "standard" CF attribute.

I'll be glad to rework the definitions to make them directionality-agnostic 
when I get back next week.

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: jbi...@cicsnc.org<mailto:jbi...@cicsnc.org>
o: +1 828 271 4900

Connect with us on Facebook for 
climate<http://www.facebook.com/NOAANCEIclimate> and ocean and 
geophysics<http://www.facebook.com/NOAANCEIoceangeo> information, and follow us 
on Twitter at @NOAANCEIclimate <http://www.twitter.com/NOAANCEIclimate> and 
@NOAANCEIocngeo<http://www.twitter.com/NOAANCEIocngeo>.




On Sat, Aug 4, 2018 at 3:45 AM Lowry, Roy K. 
mailto:r...@bodc.ac.uk>> wrote:

Dear Nan,


So are we returning to the wording in Alison's original definitions (e.g. yaw 
normally clockwise facing front) before you with my support asked for the 
ambiguity be removed? Or do you want to go even further with no mention of sign 
convention at all?


I would also question whether a Standard Name definition is the place to 
specify the mechanism to be used for the description of a sign convention as it 
has wider implications than the parameters currently under discussion. Would it 
not be more appropriate for this to be considered an enhancement to CF and 
written into the Conventions document? If so, it should it not be the subject 
of a GitHub ticket?


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu>> on 
behalf of Nan Galbraith mailto:ngalbra...@whoi.edu>>
Sent: 04 August 2018 02:18
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

Thanks, Jim.

> change the definitions to avoid declaring which direction is
> positive, make the direction attribute optional, and say that users
> should be careful about assuming the directionality for variables
> lacking the attribute.

This is the approach I'd prefer as well.

- Nan


Quoting Jim Biard mailto:jbi...@cicsnc.org>>:

> Nan,
>
> I didn't go to the lengths of making new regularized definitions
> before I wrote that list. I was thinking in terms of making the
> clockwise/anticlockwise call based on the right hand rule and the
> unit vector for each axis. For roll, for example, if the X unit
> vector faces forward, the "right side down" roll is actually
> anticlockwise - that is, it is in the direction that your right hand
> fingers curl if you grab the unit vector in your hand with your
> thumb pointing in the same direction as the unit vector. That
> definition is independent of observer location and look direction.
> My definitions for all the direction values are following that same
> convention.
>
> Accurate knowledge of the sign of roll, pitch, and yaw is critical
> in the satellite and aircraft world. The look angles for remote
> sensors are affected by these values. I get it that not all systems
> care about the signed values, so that reason and for backward
> compatibility I suggested that we could change the definitions to
> avoid declaring which direction is positive, make the direction
> attribute optional, and say that users should be careful about
> assuming the directionality for variables lacking the attribute.
>
> Grace and peace,
>
> Jim
>>
>> On 8/3/18 2:03 PM, Nan Galbraith wrote:
>>

Re: [CF-metadata] Platform Heave

[Jim Biard]

Hi.

There are other standard names that call for a separate attribute or
variable that provides context. The attributes (at the moment) are all
standard CF attributes (cell_methods, flag_meanings, comment, etc). I'd
love to get feedback from the community about whether or not a
directionality attribute would need to described as a "standard" CF
attribute.

I'll be glad to rework the definitions to make them directionality-agnostic
when I get back next week.

Grace and peace,

Jim

[image: 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: jbi...@cicsnc.org
o: +1 828 271 4900

*Connect with us on Facebook for climate
<http://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<http://www.facebook.com/NOAANCEIoceangeo> information, and follow us on
Twitter at @NOAANCEIclimate
<http://www.twitter.com/NOAANCEIclimate>and @NOAANCEIocngeo
<http://www.twitter.com/NOAANCEIocngeo>.*



On Sat, Aug 4, 2018 at 3:45 AM Lowry, Roy K.  wrote:

> Dear Nan,
>
>
> So are we returning to the wording in Alison's original definitions (e.g.
> yaw normally clockwise facing front) before you with my support asked for
> the ambiguity be removed? Or do you want to go even further with no mention
> of sign convention at all?
>
>
> I would also question whether a Standard Name definition is the place to
> specify the mechanism to be used for the description of a sign convention
> as it has wider implications than the parameters currently under
> discussion. Would it not be more appropriate for this to be considered an
> enhancement to CF and written into the Conventions document? If so, it
> should it not be the subject of a GitHub ticket?
>
>
> Cheers, Roy.
>
>
> I have now retired but will continue to be active through an Emeritus
> Fellowship using this e-mail address.
>
>
> ----------
> *From:* CF-metadata  on behalf of Nan
> Galbraith 
> *Sent:* 04 August 2018 02:18
> *To:* cf-metadata@cgd.ucar.edu
> *Subject:* Re: [CF-metadata] Platform Heave
>
> Thanks, Jim.
>
> > change the definitions to avoid declaring which direction is
> > positive, make the direction attribute optional, and say that users
> > should be careful about assuming the directionality for variables
> > lacking the attribute.
>
> This is the approach I'd prefer as well.
>
> - Nan
>
>
> Quoting Jim Biard :
>
> > Nan,
> >
> > I didn't go to the lengths of making new regularized definitions
> > before I wrote that list. I was thinking in terms of making the
> > clockwise/anticlockwise call based on the right hand rule and the
> > unit vector for each axis. For roll, for example, if the X unit
> > vector faces forward, the "right side down" roll is actually
> > anticlockwise - that is, it is in the direction that your right hand
> > fingers curl if you grab the unit vector in your hand with your
> > thumb pointing in the same direction as the unit vector. That
> > definition is independent of observer location and look direction.
> > My definitions for all the direction values are following that same
> > convention.
> >
> > Accurate knowledge of the sign of roll, pitch, and yaw is critical
> > in the satellite and aircraft world. The look angles for remote
> > sensors are affected by these values. I get it that not all systems
> > care about the signed values, so that reason and for backward
> > compatibility I suggested that we could change the definitions to
> > avoid declaring which direction is positive, make the direction
> > attribute optional, and say that users should be careful about
> > assuming the directionality for variables lacking the attribute.
> >
> > Grace and peace,
> >
> > Jim
> >>
> >> On 8/3/18 2:03 PM, Nan Galbraith wrote:
> >>> Hi Roy -
> >>>
> >>> Yes,  I've been looking at that page quite a bit lately, and I
> >>> think it backs up
> >>> what I'm saying.
> >>>
> >>> If you are standing on that fuselage (may we never), facing
> >>> forward, the red roll
> >>> arrow is showing a clockwise motion, with right side moving
> >>> downward. If you
> >>> were facing aft, the arrow would be anticlockwise, but the right side
> would
> >>>

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Nan,


So are we returning to the wording in Alison's original definitions (e.g. yaw 
normally clockwise facing front) before you with my support asked for the 
ambiguity be removed? Or do you want to go even further with no mention of sign 
convention at all?


I would also question whether a Standard Name definition is the place to 
specify the mechanism to be used for the description of a sign convention as it 
has wider implications than the parameters currently under discussion. Would it 
not be more appropriate for this to be considered an enhancement to CF and 
written into the Conventions document? If so, it should it not be the subject 
of a GitHub ticket?


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Nan Galbraith 

Sent: 04 August 2018 02:18
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Thanks, Jim.

> change the definitions to avoid declaring which direction is
> positive, make the direction attribute optional, and say that users
> should be careful about assuming the directionality for variables
> lacking the attribute.

This is the approach I'd prefer as well.

- Nan


Quoting Jim Biard :

> Nan,
>
> I didn't go to the lengths of making new regularized definitions
> before I wrote that list. I was thinking in terms of making the
> clockwise/anticlockwise call based on the right hand rule and the
> unit vector for each axis. For roll, for example, if the X unit
> vector faces forward, the "right side down" roll is actually
> anticlockwise - that is, it is in the direction that your right hand
> fingers curl if you grab the unit vector in your hand with your
> thumb pointing in the same direction as the unit vector. That
> definition is independent of observer location and look direction.
> My definitions for all the direction values are following that same
> convention.
>
> Accurate knowledge of the sign of roll, pitch, and yaw is critical
> in the satellite and aircraft world. The look angles for remote
> sensors are affected by these values. I get it that not all systems
> care about the signed values, so that reason and for backward
> compatibility I suggested that we could change the definitions to
> avoid declaring which direction is positive, make the direction
> attribute optional, and say that users should be careful about
> assuming the directionality for variables lacking the attribute.
>
> Grace and peace,
>
> Jim
>>
>> On 8/3/18 2:03 PM, Nan Galbraith wrote:
>>> Hi Roy -
>>>
>>> Yes,  I've been looking at that page quite a bit lately, and I
>>> think it backs up
>>> what I'm saying.
>>>
>>> If you are standing on that fuselage (may we never), facing
>>> forward, the red roll
>>> arrow is showing a clockwise motion, with right side moving
>>> downward. If you
>>> were facing aft, the arrow would be anticlockwise, but the right side would
>>> be rising.
>>>
>>> So, 'roll: "clockwise" for positive right side up and
>>> "anticlockwise" for positive right
>>> side down'- is backwards in either case. I'm not disputing
>>> anything except
>>> the term 'clockwise'  in this phrase.
>>>
>>> Thanks - Nan
>>>
>>> On 8/3/18 1:43 PM, Lowry, Roy K. wrote:
>>>>
>>>> Hi Nan,
>>>>
>>>>
>>>> Whilst I appreciate the limitations of Wikipedia as an
>>>> authoritative source have a look at
>>>> https://en.wikipedia.org/wiki/Aircraft_principal_axes
[https://upload.wikimedia.org/wikipedia/commons/thumb/5/54/Flight_dynamics_with_text.png/1200px-Flight_dynamics_with_text.png]<https://en.wikipedia.org/wiki/Aircraft_principal_axes>

Aircraft principal axes - 
Wikipedia<https://en.wikipedia.org/wiki/Aircraft_principal_axes>
en.wikipedia.org
Normal axis, or yaw axis — an axis drawn from top to bottom, and perpendicular 
to the other two axes.Parallel to the fuselage station.; Transverse axis, 
lateral axis, or pitch axis — an axis running from the pilot's left to right in 
piloted aircraft, and parallel to the wings of a winged aircraft.



>>>>
>>>>
>>>> Cheers, Roy.
>>>>
>>>>
>>>> 
>>>> *From:* Nan Galbraith 
>>>> *Sent:* 03 August 2018 18:23
>>>> *To:* Jim Biard; Lowry, Roy K.; kke...@ou.edu
>>>> *Subject:* Re: [CF-metadata] Platform Heave (pitch, roll)
>>>> Hi Jim, Roy and Ken -
>>>>
>>>>

Re: [CF-metadata] Platform Heave

[Nan Galbraith]

Thanks, Jim.

change the definitions to avoid declaring which direction is  
positive, make the direction attribute optional, and say that users  
should be careful about assuming the directionality for variables  
lacking the attribute.


This is the approach I'd prefer as well.

- Nan


Quoting Jim Biard :


Nan,

I didn't go to the lengths of making new regularized definitions  
before I wrote that list. I was thinking in terms of making the  
clockwise/anticlockwise call based on the right hand rule and the  
unit vector for each axis. For roll, for example, if the X unit  
vector faces forward, the "right side down" roll is actually  
anticlockwise - that is, it is in the direction that your right hand  
fingers curl if you grab the unit vector in your hand with your  
thumb pointing in the same direction as the unit vector. That  
definition is independent of observer location and look direction.  
My definitions for all the direction values are following that same  
convention.


Accurate knowledge of the sign of roll, pitch, and yaw is critical  
in the satellite and aircraft world. The look angles for remote  
sensors are affected by these values. I get it that not all systems  
care about the signed values, so that reason and for backward  
compatibility I suggested that we could change the definitions to  
avoid declaring which direction is positive, make the direction  
attribute optional, and say that users should be careful about  
assuming the directionality for variables lacking the attribute.


Grace and peace,

Jim


On 8/3/18 2:03 PM, Nan Galbraith wrote:

Hi Roy -

Yes,  I've been looking at that page quite a bit lately, and I  
think it backs up

what I'm saying.

If you are standing on that fuselage (may we never), facing  
forward, the red roll
arrow is showing a clockwise motion, with right side moving  
downward. If you

were facing aft, the arrow would be anticlockwise, but the right side would
be rising.

So, 'roll: "clockwise" for positive right side up and  
"anticlockwise" for positive right
side down'    - is backwards in either case. I'm not disputing  
anything except

the term 'clockwise'  in this phrase.

Thanks - Nan

On 8/3/18 1:43 PM, Lowry, Roy K. wrote:


Hi Nan,


Whilst I appreciate the limitations of Wikipedia as an  
authoritative source have a look at  
https://en.wikipedia.org/wiki/Aircraft_principal_axes



Cheers, Roy.


  
*From:* Nan Galbraith 

*Sent:* 03 August 2018 18:23
*To:* Jim Biard; Lowry, Roy K.; kke...@ou.edu
*Subject:* Re: [CF-metadata] Platform Heave (pitch, roll)
Hi Jim, Roy and Ken -

I'm skipping the list because this is a minor point and ... and I may be
missing
something obvious.

It's hard not to think of these terms as they apply to ships. In that
environment,
we'd use the convention of the observer facing forward; therefore roll
would be
clockwise if the right side were going down, not up. I'm supposing that
would
also apply to aircraft.

Cheers - Nan




If we declare that X is positive forward, that Y is positive left,
that Z is positive up, and that we use the right-hand rule for angle
directions, the direction attribute values could be:

  * 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.








------------  
>>>

*From:* CF-metadata  on behalf of
Jim Biard 
*Sent:* 03 August 2018 15:41
*To:* cf-metadata@cgd.ucar.edu
*Subject:* Re: [CF-metadata] Platform Heave

I freely admit that I picked direction on sway arbitrarily. In my
experience, part of the variation that arises in the definitions of
the different motions arises from different thoughts about their
use, particularly whether someone is thinking the values are used to
transform into the platform body frame vs transform from it. Or
maybe they just aren't worrying about consistency. Like as not,
choices have often been made in attempts to make the values have the
signed-ness that felt right to people, and we can't keep to
conventions like the right hand rule and make it all work
consistently. We want a positive pitch to be nose up. We want a
positive yaw to be nose right. We want positive heave to be up. My
natural tendency is to think of "roll right" as positive and "sway
right" as positive, but that isn't 

Re: [CF-metadata] Platform Heave

[Jim Biard]

Nan,

I didn't go to the lengths of making new regularized definitions before 
I wrote that list. I was thinking in terms of making the 
clockwise/anticlockwise call based on the right hand rule and the unit 
vector for each axis. For roll, for example, if the X unit vector faces 
forward, the "right side down" roll is actually anticlockwise - that is, 
it is in the direction that your right hand fingers curl if you grab the 
unit vector in your hand with your thumb pointing in the same direction 
as the unit vector. That definition is independent of observer location 
and look direction. My definitions for all the direction values are 
following that same convention.


Accurate knowledge of the sign of roll, pitch, and yaw is critical in 
the satellite and aircraft world. The look angles for remote sensors are 
affected by these values. I get it that not all systems care about the 
signed values, so that reason and for backward compatibility I suggested 
that we could change the definitions to avoid declaring which direction 
is positive, make the direction attribute optional, and say that users 
should be careful about assuming the directionality for variables 
lacking the attribute.


Grace and peace,

Jim


On 8/3/18 2:03 PM, Nan Galbraith wrote:

Hi Roy -

Yes,  I've been looking at that page quite a bit lately, and I think 
it backs up

what I'm saying.

If you are standing on that fuselage (may we never), facing forward, 
the red roll
arrow is showing a clockwise motion, with right side moving downward. 
If you
were facing aft, the arrow would be anticlockwise, but the right side 
would

be rising.

So, 'roll: "clockwise" for positive right side up and "anticlockwise" 
for positive right
side down'    - is backwards in either case. I'm not disputing 
anything except

the term 'clockwise'  in this phrase.

Thanks - Nan

On 8/3/18 1:43 PM, Lowry, Roy K. wrote:


Hi Nan,


Whilst I appreciate the limitations of Wikipedia as an authoritative 
source have a look at 
https://en.wikipedia.org/wiki/Aircraft_principal_axes



Cheers, Roy.


 


*From:* Nan Galbraith 
*Sent:* 03 August 2018 18:23
*To:* Jim Biard; Lowry, Roy K.; kke...@ou.edu
*Subject:* Re: [CF-metadata] Platform Heave (pitch, roll)
Hi Jim, Roy and Ken -

I'm skipping the list because this is a minor point and ... and I 
may be

missing
something obvious.

It's hard not to think of these terms as they apply to ships. In that
environment,
we'd use the convention of the observer facing forward; therefore roll
would be
clockwise if the right side were going down, not up. I'm supposing that
would
also apply to aircraft.

Cheers - Nan



> If we declare that X is positive forward, that Y is positive left,
> that Z is positive up, and that we use the right-hand rule for angle
> directions, the direction attribute values could be:
>
>   * 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.

>


>
>>>
>>> 
------------ 


>>>
>>> *From:* CF-metadata  on behalf of
>>> Jim Biard 
>>> *Sent:* 03 August 2018 15:41
>>> *To:* cf-metadata@cgd.ucar.edu
>>> *Subject:* Re: [CF-metadata] Platform Heave
>>>
>>> I freely admit that I picked direction on sway arbitrarily. In my
>>> experience, part of the variation that arises in the definitions of
>>> the different motions arises from different thoughts about their
>>> use, particularly whether someone is thinking the values are 
used to

>>> transform into the platform body frame vs transform from it. Or
>>> maybe they just aren't worrying about consistency. Like as not,
>>> choices have often been made in attempts to make the values have 
the

>>> signed-ness that felt right to people, and we can't keep to
>>> conventions like the right hand rule and make it all work
>>> consistently. We want a positive pitch to be nose up. We want a
>>> positive yaw to be nose right. We want positive heave to be up. My
>>> natural tendency is to think of "roll right" as positive and "sway
>>> right" as positive,

Re: [CF-metadata] Platform Heave (pitch, roll)

[Nan Galbraith]

Hi all -

I'm still interested in using a single standard name each for pitch and 
roll,

but not because I'm concerned about too many of standard names. There
can be a case made for including pitch and roll without actually knowing
the sign/direction.

In some cases, these angle are only important because they indicate a
deviation from the expected vertical/horizontal norm; which way the
platform is pointing doesn't really matter.

Our ADCPs, for example, output these terms; the sign convention,
if it's published, isn't easy to find, and nobody particularly cares. The
correction for the angle is made internally in firmware; the values may
be (should be) carried along as a rough QC term - some users will want
to ignore data points where the angles are greater than some value.

In those cases, a standard name that doesn't specify the direction would
be really useful. An attribute could be specified for cases where the
direction is important.

And Roy, I think you have this exactly backwards: 'if we specify an 
attribute

it would need to be added to all existing data.'

If we change the definitions so that they specify the direction, THAT may
make these data files incorrect. If we simply add a definition for a new
attribute while we're updating the definitions, data providers can 
choose whether
they need to add this to the existing data. The definitions remain vague 
as to

direction, and that seems fine to me.

Thanks - Nan

On 8/3/18 12:21 PM, Jim Biard wrote:


Roy,


It sounds like sway ought to be left-positive. But if the world is OK 
with things otherwise, then OK.



Jim


On 8/3/18 11:36 AM, Lowry, Roy K. wrote:


Dear Jim,


I really don't think we need to take this approach. I'm investigating 
existing datasets in various European projects and have yet to find 
anything that breaks the conventions heave positive up, roll 
right-side down , yaw positive clockwise and pitch positive nose up. 
I've yet to look into sway and surge which seem far less common in 
oceanographic data. From his last e-mail Ken's data products 
also follow these conventions.



Don't forget, we are adding definitions to existing Standard Names 
not creating new Standard Names and so should be aiming to cause as 
little disruption to the CF community as possible. Remember if we 
specify an attribute it would need to be added to all existing data.



Cheers, Roy.




*From:* CF-metadata  on behalf of 
Jim Biard 

*Sent:* 03 August 2018 15:41
*To:* cf-metadata@cgd.ucar.edu
*Subject:* Re: [CF-metadata] Platform Heave

I freely admit that I picked direction on sway arbitrarily. In my 
experience, part of the variation that arises in the definitions of 
the different motions arises from different thoughts about their use, 
particularly whether someone is thinking the values are used to 
transform into the platform body frame vs transform from it. Or maybe 
they just aren't worrying about consistency. Like as not, choices 
have often been made in attempts to make the values have the 
signed-ness that felt right to people, and we can't keep to 
conventions like the right hand rule and make it all work 
consistently. We want a positive pitch to be nose up. We want a 
positive yaw to be nose right. We want positive heave to be up. My 
natural tendency is to think of "roll right" as positive and "sway 
right" as positive, but that isn't what other people think of.


As I read what I wrote, I realize I didn't use a consistent approach 
to position and look direction when assigning clockwise and 
anticlockwise to roll, pitch, and yaw. I need to regularize that.


Reading the Conventions about vertical coordinates, it says they must 
all have a "positive" attribute with a value of "up" or "down". I 
don't see a problem with having the definitions back off of declaring 
a specific directionality and add an attribute declaring 
directionality. We could call the attribute "direction" so as not to 
step on the "positive" attribute, and say that if the attribute is 
not present that the user should not assume which direction is correct.


If we declare that X is positive forward, that Y is positive left, 
that Z is positive up, and that we use the right-hand rule for angle 
directions, the direction attribute values could be:


  * 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"

Re: [CF-metadata] Platform Heave

[Nan Galbraith]

Thank you, Jim, well done.

My only concern is that platform_orientation is describing the same angle
as yaw, and maybe should be deprecated.  The web is full of references to
'platform orientation', and a very quick check tells me they (mainly) 
refer to

all 3 axes.

I tried to check the sign of roll for ADCPs, since this is a variable 
that's output
by the Teledyne-RDIs that we use, but I don't have the time to do a 
thorough job
at this point. If different communities define this differently, Maybe 
we'll need to

consider using an attribute.

Cheers - Nan

On 8/2/18 5:01 AM, Lowry, Roy K. wrote:


Dear All,


You're not going to believe this, but try Googling 'pitch roll yaw' 
and look through the images at the roll sign convention. This reveals 
some inconsistency on whether positive roll is clockwise when looking 
forward (Jim's definition) or looking backward (Ken's definition).



My personal experience from going to sea was that positive roll was 
port to starboard - i.e. clockwise when looking forward. I'm pretty 
sure the roll data streams we handle (Autosub and gliders) 
also conform to this convention, but will ask somebody to check.



Could I suggest that Ken also check his definition sources and data 
streams.



Cheers, Roy.




*From:* CF-metadata  on behalf of 
Kenneth Kehoe 

*Sent:* 01 August 2018 22:51
*To:* cf-metadata@cgd.ucar.edu
*Subject:* Re: [CF-metadata] Platform Heave
Sounds good to me except the platform_roll positive direction seems to 
be opposite of what we have been describing. I typically have platform 
roll positive for right-hand side rising.


Ken


On 2018-8-1 13:55, Jim Biard wrote:


Hi.


Here is my proposal for a self-consistent and generic set of 
definitions for roll, pitch, yaw, surge, sway, heave, course, and 
orientation. I've tried to avoid lots of reference frame or vector 
terms, basing everything on the vertical direction and the nominal 
forward motion direction, which are two things all the moving 
platforms we are concerned with have, and which I think are easy 
enough to extrapolate to a stationary platform. I haven't bothered to 
do the *_rate definitions, since they are simple extrapolations of 
these definitions.


I have taken the liberty of removing the redundant word "angle" from 
the definitions of roll, pitch, and yaw. It is like using "latitude 
angle" for latitude or "course angle" for course. We can make the 
redundant formulations aliases of the proper ones.




*

platform_roll: 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 for the platform. The 
rotation is positive clockwise about that axis when seen from behind 
the platform looking towards it (e.g. right-hand side falling), and 
relative to the “at rest” rotation of the platform with respect to 
the X axis. 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.


**

*
*

platform_pitch: 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 for the platform. The rotation is 
positive clockwise about that axis when seen from the left of the 
platform looking towards it (e.g. front end rising), and relative to 
the “at rest” rotation of the platform with respect to the Y axis. 
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.


**

*
*

platform_yaw: Yaw is a rotation about the local vertical axis (the Z 
axis). The rotation is positive clockwise about that axis when seen 
from above the platform looking towards it (e.g. front end turning to 
the right), and relative to the “at rest” rotation of the platform 
with respect to the Z axis. 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.


**

*
*

platform_surge: 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 for the platform. 
The displacement is positive for motion of the platform in the 
nominal forward motion direction (e.g. forward motion), and 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. 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.

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

On second thoughts removing the underscores is more elegant correction than 
adding 'platform'.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Lowry, Roy K. 

Sent: 30 July 2018 18:49
To: Kenneth Kehoe
Cc: CF Metadata List
Subject: Re: [CF-metadata] Platform Heave


Hi Ken,


You're absolutely right - should have been platform_yaw_angle. Getting the 
detail spot on in these things isn't easy, which is why we have discussion 
lists!


With the way I'm currently seeing things I don't agree that pitch and roll 
affect the definition of heave. They are only factors that come into account 
with the coupling of heave into the next level of the CRS hierarchy.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Kenneth Kehoe 

Sent: 30 July 2018 18:39
Cc: CF Metadata List
Subject: Re: [CF-metadata] Platform Heave

I agree with John the (keel to top of mast) statement is incorrect when the 
platform is tilted. I only inserted that to help describe the Z-axis. But I 
don't think it's helping. I think John is also right on point with this since I 
can't find a definition of heave that discusses the orientation of the platform 
and how it relates to the measurement of heave. That is why I'm suggesting we 
not try to tackle that issue. From an instrument perspective I don't think the 
organization writing the measurement to file actually know all the details of 
how the values are derived or the full reference frame. I tell people to not 
use the standard_name definitions unless they are positive it matches exactly, 
and without all the information I don't think people will be able to use a too 
specific definition. A less specific definition would allow the use now, and a 
more specific definition can be added later if needed.

I did like Roy's definition of platform_yaw_angle and platform_yaw_rate. My 
only suggestion is to remove the underscore in "yaw_angle" in the definition of 
platform_yaw_rate, or use the full term "platform_yaw_angle". Otherwise it 
appears like a reference to a different term.

Ken



On 2018-7-30 10:52, John Graybeal wrote:
1) Now that we have another platform_heave comment, could we please create a 
new thread for the discussion on pitch/roll/heading?  Maybe starting without 
all the historical points, at least the heave-related ones? Both are difficult 
conversations to follow in sequence.

2) I have a concern about the last two heave definitions.
  a) "Heave is the linear motion along the vertical Z-axis (e.g. keel to top of 
mast) with positive values representing upward motion.”

I like the thrust of this definition, it’s simple to understand. However I 
don’t think it’s measured in the direction of keel to top of mast of the 
current or recent vessel position, is it? I rather assume it is perpendicular 
to a nominally level service, possibly in the direction of the gravity vector. 
The dictionary definition "Heaving is the linear motion along the vertical 
Z-axis” with the positive values coda seems closer.

  b) "upwards vertical displacement of a platform over a measurement time 
interval”

I can’t tell how to parse ‘over’ here.  An upwards vertical displacement is 
relative to another position, and in this case I think that ‘original’ position 
is being measured (at least conceptually) during another time interval. It just 
needs a few words, something like “of a platform when compared to its average 
vertical position over a corresponding time interface”.

But I guess the fundamental issue is I can’t tell (and don’t actually know) 
what heave is determined with respect to. If my last 11 positions relative to 
average seas are 0, 1, 2, 2, 1, 4, 1, 2, 2, 1, 0 (think hilly!), I have no idea 
if the heave at the peak (‘4’) is 4 or something else — it just depends on when 
and how long the baseline measurement is, doesn’t it?  (Or to put it another 
way, is the heave at the 7th point a negative number, since the ship just went 
down 3 units?)  If someone can answer that then our best definition might be 
more obvious.

John

---
John Graybeal
jbgrayb...@mindspring.com<mailto:jbgrayb...@mindspring.com>

On Jul 29, 2018, at 04:29, Lowry, Roy K. 
mailto:r...@bodc.ac.uk>> wrote:

Dear All,

Giving it some thought over the weekend I realise that where we lost the plot 
in this discussion was when we encountered 'direction of travel'. Jim 
succinctly described platform motion with the phrase 'nested co-ordinate 
systems'. What I failed to realise - and I'm guessing I'm not alone - is that 
the pitch, roll, heave etc. family of terms for platform motion refer SOLELY to 
the innermost co-ordinate reference in that nest and that 

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hear Hear!!!


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Nan Galbraith 

Sent: 30 July 2018 19:22
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Point of order!

I'm in favor of less specific definitions; other attributes can be
used to describe methods and ... whatever else is needed.

On the other hand, planning to change a definition to something more
specific at some point in the future is not good for CF. If I label
something
as heave now, it should still be heave in 20 years.

Cheers - Nan

On 7/30/18 1:39 PM, Kenneth Kehoe wrote:
> A less specific definition would allow the use now, and a more
> specific definition can be added later if needed.
>

--
***
* Nan GalbraithInformation Systems Specialist *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543 (508) 289-2444 *
***


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
CF-metadata Info Page - 
mailman.cgd.ucar.edu<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
mailman.cgd.ucar.edu
This is an unmoderated list for discussions about interpretation, 
clarification, and proposals for extensions or change to the CF conventions.




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.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Platform Heave

[Nan Galbraith]

Point of order!

I'm in favor of less specific definitions; other attributes can be
used to describe methods and ... whatever else is needed.

On the other hand, planning to change a definition to something more
specific at some point in the future is not good for CF. If I label 
something

as heave now, it should still be heave in 20 years.

Cheers - Nan

On 7/30/18 1:39 PM, Kenneth Kehoe wrote:
A less specific definition would allow the use now, and a more 
specific definition can be added later if needed.




--
***
* Nan GalbraithInformation Systems Specialist *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543 (508) 289-2444 *
***


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Nan,


By platform at rest I mean a situation where pitch=0, roll=0, yaw=0, heave=0 
etc. I'm now seeing a tilted platform, such as an out of balance deck load, as 
a coupling to the next level of CRS, so your last statement is absolutely spot 
on.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Nan Galbraith 

Sent: 30 July 2018 18:12
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Hi all -

I like Ken K's definitions; simple and to the point;  And I agree that
we need to be explicit
about positive direction (which term, by the way, doesn't google well).

I'm not sure I agree with Roy that 'zero is platform at rest' - could
you please explain
that? By 'at rest' do we mean that no forces are operating on the
platform? Would  a buoy
have roll and heave angles if its deck load were out of balance?  If its
deck isn't level, what
term would describe that? I suppose you're building on the fact that
these rotations are
relative to the internal axes of the platform, with no relation to the
'real world'.

It does seem like we're converging ... maybe.

Cheers - Nan

-

On 7/29/18 7:29 AM, Lowry, Roy K. wrote:
>  > Dear All, > > > Giving it some thought over the weekend I realise
that where we lost > the plot in this discussion was when we encountered
'direction of > travel'. Jim succinctly described platform motion with
the phrase > 'nested co-ordinate systems'. What I failed to realise -
and I'm > guessing I'm not alone - is that the pitch, roll, heave etc.
family > of terms for platform motion refer SOLELY to the innermost >
co-ordinate reference in that nest and that the 'zero' for these >
measurements is 'platform at rest'. This innermost co-ordinate >
reference comprises three orthogonal axes that intersect at the >
platform's centre of gravity. Two of these are horizontal (Ken's >
longitudinal X-axis and transverse Y-axis) and the third vertical >
(Ken's vertical Z-axis). Others make no attempt to treat these >
parameters in the same way as zenith, and I now realise CF shouldn't >
be any different. > > > Having come to terms with this, Ken's definition
elements have a > beautiful simplicity that can be slotted into Alison's
compound > definitions. My only problem is the inclusion of nautical
terms like > 'bow' and 'stern', but these can easily be replaced by
generic > equivalents such as 'front' and 'back'. I would also make it
clearer > is that zero is platform at rest. > > > For example the
definition pair for yaw become: > > > platform_yaw_angle > > "yaw
_angle" is the amount of rotation from the rest position around > the
vertical Z-axis with positive values resulting in clockwise > motion
when viewed from above. The vertical Z axis, also known as the > "yaw
axis", is an imaginary line running vertically through the > platform's
centre of gravity. Standard names for "platform" describe > the motion
and orientation of the vehicle from which observations are > made.
Platforms include, but are not limited to, satellites, > aeroplanes,
ships, instruments and buoys. > > > platform_yaw_rate > >
"platform_yaw_rate" is the change per unit time of "yaw_angle". "yaw >
_angle" is the amount of rotation from the rest position around the >
vertical Z-axis with positive values resulting in clockwise motion >
when viewed from above. The vertical Z axis, also known as the "yaw >
axis", is an imaginary line running vertically through the platform's >
centre of gravity. Standard names for "platform" describe the motion >
and orientation of the vehicle from which observations are made. >
Platforms include, but are not limited to, satellites, aeroplanes, >
ships, instruments and buoys. > > > How does that work for people? > > >
Cheers, Roy. > > > -
> From: CF-metadata on behalf of Kenneth Kehoe   > Sent: 27 July 
> 2018 16:49 > Subject: Re: [CF-metadata] Platform Heave
 > > All, > > Sorry for joining this conversation late. This is an
important > discussion for my group and finding a resolution would be
very > helpful. For my purposes I only need a good definition, which
might > coincide with the nautical definitions. For example this
reference > <https://www.wartsila.com/encyclopedia/term/ship-motions>
[https://cdn.wartsila.com/images/default-source/marine-pictures/encyclopedia-download.jpg?sfvrsn=adbfdc45_41zB]<https://www.wartsila.com/encyclopedia/term/ship-motions>

Ship motions - Wärtsilä<https://www.wartsila.com/encyclopedia/term/ship-motions>
www.wartsila.com
Ship motions. A ship at sea moves in six de

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Ken,


You're absolutely right - should have been platform_yaw_angle. Getting the 
detail spot on in these things isn't easy, which is why we have discussion 
lists!


With the way I'm currently seeing things I don't agree that pitch and roll 
affect the definition of heave. They are only factors that come into account 
with the coupling of heave into the next level of the CRS hierarchy.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Kenneth Kehoe 

Sent: 30 July 2018 18:39
Cc: CF Metadata List
Subject: Re: [CF-metadata] Platform Heave

I agree with John the (keel to top of mast) statement is incorrect when the 
platform is tilted. I only inserted that to help describe the Z-axis. But I 
don't think it's helping. I think John is also right on point with this since I 
can't find a definition of heave that discusses the orientation of the platform 
and how it relates to the measurement of heave. That is why I'm suggesting we 
not try to tackle that issue. From an instrument perspective I don't think the 
organization writing the measurement to file actually know all the details of 
how the values are derived or the full reference frame. I tell people to not 
use the standard_name definitions unless they are positive it matches exactly, 
and without all the information I don't think people will be able to use a too 
specific definition. A less specific definition would allow the use now, and a 
more specific definition can be added later if needed.

I did like Roy's definition of platform_yaw_angle and platform_yaw_rate. My 
only suggestion is to remove the underscore in "yaw_angle" in the definition of 
platform_yaw_rate, or use the full term "platform_yaw_angle". Otherwise it 
appears like a reference to a different term.

Ken



On 2018-7-30 10:52, John Graybeal wrote:
1) Now that we have another platform_heave comment, could we please create a 
new thread for the discussion on pitch/roll/heading?  Maybe starting without 
all the historical points, at least the heave-related ones? Both are difficult 
conversations to follow in sequence.

2) I have a concern about the last two heave definitions.
  a) "Heave is the linear motion along the vertical Z-axis (e.g. keel to top of 
mast) with positive values representing upward motion.”

I like the thrust of this definition, it’s simple to understand. However I 
don’t think it’s measured in the direction of keel to top of mast of the 
current or recent vessel position, is it? I rather assume it is perpendicular 
to a nominally level service, possibly in the direction of the gravity vector. 
The dictionary definition "Heaving is the linear motion along the vertical 
Z-axis” with the positive values coda seems closer.

  b) "upwards vertical displacement of a platform over a measurement time 
interval”

I can’t tell how to parse ‘over’ here.  An upwards vertical displacement is 
relative to another position, and in this case I think that ‘original’ position 
is being measured (at least conceptually) during another time interval. It just 
needs a few words, something like “of a platform when compared to its average 
vertical position over a corresponding time interface”.

But I guess the fundamental issue is I can’t tell (and don’t actually know) 
what heave is determined with respect to. If my last 11 positions relative to 
average seas are 0, 1, 2, 2, 1, 4, 1, 2, 2, 1, 0 (think hilly!), I have no idea 
if the heave at the peak (‘4’) is 4 or something else — it just depends on when 
and how long the baseline measurement is, doesn’t it?  (Or to put it another 
way, is the heave at the 7th point a negative number, since the ship just went 
down 3 units?)  If someone can answer that then our best definition might be 
more obvious.

John

---
John Graybeal
jbgrayb...@mindspring.com<mailto:jbgrayb...@mindspring.com>

On Jul 29, 2018, at 04:29, Lowry, Roy K. 
mailto:r...@bodc.ac.uk>> wrote:

Dear All,

Giving it some thought over the weekend I realise that where we lost the plot 
in this discussion was when we encountered 'direction of travel'. Jim 
succinctly described platform motion with the phrase 'nested co-ordinate 
systems'. What I failed to realise - and I'm guessing I'm not alone - is that 
the pitch, roll, heave etc. family of terms for platform motion refer SOLELY to 
the innermost co-ordinate reference in that nest and that the 'zero' for these 
measurements is 'platform at rest'. This innermost co-ordinate reference 
comprises three orthogonal axes that intersect at the platform's centre of 
gravity. Two of these are horizontal (Ken's longitudinal X-axis and transverse 
Y-axis) and the third vertical (Ken's vertical Z-axis). Others make no attempt 
to treat these parameters in the same way as zenith, and I now realise CF 
sh

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi John,


Think about my last posting. Heave is only relevant to the internal platform 
CRS. How it couples to other CRS, such as a 3-D platform locations, may well 
differ for different types of platform, but that should not be a concern of the 
heave definition.


Heave has a lot in common with pitche, roll, heave etc. so I don't think it 
should be decoupled.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: John Graybeal 
Sent: 30 July 2018 17:52
To: Lowry, Roy K.
Cc: Kenneth Kehoe; CF Metadata List
Subject: Re: [CF-metadata] Platform Heave

1) Now that we have another platform_heave comment, could we please create a 
new thread for the discussion on pitch/roll/heading?  Maybe starting without 
all the historical points, at least the heave-related ones? Both are difficult 
conversations to follow in sequence.

2) I have a concern about the last two heave definitions.
  a) "Heave is the linear motion along the vertical Z-axis (e.g. keel to top of 
mast) with positive values representing upward motion.”

I like the thrust of this definition, it’s simple to understand. However I 
don’t think it’s measured in the direction of keel to top of mast of the 
current or recent vessel position, is it? I rather assume it is perpendicular 
to a nominally level service, possibly in the direction of the gravity vector. 
The dictionary definition "Heaving is the linear motion along the vertical 
Z-axis” with the positive values coda seems closer.

  b) "upwards vertical displacement of a platform over a measurement time 
interval”

I can’t tell how to parse ‘over’ here.  An upwards vertical displacement is 
relative to another position, and in this case I think that ‘original’ position 
is being measured (at least conceptually) during another time interval. It just 
needs a few words, something like “of a platform when compared to its average 
vertical position over a corresponding time interface”.

But I guess the fundamental issue is I can’t tell (and don’t actually know) 
what heave is determined with respect to. If my last 11 positions relative to 
average seas are 0, 1, 2, 2, 1, 4, 1, 2, 2, 1, 0 (think hilly!), I have no idea 
if the heave at the peak (‘4’) is 4 or something else — it just depends on when 
and how long the baseline measurement is, doesn’t it?  (Or to put it another 
way, is the heave at the 7th point a negative number, since the ship just went 
down 3 units?)  If someone can answer that then our best definition might be 
more obvious.

John

---
John Graybeal
jbgrayb...@mindspring.com<mailto:jbgrayb...@mindspring.com>

On Jul 29, 2018, at 04:29, Lowry, Roy K. 
mailto:r...@bodc.ac.uk>> wrote:

Dear All,

Giving it some thought over the weekend I realise that where we lost the plot 
in this discussion was when we encountered 'direction of travel'. Jim 
succinctly described platform motion with the phrase 'nested co-ordinate 
systems'. What I failed to realise - and I'm guessing I'm not alone - is that 
the pitch, roll, heave etc. family of terms for platform motion refer SOLELY to 
the innermost co-ordinate reference in that nest and that the 'zero' for these 
measurements is 'platform at rest'. This innermost co-ordinate reference 
comprises three orthogonal axes that intersect at the platform's centre of 
gravity. Two of these are horizontal (Ken's longitudinal X-axis and transverse 
Y-axis) and the third vertical (Ken's vertical Z-axis). Others make no attempt 
to treat these parameters in the same way as zenith, and I now realise CF 
shouldn't be any different.

Having come to terms with this, Ken's definition elements hve a beautiful 
simplicity that can be slotted into Alison's compound definitions. My only 
problem is the inclusion of nautical terms like 'bow' and 'stern', but these 
can easily be replaced by generic equivalents such as 'front' and 'back'. I 
would also make it clearer is that zero is platform at rest.

For example the definition pair for yaw become:

platform_yaw_angle
"yaw _angle" is the amount of rotation from the rest position around the 
vertical Z-axis with positive values resulting in clockwise motion when viewed 
from above. The vertical Z axis, also known as the "yaw axis", is an imaginary 
line running vertically through the platform's centre of gravity.  Standard 
names for "platform" describe the motion and orientation of the vehicle from 
which observations are made. Platforms include, but are not limited to, 
satellites, aeroplanes, ships, instruments and buoys.

platform_yaw_rate

"platform_yaw_rate" is the change per unit time of "yaw_angle".  "yaw _angle" 
is the amount of rotation from the rest position around the vertical Z-axis 
with positive values resulting in clockwise motion when viewed from above. The 
vertical

Re: [CF-metadata] Platform Heave

[Nan Galbraith]

Hi all -

I like Ken K's definitions; simple and to the point;  And I agree that 
we need to be explicit

about positive direction (which term, by the way, doesn't google well).

I'm not sure I agree with Roy that 'zero is platform at rest' - could 
you please explain
that? By 'at rest' do we mean that no forces are operating on the 
platform? Would  a buoy
have roll and heave angles if its deck load were out of balance?  If its 
deck isn't level, what
term would describe that? I suppose you're building on the fact that 
these rotations are
relative to the internal axes of the platform, with no relation to the 
'real world'.


It does seem like we're converging ... maybe.

Cheers - Nan

-

On 7/29/18 7:29 AM, Lowry, Roy K. wrote:
 > Dear All, > > > Giving it some thought over the weekend I realise 
that where we lost > the plot in this discussion was when we encountered 
'direction of > travel'. Jim succinctly described platform motion with 
the phrase > 'nested co-ordinate systems'. What I failed to realise - 
and I'm > guessing I'm not alone - is that the pitch, roll, heave etc. 
family > of terms for platform motion refer SOLELY to the innermost > 
co-ordinate reference in that nest and that the 'zero' for these > 
measurements is 'platform at rest'. This innermost co-ordinate > 
reference comprises three orthogonal axes that intersect at the > 
platform's centre of gravity. Two of these are horizontal (Ken's > 
longitudinal X-axis and transverse Y-axis) and the third vertical > 
(Ken's vertical Z-axis). Others make no attempt to treat these > 
parameters in the same way as zenith, and I now realise CF shouldn't > 
be any different. > > > Having come to terms with this, Ken's definition 
elements have a > beautiful simplicity that can be slotted into Alison's 
compound > definitions. My only problem is the inclusion of nautical 
terms like > 'bow' and 'stern', but these can easily be replaced by 
generic > equivalents such as 'front' and 'back'. I would also make it 
clearer > is that zero is platform at rest. > > > For example the 
definition pair for yaw become: > > > platform_yaw_angle > > "yaw 
_angle" is the amount of rotation from the rest position around > the 
vertical Z-axis with positive values resulting in clockwise > motion 
when viewed from above. The vertical Z axis, also known as the > "yaw 
axis", is an imaginary line running vertically through the > platform's 
centre of gravity. Standard names for "platform" describe > the motion 
and orientation of the vehicle from which observations are > made. 
Platforms include, but are not limited to, satellites, > aeroplanes, 
ships, instruments and buoys. > > > platform_yaw_rate > > 
"platform_yaw_rate" is the change per unit time of "yaw_angle". "yaw > 
_angle" is the amount of rotation from the rest position around the > 
vertical Z-axis with positive values resulting in clockwise motion > 
when viewed from above. The vertical Z axis, also known as the "yaw > 
axis", is an imaginary line running vertically through the platform's > 
centre of gravity. Standard names for "platform" describe the motion > 
and orientation of the vehicle from which observations are made. > 
Platforms include, but are not limited to, satellites, aeroplanes, > 
ships, instruments and buoys. > > > How does that work for people? > > > 
Cheers, Roy. > > > -
From: CF-metadata on behalf of Kenneth Kehoe   > Sent: 27 July 2018 16:49 > Subject: Re: [CF-metadata] Platform Heave 
> > All, > > Sorry for joining this conversation late. This is an 
important > discussion for my group and finding a resolution would be 
very > helpful. For my purposes I only need a good definition, which 
might > coincide with the nautical definitions. For example this 
reference > <https://www.wartsila.com/encyclopedia/term/ship-motions> 
would > suffice for most of my needs except for the missing definition 
of > positive direction. I've asked about defining a positive direction 
in > the past using the "positive" attribute and it was decided to not > 
expand that attribute. If we can define the positive direction in all > 
the platform standard names that would be great, but it should be > 
universally existent for all current and future platform > definitions. 
> > I would prefer to not get into the details of how a value is 
derived > in the definition as that is more of the cell_methods domain. 
Also I > find that confusing as heave on an ocean going ship is not 
always > measured as the difference between two GPS points but could be 
an > integration of a speed or acceleration. This would result in two > 
diff

Re: [CF-metadata] Platform Heave

[John Graybeal]

ship using this e-mail address.
> 
> 
> From: CF-metadata  <mailto:cf-metadata-boun...@cgd.ucar.edu>> on behalf of Kenneth Kehoe 
> mailto:kke...@ou.edu>>
> Sent: 27 July 2018 16:49
> To: cf-metadata@cgd.ucar.edu <mailto:cf-metadata@cgd.ucar.edu>
> Subject: Re: [CF-metadata] Platform Heave
>  
> All,
> 
> Sorry for joining this conversation late. This is an important discussion for 
> my group and finding a resolution would be very helpful. For my purposes I 
> only need a good definition, which might coincide with the nautical 
> definitions. For example this reference 
> <https://www.wartsila.com/encyclopedia/term/ship-motions> would suffice for 
> most of my needs except for the missing definition of positive direction. 
> I've asked about defining a positive direction in the past using the 
> "positive" attribute and it was decided to not expand that attribute. If we 
> can define the positive direction in all the platform standard names that 
> would be great, but it should be universally existent for all current and 
> future platform definitions.
> 
> I would prefer to not get into the details of how a value is derived in the 
> definition as that is more of the cell_methods domain. Also I find that 
> confusing as heave on an ocean going ship is not always measured as the 
> difference between two GPS points but could be an integration of a speed or 
> acceleration. This would result in two different measurements that depend on 
> the method, but both are correct.
> 
> I next attempted to come up with some definitions but I ended up going down a 
> wormhole of different reference frames only to realize in the end my 
> definitions will never match with the values from the vendor supplied data 
> values because my definitions were becoming too specific. I can't find a 
> definition of heave that takes into account tides, large waves (water or 
> atmospheric), or orientation of the platform. They all seem to be relative to 
> the platform position some x time ago. So here is my attempt at the 
> definitions:
> 
> platform_heave =  Heave is the linear motion along the vertical Z-axis (e.g. 
> keel to top of mast) with positive values representing upward motion.
> 
> platform_sway = Sway is the motion along the transverse Y-axis (e.g. port to 
> starboard) with positive values towards the right-hand side the platform 
> (starboard) when oriented towards leading edge of the platform.
> 
> platform_surge = Surge is the motion along the longitudinal X-axis (e.g. 
> stern to bow) with positive values indicating motion towards the leading edge 
> of the platform (bow).
> 
> platform_roll_angle = Roll is a rotation around a longitudinal X-axis with 
> positive values resulting in counter clockwise motion (e.g. right-hand side 
> rising) when oriented towards leading edge of the platform.
> 
> platform_pitch_angle = Pitch is a rotation around the transverse Y-axis with 
> positive values resulting in counter clockwise motion (e.g. leading edge of 
> the platform rising).
> 
> platform_yaw_angle = Yaw is a rotation around the vertical Z-axis with 
> positive values resulting in clockwise motion of the forward section (bow) 
> when viewed from above.
> 
> platform_roll_rate = Roll rate is rotation change per unit time around a 
> longitudinal X-axis with positive values resulting in counter clockwise 
> motion (e.g. right-hand side rising) when oriented towards leading edge of 
> the platform.
> 
> platform_pitch_rate = Pitch rate is rotation change per unit time around the 
> transverse Y-axis with positive values resulting in counter clockwise motion 
> (e.g. leading edge of the platform rising).
> 
> platform_yaw_rate = Yaw rate is rotation change per unit time around the 
> vertical Z-axis with positive values resulting in clockwise motion of the 
> forward section (bow) when viewed from above.
> 
> I know these differ from the current definitions, but I'm not completely 
> understanding how the definitions are created. Is platform_orientation always 
> prepended? Is a rate always defined with the same as the angle definition but 
> with a final sentence explaining it's actually a rate?
> 
> Thanks,
> 
> Ken
> 
> 
> 
> On 2018-7-25 09:50, Jim Biard wrote:
>> Alison,
>> It's a lovely nested reference frames problem, isn't it? Roll, pitch, and 
>> yaw are usually defined relative to a center of motion (CM) reference frame 
>> defined using the (mean) direction of motion and the up direction. In my 
>> (satellite-based) experience, the Y axis unit vector is defined by the 
>> normalized cross-product of the up unit vector with the direction of motion 
>> unit vector (Z x X). The X axi

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear All,


Giving it some thought over the weekend I realise that where we lost the plot 
in this discussion was when we encountered 'direction of travel'. Jim 
succinctly described platform motion with the phrase 'nested co-ordinate 
systems'. What I failed to realise - and I'm guessing I'm not alone - is that 
the pitch, roll, heave etc. family of terms for platform motion refer SOLELY to 
the innermost co-ordinate reference in that nest and that the 'zero' for these 
measurements is 'platform at rest'. This innermost co-ordinate reference 
comprises three orthogonal axes that intersect at the platform's centre of 
gravity. Two of these are horizontal (Ken's longitudinal X-axis and transverse 
Y-axis) and the third vertical (Ken's vertical Z-axis). Others make no attempt 
to treat these parameters in the same way as zenith, and I now realise CF 
shouldn't be any different.


Having come to terms with this, Ken's definition elements hve a beautiful 
simplicity that can be slotted into Alison's compound definitions. My only 
problem is the inclusion of nautical terms like 'bow' and 'stern', but these 
can easily be replaced by generic equivalents such as 'front' and 'back'. I 
would also make it clearer is that zero is platform at rest.


For example the definition pair for yaw become:


platform_yaw_angle

"yaw _angle" is the amount of rotation from the rest position around the 
vertical Z-axis with positive values resulting in clockwise motion when viewed 
from above. The vertical Z axis, also known as the "yaw axis", is an imaginary 
line running vertically through the platform's centre of gravity.  Standard 
names for "platform" describe the motion and orientation of the vehicle from 
which observations are made. Platforms include, but are not limited to, 
satellites, aeroplanes, ships, instruments and buoys.

platform_yaw_rate

"platform_yaw_rate" is the change per unit time of "yaw_angle".  "yaw _angle" 
is the amount of rotation from the rest position around the vertical Z-axis 
with positive values resulting in clockwise motion when viewed from above. The 
vertical Z axis, also known as the "yaw axis", is an imaginary line running 
vertically through the platform's centre of gravity.  Standard names for 
"platform" describe the motion and orientation of the vehicle from which 
observations are made. Platforms include, but are not limited to, satellites, 
aeroplanes, ships, instruments and buoys.


How does that work for people?


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Kenneth Kehoe 

Sent: 27 July 2018 16:49
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

All,

Sorry for joining this conversation late. This is an important discussion for 
my group and finding a resolution would be very helpful. For my purposes I only 
need a good definition, which might coincide with the nautical definitions. For 
example this reference<https://www.wartsila.com/encyclopedia/term/ship-motions> 
would suffice for most of my needs except for the missing definition of 
positive direction. I've asked about defining a positive direction in the past 
using the "positive" attribute and it was decided to not expand that attribute. 
If we can define the positive direction in all the platform standard names that 
would be great, but it should be universally existent for all current and 
future platform definitions.

I would prefer to not get into the details of how a value is derived in the 
definition as that is more of the cell_methods domain. Also I find that 
confusing as heave on an ocean going ship is not always measured as the 
difference between two GPS points but could be an integration of a speed or 
acceleration. This would result in two different measurements that depend on 
the method, but both are correct.

I next attempted to come up with some definitions but I ended up going down a 
wormhole of different reference frames only to realize in the end my 
definitions will never match with the values from the vendor supplied data 
values because my definitions were becoming too specific. I can't find a 
definition of heave that takes into account tides, large waves (water or 
atmospheric), or orientation of the platform. They all seem to be relative to 
the platform position some x time ago. So here is my attempt at the definitions:

platform_heave =  Heave is the linear motion along the vertical Z-axis (e.g. 
keel to top of mast) with positive values representing upward motion.

platform_sway = Sway is the motion along the transverse Y-axis (e.g. port to 
starboard) with positive values towards the right-hand side the platform 
(starboard) when oriented towards leading edge of the platform.

platform_surge = Surge is the motion along the lon

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Ken,


We're in the same business with exactly the same data streams, although I've 
never dealt with sway and surge. Your reference and your definitions neatly 
sidestep the issue that has dominated the discussions to date, which is the 
semantics of the zero value. Pitch and roll are easy for ships - zero is 
horizontal. Heave is a little more tricky - zero is the position of the ship 
would occupy if it wasn't moving.


Yaw has become more of a minefield because 'direction of travel' has crept into 
some definitions and data sets are starting to appear that contain the compass 
bearing towards which the bow points instantaneously (something I'd call 
heading + yaw). For ships, direction of travel could be interpreted as course 
made good, which isn't the same thing as heading - my preferred zero for yaw - 
as it's influenced by water body motion. Discussion over the past couple of 
days has been aimed at eliminating this ambiguity. Remember what's obvious to a 
seafarer is alien to a satellite operator and in CF we're trying to establish 
cross-domain understanding.


Jim concerns me a little, but providing nothing he proposes invalidates the 
classic nautical understanding of these terms then we could end up with 
something that not only works for the marine community, but also for aircraft 
and satellites.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Kenneth Kehoe 

Sent: 27 July 2018 16:49
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

All,

Sorry for joining this conversation late. This is an important discussion for 
my group and finding a resolution would be very helpful. For my purposes I only 
need a good definition, which might coincide with the nautical definitions. For 
example this reference<https://www.wartsila.com/encyclopedia/term/ship-motions> 
would suffice for most of my needs except for the missing definition of 
positive direction. I've asked about defining a positive direction in the past 
using the "positive" attribute and it was decided to not expand that attribute. 
If we can define the positive direction in all the platform standard names that 
would be great, but it should be universally existent for all current and 
future platform definitions.

I would prefer to not get into the details of how a value is derived in the 
definition as that is more of the cell_methods domain. Also I find that 
confusing as heave on an ocean going ship is not always measured as the 
difference between two GPS points but could be an integration of a speed or 
acceleration. This would result in two different measurements that depend on 
the method, but both are correct.

I next attempted to come up with some definitions but I ended up going down a 
wormhole of different reference frames only to realize in the end my 
definitions will never match with the values from the vendor supplied data 
values because my definitions were becoming too specific. I can't find a 
definition of heave that takes into account tides, large waves (water or 
atmospheric), or orientation of the platform. They all seem to be relative to 
the platform position some x time ago. So here is my attempt at the definitions:

platform_heave =  Heave is the linear motion along the vertical Z-axis (e.g. 
keel to top of mast) with positive values representing upward motion.

platform_sway = Sway is the motion along the transverse Y-axis (e.g. port to 
starboard) with positive values towards the right-hand side the platform 
(starboard) when oriented towards leading edge of the platform.

platform_surge = Surge is the motion along the longitudinal X-axis (e.g. stern 
to bow) with positive values indicating motion towards the leading edge of the 
platform (bow).

platform_roll_angle = Roll is a rotation around a longitudinal X-axis with 
positive values resulting in counter clockwise motion (e.g. right-hand side 
rising) when oriented towards leading edge of the platform.

platform_pitch_angle = Pitch is a rotation around the transverse Y-axis with 
positive values resulting in counter clockwise motion (e.g. leading edge of the 
platform rising).

platform_yaw_angle = Yaw is a rotation around the vertical Z-axis with positive 
values resulting in clockwise motion of the forward section (bow) when viewed 
from above.

platform_roll_rate = Roll rate is rotation change per unit time around a 
longitudinal X-axis with positive values resulting in counter clockwise motion 
(e.g. right-hand side rising) when oriented towards leading edge of the 
platform.

platform_pitch_rate = Pitch rate is rotation change per unit time around the 
transverse Y-axis with positive values resulting in counter clockwise motion 
(e.g. leading edge of the platform rising).

platform_yaw_rate = Yaw rate is rotation change per unit time around the 
vertical Z-axis with

Re: [CF-metadata] Platform Heave

[Kenneth Kehoe]

 (and a bit with airplanes).


Grace and peace,

Jim


On 7/25/18 9:37 AM, Alison Pamment - UKRI STFC wrote:

Hi Roy and Jim,

Thanks for your quick comments on the definitions. I have just been looking 
again at the suggested text for yaw_angle:
'Platform yaw angle is the angle between the platform's longitudinal/X axis and 
the direction of travel. Zero yaw angle means the longitudinal axis is aligned 
with the direction of travel, or a reference direction if the platform is 
stationary. The usual sign convention is that yaw angle is measured positive 
when the front or leading edge of the platform is rotated clockwise from its 
orientation (which has the standard name platform_orientation).'

The problem is how to describe the reference direction which the angle is calculated 
relative to. I started out by talking about 'direction of travel' and later referred to 
'platform_orientation'. The definition of platform_orientation says 'The platform 
orientation is the direction in which the "front" or longitudinal axis of the 
platform is pointing (not necessarily the same as the direction in which it is 
travelling, called platform_course).' I've realised my new definition doesn't really make 
sense if direction of travel and orientation aren't the same (and clearly they can be 
different). Also, if 'orientation' is the instantaneous direction of the longitudinal 
axis, then presumably it includes yaw angle, so it isn't the right reference for 
measuring yaw.

I've revised the text as follows:
'Platform yaw angle is the angle between the platform's longitudinal/X axis and 
the platform's mean orientation (i.e. its orientation not including high 
frequency variations due to swaying and rocking motions, for example, ship 
motions caused by the passing of sea surface waves). Zero yaw angle means the 
longitudinal axis is aligned with the mean orientation. The usual sign 
convention is that yaw angle is measured positive when the front or leading 
edge of the platform is rotated clockwise from its mean orientation (which has 
the standard name platform_orientation).

Does it sound okay to refer to a 'mean orientation' in this way? I'm having 
trouble thinking of a better wording!

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail:alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

-Original Message-
From: CF-metadata  On Behalf Of Alison 
Pamment - UKRI STFC
Sent: 25 July 2018 13:12
To: Hamilton, Steve;cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Dear Steve, Nan, et al,

Thank you for proposing new standard names for platform_heave and improved 
definitions for existing names for platform pitch, roll and yaw. Thank you also 
to all those who submitted comments about these names.

Regarding Steve's proposals for new names, the discussion seems to have reached 
consensus on the quantities themselves.

Until now, our usual explanatory sentence for 'platform' has said 'Standard 
names for platform describe the motion and orientation of the vehicle from 
which observations are made e.g. aeroplane, ship or satellite.' Nan has 
suggested extending the list of possible platforms, which seems fair enough, so 
we would now have 'Standard names for platform describe the motion and 
orientation of the vehicle from which observations are made. Platforms include, 
but are not limited to, satellites, aeroplanes, ships, instruments, and buoys.' 
I've added this into the definitions of Steve's names, leading to:

platform_heave (m)
'Standard names for "platform" describe the motion and orientation of the vehicle from 
which observations are made. Platforms include, but are not limited to, satellites, aeroplanes, 
ships, instruments, and buoys. "Heave" means the vertical displacement of a platform 
(positive upwards) over a measurement time interval.'

platform_heave_rate (m s-1)
'Standard names for "platform" describe the motion and orientation of the vehicle from which 
observations are made. Platforms include, but are not limited to, satellites, aeroplanes, ships, instruments, 
and buoys "Heave" means the vertical displacement of a platform (positive upwards) over a 
measurement time interval. "Heave rate" means the rate of change of vertical displacement of the 
platform over a measurement time interval.'

These two names are accepted for publication in the standard name table and 
will be added in the next update, planned for 6th August.

We have six existing platform pitch, roll and yaw names:
platform_pitch_angle (degree)
platform_pitch_rate (degree s-1)
platform_roll_angle (degree)
platform_roll_rate (degree s-1)
platform_yaw_angle (degree)
platform_yaw_rate (degree s-1)

Nan has suggested the following definitions, based 
onhttps://en.wikipedia.org/wiki/Ship_motions. (A quick s

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Jim,


If you can make clear suggestions that make the existing Standard Names more 
widely applicable without the need to rework legacy data that have been 
labelled with these Standard Names then that is obviously beneficial.  However, 
please do this by quoting concrete alternative definitions so that we can all 
understand where you are proposing we go from where we currently are.


BTW if you look at my last reply to Nan then you'll see that the wisdom of 
coupling the platform_orientation Standard Name into the definition of yaw has 
already been questioned.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 26 July 2018 20:05
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Roy,


I'm just trying to lay out the scope of the challenge to see if we can avoid 
defining terms in ways that require us to have ship_yaw as a different term 
than satellite_yaw, for example. I appreciate that the marine community has a 
long history (longer than the aerospace communities) with these terms. All the 
same, it seems to me that we should be able to define basic terms such as 
pitch, roll, and yaw (and maybe surge, sway, and heave as well) in terms that 
are usable by all. As an example, using platform_orientation in the definition 
of platform_yaw renders the term quasi-meaningless for platforms that require 
more than one quantity to define the transform between the platform body 
reference system and its motion reference system. Using platform_course in 
these definitions has a similar limiting effect for platforms that require more 
and/or different terms to define their motion reference frames.


Maybe it's not possible to find a happy medium, but I'm hoping to do so. I'll 
suggest some standard name definitions of my own shortly.


Grace and peace,


Jim

On 7/26/18 2:46 PM, Lowry, Roy K. wrote:

Dear Jim,


I think the problem is that the 'platform' standard names have been developed 
by a community versed in the ship/aircraft/buoy and to a lesser extent 
submarine/glider use cases (i.e. those with which you are least familiar) and 
we're now talking as if they should be totally generic.


The one thing I understand in your e-mail (most of it is gobbledy-gook to me as 
an observational oceanographer) is that there are different kinds of platforms 
with different degrees of freedom and their own terminology. For example, 
pitch, roll and yaw are not (hopefully!) concepts applicable to a fixed oil rig.


These data streams have been returned by our primary platforms (research 
vessels) for decades - e.g. heading that CF decided to name 
platform_orientation - has been in every research vessel navigation file that 
I've handled from the late 1980s to around 2005. There is usually also speed 
through the water, latitiude, longitude, speed made good (speed over the 
seabed), course made good, velocity north over seabed and velocity east over 
seabed. Some also include pitch, roll and yaw. You cannot suddenly decide that 
the data of decades should be transformed into an idealised generic co-ordinate 
reference system for CF.


My view is that realistically an all-encompassing, totally generic solution 
should be confined to the 'too hard' basket and that we should define the 
standard names based on use cases of known data streams. Consideration then 
would then need to be given to data streams outside the original scope as to 
whether the existing Standard Names are appropriate or new Standard Names are 
required.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Jim Biard <mailto:jbi...@cicsnc.org>
Sent: 26 July 2018 18:25
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave


Alison, Roy,

I don't mean to be difficult, but I think that for greatest generality the 
"motion and orientation" of a platform pretty much has to be relative to a 
reference frame that depends only on the translational motion (if any) of the 
platform. When I look more closely at the definitions we have now, I also see 
that platform_course and platform_orientation are insufficient for the 
satellite case, and don't quite cover the airborne case. The full set of 
elements needed to define a point on a platform in its internal frame in terms 
of an earth-based reference frame are:

  *   Oim = Vector that describes the baseline offset of the origin of the 
platform's internal reference frame relative to the platform's motion frame.
  *   Mim = Matrix that describes the baseline rotation of the platform's 
internal reference frame relative to the platform's motion frame.
  *   Mrpy = Matrix

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Jim,


I think the problem is that the 'platform' standard names have been developed 
by a community versed in the ship/aircraft/buoy and to a lesser extent 
submarine/glider use cases (i.e. those with which you are least familiar) and 
we're now talking as if they should be totally generic.


The one thing I understand in your e-mail (most of it is gobbledy-gook to me as 
an observational oceanographer) is that there are different kinds of platforms 
with different degrees of freedom and their own terminology. For example, 
pitch, roll and yaw are not (hopefully!) concepts applicable to a fixed oil rig.


These data streams have been returned by our primary platforms (research 
vessels) for decades - e.g. heading that CF decided to name 
platform_orientation - has been in every research vessel navigation file that 
I've handled from the late 1980s to around 2005. There is usually also speed 
through the water, latitiude, longitude, speed made good (speed over the 
seabed), course made good, velocity north over seabed and velocity east over 
seabed. Some also include pitch, roll and yaw. You cannot suddenly decide that 
the data of decades should be transformed into an idealised generic co-ordinate 
reference system for CF.


My view is that realistically an all-encompassing, totally generic solution 
should be confined to the 'too hard' basket and that we should define the 
standard names based on use cases of known data streams. Consideration then 
would then need to be given to data streams outside the original scope as to 
whether the existing Standard Names are appropriate or new Standard Names are 
required.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 26 July 2018 18:25
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Alison, Roy,

I don't mean to be difficult, but I think that for greatest generality the 
"motion and orientation" of a platform pretty much has to be relative to a 
reference frame that depends only on the translational motion (if any) of the 
platform. When I look more closely at the definitions we have now, I also see 
that platform_course and platform_orientation are insufficient for the 
satellite case, and don't quite cover the airborne case. The full set of 
elements needed to define a point on a platform in its internal frame in terms 
of an earth-based reference frame are:

  *   Oim = Vector that describes the baseline offset of the origin of the 
platform's internal reference frame relative to the platform's motion frame.
  *   Mim = Matrix that describes the baseline rotation of the platform's 
internal reference frame relative to the platform's motion frame.
  *   Mrpy = Matrix that describes non-baseline roll, pitch, and yaw of the 
platform relative to the platform's motion frame.
  *   Ossh = Vector that describes non-baseline surge, sway, and heave of the 
platform relative to the platform's motion frame.
  *   Ome = Vector that describes the offset of the origin of the platform's 
motion frame relative to an earth-based reference frame.
  *   Mme = Matrix that describes the rotation of the platform's motion frame 
relative to an earth-based reference frame.

The motion frame is fixed to the baseline platform center of mass. So the full 
equation is:
Pe = Ome + Mme(Ossh + Mrpy(Oim + Mim(Pi)))

where Pi is a point on the platform in its internal reference frame and Pe is a 
point on the platform in an earth-based reference frame. There's a total of 18 
terms (3 per vector or matrix) that may be needed to define the 
platform-to-earth transformation. Oim and Mim are almost always static, so that 
leaves up to 12 dynamic terms needed to define the others.

Here's a stab at how these vary for different kinds of platforms.

Satellites:

Mim sometimes includes a 180 degree baseline roll angle and a possible 90 
degree baseline yaw. Ossh is usually merged with Ome. Mme is defined using the 
satellite's velocity vector in the earth reference frame to produce a reference 
frame that has its Z unit vector pointing away from the earth, its X unit 
vector tangent to the orbit, and its Y unit vector transverse to the orbit at 
any given moment. This gives us a minimum of 9 dynamic terms (roll, pitch, yaw, 
Vx, Vy, Vz, X, Y, Z) and a Mim matrix that can't be defined by a single 
platform_orientation angle.

Airplanes (& submarines?):

I don't have as much experience with this one. In my limited experience: Mim 
might require up to three angles. Ome is defined using X/Y/altitude. Mme is 
defined using the heading angle to produce a reference frame that has its Z 
unit vector pointing away from the earth's surface, its Y and X unit vectors 
parallel to the earth's surface, and its X unit vector pointing in the 
direction of the platform_course at any given moment. This give

Re: [CF-metadata] Platform Heave

[Jim Biard]

vehicle from which 
observations are made. Platforms include, but are not limited to, satellites, aeroplanes, ships, instruments 
and buoys. "Yaw" means rotation of the platform in the horizontal plane about its vertical/Z axis. 
The vertical/Z axis, also known as the "yaw axis", is an imaginary line running vertically through 
the platform and through its center of gravity. In yaw motion, the platform rotates clockwise or counter 
clockwise in the horizontal, relative to its orientation, which has the standard name platform_orientation. 
Platform yaw angle is the angle at a given instant between the platform's longitudinal/X axis and the 
position of that axis with high frequency variations (e.g. the effect of surface waves on a ship) removed. 
Zero yaw angle means the longitudinal axis is aligned with the platform_orientation. The usual sign 
convention is that yaw angle is measured positive when the front or leading
  edge of the platform is rotated clockwise from the platform_orientation.'


Okay?


Like Roy, I had wondered whether 'platform_orientation' should really be an 
instantaneous quantity or something with high frequency variability removed. If 
it is the latter (which I think was probably the original intention of the 
standard name) then we should amend the definition as follows:

'Standard names for "platform" describe the motion and orientation of the vehicle from 
which observations are made. Platforms include, but are not limited to, satellites, aeroplanes, 
ships, instruments and buoys. The platform orientation is the direction in which the 
"front" or longitudinal axis of the platform is pointing with high frequency variations 
(e.g. the effect of surface waves on a ship) removed. (This is not necessarily the same as the 
direction in which the platform is travelling, called platform_course).'


Okay?


As an additional point, I note that besides the names already discussed in this 
thread, there are a further 11 existing platform names. I will include the new 
text for 'platform' in their definitions as part of the August standard names 
update.


Best wishes,

Alison


From: Lowry, Roy K. 
Sent: 25 July 2018 16:35:27
To: Pamment, Alison (STFC,RAL,RALSP); cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Hi again,


This is an area where it is easy to get tied up in knots because there are 
multiple reference frames. If we talk ships then there is the 
platform_orientation (or heading) which is measured using a gyro-compass - a 
stabilised instrument that eliminates high-frequency variations in where the 
bow is actually pointing and provides the zero reference point for yaw.


The concept of 'travel' relates to another reference frame external to the 
platform - say a GPS CRS  - but yaw only has relevance to the platform's 
internal reference frame. So you are right that bringing 'direction of travel' 
into a definition of yaw is a bad thing even though it's reasonably common 
practice to do so.


Mean orientation is also possibly best avoided as the platform_orientation 
isn't necessarily determined by averaging instantaneous longitudinal axis 
orientations.  It could be - and often is - measured by something that has 
greater inertia than the platform.


So how about using :


Platform yaw angle is the angle at a given instant between the platform's 
longitudinal/X axis and the position of that axis with high frequency 
variations (e.g. the effect of surface waves on a ship) removed. Zero yaw angle 
means the longitudinal axis is aligned with the platform_orientation. The usual 
sign convention is that yaw angle is measured positive when the front or 
leading edge of the platform is rotated clockwise from the platform_orientation.


This raises the question as to whether the platform_orientation definition 
should have the clarification 'with high-frequency variability removed' added. 
This would be an explicit statement of what - to me at least - is commonly 
understood meaning of 'heading'.


Does that help?


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Alison Pamment - 
UKRI STFC 
Sent: 25 July 2018 14:37
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Roy and Jim,

Thanks for your quick comments on the definitions. I have just been looking 
again at the suggested text for yaw_angle:
'Platform yaw angle is the angle between the platform's longitudinal/X axis and 
the direction of travel. Zero yaw angle means the longitudinal axis is aligned 
with the direction of travel, or a reference direction if the platform is 
stationary. The usual sign convention is that yaw angle is measured positive 
when the front or leading edge of the platform is rotated clockwise from its 
orientation (which has the standard name platfor

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Nan,


I think your suggestion for changing the order of the components of the 
definitions is a good one. I also agree that making the yaw angle sign 
convention totally unambiguous is an improvement.


However,  your yaw definition leaves open the Devil's Advocate argument that if 
the platform rotates around its vertical axis then its orientation changes by 
the amount that the platform has rotated. So how can the yaw be measured 
relative to something that has also changed?  We both know how it works for 
ships with the inertia of the gyrocompass, but how does one put that into words 
so that it covers all the things that we want to label 'platform'?


That is what I was attempting to do by considering yaw as a high-frequency 
variance in where the platform is pointing and platform orientation as its 
smoothed equivalent. Could using the word 'smoothed' be our get-out clause 
here? It covers both inertial measurement and averaging. If 'In yaw motion, the 
platform rotates

horizontally relative to its orientation' were replaced by 'In yaw motion, the 
platform rotates
horizontally relative to its smoothed orientation' then my objection abates.

That leaves us with the vexed question about what to do about the current 
Standard Name platform_orientation. You would like it to cover both undamped 
compass and gyrocompass orientations.  I can see the argument for this within 
CF philosophy which would dictate a cell method be used to distinguish smoothed 
and unsmoothed orientations. However, if we do that then the reference to the 
platform_orientation Standard Name has to be removed from the yaw_angle 
definition as you can't define against something that is ambiguous.

That would change the yaw_angle definition to:

Platform_yaw_angle is the rotation of a platform in the horizontal plane about 
its vertical/Z axis. This axis, also known as the "yaw axis", runs vertically 
through the center of gravity of the platform. In yaw motion, the platform 
rotates horizontally relative to its smoothed orientation Yaw angle is measured 
positive clockwise from that smoothed orientation. Standard names for 
"platform" describe the motion and orientation of the vehicle from which 
observations are made. Platforms include, but are not limited to, satellites, 
aeroplanes, ships, instruments and buoys.


and the existing platform_orientation Standard Name can be left asis to cover 
both smoothed and unsmoothed values.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Nan Galbraith 

Sent: 26 July 2018 14:34
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Hi all -

Thank you, Alison and all, this is really good. I haven't looked through
all the
current versions of the definitions yet but I hope to do that shortly.

I think the proposed yaw definition may be a bit too detailed; getting into
details like the removal of high frequency variations seems unnecessary
(and
maybe counter productive). Could we consider something simpler? (see below,
please)

Second, would it be possible to turn all these definitions around so
that the
definition of the concept is at the start, and the term platform comes
at the
end?  That would make it much more efficient when people are looking for
the standard name at cf-standard-name-table.html.

And last, could we specify that the yaw angle value (though not the motion
itself) is clockwise? A phrase like 'usual sign convention' might lead
to confusion
interpreting the values, or require extra attributes to clarify.

If that's all acceptable, platform_yaw_angle would be:

"platform_yaw_angle is the rotation of a platform in the horizontal
plane about its
vertical/Z axis. This axis, also known as the "yaw axis", runs
vertically through the
center of gravity of the platform. In yaw motion, the platform rotates
horizontally
relative to its orientation, which has the standard name
platform_orientation. Yaw
angle is measured positive clockwise from platform_orientation. Standard
names
for "platform" describe the motion and orientation of the vehicle from
which observations
are made. Platforms include, but are not limited to, satellites,
aeroplanes, ships,
instruments and buoys."

Thanks again -
Nan


On 7/25/18 12:34 PM, Alison Pamment - UKRI STFC wrote:
> Dear Roy and Jim,
>
>
> Thanks again both for your help.
>
>
> Both your replies are saying that referring to direction of motion for 
> measuring yaw is a bad idea, and in any case it doesn't apply to stationary 
> platforms (which presumably have some means of determining their own 
> orientation relative to concepts such as 'up', 'north', etc.)  You are both 
> advising against saying 'mean orientation' and I agree that it's not really a 
> well-defined concept.
>
>
> I 

Re: [CF-metadata] Platform Heave

[Nan Galbraith]

 orientation of 
the vehicle from which observations are made. Platforms include, but 
are not limited to, satellites, aeroplanes, ships, instruments and 
buoys. The platform orientation is the direction in which the "front" 
or longitudinal axis of the platform is pointing with high frequency 
variations (e.g. the effect of surface waves on a ship) removed. 
(This is not necessarily the same as the direction in which the 
platform is travelling, called platform_course).'



Okay?


As an additional point, I note that besides the names already 
discussed in this thread, there are a further 11 existing platform 
names. I will include the new text for 'platform' in their 
definitions as part of the August standard names update.



Best wishes,

Alison


From: Lowry, Roy K. 
Sent: 25 July 2018 16:35:27
To: Pamment, Alison (STFC,RAL,RALSP); cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Hi again,


This is an area where it is easy to get tied up in knots because 
there are multiple reference frames. If we talk ships then there is 
the platform_orientation (or heading) which is measured using a 
gyro-compass - a stabilised instrument that eliminates high-frequency 
variations in where the bow is actually pointing and provides the 
zero reference point for yaw.



The concept of 'travel' relates to another reference frame external 
to the platform - say a GPS CRS  - but yaw only has relevance to the 
platform's internal reference frame. So you are right that bringing 
'direction of travel' into a definition of yaw is a bad thing even 
though it's reasonably common practice to do so.



Mean orientation is also possibly best avoided as the 
platform_orientation isn't necessarily determined by averaging 
instantaneous longitudinal axis orientations.  It could be - and 
often is - measured by something that has greater inertia than the 
platform.



So how about using :


Platform yaw angle is the angle at a given instant between the 
platform's longitudinal/X axis and the position of that axis with 
high frequency variations (e.g. the effect of surface waves on a 
ship) removed. Zero yaw angle means the longitudinal axis is aligned 
with the platform_orientation. The usual sign convention is that yaw 
angle is measured positive when the front or leading edge of the 
platform is rotated clockwise from the platform_orientation.



This raises the question as to whether the platform_orientation 
definition should have the clarification 'with high-frequency 
variability removed' added. This would be an explicit statement of 
what - to me at least - is commonly understood meaning of 'heading'.



Does that help?


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.




From: CF-metadata  on behalf of 
Alison Pamment - UKRI STFC 

Sent: 25 July 2018 14:37
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Roy and Jim,

Thanks for your quick comments on the definitions. I have just been 
looking again at the suggested text for yaw_angle:
'Platform yaw angle is the angle between the platform's 
longitudinal/X axis and the direction of travel. Zero yaw angle means 
the longitudinal axis is aligned with the direction of travel, or a 
reference direction if the platform is stationary. The usual sign 
convention is that yaw angle is measured positive when the front or 
leading edge of the platform is rotated clockwise from its 
orientation (which has the standard name platform_orientation).'


The problem is how to describe the reference direction which the 
angle is calculated relative to. I started out by talking about 
'direction of travel' and later referred to 'platform_orientation'. 
The definition of platform_orientation says 'The platform orientation 
is the direction in which the "front" or longitudinal axis of the 
platform is pointing (not necessarily the same as the direction in 
which it is travelling, called platform_course).' I've realised my 
new definition doesn't really make sense if direction of travel and 
orientation aren't the same (and clearly they can be different). 
Also, if 'orientation' is the instantaneous direction of the 
longitudinal axis, then presumably it includes yaw angle, so it isn't 
the right reference for measuring yaw.


I've revised the text as follows:
'Platform yaw angle is the angle between the platform's 
longitudinal/X axis and the platform's mean orientation (i.e. its 
orientation not including high frequency variations due to swaying 
and rocking motions, for example, ship motions caused by the passing 
of sea surface waves). Zero yaw angle means the longitudinal axis is 
aligned with the mean orientation. The usual sign convention is that 
yaw angle is measured positive when the front or leading edge of the 
platform is rotated clockwise from its mean orientation (which has 
the standar

Re: [CF-metadata] Platform Heave

[Nan Galbraith]

Hi all -

Thank you, Alison and all, this is really good. I haven't looked through 
all the

current versions of the definitions yet but I hope to do that shortly.

I think the proposed yaw definition may be a bit too detailed; getting into
details like the removal of high frequency variations seems unnecessary 
(and

maybe counter productive). Could we consider something simpler? (see below,
please)

Second, would it be possible to turn all these definitions around so 
that the
definition of the concept is at the start, and the term platform comes 
at the

end?  That would make it much more efficient when people are looking for
the standard name at cf-standard-name-table.html.

And last, could we specify that the yaw angle value (though not the motion
itself) is clockwise? A phrase like 'usual sign convention' might lead 
to confusion

interpreting the values, or require extra attributes to clarify.

If that's all acceptable, platform_yaw_angle would be:

"platform_yaw_angle is the rotation of a platform in the horizontal 
plane about its
vertical/Z axis. This axis, also known as the "yaw axis", runs 
vertically through the
center of gravity of the platform. In yaw motion, the platform rotates 
horizontally
relative to its orientation, which has the standard name 
platform_orientation. Yaw
angle is measured positive clockwise from platform_orientation. Standard 
names
for "platform" describe the motion and orientation of the vehicle from 
which observations
are made. Platforms include, but are not limited to, satellites, 
aeroplanes, ships,

instruments and buoys."

Thanks again -
Nan


On 7/25/18 12:34 PM, Alison Pamment - UKRI STFC wrote:

Dear Roy and Jim,


Thanks again both for your help.


Both your replies are saying that referring to direction of motion for 
measuring yaw is a bad idea, and in any case it doesn't apply to stationary 
platforms (which presumably have some means of determining their own 
orientation relative to concepts such as 'up', 'north', etc.)  You are both 
advising against saying 'mean orientation' and I agree that it's not really a 
well-defined concept.


I like Roy's suggested text which refers to the platform's own axis to define 
yaw. So the full definition of platform_yaw_angle would be:

'Standard names for "platform" describe the motion and orientation of the vehicle from which 
observations are made. Platforms include, but are not limited to, satellites, aeroplanes, ships, instruments 
and buoys. "Yaw" means rotation of the platform in the horizontal plane about its vertical/Z axis. 
The vertical/Z axis, also known as the "yaw axis", is an imaginary line running vertically through 
the platform and through its center of gravity. In yaw motion, the platform rotates clockwise or counter 
clockwise in the horizontal, relative to its orientation, which has the standard name platform_orientation. 
Platform yaw angle is the angle at a given instant between the platform's longitudinal/X axis and the 
position of that axis with high frequency variations (e.g. the effect of surface waves on a ship) removed. 
Zero yaw angle means the longitudinal axis is aligned with the platform_orientation. The usual sign 
convention is that yaw angle is measured positive when the front or
  leading
  edge of the platform is rotated clockwise from the platform_orientation.'


Okay?


Like Roy, I had wondered whether 'platform_orientation' should really be an 
instantaneous quantity or something with high frequency variability removed. If 
it is the latter (which I think was probably the original intention of the 
standard name) then we should amend the definition as follows:

'Standard names for "platform" describe the motion and orientation of the vehicle from 
which observations are made. Platforms include, but are not limited to, satellites, aeroplanes, 
ships, instruments and buoys. The platform orientation is the direction in which the 
"front" or longitudinal axis of the platform is pointing with high frequency variations 
(e.g. the effect of surface waves on a ship) removed. (This is not necessarily the same as the 
direction in which the platform is travelling, called platform_course).'


Okay?


As an additional point, I note that besides the names already discussed in this 
thread, there are a further 11 existing platform names. I will include the new 
text for 'platform' in their definitions as part of the August standard names 
update.


Best wishes,

Alison


From: Lowry, Roy K. 
Sent: 25 July 2018 16:35:27
To: Pamment, Alison (STFC,RAL,RALSP); cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Hi again,


This is an area where it is easy to get tied up in knots because there are 
multiple reference frames. If we talk ships then there is the 
platform_orientation (or heading) which is measured using a gyro-compass - a 
stabilised instrument 

Re: [CF-metadata] Platform Heave

[Alison Pamment - UKRI STFC]

Dear Roy and Jim,


Thanks again both for your help.


Both your replies are saying that referring to direction of motion for 
measuring yaw is a bad idea, and in any case it doesn't apply to stationary 
platforms (which presumably have some means of determining their own 
orientation relative to concepts such as 'up', 'north', etc.)  You are both 
advising against saying 'mean orientation' and I agree that it's not really a 
well-defined concept.


I like Roy's suggested text which refers to the platform's own axis to define 
yaw. So the full definition of platform_yaw_angle would be:

'Standard names for "platform" describe the motion and orientation of the 
vehicle from which observations are made. Platforms include, but are not 
limited to, satellites, aeroplanes, ships, instruments and buoys. "Yaw" means 
rotation of the platform in the horizontal plane about its vertical/Z axis. The 
vertical/Z axis, also known as the "yaw axis", is an imaginary line running 
vertically through the platform and through its center of gravity. In yaw 
motion, the platform rotates clockwise or counter clockwise in the horizontal, 
relative to its orientation, which has the standard name platform_orientation. 
Platform yaw angle is the angle at a given instant between the platform's 
longitudinal/X axis and the position of that axis with high frequency 
variations (e.g. the effect of surface waves on a ship) removed. Zero yaw angle 
means the longitudinal axis is aligned with the platform_orientation. The usual 
sign convention is that yaw angle is measured positive when the front or 
leading 
 edge of the platform is rotated clockwise from the platform_orientation.'


Okay?


Like Roy, I had wondered whether 'platform_orientation' should really be an 
instantaneous quantity or something with high frequency variability removed. If 
it is the latter (which I think was probably the original intention of the 
standard name) then we should amend the definition as follows:

'Standard names for "platform" describe the motion and orientation of the 
vehicle from which observations are made. Platforms include, but are not 
limited to, satellites, aeroplanes, ships, instruments and buoys. The platform 
orientation is the direction in which the "front" or longitudinal axis of the 
platform is pointing with high frequency variations (e.g. the effect of surface 
waves on a ship) removed. (This is not necessarily the same as the direction in 
which the platform is travelling, called platform_course).'


Okay?


As an additional point, I note that besides the names already discussed in this 
thread, there are a further 11 existing platform names. I will include the new 
text for 'platform' in their definitions as part of the August standard names 
update.


Best wishes,

Alison


From: Lowry, Roy K. 
Sent: 25 July 2018 16:35:27
To: Pamment, Alison (STFC,RAL,RALSP); cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Hi again,


This is an area where it is easy to get tied up in knots because there are 
multiple reference frames. If we talk ships then there is the 
platform_orientation (or heading) which is measured using a gyro-compass - a 
stabilised instrument that eliminates high-frequency variations in where the 
bow is actually pointing and provides the zero reference point for yaw.


The concept of 'travel' relates to another reference frame external to the 
platform - say a GPS CRS  - but yaw only has relevance to the platform's 
internal reference frame. So you are right that bringing 'direction of travel' 
into a definition of yaw is a bad thing even though it's reasonably common 
practice to do so.


Mean orientation is also possibly best avoided as the platform_orientation 
isn't necessarily determined by averaging instantaneous longitudinal axis 
orientations.  It could be - and often is - measured by something that has 
greater inertia than the platform.


So how about using :


Platform yaw angle is the angle at a given instant between the platform's 
longitudinal/X axis and the position of that axis with high frequency 
variations (e.g. the effect of surface waves on a ship) removed. Zero yaw angle 
means the longitudinal axis is aligned with the platform_orientation. The usual 
sign convention is that yaw angle is measured positive when the front or 
leading edge of the platform is rotated clockwise from the platform_orientation.


This raises the question as to whether the platform_orientation definition 
should have the clarification 'with high-frequency variability removed' added. 
This would be an explicit statement of what - to me at least - is commonly 
understood meaning of 'heading'.


Does that help?


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Alison 
Pamment - U

Re: [CF-metadata] Platform Heave

[Jim Biard]

Alison,

It's a lovely nested reference frames problem, isn't it? Roll, pitch, 
and yaw are usually defined relative to a center of motion (CM) 
reference frame defined using the (mean) direction of motion and the up 
direction. In my (satellite-based) experience, the Y axis unit vector is 
defined by the normalized cross-product of the up unit vector with the 
direction of motion unit vector (Z x X). The X axis unit vector is then 
defined by the cross-product of the Y unit vector and the up unit vector 
(Y x Z). This means of forming the CM reference frame decouples 
orientation from motion. The X axis is not necessarily identical to the 
direction of motion. The vehicle reference frame may have fixed offsets 
in x, y, z, roll, pitch, and yaw relative to the CM reference frame, but 
in my limited experience those offsets have been zero.


Platforms that aren't moving are an even more entertaining case, for sure!

In the end, I'd tend towards referring to a CM or geospatial reference 
frame with the Z direction defined as "up" if I'm going to try and get 
detailed about it, as opposed to 'mean orientation'. But I only have 
experience with satellites (and a bit with airplanes).


Grace and peace,

Jim


On 7/25/18 9:37 AM, Alison Pamment - UKRI STFC wrote:

Hi Roy and Jim,

Thanks for your quick comments on the definitions. I have just been looking 
again at the suggested text for yaw_angle:
'Platform yaw angle is the angle between the platform's longitudinal/X axis and 
the direction of travel. Zero yaw angle means the longitudinal axis is aligned 
with the direction of travel, or a reference direction if the platform is 
stationary. The usual sign convention is that yaw angle is measured positive 
when the front or leading edge of the platform is rotated clockwise from its 
orientation (which has the standard name platform_orientation).'

The problem is how to describe the reference direction which the angle is calculated 
relative to. I started out by talking about 'direction of travel' and later referred to 
'platform_orientation'. The definition of platform_orientation says 'The platform 
orientation is the direction in which the "front" or longitudinal axis of the 
platform is pointing (not necessarily the same as the direction in which it is 
travelling, called platform_course).' I've realised my new definition doesn't really make 
sense if direction of travel and orientation aren't the same (and clearly they can be 
different). Also, if 'orientation' is the instantaneous direction of the longitudinal 
axis, then presumably it includes yaw angle, so it isn't the right reference for 
measuring yaw.

I've revised the text as follows:
'Platform yaw angle is the angle between the platform's longitudinal/X axis and 
the platform's mean orientation (i.e. its orientation not including high 
frequency variations due to swaying and rocking motions, for example, ship 
motions caused by the passing of sea surface waves). Zero yaw angle means the 
longitudinal axis is aligned with the mean orientation. The usual sign 
convention is that yaw angle is measured positive when the front or leading 
edge of the platform is rotated clockwise from its mean orientation (which has 
the standard name platform_orientation).

Does it sound okay to refer to a 'mean orientation' in this way? I'm having 
trouble thinking of a better wording!

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

-Original Message-
From: CF-metadata  On Behalf Of Alison 
Pamment - UKRI STFC
Sent: 25 July 2018 13:12
To: Hamilton, Steve ; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Dear Steve, Nan, et al,

Thank you for proposing new standard names for platform_heave and improved 
definitions for existing names for platform pitch, roll and yaw. Thank you also 
to all those who submitted comments about these names.

Regarding Steve's proposals for new names, the discussion seems to have reached 
consensus on the quantities themselves.

Until now, our usual explanatory sentence for 'platform' has said 'Standard 
names for platform describe the motion and orientation of the vehicle from 
which observations are made e.g. aeroplane, ship or satellite.' Nan has 
suggested extending the list of possible platforms, which seems fair enough, so 
we would now have 'Standard names for platform describe the motion and 
orientation of the vehicle from which observations are made. Platforms include, 
but are not limited to, satellites, aeroplanes, ships, instruments, and buoys.' 
I've added this into the definitions of Steve's names, leading to:

platform_heave (m)
'Standard names for "platform" describe the motion and orientation of the vehicle from 
which observations are made. Platform

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi again,


This is an area where it is easy to get tied up in knots because there are 
multiple reference frames. If we talk ships then there is the 
platform_orientation (or heading) which is measured using a gyro-compass - a 
stabilised instrument that eliminates high-frequency variations in where the 
bow is actually pointing and provides the zero reference point for yaw.


The concept of 'travel' relates to another reference frame external to the 
platform - say a GPS CRS  - but yaw only has relevance to the platform's 
internal reference frame. So you are right that bringing 'direction of travel' 
into a definition of yaw is a bad thing even though it's reasonably common 
practice to do so.


Mean orientation is also possibly best avoided as the platform_orientation 
isn't necessarily determined by averaging instantaneous longitudinal axis 
orientations.  It could be - and often is - measured by something that has 
greater inertia than the platform.


So how about using :


Platform yaw angle is the angle at a given instant between the platform's 
longitudinal/X axis and the position of that axis with high frequency 
variations (e.g. the effect of surface waves on a ship) removed. Zero yaw angle 
means the longitudinal axis is aligned with the platform_orientation. The usual 
sign convention is that yaw angle is measured positive when the front or 
leading edge of the platform is rotated clockwise from the platform_orientation.


This raises the question as to whether the platform_orientation definition 
should have the clarification 'with high-frequency variability removed' added. 
This would be an explicit statement of what - to me at least - is commonly 
understood meaning of 'heading'.


Does that help?


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 25 July 2018 14:37
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Roy and Jim,

Thanks for your quick comments on the definitions. I have just been looking 
again at the suggested text for yaw_angle:
'Platform yaw angle is the angle between the platform's longitudinal/X axis and 
the direction of travel. Zero yaw angle means the longitudinal axis is aligned 
with the direction of travel, or a reference direction if the platform is 
stationary. The usual sign convention is that yaw angle is measured positive 
when the front or leading edge of the platform is rotated clockwise from its 
orientation (which has the standard name platform_orientation).'

The problem is how to describe the reference direction which the angle is 
calculated relative to. I started out by talking about 'direction of travel' 
and later referred to 'platform_orientation'. The definition of 
platform_orientation says 'The platform orientation is the direction in which 
the "front" or longitudinal axis of the platform is pointing (not necessarily 
the same as the direction in which it is travelling, called platform_course).' 
I've realised my new definition doesn't really make sense if direction of 
travel and orientation aren't the same (and clearly they can be different). 
Also, if 'orientation' is the instantaneous direction of the longitudinal axis, 
then presumably it includes yaw angle, so it isn't the right reference for 
measuring yaw.

I've revised the text as follows:
'Platform yaw angle is the angle between the platform's longitudinal/X axis and 
the platform's mean orientation (i.e. its orientation not including high 
frequency variations due to swaying and rocking motions, for example, ship 
motions caused by the passing of sea surface waves). Zero yaw angle means the 
longitudinal axis is aligned with the mean orientation. The usual sign 
convention is that yaw angle is measured positive when the front or leading 
edge of the platform is rotated clockwise from its mean orientation (which has 
the standard name platform_orientation).

Does it sound okay to refer to a 'mean orientation' in this way? I'm having 
trouble thinking of a better wording!

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

-Original Message-
From: CF-metadata  On Behalf Of Alison 
Pamment - UKRI STFC
Sent: 25 July 2018 13:12
To: Hamilton, Steve ; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Dear Steve, Nan, et al,

Thank you for proposing new standard names for platform_heave and improved 
definitions for existing names for platform pitch, roll and yaw. Thank you also 
to all those who submitted comments about these names.

Regarding Steve's proposals for new names, the discussion seems to have reached 
consensus on the quantities themselv

Re: [CF-metadata] Platform Heave

[Alison Pamment - UKRI STFC]

Hi Roy and Jim,

Thanks for your quick comments on the definitions. I have just been looking 
again at the suggested text for yaw_angle:
'Platform yaw angle is the angle between the platform's longitudinal/X axis and 
the direction of travel. Zero yaw angle means the longitudinal axis is aligned 
with the direction of travel, or a reference direction if the platform is 
stationary. The usual sign convention is that yaw angle is measured positive 
when the front or leading edge of the platform is rotated clockwise from its 
orientation (which has the standard name platform_orientation).'

The problem is how to describe the reference direction which the angle is 
calculated relative to. I started out by talking about 'direction of travel' 
and later referred to 'platform_orientation'. The definition of 
platform_orientation says 'The platform orientation is the direction in which 
the "front" or longitudinal axis of the platform is pointing (not necessarily 
the same as the direction in which it is travelling, called platform_course).' 
I've realised my new definition doesn't really make sense if direction of 
travel and orientation aren't the same (and clearly they can be different). 
Also, if 'orientation' is the instantaneous direction of the longitudinal axis, 
then presumably it includes yaw angle, so it isn't the right reference for 
measuring yaw.

I've revised the text as follows:
'Platform yaw angle is the angle between the platform's longitudinal/X axis and 
the platform's mean orientation (i.e. its orientation not including high 
frequency variations due to swaying and rocking motions, for example, ship 
motions caused by the passing of sea surface waves). Zero yaw angle means the 
longitudinal axis is aligned with the mean orientation. The usual sign 
convention is that yaw angle is measured positive when the front or leading 
edge of the platform is rotated clockwise from its mean orientation (which has 
the standard name platform_orientation).

Does it sound okay to refer to a 'mean orientation' in this way? I'm having 
trouble thinking of a better wording!

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory 
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

-Original Message-
From: CF-metadata  On Behalf Of Alison 
Pamment - UKRI STFC
Sent: 25 July 2018 13:12
To: Hamilton, Steve ; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Dear Steve, Nan, et al,

Thank you for proposing new standard names for platform_heave and improved 
definitions for existing names for platform pitch, roll and yaw. Thank you also 
to all those who submitted comments about these names.

Regarding Steve's proposals for new names, the discussion seems to have reached 
consensus on the quantities themselves.

Until now, our usual explanatory sentence for 'platform' has said 'Standard 
names for platform describe the motion and orientation of the vehicle from 
which observations are made e.g. aeroplane, ship or satellite.' Nan has 
suggested extending the list of possible platforms, which seems fair enough, so 
we would now have 'Standard names for platform describe the motion and 
orientation of the vehicle from which observations are made. Platforms include, 
but are not limited to, satellites, aeroplanes, ships, instruments, and buoys.' 
I've added this into the definitions of Steve's names, leading to:

platform_heave (m)
'Standard names for "platform" describe the motion and orientation of the 
vehicle from which observations are made. Platforms include, but are not 
limited to, satellites, aeroplanes, ships, instruments, and buoys. "Heave" 
means the vertical displacement of a platform (positive upwards) over a 
measurement time interval.'

platform_heave_rate (m s-1)
'Standard names for "platform" describe the motion and orientation of the 
vehicle from which observations are made. Platforms include, but are not 
limited to, satellites, aeroplanes, ships, instruments, and buoys "Heave" means 
the vertical displacement of a platform (positive upwards) over a measurement 
time interval. "Heave rate" means the rate of change of vertical displacement 
of the platform over a measurement time interval.'

These two names are accepted for publication in the standard name table and 
will be added in the next update, planned for 6th August.

We have six existing platform pitch, roll and yaw names:
platform_pitch_angle (degree)
platform_pitch_rate (degree s-1)
platform_roll_angle (degree)
platform_roll_rate (degree s-1)
platform_yaw_angle (degree)
platform_yaw_rate (degree s-1)

Nan has suggested the following definitions, based on 
https://en.wikipedia.org/wiki/Ship_motions. (A quick search of other online 
sources yields definitions consistent with these).
Pitch
Th

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Alison,


Excellent job with the definitions. My view is that the pitch/roll/yaw names 
are fine.


Cheers, Roy.



I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 25 July 2018 13:11
To: Hamilton, Steve; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Dear Steve, Nan, et al,

Thank you for proposing new standard names for platform_heave and improved 
definitions for existing names for platform pitch, roll and yaw. Thank you also 
to all those who submitted comments about these names.

Regarding Steve's proposals for new names, the discussion seems to have reached 
consensus on the quantities themselves.

Until now, our usual explanatory sentence for 'platform' has said 'Standard 
names for platform describe the motion and orientation of the vehicle from 
which observations are made e.g. aeroplane, ship or satellite.' Nan has 
suggested extending the list of possible platforms, which seems fair enough, so 
we would now have 'Standard names for platform describe the motion and 
orientation of the vehicle from which observations are made. Platforms include, 
but are not limited to, satellites, aeroplanes, ships, instruments, and buoys.' 
I've added this into the definitions of Steve's names, leading to:

platform_heave (m)
'Standard names for "platform" describe the motion and orientation of the 
vehicle from which observations are made. Platforms include, but are not 
limited to, satellites, aeroplanes, ships, instruments, and buoys. "Heave" 
means the vertical displacement of a platform (positive upwards) over a 
measurement time interval.'

platform_heave_rate (m s-1)
'Standard names for "platform" describe the motion and orientation of the 
vehicle from which observations are made. Platforms include, but are not 
limited to, satellites, aeroplanes, ships, instruments, and buoys "Heave" means 
the vertical displacement of a platform (positive upwards) over a measurement 
time interval. "Heave rate" means the rate of change of vertical displacement 
of the platform over a measurement time interval.'

These two names are accepted for publication in the standard name table and 
will be added in the next update, planned for 6th August.

We have six existing platform pitch, roll and yaw names:
platform_pitch_angle (degree)
platform_pitch_rate (degree s-1)
platform_roll_angle (degree)
platform_roll_rate (degree s-1)
platform_yaw_angle (degree)
platform_yaw_rate (degree s-1)

Nan has suggested the following definitions, based on 
https://en.wikipedia.org/wiki/Ship_motions. (A quick search of other online 
sources yields definitions consistent with these).
Pitch
The up/down rotation of a platform about its transverse/Y axis. The 
transverse/Y axis, lateral or pitch axis is an imaginary line running 
horizontally across the platform and through its center of gravity. A pitch  
motion is an up-or-down movement of the bow and stern of the platform.

Roll
The tilting rotation of a platform about its longitudinal/X axis. The 
longitudinal/X axis, or roll axis, is an imaginary line running horizontally 
through the length of the platform, through its center of gravity, and parallel 
to the waterline. A roll motion is a side-to-side or port-starboard tilting 
motion of the superstructure around this axis.

Yaw
The turning rotation of a platform about its vertical/Z axis. The vertical/Z 
axis, or yaw axis, is an imaginary line running vertically through the platform 
and through its center of gravity. A yaw motion is a side-to side movement of 
the bow and stern of the ship.

These are useful and concise definitions. I suggest that we don't refer 
anywhere to 'ship', 'bow' or 'stern', since we want the definitions to apply to 
all possible platforms. I'm thinking also that 'port' and 'starboard' may apply 
to ships and aeroplanes, but perhaps not to a satellite, so are probably best 
avoided. Similarly, 'waterline' only applies to maritime platforms. I suggest 
the following amendments to make the definitions as generic as possible:

Pitch
"Pitch" means rotation of the platform in the vertical plane about its 
transverse/Y axis. The transverse/Y axis, also known as the "lateral axis" or 
"pitch axis", is an imaginary line running horizontally across the platform and 
through its center of gravity. In pitch motion, the leading edge of the 
platform moves vertically upwards while the rear moves vertically downwards, 
and vice versa.

Roll
"Roll" means rotation of the platform in the vertical plane about its 
longitudinal/X axis. The longitudinal/X axis, also known as the "roll axis", is 
an imaginary line running horizontally through the length of the platform and 
through its center of gravity. In roll motion, the platform tilts such that 

Re: [CF-metadata] Platform Heave

[Jim Biard]

ough the platform and through its center of gravity. In yaw motion, the platform 
rotates clockwise or counter clockwise in the horizontal, relative to its orientation, which has 
the standard name platform_orientation.

Are these okay?

For names such as platform_view_angle and platform_zenith_angle we also 
describe how the angle itself is measured. We should do the same for pitch, 
roll and yaw angles while we are in the process of updating the definitions. I 
have come up with the following:

Pitch angle
Platform pitch angle is the angle between the local horizontal and the 
platform's longitudinal/X axis. Zero pitch angle means the longitudinal axis is 
horizontal. The usual sign convention is that pitch angle is measured positive 
when the front or leading edge of the platform is elevated above the 
horizontal, negative when it is below the horizontal.

Roll angle
Platform roll angle is the angle between the local horizontal and the platform's 
lateral/Y axis. Zero roll angle means the lateral axis is horizontal. The usual sign 
convention is that roll angle is measured positive when the right hand edge of the 
platform (when viewing towards the orientation direction or "front" of the 
platform) is elevated above the horizontal, negative when it is below the horizontal.

Yaw angle
Platform yaw angle is the angle between the platform's longitudinal/X axis and 
the direction of travel. Zero yaw angle means the longitudinal axis is aligned 
with the direction of travel, or a reference direction if the platform is 
stationary. The usual sign convention is that yaw angle is measured positive 
when the front or leading edge of the platform is rotated clockwise from its 
orientation (which has the standard name platform_orientation).

Just so we can see a couple of examples of pulling all this together, I've 
written out the full revised definitions of platform platform_pitch_angle and 
platform_pitch_rate below.

platform_pitch_angle (degree)
'Standard names for "platform" describe the motion and orientation of the vehicle from which observations are 
made. Platforms include, but are not limited to, satellites, aeroplanes, ships, instruments and buoys. 
"Pitch" means rotation of the platform in the vertical plane about its transverse/Y axis. The transverse/Y 
axis, also known as the "lateral axis" or "pitch axis", is an imaginary line running horizontally 
across the platform and through its center of gravity. In pitch motion, the leading edge of the platform moves 
vertically upwards while the rear moves vertically downwards, and vice versa. Platform pitch angle is the angle between 
the local horizontal and the platform's longitudinal/X axis. Zero pitch angle means the longitudinal axis is 
horizontal. The usual sign convention is that pitch angle is measured positive when the front or leading edge of the 
platform is elevated above the horizontal, negative when it is below the horizontal.'

platform_pitch_rate (degree s-1)
'Standard names for "platform" describe the motion and orientation of the vehicle from which observations are 
made. Platforms include, but are not limited to, satellites, aeroplanes, ships, instruments and buoys. 
"Pitch" means rotation of the platform in the vertical plane about its transverse/Y axis. The transverse/Y 
axis, also known as the "lateral axis" or "pitch axis", is an imaginary line running horizontally 
across the platform and through its center of gravity. In pitch motion, the leading edge of the platform moves 
vertically upwards while the rear moves vertically downwards, and vice versa. The quantity with standard name 
platform_pitch_rate is the change per unit time in the quantity with standard name platform_pitch_angle.'

The roll and yaw definitions would be constructed similarly.

The pitch/roll/yaw names are still under discussion. I'd welcome further 
comments on these.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

-Original Message-
From: CF-metadata  On Behalf Of Hamilton, 
Steve
Sent: 11 July 2018 10:52
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Nan,

I agree expanding on the existing standard name descriptions does make sense 
and standardising for _rate and _angle

What you suggest below seems acceptable

Thanks

Steve

-Original Message-
From: CF-metadata  On Behalf Of Nan Galbraith
Sent: 10 July 2018 17:39
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Alison, Steve, and all -

Since we have a little time to finalize this, could we also consider updating 
the definitions of platform_pitch_angle, platform_roll_angle and 
platform_yaw_angle?

Currently, these all say 'Standard name

Re: [CF-metadata] Platform Heave

[Alison Pamment - UKRI STFC]

 horizontal, relative to its orientation, which has the standard name 
platform_orientation.

Are these okay?

For names such as platform_view_angle and platform_zenith_angle we also 
describe how the angle itself is measured. We should do the same for pitch, 
roll and yaw angles while we are in the process of updating the definitions. I 
have come up with the following:

Pitch angle
Platform pitch angle is the angle between the local horizontal and the 
platform's longitudinal/X axis. Zero pitch angle means the longitudinal axis is 
horizontal. The usual sign convention is that pitch angle is measured positive 
when the front or leading edge of the platform is elevated above the 
horizontal, negative when it is below the horizontal.

Roll angle
Platform roll angle is the angle between the local horizontal and the 
platform's lateral/Y axis. Zero roll angle means the lateral axis is 
horizontal. The usual sign convention is that roll angle is measured positive 
when the right hand edge of the platform (when viewing towards the orientation 
direction or "front" of the platform) is elevated above the horizontal, 
negative when it is below the horizontal.

Yaw angle
Platform yaw angle is the angle between the platform's longitudinal/X axis and 
the direction of travel. Zero yaw angle means the longitudinal axis is aligned 
with the direction of travel, or a reference direction if the platform is 
stationary. The usual sign convention is that yaw angle is measured positive 
when the front or leading edge of the platform is rotated clockwise from its 
orientation (which has the standard name platform_orientation).

Just so we can see a couple of examples of pulling all this together, I've 
written out the full revised definitions of platform platform_pitch_angle and 
platform_pitch_rate below.

platform_pitch_angle (degree)
'Standard names for "platform" describe the motion and orientation of the 
vehicle from which observations are made. Platforms include, but are not 
limited to, satellites, aeroplanes, ships, instruments and buoys. "Pitch" means 
rotation of the platform in the vertical plane about its transverse/Y axis. The 
transverse/Y axis, also known as the "lateral axis" or "pitch axis", is an 
imaginary line running horizontally across the platform and through its center 
of gravity. In pitch motion, the leading edge of the platform moves vertically 
upwards while the rear moves vertically downwards, and vice versa. Platform 
pitch angle is the angle between the local horizontal and the platform's 
longitudinal/X axis. Zero pitch angle means the longitudinal axis is 
horizontal. The usual sign convention is that pitch angle is measured positive 
when the front or leading edge of the platform is elevated above the 
horizontal, negative when it is below the horizontal.'

platform_pitch_rate (degree s-1)
'Standard names for "platform" describe the motion and orientation of the 
vehicle from which observations are made. Platforms include, but are not 
limited to, satellites, aeroplanes, ships, instruments and buoys. "Pitch" means 
rotation of the platform in the vertical plane about its transverse/Y axis. The 
transverse/Y axis, also known as the "lateral axis" or "pitch axis", is an 
imaginary line running horizontally across the platform and through its center 
of gravity. In pitch motion, the leading edge of the platform moves vertically 
upwards while the rear moves vertically downwards, and vice versa. The quantity 
with standard name platform_pitch_rate is the change per unit time in the 
quantity with standard name platform_pitch_angle.'

The roll and yaw definitions would be constructed similarly.

The pitch/roll/yaw names are still under discussion. I'd welcome further 
comments on these.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory     
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

-Original Message-
From: CF-metadata  On Behalf Of Hamilton, 
Steve
Sent: 11 July 2018 10:52
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Nan,

I agree expanding on the existing standard name descriptions does make sense 
and standardising for _rate and _angle

What you suggest below seems acceptable

Thanks

Steve

-Original Message-
From: CF-metadata  On Behalf Of Nan Galbraith
Sent: 10 July 2018 17:39
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Alison, Steve, and all -

Since we have a little time to finalize this, could we also consider updating 
the definitions of platform_pitch_angle, platform_roll_angle and 
platform_yaw_angle?

Currently, these all say 'Standard names for platform describe the motion and 
orientation of the vehicle from which observations are made e.g. aeroplane, 
shi

Re: [CF-metadata] Platform Heave

[Hamilton, Steve]

Hi Nan,

I agree expanding on the existing standard name descriptions does make sense 
and standardising for _rate and _angle

What you suggest below seems acceptable

Thanks

Steve

-Original Message-
From: CF-metadata  On Behalf Of Nan Galbraith
Sent: 10 July 2018 17:39
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Alison, Steve, and all -

Since we have a little time to finalize this, could we also consider updating 
the definitions of platform_pitch_angle, platform_roll_angle and 
platform_yaw_angle?

Currently, these all say 'Standard names for platform describe the motion and 
orientation of the vehicle from which observations are made e.g. aeroplane, 
ship or satellite.'

John Helly pointed to the helpful Wikipedia page for ship motion, 
https://en.wikipedia.org/wiki/Ship_motions. The suggestions below are merged 
from different sections of that page, and might be a little ... long, but I'd 
also like to append something like 'Platforms include but are not limited to 
satellites, aeroplanes, ships, instruments, and buoys.'

Pitch
The up/down rotation of a platform about its transverse/Y axis. The 
transverse/Y axis, lateral or pitch axis is an imaginary line running 
horizontally across the platform and through its center of gravity. A pitch  
motion is an up-or-down movement of the bow and stern of the platform.

Roll
The tilting rotation of a platform about its longitudinal/X axis. The 
longitudinal/X axis, or roll axis, is an imaginary line running horizontally 
through the length of the platform, through its center of gravity, and parallel 
to the waterline. A roll motion is a side-to-side or port-starboard tilting 
motion of the superstructure around this axis.

Yaw
The turning rotation of a platform about its vertical/Z axis. The vertical/Z 
axis, or yaw axis, is an imaginary line running vertically through the platform 
and through its center of gravity.
A yaw motion is a side-to side movement of the bow and stern of the ship.

And we had something like this for heave:
platform_heave (m) = upwards vertical displacement

I suppose these could also be applied to platform_*_rates.

Regards -
Nan


On 7/4/18 4:47 AM, Alison Pamment - UKRI STFC wrote:

> Dear Steve,  > > Thank you for your message and apologies for not 
> having processed
 > your proposals as yet. I have been working on the CMIP names, but > they are 
 > reaching a conclusion and I will shortly be looking through > the many other 
 > proposals that have been waiting for attention. > > A quick look through the 
 > discussion of your names shows they are > pretty much agreed. You need take 
 > no further action at this time - I > will check that the names and 
 > definitions are clear and consistent > with existing names and get back to 
 > you on the list with any final > comments or questions. Version 56 of the 
 > standard name table will be > published later today - I think we can 
 > probably finalise your names > in time for version 57. > > Best wishes, 
 > Alison
> 
> From: Hamilton, Steve 
> Sent: 03 July 2018 09:12
>
>
> Please can you advise if this standard name has now been accepted and 
> when it will be included in the CF Standard Names
>
> If there is something else to do please let me know
>
> Thanks
>
> Steve
>
>
> 
> From: Jim Biard mailto:jbi...@cicsnc.org>>
> Sent: 01 June 2018 22:56
>
>
> Nan,
> Thanks for pulling things back in. I very much like the idea of keeping 
> technology or specific methods out of the definition if at all possible, so I 
> like your proposal. I expect we should include platform in the definition, as 
> well as an indication that this is dynamic (over time). How about these 
> definitions?
> platform_heave (m) = upwards vertical displacement of a platform over 
> a measurement time interval platform_heave_rate (m s-1) = upwards rate 
> of change in vertical displacement of a platform over a measurement time 
> interval They leave out some detail but capture the relative nature of the 
> quantities.
> (In my mind, the primary detail being left out is the 'net zero' 
> nature of the quantities, which gets back to defining the 
> 'moving-mean' sea level reference point.) Grace and peace,
>
> Jim

> On 6/1/18 11:23 AM, Nan Galbraith wrote:
> Hi all -
>
> The latest version is confusing to me. The term 'a platform that is 
> nominally at rest' does not apply to many platforms for which heave is 
> calculated; the original version of that, 'a moving object above the 
> vertical level of that object when stationary' was maybe a little more 
> clear... if also a little wordy.
>
> And, the term  'vertical displacement determined by integrating 
> vertical accelera

Re: [CF-metadata] Platform Heave

[Nan Galbraith]

Hi Alison, Steve, and all -

Since we have a little time to finalize this, could we also consider 
updating the definitions

of platform_pitch_angle, platform_roll_angle and platform_yaw_angle?

Currently, these all say 'Standard names for platform describe the 
motion and orientation
of the vehicle from which observations are made e.g. aeroplane, ship or 
satellite.'


John Helly pointed to the helpful Wikipedia page for ship motion,
https://en.wikipedia.org/wiki/Ship_motions. The suggestions below are 
merged from
different sections of that page, and might be a little ... long, but I'd 
also
like to append something like 'Platforms include but are not limited to 
satellites, aeroplanes,

ships, instruments, and buoys.'

Pitch
The up/down rotation of a platform about its transverse/Y axis. The 
transverse/Y
axis, lateral or pitch axis is an imaginary line running horizontally 
across the platform
and through its center of gravity. A pitch  motion is an up-or-down 
movement of the

bow and stern of the platform.

Roll
The tilting rotation of a platform about its longitudinal/X axis. The 
longitudinal/X axis,
or roll axis, is an imaginary line running horizontally through the 
length of the platform,
through its center of gravity, and parallel to the waterline. A roll 
motion is a side-to-side

or port-starboard tilting motion of the superstructure around this axis.

Yaw
The turning rotation of a platform about its vertical/Z axis. The 
vertical/Z axis, or yaw axis,
is an imaginary line running vertically through the platform and through 
its center of gravity.

A yaw motion is a side-to side movement of the bow and stern of the ship.

And we had something like this for heave:
platform_heave (m) = upwards vertical displacement

I suppose these could also be applied to platform_*_rates.

Regards -
Nan


On 7/4/18 4:47 AM, Alison Pamment - UKRI STFC wrote:

Dear Steve,  > > Thank you for your message and apologies for not having processed 
> your proposals as yet. I have been working on the CMIP names, but > 
they are reaching a conclusion and I will shortly be looking through > 
the many other proposals that have been waiting for attention. > > A 
quick look through the discussion of your names shows they are > pretty 
much agreed. You need take no further action at this time - I > will 
check that the names and definitions are clear and consistent > with 
existing names and get back to you on the list with any final > comments 
or questions. Version 56 of the standard name table will be > published 
later today - I think we can probably finalise your names > in time for 
version 57. > > Best wishes, Alison


From: Hamilton, Steve 
Sent: 03 July 2018 09:12


Please can you advise if this standard name has now been accepted and when it 
will be included in the CF Standard Names

If there is something else to do please let me know

Thanks

Steve



From: Jim Biard mailto:jbi...@cicsnc.org>>
Sent: 01 June 2018 22:56


Nan,
Thanks for pulling things back in. I very much like the idea of keeping 
technology or specific methods out of the definition if at all possible, so I 
like your proposal. I expect we should include platform in the definition, as 
well as an indication that this is dynamic (over time). How about these 
definitions?
platform_heave (m) = upwards vertical displacement of a platform over a 
measurement time interval
platform_heave_rate (m s-1) = upwards rate of change in vertical displacement 
of a platform over a measurement time interval
They leave out some detail but capture the relative nature of the quantities.
(In my mind, the primary detail being left out is the 'net zero' nature of the 
quantities, which gets back to defining the 'moving-mean' sea level reference 
point.)
Grace and peace,

Jim



On 6/1/18 11:23 AM, Nan Galbraith wrote:
Hi all -

The latest version is confusing to me. The term 'a platform that is nominally 
at rest' does
not apply to many platforms for which heave is calculated; the original version 
of that,
'a moving object above the vertical level of that object when stationary' was 
maybe a little
more clear... if also a little wordy.

And, the term  'vertical displacement determined by integrating vertical 
accelerations' may
also not apply - I've been looking at the different ways heave is calculated, 
and there
are a few: 'Heave can be computed from GPS RTK height measurements and from
vertical accelerations measured by linear accelerometers'

Why  not keep it simple: platform_heave (m) = upwards vertical displacement?  
Do we need
to be more specific than that?

Thanks - Nan


From: Lowry, Roy K.
Sent: 30 May 2018 21:37

An afterthought. Heave is conventionally positive upwards so to make this clear 
I would add the word 'upwards' thus:

platform_heave (m) = upwards vertical displacement determined by integrating 
vertical accelerations of a platform that is nominally at rest.

platform_heave_rate 

Re: [CF-metadata] Platform Heave

[Alison Pamment - UKRI STFC]

Dear Steve,

Thank you for your message and apologies for not having processed your 
proposals as yet. I have been working on the CMIP names, but they are reaching 
a conclusion and I will shortly be looking through the many other proposals 
that have been waiting for attention.

A quick look through the discussion of your names shows they are pretty much 
agreed. You need take no further action at this time - I will check that the 
names and definitions are clear and consistent with existing names and get back 
to you on the list with any final comments or questions. Version 56 of the 
standard name table will be published later today - I think we can probably 
finalise your names in time for version 57.

Best wishes,
Alison


From: CF-metadata  on behalf of Hamilton, 
Steve 
Sent: 03 July 2018 09:12
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Please can you advise if this standard name has now been accepted and when it 
will be included in the CF Standard Names

If there is something else to do please let me know

Thanks

Steve

From: CF-metadata  On Behalf Of Lowry, Roy K.
Sent: 04 June 2018 12:21
To: Jim Biard ; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

I'm equally happy with this.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu>> on 
behalf of Jim Biard mailto:jbi...@cicsnc.org>>
Sent: 01 June 2018 22:56
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

Nan,
Thanks for pulling things back in. I very much like the idea of keeping 
technology or specific methods out of the definition if at all possible, so I 
like your proposal. I expect we should include platform in the definition, as 
well as an indication that this is dynamic (over time). How about these 
definitions?
platform_heave (m) = upwards vertical displacement of a platform over a 
measurement time interval
platform_heave_rate (m s-1) = upwards rate of change in vertical displacement 
of a platform over a measurement time interval
They leave out some detail but capture the relative nature of the quantities.
(In my mind, the primary detail being left out is the 'net zero' nature of the 
quantities, which gets back to defining the 'moving-mean' sea level reference 
point.)
Grace and peace,

Jim
On 6/1/18 11:23 AM, Nan Galbraith wrote:
Hi all -

The latest version is confusing to me. The term 'a platform that is nominally 
at rest' does
not apply to many platforms for which heave is calculated; the original version 
of that,
'a moving object above the vertical level of that object when stationary' was 
maybe a little
more clear... if also a little wordy.

And, the term  'vertical displacement determined by integrating vertical 
accelerations' may
also not apply - I've been looking at the different ways heave is calculated, 
and there
are a few: 'Heave can be computed from GPS RTK height measurements and from
vertical accelerations measured by linear accelerometers'

Why  not keep it simple: platform_heave (m) = upwards vertical displacement?  
Do we need
to be more specific than that?

Thanks - Nan

On 5/31/18 5:01 AM, Hamilton, Steve wrote:


Thanks for everyone’s input, the below seems acceptable for now

Regards

Steve

From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> On 
Behalf Of Lowry, Roy K.
Sent: 30 May 2018 21:37
To: Jim Biard <mailto:jbi...@cicsnc.org>; 
cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

An afterthought. Heave is conventionally positive upwards so to make this clear 
I would add the word 'upwards' thus:

platform_heave (m) = upwards vertical displacement determined by integrating 
vertical accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = upwards vertical velocity determined by 
integrating vertical accelerations of a platform that is nominally at rest.

Cheers. Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu> 
<mailto:cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu>>
 on behalf of Lowry, Roy K. mailto:r...@bodc.ac.uk> 
<mailto:r...@bodc.ac.uk><mailto:r...@bodc.ac.uk>>
Sent: 30 May 2018 21:02
To: Jim Biard; cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu> 
<mailto:cf-metadata@cgd.ucar.edu><mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

Thanks Jim,

That work for me.

Cheers, Roy.



From: CF-metadata 
mai

Re: [CF-metadata] Platform Heave

[Hamilton, Steve]

Please can you advise if this standard name has now been accepted and when it 
will be included in the CF Standard Names

If there is something else to do please let me know

Thanks

Steve

From: CF-metadata  On Behalf Of Lowry, Roy K.
Sent: 04 June 2018 12:21
To: Jim Biard ; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


I'm equally happy with this.



I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu>> on 
behalf of Jim Biard mailto:jbi...@cicsnc.org>>
Sent: 01 June 2018 22:56
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave


Nan,

Thanks for pulling things back in. I very much like the idea of keeping 
technology or specific methods out of the definition if at all possible, so I 
like your proposal. I expect we should include platform in the definition, as 
well as an indication that this is dynamic (over time). How about these 
definitions?

platform_heave (m) = upwards vertical displacement of a platform over a 
measurement time interval

platform_heave_rate (m s-1) = upwards rate of change in vertical displacement 
of a platform over a measurement time interval

They leave out some detail but capture the relative nature of the quantities.

(In my mind, the primary detail being left out is the 'net zero' nature of the 
quantities, which gets back to defining the 'moving-mean' sea level reference 
point.)
Grace and peace,

Jim
On 6/1/18 11:23 AM, Nan Galbraith wrote:
Hi all -

The latest version is confusing to me. The term 'a platform that is nominally 
at rest' does
not apply to many platforms for which heave is calculated; the original version 
of that,
'a moving object above the vertical level of that object when stationary' was 
maybe a little
more clear... if also a little wordy.

And, the term  'vertical displacement determined by integrating vertical 
accelerations' may
also not apply - I've been looking at the different ways heave is calculated, 
and there
are a few: 'Heave can be computed from GPS RTK height measurements and from
vertical accelerations measured by linear accelerometers'

Why  not keep it simple: platform_heave (m) = upwards vertical displacement?  
Do we need
to be more specific than that?

Thanks - Nan

On 5/31/18 5:01 AM, Hamilton, Steve wrote:


Thanks for everyone's input, the below seems acceptable for now

Regards

Steve

From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> On 
Behalf Of Lowry, Roy K.
Sent: 30 May 2018 21:37
To: Jim Biard <mailto:jbi...@cicsnc.org>; 
cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

An afterthought. Heave is conventionally positive upwards so to make this clear 
I would add the word 'upwards' thus:

platform_heave (m) = upwards vertical displacement determined by integrating 
vertical accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = upwards vertical velocity determined by 
integrating vertical accelerations of a platform that is nominally at rest.

Cheers. Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu> 
<mailto:cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu>>
 on behalf of Lowry, Roy K. mailto:r...@bodc.ac.uk> 
<mailto:r...@bodc.ac.uk><mailto:r...@bodc.ac.uk>>
Sent: 30 May 2018 21:02
To: Jim Biard; cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu> 
<mailto:cf-metadata@cgd.ucar.edu><mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

Thanks Jim,

That work for me.

Cheers, Roy.



From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu> 
<mailto:cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu>>
 on behalf of Jim Biard mailto:jbi...@cicsnc.org> 
<mailto:jbi...@cicsnc.org><mailto:jbi...@cicsnc.org>>
Sent: 30 May 2018 18:39
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu> 
<mailto:cf-metadata@cgd.ucar.edu><mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

Roy,

So, heave is integrated vertical acceleration? How about

platform_heave (m) = vertical displacement determined by integrating vertical 
accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = vertical velocity determined by integrating 
vertical accelerations of a platform that is nominally at rest.

Jim

On 5/27/18 5:38 AM, Lowry, Roy K. wrote:

Hi Jim,

Does

 "Heave" 

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

I'm equally happy with this.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 01 June 2018 22:56
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Nan,

Thanks for pulling things back in. I very much like the idea of keeping 
technology or specific methods out of the definition if at all possible, so I 
like your proposal. I expect we should include platform in the definition, as 
well as an indication that this is dynamic (over time). How about these 
definitions?

platform_heave (m) = upwards vertical displacement of a platform over a 
measurement time interval

platform_heave_rate (m s-1) = upwards rate of change in vertical displacement 
of a platform over a measurement time interval

They leave out some detail but capture the relative nature of the quantities.

(In my mind, the primary detail being left out is the 'net zero' nature of the 
quantities, which gets back to defining the 'moving-mean' sea level reference 
point.)

Grace and peace,

Jim

On 6/1/18 11:23 AM, Nan Galbraith wrote:
Hi all -

The latest version is confusing to me. The term 'a platform that is nominally 
at rest' does
not apply to many platforms for which heave is calculated; the original version 
of that,
'a moving object above the vertical level of that object when stationary' was 
maybe a little
more clear... if also a little wordy.

And, the term  'vertical displacement determined by integrating vertical 
accelerations' may
also not apply - I've been looking at the different ways heave is calculated, 
and there
are a few: 'Heave can be computed from GPS RTK height measurements and from
vertical accelerations measured by linear accelerometers'

Why  not keep it simple: platform_heave (m) = upwards vertical displacement?  
Do we need
to be more specific than that?

Thanks - Nan

On 5/31/18 5:01 AM, Hamilton, Steve wrote:

Thanks for everyone’s input, the below seems acceptable for now

Regards

Steve

From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> On 
Behalf Of Lowry, Roy K.
Sent: 30 May 2018 21:37
To: Jim Biard <mailto:jbi...@cicsnc.org>; 
cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

An afterthought. Heave is conventionally positive upwards so to make this clear 
I would add the word 'upwards' thus:

platform_heave (m) = upwards vertical displacement determined by integrating 
vertical accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = upwards vertical velocity determined by 
integrating vertical accelerations of a platform that is nominally at rest.

Cheers. Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu> 
<mailto:cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu>>
 on behalf of Lowry, Roy K. mailto:r...@bodc.ac.uk> 
<mailto:r...@bodc.ac.uk><mailto:r...@bodc.ac.uk>>
Sent: 30 May 2018 21:02
To: Jim Biard; cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu> 
<mailto:cf-metadata@cgd.ucar.edu><mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

Thanks Jim,

That work for me.

Cheers, Roy.



From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu> 
<mailto:cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu>>
 on behalf of Jim Biard mailto:jbi...@cicsnc.org> 
<mailto:jbi...@cicsnc.org><mailto:jbi...@cicsnc.org>>
Sent: 30 May 2018 18:39
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu> 
<mailto:cf-metadata@cgd.ucar.edu><mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

Roy,

So, heave is integrated vertical acceleration? How about

platform_heave (m) = vertical displacement determined by integrating vertical 
accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = vertical velocity determined by integrating 
vertical accelerations of a platform that is nominally at rest.

Jim

On 5/27/18 5:38 AM, Lowry, Roy K. wrote:

Hi Jim,

Does

 "Heave" is a term used to describe the vertical displacement
of a moving object above the vertical level of that object
when stationary.

help by getting rid of the semantically-loaded word 'height'?
If not, what would?

I think the confusion is because you are thinking of heave in
terms of position within a reference frame. To think of it as the
vertical displacement between a real platform and a massless
platform is mislea

Re: [CF-metadata] Platform Heave

[Jim Biard]

Nan,

Thanks for pulling things back in. I very much like the idea of keeping 
technology or specific methods out of the definition if at all possible, 
so I like your proposal. I expect we should include platform in the 
definition, as well as an indication that this is dynamic (over time). 
How about these definitions?


platform_heave (m) = upwards vertical displacement of a platform over a 
measurement time interval


platform_heave_rate (m s-1) = upwards rate of change in vertical 
displacement of a platform over a measurement time interval


They leave out some detail but capture the relative nature of the 
quantities.


(In my mind, the primary detail being left out is the 'net zero' nature 
of the quantities, which gets back to defining the 'moving-mean' sea 
level reference point.)


Grace and peace,

Jim

On 6/1/18 11:23 AM, Nan Galbraith wrote:

Hi all -

The latest version is confusing to me. The term 'a platform that is 
nominally at rest' does
not apply to many platforms for which heave is calculated; the 
original version of that,
'a moving object above the vertical level of that object when 
stationary' was maybe a little

more clear... if also a little wordy.

And, the term  'vertical displacement determined by integrating 
vertical accelerations' may
also not apply - I've been looking at the different ways heave is 
calculated, and there
are a few: 'Heave can be computed from GPS RTK height measurements and 
from

vertical accelerations measured by linear accelerometers'

Why  not keep it simple: platform_heave (m) = upwards vertical 
displacement?  Do we need

to be more specific than that?

Thanks - Nan

On 5/31/18 5:01 AM, Hamilton, Steve wrote:


Thanks for everyone’s input, the below seems acceptable for now

Regards

Steve

From: CF-metadata  On Behalf Of 
Lowry, Roy K.

Sent: 30 May 2018 21:37
To: Jim Biard ; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

An afterthought. Heave is conventionally positive upwards so to make 
this clear I would add the word 'upwards' thus:


platform_heave (m) = upwards vertical displacement determined by 
integrating vertical accelerations of a platform that is nominally at 
rest.


platform_heave_rate (m s-1) = upwards vertical velocity determined by 
integrating vertical accelerations of a platform that is nominally at 
rest.


Cheers. Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.




From: CF-metadata <mailto:cf-metadata-boun...@cgd.ucar.edu>> on behalf of Lowry, Roy K. 
mailto:r...@bodc.ac.uk>>

Sent: 30 May 2018 21:02
To: Jim Biard; cf-metadata@cgd.ucar.edu 
<mailto:cf-metadata@cgd.ucar.edu>

Subject: Re: [CF-metadata] Platform Heave

Thanks Jim,

That work for me.

Cheers, Roy.



From: CF-metadata <mailto:cf-metadata-boun...@cgd.ucar.edu>> on behalf of Jim Biard 
mailto:jbi...@cicsnc.org>>

Sent: 30 May 2018 18:39
To: cf-metadata@cgd.ucar.edu <mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

Roy,

So, heave is integrated vertical acceleration? How about

platform_heave (m) = vertical displacement determined by integrating 
vertical accelerations of a platform that is nominally at rest.


platform_heave_rate (m s-1) = vertical velocity determined by 
integrating vertical accelerations of a platform that is nominally at 
rest.


Jim

On 5/27/18 5:38 AM, Lowry, Roy K. wrote:

    Hi Jim,

    Does

     "Heave" is a term used to describe the vertical displacement
    of a moving object above the vertical level of that object
    when stationary.

    help by getting rid of the semantically-loaded word 'height'?
    If not, what would?

    I think the confusion is because you are thinking of heave in
    terms of position within a reference frame. To think of it as the
    vertical displacement between a real platform and a massless
    platform is misleading- such considerations are part of the
    derivation of wave height from high frequency heave measurements,
    which isn't relevant to a discussion of the raw measurement. It's
    also worth bearing in mind that whilst the debate has focused on
    platforms floating on the sea surface, the concept of heave could
    in theory be applied to objects in the atmosphere.

    In practice, heave is measured by accelerometers that are usually
    combined with tilt sensors that give pitch, roll and yaw. Hence,
    it is totally decoupled from any reference outside the platform.

    To answer your last muse, to get heave from a high frequency
    height relative to datum time series the method would need to
    determine the height of the object when 'stationary'. In the case
    of objects on the sea, 'stationary' is considered to be a flat
    calm sea (i.e. no waves), whi

Re: [CF-metadata] Platform Heave

[Nan Galbraith]

Hi all -

The latest version is confusing to me. The term 'a platform that is 
nominally at rest' does
not apply to many platforms for which heave is calculated; the original 
version of that,
'a moving object above the vertical level of that object when 
stationary' was maybe a little

more clear... if also a little wordy.

And, the term  'vertical displacement determined by integrating vertical 
accelerations' may
also not apply - I've been looking at the different ways heave is 
calculated, and there

are a few: 'Heave can be computed from GPS RTK height measurements and from
vertical accelerations measured by linear accelerometers'

Why  not keep it simple: platform_heave (m) = upwards vertical 
displacement?  Do we need

to be more specific than that?

Thanks - Nan

On 5/31/18 5:01 AM, Hamilton, Steve wrote:


Thanks for everyone’s input, the below seems acceptable for now

Regards

Steve

From: CF-metadata  On Behalf Of 
Lowry, Roy K.

Sent: 30 May 2018 21:37
To: Jim Biard ; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

An afterthought. Heave is conventionally positive upwards so to make 
this clear I would add the word 'upwards' thus:


platform_heave (m) = upwards vertical displacement determined by 
integrating vertical accelerations of a platform that is nominally at 
rest.


platform_heave_rate (m s-1) = upwards vertical velocity determined by 
integrating vertical accelerations of a platform that is nominally at 
rest.


Cheers. Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.




From: CF-metadata <mailto:cf-metadata-boun...@cgd.ucar.edu>> on behalf of Lowry, Roy K. 
mailto:r...@bodc.ac.uk>>

Sent: 30 May 2018 21:02
To: Jim Biard; cf-metadata@cgd.ucar.edu <mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

Thanks Jim,

That work for me.

Cheers, Roy.



From: CF-metadata <mailto:cf-metadata-boun...@cgd.ucar.edu>> on behalf of Jim Biard 
mailto:jbi...@cicsnc.org>>

Sent: 30 May 2018 18:39
To: cf-metadata@cgd.ucar.edu <mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

Roy,

So, heave is integrated vertical acceleration? How about

platform_heave (m) = vertical displacement determined by integrating 
vertical accelerations of a platform that is nominally at rest.


platform_heave_rate (m s-1) = vertical velocity determined by 
integrating vertical accelerations of a platform that is nominally at 
rest.


Jim

On 5/27/18 5:38 AM, Lowry, Roy K. wrote:

Hi Jim,

Does

 "Heave" is a term used to describe the vertical displacement
of a moving object above the vertical level of that object
when stationary.

help by getting rid of the semantically-loaded word 'height'?
If not, what would?

I think the confusion is because you are thinking of heave in
terms of position within a reference frame. To think of it as the
vertical displacement between a real platform and a massless
platform is misleading- such considerations are part of the
derivation of wave height from high frequency heave measurements,
which isn't relevant to a discussion of the raw measurement. It's
also worth bearing in mind that whilst the debate has focused on
platforms floating on the sea surface, the concept of heave could
in theory be applied to objects in the atmosphere.

In practice, heave is measured by accelerometers that are usually
combined with tilt sensors that give pitch, roll and yaw. Hence,
it is totally decoupled from any reference outside the platform.

To answer your last muse, to get heave from a high frequency
height relative to datum time series the method would need to
determine the height of the object when 'stationary'. In the case
of objects on the sea, 'stationary' is considered to be a flat
calm sea (i.e. no waves), which can be approximated by averaging
the raw time series. So, heave could be approximated by
differencing the raw and averaged data. However, I can't think why
anybody would want to do that.

Cheers, Roy.



From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> on behalf of Jim Biard
 <mailto:jbi...@cicsnc.org>
Sent: 26 May 2018 23:18
To: cf-metadata@cgd.ucar.edu <mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

My biggest concern is that the standard name definition makes it
clear in some fashion or other that this is a measure of
deviations from some lower frequency (or low-pass filtered)
measure of vertical position. (As are sway and surge in relation
to their corres

Re: [CF-metadata] Platform Heave

[Hamilton, Steve]

Thanks for everyone's input, the below seems acceptable for now

Regards

Steve

From: CF-metadata  On Behalf Of Lowry, Roy K.
Sent: 30 May 2018 21:37
To: Jim Biard ; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


An afterthought. Heave is conventionally positive upwards so to make this clear 
I would add the word 'upwards' thus:



platform_heave (m) = upwards vertical displacement determined by integrating 
vertical accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = upwards vertical velocity determined by 
integrating vertical accelerations of a platform that is nominally at rest.



Cheers. Roy.




I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu>> on 
behalf of Lowry, Roy K. mailto:r...@bodc.ac.uk>>
Sent: 30 May 2018 21:02
To: Jim Biard; cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave


Thanks Jim,



That work for me.



Cheers, Roy.



I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu>> on 
behalf of Jim Biard mailto:jbi...@cicsnc.org>>
Sent: 30 May 2018 18:39
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave


Roy,



So, heave is integrated vertical acceleration? How about



platform_heave (m) = vertical displacement determined by integrating vertical 
accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = vertical velocity determined by integrating 
vertical accelerations of a platform that is nominally at rest.



Jim

On 5/27/18 5:38 AM, Lowry, Roy K. wrote:

Hi Jim,



Does


 "Heave" is a term used to describe the vertical displacement of a moving 
object above the vertical level of that object when stationary.

help by getting rid of the semantically-loaded word 'height'? If not, what 
would?

I think the confusion is because you are thinking of heave in terms of position 
within a reference frame. To think of it as the vertical displacement between a 
real platform and a massless platform is misleading- such considerations are 
part of the derivation of wave height from high frequency heave measurements, 
which isn't relevant to a discussion of the raw measurement. It's also worth 
bearing in mind that whilst the debate has focused on platforms floating on the 
sea surface, the concept of heave could in theory be applied to objects in the 
atmosphere.

In practice, heave is measured by accelerometers that are usually combined with 
tilt sensors that give pitch, roll and yaw. Hence, it is totally decoupled from 
any reference outside the platform.

To answer your last muse, to get heave from a high frequency height relative to 
datum time series the method would need to determine the height of the object 
when 'stationary'. In the case of objects on the sea, 'stationary' is 
considered to be a flat calm sea (i.e. no waves), which can be approximated by 
averaging the raw time series. So, heave could be approximated by differencing 
the raw and averaged data. However, I can't think why anybody would want to do 
that.


Cheers, Roy.



I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Jim Biard <mailto:jbi...@cicsnc.org>
Sent: 26 May 2018 23:18
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

My biggest concern is that the standard name definition makes it clear in some 
fashion or other that this is a measure of deviations from some lower frequency 
(or low-pass filtered) measure of vertical position. (As are sway and surge in 
relation to their corresponding horizontal coordinates.) As was pointed out, 
heave is used in certain communities, so it's reasonable to provide a standard 
name, but it seems rather imprecise as it has been described so far.

If I have understood the explanations correctly, a time series of platform 
height relative to a fixed datum that has sufficient precision and frequency 
would fully represent the heave along with the more slowly varying effects of 
tide, waves, etc. So is heave, as usually used, the first-order instantaneous 
difference between the height of an actual platform and the height of a 
massless ideal platform that would maintain a fixed offset relative to the sea 
surface? And, just out of curiosity, how would a time series of instantaneous 
measures of height relative to a fixed datum be separated in practice into 
heave and "non-heave" height?

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

An afterthought. Heave is conventionally positive upwards so to make this clear 
I would add the word 'upwards' thus:


platform_heave (m) = upwards vertical displacement determined by integrating 
vertical accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = upwards vertical velocity determined by 
integrating vertical accelerations of a platform that is nominally at rest.


Cheers. Roy.



I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Lowry, Roy K. 

Sent: 30 May 2018 21:02
To: Jim Biard; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Thanks Jim,


That work for me.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 30 May 2018 18:39
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Roy,


So, heave is integrated vertical acceleration? How about


platform_heave (m) = vertical displacement determined by integrating vertical 
accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = vertical velocity determined by integrating 
vertical accelerations of a platform that is nominally at rest.


Jim

On 5/27/18 5:38 AM, Lowry, Roy K. wrote:

Hi Jim,


Does


 "Heave" is a term used to describe the vertical displacement of a moving 
object above the vertical level of that object when stationary.

help by getting rid of the semantically-loaded word 'height'? If not, what 
would?

I think the confusion is because you are thinking of heave in terms of position 
within a reference frame. To think of it as the vertical displacement between a 
real platform and a massless platform is misleading- such considerations are 
part of the derivation of wave height from high frequency heave measurements, 
which isn't relevant to a discussion of the raw measurement. It's also worth 
bearing in mind that whilst the debate has focused on platforms floating on the 
sea surface, the concept of heave could in theory be applied to objects in the 
atmosphere.

In practice, heave is measured by accelerometers that are usually combined with 
tilt sensors that give pitch, roll and yaw. Hence, it is totally decoupled from 
any reference outside the platform.

To answer your last muse, to get heave from a high frequency height relative to 
datum time series the method would need to determine the height of the object 
when 'stationary'. In the case of objects on the sea, 'stationary' is 
considered to be a flat calm sea (i.e. no waves), which can be approximated by 
averaging the raw time series. So, heave could be approximated by differencing 
the raw and averaged data. However, I can't think why anybody would want to do 
that.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Jim Biard <mailto:jbi...@cicsnc.org>
Sent: 26 May 2018 23:18
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

My biggest concern is that the standard name definition makes it clear in some 
fashion or other that this is a measure of deviations from some lower frequency 
(or low-pass filtered) measure of vertical position. (As are sway and surge in 
relation to their corresponding horizontal coordinates.) As was pointed out, 
heave is used in certain communities, so it's reasonable to provide a standard 
name, but it seems rather imprecise as it has been described so far.

If I have understood the explanations correctly, a time series of platform 
height relative to a fixed datum that has sufficient precision and frequency 
would fully represent the heave along with the more slowly varying effects of 
tide, waves, etc. So is heave, as usually used, the first-order instantaneous 
difference between the height of an actual platform and the height of a 
massless ideal platform that would maintain a fixed offset relative to the sea 
surface? And, just out of curiosity, how would a time series of instantaneous 
measures of height relative to a fixed datum be separated in practice into 
heave and "non-heave" height?

Getting back on track, it seems to me that the definition ought to somehow 
assist the reader in understanding how heave relates to other measures of 
height.

[CICS-NC]<http://www.cicsnc.org/>Visit us on
[https://ncics.org/wp-content/themes/ncics/img/NCICS_logo-560x292.png]<http://www.cicsnc.org/>

North Carolina Institute for Climate Studies<http://www.cicsnc.org/>
www.cicsnc.org<http://www.cicsnc.org>
The North Carolina Institute for Climate Stud

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Thanks Jim,


That work for me.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 30 May 2018 18:39
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Roy,


So, heave is integrated vertical acceleration? How about


platform_heave (m) = vertical displacement determined by integrating vertical 
accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = vertical velocity determined by integrating 
vertical accelerations of a platform that is nominally at rest.


Jim

On 5/27/18 5:38 AM, Lowry, Roy K. wrote:

Hi Jim,


Does


 "Heave" is a term used to describe the vertical displacement of a moving 
object above the vertical level of that object when stationary.

help by getting rid of the semantically-loaded word 'height'? If not, what 
would?

I think the confusion is because you are thinking of heave in terms of position 
within a reference frame. To think of it as the vertical displacement between a 
real platform and a massless platform is misleading- such considerations are 
part of the derivation of wave height from high frequency heave measurements, 
which isn't relevant to a discussion of the raw measurement. It's also worth 
bearing in mind that whilst the debate has focused on platforms floating on the 
sea surface, the concept of heave could in theory be applied to objects in the 
atmosphere.

In practice, heave is measured by accelerometers that are usually combined with 
tilt sensors that give pitch, roll and yaw. Hence, it is totally decoupled from 
any reference outside the platform.

To answer your last muse, to get heave from a high frequency height relative to 
datum time series the method would need to determine the height of the object 
when 'stationary'. In the case of objects on the sea, 'stationary' is 
considered to be a flat calm sea (i.e. no waves), which can be approximated by 
averaging the raw time series. So, heave could be approximated by differencing 
the raw and averaged data. However, I can't think why anybody would want to do 
that.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Jim Biard <mailto:jbi...@cicsnc.org>
Sent: 26 May 2018 23:18
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

My biggest concern is that the standard name definition makes it clear in some 
fashion or other that this is a measure of deviations from some lower frequency 
(or low-pass filtered) measure of vertical position. (As are sway and surge in 
relation to their corresponding horizontal coordinates.) As was pointed out, 
heave is used in certain communities, so it's reasonable to provide a standard 
name, but it seems rather imprecise as it has been described so far.

If I have understood the explanations correctly, a time series of platform 
height relative to a fixed datum that has sufficient precision and frequency 
would fully represent the heave along with the more slowly varying effects of 
tide, waves, etc. So is heave, as usually used, the first-order instantaneous 
difference between the height of an actual platform and the height of a 
massless ideal platform that would maintain a fixed offset relative to the sea 
surface? And, just out of curiosity, how would a time series of instantaneous 
measures of height relative to a fixed datum be separated in practice into 
heave and "non-heave" height?

Getting back on track, it seems to me that the definition ought to somehow 
assist the reader in understanding how heave relates to other measures of 
height.

[CICS-NC]<http://www.cicsnc.org/>Visit us on
[https://ncics.org/wp-content/themes/ncics/img/NCICS_logo-560x292.png]<http://www.cicsnc.org/>

North Carolina Institute for Climate Studies<http://www.cicsnc.org/>
www.cicsnc.org<http://www.cicsnc.org>
The North Carolina Institute for Climate Studies is a unique center of 
excellence showcasing a partnership between universities, the private sector, 
non-profit organizations, community groups, and the federal government.



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: jbi...@cicsnc.org<mailto:jbi...@cicsnc.org>
o: +1 828 271 4900

Connect with us on Facebook for 
climate<http://www.facebook.com/NOAANCEIclimate> and ocea

Re: [CF-metadata] Platform Heave

[Jim Biard]

Roy,


So, heave is integrated vertical acceleration? How about


platform_heave (m) = vertical displacement determined by integrating 
vertical accelerations of a platform that is nominally at rest.


platform_heave_rate (m s-1) = vertical velocity determined by 
integrating vertical accelerations of a platform that is nominally at rest.



Jim


On 5/27/18 5:38 AM, Lowry, Roy K. wrote:


Hi Jim,


Does


 "Heave" is a term used to describe the vertical displacement of a 
moving object above the vertical level of that object when stationary.


help by getting rid of the semantically-loaded word 'height'? If not, 
what would?


I think the confusion is because you are thinking of heave in terms of 
position within a reference frame. To think of it as the vertical 
displacement between a real platform and a massless platform is 
misleading- such considerations are part of the derivation of wave 
height from high frequency heave measurements, which isn't relevant 
to a discussion of the raw measurement. It's also worth bearing in 
mind that whilst the debate has focused on platforms floating on the 
sea surface, the concept of heave could in theory be applied to 
objects in the atmosphere.


In practice, heave is measured by accelerometers that are usually 
combined with tilt sensors that give pitch, roll and yaw. Hence, it is 
totally decoupled from any reference outside the platform.


To answer your last muse, to get heave from a high frequency height 
relative to datum time series the method would need to determine the 
height of the object when 'stationary'. In the case of objects on the 
sea, 'stationary' is considered to be a flat calm sea (i.e. no waves), 
which can be approximated by averaging the raw time series. So, heave 
could be approximated by differencing the raw and averaged data. 
However, I can't think why anybody would want to do that.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an 
Emeritus Fellowship using this e-mail address.





*From:* CF-metadata  on behalf of 
Jim Biard 

*Sent:* 26 May 2018 23:18
*To:* cf-metadata@cgd.ucar.edu
*Subject:* Re: [CF-metadata] Platform Heave
My biggest concern is that the standard name definition makes it clear 
in some fashion or other that this is a measure of deviations from 
some lower frequency (or low-pass filtered) measure of vertical 
position. (As are sway and surge in relation to their corresponding 
horizontal coordinates.) As was pointed out, heave is used in certain 
communities, so it's reasonable to provide a standard name, but it 
seems rather imprecise as it has been described so far.


If I have understood the explanations correctly, a time series of 
platform height relative to a fixed datum that has sufficient 
precision and frequency would fully represent the heave along with the 
more slowly varying effects of tide, waves, etc. So is heave, as 
usually used, the first-order instantaneous difference between the 
height of an actual platform and the height of a massless ideal 
platform that would maintain a fixed offset relative to the sea 
surface? And, just out of curiosity, how would a time series of 
instantaneous measures of height relative to a fixed datum be 
separated in practice into heave and "non-heave" height?


Getting back on track, it seems to me that the definition ought to 
somehow assist the reader in understanding how heave relates to other 
measures of height.


CICS-NC <http://www.cicsnc.org/>Visit us on
<http://www.cicsnc.org/>

North Carolina Institute for Climate Studies <http://www.cicsnc.org/>
www.cicsnc.org
The North Carolina Institute for Climate Studies is a unique center of 
excellence showcasing a partnership between universities, the private 
sector, non-profit organizations, community groups, and the federal 
government.




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: jbi...@cicsnc.org <mailto:jbi...@cicsnc.org>
o: +1 828 271 4900

/Connect with us on Facebook for climate 
<http://www.facebook.com/NOAANCEIclimate> and ocean and geophysics 
<http://www.facebook.com/NOAANCEIoceangeo> information, and follow us 
on Twitter at @NOAANCEIclimate 
<http://www.twitter.com/NOAANCEIclimate>and @NOAANCEIocngeo 
<http://www.twitter.com/NOAANCEIocngeo>.//


/


On Sat, May 26, 2018 at 3:11 AM, Lowry, Roy K. <mailto:r...@bodc.ac.uk>> wrote:


Dear Jim and John,


Heave is indeed a height relative to a datum, that datum being
the calm sea surface, which is 

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Jim,


Does


 "Heave" is a term used to describe the vertical displacement of a moving 
object above the vertical level of that object when stationary.

help by getting rid of the semantically-loaded word 'height'? If not, what 
would?

I think the confusion is because you are thinking of heave in terms of position 
within a reference frame. To think of it as the vertical displacement between a 
real platform and a massless platform is misleading- such considerations are 
part of the derivation of wave height from high frequency heave measurements, 
which isn't relevant to a discussion of the raw measurement. It's also worth 
bearing in mind that whilst the debate has focused on platforms floating on the 
sea surface, the concept of heave could in theory be applied to objects in the 
atmosphere.

In practice, heave is measured by accelerometers that are usually combined with 
tilt sensors that give pitch, roll and yaw. Hence, it is totally decoupled from 
any reference outside the platform.

To answer your last muse, to get heave from a high frequency height relative to 
datum time series the method would need to determine the height of the object 
when 'stationary'. In the case of objects on the sea, 'stationary' is 
considered to be a flat calm sea (i.e. no waves), which can be approximated by 
averaging the raw time series. So, heave could be approximated by differencing 
the raw and averaged data. However, I can't think why anybody would want to do 
that.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Jim Biard 
<jbi...@cicsnc.org>
Sent: 26 May 2018 23:18
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

My biggest concern is that the standard name definition makes it clear in some 
fashion or other that this is a measure of deviations from some lower frequency 
(or low-pass filtered) measure of vertical position. (As are sway and surge in 
relation to their corresponding horizontal coordinates.) As was pointed out, 
heave is used in certain communities, so it's reasonable to provide a standard 
name, but it seems rather imprecise as it has been described so far.

If I have understood the explanations correctly, a time series of platform 
height relative to a fixed datum that has sufficient precision and frequency 
would fully represent the heave along with the more slowly varying effects of 
tide, waves, etc. So is heave, as usually used, the first-order instantaneous 
difference between the height of an actual platform and the height of a 
massless ideal platform that would maintain a fixed offset relative to the sea 
surface? And, just out of curiosity, how would a time series of instantaneous 
measures of height relative to a fixed datum be separated in practice into 
heave and "non-heave" height?

Getting back on track, it seems to me that the definition ought to somehow 
assist the reader in understanding how heave relates to other measures of 
height.

[CICS-NC]<http://www.cicsnc.org/>Visit us on
[https://ncics.org/wp-content/themes/ncics/img/NCICS_logo-560x292.png]<http://www.cicsnc.org/>

North Carolina Institute for Climate Studies<http://www.cicsnc.org/>
www.cicsnc.org
The North Carolina Institute for Climate Studies is a unique center of 
excellence showcasing a partnership between universities, the private sector, 
non-profit organizations, community groups, and the federal government.



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: jbi...@cicsnc.org<mailto:jbi...@cicsnc.org>
o: +1 828 271 4900

Connect with us on Facebook for 
climate<http://www.facebook.com/NOAANCEIclimate> and ocean and 
geophysics<http://www.facebook.com/NOAANCEIoceangeo> information, and follow us 
on Twitter at @NOAANCEIclimate <http://www.twitter.com/NOAANCEIclimate> and 
@NOAANCEIocngeo<http://www.twitter.com/NOAANCEIocngeo>.



On Sat, May 26, 2018 at 3:11 AM, Lowry, Roy K. 
<r...@bodc.ac.uk<mailto:r...@bodc.ac.uk>> wrote:

Dear Jim and John,


Heave is indeed a height relative to a datum, that datum being the calm sea 
surface, which is a local short interval mean sea level that isn't linked into 
any global reference system.  Indeed the 'datum' moves relative to the rest of 
the world - but not the platform - as tide rises and falls so many would prefer 
to call it an 'instrument zero' rather than a 'datum'.


Heave is therefore a very different measurement to any sea l

Re: [CF-metadata] Platform Heave

[Jim Biard]

My biggest concern is that the standard name definition makes it clear in
some fashion or other that this is a measure of deviations from some lower
frequency (or low-pass filtered) measure of vertical position. (As are sway
and surge in relation to their corresponding horizontal coordinates.) As
was pointed out, heave is used in certain communities, so it's reasonable
to provide a standard name, but it seems rather imprecise as it has been
described so far.

If I have understood the explanations correctly, a time series of platform
height relative to a fixed datum that has sufficient precision and
frequency would fully represent the heave along with the more slowly
varying effects of tide, waves, etc. So is heave, as usually used, the
first-order instantaneous difference between the height of an actual
platform and the height of a massless ideal platform that would maintain a
fixed offset relative to the sea surface? And, just out of curiosity, how
would a time series of instantaneous measures of height relative to a fixed
datum be separated in practice into heave and "non-heave" height?

Getting back on track, it seems to me that the definition ought to somehow
assist the reader in understanding how heave relates to other measures of
height.

[image: 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: jbi...@cicsnc.org
o: +1 828 271 4900

*Connect with us on Facebook for climate
<http://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<http://www.facebook.com/NOAANCEIoceangeo> information, and follow us on
Twitter at @NOAANCEIclimate
<http://www.twitter.com/NOAANCEIclimate>and @NOAANCEIocngeo
<http://www.twitter.com/NOAANCEIocngeo>.*


On Sat, May 26, 2018 at 3:11 AM, Lowry, Roy K. <r...@bodc.ac.uk> wrote:

> Dear Jim and John,
>
>
> Heave is indeed a height relative to a datum, that datum being the calm
> sea surface, which is a local short interval mean sea level that isn't
> linked into any global reference system.  Indeed the 'datum' moves relative
> to the rest of the world - but not the platform - as tide rises and falls
> so many would prefer to call it an 'instrument zero' rather than a 'datum'.
>
>
> Heave is therefore a very different measurement to any sea level parameter
> and is the raw measurement recorded at high (Hz to kHz) frequency as a time
> series by floating wave instruments such as waveriders and shipborne wave
> recorders. It therefore cannot be sensibly described by the same or
> similar Standard Name as a measurement of height above a globally
> referenced datum like long-term mean sea level or geoid. Whilst the
> Standard Name could be 'platform_height_above_calm_sea_surface'  or
> 'platform_height_above_stationary_position' I would argue that 'heave' is
> a term from the same domain vocabulary as 'pitch', 'roll' and 'yaw' and
> therefore should be used.
>
>
> John is right to point out that the heave measurement is affected by the
> nature of the platform with a 250,000 tonne supertanker moving up and down
> much less than a rowing boat in a given wave climate, especially a wind
> sea. That was what was behind the SBWR corrections based on platform
> dimensions set up by Laurie Draper and Tom Tucker back in the 1980s.
>
>
> Cheers, Roy.
>
>
> I am retiring on 31/05/2018 but will continue to be active through an
> Emeritus Fellowship using this e-mail address.
>
>
> --
> *From:* CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of John
> Helly <hel...@ucsd.edu>
> *Sent:* 26 May 2018 04:48
> *To:* Jim Biard; cf-metadata@cgd.ucar.edu
> *Subject:* Re: [CF-metadata] Platform Heave
>
>
> Can't let go of this yet.
>
> If you think about the inverse problem of deriving the sea surface
> elevation from the heave you would have to account for the latency of ship
> motion relative to the sea-surface. A  wave passing under a ship induces
> motions that are not instantaneous either in attack or decay.
>
> J.
>
> On 5/25/18 20:42, John Helly wrote:
>
> I believe it's a synonym within the oceanographic community for the
> vertical motion of an ocean-going platform.
>
> https://en.wikipedia.org/wiki/Ship_motions
> Ship motions - Wikipedia <https://en.wikipedia.org/wiki/Ship_motions>
> en.wikipedia.org
> Ship motions are defined by the six degrees of freedom that a ship, boat
> or any other craft can experience.
>

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Jim and John,


Heave is indeed a height relative to a datum, that datum being the calm sea 
surface, which is a local short interval mean sea level that isn't linked into 
any global reference system.  Indeed the 'datum' moves relative to the rest of 
the world - but not the platform - as tide rises and falls so many would prefer 
to call it an 'instrument zero' rather than a 'datum'.


Heave is therefore a very different measurement to any sea level parameter and 
is the raw measurement recorded at high (Hz to kHz) frequency as a time series 
by floating wave instruments such as waveriders and shipborne wave recorders. 
It therefore cannot be sensibly described by the same or similar Standard Name 
as a measurement of height above a globally referenced datum like long-term 
mean sea level or geoid. Whilst the Standard Name could be 
'platform_height_above_calm_sea_surface'  or 
'platform_height_above_stationary_position' I would argue that 'heave' is a 
term from the same domain vocabulary as 'pitch', 'roll' and 'yaw' and therefore 
should be used.


John is right to point out that the heave measurement is affected by the nature 
of the platform with a 250,000 tonne supertanker moving up and down much less 
than a rowing boat in a given wave climate, especially a wind sea. That was 
what was behind the SBWR corrections based on platform dimensions set up by 
Laurie Draper and Tom Tucker back in the 1980s.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of John Helly 
<hel...@ucsd.edu>
Sent: 26 May 2018 04:48
To: Jim Biard; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Can't let go of this yet.

If you think about the inverse problem of deriving the sea surface elevation 
from the heave you would have to account for the latency of ship motion 
relative to the sea-surface. A  wave passing under a ship induces motions that 
are not instantaneous either in attack or decay.

J.

On 5/25/18 20:42, John Helly wrote:

I believe it's a synonym within the oceanographic community for the vertical 
motion of an ocean-going platform.

https://en.wikipedia.org/wiki/Ship_motions

Ship motions - Wikipedia<https://en.wikipedia.org/wiki/Ship_motions>
en.wikipedia.org
Ship motions are defined by the six degrees of freedom that a ship, boat or any 
other craft can experience.



Could just be jargon but it strike me as more complex: nonetheless a vertical 
position relative to a datum, but the buoyancy, stability and momentum of the 
platform are implied as part of the dynamics.  It seems that the datum is not a 
geophysical one alone but confounded with the 'normal' waterline for a platform 
so it may be relative to the water level in which the platform is embedded.  
That's a tough one.  Two different platforms on the same sea surface would have 
different 'heave', for example.

J.

On 5/25/18 19:54, Jim Biard wrote:
Hi.

I get and endorse the need for pitch, roll, and yaw, but I remain perplexed 
about heave. How is a time series of 'heave' different from a time series of 
height relative to some vertical datum? I've yet to see a proposed definition 
that convinces me that this is a uniquely different quantity.

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: jbi...@cicsnc.org<mailto:jbi...@cicsnc.org>
o: +1 828 271 4900

Connect with us on Facebook for 
climate<http://www.facebook.com/NOAANCEIclimate> and ocean and 
geophysics<http://www.facebook.com/NOAANCEIoceangeo> information, and follow us 
on Twitter at @NOAANCEIclimate <http://www.twitter.com/NOAANCEIclimate> and 
@NOAANCEIocngeo<http://www.twitter.com/NOAANCEIocngeo>.



On Fri, May 25, 2018 at 7:28 AM, Lowry, Roy K. 
<r...@bodc.ac.uk<mailto:r...@bodc.ac.uk>> wrote:

Dear All,


I agree with Nan that definitions of pitch roll and yaw would improve the 
existing Standard Name definitions. I also agree with using the existing 
orientation Standard Names for ADCPs and that the 'platform' definition wording 
could make this clearer. However, such an enhancements should be submitted as a 
separate proposal and not be considered as part of Steve's proposal.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
<cf-metadata-boun...@cgd.ucar.edu<mailto:cf