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 Archival Email: alison.pamment at stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.
From: CF-metadata <cf-metadata-bounces at cgd.ucar.edu> On Behalf Of Lowry, Roy K.
Sent: 20 September 2018 15:38
To: cf-metadata at cgd.ucar.edu; ngalbraith at 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-bounces at cgd.ucar.edu> on behalf of Nan Galbraith <mailto:ngalbraith at whoi.edu>
Sent: 20 September 2018 15:11
To: mailto:cf-metadata at 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.pamment at stfc.ac.uk>
> *Sent:* 19 September 2018 19:04
> *To:* Lowry, Roy K.; Jim Biard; mailto:cf-metadata at 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 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:
> mailto:alison.pamment at stfc.ac.uk
--
*******************************************************
* 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
mailto:CF-metadata at 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.
________________________________________
Received on Thu Sep 20 2018 - 08:59:51 BST
