[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[netCDFJava #KJR-472449]: missing/fill values and EnhanceScaleMissingImpl
- Subject: [netCDFJava #KJR-472449]: missing/fill values and EnhanceScaleMissingImpl
- Date: Fri, 29 Jul 2011 06:55:51 -0600
Hi Don:
I think Russ and I have talked about this and decided that _FillValue should
match the bit pattern exactly (for portability?). valid_range, valid_min,
valid_max, and missing value are intended to match data values and so should be
allowed some slop. Im cc'ing Russ in case he remembers different.
My own opinion is that the trouble stems from overloading _FillValue with
multiple meanings, plus the lack of clarity to tell people what they should do.
We should probably make another pass at
http://www.unidata.ucar.edu/software/netcdf/docs/BestPractices.html
John
> John-
>
> In the GrADS IOSP, I added a _FillValue attribute for the GrADS Data
> Descriptor File "undef" value:
>
> http://www.iges.org/grads/gadoc/descriptorfile.html#UNDEF
>
> I used _FillValue instead of missing_value because it seemed more
> accepted in the CF conventions until the recent change to undeprecate
> missing_value. Also, NCL prefers _FillValue over missing_value and I
> was working with NCL at the time I wrote the IOSP.
>
> I came across a file today where the undef was set to 9.99E8, but the
> "missing" values in the file ranged from 9.9899994E8 to 9.99E8 (We're
> looking into why it is inconsistent - the file is written by GrADS).
> Talking to one of the developers, they always use 32-bit values (floats)
> for the data when working with GrADS and I'm using float for the
> variable type.
>
> The logic in EnhanceScaleMissingImpl is different for _FillValue vs.
> missing_value. isMissingValue uses ucar.nc2.util.Misc.closeEnough
> whereas isFillValue uses straight equality.
>
> I can change the IOSP to have both _FillValue and missing_value
> attributes, or change _FillValue to missing_value and I get the results
> I expect. However, it seems like there may be some slop even in fill
> values, so perhaps isFillValue should use Misc.closeEnough instead of
> straight equality which also solves this problem. That seems more
> prudent for the typically large values that are used as _FillValues.
>
> Thoughts?
>
> Don
> --
> Don Murray
> NOAA/ESRL/PSD and CIRES
> 303-497-3596
> http://www.esrl.noaa.gov/psd/people/don.murray/
>
>
Ticket Details
===================
Ticket ID: KJR-472449
Department: Support netCDF Java
Priority: Critical
Status: Open