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

[Markus Metz]

Glynn Clements wrote:
> Dylan Beaudette wrote:
>
>   
>> 3. Allow the user to specify what they would like NULL cells encoded as. 
>> Unless I am overlooking something, it would seem reasonable to export a CELL 
>> map to a signed integer format, and use some obvious negative value for NULL:
>>     
>
> If you're exporting to a 32-bit (signed or unsigned) integer format,
> the obvious choice for null is 0x80000000. That's what GRASS uses
> internally, so it can never occur as a legitimate value (if a
> computation ends up producing that value, it will get treated as a
> null in all regards).
>   
0x80000000 as nodata value seems to work with GeoTIFF for Int32 but not 
for UInt32, here gdalinfo tells me NoData Value=2147483648 which is well 
within the range of UInt32. It may be a problem that nodataval in 
r.out.gdal is of type double, so 0x80000000 is cast to double and then 
either back to int or left as double. In the case of UInt32, the raster 
to be exported is currently read as DCELL, written as GDT_Float64 and 
then converted to GDT_UInt32. There is a lot of type casting going on in 
r.out.gdal, making tests a bit complicated. In the end, the value 
assigned to NULL cells must match the nodata value in the metadata, and 
a safe default choice seems to be type min or type max.

NaN seems to work for Float32 and Float64, at least gdal reports NoData 
Value=nan and QGIS display is ok for GTiff, HFA, PAux, EHdr. NaN is 
constructed with 0.0/0.0, idea from r.univar.

IMHO, using 0x80000000 or similar can be dangerous (not sure about NaN) 
because I don't know how these values are supported by all the different 
file formats and all the different applications. Testing welcome!

I would suggest to use some fool-proof default nodata value for GDAL 
integer types, i.e. type min or type max, check if it works, otherwise 
abort and ask the user to specify a nodata value. For GDAL floating 
point types, it could be recommended to use the default nodata value 
(NaN) instead of specifying a nodata value.

Markus M