Re: [netcdfgroup] Interpretation of valid_min/max/range attributes

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

  • 2015 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: