#73: r.out.gdal tiff output does not work --------------------------+------------------------------------------------- Reporter: helena | Owner: [email protected] 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>
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
