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

[GRASS GIS]

#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 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(). tricks like
 "{{{if(val<type_min) val=(type_min||NULL);}}}" are evil. the user can use
 r.mapcalc or r.reclass if they really want that. better we refuse to
 honour broken requests.


  * exit with an error if user supplied nodata= is outside of range for the
 given type. if no value is given use the following rules:
   - signed int types: minimum in range
   - unsigned int types: maximum in range
   - all floating point: IEEE's NaN


  * ?? 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 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. If we do that then we don't need a
 -f flag (which I'd rather we didn't have).


  * drop the complex types in grass7. we can easily re-add them if the
 next-gen raster format can store multiband i.fft output maps or whatever.
 has anyone ever once come across in the wild a map using these types? or
 are they on the list just because they can be?


  * if writing a message saying "NULL cells were found in the map but the
 nodata option was not specified. Using a default value of xxxxx." beware
 that what is printed by the G_warning() or G_message() text may not be the
 internally stored value, as it has been passed through printf %{}. so
 don't trust your own eyes looking at that output + we should carefully
 test that. I guess it means supplying a different %ld %u or whatever for
 each individual type, but so be it.



 [crossing-threads]
  * 999 as NULL is dangerous, it can easily be an elevation value. -9999 is
 bad too, you just hit it less often (& data isn't always elevation). But
 even though you hit it less often doesn't mean it's still not going to
 bite you one day, so it's a bug. bugs which don't happen all the time
 could be considered more evil, because you have come to trust the program
 and are not expecting them. but alas, probably for r.out.arc we are stuck
 with whatever values Arc will take for input.



 Hamish

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