[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              
----------------------+-----------------------------------------------------
Comment (by mmetz):

 Replying to [comment:4 hamish]:
 > Replying to [comment:3 mmetz]:
 > > the r.out.gdal version in 6.5 is not the proper fix,
 >
 > ok. for my needs yesterday it did the trick though, but I had to run it
 twice to learn + get there.

 Not good, it shouldn't be that complicated. The module should export a
 correct raster map with default settings only, also if GDAL format is
 given but nothing else. It gets a bit more complicated with nodata value
 and/or data type set.
 >
 > > 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.
 >
 > could you quickly highlight the differences between them now? I've sort
 of lost track.

 This is what g7 r.out.gdal does:

 Before actual export:

 1. Range check: abort with error if the selected GDAL data type can not
 hold any of the values in the raster, e.g. using GDAL data type Byte with
 a CELL raster with all values > 255 and/or < 0: Raster export would result
 in complete data loss, aborting.

 2. Precision test: precision loss occurs if DCELL is exported as some
 integer or FLOAT32 or if Float32 is exported as some integer or if CELL is
 exported as Float32 and the min max values are outside the range of what
 can be represented in Float32 (see [!1]). Override with force flag.

 3. Check if any given nodata value is within the range of the selected
 GDAL data type. Report what would happen and abort raster export if
 outside range (mismatch between metadata nodata value and the value
 replacing NULLs). Effects can be drastic, try g7 r.out.gdal with type=Byte
 and nodata=-1 and nodata=-9999. Can't override.

 4. Get default nodata value if none specified: for any floating point this
 is NaN, for integer types, it figures out a default type. Based on
 discussion in [!1].

 During actual export:

 5. Real nodata value check: abort if the selected nodata value is present
 in the part of the raster map to be exported. Override with force flag.

 6. Real range check: abort if any values in the part of the raster map to
 be exported are outside the selected GDAL data type -> data loss, near
 unpredictable results, can't override.

 The checks during the actual export could be moved to a separate pass over
 all raster bands to be exported, I think this is the safest solution, then
 r.out.gdal does not have to bother with cleaning up and can leave all
 format-specific error handling to GDAL. Looking at the ever increasing
 number of GDAL-supported formats, the introduction of format specific code
 to r.out.gdal would open a box of Pandora, and IMHO the purpose of
 r.out.gdal is that all that format-specific stuff can be left to the GDAL
 lib.

 What is missing is a region check. At the very least, r.out.gdal should
 make sure that at least some parts of the raster maps to be exported fall
 within the current region, if not, abort with error: raster map outside
 current region, nothing to export. I wouldn't make it too complicated, so
 no resolution checks and also export if parts of the current region are
 not covered by the raster map to be exported.

 [!1] http://lists.osgeo.org/pipermail/grass-dev/2009-April/043464.html and
 following

 Markus M

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