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

[Markus Metz]

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?