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

[GRASS GIS]

#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 mmetz):

 Trying to summarize the suggestions and discussions for a new design:

  * before actual export new precision test for each band
    - FCELL/DCELL to be exported as some GDAL integer type -> warning
    - CELL exported as GDT_FLOAT32 and raster_min < -2^24^ or raster_max >
 2^24^ -> warning
    - DCELL exported as GDT_Float32 -> warning

  * before actual export new range test for each band
    - if raster_min >= type_min and raster_max =< type_max -> fine, proceed
    - else if raster_min > type_max or raster_max < type_min -> complete
 data loss, error
    - else there is a partial data range overlap -> check data range during
 actual export

  * before actual export, get a reasonable default nodata value if none
 given
    - NaN for all GDAL floating point datatypes. Is NaN constructed with
 0.0/0.0 ok?
    - GDAL signed int types: first try minimum in potential range, if
 raster_min <= type_min, try maximum in potential range, if raster_max >=
 type_max, use minimum (would be (GInt32) 0x80000000 for GDT_Int32). This
 can re-use results of range check above.
    - GDAL unsigned int types: first try maximum in potential range, if
 raster_max >= type_max, try minimum in potential range, if raster_min <=
 type_min, use maximum. This can re-use results of range check above.
    - no warnings or errors at this stage because it is yet unknown if
 there are any NULL cells in the (with g.region selected part of the)
 raster maps to be exported

  * before actual export, in case of custom nodata make sure the metadata
 nodata value and the raster nodata value are identical
    - if (nodata != (double) (GDAL datatype) nodata) -> warning and nodata
 = (double) (GDAL datatype) nodata
    - This would give feedback to the user about what GDAL has to do later
 for the selected export datatype and nodata value. And the metadata nodata
 value would always be identical to the value replacing NULL cells.

  * during actual export, check for presence of cells with nodata value
    - NULL cells present: message about nodata value used to replace NULLs
    - if there are cells == nodata value and NULL cells were assigned that
 nodata value -> -f flag and user nodata value: warning, else error

  * during actual export, check actual raster range against range of GDAL
 datatype if needed (depends on result of range check above)
    - raster_min < type_min or raster_max > type_max -> data loss, error

 as in previous C versions of r.out.gdal, only write GDAL nodata to
 metadata if NULLs were encountered. It seems that GDAL metadata nodata is
 raster band specific, not globally set for the whole file; r.out.gdal
 behaves accordingly.

 All warnings and errors should clearly explain what is the problem and
 give tips on how it can be solved.

 Hamish, what exactly should this compatibility flag do? There is all sorts
 of software with all sorts of different deficiencies out there...

 I hope I didn't forget something

 Markus M

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/73#comment:49>
GRASS GIS <http://grass.osgeo.org>