⇐ ⇒

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

From: Jennifer M. Adams <jma>
Date: Wed, 11 Oct 2006 13:24:09 -0400

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://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20061011/03d135fc/attachment-0002.html>
Received on Wed Oct 11 2006 - 11:24:09 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒