problem with Mapserver WCS handling of NaN?

[Frank Warmerdam]

Jeff de La Beaujardiere wrote:
> Frank Warmerdam wrote:
>> GDAL does not generally support specifying NaN as a nodata value,
>> and neither does MapServer specifically support this.
> 
> And yet, somehow, when the same GeoTIFFs are converted to images
> by the WMS component (based on CLASS entries in the mapfile), all
> the NaN areas are transparent. How does that happen?
>
> ...Wait, I think I know. The fact that it works in the WMS case
> is accidental. GDAL (or something) is converting NaN to 0. If I
> request a numeric output (WCS), I get floating-point 0.0 values,
> which is bad. However, if I request an image output (WMS), I get
> zeroes in all 4 image channels (red, green, blue, alpha), and
> alpha=0 makes that pixel transparent, which is good.

Jeff,

Yes, likely.  Depending on how your WCS is setup, the NaN's may be
converted to zeros as part of coercing the data type to integer (byte).
Or it may be that NaN does not match any class definition.

>> If you wanted, we could look at mechanisms to specify NaN as a nodata 
>> value in GDAL
> 
> In theory, we shouldn't have to specify that explicitly. Not-a-number
> is a legitimate construct in the IEEE floating-point definition used
> by TIFF. GDAL should not be converting NaNs to anything, just passing
> them through as-is.

And that is what currently happens if the data is requested as a float.

> A single GeoTIFF should magically work. 

Well, there is work, and there is work.  GDAL has a nodata scheme tuned
to integer data where the "nodata value" is kept track of as a special
sort of metadata.  All the machinery that understands "nodata is
transparent" only kicks in when that metadata is set to a value.

I would claim you produced a poor product by not providing the metadata
indicating that NaN should be treated as nodata.  You might counter
claim that it is the self-evident meaning of NaN - but unfortunately
my software (and much imaging software) is built on a general model
with poor handling of special floating point capabilities like Inf,
NaN and values that have no numeric meaning.

>> I'm not positive that the case you are using for WCS
>> in MapServer even honours nodata values in the source data.
> 
> I'm not sure what you mean by that.

There are many different pieces of logic things can go through
in MapServer WCS.  For instance IMAGEMODE BYTE is handled quite
distinctly from IMAGEMODE RGB or IMAGEMODE PC256.  It can make
quite a difference whether you are going through reprojection or not.
Some of these code paths do not support "nodata" value because the
imagery is scaled to 8bit before any operations that could recognise
nodata.

>> Is it practical for you to work with files with a more conventional
>> style of data value?
> 
> I will gladly try anything you suggest to make this work.
> I could convert my files so that no-data areas were represented
> by a numeric value (people often use something like 9999 or -9999).
> However, GDAL and WCS would have no way of knowing that if an area
> of 9999 overlays an area of valid data that the valid data should
> "show through." NaN is really the only unambiguous choice.

On the contrary - you could declare in the TIFF metadata that the
value (ie. 9999) is nodata and MapServer will attempt to treat it
as transparent.  However, as I noted above there are many cases and
some may not support this.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org