> 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 ;-) ) Did you run into particular problems beyond this apparent mismatch ? Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
