[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:25 hamish]:
 > Replying to [comment:24 mmetz]:
 >
 >  - 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.
 >
 Yes, but for GeoTIFF these short colortables are not colortables in the
 GeoTIFF sense, but custom metadata. The equivalent in gdal_translate would
 be gdal_translate -mo "COLOR_TABLE_RULE_0=..." Qgis reads these rules
 instead of the colortable if rules are present, but qgis is the only
 application doing so. Grass doesn't do that itself, i.e. it exports
 COLOR_TABLE_RULE, but ignores these entries on import (enhancement for
 r.in.gdal?).
 >
 > 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?)
 >
 Hmm, interesting. limits.h defines INT_MAX as 2147483647 and INT_MIN as
 -INTMAX - 1
 Also true: USHRT_MAX (UInt16 max) = SHRT_MAX - SHRT_MIN (Int16 max and
 min)

 UINT_MAX (UInt32 max) = INT_MAX - INT_MIN (Int32 max and min) or INT_MAX +
 INT_MAX + 1

 But if gdal decides Int32 min is -2147483647, then it be.
 >
 > 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"
 >
 Not that I am, I would suggest using the same like gdal or limits.h
 (UInt32 max = 4294967295U)

 Float23 and Float 64 limits: on my system (Linux 64 with gcc 4.1.2) there
 are FLT_MAX and DBL_MAX defined and can be used for TYPE_FLOAT32_MIN/MAX
 and TYPE_FLOAT64_MIN/MAX. Are FLT_MAX and DBL_MAX defined on other systems
 (in float.h) too? This would be more accurate than the current
 approximation in local_proto.h.
 >
 > 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.
 >
 If a nodata value is chosen automatically in the presence of NULL cells
 and absence of user-specified nodata option, this must be correct and
 consistent, i.e. always max or always min of the datatype which is not the
 case right now. Should be corrected when the range testing is implemented.

 Markus

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