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
