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@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
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
