Dear Cathy,
I fully understand the issue of parameter labelling in NASA Ames, having spent a lot of time trying to sort out the plaintext labelling in the Ames data stock of BADC as part of the NERC DataGrid project over a decade ago. Some of the problems - spelling, variations in word order and different terms for the same thing - were soluble. Others, especially text strings that nobody could understand weren't.
Replacing this plaintext by standardised parameter labelling is therefore something that should be actively encouraged and Standard Names are one (not the only but probably the best for atmospheric physics) tool that may be used for this purpose. However, if you adopt a policy of making Standard Names a mandatory label for every parameter in every Ames file - as Jim says a stricter restriction than CF (which allows a text long name as an alternative to the Standard Name) - you are going to run into the problems documented in your e-mail.
There is a continuous process of adding Standard Names, but each name added requires resource and the available resources are limited, which means that it can take a significant amount of time between a new name request and it being published. The time required can be reduced by putting effort into the Standard Name request by preparing names taking established syntactic practices into account and by preparing definitions, again following established practices. It also helps if each request is restricted to a smallish number of semantically connected Standard Names. So, you might have more success with a policy for parameter labelling in the Ames files of using Standard Names if available or plaintext if not, supported by a programme of Standard Name development to eliminate the need for plaintext over time.
I'll comment on two specific issues you raised. The first is level. The established principle in CF for handling this is to use a Standard Name to describe the measured phenomenon and then have a z-axis co-ordinate variable the describe the height. So, '2m air temperature' would have a parameter labelled 'air_temperature' linked to a co-ordinate parameter labelled 'height' in which the value 2 is stored. This technique obviously won't map into Ames, which is basically a spreadsheet with header text records. The only thing I can think of would be to establish your own conventions and use something like 'air_temperature:height=2m' as the parameter label.
Secondly, units. CF Standard names are linked to Canonical Units, which specify dimensions, not actual units of measure including scale. Thus for evaporation rate the Canonical unit is metres/second (dimensions length time-1), which is compatible with mm/hour as they both have the same dimensions. In CF the units of measure including scale (based on UDUNITS conventions) are stored in a separate parameter attribute in the NetCDF file.
Hope this helps.
Cheers, Roy.
Please note that I partially retired on 01/11/2015. I am now only working 7.5 hours a week and can only guarantee e-mail response on Wednesdays, my day in the office. All vocabulary queries should be sent to enquiries at bodc.ac.uk. Please also use this e-mail if your requirement is urgent.
________________________________
From: CF-metadata <cf-metadata-bounces at cgd.ucar.edu> on behalf of Jim Biard <jbiard at cicsnc.org>
Sent: 01 September 2017 14:03
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] A user has a set of variables they can't store: advice?
Cathy,
CF is not, per se, restricted to netCDF, but it does have a lot of legacy that is connected to the netCDF way of doing things. There are a couple of attempts out there to use CF terms in JSON, for example. I'm unfamiliar with the Ames format, so I can't speak to how easy or hard it will be to use CF with that format.
As far as the other issues you mention are concerned, CF has ways to handle pretty much all of them. Level is not a problem, point data is not a problem, and variant units for a given standard name is not a problem. It is even just fine to have data without a standard name associated with it. If you find a quantity for which no standard name exists, you can compose a proposal for a new standard name (including a detailed definition with canonical units) and email it to the CF-Metadata listserv. It will be discussed, and if the community agrees with them, they will be added to the standard_name database.
You guys will need to educate yourselves on CF and how it is used. Read the Conventions and supporting documents at
http://cfconventions.org/
CF Conventions Home Page<
http://cfconventions.org/>
cfconventions.org
Climate and Forecast Metadata also know as the CF Convention or CF Metadata
There are examples and templates that can be instructive. You can find some at these links:
https://www.nodc.noaa.gov/data/formats/netcdf/v2.0/
NCEI NetCDF Templates v2.0 - National Oceanic and ...<
https://www.nodc.noaa.gov/data/formats/netcdf/v2.0/>
www.nodc.noaa.gov
NCEI NetCDF Templates v2.0 Purpose. The NOAA National Centers for Environmental Information (NCEI) have developed netCDF templates based on what are called "feature ...
https://www.unidata.ucar.edu/software/netcdf/examples/files.html
Example netCDF files - Unidata<
https://www.unidata.ucar.edu/software/netcdf/examples/files.html>
www.unidata.ucar.edu
Example netCDF files. Below we provide links to some sample netCDF files. These may be useful to developers of netCDF tools who want to test their tool on ...
http://cfconventions.org/cf-conventions/v1.6.0/cf-conventions.html#appendix-examples-discrete-geometries
NetCDF Climate and Forecast (CF) Metadata Conventions<
http://cfconventions.org/cf-conventions/v1.6.0/cf-conventions.html#appendix-examples-discrete-geometries>
cfconventions.org
This document describes the CF conventions for climate and forecast metadata designed to promote the processing and sharing of files created with the netCDF ...
Grace and peace,
Jim
On 8/31/17 6:23 PM, Cathy Smith wrote:
Hi
A user trying to use CF standard names sent me this list of variables they were unable to find the names of. Note this is for observations at a point. It is to be stored in NASA Ames format and not netCDF. In some cases, the units was the issue (e.g. evap rate). In some cases, the data was at a specific level (e.g. 10m wind speed) and it wasn't clear how 'level' would be indicated in the Ames metadata.
The 'level' issue may be part of another one: CF was designed for gridded data but from a talk on the web, it is
"Framed as a netCDF standard, but most CF ideas relate to metadata design in general, hence can be contained in other formats such as XML"
So, can the CF standard names really apply to point collected data not in netCDF? And, can these all be considered as potential variables for CF if they don't already exist?
Here is the list.
Bulk buoyancy flux into ocean (W m-2)
Friction velocity that includes gustiness (m s-1) [aka ustar]
Wind stress (N m-2)
Temperature scaling parameter (K) [aka tstar]
Specific humidity scaling parameter (g kg-2) [aka qstar]
Thermal roughness length (m)
Moisture roughness length (m)
Wind stress transfer coefficient at zu () [aka Cd]
Sensible heat transfer coefficient at zu () [aka Ch, Stanton number]
Latent heat transfer coefficient at zu () [aka Ce, Dalton number]
Obukhov length scale L (m)
Monin-Obukhov stability parameter zu/L ()
wind_speed at 10 m (m s-1)
air_temperature at 10 m (C)
specific_humidity at 10 m (g kg-1)
relative_humidity at 10 m (%)
Neutral value of wind speed at zu (m s-1)
Neutral value of wind speed at 10 m (m s-1)
Neutral value of drag coefficient at 10 m ()
Neutral value of Stanton number at 10 m ()
Neutral value of Dalton number at 10 m ()
Cool-skin temperature depression (C)
Surface saturation specific humidity (g kg-1)
Latent heat of vaporization (J kg-1)
and maybe
Evaporation rate (mm h-1)
Thanks
Cathy Smith
--
----------------------------------------------
NOAA/ESRL PSD and CU CIRES
303-497-6263
http://www.esrl.noaa.gov/psd/people/cathy.smith/
Emails about data/webpages may get quicker responses from emailing
esrl.psd.data at noaa.gov<mailto:esrl.psd.data at noaa.gov>
_______________________________________________
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
--
[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 National Centers for Environmental Information <http://ncdc.noaa.gov/>
formerly 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
Connect with us on Facebook for climate<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us on Twitter at _at_NOAANCEIclimate<https://twitter.com/NOAANCEIclimate> and @NOAANCEIocngeo<https://twitter.com/NOAANCEIocngeo>.
________________________________
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170901/84e8e487/attachment.html>
Received on Fri Sep 01 2017 - 08:05:21 BST
