Hi devs, FWD of an issue with r.out.gdal in G7. Any ideas?
Markus ---------- Forwarded message ---------- From: Even Rouault <[email protected]> Date: Thu, Jul 16, 2015 at 2:07 AM Subject: Fwd: Re: [gdal-dev] Setting NODATA to -nan To: [email protected] Hi Markus, Below you'll find the original report about what discussed on the way to the party tonight, and then my analysis. The GDAL ticket with the dataset is https://trac.osgeo.org/gdal/ticket/6036 I'm not sure there's really an issue in practice on the GDAL side. It is just that dealing with nan is odd to anybody (and the way Windows and Linux displays nan as a string is different). Even [gdal-dev] Setting NODATA to -nan From: Homme Zwaagstra <[email protected]> To: gdal-dev <[email protected]> Date: Yesterday 11:21:54 Hello, I've got the following raster exported from GRASS using `r.out.gdal`: gdalinfo ppp-2015.tif Driver: GTiff/GeoTIFF Files: ppp-2015.tif ppp-2015.tif.aux.xml Size is 432017, 216009 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (-180.000000000000000,90.000000000000000) Pixel Size = (0.000833300541414,-0.000833298612558) Metadata: AREA_OR_POINT=Area Image Structure Metadata: COMPRESSION=DEFLATE INTERLEAVE=BAND Corner Coordinates: Upper Left (-180.0000000, 90.0000000) (180d 0' 0.00"W, 90d 0' 0.00"N) Lower Left (-180.0000000, -90.0000000) (180d 0' 0.00"W, 90d 0' 0.00"S) Upper Right ( 180.0000000, 90.0000000) (180d 0' 0.00"E, 90d 0' 0.00"N) Lower Right ( 180.0000000, -90.0000000) (180d 0' 0.00"E, 90d 0' 0.00"S) Center ( 0.0000000, 0.0000000) ( 0d 0' 0.01"E, 0d 0' 0.01"N) Band 1 Block=256x256 Type=Float32, ColorInterp=Gray NoData Value=nan Metadata: COLOR_TABLE_RULES_COUNT=5 COLOR_TABLE_RULE_RGB_0=0.000000e+00 1.681282e+03 255 255 0 0 255 0 COLOR_TABLE_RULE_RGB_1=1.681282e+03 3.362563e+03 0 255 0 0 255 255 COLOR_TABLE_RULE_RGB_2=3.362563e+03 5.043845e+03 0 255 255 0 0 255 COLOR_TABLE_RULE_RGB_3=5.043845e+03 6.725127e+03 0 0 255 255 0 255 COLOR_TABLE_RULE_RGB_4=6.725127e+03 8.406408e+03 255 0 255 255 0 0 Generated_with=GRASS GIS 7.0.0 As you can see the NoData is set to `nan`. However, within the data it is actually `-nan`: gdallocationinfo ppp-2015.tif -wgs84 42.0776 30.9305 Report: Location: (266503P,70886L) Band 1: Value: -nan I have tried to force the NoData to `-nan` as follows but with no joy: gdal_translate -a_nodata '-nan' -of VRT ppp-2015.tif ppp-2015.vrt gdalinfo ppp-2015.vrt Driver: VRT/Virtual Raster Files: ppp-2015.vrt /data/data/ppp_v2c_2015/ppp-2015.tif Size is 432017, 216009 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (-180.000000000000000,90.000000000000000) Pixel Size = (0.000833300541414,-0.000833298612558) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left (-180.0000000, 90.0000000) (180d 0' 0.00"W, 90d 0' 0.00"N) Lower Left (-180.0000000, -90.0000000) (180d 0' 0.00"W, 90d 0' 0.00"S) Upper Right ( 180.0000000, 90.0000000) (180d 0' 0.00"E, 90d 0' 0.00"N) Lower Right ( 180.0000000, -90.0000000) (180d 0' 0.00"E, 90d 0' 0.00"S) Center ( 0.0000000, 0.0000000) ( 0d 0' 0.01"E, 0d 0' 0.01"N) Band 1 Block=128x128 Type=Float32, ColorInterp=Gray NoData Value=nan Metadata: COLOR_TABLE_RULES_COUNT=5 COLOR_TABLE_RULE_RGB_0=0.000000e+00 1.681282e+03 255 255 0 0 255 0 COLOR_TABLE_RULE_RGB_1=1.681282e+03 3.362563e+03 0 255 0 0 255 255 COLOR_TABLE_RULE_RGB_2=3.362563e+03 5.043845e+03 0 255 255 0 0 255 COLOR_TABLE_RULE_RGB_3=5.043845e+03 6.725127e+03 0 0 255 255 0 255 COLOR_TABLE_RULE_RGB_4=6.725127e+03 8.406408e+03 255 0 255 255 0 0 Generated_with=GRASS GIS 7.0.0 Even editing the VRT to contain `<NoDataValue>-nan</NoDataValue>` yields a positive nan value in gdalinfo. This looks like it might be a GDAL bug to me? Is there a way I can specify `-nan` as the NODATA value for this dataset without regenerating it (it's quite large)? Many thanks, Homme ---------- Forwarded Message ---------- Subject: Re: [gdal-dev] Setting NODATA to -nan Date: Wednesday 15 July 2015, 20:02:11 From: Even Rouault <[email protected]> To: Homme Zwaagstra <[email protected]> CC: [email protected] > 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 ----------------------------------------- -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
