NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
On Apr 17, 2015, at 9:53 AM, Bentley, Philip <philip.bentley@xxxxxxxxxxxxxxxx<mailto:philip.bentley@xxxxxxxxxxxxxxxx>> wrote: Hi Russ, Thanks for your thoughts. A few follow-up comments below. From: netcdfgroup-bounces@xxxxxxxxxxxxxxxx<mailto:netcdfgroup-bounces@xxxxxxxxxxxxxxxx> [mailto:netcdfgroup-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Russ Rew Sent: 15 April 2015 16:34 To: netcdfgroup@xxxxxxxxxxxxxxxx<mailto:netcdfgroup@xxxxxxxxxxxxxxxx> Subject: Re: [netcdfgroup] Interpretation of valid_min/max/range attributes Hi Phil, I think that's a misinterpretation of the Users Guide attribute conventions. Under the description for _FillValue, the Guide states: The fill value ... is normally outside the valid range and therefore treated as missing when read by generic applications. It is legal (but not recommended) for the fill value to be within the valid range. The last sentence implies that the valid range is not determined by the _Fill_Value. I think it's intended that the rule about _Fill_Value under the description for valid_range only applies in case none of valid_min, valid_max, or valid_range are specified, so it wouldn't apply to your example: If neither valid_min, valid_max nor valid_range is defined then generic applications should define a valid range as follows. ... Indeed, that statement, together with this one from the preceding paragraph (in the NUG)... “Generic applications should treat values outside the valid range as missing.” ...would seem, on the face of it, to be unambiguous: every netcdf dataset is associated with a valid range (whether explicitly defined or constructed from the rules), and generic netcdf applications should treat values outside the valid range as missing. I seldom encounter netcdf files which contain the valid min/max/range attributes, and so don’t really have a strong view on their usage. However, if commentators do not think these attributes should be used to identify missing data (which seems to be the documented intent), then perhaps there is a need to clarify what purpose they do serve. To enable client s/w to report invalid values during file load operations? To prohibit writing invalid values during file write operations? To act as an informal guide to users of the data that the values should probably fall within this range! Regards, Phil One example use case is where the product designer uses “special" values to indicate quality-related issues (instead of a separate quality flag array) (e.g., MODIS L1B scenes). In this case, they still use _FillValue to indicate there was no data, or a value could not be computed, but the extra special values for, well, special situations. But they don’t want them plotted/mapped/computed-on-normally, so they put them outside a valid range. A related use case is when the instrument or processing algorithm retrieved values, but they are outside the expected or physically reasonable range of the parameter. Again, the producers don’t want them treated as the normal data are. Again, a separate quality flag array could be used, but that raises its own usability issues (like how to ensure the user gets the associated quality array when downloading a variable subset via OPeNDAP). — Christopher Lynnes NASA/GSFC 301-614-5185 “I love it when a plan comes together.” — Hannibal Smith
netcdfgroup archives: