[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work

[Markus Metz]

This is now a mix of r.in.gdal and r.out.gdal. The two modules 
complement each other, and I guess a minimum requirement would be that 
something exported with r.out.gdal and then imported again with 
r.in.gdal should be identical (taking into consideration the region 
settings during export) and not have any data loss, be it due to 
clipping data or due to nodata problems.

Glynn Clements wrote:
>   
>>> The only "fool-proof" nodata value for CELL is 0x80000000; all other
>>> values may be actual data values.
>>>       
>> For grass rasters of type CELL, not for gdal export as Int32. gdalinfo 
>> says NoData Value=2147483648, but cells that should be nodata are 
>> -2147483648 and are thus not recognized as nodata.
>>     
>
> It worked as of a few days ago, in the version I have checked out:
>
> raster/r.in.gdal/main.c:780:
>
> 	   if (((GInt32 *) cell)[indx] == (GInt32) dfNoData) {
>
> (GInt32)2147483648 and (GInt32)-2147483648 are equal.
>   
I think the problem is that gdal allows the nodata value to be out of 
range with regard to the raster type, e.g. in gdal, a nodata value of 
-9999 with GDT_Byte is legal and can be used to effectively disable 
nodata information. No idea if this conforms to GeoTIFF specs (probably 
yes), but I'm pretty sure that this is the current policy of gdal 
(possible with e.g. gdal_translate).
That would also mean that r.out.gdal with type = GDT_Int32 and nodata = 
2147483648, NULL cells become -2147483648 but the nodata value in the 
metadata stays 2147483648 (gdalinfo on the export output), which in turn 
means that other software, also QGIS, does not see any nodata cells in 
the export output ->information loss about NULL cells. That's why I 
wouldn't use 0x80000000 as default nodata value for GDT_Int32 in 
r.out.gdal even if r.in.gdal has no problems with it.
> If it's been changed, use nodata=-0x80000000. 
That's currently done in r.out.gdal in trunk and devbr6.
> Or cast the nodata value
> to the source data type then back to double.
>   
For r.out.gdal, there was discussion about not to override user options 
and instead issue an error or a warning (going for error now) that the 
nodata value is out of range. Currently, all default nodata values are 
within the range of the selected GDAL data type. User-defined nodata 
values are tested whether they are within the range of the selected data 
type, if not, r.out.gdal in trunk and devbr6 exits with an error 
message. r.out.gdal also exits with an error message if the nodata value 
is present in the raster to be exported in order to avoid data loss.
This is a rather strict and conservative approach because of the 
reported problems with nodata in r.out.gdal exports.

Markus M