Re: [netcdfgroup] Behaviour of ncdump -t option

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/



  • 2011 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: