GRASS 7 ideas collection

Maintenance of repository

For grass7 development will be used svn-trunk, for grass6 must be created new branch.

  Planning is continued here: http://trac.osgeo.org/grass/wiki/Grass7Planning

Raster

See also Replacement raster format

Library

• allowing nulls to be embedded
• Split libgis into G_() part and Rast_() part
• Rewrite library from scratch. See suggestions
• Insert 'vertical' 2d rasters (e.g. geophysical survey data)
• GRASS raster "live links" via GDAL

Modules

rename

• rename r.in.gdal to r.import
• rename r.out.gdal to r.export
• rename r.volume 'data' parameter to something more standard like 'input' or 'map'

remove

• Remove r.bitpattern since r.mapcalc does it more nicely now
• Remove r.in.arc and r.out.arc, if a related bug in r.in.gdal is fixed. The integer/floating point detection for AAIGrid driver in GDAL was fixed after 1.3.2 release, so r.in.gdal and r.out.gdal should be enough now.

• remove r.resample and r.bilinear in favor of r.resamp.interp
• remove r.univar.sh; newly implemented r.univar features cover it

• remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See RT #3680 (starting with date Sun, Nov 26 2006 14:54:23).

It might be worth keeping r.out.tiff! It makes a nice delta when things don't go well (eg QGIS bug#348) --HB

• Remove remaining -v and -q flags for verbosity levels of modules.

Merge

• merge r.surf.idw and r.surf.idw2

while r.surf.idw will only output CELL maps, it is Very Fast.

• r.sum, r.mode, r.median, r.average, r.statistics, r.univar, r.univar2 - maybe they can be reduced to just r.statistics and r.univar? See RT #1848 and a thread on the GRASS dev list

• r.resamp.rst: merge into r.resamp.interp to make resolution management identical to the other modules

• r.in.wms and r.in.srtm into r.in.gdal thanks to native support for WMS and SRTM in GDAL 1.5
• r.buffer and r.grow

fix

• fix lseek() usage for Large File Support: see list of affected modules
• fix the raster map history management (truncating long history, odd storage). It should work like for vector maps in GRASS 6.
• r.volume centroids parameter only makes a level one vector with no attribute table; module should be updated to GRASS 6 vector library)

Vector

Radim's TODO list

Vector TODO list

• Particularly important: "Keep topology and spatial index in file instead of in memory" --ML

Library

• 2d 'vertical' vector data (e.g. Geologic Cross Sections)
• implement transactions for geometry handling (esp. v.edit, v.digit and to avoid leftover files when a vector command fails)
• Assume cat 0 as the first possible, instead of 1. GRASS has supported cat 0 since around 2005, but it hasn't been widely used. According to Radim, using cat 0 allows for exact mapping from OGR FID (which can be 0) to GRASS cat.
• support for elliptical arcs, quadratic and cubic splines. Elliptical arcs or circular arcs are very common in Swiss survey data (Amtliche Vermessung)

Modules

rename

• rename v.in.ogr to v.import
• rename v.out.ogr to v.export
• rename v.mkgrid to v.grid
• rename v.univar.sh to v.db.univar (comment)

remove

• Remove doubled units in v.to.db GUI

merge

• merge v.select and v.overlay

needs discussion, they are doing fundamentally different things --HB

• merge v.sample and v.what.rast

See a feature request #506 in GForge.

fix

• Fix the Column 'cat_' already exists (duplicate name) in v.in.ogr. Maybe by creating columns cat_1, cat_2 etc. each time a Grass vector is exported to shapefile and imported back to Grass?
• write Vect_map_exists() and implement in g.remove and v.digit -n (why wait for GRASS 7 ??)
• add '-d' dissolve to v.reclass
• add 'where=' to v.to.rast (why wait for GRASS 7 ??)
• implement Douglas-Peucker generalization (C code file)to substitute prune tool of v.clean (done?, see also GSoC)
  • This is done. v.generalize does D-P and a lot more -WB
• Rewrite vector labeling. Needs more placement control options (may be db field value based), label overlapping prevention would be also good. May be we could borrow some ideas from MapServer? (ongoing: v.label.sa)
• v.what.vect - rename parameters "vector" to "map", "qvector" to "qmap"
• v.type - change type= option to from= and to=.(code's already in there)

enhance

• extend v.overlay to allow combination of all types (point, line, area)
• v.category: add possibility to create new layer categories on the basis of a column in the table linked to an existing layer

General

Library

• Add support for planetary bodies reference systems
• Add new partial differential equation (PDE) library with OpenMP support (GRASS 6.3)

Modules

• g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [1].

controversial, needs more discussion --HB

• g.region
  • Glynn's notes - cleaning the print flags and new print= option
  • Support vector's 3rd dimension in g.region vect= [-a], [res=], like the 2d extents are (or should be).

Database

Library

• establish SQLite as default DBMI driver (DBF is too limited)

Modules

• allow cross-mapset database access, i.e. parse the '@mapset' notation appended to vector names

Imagery

Library

Do merge of image libraries:

• A)
  • lib/imagery/: standard lib, in use (i.* except for i.points3, i.rectify3)
  • imagery/i.ortho.photo/libes/: standard lib, in use (i.ortho.photo, photo.*)
• B)
  • lib/image3/: never finished improvement which integrated the standard lib and the ortho lib. Seems to provide also ortho rectification for satellite data (i.points3, i.rectify3)

Modules

• merge of i.points, i.vpoints, i.points3

drop these altogether? (loss of interactive XDRIVER)

• merge of i.rectify and i.rectify3

maybe depend on gdalwarp C API for this?

• addition of new resampling algorithms such as bilinear, cubic convolution (take from r.proj?)
• add other warping methods (maybe thin splines from GDAL?)
• implement/finish linewise ortho-rectification of satellite data
• Depreciate tape functions in next major revision of GRASS and create a tape module that accomplishes tape access.

Raster3D

Library

• renaming of all G3D library functions to fulfil the grass coding standard
• extent/rewrite documentation
• localisation support (why wait for GRASS 7 ??)

Modules

• report and support modules like r3.stats, r3.support
• voxel -> vector (isosurfaces ...) and vector -> voxel (lines, faces, volumes) conversion modules
• module for 3d Kriging interpolation based on vector points
• a GRASS-Python/VTK visualisation/manipulation tool

Display

New display architecture

Comments from Glynn Clements (from here):

1. Eliminating separate driver processes. Having to extend the protocol for each new operation has been a major drag on development.
2. Use of floating-point for all graphics coordinates. For geographic data, the expected approach will be to set an appropriate transform then use cartographic coordinates.
3. Common architecture for both video and hardcopy output. ps.map should be redundant.

In retrospect, #1 means that we don't really need support for the Windows/MacOSX GUI, just the ability to generate image files.

With X, we could take the shortcut of having d.* commands draw directly into an existing window, but I don't know whether that's possible on other platforms.

OTOH, it might be useful to be able to use the same functions for self-contained GUI programs (e.g. vector digitising) as for d.* commands.

Library

• Drop support for interactive xmon modules

Modules

• d.font etc.
  • Huidae Cho merged d.text.freetype and d.text into d.text.new; drop them and rename d.text.new into d.text
  • merge d.font and d.font.freetype too

now done in 6.3?

• d.vect
  • consolidate parameter names (attrcol, wcolumn, rgb_column)

how?

• remove d.ask, d.menu, d.linegraph(?), d.mapgraph, d.text.freetype, d.paint.labels (symlink), d.font.*

• remove d.m

• d.legend, d.barscale, d.text, etc: make at=0,0 origin identical!

FWIW, I copied the d.legend at= syntax from d.frame --HB

Postscript

Modules

ps.map

• remove scale parameter

-> from the command line, not the map instruction

• rename sizecol to sizecolumn (remove the given warning)

See also "New display architecture" comments above.

Parser

• "Add another semantic meaning to the parser system for a type safe enumerated list" (Cedric's words commenting the bug that v.type doesn't allow for selecting input and output type in GUI

• Making GRASS modules be less verbose. Use --verbose flag and GRASS_VERBOSE environment variable. All output (G_message, G_percetn, G_warning) should go to GRASS_LOG file which could be grassdata/location/mapset/.grass.log by default.

less verbose: this is well underway in 6.3

Note warning and errors are already logged to GIS_ERROR_LOG (see variables.html)

Init shell and startup

• .grassrc6 is not what you expect. It holds the g.gisenv GIS variables, it's not a shell script containing commands like .bashrc is.

Suggestion: We should change the name for 7.x. It isn't an "rc" file in the conventional sense.

Suggestion: make it even a $HOME/.grass7/ directory to store settings etc (e.g., from r.li and others)

• It is asked to run GRASS in its own shell to avoid portability issues 1.

• Eliminate Init.sh. Glynn explains on GRASS user ML: "Most of the environment can be set up through an e.g. /etc/env.d/grass script. The database, location and mapset can be set through g.mapset. The only slight subtlety is if you want multiple independent sessions, but that can be done with a fraction of the code in Init.sh."

• Provide a mechanism (g.access option?) to enable r/w access for users in mapsets they don't own. So that it they don't need to hack lib/gis/mapset_msc.c. Glynn explains on GRASS user ML: "AFAICT, that restriction has been unnecessary ever since the lockfile was moved from the user's home directory to the mapset directory."

Data management

• store vertical units on per-map base, using code from units software

Support for free form unit meta-data added in 6.3. I don't mind it as a guide, but we shouldn't be limited to units found in units. --HB

• store vertical map datum on per-location base (GDAL/OGR needs the same enhancement)

This requires more discussion. I'm not sure it's a good idea to do this location-wide. --HB

On a per raster map basis done in 6.3 cvs.

• add versioning for maps (to recover previous map versions)

see "v.info -h" ?

Time series

• Implement better Time series in GRASS support (series of satellite data etc)

for example?

Visualization

• better support for faces and kernels in libgis

not really Visualization, but....

CLI

• Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 documents/parameter_proposal.txt

• Get rid of 'quiet/verbose' flags, preparation in GRASS 6, e.g.:

    /* please, remove before GRASS 7 released */
    if(q->answer) {
        putenv("GRASS_VERBOSE=0");
        G_warning(_("The '-q' flag is superseded and will be removed "
            "in future. Please use '--quiet' instead"));
    }

GUI

• Multiplatform
• Fast, minimalist, number of windows reduced
• Manageable also from command line via d.* modules
• Facilitating easy development of custom GUI application based on GRASS

• → WxPython-based GUI for GRASS

Conceptual changes

• File organization in binaries:
  • the grass etc dir is a mess... module should maintain arch-deps and arch-indep things in different paths -- frankie at #grass irc
  • it's basically a FHS violation, i dunno if it is reported by lintian, anyway /usr/lib/grass should be used for arch-deps data, not for mixed stuff -- frankie at #grass irc
• Creating $HOME/.grass7 directory for
  • Custom fonts
  • r.li and other modules temp. files
  • GEM addons installation
  • Default path for custom scripts
  • Custom symbols and EPS fill patterns
  • Custom color maps
  • Add here new item

User Wishes

This section is not really development related...

• 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):
  • dynamic surfaces and volumes
  • some water
  • particles
  • solar radiation and energy
• Convince the users to use ParaView [2] for sophisticated animations --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 discussion
• Or use VisIt software, it should be able to read GRASS maps directly via GDAL

Complete GRASS Test Suite

• base a comprehensive test suite on Soeren's GRASS Test Suite
• automated error checking on all modules to catch data corruption issues