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 <[email protected]>
*Sent:* 19 September 2018 19:04
*To:* Lowry, Roy K.; Jim Biard; [email protected]
*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 sentence in the
definitions similar to that in the carbon_dioxide name.
There is just one problem with adopting my suggested approach - it
requires a change to the conventions. CF trac #155/GitHub issue #132
discusses the fact the current XML schema for the standard name table
actually doesn't allow for two names to have the same alias.
Personally, I think there are good reasons 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 Archival Email:
[email protected]
--
*******************************************************
* Nan Galbraith Information Systems Specialist *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 (508) 289-2444 *
*******************************************************
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
