[CF-metadata] vertical coordinates and positive attributes

From: Jonathan Gregory <j.m.gregory>
Date: Thu, 30 Jan 2014 17:35:26 +0000

Dear all

For me it's an important principle that the standard names encapsulate a sign
convention when relevant, and that's been the case ever since we started to
define them 15 years ago. This is important because unclear sign conventions
are a real nuisance for data analysis. There hasn't been a need for an
explicit statement about "depth" because it is clear from the definition in
English, I would argue. We would not need two distinct standard names of depth
(vertical distance below the surface) and height (vertical distance above the
surface) if the sign convention was arbitrary, because an ambiguous sign would
make them synonymous. I would suggest that the inclusion of these two distinct
names is itself a statement that the sign is not arbitrary. It would be odd to
allow a height of 10 m above the ground to be encoded as -10 m. Surely no-one
would think that makes sense according to the definition, would they? If not,
it equally doesn't make sense to encode a depth of 10 m as -10 m.

There are many other standard names with implicit sign conventions e.g.
surface_net_downward_shortwave_flux. A positive number for that quantity
means a flux which is downward. It would be an error to use the opposite
sign convention for that quantity. Again, if the sign were arbitrary, we
would just have called it "net flux", not "net downward flux".

> Isn't the purpose of the standard name is to capture the semantics of a
> variable -- i.e. its physical interpretation? You are suggesting that a
> user of the file (or a search engine) should attach a different meaning to
> the concept of "DEPTH" in an ocean model based upon whether it is encoded as
> a positive or negative value. Do we attach a different interpretation to
> "TIME" because it is encoded as "days" versus "hours"?

Yes, I think the standard name is intended to capture the semantics (i.e.
the meaning) of the variable, and that includes its sign, in the case of
signed quantities. Height means positive upwards, depth means positive
downwards, temperature means warmer if the number is more positive, sea ice
thickness is a positive number which is bigger if the sea ice is thicker, and
so on. I think the user of the file should always apply the same, correct,
definition when interpreting numbers which have the standard_name of depth,
which is that, if they are positive, they refer to levels below the surface.
This is not a matter of units, like days versus hours. Depth is positive
downwards regardless of whether it is in millimetres or miles, just like
temperature is more positive when warmer regardless of whether it is Celsius
or Fahrenheit.

Ultimately standard names are for humans to interpret. I appreciate that
software may want to know which way up to plot the vertical axis, and the
positive attribute is useful for that. It is mandatory for vertical coordinate
variables (except pressure), so software shouldn't need to look anywhere
else for that information. As John said in his summary, it's not currently
in the standard for data variables, but we could change the convention to
recognise it as an optional attribute of data variables if that would help.

Best wishes

Jonathan
Received on Thu Jan 30 2014 - 10:35:26 GMT