Wouldn't this fall into the realm of LibCF? Could ncdump be linked to
libcf somehow?
Ciao,
Dave
Dave Kindig
Research Assistant - TechX Corp (www.txcorp.com)
303-444-2386
On 06/07/2011 01:54 PM, Dave Allured wrote:
Phil said, "Naturally it wouldn't be right (or would it?) to encode CF
rules within the base netCDF libraries ..."
I would like to keep the command line simple. For the -t option, it
seems reasonable for ncdump to recognize the requisite CF attributes
to properly interpret a time boundary variable, in particular the
"Conventions" and "bounds" attributes.
Alternatively, consider whether it would be reasonable to universally
dedicate the CF "bounds" attribute, or perhaps "_bounds", for this
purpose. Are there any extant conventions or data sets that use the
"bounds" attribute in a conflicting way?
--Dave
On 6/7/2011 9:48 AM, Bentley, Philip wrote:
Hi folks,
With the 4.x version of ncdump one can use the -t option to request
output of time data as human-readable date-time strings rather than
as 'raw' numbers (e.g. days since reference_date). This works well
when one is querying a primary time coordinate variable that
possesses the requisite netCDF attributes, e.g. units and calendar
(as shown in the CDL snippet below).
But it doesn’t work so well for CF-compliant boundary variables
(e.g. time_bnds in our example) used to specify the cell bounds of
coordinate variables. The reason being that such boundary variables
typically do not replicate the relevant attributes attached to the
'parent' coordinate variable.
dimensions:
time = UNLIMITED ; // (1800 currently)
lat = 216 ;
lon = 360 ;
bnds = 2 ;
variables:
double time(time) ;
time:bounds = "time_bnds" ;
time:units = "days since 1859-12-01" ;
time:calendar = "360_day" ;
time:axis = "T" ;
time:long_name = "time" ;
time:standard_name = "time" ;
double time_bnds(time, bnds) ;
// no attributes
This shortcoming can readily be overcome by duplicating the units
and calendar attributes on the time_bnds variable (usng, say, the
ncatted utility). But one can see that doing this would become a
chore after a while!
Naturally it wouldn't be right (or would it?) to encode CF rules
within the base netCDF libraries, so I wonder if there's a case for
enhancing the -t option in some way such that the user could specify
the associated variable from which to read requisite attributes. For
example, the extended command to print out the date-time strings of
the time_bnds variable might appear thus:
$ ncdump -v time_bnds -t time myfile.nc
Or, if it was necessary to maintain the unadorned -t option for
backwards compatibility:
$ ncdump -v time_bnds -T time myfile.nc
Any mileage in this suggestion?
Regards,
Phil
_______________________________________________
netcdfgroup mailing list
netcdfgroup@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
