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

 Replying to [comment:24 mmetz]:

 Hamish:
 > > 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.

 Replying to [comment:24 mmetz]:
 > This is the same like r.null setnull=nodata. Is this raster
 > editing?

 It is not the same because the raster cells are intact. You can "cleanse"
 away the metadata with {{{ tifftopnm file.gtiff | pnmtotiff > file.tif }}}
 and the metadata "nodata" tag is gone and your data is as it once was.


 > 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?

 thanks, done.


 > > -c flag added
 > Potentially misleading description: "Do not export long
 > colortable"? A user might wonder whether short colortables
 > are always exported?

 they'd be right. Short tables are still written.

  - Long: Byte and UInt16 maps write out a RGB value for each 256/66536
 possible int.

  - Short: These are the COLOR_TABLE_RULE_RGB_n metadata created by
 GRASS by copying over the contents of the colr/ file. They are typically
 4-5 lines long and work by ranges not per-possibility.

 I agree it is unpleasant if the user specifies {{{
 createopt="PROFILE=BASELINE" }}} for a bare-bones GeoTIFF and GRASS still
 writes out COLOR_TABLE_RULE metadata anyway.

 But typically the user will use that flag to avoid the list of 66536
 RGB values, not the list of 5 rules.


 > > 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.


 thanks for the refs., most useful

 I notice gdal's gcore/rasterio.cpp has its Int32 min at -2147483647 not
 -2147483648. That might make a diff if we wanted to use the min as the
 default nodata value.  ?? (or is that < not <= so ok?)


 > There is a cplusplus style comment in local_proto.h. OK, it's
 > in a c style comment, but that could be uncommented soon.

 just a temporary thing, while we sort this out, and less dangerous
 than a c-comment nested in another c-comment.

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

 I've copied your comment into my local copy of main.c.


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

 right.

 I'm no expert on when it is best to terminate a big number with "UL", "L",
 ".0", "f" or use the likes of "(double)(unsigned int)0xFFFFFFFFu"


 I notice with the current code that if I make a UInt16 map and don't
 specify a nodata value the G_message reports it defaults to -32768, but
 this may just be %d speaking, not the variable.


 Hamish

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