It's obvious even to this non-expert that different reference surfaces
yield different heights, but I fail to see how they are different
"sorts of height". Though I'm happy to stand corrected on that.
But for another reason I would like to take a contrary position here:
I don't believe the standard_name attribute uniquely identifies
a physical quantity, and the fact of two quantities sharing that
attribute doesn't make them "synonymous" to use Jim's terminology.
The example I often use to illustrate this is the quantities called
high, middle and low cloud amount. They all share the standard_name
cloud_amount_in_atmospheric_layer, and then another attribute defines
the layer.
The reason I'm making a bit of an issue of this, is that I think trying
to squeeze too much information into the standard_name attribute alone
will make it too convoluted. Other attributes of the variable may be
needed to remove all ambiguity, and that's fine. It's always been so
in CF.
Jonathan Gregory writes:
Dear Jim
I think the same as Karl. The reason is that I regard height above geoid and
height above reference ellipsoid as different geophysical quantities, as are
height above bedrock (the example I gave in an earlier email, to Rich) and
height (in the sense of the CF standard_name table i.e. above the ground). If
I am standing on the summit of Mount Everest, the height above ground of
my crampons is about 0 m, but their altitude is about 8848 m. In fact in your
email you referred to them as different "sorts" of height. That sounds to me
like different geophysical quantities. Conversion between them is possible but
it is a non-trivial operation involving geophysical data. Similarly conversion
is possible between altitude and geopotential height but they are different
geophysical quantities with different standard names.
The geoid and reference ellipsoid definition, however, are fine in the grid
mapping, because they do not define the geophysical quantity. They just make
it numerically precise.
Best wishes
Jonathan
----- Forwarded message from Jim Biard <[email protected]> -----
From: Jim Biard <[email protected]>
Date: Tue, 11 Feb 2014 13:51:56 -0500
To: CF metadata <[email protected]>
X-Mailer: Apple Mail (2.1827)
CC: Karl Taylor <[email protected]>
Subject: Re: [CF-metadata] Vertical datums (again)
Karl,
My point is that putting the reference surface in the standard name
(potentially) proliferates standard names for things that (like temperatures in
different units) are not different except for their reference frame. I agree
that we don?t want to put the datum information in the units, but the place for
this sort of information already exists - it?s the grid_mapping variable. We
don?t have the appropriate attributes defined yet, but that is where the
information should go. The definition of the standard name can state a
requirement for the information to present in a grid_mapping variable. I
thought that the point of standard names was to assist in identifying variables
that are of the same kind or class, and that the goal was to avoid putting
implementation details into standard_names. By tacking on CRS details, it
seems to me that we are moving away from that goal.
Grace and peace,
Jim
Visit us on
Facebook Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: [email protected]
o: +1 828 271 4900
On Feb 11, 2014, at 1:44 PM, Karl Taylor <[email protected]> wrote:
Hi all,
for temperature, the units imply a zero point, but for height they don't. For time, we
specifically include the zero point in the units (e.g., "days since 20010101") and we
also distinguish among various calendars with the "calendar" attribute. For height I
wouldn't advocate that approach, but rather the already proposed hybrid approach: the standard
name (roughly) specifies the reference surface, which can then be more precisely defined in another
place (e.g., within the grid_mapping).
best regards,
Karl
On 2/11/14, 10:05 AM, Jim Biard wrote:
Hi.
It seems to me that tacking on a description of the datum in the standard name
isn?t a good plan. It creates a linkage between standard names and grid
mappings / WKT blocks. The nature of the height of the sea surface is
not altered by the choice of datum. The values will be different, depending on
what sort of height, but you can (most of the time!) translate heights from one
CRS to another. It is definitely more complicated, but tacking on a datum
description appears to me to be akin to having different standard names for
?temperature_in_C? and ?temperature_in_K?. If you have properly specified your
CRS, the question of where the zero in your height scale is located is
completely unambiguous.
Grace and peace,
Jim
Visit us on
Facebook Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: [email protected]
o: +1 828 271 4900
On Feb 11, 2014, at 11:43 AM, Jonathan Gregory <[email protected]>
wrote:
Dear Rich
Thanks for the detailed explanation (and analogy) of why it's useful
to tack on the "_above_geoid" or "_above_ellipsoid" or
"_above_tidal_datum" to the standard-name.
So we do that and then specify the geoid, ellipsoid or tidal datum
elsewhere in the grid_mapping variable, right?
Yes, that is the way we've been proceeding up to now. In fact we do not have
any stdnames yet referring to tidal datum, but you're welcome to propose them
if they're needed now, of course.
geoid: NAVD88, GEOID93, GEOID96, USGG2009, etc
ellipsoid: WGS84, Airy 1830, Airy Modified 1849, etc
tidal_datum: MLLW, MLW, MTL, MHW, MHHW, etc
Thanks for these useful lists! I would tend to think that we should
give different standard names for the various different tidal datums, since
I would regard those as different geophysical quantities - would you agree?
If there was data which referred to a tidal datum but didn't actually know
which one it was, I suppose it might still be useful (if imprecise) and it
could have a standard name that referred to "tidal datum" generically. But
if you know it's mean_high_water (for instance), I would spell that out in
the standard name.
However I think the various geoids are all different estimates of the same
geophysical quantity, so they should *not* have different standard names.
Likewise the ref ellipsoid is the "best" ellipsoid approximating the geoid -
again, that is a single geophysical concept, with many alternative versions.
So we need a place to name the geoid, if that is the vertical datum. It would
be good to have a similar treatment to CRS WKT for this, but I don't see a
place in WKT where the geoid can be identified. Can anyone help? Is the geoid
implied by, or identical to, the vertical datum name, perhaps? How does one
know, in WKT, whether the vertical datum is a geoid or a ref ellipsoid?
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
_______________________________________________
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
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
V. Balaji Office: +1-609-452-6516
Head, Modeling Systems Group, GFDL Home: +1-212-643-2089
Princeton University Email: [email protected]
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
