Hi folks,
The final para of section 2.5.1 of the CF conventions document describes
the use of the _FillValue (or missing_value) attribute in the case of
data packed using the scale-and-offset method. What is not clear - at
least to me - is what the preferred application behaviour should be in
the case where the data is unpacked and then written out to a new netCDF
file. In particular, what fill value should be used for the unpacked
data variable?
I presume that one wouldn't normally want to use the original fill value
since that value (typically an 8- or 16-bit integer) is quite likely to
fall within the normal range of the unpacked data (typically a 32- or
64-bit float).
In the absence of explicitly setting a fill value attribute on the
unpacked data variable I assume that the netCDF default fill value will
be used for the data type in question. Which may not always be desirable
(certainly not for 32-bit floats, where the default fill value can give
rise to subtle precision-related problems).
With this in mind, I was wondering if there is any merit in defining a
new attribute called, say, _UnpackedFillValue (or
unpacked_missing_value)? If client software detected this attribute then
the associated value (same data type as the scale_factor and add_offset
attributes) would be used as the fill value for the unpacked data
variable.
Alternatively, the names _FillValueUnpacked (missing_value_unpacked)
might be preferable since they would then appear together pair-wise in
CDL-type listings, e.g.
short pkd_var(z, y, x) :
...
pkd_var:_FillValue = -32768 ;
pkd_var:_FillValueUnpacked = -1.0e30 ;
pkd_var:add_offset = 42.0 ;
pkd_var:scale_factor = 1234.0 ;
...
Any merit/mileage in this idea?
Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120924/69dbc29a/attachment-0001.html>
Received on Mon Sep 24 2012 - 08:00:19 BST
