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

Glynn Clements glynn at gclements.plus.com
Fri Apr 17 01:36:52 EDT 2009


Markus Metz wrote:

> >>> 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.
> >>     
> >
> > Nope.
>    
> Not sure if your Nope refers to all of the above or only some of the 
> above ;-)

To the guesses about int/float casts being involved, or r.out.gdal
being involved. Export works fine either way; it's the import that's
problematic.

> Int32 is preferable over UInt32, ok, but it is possible to export a CELL 
> (or any other) raster as UInt32.

It's possible, but it's lossy, the same as exporting CELL to an 8-bit
or 16-bit format.

> > If the input is GDT_Int32, GDAL interprets 0x80000000 as -2147483648,
> > which is within the range of an int. But if the input is GDT_UInt32,
> > 0x80000000 is interpreted as +2147483648, which is out of range.
> >   
> out of range of CELL, not GDT_UInt32.

Yes.

> Input can not be GDT_UInt32, 
> unless you are referring to r.in.gdal instead of r.out.gdal (leaving out 
> r.external links).

I'm referring to r.in.gdal.

> > r.in.gdal can't just read the data as GDT_UInt32, as that would result
> > in negative values being converted to zero.
> >   
> ??? should r.in.gdal not import data as they are, e.g. UInt32, and then 
> select a grass raster type that can hold the data range, FCELL or DCELL 
> for UInt32, but not CELL?

Arguably it should, but it doesn't; both Int32 and UInt32 are imported
as Int32/CELL.

It should probably check the range of the data to select an
appropriate type. E.g. if it's UInt32 but the range will fit into
CELL, then import as UInt32 into a CELL array.

> >  As CELL is signed, exporting as
> > GDT_UInt32 is lossy; half the range of the source type is
> > unrepresentable, while half the range of the destination type is
> > unused.
> 
> Still, it is possible. Your comment could go into the manual. All the 
> complex GDAL data types are also not represented by GRASS raster types.

Exporting to complex is safe, but somewhat pointless (unless you add
an option to export separate real and imaginary maps; this might be
useful for i.fft output).

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

If it's been changed, use nodata=-0x80000000. Or cast the nodata value
to the source data type then back to double.

> I could not find a fool-proof nodata value for Int32 exports in my tests 
> (independent of the grass raster map type), so I would leave it to the 
> user and within r.out.gdal make sure the selected nodata value is not 
> present in the grass raster.
> 
> Markus M
> 
> PS: I don't insist on exporting as UInt32, that was just an example. A 
> better example would have been the troublemaker UInt16.

For an 8-bit or 16-bit type, overflow can't always be avoided. But it
should always be possible to losslessly export CELL to a 32-bit type.

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


More information about the grass-dev mailing list