GRASS 6.3 Feature Plan

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 CVS: tags and branches. A release branch is considered as "frozen", only bugfixes can be done.

RC1

(not released yet, planned for 22 Oct 2007)

• annoying winGRASS vector/DBMI freeze bug (Glynn Clements)
• replace r.proj with r.proj.seg
• d.text with d.text.new
• Windows start script's installed on Linux (grass63.bat etc.) #323 and #471 (Glynn Clements)
• Makefile cleanups for parallel builds #359 (Glynn Clements)

Must do

• complete and stabilize the native winGRASS port (seems to be in a good shape now)
• g.region vect=map -a issues #489
• r.out.gdal sets NoData wrong #405
• r.info and Total Cell count overflow #493

Mostly done?

• use GEM for GRASS Addons SVN - status unclear

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 vector improvements as suggested by Radim
• Integrate 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, for 6.5?
• 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)

• raster maps: implement SQL based time series support (Markus has working code from Soeren; done some improvements)
• 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.

In progress

• native MS Windows port
• 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 [1] and [2]:
  • display commands
  • database commands
  • general commands
  • imagery commands
  • misc commands
  • paint commands
  • photo commands
  • postscript commands
  • raster commands
  • raster3D commands
  • vector commands
• continue with WxPython-based GUI for GRASS
• write (Python based?) GUI wizard to create new locations (done by Jachym, see WxPython-based GUI for GRASS)
• improve Python-SWIG interface
• less verbose commands (work in progress)
• BLAS/LAPACK updates (Brad)