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.
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. A single GeoTIFF should magically work. Multiple overlapping GeoTIFFS are, admittedly, more complex. When the tiling is done, a pixel value from a file later in the tile index should overwrite the former value only if the new value is a real number. This part somehow works in the WMS case--the transparent areas of a later file let the opaque areas of an earlier file show through.
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.
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. -Jeff DLB
