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

GRASS GIS trac at osgeo.org
Sun Oct 26 03:35:58 EDT 2008


#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:20 hamish]:
 >
 >  - if a Byte map has data 0-255 *and* NULL, it seems reasonable to me to
 default to nodata=255 + issue a warning. *But* if a map has 0-255 with
 *no* NULLs, nodata should not be set* to 255, as this would lead to a loss
 of fidelity. (improper removal of all cells with cat=255 for no gain)
 >
 This is the current implementation in 6.4 (unless modified recently) and
 my version.
 >
 > [*] ie should not be set, unless the user requests it explicitly with
 the nodata= opt
 >
 Thicker: I disagree, this is raster editing which should be done before
 exporting, identical to r.null setnull=val.
 >
 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, 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), respect the current region resolution

 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

 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

 > sorry to be so thick,
 Being thick is necessary, r.out.gdal is important for data exchange with
 people using other applications

 Markus

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


More information about the grass-dev mailing list