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

20031203: IDV handling of _FillValue in short integer fields

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: 20031203: IDV handling of _FillValue in short integer fields
  • Date: Thu, 04 Dec 2003 05:53:46 -0700
>From: Richard Signell <address@hidden>
>Organization: SACLANTCEN
>Keywords: 200312030737.hB37bDp2005318 IDV netCDF _FillValue

Hi Rich-

>> >IDV correctly eliminates the _FillValue elements
>> >from "depth" in the display, but does not eliminate the _FillValue
>> >elements in the "hsig" field.   (I was doing color shaded plan view
>> >displays).
>> >
>
>> Thanks for pointing this out.  We've determined the problem
>> and are working on the best way to solve it.  I'll send more
>> when I have the answer, but just wanted to let you know
>> we're working on it.

We figured out the problem and the fix will be in the next release
(1.1b3 around early January).  For now, you could just set the 
range of your color table to 0 to .5 and you should see some good
shading of the sig wave heights (and red missing values ;-)).
Also, you can use the Edit->Change Display Unit... menu option
to view it in fathoms if you want. ;-)  It's a nice dataset.
I'm going to play around with it and then I'll send a note
on how you can display this as topography.  I think I found
another bug that I have to track down first (hey, it's beta
code!)

For the details, the problem was in the way the Java netCDF library 
was comparing values against the _FillValue.  It was a rounding
error between doubles and floats.  It would check to see if
a value was a _FillValue and there was just a slight difference
way off in the 8th decimal place or so due to a casting of a 
float to a double.   Anyway, it's fixed now and again, thanks
for pointing this out.  It also lead to a little change that
improves the efficiency.

Don