[GRASS-dev] Re: [GRASS GIS] #788: r.out.gdal and nodata

[GRASS GIS]

#788: r.out.gdal and nodata
----------------------+-----------------------------------------------------
  Reporter:  frankie  |       Owner:  grass-dev at lists.osgeo.org
      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 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.

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


 > > it has left an incomplete map in the filesystem.
 ...
 > The output map is not always in a single file, may also be in
 > a database (Oracle Spatial, Rasterlite in SQLite). How to handle
 > e.g. Erdas Imagine .img with external spill files?

 don't know. perhaps we can't catch all cases. perhaps we are helped by the
 fact that some of the extra files get written along with the metadata
 after the job is done. We would need GDAL-dev's advice on this one I
 think.

 > As I see it, there are three possibilities if the nodata value
 > is present in the rasterband to be exported:
 > 1. Current behaviour, abort with error message, leaves a broken raster.

 1.5. Current behaviour, abort with error message, but try to delete what
 we know can. A possible way to do this is to write the output to
 $MAPSET/.tmp/ and then move it into the destination dir once successfully
 complete. (??)

 > 2. Continue with warning, leaves corrupted raster.

 no thanks. unknowingly trusting corrupted data is the worst kind of bug.
 if it's in a script you are likely to miss the warning message in all the
 noise.

 > 3. Introduce a first pass to check if the nodata value is
 > present in the rasterband to be exported, abort with error if
 > necessary before actual export. No output is written, but it will
 > double the time needed for export.

 actually it'll be a bit faster than double. After the initial read from
 disk most of it will be cached in memory and not need to be read again,
 and also the scanning step is probably less i/o and cpu intensive than the
 step that writes to disk. Personally I'm willing to trade a little time to
 guarantee pristine results, but that may not fit everyone's use case.
 Those really concerned with the time could use the -force flag to bypass
 those checks...


 > Anyway, the above example would successfully export in 7.0, in
 > this case 255 would be selected as default nodata value because
 > 0 is present in the rasterband.

 ok.

 > What parts of the 7.0 version of r.out.gdal qualify as bugfixes
 > and what parts qualify as changed default behaviour compared to
 > 6.4?

 again, I've sort of forgotten how far things got and am not sure what's on
 that list.


 > BTW, the INTERLEAVE option has no effect if only one raster band
 > is exported.

 yeah, I noticed that after posting. I had cut&pasted it out of my template
 collection (aka the man pages) and it went along for the ride.


 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/788#comment:4>
GRASS GIS <http://grass.osgeo.org>