Date: Wed, 25 Jan 2012 08:43:45 -0800
From: Karl Taylor<[email protected]>
Subject: Re: [CF-metadata] Request for new land_ice and firn standard
names
To: [email protected]
Message-ID:<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Hello,
There is no mention of snow or surface melt water (ponds). Should
something explicit be said about including/excluding these in any of
definitions below? Also, if I understand correctly, I would be explicit
that
"Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock
and also includes ice-shelves. "Fern" is included as part of "land ice".
cheers,
Karl
On 1/25/12 5:44 AM, Tamsin Edwards wrote:
Hello,
I would like to request the following new standard names and one
deprecation. I've attempted to give definitions that are consistent with
related names in the table.
1. land_ice_mass_accumulation_rate (m s-1)
"Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock
and also includes ice-shelves. The accumulation rate is the rate at
which ice is added per unit area at the land ice surface.
2. runoff_rate (m s-1)
Runoff is the liquid water which drains from land. If not specified,
"runoff" refers to the sum of surface runoff and subsurface drainage.
The runoff rate is the rate at which water is lost per unit area.
3. land_ice_basal_altitude (m)
"Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock
and also includes ice-shelves. Altitude is the (geometric) height above
the geoid, which is the reference geopotential surface. The geoid is
similar to mean sea level. Basal altitude is the altitude of the base of
the ice.
4. land_ice_thickness_excluding_firn (m)
"Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock
and also includes ice-shelves. "Firn" means partially-compacted snow on
the land ice surface. "Thickness" means the vertical extent of a layer.
Land ice thickness excluding firn means thickness of only the land ice
and not the firn layer.
5. firn_thickness (m)
"Firn" means partially-compacted snow on the land ice surface.
"Thickness" means the vertical extent of a layer. Firn thickness means
thickness of the firn layer.
6. land_ice_and_firn_thickness (m)
"Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock
and also includes ice-shelves. "Firn" means partially-compacted snow on
the land ice surface. "Thickness" means the vertical extent of a layer.
Land ice and firn thickness means the total thickness of land ice and
the firn layer.
7. land_ice_and_firn_thickness_expressed_as_ice_equivalent (m)
"Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock
and also includes ice-shelves. "Firn" means partially-compacted snow on
the land ice surface. "Thickness" means the vertical extent of a layer.
Land ice and firn thickness expressed as ice equivalent means the total
thickness of land ice and the firn layer if the firn were converted to ice.
I would like to propose that land_ice_thickness be deprecated due to
vagueness.
Best wishes,
Tamsin
_______________________________________________
CF-metadata mailing list
[email protected]
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/20120125/1c9054df/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 25 Jan 2012 19:16:00 -0500
From: Randy Horne<[email protected]>
Subject: Re: [CF-metadata] Non-standard dimensionless vertical
coordinates
To: [email protected]
Message-ID:<[email protected]>
Content-Type: text/plain; charset=windows-1252
Further analysis (and help from Steve Hankin) revealed that I had
misunderstanding on the constraints associated with the values elements in a
coordinate variable could have. Just as long as successive values are
increasing or decreasing, the coordinate variable element values are CF
compliant.
Once I got past this issue, the rest of CF compliant data declaration fell into
place. Here are the key aspects of the CF compliant solution
(1)
The vertical coordinates associated with the data set is in fact dimensional.
The coordinates represent increasing pressure levels in hectopascals (hPa).
(2)
The vertical pressure levels reported are not contiguous, and, in fact, represent
discrete samples based on need. Thus, the new conventions associated with discrete
sampling geometries applies. The feature type associated with our product is
"profile".
(3)
The axis attribute needed to be set to "Z" to ensure it is clear that the
pressure level variable is the vertical dimension coordinate variable.
Following is an example:
attributes:
:featureType = ?profile?;
dimensions:
time = 1;
y = 10;
x = 10;
pressure_levels = 101;
variables:
short profile_data (time, y, x, pressure_levels);
.
.
:coordinates = "time y x pressure_levels";
.
.
float pressure_levels (pressure_levels);
:standard_name = ?...?
:long_name = ?pressure?
:units = "hPa";
:axis = "Z";
Note that in this data declaration, the profile_data at the 101 levels in the
atmosphere at each x,y in the grid varies most rapidly. This is as a result of
the inherent characteristics of the data processing required to generate the
product file.
On Jan 24, 2012, at 1:00 PM, Randy Horne wrote:
On the program I am working, we have temperature and pressure profile products
where data values are generated for multiple pressure levels in the atmosphere
(i.e. the z-axis). Dimensionless vertical coordinates as defined in paragraph
4.3.2 of the CF metadata document appears to be the best way to establish
coordinates for the data values at the different pressure levels.
Unfortunately, the various formula options defined in Appendix D.
Dimensionless Vertical Coordinates do not work for the pressure levels that are
reported in our temperature and pressure profile products. In fact, because
of the non-linear and non-exponential characteristics of the reported pressure
levels, it is unlikely any type of simple formula can be constructed to provide
a mapping between monotonically increasing integers and reported pressure
levels.
Any thoughts as to what other options we have to handle this ?
..............End of Message ...............................-->
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
____________________________________
Randy C. Horne ([email protected])
Principal Engineer, Excalibur Laboratories Inc.
voice& fax: (321) 952.5100
url: http://www.excaliburlabs.com
------------------------------
Message: 5
Date: Thu, 26 Jan 2012 10:48:14 +0000
From: Jonathan Gregory<[email protected]>
Subject: Re: [CF-metadata] Regions, Gazetteer, etc
To: John Graybeal<[email protected]>
Cc: CF Metadata List<[email protected]>
Message-ID:<[email protected]>
Content-Type: text/plain; charset=us-ascii
Dear John
Could you say a bit more about this requirement? In particular, "plain text with nothing but
the list in it" and "machine-readable" aren't entirely contradictory, but may
preclude more complex representations that are appropriate, no? (I'm not an expert in gazetteer
representation, but being able to represent e.g., hierarchies of metadata gets tricky, I'm
guessing. Is something like XML or RDF close enough to plain text to meet this goal/requirement?
The main problem I was getting at is that a discursive HTML document is
difficult for a program to use! A table in XML, for instance, would be OK,
I agree. If it were primarily in XML, it would be helpful to provide a more
human-readable version as well (e.g. the discursive HTML form). A plain-text
file has the advantage of being both human- and machine-readable, doesn't it.
Best wishes
Jonathan
------------------------------
Message: 6
Date: Thu, 26 Jan 2012 10:57:11 +0000
From: Jonathan Gregory<[email protected]>
Subject: Re: [CF-metadata] mailing list and trac tickets
To: [email protected]
Message-ID:<[email protected]>
Content-Type: text/plain; charset=us-ascii
Dear all
Thanks for your replies about this. In an off-list discussion, we are trying
to work out how to deliver trac tickets to everyone.
Best wishes
Jonathan
------------------------------
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
End of CF-metadata Digest, Vol 105, Issue 11
********************************************
