⇐ ⇒

[CF-metadata] new standard name requests

From: Jonathan Gregory <j.m.gregory>
Date: Tue, 11 Feb 2014 16:48:07 +0000

Dear Kris

Thanks for your email.

> My group is producing a climate data record (CDR) of satellite-based cloud property retrievals in support of the NOAA CDR program. When we do our retrievals, we do not directly retrieve parameters at cloud top but rather at some depth within the cloud where the infrared radiation is emitted. We call this depth within the cloud the "cloud radiative center". I see that NetCDF standard names exist for cloud top parameters, but none for the cloud radiative center. So I propose that the following new standard names be added to the list. Perhaps the wording could be adjusted to some degree, but we have to incorporate the concept of cloud radiative center into the name
>
> height_at the_cloud_radiative_center
> air_temperature_at_the_cloud_radiative_center
> pressure_at_the_cloud_radiative_center

Three questions occur to me.

(1) Is "cloud radiative center" a concept which is used outside your group?
In general we define standard names for quantities which are generally used
in the community.

(2) Do you really mean "height" i.e. distance above the ground? Or perhaps you
mean altitude or geopotential height or something else?

(3) I guess you mean air_pressure - is that right?

Best wishes

Jonathan

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 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: 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> 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
>>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140211/aa17783a/attachment-0001.html>

Received on Tue Feb 11 2014 - 09:48:07 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒