Dear Steve
I agree that one can encode distances below the surface as negative and it's
often done. My point is that the CF standard name of "depth" is not appropriate
for such values; one should use "height" instead. The choice of which standard
name to use corresponds to the choice in a mathematical derivation that z is
positive upwards or z is positive downwards. The concept of depth doesn't
have an implicit sign convention, but the CF standard name does. CF altitude
means "geometric height above the geoid". This is also a signed quantity,
which can be used for levels both above and below the geoid. There is a CF
standard_name of bedrock_altitude, for instance, which could be of either sign
locally; its sign is not arbitrary.
I think the sign convention is one of many semantic markers which are encoded
together in standard names. The possibility has previously been discussed of
supplementing the standard name table with entries to indicate these semantic
components. That would not be an alternative to the standard_name itself, but
if there are aspects which need to be processed automatically, it would allow
them to be looked up. However, it would obviously take some work to go through
the standard_name table and decide for each one if positive was up, down or
irrelevant.
Best wishes
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
> >CF-metadata at cgd.ucar.edu
> >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
----- End forwarded message -----
Received on Mon Feb 03 2014 - 10:45:03 GMT
