[Fwd: Re: Fwd: [CF-metadata] units in cf standard names]

Jennifer M. Adams jma at cola.iges.org
Wed Oct 11 11:24:09 MDT 2006


UDUNITS may not be perfect, but I'm grateful for it. It always builds  
without a hitch, and it's far better than trying to manipulate  
calendar information without the help of an external library. I  
completely understand why you wouldn't want to support all the  
possibilities and complexities of Calendars. It's a mess!  Just last  
week, someone in the GrADS community asked for a 122-day boreal  
summer (Jun-Sep) calendar definition. NOOoooo! And now that I know  
the UDUNITS developers are listening, I'm sorry I said it was sloppy.

Jennifer Adams




On Oct 11, 2006, at 12:17 PM, John Caron wrote:

> There's some feeling here that the Calandar handling aspects of  
> udunits are probably a mistake, that is, dont belong in a physical  
> units package. They are adequate for simple cases, but we havent  
> been all that interested in supporting all the complexities of  
> Calendars.
> In the future, we might want to look to other packages for that  
> functionality.
>
> John
>
> Jennifer M. Adams wrote:
>> Steve Hankin brought to my attention a post to this group  
>> regarding  the udunits library. I have just subscribed to this  
>> list in order to  post the following reply:
>> GrADS uses the udunits library to get the time axis information  
>> for  netcdf files when the only available metadata is whatever is   
>> contained in the file itself.  The udunits library has some   
>> limitations (e.g. 365_day_calendar isn't supported), but it works   
>> well enough. I spent some time poking at the code a year or so  
>> ago  when looking into fixing problems with no_leap time axes, and  
>> I found  a lot of sloppy and complicated code I didn't want to  
>> have to  rewrite. I didn't feel it was really worth fixing when it  
>> was much  simpler to just ask the user to provide the right time  
>> start time and  increment for those types of data files. Plus, I  
>> didn't want to have  to carry around a patch to an external  
>> library for future releases.
>> Jennifer
>> -- 
>> Jennifer M. Adams
>> IGES/COLA
>> 4041 Powder Mill Road, Suite 302
>> Beltsville, MD 20705
>> jma at cola.iges.org
>> On Oct 10, 2006, at 6:36 PM, Steve Hankin wrote:
>>> just in case this email slipped by -- GrADS uses udunits, doesn't  
>>> it?
>>>
>>> From: Bryan Lawrence <b.n.lawrence at rl.ac.uk>
>>> Date: October 10, 2006 4:11:20 PM EDT
>>> To: Roy Lowry <rkl at bodc.ac.uk>
>>> Cc: cf-metadata at cgd.ucar.edu
>>> Subject: Re: Fwd: [CF-metadata] units in cf standard names
>>>
>>>> The choice of udunits was made by COARDS. We carry on with it  
>>>> for  COARDS
>>>> compatibility. Are there any other similarly comprehensive and   
>>>> flexible
>>>> standards for interpreting units strings? I think the main  
>>>> benefit  is to
>>>> provide a general syntax, and secondarily some associated  
>>>> software  for parsing
>>>> and converting units.
>>>
>>>
>>> Is anyone actually using udunits in anger with netcdf-cf data. If  
>>> so,
>>> how? (I'm not dissing the importance of syntax, and coards ...  
>>> nor  am I
>>> pushing a barrow for change here, just trying to understand exactly
>>> where we are ...)
>>>
>>> Cheers
>>> Bryan
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu
>>> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>
>>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>

Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Beltsville, MD 20705
jma at cola.iges.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cgd.ucar.edu/pipermail/cf-metadata/attachments/20061011/03d135fc/attachment.html


More information about the CF-metadata mailing list