Re: elevation becomes altitude

• To: John J Brecht <john.brecht@xxxxxxx>
• Subject: Re: elevation becomes altitude
• From: Don Murray <dmurray@xxxxxxxxxxxxxxxx>
• Date: Thu, 19 Sep 2002 08:40:27 -0600

Hi John-

John J Brecht wrote:

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 you open it with the same Plain that uses the customized
QuantitiesDB, does it work?  InputNetcdf just creates a Plain()
object, so it won't use the custom QuanititesDB.

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?

If you use the same Plain() object to open/save/open the
file, things should work.  If not, that is a bug that needs
to be fixed.  However, there will always be the problem
that no two RealTypes can have the same name, so if you
have Elevation in feet in one file and Elevation in meters
in another, the default Unit will come from the "Elevation"
RealType you created when the first file was opened (in
this case feet).  That's all predicated on there not being
an existing RealType named Elevation with incompatible units
(Elevation, "degrees" for radar elevation angle).

We are looking into other solutions (such has having
View.java use the RealType.alias() methoc), but since this
all was a design decision (good or bad) long ago, any
changes will have to be thoroughly tested.  There is a lot
of code out there that expects that Elevation with units
of length gets mapped to RealType.Altitude, just as "lat"
gets RealType.Latitude and "lon" gets RealType.Longitude
so anything that changes this behavior would not be good.
Other solutions are to create an EmptyQuantityDB which
would mean that nothing would get translated.  However,
conflicting names/units will still be a problem.

Let us know if using the same Plain to open/save/open
doesn't give you the desired results.

Don
*************************************************************
Don Murray                               UCAR Unidata Program
dmurray@xxxxxxxxxxxxxxxx                        P.O. Box 3000
(303) 497-8628                              Boulder, CO 80307
http://www.unidata.ucar.edu/staff/donm
*************************************************************

• References:
  • Re: elevation becomes altitude
    • From: Steve Emmerson
  • Re: elevation becomes altitude
    • From: John J Brecht