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
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
