[gdal-dev] Setting NODATA to -nan

[Homme Zwaagstra]

On 15/07/15 19:02, Even Rouault wrote:
>
 >> Thanks Even,
 >>
 >> I have submitted <https://trac.osgeo.org/gdal/ticket/6036> with an
 >> attached TIFF
 >> infested with `-nan` values.
 >>
 >> While researching this I cam across this question
 >> <http://stackoverflow.com/q/3772835> which might contain some 
information of
 >> interest.
 >
 > Hum looking more closely at representation of nan values in IEEE754, 
there is
 > at least 12 million different ways of representing nan for a 32bit 
floating
 > point value. And you can indeed have signed NaN... But I'm not sure 
it is
 > really useful to set "-nan" as the declared nodata value (it is 
stored as a
 > string in GeoTIFF) since even 2 NaN values that could be printed in 
text form
 > as "-nan" could have a different binary representation.
 >
 > The parts of GDAL that test pixel values against nodata have normally a
 > special behaviour  to test the pixel values against nodata, when the 
nodata
 > value is one of the NaN values, so I wouldn't expect this apparent
 > inconsistency to cause problems
 >
 > For example when running gdalinfo -stats on your file, I get :
 >
 > ERROR 1: negative-nan-example.tif, band 1: Failed to compute 
statistics, no
 > valid pixels found in sampling.
 >
 > Which is expected since all pixels are set to nan (-nan yeah...), so
 > ComputeStatistics() actually managed to match the declared nan with 
the -nan
 > as pixel values. (which is quite ironical since a property of nan is 
that nan
 > != nan, but here nan ~= -nan ;-) )

Firstly thanks for looking into this.  Secondly, wow - 12 million 
different ways
to say that's not a number and still not be completely convincing. From a
practical point of view that all seems fairly crazy!

>
 >
 > Did you run into particular problems beyond this apparent mismatch ?

Yes, the issue that brought this to light was that I am trying to 
convert the
single band TIFF containing -nan values to a colour relief along the 
following
lines:

gdaldem color-relief single-band.tif colour-relief.ramp 
colour-relief.tif -alpha -of GTiff -co COMPRESS=DEFLATE -co PREDICTOR=1 
-co ZLEVEL=9 -co TILED=YES

colour-relief.ramp is as follows:

382    0   1   36
171    12  15  118
114    33  109 158
57     63  184 105
5      120 234 50
0      254 255 125
nv     0   0   0   0

I was expecting the -nan values to be interpreted as nv and therefore made
transparent in colour-relief.tif.  However, they were assigned the RGB value
0,1,36 i.e. the maximum value in the ramp!

I can provide a bite sized example of the dataset that contains some 
real values
if that is helpful.

Best regards,

Homme

>
 > Even
 >


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150715/cba3a4a2/attachment.html>