Markus Metz 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.
Nope. The problem is that r.in.gdal reads the data as GDT_Int32, which causes GDAL to clamp 0x80000000 to 0x7fffffff. 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. r.in.gdal can't just read the data as GDT_UInt32, as that would result in negative values being converted to zero. Ultimately, exporting CELL data as GDT_UInt32 is a bad idea, as it cannot represent negative values. 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. > 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. The only "fool-proof" nodata value for CELL is 0x80000000; all other values may be actual data values. More generally, you can't losslessly export N+1 data values using a format which only supports N values (e.g. exporting 0-255 plus null using only one byte per cell). -- Glynn Clements <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
