Hi Jonathan,
A quick message here, intended as much as anything for the email
archives, to make it clear that differences of viewpoint remain about
the use of negative depth values. The alternative viewpoint is that the
implicit semantics in the term "depth" is its _realm_: the variable name
"depth" tells us humans that one is referring to a location that lies
beneath the ocean (or earth) surface. Similarly for "Altitude". There
is no implied sign convention. Depths that are encoded as negatives
because the underlying mathematical axis is assigned as positive="up"
are supported by CF and have been in use by oceanographers for decades.
I believe the underlying issue is that geo-positioning variables have a
level of complexity not found in other parameters. Longitudes, for
example, have encoding variants, depending whether the branch point is
at Greenwich or at the Dateline. Yet CF simply calls them standard_name
"longitude" (see *). Time, too has many encodings, yet is simply
"time". This is not the case for _dependent_ variables such as
surface_net_downward_shortwave_flux. For dependent parameters, once the
units have been specified, we insist on a single fixed encoding, and the
sign convention is thereby captured (and great value to doing so!).
- Steve
(*) Further metadata to describe the longitude encoding would be a
valuable addition to CF. In discrete geometry files CF provide no
metadata-level clue about where the branch point lies. A client has to
scan the longitude values looking for clues.
=============================================================
On 1/30/2014 9:35 AM, Jonathan Gregory wrote:
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
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
