Jonathan Gregory wrote:
>Dear All
>
>I think Brian's argument is a good one that we can't rely on a distinction of
>function between _FillValue and missing_value in practice. Although it might
>be nice to distinguish between data accidentally and purposely unwritten from
>the point of view of documentation, you will treat them the same way so we can
>manage without the distinction.
>
>I would suggest we might replace the paragraph starting "The missing_value
>attribute" in 2.5.1 with a new version (in CF-1.1!)
>
>The attribute missing_value is not treated in any special way by the netCDF
>library or conforming generic applications. We do not recommend its use, but
>this standard recognizes it for compatibility with COARDS and any specific
>applications which do have a particular interpretation for it. The
>missing_value attribute can be a scalar or vector containing values indicating
>missing data. These values should all be outside the valid range so that
>generic applications will treat them as missing.
>
>Cheers
>
>Jonathan
>_______________________________________________
>CF-metadata mailing list
>CF-metadata at cgd.ucar.edu
>http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
The Java Netcdf library provides functionality to the application
programmer for dealing with missing data, and so recognizes _FillValue,
missing_value, valid_range, etc. attributes. This can be a bit tricky
when combined with packed data, so it seemed useful to provide a
standard way to handle that. Eventually some of that functionality might
make its way into the C library.
Im not sure what the objection is/was to missing_value attribute, it
seems the right way to enumerate missing values if thats what you want
to do.
BTW, as Russ said, I thought NUG meant NUWG, and the NUG (users guide)
does not deprecate missing_value
Brian Eaton wrote:
>I think it is useful to distinguish between the different reasons for
>missing data. Because _FillValue is treated specially by netCDF, I
>think we should prefer the use of missing_value to identify data that
>have been written properly, but are missing by design.
>
>
I think that may have been the original intent of having both a _FillValue
and a missing_value attribute. But that distinction is not enforced by the
library and hence data writers are free to use it to indicate data that is
intentionally missing (rather than accidentally missing). That is by far
the most common use of this attribute, and I would guess that that's why
the decision was made to deprecate missing_value and just use _FillValue.
The current interpretation of _FillValue is that it is used to define the
valid range and all data values outside the valid range are considered to
be missing.
What Brian says is true, that the library doesnt really do anything
special with _FillValue (other than fill the data with it before writing
any user values). Still, an application can certainly use the _FillValue
to look for inadvertant missing data, and I dont see any reason to
discourage that, which would require, as Karl points out, using
missing_value to indicate deliberate missing data.
I dont think of _FillValue as defining the valid range, but rather its
one specific value that is reccomended to be outside the valid range if
that is defined.
Received on Thu Nov 06 2003 - 10:11:12 GMT
