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

Markus Metz markus.metz.giswork at googlemail.com
Wed Apr 15 14:36:01 EDT 2009


Moritz Lennert wrote:
> 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.
1. warn the user only if no nodata value is given, otherwise (nodata 
value was given) assume that the user knows what she/he is doing?
1a. only in the patch which is not submitted, and no precision test.
2. suggested but nowhere implemented. why should we have a force option 
to override all the requested but not yet present safety checks?
3. was always possible

I THINK calculating a reasonable nodata value is both time and memory 
expensive, maybe there is some ingenious way to avoid memory costs, but 
I'm pretty sure that two passes for each raster band are necessary, i.e. 
time intensive.

r.out.gdal selects a file format, a suitable data type and a default 
nodata value if none of them were given, but that's more of a guess, and 
the user should know best what file format, data type and nodata value 
is appropriate. It gets all a bit more complicated because r.out.gdal 
can export several raster maps into one single file if supported by the 
selected file format. Therefore I would prefer some simple tests and 
abort with a helpful message if something goes wrong instead of doing 
fancy automated guessing that would make the code much more complex and 
thus more difficult to maintain.

r.out.gdal supports all raster formats supported by gdal, and that's a 
lot, becoming more with every new version of gdal. IMHO, r.out.gdal 
should check if input options would cause corrupted output and otherwise 
refer to the gdal documentation.

I'm busy working on an update for r.out.gdal and should be able to 
submit to trunk tomorrow. Changes are range-check for both the raster 
band to be exported (does it fit into the selected datatype) and nodata 
value, and it would abort with an error if the selected nodata value is 
present in the raster to be exported, avoiding information loss (no time 
or memory penalty here).

Markus M


More information about the grass-dev mailing list