[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work

GRASS GIS trac at osgeo.org
Wed Apr 22 09:05:08 EDT 2009


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

 Replying to [comment:47 hamish]:
 > my 2c o'today,
 >
 >  * if type is UInt8 and input map has values outside of that, just
 report an error and exit. you don't have to search every cell first, just
 use G_read_range()+G_get_range_min_max() or
 G_read_fp_range()+G_get_fp_range_min_max().
 Note that the current region is respected and the actual data range to be
 exported can be smaller than reported by G_get_fp_range_min_max(). OTOH,
 taking that into consideration may be overdoing it a bit.
 >
 >  * exit with an error if user supplied nodata= is outside of range for
 the given type.
 Glynn suggested interpretation: if (nodata != (double) (GDAL datatype)
 nodata) -> warning, nodata = (double) (GDAL datatype) nodata, proceed. (I
 hope I got that right for a change...) Result would be a valid raster,
 granted that subsequent checks are passed.
 >
 >  * ?? can we wait to tell gdal the nodata value (for the metatag) until
 after we have processed all rows?? if so we can just not set one with GDAL
 at all if we didn't come across any NULL cells in the write loop.
 We have waited all the time :-) That was always done in the C version and
 AFAICT nobody wants to change that.
 > We must decide what to use if we do come across one before we start the
 loop (see previous point) that would allow for a 0-255 GRASS CELL map with
 no NULLs to preserve all data, while allowing a CELL map with 0-255+NULL,
 type=UInt8, and the user specified a nodata= value in the range of 0-255
 to correctly follow the user's wishes.
 0-255+NULL, type=UInt8 causes data loss unless the user found a free
 unused slot within 0-255. IMHO, big warning if not error on data loss i.e.
 when nodata value encountered *and* NULLs present.

 I'll try to summarize the suggestions so far into a description of the new
 design for r.out.gdal, but I need a bit more time to read again through
 all contributions.

 Markus M

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


More information about the grass-dev mailing list