Re: [netcdfgroup] Behaviour of ncdump -t option

• To: "Russ Rew" <russ@xxxxxxxxxxxxxxxx>, <netcdfgroup@xxxxxxxxxxxxxxxx>
• Subject: Re: [netcdfgroup] Behaviour of ncdump -t option
• From: "Bentley, Philip" <philip.bentley@xxxxxxxxxxxxxxxx>
• Date: Thu, 9 Jun 2011 09:28:38 +0100

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/ 
> 

• References:
  • [netcdfgroup] Behaviour of ncdump -t option
    • From: Bentley, Philip
  • Re: [netcdfgroup] Behaviour of ncdump -t option
    • From: Dave Allured
  • Re: [netcdfgroup] Behaviour of ncdump -t option
    • From: Russ Rew