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 <cf-metadata-bounces at cgd.ucar.edu> on behalf of Jonathan Gregory <j.m.gregory at reading.ac.uk>
Sent: 20 September 2018 16:16
To: cf-metadata at 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 <alison.pamment at stfc.ac.uk> -----
> Date: Thu, 20 Sep 2018 14:59:51 +0000
> From: Alison Pamment - UKRI STFC <alison.pamment at stfc.ac.uk>
> To: "rkl at bodc.ac.uk" <rkl at bodc.ac.uk>, "cf-metadata at cgd.ucar.edu"
> <cf-metadata at cgd.ucar.edu>, "ngalbraith at whoi.edu"
> <ngalbraith at 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 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.
> ________________________________________
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
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.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20180920/b96e9db6/attachment-0001.html>
Received on Thu Sep 20 2018 - 09:35:39 BST
