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

 I have just applied in SVN (r34015,6) some updates which should help. I
 took a lot of your suggestions, but not all.

 {{{
 cleanups in pursuit of bug #73 in collaboration with Markus Metz
 * rename & move export band to its own file
 * flag to disable writing long (UInt16) color tables
 * add type length defines (needs completion & review)
 * add some TODO comments where future work is required
 * help page cleanups
 }}}


 Replying to [comment:21 mmetz]:
 > As a summary, I see three issues of controversy:
 >
 > 1. should implicit raster editing be allowed, i.e. give and
 > respect nodata in the absence of NULL cells,

 AFAIK this is just the setting of a metadata tag (or not), so not
 really editing the raster data at all. As such I don't mind if
 the user decides to set it when it would otherwise not be.
 There's no processing involved.


 > give out of range nodata value (NULL cells are replaced with min
 > or max of data type,
 > r.null null=nodataval gets "secretly" converted by gdal to
 > r.null null=datatype_min or r.null null=datatype_max),

 It should exit with an error if the user-supplied nodata= value is out of
 range for the specified data type. When the module comes across a NULL
 cell it needs to know what to do with it.


 > respect the current region resolution

 note added to the help page that g.region is boss.


 > 2. should the user be allowed to do strange things like giving
 > out of range nodata values or specify a data type not covering
 > the range of cell values

 No, G_fatal_error() for both; the module needs to know what to write out
 for the cell and shouldn't just make stuff up.


 > 3. should r.out.gdal consider flaws in (not only) GeoTIFF support
 > of other applications, e.g. give an option to export the
 > colortable and don't do it by default, or should r.out.gdal
 > (stubbornly?) stick to the specs

 -c flag added to turn off (long) color tables for Byte and UInt16. I think
 it is worth checking if the GDAL code could be changed to only write out
 as much of the table as needed, not up to 65535-max empty rules.

 AFAIAC, upon request we should offer the user the chance to export a bare-
 bones BASELINE GeoTIFF (we have r.out.tiff for that), but by default we
 should keep the GeoTIFF as self-documenting and metadata up'd as
 possible-- as that is what makes the data valuable and viable in the long
 term and support files are quickly lost.


 I'd note that INTERLEAVE=PIXEL is only the default for the very latest
 versions of GDAL released in the last months. On my system it still
 defaults to BAND.


 The type range limit testing stuff is still TODO. (both data max/min and
 nodata=)


 Hamish

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