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. Cheers, Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev