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 <jbiard at cicsnc.org> -----
> From: Jim Biard <jbiard at cicsnc.org>
> Date: Tue, 11 Feb 2014 13:51:56 -0500
> To: CF metadata <cf-metadata at cgd.ucar.edu>
> X-Mailer: Apple Mail (2.1827)
> CC: Karl Taylor <taylor13 at 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: jbiard at cicsnc.org
> o: +1 828 271 4900
>
>
>
>
> On Feb 11, 2014, at 1:44 PM, Karl Taylor <taylor13 at 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 go
>> They don't usually talk about heights above the surface, but
>> that's not their area of interest. I found that in meteorology,
>> geometric height (as opposed to geopotential height) appears to
>> be what geodesists call orthometric height, or height relative to
>> a geoid. I also discovered that in aviation, they often use
>> height to mean "height above the surface", and altitude to mean
>> "height above the vertical reference".
>>
>> In addition to all of the above, I found that there appears to be
>> no consensus on specific meanings for height, elevation, and
>> altitude. Height appears to be generally accepted (outside of
>> aviation) as any measure of vertical distance. Elevation and
>> altitude both tend to be heights measured relative to a reference
>> surface. Geodesists use the three terms interchangeably.
>> Because the word height does not usually invoke any particular
>> reference frame, it is mostly used with qualifiers (orthometric,
>> above sea level, etc).
>>
>> In CF, the standard name table has defined altitude and height.
>> Height is defined to be "height above the surface". Not my
>> preference, but it's a done deal. Altitude is defined as
>> orthometric height. It uses the word "geometric", which seems to
>> be the way meteorologists tend to refer to it. We then have a
>> lot of qualified height names, some of which are themselves
>> definitions of measures from geodesy, some of which use height in
>> the sense of "height above the surface", and some of which use
>> height in the sense of "height above a vertical reference".
>> Interestingly, we don't have standard names "elevation" or
>> "height_above_geoid". This all makes sense for a system that
>> appears to have grown from one where vertical datums weren't
>> really considered (horizontal ones, either!), into one where
>> questions of reference frames have become more important.
>>
>> Given all the confusion of usage both within CF and in the
>> community at large, I guess there's no reason not to continue to
>> proliferate height qualifiers in standard names. We already have
>> several.
>>
>> I'd be interested to know how often people have used the standard
>> name "height" to mark vertical coordinates, when the values they
>> have almost certainly are not "height above the surface".
>>
>> 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: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
>> o: +1 828 271 4900
>>
>>
>>
>>
>>
>> On Feb 12, 2014, at 11:42 AM, Jonathan Gregory
>> <j.m.gregory at reading.ac.uk <mailto:j.m.gregory at reading.ac.uk>> 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 <jbiard at cicsnc.org
>>> <mailto:jbiard at cicsnc.org>> -----
>>>
>>>> From: Jim Biard <jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>>
>>>> Date: Tue, 11 Feb 2014 13:51:56 -0500
>>>> To: CF metadata <cf-metadata at cgd.ucar.edu
>>>> <mailto:cf-metadata at cgd.ucar.edu>>
>>>> X-Mailer: Apple Mail (2.1827)
>>>> CC: Karl Taylor <taylor13 at llnl.gov <mailto:taylor13 at 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
>>>> FacebookJim 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: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
>>>> o: +1 828 271 4900
>>>>
>>>>
>>>>
>>>>
>>>> On Feb 11, 2014, at 1:44 PM, Karl Taylor <taylor13 at llnl.gov
>>>> <mailto:taylor13 at 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
>>>>>> FacebookJim 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: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
>>>>>> o: +1 828 271 4900
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Feb 11, 2014, at 11:43 AM, Jonathan Gregory
>>>>>> <j.m.gregory at reading.ac.uk
>>>>>> <mailto:j.m.gregory at 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 at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>>>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> CF-metadata mailing list
>>>>>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>>>
>>>>> _______________________________________________
>>>>> CF-metadata mailing list
>>>>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>>
>>>
>>>> _______________________________________________
>>>> CF-metadata mailing list
>>>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>
>>>
>>> ----- End forwarded message -----
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
John Helly, University of California, San Diego / San Diego Supercomputer Center / Scripps Institution of Oceanography / 760 840 8660 mobile / stonesteps (Skype) / stonesteps7 (iChat) / http://www.sdsc.edu/~hellyj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140215/cd73e628/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Satellite_Altimetry.pdf
Type: application/pdf
Size: 212491 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140215/cd73e628/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hellyj.vcf
Type: text/x-vcard
Size: 158 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140215/cd73e628/attachment-0001.vcf>
Received on Wed Feb 12 2014 - 09:42:48 GMT
