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

[Dylan Beaudette]

On Wednesday 15 April 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.
>
> Moritz

Thanks for the notice on 2-3. Your approach sounds good to me. 

Cheers,
Dylan

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