Hi Russ,
That's great. Thanks.
Phil
> -----Original Message-----
> From: netcdfgroup-bounces@xxxxxxxxxxxxxxxx
> [mailto:netcdfgroup-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Russ Rew
> Sent: 08 June 2011 15:33
> To: netcdfgroup@xxxxxxxxxxxxxxxx
> Subject: Re: [netcdfgroup] Behaviour of ncdump -t option
>
> 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 mailing list
> netcdfgroup@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
