wiki:Grass6Planning

Version 147 (modified by neteler, 10 years ago) ( diff )

cleanup

Table of Contents

  1. To be released
    1. GRASS 6.4.5
  2. Blockers
  3. Further bugs to be fixed in GRASS GIS 6
  4. Can do in GRASS GIS 6
  5. HTML manual pages polishing
  6. Wishlist
    1. Updates to vector querying
  7. Already released
    1. GRASS GIS 6.4.5
    2. GRASS GIS 6.4.4
    3. GRASS 6.4.3
    4. GRASS 6.4.2
    5. GRASS 6.4.1
    6. GRASS 6.4.0

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.4.

There is the release branch for 6.4.x - releasebranch_6_4. See details at ​tags and branches. A release branch is considered as "frozen", only bugfixes can be done.

To be released

Please backport with one commit (log message) for one change, not all at once, thanks. In general it is a good idea to wait a few days after release before beginning lots of changes, in case a "brown bag" release is needed. Otherwise we'd need to cut a new branch from the tag for that (to avoid brown-bag releases, last minute changes just before release are also discouraged).

GRASS 6.4.5

  • ... add issues here

Blockers

No results

Further bugs to be fixed in GRASS GIS 6

Can do in GRASS GIS 6

Merge in replacements from Addons:

Modules to consider:

  • v.pack

HTML manual pages polishing

The ​validator reports faulty pages. Correct pages are also needed for a future reST/Sphinx conversion

DONE:

  • gis.m
  • d.colorlist
  • d.extend
  • d.nviz
  • d.profile
  • d.rast.arrow
  • db.execute
  • db.select
  • g.mkfontcap
  • g.proj
  • d.what.rast

TODO list (you may use validator ​file upload, the dillo web browser also has a nice validator built in):

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 <- done in GRASS GIS 7
  • Make sqlite the default DB <- done for 7
  • Integrate i.points.auto (merge into i.vpoints) - note that A Scianna/Palermo has modernized version - ???
  • raster maps: implement SQL based time series support <- done for 7

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.

Already released

Release summary list

GRASS GIS 6.4.5

GRASS GIS 6.4.4

GRASS 6.4.3

Release/6.4.3-News

New features (for release news):

  • Python editor for wxGUI Graphical Modeler

GRASS 6.4.2

Release/6.4.2-News

List of backports (modules) - done in r45933

  • v.net.allpairs, v.net.bridge, v.net.centrality, v.net.components, v.net.connectivity, v.net.distance, v.net.flow, v.net.spanningtree, v.net.timetable
  • v.kernel: r45407 (#1277) - done in r45955, r45956
  • r.univar, r3.univar: zonal support - done in r45941
  • pythonlib - done in r45934, r45935, r45936
  • v.out.ogr transactions + overwrite - done in r45943

Candidates for backporting:

  • r44869, r44817, r44890 (#1128) done in r46624, r44930, r45069, r45190, r45191, r45262 + r45235
  • wxGUI - done in r45931
  • wxGUI/vdigit - done in r45931
  • ps.map (I ask that this change is not backported until further notice. Only the minimal patch to backport the "b flag" should be considered. I'm still considering reverting parts of the rest. thanks, HB.)
  • quoting: (HB: each change requires testing before backport, tx)
  • gislib: (HB: do not backport, it's buggy: returns before logging errors to GIS_ERROR_LOG.)

GRASS 6.4.1

Release/6.4.1-News

  • Any open Trac bugs which are blockers for 6.4.1 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.

Candidates for backporting:

GRASS 6.4.0

Release/6.4.0-News

Note: See TracWiki for help on using the wiki.