Both geoids and reference ellipsoids are vertical datums used as the reference from which measurements can be made. I'm not sure I see how that makes those measurements different geophysical quantities.
I can see how lat/lon and X/Y are different. Similarly, height and pressure levels are different. But height as measured from two different types of vertical datums does not seem different in the same manner. Ethan On 2/12/2014 9:42 AM, Jonathan Gregory wrote: > 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 <jbi...@cicsnc.org> ----- > >> From: Jim Biard <jbi...@cicsnc.org> >> Date: Tue, 11 Feb 2014 13:51:56 -0500 >> To: CF metadata <cf-metadata@cgd.ucar.edu> >> X-Mailer: Apple Mail (2.1827) >> CC: Karl Taylor <taylo...@llnl.gov> >> 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: jbi...@cicsnc.org >> o: +1 828 271 4900 >> >> >> >> >> On Feb 11, 2014, at 1:44 PM, Karl Taylor <taylo...@llnl.gov> 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: jbi...@cicsnc.org >>>> o: +1 828 271 4900 >>>> >>>> >>>> >>>> >>>> On Feb 11, 2014, at 11:43 AM, Jonathan Gregory <j.m.greg...@reading.ac.uk> >>>> 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 >>>>> CF-metadata@cgd.ucar.edu >>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>>> >>>> >>>> >>>> _______________________________________________ >>>> CF-metadata mailing list >>>> CF-metadata@cgd.ucar.edu >>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata@cgd.ucar.edu >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> > >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata@cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > ----- End forwarded message ----- > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- Ethan Davis UCAR Unidata Program eda...@unidata.ucar.edu http://www.unidata.ucar.edu _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata