[CF-metadata] Platform Heave

From: Jonathan Gregory <j.m.gregory>
Date: Fri, 31 Aug 2018 15:33:53 +0100

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
Received on Fri Aug 31 2018 - 08:33:53 BST