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
