[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20050603: Use of Java udunits package

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 20050603: Use of Java udunits package
  • Date: Mon, 06 Jun 2005 13:20:19 -0600
Peter,

>Date: Mon, 06 Jun 2005 12:03:05 -0700
>From: Peter Hollemans <address@hidden>
>To: Steve Emmerson <address@hidden>
>Organization: NOAA
>Subject: Re: 20050603: Use of Java udunits package
>Keywords: 200506031601.j53G1GZu004496 netCDF-Java UDUNITS

The above message contained the following:

> I agree that it's better to insulate the user from the implementation. 
> However in my case, I'm satisfied with only supporting Gaussian or 
> linear conversions.  The coefficients are useful to me because I already 
> have a system of software in place that reads HDF data and translates 
> integers into floating point by way of a scaling factor and offset. 
> It's easier for me to update my implementation to convert units by 
> modifying the scaling factor and offset using the unit conversion 
> coefficients than it is to check for a SimpleUnit object and convert 
> using that for every retrieval of a floating point value.  However, I 
> may still adopt the SimpleUnit.convertTo() approach, I just haven't 
> considered all the ramifications yet.

Compositing transformations is problemematical if there's no general
framework in which each transformation is a particular instance.  Good
luck.

At least the array-based convertTo() methods are more efficient than the
one that convert a single value.

Regards,
Steve Emmerson