NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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
netcdfgroup archives: