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

[Dylan Beaudette]

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.

Cheers,

Dylan


-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341