Ok, fair enough. I understand it's blurry, and I suppose all I'm
arguing for is some general vigilance against proliferation of
names. You understand as well as anyone the need to be very very
precise in defining sea level rise, and I'll defer to your judgment
on this matter. (BTW when are we going to see a standard_name with
"barystatic" in it?)
Thanks,
Jonathan Gregory writes:
Dear Ethan, Balaji et al.
No-one is suggesting having different standard names for different geoids or
different reference ellipsoids, as far as I know. We agree that the identity of
the geoid etc. belongs in the grid mapping. The distinction of standard names
is for different geophysical quantities. The distinction of what is truly
different is blurred, but we have to make black-and-white choices. The one
which we make in many existing CF standard names is that if quantities refer
to different geophysically defined surfaces that makes them different geo-
physical quantities. I think that's a useful distinction for a data-analyst.
Geoid, reference ellipsoid, surface (i.e. bottom of the atmosphere), bedrock
(bottom of atmosphere, sea or ice sheet, whichever is lowest) and mean sea
level are all different geophysical concepts, aren't they. In my opinion,
primarily as a scientist analysing data, heights referring to these various
references are not the same geophysical quantity, and I expect them to have
different standard names. That is the approach we have followed in naming
quantities up to now.
I agree with Balaji to the extent that the standard name is not a complete
characterisation of a quantity. There is other CF metadata. Especially, there
are coordinates. The height of cloud can be specified by coordinates, which
avoids the needs for more standard names, is more precise and much more
flexible. I regard cloud amount on any level as the same geophysical quantity
(while acknowledging that different cloud microphysics is at work, of course)
and so I am happy for clouds at various heights to be distinguished by
coordinates. The same is the reason why we have a standard_name for
air_temperature, but we don't have one for "surface air temperature", since
the extra precision can be supplied by a coordinate of height. This is another
blurred distinction, I realise, but I think it works quite well in practice.
Cheers
Jonathan
----- Forwarded message from Ethan Davis <eda...@unidata.ucar.edu> -----
Date: Wed, 12 Feb 2014 10:43:46 -0700
From: Ethan Davis <eda...@unidata.ucar.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
Thunderbird/24.3.0
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Vertical datums (again)
Hi all,
I agree with Jim on this. The grid_mapping, rather than the standard
name, is the appropriate place for this information. Just as it is for
"latitude" and "longitude (and X and Y). We don't have "latitude-wgs84"
or "latitude-airy-1830".
Ethan
On 2/11/2014 11:51 AM, Jim Biard wrote:
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
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
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: v.bal...@noaa.gov
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
