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

 [keep it in the bug report please!]

 > > Comment (by neteler):
 > >  what about integrating your fixes from
 > >
 >
 http://markus.metz.giswork.googlepages.com/r.out.gdal.conservative.tar.gz
 > >  ?

 Markus Metz wrote:
 > Sure, no objections from my side, I'm using this version only. But
 > r.out.gdal is a very important module of GRASS and maybe some more
 > testing is required. Also, the new features may not find approval by
 > all,

 yep


 > e.g. I've put in rather restrictive NULL cell handling: the user
 > has to specify a nodata value that falls within the range of the
 > selected datatype (Byte, UInt16, Int16, ...), a nodata value is no
 > longer chosen automatically as in the original version. If a nodata
 > value is not given, but NULL cells are present, r.out.gdal aborts with
 > an error message.

 When possible, I think it better to have a sensible default then give the
 user the option to override. That's what we have in the existing code.
 NULL=max possible is a common usage, so not bad for a default. Your change
 is too conservative for my vote, and generally I don't like banning users
 from doing things just because my imagination is limited as to why they
 would want to do something funny. If they really want to set nodata=
 out of bounds, and explicitly give a nodata= value specifying that, I'd
 say let them (with a warning in case they didn't realize, of course).


 > My version also no longer uses the current region resolution, instead
 > the current region extends are aligned to the resolution of the raster
 > to be exported to avoid any implicit resampling.

 Nope. I see your reasons, but this is in violation of GRASS's standard
 raster semantics, and one of the reasons for the r.out.gdal.sh ->
 r.out.gdal (.c) was to "fix" this. (sort of)

 Maybe it makes the GRASS<->R stats people happier?, but shouldn't be the
 default method, and I doubt offered at all. I would think this better
 handled with a note in the help page with a suggestion to use
 "g.region res=.. -a" if they want that.


 > And the colortable is only exported on request, and then with a warning
 > message.

 IMO that should be automatic with Byte maps (255 levels), perhaps needed
 with UInt16 maps (with 65535 levels) it should be optional...


 > If these changes are ok with you then integrate the changes, otherwise
 > maybe only some, but not all changes could be integrated. More
 > discussion needed on how to change/improve r.out.gdal?

 as above. I need to reread the (long) bug history now, but fwiw I just
 fixed
 yesterday a bug in SVN where nodata= value given by the user was only
 used if type= was also given, otherwise the auto-type determination reset
 it.

 I also noticed that QGIS 0.8.1 (old, but latest debianGIS package for
 Etch/stable) has a bug where the first palette entry always is black,
 even when the GeoTIFF says otherwise. (loads/views fine in other software)
 In my case it was a 7-color palette with cat 0 being white in the color
 table.


 Hamish

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