RE: ncdigest V1 #590

• To: "'netcdfgroup@xxxxxxxxxxxxxxxx'" <netcdfgroup@xxxxxxxxxxxxxxxx>
• Subject: RE: ncdigest V1 #590
• From: "Davies, Harvey" <harvey.davies@xxxxxxxxxxxx>
• Date: Thu, 26 Apr 2001 15:35:59 +1000

> Date: Wed, 25 Apr 2001 19:54:57 -0600 (MDT)
> From: Brian Eaton <eaton@xxxxxxxxxxxxx>
> Subject: RE: ncdigest V1 #589 (standard handling of scale/offset and missi
> ng data)
> 
> My experience with generic applications is that if values indicated by the
> _FillValue attribute are treated in some special way, they are treated
> that
> way independently of whether or not the _FillValue falls within a
> specified
> valid range.
> 
> This is true for the first two generic applications that I tested, namely
> ncdump and ncview.
> 
> From the ncdump manpage we see:
> 
>      ncdump uses `_' to represent data values that are  equal  to
>      the  `_FillValue'  attribute  for  a  variable,  intended to
>      represent data that has not yet been written.
> 
> I verified that this behavior is true even when the _FillValue is within
> the valid range.  This is not broken in the sense that ncdump is doing
> exactly what it says it does.  But I think that most people would be
> unhappy to see '_' in their ncdump output for values that they consider to
> be valid.
> 
> ncview also treats _FillValue as missing even if it's contained in a
> specified valid range.  In an image of a 2D field this results in "valid"
> data being displayed in a color outside the color map.
> 
> My conclusion from this is that _FillValue should never be used to
> indicate
> a default value for valid data, because it will be treated exactly as if
> it
> were missing, or never written, by most applications.
> 
OK, you have convinced me this would be a very confusing & stupid thing to
do.  But I suspect John Caron
still wants a rule to handle this case if it does occur.  I think it would
be reasonable in this case to treat the
_FillValue as valid.

• Follow-Ups:
  • Re: _FillValue
    • From: John Caron