Re: elevation becomes altitude

John,

Try invoking the static method setInstance(QuantityDB) of class
visad.data.netcdf.QuantityDBManager with the quantity database of your
choice before invoking anything of Plain.  This will set the quantity
database that is used by all subsequent Plain instances.

Regards,
Steve Emmerson   <http://www.unidata.ucar.edu>

>Date: Wed, 18 Sep 2002 17:01:05 -0700
>From: "John J Brecht" <john.brecht@xxxxxxx>
>Organization: UCAR/Unidata
>To: visad-list@xxxxxxxxxxxxx
>Subject: Re: elevation becomes altitude
>Keywords: 200209190001.g8J01P127781
>
> I tried both solutions and neither worked. The QuantityDB I construct 
> seems to be completely ignored by the Plain constructed with it.  That 
> is, if I construct a Plain with a custom QuantityDB using the code 
> mentioned earlier, and then I save my data with that Plain, and then I 
> open it right back up with an InputNetcdf, I find the things have 
> changed back to "Altitude" instead of  "Elevation" and Kelvin instead of 
> Farenheit on me.
> 
> If I use a VisADSerialForm a little progress can be made, but it turns 
> out that the Spreadsheet gets confused.  It seems to handle the 
> elevation data correctly, but it chokes on the temperature data, 
> treating it in some ways as Kelvin and in some ways as Farenheit, though 
> I can't really decipher what it's doing...  Nonetheless, this isn't an 
> acceptable solution - even if I figure out what's going on, I'd still 
> like to be able to use Farenheit or Celsius data, as per the orginal 
> data file that I'm importing.  When I override setMaps, all I can do is 
> explicitly pick one or the other.  Furthermore, using a VisADSerialForm 
> is not a preferred solution, either, as all my data files will be 
> invalidated if/when VisAD changes.
> 
> Is there another data format I might consider that handles units 
> correctly, or is this just something I'll have to live with?
> 
> -john