<div dir="ltr"><div><div><div>Hi,<br><br></div><div>it might be that some communication improvement from GRASS-GDAL could be done?<br></div><div><br></div>is there a clear NODATA/NAN definition understood within GDAL that we could use within r.out.gdal as a target NODATA value whenever anything than a number is used (i.e. NaN, nan, -nan, helloworld, mynameisbee, etc.)<br><br></div>typically MODIS users are used to -28768 and similar "standard" NODATA numbers, but that maybe another story.<br><br></div>0.01c<br><div><div><br><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 16, 2015 at 6:34 PM Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi devs,<br>
<br>
FWD of an issue with r.out.gdal in G7. Any ideas?<br>
<br>
Markus<br>
<br>
<br>
---------- Forwarded message ----------<br>
From: Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>><br>
Date: Thu, Jul 16, 2015 at 2:07 AM<br>
Subject: Fwd: Re: [gdal-dev] Setting NODATA to -nan<br>
To: <a href="mailto:neteler@osgeo.org" target="_blank">neteler@osgeo.org</a><br>
<br>
<br>
Hi Markus,<br>
<br>
Below you'll find the original report about what discussed on the way to the<br>
party tonight, and then my analysis. The GDAL ticket with the dataset is<br>
<a href="https://trac.osgeo.org/gdal/ticket/6036" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/ticket/6036</a><br>
<br>
I'm not sure there's really an issue in practice on the GDAL side. It is just<br>
that dealing with nan is odd to anybody (and the way Windows and Linux<br>
displays nan as a string is different).<br>
<br>
Even<br>
<br>
<br>
<br>
<br>
[gdal-dev] Setting NODATA to -nan<br>
From: Homme Zwaagstra <<a href="mailto:hrz@geodata.soton.ac.uk" target="_blank">hrz@geodata.soton.ac.uk</a>><br>
To: gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>><br>
Date: Yesterday 11:21:54<br>
Hello,<br>
<br>
I've got the following raster exported from GRASS using `r.out.gdal`:<br>
<br>
gdalinfo ppp-2015.tif<br>
Driver: GTiff/GeoTIFF<br>
Files: ppp-2015.tif<br>
ppp-2015.tif.aux.xml<br>
Size is 432017, 216009<br>
Coordinate System is:<br>
GEOGCS["WGS 84",<br>
DATUM["WGS_1984",<br>
SPHEROID["WGS 84",6378137,298.257223563,<br>
AUTHORITY["EPSG","7030"]],<br>
AUTHORITY["EPSG","6326"]],<br>
PRIMEM["Greenwich",0],<br>
UNIT["degree",0.0174532925199433],<br>
AUTHORITY["EPSG","4326"]]<br>
Origin = (-180.000000000000000,90.000000000000000)<br>
Pixel Size = (0.000833300541414,-0.000833298612558)<br>
Metadata:<br>
AREA_OR_POINT=Area<br>
Image Structure Metadata:<br>
COMPRESSION=DEFLATE<br>
INTERLEAVE=BAND<br>
Corner Coordinates:<br>
Upper Left (-180.0000000, 90.0000000) (180d 0' 0.00"W, 90d 0' 0.00"N)<br>
Lower Left (-180.0000000, -90.0000000) (180d 0' 0.00"W, 90d 0' 0.00"S)<br>
Upper Right ( 180.0000000, 90.0000000) (180d 0' 0.00"E, 90d 0' 0.00"N)<br>
Lower Right ( 180.0000000, -90.0000000) (180d 0' 0.00"E, 90d 0' 0.00"S)<br>
Center ( 0.0000000, 0.0000000) ( 0d 0' 0.01"E, 0d 0' 0.01"N)<br>
Band 1 Block=256x256 Type=Float32, ColorInterp=Gray<br>
NoData Value=nan<br>
Metadata:<br>
COLOR_TABLE_RULES_COUNT=5<br>
COLOR_TABLE_RULE_RGB_0=0.000000e+00 1.681282e+03 255 255 0 0 255 0<br>
COLOR_TABLE_RULE_RGB_1=1.681282e+03 3.362563e+03 0 255 0 0 255 255<br>
COLOR_TABLE_RULE_RGB_2=3.362563e+03 5.043845e+03 0 255 255 0 0 255<br>
COLOR_TABLE_RULE_RGB_3=5.043845e+03 6.725127e+03 0 0 255 255 0 255<br>
COLOR_TABLE_RULE_RGB_4=6.725127e+03 8.406408e+03 255 0 255 255 0 0<br>
Generated_with=GRASS GIS 7.0.0<br>
<br>
As you can see the NoData is set to `nan`. However, within the data it is<br>
actually `-nan`:<br>
<br>
gdallocationinfo ppp-2015.tif -wgs84 42.0776 30.9305<br>
Report:<br>
Location: (266503P,70886L)<br>
Band 1:<br>
Value: -nan<br>
<br>
I have tried to force the NoData to `-nan` as follows but with no joy:<br>
<br>
gdal_translate -a_nodata '-nan' -of VRT ppp-2015.tif ppp-2015.vrt<br>
<br>
gdalinfo ppp-2015.vrt<br>
Driver: VRT/Virtual Raster<br>
Files: ppp-2015.vrt<br>
/data/data/ppp_v2c_2015/ppp-2015.tif<br>
Size is 432017, 216009<br>
Coordinate System is:<br>
GEOGCS["WGS 84",<br>
DATUM["WGS_1984",<br>
SPHEROID["WGS 84",6378137,298.257223563,<br>
AUTHORITY["EPSG","7030"]],<br>
AUTHORITY["EPSG","6326"]],<br>
PRIMEM["Greenwich",0],<br>
UNIT["degree",0.0174532925199433],<br>
AUTHORITY["EPSG","4326"]]<br>
Origin = (-180.000000000000000,90.000000000000000)<br>
Pixel Size = (0.000833300541414,-0.000833298612558)<br>
Metadata:<br>
AREA_OR_POINT=Area<br>
Image Structure Metadata:<br>
INTERLEAVE=BAND<br>
Corner Coordinates:<br>
Upper Left (-180.0000000, 90.0000000) (180d 0' 0.00"W, 90d 0' 0.00"N)<br>
Lower Left (-180.0000000, -90.0000000) (180d 0' 0.00"W, 90d 0' 0.00"S)<br>
Upper Right ( 180.0000000, 90.0000000) (180d 0' 0.00"E, 90d 0' 0.00"N)<br>
Lower Right ( 180.0000000, -90.0000000) (180d 0' 0.00"E, 90d 0' 0.00"S)<br>
Center ( 0.0000000, 0.0000000) ( 0d 0' 0.01"E, 0d 0' 0.01"N)<br>
Band 1 Block=128x128 Type=Float32, ColorInterp=Gray<br>
NoData Value=nan<br>
Metadata:<br>
COLOR_TABLE_RULES_COUNT=5<br>
COLOR_TABLE_RULE_RGB_0=0.000000e+00 1.681282e+03 255 255 0 0 255 0<br>
COLOR_TABLE_RULE_RGB_1=1.681282e+03 3.362563e+03 0 255 0 0 255 255<br>
COLOR_TABLE_RULE_RGB_2=3.362563e+03 5.043845e+03 0 255 255 0 0 255<br>
COLOR_TABLE_RULE_RGB_3=5.043845e+03 6.725127e+03 0 0 255 255 0 255<br>
COLOR_TABLE_RULE_RGB_4=6.725127e+03 8.406408e+03 255 0 255 255 0 0<br>
Generated_with=GRASS GIS 7.0.0<br>
<br>
Even editing the VRT to contain `<NoDataValue>-nan</NoDataValue>` yields a<br>
positive nan value in gdalinfo.<br>
<br>
This looks like it might be a GDAL bug to me? Is there a way I can specify<br>
`-nan` as the NODATA value for this dataset without regenerating it<br>
(it's quite<br>
large)?<br>
<br>
Many thanks,<br>
<br>
Homme<br>
<br>
<br>
---------- Forwarded Message ----------<br>
<br>
Subject: Re: [gdal-dev] Setting NODATA to -nan<br>
Date: Wednesday 15 July 2015, 20:02:11<br>
From: Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>><br>
To: Homme Zwaagstra <<a href="mailto:hrz@geodata.soton.ac.uk" target="_blank">hrz@geodata.soton.ac.uk</a>><br>
CC: <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<br>
<br>
> Thanks Even,<br>
><br>
> I have submitted <<a href="https://trac.osgeo.org/gdal/ticket/6036" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/ticket/6036</a>> with an<br>
> attached TIFF<br>
> infested with `-nan` values.<br>
><br>
> While researching this I cam across this question<br>
> <<a href="http://stackoverflow.com/q/3772835" rel="noreferrer" target="_blank">http://stackoverflow.com/q/3772835</a>> which might contain some information of<br>
> interest.<br>
<br>
Hum looking more closely at representation of nan values in IEEE754, there is<br>
at least 12 million different ways of representing nan for a 32bit floating<br>
point value. And you can indeed have signed NaN... But I'm not sure it is<br>
really useful to set "-nan" as the declared nodata value (it is stored as a<br>
string in GeoTIFF) since even 2 NaN values that could be printed in text form<br>
as "-nan" could have a different binary representation.<br>
<br>
The parts of GDAL that test pixel values against nodata have normally a<br>
special behaviour to test the pixel values against nodata, when the nodata<br>
value is one of the NaN values, so I wouldn't expect this apparent<br>
inconsistency to cause problems<br>
<br>
For example when running gdalinfo -stats on your file, I get :<br>
<br>
ERROR 1: negative-nan-example.tif, band 1: Failed to compute statistics, no<br>
valid pixels found in sampling.<br>
<br>
Which is expected since all pixels are set to nan (-nan yeah...), so<br>
ComputeStatistics() actually managed to match the declared nan with the -nan<br>
as pixel values. (which is quite ironical since a property of nan is that nan<br>
!= nan, but here nan ~= -nan ;-) )<br>
<br>
Did you run into particular problems beyond this apparent mismatch ?<br>
<br>
Even<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
-----------------------------------------<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</blockquote></div>