Glynn Clements wrote:
Markus Metz wrote:
so the user will have to understand the conversion issues even if they
never use an out-of-range value. Ultimately, its either usability or
flexibility.
Without the -f flag I would opt for usability, with the -f flag for
flexibility.
Having -f affect the interpretation of nodata= also harms usability.
I know. There was discussion about that, and Dylan asked for the
possibility to
"2. include a 'force' option to make r.out.gdal do exactly what your
command line instructions suggest-- possibly leading to corruption of
NULL data"
Maybe this referred only to the problem of input data having the
requested nodata value, and not to allow a mismatch between metadata
nodata and the value replacing NULL cells?
The GDAL API documentation says "To clear the nodata value, just set it
with an "out of range" value." This is currently possible with the -f
flag, but r.out.gdal then does not give any information on what value is
assigned to NULL cells, only what nodata value is written to the metadata.
Right. There's only one nodata= option, and it's performing a dual
function: what to store for null cells and what to set GDAL's no-data
value to. If you want to allow a mismatch, you really need two
options.
I thought in this case (allow mismatch) it would be enough to write it
as double to metadata without prior cast to the selected GDAL datatype.
Yeah, but what are you going to write for nulls in the input data?
Suppose the user specifies a CELL input map (which contains at least
0-255 and null), byte (GDT_UInt8) output, -f, and nodata=9999. So you
use 9999.0 as GDAL's no-data value, but how will you treat null values
in the input data?
In this case, the current code of all C versions of r.out.gdal writes
(CELL) 9999 for NULLs. This is then cast by the gdal library to GDT_Byte
(255).
Maybe I misunderstood the requested behaviour for the -f flag, so let's
not allow a nodata mismatch, convert the nodata value first to the
selected GDAL datatype if necessary and then we get the same value for
nodata metadata and raster data where NULLs were replaced.
In this case, there should be a warning because (GDT_Byte) 9999.0 = 255
is present in the input data and the user is asked to select a different
nodata value. Export would proceed because of -f.
Anyway, now I will stop defending a feature that I was never convinced
of (allowing this nodata mismatch). Can we now put together a next
version of r.out.gdal based on this discussion that always interprets
any user-given nodata value (with warning where appropriate) to make
sure metadata info and raster data are the same?
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
