#788: r.out.gdal and nodata ----------------------+----------------------------------------------------- Reporter: frankie | Owner: [email protected] 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>
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
