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

 Replying to [comment:23 hamish]:
 >
 > Replying to [comment:21 mmetz]:
 > >
 > > 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.
 >
 This is the same like r.null setnull=nodata. Is this raster editing?
 >
 > note added to the help page that g.region is boss.
 >
 Little word missing? "... if you need to realign the region settings
 '''to''' the original map's before export."

 Also maybe remove comments on GDAL datatypes just below the ranges of
 datatypes, because they are not really necessary?
 >
 > -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.
 >
 Potentially misleading description: "Do not export long colortable"? A
 user might wonder whether short colortables are always exported?
 >
 > The type range limit testing stuff is still TODO. (both data max/min and
 nodata=)
 >
 The min/max values for all integer types are identical to gdal and AFAIK
 universally valid. See min/max values in gdal-1.5.2 gcore/rasterio.cpp. As
 I understand, min/max values for float32 are indirectly determined in gdal
 using typecast from double to float. The min/max values for float32 and
 float64 as suggested by me correspond to IEE 754 to my best knowledge.
 Values farthest away from zero have all bits in the mantissa set and all
 but the last in the exponent which is equal to (1 - 1/2^24^) * 2^128^ for
 float32 and (1 - 1/2^53^) * 2^1024^ for float64, taken from
 http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF.
 >
 There is a cplusplus style comment in local_proto.h. OK, it's in a c style
 comment, but that could be uncommented soon.

 In the TODO line 386 rather use GDALGetDataTypeName(datatype) than
 type->answer because type is not required and datatype is known by then.

 Even looking very hard I can't find more to criticize;-)

 I guess once the type ranges are confirmed the TODOs can be done.

 Markus

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