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
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140203/3598b609/attachment-0001.html>
Received on Mon Feb 03 2014 - 10:24:31 GMT
