#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 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>