GRASS 6.3 Feature Plan

From GRASS-Wiki
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.

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

released 24 Oct 2007

  • annoying winGRASS vector/DBMI freeze bug (Glynn Clements)
  • replace r.proj with r.proj.seg
  • replace 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)
  • r.info and Total Cell count overflow #493 (Glynn Clements, Brad Douglas)
  • Makefile cleanups for MS-Windows (Glynn Clements)

RC2

not released yet

  • gis.m/georect: fix broken msg which crashed the tool (Michael Barton)
  • g.version newline fix (Hamish Bowman)
  • r.stats complilation fix for Slackware (Huidae Cho)
  • r.terraflow: changed to GPL (Laura Toma, Glynn Clements)
  • Fix definition of US survey foot (Glynn Clements)
  • r.out.tiff/db.execute manual bug for extensions (Paul Kelly)
Must do
  • complete and further stabilize the native winGRASS port (seems to be in a good shape now)
  • 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, propably 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.
  • 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..
Mostly done?
-- HB 24 Oct 2007: needs testing- commit after 6.3.0 is released
-- not sure why not to be committed to HEAD - MN
-- HB 29 Oct: It can go into HEAD now, I just haven't done it yet. It should not be in the 6.3.0 release, that was my meaning.
-- HB 24 Oct 2007: not ready. needs fixing for NULLs.
-- 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)
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.
  • 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.
    • 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).
  • 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.
    • 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).

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 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)
Retrieved from "https://grasswiki.osgeo.org/w/index.php?title=GRASS_6.3_Feature_Plan&oldid=5073"