GRASS 6.3 Feature Plan: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
(link to Image processing)
(move to trac)
 
(94 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{Historic}}
{{MoveToTrac}}
''Move to Trac and note that it is histirical page. Link GRASS 7 or some general one.''
'''''The info here is really old. See the [https://trac.osgeo.org/grass/wiki Trac development wiki] and [https://trac.osgeo.org/grass/roadmap roadmap] for the latest information.'''''
== GRASS 6.3.x feature plan ==
== GRASS 6.3.x feature plan ==
=== About feature plan ===
=== About feature plan ===
Line 4: Line 11:
To make GRASS releases more often and more predictable, here is GRASS next releases feature plan. This feature plan has to be filled by developers working on GRASS 6.3.
To make GRASS releases more often and more predictable, here is GRASS next releases feature plan. This feature plan has to be filled by developers working on GRASS 6.3.


Basic principles:
=== TODO GRASS 6.3.0 ===
# Add a short feature description, bug No., etc. what You want to see and what '''YOU will implement or fix''' in upcoming GRASS 6.3 to ''[[#TODO]]'' list. Sign it using four tildes <nowiki>~~~~</nowiki>!
There is the release branch for 6.3.x, see details at [http://grass.osgeo.org/devel/cvstags.php tags and branches]. A release branch is considered as "frozen", only bugfixes can be done.
# If You work on it, and You think it will make to next release, '''MOVE''' to  ''[[#In progress]]'' section.
 
# When You finish and commit Your work, '''MOVE''' it to ''[[#Finished]]'' section.
==== RC1 ====
 
''released 24 Oct 2007''
 
* see http://trac.osgeo.org/grass/wiki/Release/6.3.0RC1-News
 
==== RC2 ====
 
''Released 20 Nov 2007''
 
* see http://trac.osgeo.org/grass/wiki/Release/6.3.0RC2-News
 
==== RC3 ====
 
''released 30 Nov 2007''
 
* see http://trac.osgeo.org/grass/wiki/Release/6.3.0RC3-News
 
==== RC4 ====
''released 9 Jan 2008''
 
* see http://trac.osgeo.org/grass/wiki/Release/6.3.0RC4
 
==== RC5 ====
''released 19 Feb 2008''
 
* see http://trac.osgeo.org/grass/wiki/Release/6.3.0RC5
* Added in wxGUI, g.gui
 
==== RC6 ====
''released 21 Mar 2008''
 
* see http://trac.osgeo.org/grass/wiki/Release/6.3.0RC6
 
==== 6.3.0 final ====
 
* released 23 Apr 2008
 
===== Must do =====
 
====== test: ======
 
* [&#10003;] r.out.gdal NoData
* [&#10003;] d.vect render=c
* [&#10003;] gis.m about->system
 
====== fix: ======


'''''Warning''''' After [[GRASS_6.3_release_schedule|freeze start]], You will not be able to commit any new features till freeze end. Only bugfixes and commits related to items listed in ''In progress'' section.
* [http://trac.osgeo.org/grass/milestone/6.3.0 Trac milestone status]
* Any [http://trac.osgeo.org/grass/report/3 open bugs] which are blockers for 6.3.0 should be flagged as such in the bug report.
* Look over old Gforge and RT bug trackers. Refile in trac as blockers if they are release-critical and close old reports with a link to the new one. Copy over all past discussion so it has  context and history.


=== TODO ===


* Implement [http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/doc/vector/TODO vector improvements] as suggested by Radim
====== tasks: ======
* Integrate [http://mpa.itc.it/markus/i_points_auto/ i.points.auto] (merge into i.vpoints) - see also [[Image processing]]
 
* Make sqlite the default DB?
* <strike>Change <tt>.grc</tt> extension for WxGUI as incompatible with Tcl/Tk <tt>.grc</tt> files. </strike>
* Create GRASS Addons SVN repository and really use GEM
: [http://trac.osgeo.org/grass/ticket/77 trac #77]
 
* <strike>Update release announcement and press release blurb in Web-SVN: [http://trac.osgeo.org/grass/browser/grass-web/trunk/announces/announce_grass630.html] ([http://grass.osgeo.org/announces/announce_grass630.html preview])</strike>
: AND/OR http://trac.osgeo.org/grass/wiki/Release/6.3.0RC5-News
: --HB, 4 March 2008: IMO Final 6.3.0 announcement should be posted on the website. It's cleaner. Trac Wiki is fine for the RC announcements and working on the annoucement but it seems to me tp host the final release announcement there is like greeting your new customers in the corner of your workshop, it's unprofessional.
 
===== Stalled =====
 
* v.what.vect improvements ([http://trac.osgeo.org/grass/ticket/85 see trac patch])
:  -- HB 24 Oct 2007: waiting for a real world example of when this would be useful.
 
* use GEM for ''GRASS Addons SVN'' - status unclear
** gis.m menu part of this done (Michael)
 
* g.region vect=map -a issues [http://wald.intevation.org/tracker/index.php?func=detail&aid=489&group_id=21&atid=204 #489]
: -- HB 24 Oct 2007: Is this really release critical?
: -- MS 26 Oct 2007: It was, until there was a "one row-off" bug in "g.region vect= res= -a". Fixed by Glynn in last days. A remaining issue, less important, is that "g.region vect= res= -a" needs to be run twice if the initial and target region resolution differ. This is not normal nor desired, but Glynn says it's been this way for years now. I confirm it applies to 6.2 at least too. A must-fix for GRASS 7, probably not to be fixed for legacy reasons in 6.2, and to be decided in regard to 6.3. As to me, I'm for fixing it in 6.3.
 
* <strike>r.in.xyz improvements ([http://wald.intevation.org/tracker/index.php?func=detail&aid=450&group_id=21&atid=205 see GForge patch])</strike>
:  -- HB 14 Nov 2007: patch committed to HEAD; requires testing so not for 6.3.0
 
* v.sample improvements ([http://wald.intevation.org/tracker/index.php?func=detail&aid=513&group_id=21&atid=205 see GForge patch])
:  -- HB 24 Oct 2007: not ready. needs fixing for NULLs.
 
===== Wishlist =====
 
* modify Makefile system to support translated HTML pages. Store translated HTML files in centralized directory with locale specific subdirs, file name is module name.
 
* Implement [http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/doc/vector/TODO vector improvements] as suggested by Radim
 
* Integrate [http://trac.osgeo.org/grass/browser/grass-addons/imagery/i.points.auto i.points.auto] (merge into i.vpoints) - see also [[Image processing]] - note that A Scianna/Palermo has modernized version
 
* Make sqlite the default DB? <- needs more testing, done in GRASS 7.
 
* drop d.m display manager (as now almost unmaintained; there is gis.m and/or a python based GUI)
* drop d.m display manager (as now almost unmaintained; there is gis.m and/or a python based GUI)
* raster maps: implement SQL based time series support
: Some people still prefer it (see posts to grass-dev) and I will fix bugs in it, but not enhance/add new modules to it without good reason. So I don't see the need to drop it before the WxPython version is ready. It's not hurting us any keeping it. --Hamish
* modify Makefile system to support translated HTML pages. Store translated HTML files in centralized directory with locale specific subdirs, file name is module name.
:: We should keep plain d.mon interface but why keep d.m, if gis.m has become really good? Probably we should clearly state, that d.m is UNMAINTAINED and OBSOLETE? [[User:MarisN|MarisN]] 08:24, 16 February 2007 (CET)
:: --HB: ok, d.m man page updated.
::: deleted in GRASS 7
 
* raster maps: implement SQL based [[Time series in GRASS|time series support]] (working code from Soeren in GRASS Addons SVN)
 
* Clean up Makefile system to support extension compilation and installation outside the GRASS installation and without the full GRASS source.  Much like what GEM does, but without needing the module source setup and not limited to installing within the GRASS installation dir.  This could also simplify GEM on the compilation side.  See also general [[Extension development]].
 
====== Updates to vector querying ======
 
* v.select (query using a vector map):
** add flags -p and -g for text output instead of creating a new map. It would report which map(s) and feature(s)/cat(s) meet the query criteria.
** allow multiple maps to be selected. This would directly address Eric's question. If the output is a map, it would be the equivalent of v.patch on all queried vector elements.
** add operators "contains" and "adjacent". Contains=all vector features whose nodes are completely inside a polygon (or inside or touching the boundary). Adjacent=all vector features who share a node/point or line/boundary with the selecting feature. Because GRASS is topologically correct, adjacency information is readily available.<BR>--HB: op="not" too please.
** maybe change option names from ainput and binput to selector and selected or queried. This would have to wait until GRASS 7, of course. I find ainput and binput not very clear where used in other vector operations either (maybe I'm just dense).
: --HB: input order counts, so named map options have a function.
 
* v.what (query using coordinates):
** add flags -p and -g for current behavior (-pg could be the default if we wanted to do this before GRASS 7)
** add "output=" option to allow v.what to create a new map from the results of its query, like v.select does
** allow multiple maps for input, as with the suggestion for v.select
** allow coordinates to be read optionally as a line or area boundary (-l or -a?) instead of only as individual points.
** add operators overlap, contains, adjacent.(This also would make possible interactive vector selection with a mouse drawn box or polygon from the GUI)
 
*In other words, have v.select and v.what work the same except that v.select uses a vector map for querying and v.what uses a set of coordinate points.
 
* v.overlay (boolean combination of maps):
** drop the ainput and binput. Replace with just input.<BR>--HB: careful, order of maps can matter.
** allow multiple maps to be entered into input, not just 2
** deprecate v.patch because v.overlay with the OR operator replaces it. (If we wanted to do this before GRASS 7, we'd have to create a new module, maybe named v.combine or something like that because this changes the default behavior of v.overlay).
: --HB: does it completely? I could be totally wrong, but my thought was that v.patch is very fast and does not attempt to clean (overlay) features, just lump them together in the file. Certainly for most tasks v.overlay should be the suggested route in the documentation.


=== In progress ===
=== In progress ===
* native MS Windows port
 
* complete and further stabilize the native [[WinGRASS Current Status|MS Windows port]]
: (seems to be in a good shape now)
 
* Database connection for v.out.vtk: --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
* Database connection for v.out.vtk: --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
** single column support for numerical data (int, float, double)
** single column support for numerical data (int, float, double)
** GRASSRGB column support
** GRASSRGB column support (done for ps.map)
** multiple column support for vector data
** multiple column support for vector data
* rewrite most of the g3d modules to fulfil the grass function naming convention --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
* rewrite most of the g3d modules to fulfill the grass function naming convention --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
* adding further (organized) keywords to every grass command and script [http://grass.itc.it/pipermail/grass-dev/2006-August/025164.html] and [http://grass.itc.it/pipermail/grass-dev/2006-August/025190.html]:
* adding further (organized) keywords to every grass command and script [http://grass.itc.it/pipermail/grass-dev/2006-August/025164.html] and [http://grass.itc.it/pipermail/grass-dev/2006-August/025190.html]:
** display commands
** display commands
Line 40: Line 160:
** raster3D commands
** raster3D commands
** vector commands
** vector commands
* continue with wxpython prototype
* write (Python based?) GUI wizard to create new locations (MN and terrestris.de)
* implement Python-SWIG interface
* less verbose commands


=== Finished ===
* continue with [[WxPython-based GUI for GRASS]]
* All fixes as done for [[GRASS 6.2 Feature Plan|GRASS 6.2.x]]
 
* rewrite of r.to.rast3, r.to.rast3elev, v.out.vtk and r.out.vtk to fulfil the grass function naming convention --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
* <strike>write (Python based?) GUI wizard to create new locations</strike>
* basic keyword support added [[User:Neteler|Neteler]] 15:52, 19 August 2006 (CEST)
: (done by Jachym and Michael, see [[WxPython-based GUI for GRASS]])
** This is done. AFAICT it works really well (IIDSSM). It will create locations using EPSG, georeferenced files, custom selection of projection parameters, and xy locations. You can also set default extents (DEFAULT_WIND).
 
* improve Python-SWIG interface
* less verbose commands (work in progress)
* BLAS/LAPACK updates (Brad)
* Provide interactive environment on GRASS startup [http://wald.intevation.org/tracker/index.php?func=detail&aid=521&group_id=21&atid=205 #521]
 
=== Complete ===
 
* <strike>gis.m->Help->About system doesn't work (launches another gis.m instance)</strike>
: [http://trac.osgeo.org/grass/ticket/12 trac ticket #12]
 
* <strike>change default '<tt>d.vect render=</tt>' mode from l to (?)</strike>
: --HB 28 Nov 2007: I hope to provide more test results soon
: --HB 1 Dec 2007: "L" is still problematic, new tests posted to grass-dev
: --HB 21 Jan 2008: Changed to "c". see [http://thread.gmane.org/gmane.comp.gis.grass.devel/22984/focus=23839] [http://lists.osgeo.org/pipermail/grass-dev/2008-January/034922.html]
 
* <strike>r.out.gdal sets NoData wrong [http://wald.intevation.org/tracker/index.php?func=detail&aid=405&group_id=21&atid=204 #405]</strike>
: -- HB 24 Oct 2007: Is this really release critical? - need to find Frank's email on the subject and post it to the bug report. At least for a Byte map the no data value must live somewhere in 0-255, there is no IEEE nan for Ints.
: -- MS 26 Oct 2007: It is critical. It's a data corruption issue.
: -- HB 29 Oct 2007: IMO we just document that GDAL works like that. I don't see another good solution. I still need to look up Frank's answer..
: -- MS 19 Nov 2007: This is not acceptable. It's a data corruption and a regression compared to script version of r.out.gdal. Suggestion: if we have to choose between 2 bad things: a valid value replaced by null by force, thus corrupting the output (like in C r.out.gdal), and setting null to eg. 256 for a a 0-255 raster to avoid that (like in shell-script r.out.gdal), I prefer the latter. This is less harmfull.
: -- HB 28 Nov 2007: At least for a Byte map, there is no 256! 1byte=8bits, giving you 2^8 data value possibilities and no more. Byte maps do not support NaN either. As you suggest I will compare script & C version output before commenting further.
: -- MS 17 Dec 2007: Hamish, regarding "for a Byte map, there is no 256!" - I know. But that's what gdal_translate does (see the [http://www.gdal.org/classGDALRasterBand.html#c6f081d253dee55c372e54cfdd8f05a6 link you once mentioned to me]) to avoid data corruption which takes place in C r.out.gdal. This is not "good", but at least data corruption is avoided, which would be "horrible".
: -- MS 04 Jan 2008: [http://wald.intevation.org/tracker/download.php/21/204/405/255/r-out-gdal-nodata.diff Martin's patch] fixed the bug for me.
: -- HB 21 Jan 2008: Ok, glad for the fix.


=== User Wishes ===


''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[User:MarisN|MarisN]] 12:00, 4 August 2006 (CEST)
* here are some examples to get inspired (apparently that's already possible):
** [http://skagit.meas.ncsu.edu/~helena/publwork/grasskey02/grass02talk10.html dynamic surfaces and volumes]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/cenntenial/water01dsmall.gif some water]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/balsam/fanimwalk.gif particles]
** [http://www.fhpv.unipo.sk/kagerr/pracovnici/hofierka/pv_results.html solar radiation and energy]
* Convince the users to use ParaView [http://www.paraview.org] for sophisticated animations --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
**(Add support for Paraview in GDAL/OGR or add GDAL/OGR support in ParaView to read directly data from GRASS) see diskussion


[[Category:Development]]
[[Category:Development]]
[[Category:Release Roadmap]]
[[Category:Release Roadmap]]

Latest revision as of 02:52, 29 January 2014

Move to Trac and note that it is histirical page. Link GRASS 7 or some general one.

The info here is really old. See the Trac development wiki and roadmap for the latest information.

GRASS 6.3.x feature plan

About feature plan

To make GRASS releases more often and more predictable, here is GRASS next releases feature plan. This feature plan has to be filled by developers working on GRASS 6.3.

TODO GRASS 6.3.0

There is the release branch for 6.3.x, see details at tags and branches. A release branch is considered as "frozen", only bugfixes can be done.

RC1

released 24 Oct 2007

RC2

Released 20 Nov 2007

RC3

released 30 Nov 2007

RC4

released 9 Jan 2008

RC5

released 19 Feb 2008

RC6

released 21 Mar 2008

6.3.0 final

  • released 23 Apr 2008
Must do
test:
  • [✓] r.out.gdal NoData
  • [✓] d.vect render=c
  • [✓] gis.m about->system
fix:
  • Trac milestone status
  • Any open bugs which are blockers for 6.3.0 should be flagged as such in the bug report.
  • Look over old Gforge and RT bug trackers. Refile in trac as blockers if they are release-critical and close old reports with a link to the new one. Copy over all past discussion so it has context and history.


tasks:
  • Change .grc extension for WxGUI as incompatible with Tcl/Tk .grc files.
trac #77
  • Update release announcement and press release blurb in Web-SVN: [1] (preview)
AND/OR http://trac.osgeo.org/grass/wiki/Release/6.3.0RC5-News
--HB, 4 March 2008: IMO Final 6.3.0 announcement should be posted on the website. It's cleaner. Trac Wiki is fine for the RC announcements and working on the annoucement but it seems to me tp host the final release announcement there is like greeting your new customers in the corner of your workshop, it's unprofessional.
Stalled
-- HB 24 Oct 2007: waiting for a real world example of when this would be useful.
  • use GEM for GRASS Addons SVN - status unclear
    • gis.m menu part of this done (Michael)
  • g.region vect=map -a issues #489
-- HB 24 Oct 2007: Is this really release critical?
-- MS 26 Oct 2007: It was, until there was a "one row-off" bug in "g.region vect= res= -a". Fixed by Glynn in last days. A remaining issue, less important, is that "g.region vect= res= -a" needs to be run twice if the initial and target region resolution differ. This is not normal nor desired, but Glynn says it's been this way for years now. I confirm it applies to 6.2 at least too. A must-fix for GRASS 7, probably not to be fixed for legacy reasons in 6.2, and to be decided in regard to 6.3. As to me, I'm for fixing it in 6.3.
-- HB 14 Nov 2007: patch committed to HEAD; requires testing so not for 6.3.0
-- HB 24 Oct 2007: not ready. needs fixing for NULLs.
Wishlist
  • modify Makefile system to support translated HTML pages. Store translated HTML files in centralized directory with locale specific subdirs, file name is module name.
  • Make sqlite the default DB? <- needs more testing, done in GRASS 7.
  • drop d.m display manager (as now almost unmaintained; there is gis.m and/or a python based GUI)
Some people still prefer it (see posts to grass-dev) and I will fix bugs in it, but not enhance/add new modules to it without good reason. So I don't see the need to drop it before the WxPython version is ready. It's not hurting us any keeping it. --Hamish
We should keep plain d.mon interface but why keep d.m, if gis.m has become really good? Probably we should clearly state, that d.m is UNMAINTAINED and OBSOLETE? MarisN 08:24, 16 February 2007 (CET)
--HB: ok, d.m man page updated.
deleted in GRASS 7
  • raster maps: implement SQL based time series support (working code from Soeren in GRASS Addons SVN)
  • Clean up Makefile system to support extension compilation and installation outside the GRASS installation and without the full GRASS source. Much like what GEM does, but without needing the module source setup and not limited to installing within the GRASS installation dir. This could also simplify GEM on the compilation side. See also general Extension development.
Updates to vector querying
  • v.select (query using a vector map):
    • add flags -p and -g for text output instead of creating a new map. It would report which map(s) and feature(s)/cat(s) meet the query criteria.
    • allow multiple maps to be selected. This would directly address Eric's question. If the output is a map, it would be the equivalent of v.patch on all queried vector elements.
    • add operators "contains" and "adjacent". Contains=all vector features whose nodes are completely inside a polygon (or inside or touching the boundary). Adjacent=all vector features who share a node/point or line/boundary with the selecting feature. Because GRASS is topologically correct, adjacency information is readily available.
      --HB: op="not" too please.
    • maybe change option names from ainput and binput to selector and selected or queried. This would have to wait until GRASS 7, of course. I find ainput and binput not very clear where used in other vector operations either (maybe I'm just dense).
--HB: input order counts, so named map options have a function.
  • v.what (query using coordinates):
    • add flags -p and -g for current behavior (-pg could be the default if we wanted to do this before GRASS 7)
    • add "output=" option to allow v.what to create a new map from the results of its query, like v.select does
    • allow multiple maps for input, as with the suggestion for v.select
    • allow coordinates to be read optionally as a line or area boundary (-l or -a?) instead of only as individual points.
    • add operators overlap, contains, adjacent.(This also would make possible interactive vector selection with a mouse drawn box or polygon from the GUI)
  • In other words, have v.select and v.what work the same except that v.select uses a vector map for querying and v.what uses a set of coordinate points.
  • v.overlay (boolean combination of maps):
    • drop the ainput and binput. Replace with just input.
      --HB: careful, order of maps can matter.
    • allow multiple maps to be entered into input, not just 2
    • deprecate v.patch because v.overlay with the OR operator replaces it. (If we wanted to do this before GRASS 7, we'd have to create a new module, maybe named v.combine or something like that because this changes the default behavior of v.overlay).
--HB: does it completely? I could be totally wrong, but my thought was that v.patch is very fast and does not attempt to clean (overlay) features, just lump them together in the file. Certainly for most tasks v.overlay should be the suggested route in the documentation.

In progress

(seems to be in a good shape now)
  • Database connection for v.out.vtk: --huhabla 20:47, 14 August 2006 (CEST)
    • single column support for numerical data (int, float, double)
    • GRASSRGB column support (done for ps.map)
    • multiple column support for vector data
  • rewrite most of the g3d modules to fulfill the grass function naming convention --huhabla 20:47, 14 August 2006 (CEST)
  • adding further (organized) keywords to every grass command and script [2] and [3]:
    • display commands
    • database commands
    • general commands
    • imagery commands
    • misc commands
    • paint commands
    • photo commands
    • postscript commands
    • raster commands
    • raster3D commands
    • vector commands
  • write (Python based?) GUI wizard to create new locations
(done by Jachym and Michael, see WxPython-based GUI for GRASS)
    • This is done. AFAICT it works really well (IIDSSM). It will create locations using EPSG, georeferenced files, custom selection of projection parameters, and xy locations. You can also set default extents (DEFAULT_WIND).
  • improve Python-SWIG interface
  • less verbose commands (work in progress)
  • BLAS/LAPACK updates (Brad)
  • Provide interactive environment on GRASS startup #521

Complete

  • gis.m->Help->About system doesn't work (launches another gis.m instance)
trac ticket #12
  • change default 'd.vect render=' mode from l to (?)
--HB 28 Nov 2007: I hope to provide more test results soon
--HB 1 Dec 2007: "L" is still problematic, new tests posted to grass-dev
--HB 21 Jan 2008: Changed to "c". see [4] [5]
  • r.out.gdal sets NoData wrong #405
-- HB 24 Oct 2007: Is this really release critical? - need to find Frank's email on the subject and post it to the bug report. At least for a Byte map the no data value must live somewhere in 0-255, there is no IEEE nan for Ints.
-- MS 26 Oct 2007: It is critical. It's a data corruption issue.
-- HB 29 Oct 2007: IMO we just document that GDAL works like that. I don't see another good solution. I still need to look up Frank's answer..
-- MS 19 Nov 2007: This is not acceptable. It's a data corruption and a regression compared to script version of r.out.gdal. Suggestion: if we have to choose between 2 bad things: a valid value replaced by null by force, thus corrupting the output (like in C r.out.gdal), and setting null to eg. 256 for a a 0-255 raster to avoid that (like in shell-script r.out.gdal), I prefer the latter. This is less harmfull.
-- HB 28 Nov 2007: At least for a Byte map, there is no 256! 1byte=8bits, giving you 2^8 data value possibilities and no more. Byte maps do not support NaN either. As you suggest I will compare script & C version output before commenting further.
-- MS 17 Dec 2007: Hamish, regarding "for a Byte map, there is no 256!" - I know. But that's what gdal_translate does (see the link you once mentioned to me) to avoid data corruption which takes place in C r.out.gdal. This is not "good", but at least data corruption is avoided, which would be "horrible".
-- MS 04 Jan 2008: Martin's patch fixed the bug for me.
-- HB 21 Jan 2008: Ok, glad for the fix.