[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:  major   |   Milestone:  6.5.0                    
 Component:  Raster  |     Version:  svn-trunk                
Resolution:          |    Keywords:  r.out.gdal, tiff         
  Platform:  All     |         Cpu:  All                      
---------------------+------------------------------------------------------
Comment (by mmetz):

 Replying to [comment:52 hamish]:
 > Replying to [comment:49 mmetz]:
 > >    - GDAL signed int types: (...)

 > >    - GDAL unsigned int types: (...)
 >
 > it all seems a bit complicated, but ok.
 that's my understanding of the discussion with Glynn:
 [http://lists.osgeo.org/pipermail/grass-dev/2009-April/043464.html
 http://lists.osgeo.org/pipermail/grass-dev/2009-April/043464.html] and
 following.

 >
 > >  * before actual export, in case of custom nodata make sure the
 metadata nodata value and the raster nodata value are identical
 >
 > why? if custom nodata then export NULLs in the map to be the custom
 value and clobber any real data which had that value.
 > (perhaps I don't understand something here..)

 What I meant here was to make sure that the value that replaces NULL cells
 is identical to the metadata nodata value, otherwise nodata info gets
 lost. Clobbering real data with the nodata value is a different issue
 (that is taken care of).
 >
 > >    - if (nodata != (double) (GDAL datatype) nodata) -> warning and
 nodata = (double) (GDAL datatype) nodata
 >
 > if the user asks to use a certain nodata value and it is illegal for the
 data type then exit with an error, probably giving the available range in
 the error message. don't automagically correct it for them and continue
 (ie override their expressed wishes). It is a recipe for pain.

 ok, will change it. The first warning will tell what would happen to the
 nodata value, the second warning will report the selected GDAL datatype
 and its range, then raster export aborts. E.g.
 {{{
 WARNING: Mismatch between metadata nodata value and actual nodata value in
          exported raster: specified nodata value -9999.000000 gets
          converted to 241 by selected GDAL datatype.
 WARNING: GDAL datatype: Byte, valid range: 0 - 255
 ERROR: Raster export aborted.
 }}}
 BTW, it would be the selected GDAL datatype that overrides the user's
 wishes by type casting, not r.out.gdal.
 >
 > > Hamish, what exactly should this compatibility flag do? There
 > > is all sorts of software with all sorts of different
 > > deficiencies out there...
 >
 > umm, I forget what that was in reference to. ??minimalistic metadata
 output??

 There are already GeoTIFF compatibility hints in the manual, I would like
 to leave it like that.
 >
 > is everyone happy with the colortable export stuff now?
 > (my only issue with it is that if you pass the no-metadata create
 > option to GDAL, GRASS adds its stuff anyway)
 >
 Please note that nothing much changed there, colortable export can be
 disabled from 6.4 onwards. AFAIKT, that GRASS stuff is currently only used
 by QGIS, not even GRASS i.e. r.in.gdal or r.external use that information.
 >
 > this is a substantial last-minute change to a core module

 Unfortunately, but I would really like to get this ticket solved, please
 test!

 Markus M

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