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

[Glynn Clements]

Markus Metz wrote:

> 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.

That's only possible if the exported data is in a format which can
hold the full range of the data. A UInt32 TIFF can't hold the full
range of CELL data (it can't hold any negative values).

> >>> 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,

Yes.

> 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.

You're misinterpretating my use of "0x80000000" here. I'm talking
about the C interpretation, which is the (signed) integer value
-2147483648.

> > 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.

This isn't about overriding user options, but interpreting them
correctly.

It's debatable whether just using atof(nodataopt->answer) directly is
actually a correct interpretation when the input map is CELL, or
whether the code should use e.g. atoi(nodataopt->answer) or
(CELL)atof(nodataopt->answer) for CELL inputs. Reading as int (or
casting to it) will interpret 0x80000000 as -2^31, while reading as FP
will interpret it as 2^31.

OTOH, reading as FP allows you to specify +2^31 as the nodata value
when exporting CELL as UInt32. Maybe it would be better to read as
double then cast to the destination type.

> 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.

Right.

Even so, 0x80000000 is still the ideal value for exporting CELL data
to either UInt32 or Int32. You just have to pick the correct
interpretation of it (unsigned int or signed int respectively).

-- 
Glynn Clements <glynn at gclements.plus.com>