[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):

 r.out.gdal GeoTIFF compatibility testing and new r.out.gdal test version

 Changes in r.out.gdal test version
 new flag for colortable export, default to no
 nodata value adjustment to range of selected data type with warning
 message, if user-specified nodata value is out of range
 data range checking against the selected data type, abort with error if
 range of selected data type exceeded
 alignment of current region extends to raster resolution (original uses
 current region extends and resolution), current region restored on exit
 raster band statistics (min, max, mean, stddev) written to metadata if
 supported, GDAL decides

 I tested with QGIS-0.9.1 on Linux 64bit, QGIS -0.11.0-1 on XP, SAGA-2.0.3
 on XP (doesn't work for me on Linux 64bit), gvSIG-1.1.2 (32bit binary) on
 Linux 64bit, gvSIG-1.1.1 on XP, PCI Geomatica FreeView 9.1 on XP, ER
 Viewer 7.2 (ER Mapper) on XP, and ArcMap 9.2 (ESRI) on XP.


 Tests were performed with the elevation raster map layer (range within
 Byte, FCELL map) in the North Carolina sample dataset, creating a MASK for
 elevation values <= 70m, needed for testing of nodata handling with
 nodata=0. The elevation raster was exported as Byte, UInt16, Int32, and
 Float32, once with colortable (Byte and UInt16 only, colortable export for
 other data types not supported by gdal), once without colortable, always
 as GeoTIFF.


 QGIS-0.9.1 on Linux 64bit

 display: all ok

 colortable: all ok

 cell values: all ok

 nodata: all ok



 QGIS-0.11.1 on XP

 display: all ok

 colortable: all ok

 cell values: all ok

 nodata: all ok



 gvSIG-1.1.2 (Linux 32bit binary) on Linux 64bit. Projection EPSG:32119

 display: fail for UInt16 with colortable, all other ok

 colortable: fail for UInt16, Byte ok

 cell values: fail for Byte!!! (sometimes reports negative values), all
 other ok. Interestingly the display seems to use correct values. Bug in
 gvSIG-1.1.2

 nodata: nodata not supported, actual cell value reported



 gvSIG-1.1.1 on XP, Projection EPSG:32119

 display: fail for UInt16 with colortable, all other ok

 colortable: fail for Uint16, ok for Byte

 cell values: fail for Byte!!! (sometimes reports negative values), all
 other ok. Interestingly the display seems to use correct values. Bug in
 gvSIG-1.1.1

 nodata: nodata not supported, actual cell value reported



 PCI Geomatica FreeView 9.1 on XP

 display: all ok

 colortable: all ok

 cell values: all ok

 nodata: nodata not supported, actual cell value reported



 ER Viewer 7.2 (ER Mapper) on XP

 display: fail for UInt16 with colortable, all other ok

 colortable: fail for UInt16, ok for Byte

 cell values: cell value query not supported

 nodata: cell value query not supported



 SAGA-2.0.3 on XP (I don't get it to run on Linux 64bit)

 display: all ok

 colortable: all ignored

 cell values: all ok

 nodata: all ok



 ESRI ArcMap 9.2 on XP

 display: all ok, but all without colortable and other than Byte need
 manual adjustment which is painfully slow, even for these small raster
 layers (Properties -> Symbology -> Stretch -> Minimum-Maximum)

 colortable: all ok

 cell values: all ok

 nodata: all ok



 Colortables are not allways properly rendered. GIMP and image viewers
 which are not using GDAL render a colortable for Byte type properly. Data
 types other than Byte can not be read by these 'standard' image editing
 and viewing applications.

 If nodata specification is not supported, applications return the actual
 cell value, in this case 0, instead of "NoData", "NULL", "" or similar.
 The files are still perfectly readable, only nodata assignment doesn't
 happen.

 I suggest adding a flag for colortable export with default to no and
 nodata value checking as well as data range checking against the selected
 data type.

 Another issue I discovered is that r.out.gdal uses the current region
 settings for export. This can cause implicit resampling to a different
 resolution which should be avoided IMHO. Instead, r.out.gdal could use the
 current region extends, but align the region settings used for export to
 the raster to be exported. This way, a subregion can still be exported,
 but the resolution of the GRASS raster is preserved. Also maybe check
 whether the current region extends are within the raster extends?
 Alignment of the current region to the raster to be exported by a new
 r.out.gdal is not crucial, it can be done manually beforehand with
 g.region align="myraster", but it would be very convenient if r.out.gdal
 does that and restores the original region settings after successful
 export.

 The test version of gdal is available at
 http://markus.metz.giswork.googlepages.com/r.out.gdal.conservative.tar.gz

 See enclosed README for full description and justification of all changes.

 Markus

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