Philip
I just ran into this problem this morning with time bounds in one of our
files. In addition to specifying a variable, it would also be nice to be
able to specify an attribute; specifically something like
ncdump -v time:actual_range -t time myfile.nc (or whatever for syntax;
I'm not picky).
where we have actual_range encoded in udunits. I was told it would be
too hard for ncdump -t to figure out which attributes to decode but if
one could specify the variable on the command line then it doesn't need
to decide.
Cathy Smith
NOAA/ESRL PSD
On 6/7/11 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/
--
----------------------------------------------
NOAA/ESRL PSD and CIRES CDC
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@xxxxxxxx
