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

Reply via email to