[GRASS-dev] Re: [GRASS GIS] #788: r.out.gdal and nodata

[GRASS GIS]

#788: r.out.gdal and nodata
----------------------+-----------------------------------------------------
  Reporter:  frankie  |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect   |      Status:  new                      
  Priority:  normal   |   Milestone:  6.4.0                    
 Component:  Raster   |     Version:  6.4.0 RCs                
Resolution:           |    Keywords:  r.out.gdal, nodata       
  Platform:  Linux    |         Cpu:  Unspecified              
----------------------+-----------------------------------------------------
Changes (by mmetz):

  * keywords:  r.in.gdal, nodata => r.out.gdal, nodata

Comment:

 Replying to [comment:2 hamish]:
 >
 > [...]
 >
 > in 6.4 it defaults to -1e+37 but setting nodata=nan explicitly on the
 command line works as expected. (I'm using gdalinfo on the output geotiff
 to confirm).
 >
 >
 > so this one is already "fixed", but waiting-for-backport from the 6.5
 branch.
 >
 the r.out.gdal version in 6.5 is not the proper fix, r.out.gdal in 7.0 is
 currently the safest version for raster GDAL export, waiting for backport
 to 6.5, then to 6.4 if it passed all testing.
 >
 > ----
 > I notice another problem. (latest 6.5svn)
 > If I export a palleted raster (with cats 0-7 + NULL) as type=Byte
 >
 {{{
 > G65> r.out.gdal in=map out=map_LL_WGS84.tif type=Byte
 creat="COMPRESS=DEFLATE,INTERLEAVE=BAND"
 >
 > Exporting to GDAL data type: Byte
 >  100%
 > Input raster map contains cells with NULL-value (no-data). The value 0
 was
 > used to represent no-data values in the input map. You can specify a
 nodata
 > value with the nodata option.
 > WARNING: The default nodata value is present in rasterband <map> and
 would
 >          lead to data loss. Please specify a different nodata value with
 >          the nodata parameter.
 > ERROR: Raster export aborted.
 }}}
 >
 > that's all fine, but it has left an incomplete map in the filesystem.
 The data is there (or at least some of it) but the georef & metadata is
 not. Just before that "ERROR: Raster export aborted." it should unlink()
 the output file.

 The output map is not always in a single file, may also be in a database
 (Oracle Spatial, Rasterlite in SQLite). How to handle e.g. Erdas Imagine
 .img with external spill files?

 > It doesn't know until after it starts to write if the default nodata
 value will also be present in the map, so aborting and deleting the file
 has to come after the fact. I assume any createopt="TFW=YES" files etc get
 written after, so we don't have to worry about deleting them too. (??)
 >
 As I see it, there are three possibilities if the nodata value is present
 in the rasterband to be exported:
 1. Current behaviour, abort with error message, leaves a broken raster.
 2. Continue with warning, leaves corrupted raster.
 3. Introduce a first pass to check if the nodata value is present in the
 rasterband to be exported, abort with error if necessary before actual
 export. No output is written, but it will double the time needed for
 export.

 Anyway, the above example would successfully export in 7.0, in this case
 255 would be selected as default nodata value because 0 is present in the
 rasterband.

 What parts of the 7.0 version of r.out.gdal qualify as bugfixes and what
 parts qualify as changed default behaviour compared to 6.4?

 BTW, the INTERLEAVE option has no effect if only one raster band is
 exported.

 Markus M

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/788#comment:3>
GRASS GIS <http://grass.osgeo.org>