#73: r.out.gdal tiff output does not work --------------------------+------------------------------------------------- Reporter: helena | Owner: grass-dev@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>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev