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

[Moritz Lennert]

On 15/04/09 19:22, Dylan Beaudette wrote:
> On Wednesday 15 April 2009, GRASS GIS wrote:
>> #73: r.out.gdal tiff output does not work
>> --------------------------+------------------------------------------------
>> - Reporter:  helena       |       Owner:  grass-dev at lists.osgeo.org Type: 
>> defect       |      Status:  new
>>   Priority:  critical     |   Milestone:  6.4.0
>>  Component:  Raster       |     Version:  svn-trunk
>> Resolution:               |    Keywords:  r.out.gdal, tiff
>>   Platform:  Unspecified  |         Cpu:  Unspecified
>> --------------------------+------------------------------------------------
>> - Comment (by hamish):
>>
>>  Replying to [comment:32 mmetz]:
>>  > My patch only adds safety checks to make sure that the selected
>>  > GDAL data type covers the range of the raster band to be exported
>>  > and that the given null value is within the range of the selected
>>  > GDAL data type. That would be an enhancement, not a bugfix.
>>
>>  Pretend you are r.out.gdal iterating through the raster cells to output.
>>  You come across a NULL cell. You have to write down some value, and are
>>  completely constrained to options available in the output type. What do
>>  you write out? Overflow/wrap the type? type min? type max? well (as things
>>  were) whatever you do is going to be arbirtary, and thus could lead to
>>  data loss, which is grounds for a most serious blocker bug.
> 
> I haven't thought a great deal about this, but from what I have been reading 
> and recalling past messages on the GDAL mailing list-- there just aren't any 
> general approaches to preserving NULL values in a geotiff when you need the 
> entire range of a given datatype to represent your information. 
> 
> I think that several things can be done to address this bug, some of which 
> have been mentioned:
> 
> 1. if there are any NULL cells, warn the user- possibly refuse to export the 
> image in the current format (BYTE, etc.)
> 
> 1a. if the selected output format cannot contain the entire range, or 
> precision, of input map data (input is FCELL, output is BYTE) give a warning 
> or fail with error message.
> 
> 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
> 
> 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:
> 
> # assuming that all REAL data is within 0-255
> r.out.gdal in=CELLMAP out=map.tif format=SIGNEDINT null=-1
> 
> 
>>  > also, because the manual has been updated.
>>
>>  that is easily modified, so shouldn't stop us.
>>
>>  > In any case, it would be great if this ticket could be solved
>>  > before the final release of 6.4.
>>
>>  yup
>>
> 
> I would like to see the above changes, however I cannot actually implement 
> them. Thanks to everyone who has been working on this important module.

AFAIK, except for number 1, all are implemented already. Currently there 
is an error if the null value does not fit into the data range of the 
selected output file type, but not if the selected value for null data 
is present in the data as a valid value. But as Markus explained, 
checking for this would be quite intense, so IMHO a warning that there 
are null values and that there is the possibility of loosing information 
if the user does not watch out should be enough.

Moritz