GRASS 6.3 Feature Plan

From GRASS-Wiki
Revision as of 12:53, 11 August 2006 by Neteler (talk | contribs) (add GDAL/OGR support in ParaView to read directly data from GRASS)
Jump to navigation Jump to search

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.

Basic principles:

  1. 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 ~~~~!
  2. If You work on it, and You think it will make to next release, MOVE to #In progress section.
  3. When You finish and commit Your work, MOVE it to #Finished section.

Warning After 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.

TODO

  • Make sqlite the default DB?
  • Create GRASS Addons SVN repository and really use GEM
  • 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

Wishes

  • Create 3D animation w nviz showing GRASS 3D coolness. MarisN 12:00, 4 August 2006 (CEST)
  • here are some examples to get inspired (apparently that's already possible):
  • Convince the users to use ParaView [1] for sophisticated animations || Add support for Paraview in GDAL/OGR or add GDAL/OGR support in ParaView to read directly data from GRASS

In progress

  • Database connection for v.out.vtk
    • single column support for numerical data (int, float, double)
    • GRASSRGB column support
    • multiple column support for vector data
  • rewrite most of the g3d modules to fulfil the grass function naming convention
  • rewrite of r.to.rast3, r.to.rast3elev, v.out.vtk and r.out.vtk to fulfil the grass function naming convention

Finished