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 > > CICS-NC <http://www.cicsnc.org/>Visit us on > Facebook <http://www.facebook.com/cicsnc> *Jim Biard* > *Research Scholar* > Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/> > North Carolina State University <http://ncsu.edu/> > NOAA's National Climatic Data Center <http://ncdc.noaa.gov/> > 151 Patton Ave, Asheville, NC 28801 > e: [email protected] <mailto:[email protected]> > o: +1 828 271 4900 > > > > > > On Feb 11, 2014, at 1:44 PM, Karl Taylor <[email protected] > <mailto:[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 >>> >>> CICS-NC <http://www.cicsnc.org/>Visit us on >>> Facebook <http://www.facebook.com/cicsnc> *Jim Biard* >>> *Research Scholar* >>> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/> >>> North Carolina State University <http://ncsu.edu/> >>> NOAA's National Climatic Data Center <http://ncdc.noaa.gov/> >>> 151 Patton Ave, Asheville, NC 28801 >>> e: [email protected] <mailto:[email protected]> >>> o: +1 828 271 4900 >>> >>> >>> >>> >>> >>> On Feb 11, 2014, at 11:43 AM, Jonathan Gregory >>> <[email protected] <mailto:[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] <mailto:[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] <mailto:[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 > -- Ethan Davis UCAR Unidata Program [email protected] http://www.unidata.ucar.edu _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
