Hi,
This seem like a reasonable suggestion, so I've added it to the list of
planned enhancements to ncdump:
https://www.unidata.ucar.edu/jira/browse/NCF-70
The specific change to be implemented is having ncdump properly handle
the CF "bounds" attribute for variables that use time units in the
presence of the "-t" option.
--Russ
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=92t 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 =3D UNLIMITED ; // (1800 currently)
> > lat =3D 216 ;
> > lon =3D 360 ;
> > bnds =3D 2 ;
> > variables:
> > double time(time) ;
> > time:bounds =3D "time_bnds" ;
> > time:units =3D "days since 1859-12-01" ;
> > time:calendar =3D "360_day" ;
> > time:axis =3D "T" ;
> > time:long_name =3D "time" ;
> > time:standard_name =3D "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/=20
