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

Markus Metz markus.metz.giswork at googlemail.com
Tue Apr 21 10:33:32 EDT 2009


Glynn Clements wrote:
> Markus Metz wrote:
>   
>> I think I slowly begin to understand. You suggest to use 
>> (GDT_Int32)0x80000000 for both the GDAL metadata info and the GDAL 
>> raster data although GDAL metadata nodata is double?
>>     
>
> Yes; for the latter, the value would be:
>
> 	(double) (GDT_Int32) 0x80000000
>
> IOW, -2147483648.0.
>
> Note that this isn't the same as atof("0x80000000"), which would be
> positive.
>   
Obviously. Because of the request for a -f flag I was fixed on leaving 
r.out.gdal parameters as they are, also leaving default nodata as 
double, no prior cast to the GDAL datatype. My confusion, it's clear now 
what you want for the default nodata value.
Further on, I understand you suggest to interpret the user given nodata 
option by writing to metadata (double) (GDAL datatype) <nodata value>. 
No more objections from my side, but I would print a warning if (nodata 
!= (double) (GDAL data type) nodata), telling the user what the nodata 
value will be after GDAL converted it. I would suggest to keep writing 
(double) <nodata value> with the -f flag, no prior cast. In case of the 
-f flag and a mismatch (nodata != (double) (GDAL data type) nodata), a 
message/warning could be printed with both the nodata value written to 
metadata and the value assigned to NULL cells.
>>
>> I was assuming that not only CELL, but also FCELL and DCELL maps may be 
>> exported as GDT_UInt32. Then 2^31 can occur in the raster to be 
>> exported. Actually, I was assuming that any GRASS raster type may be 
>> exported as any GDAL data type.
>>     
>
> Right. But exporting FCELL or DCELL as GDT_UInt32 is inherently lossy. 
>   
Just to make it clear: I don't insist on exporting to GDT_UInt32, but 
this is supported by r.out.gdal for all GRASS raster types, so this 
possibility must be considered IMHO, unless GDT_UInt32 becomes disabled.
> For DCELL, every possible GDT_UInt32 value may occur in the source
> data, so there isn't any "ideal" default no-data value.
>   
That's why I first want to check the range of the raster map(s) to be 
exported.
>> What if the user asks for a nodata value to be out of range, i.e. really 
>> wants it to be out of range, leading to a mismatch between the nodata 
>> value in the metadata and the value assigned to NULL cells in the GDAL 
>> export? I understood that this was requested to be possible.
>>     
>
> Hmm. To allow that, you can't cast to the source or destination type,
>   
Exactly. That's why I was thinking about e.g. (double) 2147483648 to be 
written to metadata, and not (double) (GDT_Int32) 2147483648. BTW, I can 
still not see why a user would want that, but it can be allowed.
> 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.
>   
>>>> If r.out.gdal should support out of range nodata values, and the nodata 
>>>> value is read with atof(), 2^31 should stay 2^31and not be cast to 
>>>> -2^31. The GUI description of the nodata option says that it is of type 
>>>> float (actually it's a double), i.e. suggesting that any value that is 
>>>> representable as floating point is ok.
>>>>         
>>> That's a limitation of the parser. If the input is CELL, then the
>>> nodata value which the input data uses isn't any kind of float. It
>>> might be more correct to have separate int/float nodata options.
>>>
>>> OTOH, GDAL's no-data value is always a double, even for integer data.
>>>       
>> I would rather stick to GDAL's method of handling nodata options and try 
>> to mimic that in r.out.gdal.
>>     
>
> I don't have any preference, although I suspect that users will
> regularly get bitten by the conversion issues.
>   
As above, by default r.out.gdal could write (double) (GDAL datatype) 
<nodata value> to metadata, with the -f flag no cast to GDAL datatype?
>>  
>> 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.
>
> I don't see the point in treating range limits differently to
> precision limits. Either the output type is a superset of the input
> type (lossless export) or it isn't (lossy export).
>   
Easy to change, with feedback to the user as warning in case of lossy 
export.
>
> When exporting to FP types, the default should probably be NaN (if
> supported), regardless of whether the source is integer or FP.
>
> Exporting CELL to GDT_Float32 should print a warning if the range of
> the input data exceeds +/- 2^24, as it cannot be stored exactly.
>   
OK.


More information about the grass-dev mailing list