GRASS-Wiki - User contributions [en]

AddOns/GRASS 6

2017-03-21T11:34:25Z

⚠️Benducke: Added new entry for GRASS 6 raster add-on "r.fill.gaps".

Back to the main [[AddOns]] {{bullet}} [[AddOns/GRASS 7]] {{bullet}} [[AddOns/GRASS 5]] {{bullet}} [[AddOns/GRASS 4]]

See also
svn co https://svn.osgeo.org/grass/grass-addons/grass6/
__TOC__
=== Vector add-ons ===

See also
svn co https://svn.osgeo.org/grass/grass-addons/grass6/vector

==== v.adehabitat.clusthr, v.adehabitat.kernelUD, v.adehabitat.mcp ====

: Tools to calculate home ranges of animals
: '''Author:''' Clement Calenge

Available via SVN or {{cmd|g.extension}}:
svn co https://svn.osgeo.org/grass/grass-addons/grass6/vector/adehabitat

==== v.append ====

: [http://web.archive.org/web/20060914172621/http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.append v.append] is a shell script combining two vector files AND their associated attribute tables. The vector files should be of the same type and, for best results, should have identically formatted attribute tables.
: ''Note'': also module ''v.patch'' can be used for this task.

: '''Author:''' Michael Barton

==== v.autokrige ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.autokrige/v.autokrige.py v.autokrige] achieves automatic ordinary kriging from GRASS sites (vector point data), using R with spgrass6 (RGRASS) and automap packages.

: '''Author:''' Mathieu Grelier

==== v.breach ====

: Creates vector maps of lines and points of continously lowering elevation down the input watercourses, based on the underlying input raster DEM.

: Available via [http://grass.osgeo.org/grass64/manuals/g.extension.html g.extension] or [https://svn.osgeo.org/grass/grass-addons/grass6/vector/v.breach/ SVN].

: '''Author:''' Maciej Sieczka

==== v.colors ====

: {{cmd|v.colors}} ''moved into main archive''

==== v.count.points.sh ====

: [https://web.archive.org/web/20070712104226/http://wiki.iosa.it/dokuwiki/spatial_analysis:feature_count v.count.points.sh] counts point features in areas, generates table good as input to {{cmd|d.vect.chart}}.

: '''Author:''' Stefano Costa

==== v.curvature ====

: {{AddonSrc|vector|v.curvature|version=6}} calculates average curvature along a segment given by from/to distance measured along the line specified by category.

: '''Author:''' Radim Blazek

==== v.digatt ====

: [http://src.geo.uni-augsburg.de/download/grass/v.digatt v.digatt] (shell script) Interactively assign numeric table attributes to series of vector objects. It is meant to be effective by avoiding to type in the attribute value for all single objects again and again. The user is prompted for typing in an attribute value which is assigned to all objects selected by mouseclick afterwards. Next the display is redrawn after updating the table column. Zooming allows to change the region before the old value can be reused or a new one can be typed in (or copied by mouse from another object) in order to assign it to the next series of objects etc. It is tested not very extensively yet. Therefore better work with a copy of your map and consider using v.digit or d.what.vect -e alternatively. [http://src.geo.uni-augsburg.de/download/grass/v.digatt.png screenshot].

: '''Author:''' Andreas Philipp

==== v.dip ====

: [http://marcin.slodkowski.googlepages.com/v.dip.tgz v.dip] creates points of thickness vectors from the vectors of strike and dip angles. The v.dip is the main ANSI C core program. Program so-called v.dip can run without GRASS environment.

: '''Author:''' Marcin Slodkowski

==== v.flip ====

: Flips the direction of selected vector lines (redundant since GRASS 6.3 - there is "v.edit tool=flip"; and later there came the v.digit GUI flipping tool as well).

: Available via [http://grass.osgeo.org/grass64/manuals/g.extension.html g.extension] or [https://svn.osgeo.org/grass/grass-addons/grass6/vector/v.flip/ SVN].

: '''Author:''' Maciej Sieczka

==== v.group ====

: [http://www.shockfamily.net/cedric/grass/v.group v.group] generates a new vector map with the same geometry as an existing map. The new map has categories and a table based on grouping by the values in certain columns of the existing map's table. The values in these columns are preserved in the table for the new map. It's like a v.reclass that preserves data.

: '''Author:''' Cedric Shock

==== v.in.adcirc_grid ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.in.adcirc_grid v.in.adcirc_grid] will import a grid and boundary information file (<tt>fort.14</tt>) created for the [http://www.adcirc.org ADCIRC] coastal ocean circulation model. The user may choose between importing the mesh grid triangles as lines or importing the grid nodes as points. In both cases 3D coordinates and identifier numbers are preserved.

: '''Author:''' Hamish Bowman

==== v.in.gama ====

: Converts [http://www.gnu.org/software/gama/ GNU GaMa] XML output file to a GRASS vector map layer.

:'''Author:''' Martin Landa

svn co https://svn.osgeo.org/grass/grass-addons/grass6/vector/v.in.gama

==== v.in.geodesic ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.in.geodesic v.in.geodesic] is a shell script which will create a new vector map containing a great circle line. The user may either define a beginning and end coordinate, or define a starting coordinate along with initial azimuth and desired line length.

: '''Author:''' Hamish Bowman

==== v.in.geoplot ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.in.geoplot v.in.geoplot] converts a [http://www.geoscan-research.co.uk/page9.html/ Geoplot] ASCII export file to a GRASS vector map layer.

:'''Author:''' Benjamin Ducke

svn co https://svn.osgeo.org/grass/grass-addons/grass6/vector/v.in.geoplot

==== v.in.gshhs ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.in.gshhs v.in.gshhs] imports [http://www.soest.hawaii.edu/pwessel/gshhs/index.html GSHHS] shorelines into a GRASS vector map. GSHHS (aka GSHHG) data are automatically reprojected to the current location.

:'''Authors:''' several, updated to GRASS 6 by Markus Metz

==== v.in.marxan ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.in.marxan v.in.marxan] is a python script that imports Marxan output data for display in a vector grid file prepared using v.out.marxan.
: ''see also the [http://www.uq.edu.au/marxan/ Marxan]

: '''Author:''' Trevor Wiens

==== v.in.mbsys_fnv ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.in.mbsys_fnv v.in.mbsys_fnv] imports [[MB-System]] navigation files into a GRASS vector map. You can choose from swath area coverage, track lines (including outer port/starboard edges), all bounds as points, etc. An attribute database is created containing the vital statistics of the specified feature such as track length or swath coverage (geodesic), start stop time and location, pitch, roll, heave, etc. See also the [[#v.in.p190]] addon.

:'''Author:''' Hamish Bowman

==== v.in.ncdc ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.in.ncdc v.in.ncdc] imports an [http://www.ncdc.noaa.gov NCDC] stn file (station data) into a GRASS vector map.

: '''Author:''' Huidae Cho

==== v.in.osm ====

: [http://kripton.kripserver.net/software/v.in.osm/ v.in.osm]: OpenStreetMap import into GRASS. Yet only supports deprecated API 0.4, will be modified to work with API 0.5 some time soon.

: '''Author:''' Jannis Achstetter

: See also [http://hamish.bowman.googlepages.com/gpsdrivefiles#osm osm2grass.sh] by H Bowman

==== v.in.osm2 ====

: [https://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.in.osm2 v.in.osm2]: OpenStreetMap import into GRASS. Supports current API 0.6, downloads using the [http://wiki.openstreetmap.org/wiki/Xapi Xapi] interface and imports using GpsBabel 1.3.5 or newer. GpsBabel restricts to either nodes or ways being imported at a time, not both. Use {{cmd|v.patch}} to rejoin them. (''work in progress'')

: '''Author:''' Hamish Bowman

==== v.in.ovl ====

: [http://grasslab.gisix.com/scripts/v.in.ovl/ v.in.ovl] is a shell script that imports an ASCII vector file created with TOP10|25|50 or similar products.

: '''Author:''' Peter Löwe

==== v.in.p190 ====

: [https://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.in.p190 v.in.p190] is a shell script that imports 'Centre of Source' "S" navigation data from seismic P1/90 (UKOOA) data files and writes either GRASS vector points or vector lines format. Optionally it will export the navigation data into .csv text files as well. ''Currently in the functional prototype stage, some assembly is required. See inside the shell script for details.'' For working with SEG-Y data, see also the [[#v.in.mbsys_fnv]] addon.

: '''Author:''' Hamish Bowman

==== v.in.ply ====

* GRASS 6: [https://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.in.ply v.in.ply] is a shell script that imports a PLY file and writes it as GRASS vector points. For a much more advanced version, see the GRASS 7 version.

: '''Author:''' Markus Neteler

==== v.in.postgis ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.in.postgis/v.in.postgis.py v.in.postgis] Create a GRASS layer from any sql query on PostGIS data.

: '''Author:''' Mathieu Grelier

==== v.in.redwg ====

: [http://lists.gnu.org/archive/html/info-libredwg/2010-08/msg00000.html v.in.redwg imports DWG files into GRASS.]
:'''Author:''' Rodrigo Rodrigues da Silva

svn co https://svn.osgeo.org/grass/grass-addons/grass6/vector/v.in.redwg

==== v.krige ====

: [[V.krige_GSoC_2009 | v.krige]] aims to integrate R functions for kriging (packages automap, gstat, geoR) in a trasparent way. '''Moved into trunk/devbr6 code (r40048)'''

: '''Author:''' Anne Ghisla, as Google Summer of Code 2009 project

: See also [[GRASS_AddOns#v.autokrige]] by Mathieu Grelier

==== v.lda.py ====
* '''Spatial Analysis Tools'''

: [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.lda.py v.lda.py] is a Python script for calculating Ian Johnson's (U. Sidney) Local Density Analysis values. This can be used in two ways. When only one vector points file is entered, it serves to measure clustering of point data at different neighborhood radii. When two different point files are entered, it measures the the co-occurence of the points from the two files. There is an option to export the data into a cvs format file for easy plotting in a spreadsheet or statistical program like R.

==== v.nn.py ====
* '''Spatial Analysis Tools'''

: [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.nn.py v.nn.py] is a Python script for calculating the nearest neighbor coefficient of a single vector points file--as an index of clustering--or of two points files--to provide an index of the correspondence between the points in one file and points in a different file.

==== v.ldm ====
:[https://raw.github.com/amuriy/GRASS-scripts/master/v.ldm v.ldm] Shell script to compute "Linear Directional Mean" of vector lines, to display LDM graphics on the graphic monitor, and optionally to save it to vector line and update attribute table with LDM parameters.
:See [http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/How_Linear_Directional_Mean_works/005p0000001r000000/ this link] for full LDM description.

: '''Author:''' Alexander Muriy

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/vector/v.ldm/

==== v.line.center ====

: Creates a points vector map with each point located in the middle of the length of the input vector line.

: Available via [http://grass.osgeo.org/grass64/manuals/g.extension.html g.extension] or [https://svn.osgeo.org/grass/grass-addons/grass6/vector/v.line.center/ SVN].

: '''Author:''' Maciej Sieczka

==== v.lmeasure ====

: [http://web.archive.org/web/20060827192321/http://ngeo.de/grassstuff/v.lmeasure v.lmeasure] and [http://web.archive.org/web/20060827060303/http://ngeo.de/grassstuff/v.revlmeasure v.revlmeasure] are two perl scripts that place equidistant vector points along a given arbitrary vector line starting from the beginning or end of the vector line, respectively. Resulting vector points are labeled with the distance from origin.

: '''Author:''' Mats Schuh

==== v.mainchannel ====

: [https://svn.osgeo.org/grass/grass-addons/grass6/vector/v.mainchannel/description.html v.mainchannel] is a shell script which finds the main channel of a basin starting from the vector file of the stream network.
: '''Author:''' Ivan Marchesini, Annalisa Minelli

Available via SVN or {{cmd|g.extension}}:
svn co https://svn.osgeo.org/grass/grass-addons/grass6/vector/v.mainchannel/

==== v.mk_circle ====

: [http://tekmap.ns.ca/blog/grass_mk_circle v.mk_circle] is a program to create a closed vector at a user defined location and size. The program supports output of different shapes, open boundaries and closed centroids, and will accept multiple locations and sizes from an ASCII file or standard input. GRASS 7 version is also available.

: '''Author:''' Bob Covill

==== v.mkhexgrid ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.mkhexgrid v.mkhexgrid] is a python script that creates a hexagonal grid the size of the selected region using user specified side lengths or areas. This has been updated 2011-09-14.

: '''Author:''' Trevor Wiens

==== v.out.ascii.db ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.out.ascii.db v.out.ascii.db] is a shell script for exporting vector point data coordinates and selected attribute columns to either a file or to the console.
: ''Superseded in GRASS 6.4 by the new v.out.ascii columns= option.''

: '''Author:''' Hamish Bowman

==== v.out.ascii.mat ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.out.ascii.mat v.out.ascii.mat] is a shell script for exporting vector polygon and polyline data into an ASCII text file suitable for loading into Matlab (or [http://www.gnu.org/software/octave/ Octave]).

: '''Author:''' Hamish Bowman

==== v.out.blend ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.out.blend v.out.blend] is a Blender user oriented add-on. It outputs a 3d delaunay triangulation (.ply file) from a 3d vector pointcloud and optionally an image to drape on (.tif file), e.g. within Blender. It comes wiht a brief tutorial on the use of [http://grasswiki.osgeo.org/wiki/GRASS_and_Blender GRASS and Blender].

: '''Author:''' Vincent Bain

==== v.out.geoserver ====

: [http://www.wgug.org/index.php?option=com_content&view=article&id=56&Itemid=9 v.out.geoserver] is a shell script for exporting vector data to [http://geoserver.org GeoServer] directly. It uses: v.out.ogr, curl, zip and GeoServer REST interface.

: '''Author:''' Pawel Netzel

==== v.out.gmt ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.out.gmt v.out.gmt] is a shell script that exports a polygon vector file into GMT xy file. psbasemap code was copied from Hamish's r.out.gmt.

: '''Author:''' Huidae Cho, Hamish Bowman, Dylan Beaudette

==== v.out.kml ====

: [http://grasslab.gisix.com/scripts/v.out.kml/ v.out.kml] is a shell script that exports a vector file into a KML file for Google Earth or Worldwind. see also [[#r.out.kml|r.out.kml]] and [[#r.out.gmap|r.out.gmap]]

: '''Author:''' Peter Löwe

==== v.out.marxan ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.out.marxan v.out.marxan] is a python script that prepares vector layers and exports GRASS vector attributes and adjacency information as Marxan input files. Output from Marxan simulations can be imported using v.in.marxan.
: ''see also the [http://www.uq.edu.au/marxan/ Marxan]

: '''Author:''' Trevor Wiens

==== v.out.ply ====

: [https://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.out.ply v.out.ply] is a shell script that exports a GRASS vector points cloud into a PLY file.

: '''Author:''' Markus Neteler

==== v.out.svg ====

: [http://svg.cc/assvg/grass.html v.out.svg] is a module that exports SVG notation along with optional attribute data directly from GRASS 6.x vector layers. Now part of [http://svn.osgeo.org/grass/grass/trunk/vector/v.out.svg/ grass6-svn].

: '''Author:''' Klaus Förster

==== v.points.cog ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.points.cog v.points.cog] is a shell script which will create a new point at the center of gravity of each cluster of input points or centroids, grouped by attribute. Among other things this is useful for labeling swarms of points.

: '''Author:''' Hamish Bowman

==== v.profile ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.profile v.profile] is vector map profiling tool similar to r.profile. This module will print out distance and attributes to points/lines along profiling line. It's also usefull to determine places where raster profile crosses vector features (i.e. where to place river marker on river walley crossection).

: '''Author:''' Maris Nartiss

==== v.random.cover ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.random.cover v.random.cover] is a shell script for creating random points constrained within an irregularly shaped vector area. (v.random places points only in current region rectangle). Optionally the user can upload raster values at the points. See also '<tt>r.random cover= vector_output=</tt>'

: '''Author:''' Hamish Bowman

Note: constrained sampling within an irregularly shaped vector area available in GRASS 7's {{cmd|v.random|version=70}}

==== v.rasterbounds ====

: [http://les-ejk.cz/programs v.rasterbounds] is a shell script for creating polygon-vector file of rasterfile boundaries. The best version of GRASS is 6.1+. If you are using GRASS < 6.1, you have to be in the same mapset as your raster maps are from.

: '''Author:''' Jachym Cepicky

==== v.rast.stats2 ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.rast.stats2 v.rast.stats2] is an adapted version of the GRASS module v.rast.stats. It uses the grass addon [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.univar.zonal r.univar.zonal] to speed up calculation of univariate statistics from a GRASS raster map based on vector polygons.

: '''Authors:''' Markus Neteler, Otto Dassau

==== v.sample.buffer ====
* ''Currently unavailable. Being re-written in python. Target for inclusion in addons svn is January 2011''
''v.sample.buffer'' is a shell script that samples rasters in buffers of a specified size around features in a specified vector file. Sampling results are added as attributes to the vector file. This script was designed for sampling vegetation indices and DEM derived attributes for bird point counts. Sampling results can be one or more basic statistics such as mean, range, max, etc.

: '''Author:''' Trevor Wiens

==== v.select.region ====

: [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/v.select.region.tar.bz2 v.select.region] is a shell script that prints out the names of all vectors matching an input search pattern that has geometry (points, line, areas) that fall within a region bounded by an existing vector map, or within the current Grass region.

: '''Author:''' Eric Patton

==== v.selmany ====

: [http://svn.osgeo.org/grass/grass-addons/grass6/vector/v.selmany/v.selmany v.selmany] is a shell script that allows to interactively select a set of vector objects on a given layer, then assign them attribute values in a connected database table. The script runs on the command line prompt and within a graphic monitor ; it does not work with DBF driver.

: '''Author:''' Vincent Bain

==== v.surf.icw ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.surf.icw v.surf.icw] is an IDW [[interpolation]] method using true distance cost instead of euclidean shortest distance, i.e. ''as the fish swims around an island'' not ''as the bird flies''. This will cleanly travel around hard barriers and a cost surface map may be used to model expensive-cross barriers. Input data points do not need direct line of sight to be considered, but should be kept to less than one hundred as the module becomes very computationally expensive. A number of radial basis function options are available. ([http://grass.osgeo.org/wiki/Image:Inlets_03_SurfSal_icw_big.png screenshot])

: '''Author:''' Hamish Bowman

==== v.surf.idwpow ====

: [http://www.geospatial.it/allegri/grass/v.surf.idwpow.zip v.surf.idwpow] integrates the common v.surf.idw algorithm with the exponential parameter for the distance weights

: '''Author:''' Giovanni Allegri

==== v.surf.krige ====

: '''''deprecated: use v.autokrige instead'''''
: v.surf.krige is a script that do a surface interpolation from vector point data by Kriging method. The interpolated value of a cell is determined by using an omnidirectional variogram model fitted starting from model parameter given by user shown from the experimental semi variogram produced by v.variogram. The script can perform also the Leave-One-out cross validation to test the variogram model "fitted by eye" and an automatic fitted variogram model. The cross validation helps the user to choose the best variogram model to interpolate own data.

: '''Author:''' Pierluigi De Rosa.

==== v.surf.nnbathy ====

: [http://svn.osgeo.org/grass/grass-addons/grass6/vector/v.surf.nnbathy/ v.surf.nnbathy] will interpolate vector points or x,y,z data from a text file into a raster map in the current region using the natural neighbor method (either Sibsonian or non-Sibsonian), or via simple TIN. [''n.b. natural neighbor is far superior to TIN''!] It requires Pavel Sakov's [http://code.google.com/p/nn-c/ nn] natural neighbor interpolation program ''<tt>nnbathy</tt>'' to be independently installed.

: '''Authors:''' Hamish Bowman and Maciej Sieczka

==== v.strahler ====

: [http://www.pois.org/florian/downloads/grass/v.strahler.tgz v.strahler] is a module that calculates the Strahler Order for all lines of a given dendritic network.

: '''Author:''' Florian Kindl. Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/vector/v.strahler

==== v.swathwidth ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.swathwidth v.swathwidth] creates a vector map representing the sea bottom coverage of a multibeam (swath) sonar survey.
: ([http://david.p.finlayson.googlepages.com/swathwidth Screenshots])

: '''Authors:''' David Finlayson, Hamish Bowman

==== v.thickness ====

: [http://marcin.slodkowski.googlepages.com/v.thickness.tgz v.thickness] creates points of thickness vectors from the vectors of strike and dip angles.The v.thickness is GUI GRASS script for v.dip.

: '''Author:''' Marcin Slodkowski

==== v.transect.kia ====

: [https://svn.osgeo.org/grass/grass-addons/grass6/vector/v.transect.kia v.transect.kia] calculates kilometric abundance indexes (KIA), a common indirect presence index used in wildlife monitoring along line transect surveys.
: Path lenghts can be corrected by draping on a DEM, different type of point objects can be weighted according to their relative importance, and paths can be segmented using a further polygon vector (to calculate, say, abundances per elevation range or per habitat class).
: The module is written in bash and needs a GRASS install compiled with sqlite support.

: '''Author:''' Clara Tattoni and Damiano G. Preatoni

==== v.transects ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.transects v.transects] is a python script that creates a set of equidistant lines (transects) that are perpendicular to an input vector line file. Points and quadrilateral areas are alternative outputs.

: '''Author:''' Eric Hardin

==== v.trees3d ====

: [http://les-ejk.cz/programs/ v.trees3d] is a module for making 3D trees from input vector point file.

: '''Author:''' Jachym Cepicky

==== v.triangle ====
: [https://raw.github.com/amuriy/GRASS-scripts/a7df12d996abfe6461f509fce6feb6c869af2d5e/v.triangle v.triangle] -- front-end for <Triangle> utility (http://www.cs.cmu.edu/~quake/triangle.html) of J.R. Shewchuk.

Makes exact Delaunay triangulations, constrained Delaunay triangulations, conforming Delaunay triangulations and high-quality triangular meshes. In GIS terminology, it produces 2D TIN, optionally with "breaklines".
For more details see GRASS-wiki page [http://grass.osgeo.org/wiki/TIN_with_breaklines TIN with breaklines].

: '''Author:''' Alexander Muriy

==== v.trimesh ====
: [http://www.valledemexico.ambitiouslemon.com/vtrimesh.html v.trimesh] creates a triangular mesh from a vector map using areal constraints for refinement. It uses Jonathan Shewchuk's Triangle library.

: '''Author:''' Jaime Carrera

: Available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/grass6/vector/v.trimesh/

: '''''IMPORTANT''': The needed "[http://www.cs.cmu.edu/~quake/triangle.html Triangle]" library (by Jonathan Richard Shewchunk) is not GPL compatible (since it is not free for commercial use) so must be sourced and this addon module compiled by the end user.''

==== v.to.averline ====

: [https://raw.github.com/amuriy/GRASS-scripts/a7df12d996abfe6461f509fce6feb6c869af2d5e/v.to.averline v.to.averline] is a shell script to find "average" line(s) of input vector map. It works with simple algorithm stated [http://forums.arcgis.com/threads/26757-quot-Averaging-quot-lines?p=88781&viewfull=1#post88781 here] (2 methods -- average distance to vectors sampling or average number of vectors segments).

: '''Author:''' Alexander Muriy

==== v.to.equidist ====

: [https://raw.github.com/amuriy/GRASS-scripts/master/v.to.equidist v.to.equidist] is a shell script that generates vector points or line segments along a given vector line(s) with the equal distances (uses v.segment)

: '''Author:''' Alexander Muriy

==== v.what.rast.buffer ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/v.what.rast.buffer v.what.rast.buffer] is a script that calculates univariate statistics of raster map(s) from buffers around vector points. Results are written to a file. Resolution is taken from each input map.
: ''see also the [http://starspan.casil.ucdavis.edu StarSpan] software

: '''Author:''' Hamish Bowman

==== v.variogram ====
* [deprecated: use v.autokrige instead]

: v.variogram is a script that create an omnidirectional experimental semi-variogram. This scripts require R-statistics software installed on your machine. Now the script is updated to run on spgrass6 >= 0.3 and sp >= 0.9 [http://grass.osgeo.org/pipermail/statsgrass/2006-October/000455.html reply].

: '''Author:''' Ivan Marchesini, Pierluigi De Rosa.

==== v.vect.stats ====

: {{cmd|v.vect.stats}} counts the number of points falling into each polygon and optionally calculates statistics from numeric point attributes for each polygon.

Update 12/2012: v.vect.stats is now included in core GRASS 6.4.3, 6.5, and GRASS 7.

: '''Author:''' Markus Metz

==== AniMove ====

: [http://www.faunalia.it/animov/ AniMove] is software for analysis of animal movement and ranging behaviour using QGIS+GRASS+R.

:'''Authors:''' Support by Faunalia.it

==== Utilities ====

===== Shapemerge =====

: [http://perrygeo.googlecode.com/svn/trunk/gis-bin/shpmerge.sh shpmerge] merges all the shapefiles in the current directory into a single output shapefile

:'''Authors:''' Perrygeo

=== Raster add-ons ===

See also:

svn co http://svn.osgeo.org/grass/grass-addons/grass6/raster

==== Raplat ====

GRASS-RaPlaT: The Radio Planning Tool for GRASS GIS system developed by support of Slovenian largest mobile operator Mobitel. It is especially designed for radio coverage calculation of GSM/UMTS systems, but can be applied also to other wireless systems in the frequency range 400 MHz – 2.4 GHz (e.g. TETRA, WiFi). Its structure is modular and characterized by high level of flexibility and adaptability.

* Software + Documentation: http://www-e6.ijs.si/RaPlaT/GRASS-RaPlaT_main_page.htm

: '''Author:''' Department of Communication Systems, Jozef Stefan Institue, Jamova 39, SI-1000 Ljubljana, Slovenia

==== r.area ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.area r.area] Very simple module. Calculates area size (in cells) for every individual category in input raster map and write number of cells as the value of each cell in the area. Optionally writes a binary coverage map and sets a minimum area threshold. Works well with {{cmd|r.clump}}.

: '''Author:''' Jarek Jasiewicz

==== r.basin ====

: [http://svn.osgeo.org/grass/grass-addons/grass6/raster/r.basin/ r.basin] Generates the main morphometric parameters of the basin starting from the digital elevation model and the coordinates of the basin's closing section (see [http://grass.osgeo.org/wiki/R.basin wiki] for howto).

: '''Author:''' Margherita Di Leo, Massimo Di Stefano

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.basin/

==== r.bilateral ====

: [http://les-ejk.cz/files/programs/grass/r.bilateral.tgz r.bilateral] Bilateral filter is an edge-preserving filter, which combines domain and range filtering. It is written in C language.

: '''Author:''' Jachym Cepicky

==== r.broscoe ====

: [https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.broscoe/description.html r.broscoe.sh] calculates waerden test and t test statistics for some values of threshold area on a single basin, according to A.J.Broscoe theory (1959). Dependence: v.strahler package.
: '''Authors:''' Ivan Marchesini, Annalisa Minelli

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.broscoe/r.broscoe

==== r.boxcount ====

: r.boxcount and r.boxcount.sh calculate the fractal dimension for a given map. These are versions for grass6 of [http://www.ucl.ac.uk/~tcrnmar/ Mark Lake's modules] for grass43.

: '''Authors:''' Mark Lake, grass6 port: Florian Kindl.

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.boxcount/
svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.boxcount.sh/

==== r.burn.frict ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.burn.frict r.burn.frict] converts vector geometries to raster cells, using a simple anti-aliasing method to close "gaps" between diagonal cells. Useful for "burning" vector geometries into a friction surface, making sure that simulated movement does not "slip" through converted cells that have only diagonal neighbours.

:'''Author:''' Benjamin Ducke

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.burn.frict

==== r.clump4p ====

: [http://sil.uc.edu/downloads.html#software r.clump4p] is a C module similar to r.clump. It has an option to clump diagonal cells. It is also parallelized and completes much faster than r.clump.

: '''Authors:''' P. Netzel and T.F. Stepinski

==== r.colors.out_sld ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.colors.out_sld r.colors.out_sld] is a shell script used to export the color table associated with a raster map layer to an OGC [http://docs.geoserver.org/latest/en/user/styling/sld-cookbook/rasters.html SLD] XML file, for use with [[GeoServer]] and the ilk.

: '''Author:''' Hamish Bowman

==== r.colors.out_vtk ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.colors.out_vtk r.colors.out_vtk] is a shell script used to export the color table associated with a raster map layer to a {{wikipedia|VTK}} XML file. (see also [[Help with 3D]])

: '''Author:''' Hamish Bowman

==== r.colors.quantiles ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.colors.quantiles/r.colors.quantiles r.colors.quantiles] is a shell script used to create raster colors rules based on nquantiles. It uses R and spgrass6 package (RGRASS).

: '''Authors:''' Mathieu Grelier

==== r.colors.stddev ====

: [http://hamish.bowman.googlepages.com/grass_color_maps r.colors.stddev] ''moved into main archive''

==== r.connectivity.distance ====

: [http://svn.osgeo.org/grass/grass-addons/grass6/raster/r.connectivity.distance r.connectivity.distance] is a shell script, which is - as a part of the r.connectivity.* tool-chain - intended to make connectivity analysis based on graph-theory more easily available to conservation planning. r.connectivity.distance computes the (cost) distance between all habitat patches of an input vector map within a user defined euclidean distance threshold. See also [[#r.connectivity.network]] and [[#r.connectivity.corridors]]

: '''Author:''' Stefan Blumentrath, [http://www.nina.no NINA]

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.connectivity.distance/

==== r.connectivity.network ====

: [http://svn.osgeo.org/grass/grass-addons/grass6/raster/r.connectivity.network r.connectivity.network] is a shell script, which is - as a part of the r.connectivity.* tool-chain - intended to make connectivity analysis based on graph-theory more easily available to conservation planning. r.connectivity.network performs the (core) network analysis and computes connectivity measures for a set of habitat patches based on graph-theory (usig the igraph-package in R). See also [[#r.connectivity.distance]] and [[#r.connectivity.corridors]]

: '''Author:''' Stefan Blumentrath, [http://www.nina.no NINA]

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.connectivity.network/

==== r.connectivity.corridors ====

: [http://svn.osgeo.org/grass/grass-addons/grass6/raster/r.connectivity.corridors r.connectivity.corridors] is a shell script, which is - as a part of the r.connectivity.* tool-chain - intended to make connectivity analysis based on graph-theory more easily available to conservation planning. r.connectivity.corridors computes corridors between habitat patches for edges from r.connectivity.network based on (cost) distance raster maps from r.connectivity.distance and assigns user defined weight to the corridors. See also [[#r.connectivity.distance]] and [[#r.connectivity.network]]

: '''Author:''' Stefan Blumentrath, [http://www.nina.no NINA]

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.connectivity.corridors/

==== r.convergence ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.convergence r.convergence] calculates topographic convergence index (TCI), useful to detect lineaments represented by channel/ridge systems.

: '''Author:''' Jarek Jasiewicz

==== r.convergence_angle ====

: [https://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.convergence_angle r.convergence_angle] creates a raster map containing the convergence angle at each grid cell in the current region. This is the angle between true north and grid north and is handy for rotating gridded u,v velocity component data between the current map projection and geographic coordinates. It requires the PROJ.4 utilities to be installed.

: '''Author:''' Hamish Bowman

==== r.cpt2grass ====

: [http://hamish.bowman.googlepages.com/grass_color_maps r.cpt2grass] is a GRASS script for importing a [http://www.soest.hawaii.edu/gmt/ GMT] .cpt color table into GRASS. It can save to a text file suitable for r.colors or automatically apply the color table to a raster map. For a large collection of GMT .cpt files see http://soliton.vm.bytemark.co.uk/pub/cpt-city/
: Other palette ideas from [http://geography.uoregon.edu/datagraphics/color_scales.htm Univ. Oregon] and [http://oceancolor.gsfc.nasa.gov/PRODUCTS/colorbars.html NASA/Goddard's OceanColor] (latter partially translated for use with GRASS on the [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.colors.tools/palettes grass-addons SVN]).

: '''Author:''' Hamish Bowman

==== r.csr ====

: [https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.csr r.csr] integrates several Grass programs to produce colored, shaded-relief rasters in one step. Accepts single or multiple elevation/bathymetry maps as input; optionally will fill data holidays with 3x3 median filter, multiple times, if required; can apply color maps from a) input raster, b) another raster in MAPSET, or c) from a rules file; otherwise, rainbow colorbar is applied. Output colored, shaded-relief rasters can optionally be exported to tiff format if the appropriate flag is given. Shading parameters can be modified, though useful defaults are given.

: '''Author:''' Eric Patton

==== r.cva ====

: [http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html r.cva] is a cumulative viewshed analysis module. It is an advanced version of the {{cmd|r.los}} program.

: '''Author:''' [http://www.ucl.ac.uk/~tcrnmar/ Mark Lake]

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.cva/

==== r.dam ====

r.dam is a bash script shell useful to create input for [http://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.damflood r.damflood] module (GRASS7 add-on)

https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.dam/

: '''Author:''' Roberto Marzocchi

==== r.denoise ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.denoise r.denoise] denoises (smooths/despeckles) topographic data, particular DEMs derived from radar data (including SRTM), using Xianfang Sun's [http://www.cs.cf.ac.uk/meshfiltering/index_files/Page342.htm denoising algorithm]. It is designed to preserve sharp edges and to denoise with minimal changes to the original data. See the [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.denoise/description.html manual pages] for details. Further information on Sun's denoising algorithm, including an example, is available [http://personalpages.manchester.ac.uk/staff/neil.mitchell/mdenoise/ here].

: '''Author:''' John Stevenson

==== r.dominant_dir.m and r.calc_terraflow_dir.m ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.terraflow.tools dominant_dir.m and calc_terraflow_dir.m] are two Matlab scripts for determining the dominant flow direction from a r.terraflow MFD map and converting into a GRASS aspect map for use with d.rast.arrow, etc.

: '''Author:''' Hamish Bowman

==== r.diversity ====
: [http://svn.osgeo.org/grass/grass-addons/grass6/raster/r.diversity/ r.diversity] calculates selected diversity indices by calling various r.li commands.This script uses the [http://grass.osgeo.org/grass64/manuals/html64_user/r.li.pielou.html Pielou], [http://grass.osgeo.org/grass64/manuals/html64_user/r.li.renyi.html Renyi], [http://grass.osgeo.org/grass64/manuals/html64_user/r.li.shannon.html Shannon] and [http://grass.osgeo.org/grass64/manuals/html64_user/r.li.simpson.html Simpson] indices. The output is a map for each index.

: '''Author:''' Luca Delucchi, Duccio Rocchini

==== r.eucdist ====

: [http://david.p.finlayson.googlepages.com/r.eucdist r.eucdist] creates a raster map estimating the euclidean distance from known cells.

: '''Author:''' David Finlayson

==== r.fidimo ====

: [http://jradinger.wordpress.com/fidimo/ FIDIMO (r.fidimo)] is a raster tool to model fish dispersal in river networks. Therefore, empirical leptokurtic fish dispersal kernels are used to model movement distances in rasterized river networks, considering movement barriers. FIDIMO allows predicting and simulating spatio-temporal patterns of fish dispersal.

Radinger, J., Kail, J. and Wolter, C. (2013) FIDIMO – A Free and Open Source GIS based dispersal model for riverine fish. ''Ecological Informatics'' 1–10. DOI: [http://dx.doi.org/10.1016/j.ecoinf.2013.06.002 10.1016/j.ecoinf.2013.06.002]

: '''Author:''' Johannes Radinger

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.fidimo

==== r.fill.gaps ====

: Fills small gaps in dense, rasterized datasets. This tool has been optimized for performance, not quality. It uses a simple IDW interpolation with pre-computed spatial weights. Suitable for small interpolation radii. See module's HTML manual page for details and example usage.

: '''Author:''' Benjamin Ducke

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.fill.gaps

==== r.findtheriver ====

: r.findtheriver finds the nearest stream pixel to a coordinate pair using an upstream accumulating area (UAA) raster map. This is necessary because the coordinates for streamflow gages are often not perfectly registered to the topography represented by a digital elevation model (DEM) map. Written in C for GRASS 6.x. For support contact brian_miles@unc.edu

: '''Author:''' Brian Miles

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.findtheriver/

==== r.flip ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.flip r.flip] is a shell script which will flip a raster array's rows north-for-south. The eastern edge remains in the east, and the western edge remains in the west.

: '''Author:''' Hamish Bowman

==== r.forestfrag ====

: GRASS 6 version: [http://dl.dropbox.com/u/10445979/r.forestfrag.sh r.forestfrag.sh] creates forest fragmentation index from a GRASS raster map (where forest=1, non-forest=0) based on a method developed by Riitters et. al (2000). This version only runs on GRASS 6.4 and only with 3x3 moving window (shell-script has to be adjusted for other window-sizes).
: GRASS 7 version: For a version that runs on GRASS 7.0 and which gives the option to choose the size of the moving window size, see [http://grasswiki.osgeo.org/wiki/AddOns/GRASS7/raster#r.forestfrag r.forestfrag for GRASS7.0]
: '''Author:''' Maning Sambale, Stefan Sylla

==== r.fragment ====

: [http://www.chrisgarstin.com/stuff/r.fragment r.fragment] fragments a raster into a user-defined set of smaller tiles according to an input number of rows and columns.
: '''Author:''' Eric Patton

==== r.fuzzy ====
: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.fuzzy r.fuzzy] Calculates membership of every cell in raster according membership function defined by user.
: '''Author:''' Jarek Jasiewicz

==== r.fuzzy.logic ====
: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.fuzzy.logic r.fuzzy.logic] Performs fuzzy operators (AND, OR, NOT, IMP) on membership's map using T-norms and T-conorms for 6 most popular families.
: '''Author:''' Jarek Jasiewicz

==== r.fuzzy.system ====
: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.fuzzy.system r.fuzzy.system] Perform full fuzzy classification with 6 most popular fuzzy logic families and few methods of deffuzification.
: '''Author:''' Jarek Jasiewicz

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.fuzzy.system

==== r.game_of_life ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.game_of_life r.game_of_life] is a shell script which runs Conway's classic Game of Life using GRASS raster modules. It is meant to demonstrate how easy it is to program cellular automata in GRASS as well as various 3D raster volume and time series visualization techniques.

: '''Author:''' Hamish Bowman

==== r.gauss ====

: [http://www.les-ejk.cz/files/programs/grass/r.gauss.tgz r.gauss] is Gaussian and Laplacian of Gaussian filter for GRASS. It is written in C language.

:'''Author:''' Jachym Cepicky

==== r.gradgrid4 ====

: [http://www.uibk.ac.at/geographie/personal/mergili/gradgrid4.zip gradgrid4] is a tool for interpolating values of discrete data points to a raster map, applying a local regression approach with a predictor raster. The model is based on shell and python scripts as well as an R batchfile. It was tested on Fedora Core 6 with GRASS 6.2.1 and R 2.5.1, but should work under most UNIX systems. After unzipping the gradgrid4 folder, store it at any place in your local file system. In the subfolder docs you can find a manual and a publication draft with a detailed description of the concept and the example of an application. The subfolder testloc constitutes a GRASS location with test data.

: '''Author:''' Martin Mergili

==== r.hazard.flood ====

: [http://svn.osgeo.org/grass/grass-addons/grass6/raster/r.hazard.flood/ r.hazard.flood] is an implementation of a fast procedure to detect flood prone areas. The exposure to flooding may be delineated by adopting a topographic index (TIm) computed from a DEM. The portion of a basin exposed to flood inundation is generally characterized by a TIm higher than a given threshold, tau. The threshold is automatically determinated from the cellsize. The proposed procedure may help in the delineation of flood prone areas especially in basins with marked topography. The use of the modified topographic index should not be considered as an alternative to standard hydrological-hydraulic simulations for flood mapping, but it may represent a useful and rapid tool for a preliminary delineation of flooding areas in ungauged basins and in areas where expensive and time consuming hydrological-hydraulic simulations are not affordable or economically convenient.

: '''Author:''' Margherita Di Leo

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.hazard.flood/

==== r.in.ign ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.in.ign/ r.in.ign] imports raster data from [http://api.ign.fr IGN WMTS stream service]. A transitory module, aiming at allowing french wmts support for GRASS 6.4. It is briefly documented [http://grass.osgeo.org/wiki/IGN_wmts_stream here].

: '''Author:''' Vincent Bain

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.in.ign/

==== r.in.mb ====

: [http://www.tekmap.ns.ca/blog/multibeam_import r.in.mb] is a "GRASS/[[MB-System]] program designed to import ''mbio'' compatible multibeam sonar data directly into the GRASS GIS. The program is a modified version of {{cmd|r.in.xyz}}. Instead of reading an ASCII XYZ file, ''r.in.mb'' reads an MB-System compatible list file." It can do automatic reprojection and minor hole filling. Options for restricting data according to line length, speed, acrosstrack width, beam number and survey mode (Simrad only). The default is to import bathymetry data, but optionally amplitude or sidescan sonar data can be loaded instead. GRASS 7 version is also available.

: '''Author:''' Bob Covill

==== r.in.onearth ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.in.onearth r.in.onearth]  for download and import satellite images direct from the NASA OnEarth WMS server into GRASS.

: '''Authors:''' Soeren Gebbert, Markus Neteler, Hamish Bowman

==== r.in.swisstopo ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.in.swisstopo/ r.in.swisstopo] for importing swisstopo digital elevation model data into GRASS raster maps.

: '''Author:''' Jürgen Hansmann

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.in.swisstopo/

==== r.in.wms (.py) ====

: [http://les-ejk.cz/files/programs/grass/r.in.wms.tgz r.in.wms] for download and import maps direct from WMS servers into GRASS. This script is written in Python Programming language. Note GRASS 6.2+ provides a shell script version of r.in.wms, take care of which one is actually being run.

: '''Author:''' Jachym Cepicky

==== r.in.xyz.auto ====

: [https://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.in.xyz.auto r.in.xyz.auto] runs the {{Cmd|r.in.xyz}} module, automatically setting up the region extent for you. ''For useful output it is strongly recommended to manually set the region resolution and bounds yourself instead of using this script.''

: '''Author:''' Hamish Bowman

==== r3.in.xyz ====

: [https://trac.osgeo.org/grass/browser/grass-addons/grass6/raster3d/r3.in.xyz r3.in.xyz] creates a 3D raster map from an assemblage of many coordinates using univariate statistics. It is the 3D version of {{Cmd|r.in.xyz}}.

: '''Author:''' Hamish Bowman

==== r.intersect ====

: [https://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.intersect r.intersect] creates a vector line at the intersection point of two raster maps. For example if a planar trend surface or dynamic flooding level raster map is available this module can create a "bathtub ring" vector line at the intersection of that map and a coincident elevation map.

: '''Author:''' Hamish Bowman

==== r.inund.fluv ====

: [https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.inund.fluv/ r.inund.fluv]This command allows to obtain a fluvial potentially inundation map given a high-resolution DTM of the area surrounding the river and a water surface profile calculated through an 1-D hydrodinamic model.

: '''Authors:''' Roberto Marzocchi, Bianca Federici, Domenico Sguerso

==== r.interp.mask ====

: [http://david.p.finlayson.googlepages.com/r.interp.mask r.interp.mask] Creates a user-specified buffer around interpolation points that can be used as a MASK to prevent or clip excessive extrapolation artifacts. This works much better than a standard convex hull around the points.

: '''Author:''' David Finlayson

==== r.ipso ====

: [http://svn.osgeo.org/grass/grass-addons/grass6/raster/r.ipso/ r.ipso] Produces the ipsometric and ipsographic curve related to a digital elevation model and prints the percentiles

: '''Authors:''' Margherita Di Leo, Massimo Di Stefano, Francesco Di Stefano

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.ipso/

==== r.isoregions ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.isoregions/r.isoregions r.isoregions] allows isoregions creation from a GRASS raster map.

: '''Authors:''' Mathieu Grelier

==== r.li ====

: [http://www.faunalia.it/download/r_li/ r.li] is a more flexible and faster replacement of the old r.le. '''''Moved into 6.3-SVN'''''.

: '''Authors:''' Claudio Porta, Davide Spano, Serena Pallecchi, [http://www.faunalia.it Faunalia]

==== r.local_max.pl ====

: [http://les-ejk.cz/files/programs/local_max.pl Local maxima] is a Perl script for <code>r.mapcalc</code>. It detects local maxima of the image.

: '''Author:''' Jachym Cepicky

==== r.mandelbrot ====

: [http://grasslab.gisix.com/scripts/r.mandelbrot r.mandelbrot] is a shell script to calculate the Mandelbrot set.- for GRASS versions 6.X.

: '''Author:''' Peter Löwe

==== r.maxent.lambdas ====

: [http://svn.osgeo.org/grass/grass-addons/grass6/raster/r.maxent.lambdas r.maxent.lambdas] is a shell script to compute raw and/or logistic prediction maps from a lambdas file produced with MaxEnt 3.3.3e. See also [[#r.out.maxent_swd]]

: '''Author:''' Stefan Blumentrath, [http://www.nina.no NINA]

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.maxent.lambdas/

==== mcda ====

: mcda suite is a toolset for geographics multi-criteria decision aiding and data analysis based on ELECTRE (r.mcda.electre), REGIME (r.mcda.regime) and FUZZY (r.mcda.fuzzy) algorithm. The module r.roughset is also included for geographics rough set analisys and knowledge discovery based on rough set library. It is written in C language for GRASS versions 6.X.

: '''Author:''' Gianluca Massei (g_massa@libero.it ) - Antonio Boggia

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.mcda.ahp/
svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.mcda.electre/
svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.mcda.fuzzy/
svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.mcda.roughset/
svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.mcda.regime/

==== r.mess ====

:The '''r.mess''' function computes the "Multivariate Environmental Similarity Surfaces" (MESS). It uses R and spgrass6 package

: '''Author:''' Paulo van Breugel

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.mess/

==== r.mlv ====

: [http://les-ejk.cz/files/programs/grass/r.mlv.tgz r.mlv] is Mean of least variance filter for GRASS. It is an edge-preserving (or even edge-enhacing) filter, which should serve for removing additive noise from images. It is written in C language.

: '''Author:''' Jachym Cepicky

==== r.niche.similarity ====

:The '''r.niche.similarity''' function computes two metrics to quantify niche similarity or overlap between all pairs of input raster layers: (D) the niche equivalency or similarity for two species following Warren et al. (2009) based on Schoeners D (Schoener, 1968). This metric ranges from 0 to 1, representing respectively no overlap and an identical distribution; (I) I similarity statistic of Warren et al. (2009), which is based on Hellinger Distances (van der Vaart, 1998).

: '''Author:''' Paulo van Breugel

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.niche.similarity/

==== r.obstruction, r.planning.static, r.planning.cinematic ====

: [http://www.ing.unitn.it/~grass/software.html r.obstruction, r.planning.static, r.planning.cinematic]: r.obstruction creates a polar obstruction map from a DTM. r.planning.static performs a static planning for GPS and Glonass surveys using the obstruction map created with r.obstruction. r.planning.cinematic performs a cinematic planning for GPS and Glonass surveys. (University of Trento, Faculty of Engineering)

: '''Author:''' Daniele Carli, Dimitri D'Inca', Gianluca Fruet, Domenico Sguerso, Paolo Zatelli

==== r.out.colorbar ====

: [http://tekmap.ns.ca/blog/colorbar_out r.out.colorbar] is an export program for saving GRASS raster colorbars to an image. The program uses GTK+ and cairographics. Supported export formats are PNG, PDF, and EPS.

: '''Author:''' Bob Covill

==== r.out.jpeg ====

: [http://www.geospatial.it/allegri/grass/r.out.jpeg_ r.out.jpeg] is a simple GRASS script to export georeferenced JPEG images from rasters, keeping the associated color table. It is a two-step export: first a ppm file is created, then it is converted to jpeg usgin the "convert" command from ImageMagick

: '''Author:''' Giovanni Allegri

==== r.out.geoserver ====

: [http://www.wgug.org/index.php?option=com_content&view=article&id=56&Itemid=9 r.out.geoserver] exports GRASS raster layer to [http://geoserver.org GeoServer] and publishes it using WMS. The modul is a shell script. It uses: r.out.gdal, curl, xmlstarlet and GeoServer REST interface.

: '''Author:''' Pawel Netzel

==== r.out.gmap ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.out.gmap r.out.gmap] outputs GRASS raster map into set of image tiles
following the tiling scheme of Google Maps and Microsoft Virtual Earth. Read more in the OSGeo Journal [http://www.osgeo.org/journal Volume 5 (2009, to appear)] see also [[#r.out.kml|r.out.kml]] and [[#v.out.kml|v.out.kml]]

: '''Author:''' Tomas Cebecauer

==== r.out.gmt ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.out.gmt r.out.gmt] is a GRASS script for exporting a GRASS raster map into a [http://www.soest.hawaii.edu/gmt/ GMT] grid file. It also creates a GMT color table from the data and can generate some GMT commands for plotting a postscript file. (code is experimental, but functional) see also http://169.237.35.250/~dylan/grass_user_group/#GMT_and_GRASS-overview

: '''Authors:''' Hamish Bowman, Dylan Beaudette

==== r.out.gmt2 ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.out.gmt2 r.out.gmt2] is a modified version of Hamish's r.out.gmt. Added options for title, xlabel, ylabel, comment, and map width. Removed any settings that can be changed by gmtset for more flexibility.

: '''Author:''' Huidae Cho, Hamish Bowman, Dylan Beaudette

==== r.out.kap_template ====

: [https://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.out.kap_template r.out.kap_template] is a shell script that exports a raster map into a GeoTiff and a metadata text file suitable for use with KAP (BSB) raster nautical chart converter programs such as <tt>tif2bsb</tt> (after verifying that you are legally entitled to use such a tool).
: '''''This is EXPERIMENTAL software. NOT FOR NAVIGATIONAL USE.'''''
: For an easy to use data viewer, see also the [http://www.opencpn.org OpenCPN] free navigational software.

: '''Author:''' Hamish Bowman

==== r.out.kml ====

: [https://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.out.kml r.out.kml] is a shell script that exports a raster map into a KML file and image for Google Earth or Worldwind. See also [[#v.out.kml|v.out.kml]] and [[#r.out.gmap|r.out.gmap]].

: '''Author:''' Hamish Bowman

==== r.out.maxent_swd ====

: [http://svn.osgeo.org/grass/grass-addons/grass6/raster/r.out.maxent_swd r.out.maxent_swd] is a shell script to produce a set of SWD files as input to MaxEnt 3.3.3e using r.stats. See also [[#r.maxent.lambdas]]

: '''Author:''' Stefan Blumentrath, [http://www.nina.no NINA]

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.out.maxent_swd/

==== r.out.mbtiles ====
: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.out.mbtiles r.out.mbtiles] is a script which will create a TMS tileset tree and support files suitable for processing into an MBTiles SQLite database. Zoom levels can be manually set or automatically determined from the data. Empty tiles and unneeded files are automatically prunded, and at the user's choice tiles can be converted to JPEG format. You can create just the TMS tile tree or build the full MBTiles SQLite database.

: '''Author:''' Hamish Bowman

==== r.pack ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.pack r.pack] and [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.unpack r.unpack] are two GRASS scripts for transferring raster maps to another computer as a single compressed file including color table etc.
: An earlier version has been renamed as [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.pack/experiment r.pack.mat] and [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.unpack/experiment r.unpack.mat].

: '''Author:''' Hamish Bowman

==== r.patch.many ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.patch.many r.patch.many] is a shell script which will run {{Cmd|r.patch}} in parallel, to speed up cases where there the number of input maps is very large.

: '''Author:''' Hamish Bowman

==== r.pastro ====

: [https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.pastro/ r.pastro]
Tools for the management of mobility in the mountain environment

: '''Authors:''' Andrea Cervetto, Damiano Natali, Tiziano Cosso, Roberto Marzocchi

==== r.pi ====

: [https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.pi/ r.pi] (raster patch index) provides various functions to analyse spatial attributes of a landscape. It has a focus on patch-based indices but delivers class-based indices as well. r.le and its successor r.li provide landscape indices.

: '''Authors:''' Programming: Elshad Shirinov, Scientific concept: Dr. Martin Wegmann

==== r.prominence ====

: '''r.prominence''' calculates the average difference between a central cell and its neighbors. It approximated the terrain 'ruggedness' by looking at average differences in elevation within a given neighborhood.

: '''Author:''' Benjamin Ducke

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.prominence/

==== r.rdfilter ====

: [http://jradinger.wordpress.com/software/ r.rdfilter] computes a new raster map based on the application of a focal filter on the input raster map. Thus each cell value depends on the values of adjacent cells. Instead of the “moving window”-algorithm (e.g. {{cmd|r.neighbors}}), r.rdfilter is a “real distance”-filter based on GRASS’ {{cmd|r.cost}} tool.

: '''Author:''' Johannes Radinger

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.rdfilter

==== r.refine ====

: [http://www.bowdoin.edu/~ltoma/research.html r.refine]: reduces a DEM to a TIN (takes as input a grid DEM and an error margin and simplifies it to the desired accuracy into a TIN)
Available via the source code repository [https://github.com/jonrtodd/r.refine]
: '''Authors:''' Laura Toma and Jonathan Todd

==== r.rifs ====

: [http://www.ucl.ac.uk/~tcrnmar/ r.rifs]: r.rifs generates a raster map and/or image of a fractal by means of the specified random iterated function system.

: '''Author:''' Mark Lake

==== r.rot90 ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.rot90 r.rot90] is a shell script which will rotate a raster array by 90 degrees clockwise.

: '''Author:''' Hamish Bowman

==== r.roughness ====

[http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.roughness/r.roughness.sh r.roughness.sh] is a shell script to calculate the surface roughness of a DEM, using r.surf.area and v.surf.rst. (for GRASS versions 6.1 and above)

[http://www.igc.usp.br/pessoais/guano/downloads/r.roughness60 r.roughness60] - for GRASS versions 6.0.X

[http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.roughness/r.roughness.window.area r.roughness.window.area] - calculate surface roughness as the ratio of real (surface) area and planar area, using a moving-window approach.

[http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.roughness/r.roughness.window.vector r.roughness.window.vector] - calculate surface roughness as vector dispersion, using a moving-window approach. Resulting maps are: Vector Strength (R) and Inverted Fisher's k parameter.

[http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.roughness/r.roughness.window.vector.html r.roughness.window.vector.html] - provisional help page for r.roughness.window.vector.

: '''Author:''' Carlos Henrique Grohmann

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.roughness/

==== r.roughset ====

: r.roughset is a module for geographics rough set analisys and knowledge discovery based on rough set library. It is written in C language for GRASS versions 6.X.

: '''Author:''' Gianluca Massei (g_massa@libero.it ) - Antonio Boggia

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/mcda/r.roughset/

==== r.seg ====

: '''r.seg''' performs image segmentation and discontinuity detection (based on the Mumford-Shah variational model).
: The module generates a piece-wise smooth approximation of the input raster map and a raster map of the discontinuities of the output approximation. The discontinuities of the output approximation are preserved from being smoothed.
: See [http://www.ing.unitn.it/~vittia/sw here] for details and examples.

Available [http://www.ing.unitn.it/~vittia/sw here] and with improvements via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.seg/

: '''Author''' Alfonso Vitti

==== r.smoothpatch ====

: [http://david.p.finlayson.googlepages.com/r.smoothpatch r.smoothpatch] creates a composite of two rasters using a distance-weighted average across the transition to smooth the edges.

: '''Author:''' David Finlayson

==== r.soils.texture ====

: r.soils.texture is a module to define soils texture from sand and clay raster file with a schema text file (now FAO,USDA and ISSS are available). It is written in C language. - for GRASS versions 6.x - For bugs and suggest: g_massa@libero.it

:'''Author:''' Gianluca Massei

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.soils.texture/

====r.split.line====

: [https://raw.github.com/amuriy/GRASS-scripts/master/r.split.line r.split.line] is a shell script to split raster into parts with vector line(s).

:'''Author:''' Alexander Muriy

==== r.stack ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.stack r.stack] is a shell script used to patch all the raster maps in a time series (or burst 3D raster) together into a vertical stack, to aid multi-map analyses in modules where group input is not yet available.

: '''Author:''' Hamish Bowman

==== r.stream.angle ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.stream.angle r.stream.angle] Divide stream network into straight line segments according users input. The module uses as input direction and stream network map produced by r.watershed and stream.extract or custom user input. See description for details.

: '''Author:''' Jarek Jasiewicz

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.stream.angle

==== r.stream.basins ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.stream.basins r.stream.basins] delineate basins according users input. It extends r.water.outlet funcionality to extracting more than one basin at one step. Module uses as input direction map produced stream network produced by r.stream.extract, r.watershed, r.stream.order or custom user input. See also [[R.stream.*]].

: '''Author:''' Jarek Jasiewicz

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.stream.basins

==== r.stream.del ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.stream.del r.stream.del] Calculates downslope length of first order streams and delete them if it length (in pixels) is lower than the treeshold. It also join false segments left by deletion into one with category of upper. It uses r.watershed direction map and r.watershed stream map as input. The module is added only for r.watershed module, r.stream.extract has deleting of short streams build-in. During development of r.stream.* it will be probably abandoned due to duplicate functionality.

: '''Author:''' Jarek Jasiewicz

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.stream.del

==== r.stream.distance ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.stream.distance r.stream.distance] Calculates downslope distance and downslope elevation difference between current cell and stream or outlet cells. It uses r.watershed direction map, r.watershed or r.stream.extract stream map and optionally DEM as input. See also [[R.stream.*]].

: '''Author:''' Jarek Jasiewicz

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.stream.distance

==== r.stream.extract ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.stream.extract r.stream.extract] extracts topologically clean stream networks from input elevation and optionally accumulation maps. Output is available as raster and vector and can be used as input for the other r.stream.* modules by Jarek Jasiewicz.

: '''Author:''' Markus Metz

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.stream.extract

==== r.stream.order ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.stream.order r.stream.order] orders stream network outputed by r.watershed or r.stream.extract according Strahler, Shreve, Horton and Hack ordering systems. It require as input stream and direction map and optionally accumulation map. It handle both SFD and MFD modes but all data must have been produced with the same procedure. See also [[R.stream.*]].

: '''Author:''' Jarek Jasiewicz, Markus Metz

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.stream.order

==== r.stream.pos ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.stream.pos r.stream.pos] Helper module for calculating local stream network properties and linear geostatistics. Mostly To use with R and other GRASS modules.

: '''Author:''' Jarek Jasiewicz

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.stream.pos

==== r.stream.preview ====

: In order to find a value of upslope area to be used as input to extract the river network using r.stream.extract or r.watershed, it is common to proceed by trial and error. [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.stream.preview r.stream.preview] is useful for quickly display results for various tentatives of threshold values.

: '''Author:''' Margherita Di Leo

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.stream.preview/

==== r.stream.stats ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.stream.stats r.stream.stats] calculate Hortonian statistics for Strahler or Horton stream network created by r.stream.order. It uses r.watershed direction map, DEM and r.stream.order's Strahler or Horton stream network as input. It outputs calculated statistics to standard output. See also [[R.stream.*]].

: '''Author:''' Jarek Jasiewicz

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.stream.stats

==== r.surf.nnbathy ====

: GRASS Bourne shell script wrapper for `nnbathy', a raster interpolation utility providing triangulation, natural neighbor and non-Sibsonian natural neighbor algorithms, of Pavel Sakov's [http://code.google.com/p/nn-c/ nn] natural neighbor interpolation library.

: Available via [http://grass.osgeo.org/grass64/manuals/g.extension.html g.extension] or [https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.surf.nnbathy/ SVN].

: '''Author:''' Maciej Sieczka

==== r.surf.volcano ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.surf.volcano r.surf.volcano] creates an artificial surface resembling a seamount or cone volcano. The user can alter the size and shape of the mountain and optionally roughen its surface. Available decay functions are polynomial, Gaussian, Lorentzian, logarithmic, and exponential.

: '''Author:''' Hamish Bowman

==== r.terracost ====

[http://www.bowdoin.edu/~ltoma/research.html r.terracost] Scalable approach for computing least-cost-path surfaces on massive grid terrains. '''Lead author''': Laura Toma

Available via SVN or {{cmd|g.extension}}:
svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.terracost

==== r.threshold ====

[http://svn.osgeo.org/grass/grass-addons/grass6/raster/r.threshold/ r.threshold] Finds a first tentative value of upslope area to be used as input to extract the river network using r.stream.extract or r.watershed.

Available via SVN or {{cmd|g.extension}}:
svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.threshold

==== r.tileset ====

: ''{{cmd|r.tileset}} moved into main archive''

==== r.to.vect.lines ====

: [https://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.to.vect.lines r.to.vect.lines] is a module to sample raster rows at regular intervals and turn them into 3D lines. e.g. to display in [[NVIZ]] as a wiggle plot.
: It demonstrates the use of [[Python_Ctypes_Examples|ctypes]] to access the GRASS C libraries from within a Python script. (treat as a work in progress)

: '''Author:''' Hamish Bowman

==== r.traveltime ====

: [http://jesbergwetter.twoday.net/stories/4845555/ r.traveltime] computes the travel time of surface runoff to an outlet. The program starts at the basin outlet and calculates the travel time at each raster cell recursively. A drainage area related threhold considers even surface and also channel runoff. Travel times are derived by assuming kinematic wave approximation. The results can be used to derive a time-area function. This might be usefull for precipitation-runoff calculations (estimation of flood predictions) with a lumped hydrologic model (user-specified unit hydrograph).

: '''Author:''' Kristian Förster

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.traveltime

==== r.univar.zonal ====

Note: This addon is only needed for GRASS 6.3, its functionality has been added to r.univar in 6.4+ and 7.

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.univar.zonal r.univar.zonal] is similar to {{cmd|r.univar}}, but calculates statistics separately for each category(zone) present in the separate input map used to define zones (zonal statistics). The output can be like the one of r.univar or in easier to read table format and can be written to a file.

: '''Author:''' Markus Metz

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.univar.zonal

==== r.viewshed ====

: r.viewshed is a module for extremely fast line of sight analysis (replaces the slow r.los). It is written in C language for GRASS versions 6.X/7.x.

: '''Author:''' Laura Toma, USA

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.viewshed

Once {{trac|390}} is solved, it will substitute r.los.

==== r.wavelets ====

: [http://www.ing.unitn.it/~grass/software.html r.wavelets]: This package contains wavelets decomposition and reconstruction modules for the GRASS GIS: r.owave.dec computes the orthogonal wavelet transform of a raster map. r.owave.rec reconstructs a raster map from an orthogonal wavelet transform. r.biowave.dec computes the biorthogonal wavelet transform of a raster map. r.biowave.rec reconstructs a raster map from a biorthogonal wavelet transform.

: '''Authors:''' Members of the University of Trento, Faculty of Engineering

==== r.wf ====

: [http://svn.osgeo.org/grass/grass-addons/grass6/raster/r.wf/ r.wf] produces the Width Function of a basin. The Width Function W(x) gives the number of the cells in a basin at a flow distance x from the outlet (it is also referred as distance-area function). The distance is not the euclidean one, but it is measured along the flowpath towards the outlet.

: '''Authors:''' Margherita Di Leo, Massimo Di Stefano, Francesco Di Stefano

Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.wf/

==== r.wind.sun ====

: [https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.wind.sun/description.html r.wind.sun] Calculates visual impact (raster map) of aerogenerators and photovoltaic panels using an impact factor, based on the area covered by windfarm and panels respect the area of Human Field of View.

:'''Author:''' Annalisa Minelli, Ivan Marchesini

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.wind.sun/r.wind.sun.py

==== r.xtent ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.xtent r.xtent] computes a raster map layer representing the Voronoi diagram, weighted Voronoi diagram or a more complex territorial partitioning of space around points (centers) in a vector input map, based on the XTENT formula.

:'''Author:''' Benjamin Ducke

svn co https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.xtent

==== r.zc.pl ====

: [http://les-ejk.cz/files/programs/zc.pl Zero crossing] is a simple Perl script, finds the ,,zero crossings`` from the Laplacian of Gaussian filter (see above). It is really very simple, the edges don't need to be really on that pixel, where they are detected, no interpolation is performed.

: '''Author:''' Jachym Cepicky

==== GIPE ====

: The GRASS Image Processing Environment (GIPE) has USLE, Energy-balance and radiance-reflectance correction models.

: '''Author:''' Yann Chemin (unless specified otherwise).

svn co https://svn.osgeo.org/grass/grass-addons/grass6/imagery/gipe

Remark: This is progressively moved to main GRASS SVN (aka GRASS 7)

:* r.hydro.CASC2D, ported from GRASS 5.x version, is temporarily here waiting to return to main GRASS.

:* r.soiltex2prop creates porosity, Saturated Hydraulic conductivity (Ksat) and wetting front pressure head (Hf) from percentage of sand and clay after Rawls et al., 1990. This is a must for r.hydro.CASC2D.

:* i.biomass creates biomass growth map from fPAR, lightuse efficiency, water availability (or evap.fraction), Lat, doy and tsw.

:* i.dn2ref.l7, r.dn2ref.ast create top of atmosphere reflectance for Landsat 7ETM+ and ASTER. These modules also have a flag for radiance output. Updated i.dn2ref.l7 to read .met calibration file.

:* i.dn2full.l[5,7] is an attempt to get all bands of Landsat[5,7] calibrated and corrected to either reflectance or temperature, reads only the .met file.

:* i.dn2potrad.l[5,7] is an attempt to get ET potential from DN of Landsat 7 (Careful! No Atmospheric correction!).

:* i.eb.* are a set of 10+ GRASS modules that together perform the main functions of the SEBAL model (Bastiaanssen, 1995). Those functions include (but are not limited to) Soil heat flux, sensible heat flux, net radiation, evaporative fraction at satellite overpass, diurnal actual evapotranspiration, momentum roughness length, etc. These modules are also part of any Energy-Balance related processing.

:* i.evapo.potrad creates diurnal Potential evapotranspiration assuming all net radiation becomes ET, according to SEBAL model (Bastiaanssen, 1995). This module also has a flag for diurnal net radiation as required by SEBAL in i.eb.eta.

:* i.evapo.SENAY creates actual evapotranspiration following the regional method of Senay (2007).

:* i.lmf creates a Local Maximum Fitting on the temporal dimension of the multi-date input dataset, working, but more precision still to be added.

:* i.vi.mpi is the mpi version of i.vi for cluster GRASS GIS education (no speed up here!) '''Author:''' Shamim Akhter

:* i.modis.stateqa extracts State Quality Assessment information from Modis 500m (MOD09A) products.

:* i.water creates a Water Mask from NDVI and Albedo, or specifically for Modis: NDVI and Band 7.

:* i.wi creates a given Water Index (only one so far).

==== HydroFOSS ====

: HydroFOSS - a GIS embedded approach for Free & Open Source Hydrological modeling.

: '''Author:''' Massimiliano Cannata

svn co https://svn.osgeo.org/grass/grass-addons/grass6/HydroFOSS/

==== Hikereport ====

: python script that computes length, cumulative uphill and downhill, average slopes on an interactively drawn path. Based on r.profile's output.

: '''Author:''' Stefano Negri

http://tracce.wordpress.com/?attachment_id=71

=== Misc add-ons===

==== m.eigensystem ====

m.eigensystem - Computes eigen values and eigen vectors for square matrices.

: http://svn.osgeo.org/grass/grass-addons/grass6/misc/m.eigensystem/

: '''Author:''' Michael Shapiro

===Database add-ons===
==== db.join ====

: Table joining: join one table into another through common attributes

: '''Author:''' Markus Neteler. Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/database/db.join/
or
g.extension db.join

===General add-ons===

==== Compare GRASS maps ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass7/general/g.compare.md5 g.compare.md5] Script to check if two GRASS maps are identical

: '''Author:''' Luca Delucchi

==== GRASS create location scripts ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/general/grass_create_location grass_create_location.sh] Script to generate a new GRASS location from GIS file (e.g. geoTIFF or SHAPE), wktfile or EPSG code.

: '''Author:''' Markus Neteler

==== g.infer ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/general/g.infer g.infer] is a tool to create rule-based data-driven workflows from GRASS data layers and additional data sources. g.infer can modify existing GRASS data layers, can create new vector layers or can start additional additional GRASS modules. This is controlled by an inference process, which applies a knowledge base on a set of known facts (data). g.infer allows to set up Expert Systems from domain knowledge and GIS data layers.

: '''Author:''' Peter Löwe

==== g.laptop.sh ====

: [http://www.gbd-consult.de/dassau/grass/g.laptop/g.laptop.sh g.laptop.sh] is an interactive shell script to extract raster and vector data from current Location into a new one. Data can be copied or extracted in current or original resolution and region extend. This script was written to extract smaller parts of a GRASS location to be able to present them on a laptop without the necessity to transfer huge data. Maps do not have to be in the same mapset.

: '''Author:''' Otto Dassau

==== Readline completion ====

: '''''Readline completion''''' for GRASS commands under the bash shell: [http://www.sorokine.info/grass-complete/ grass-complete] won't clutter the environment but needs to be installed; [http://dcalvelo.free.fr/grass/grass_rlcompleter.sh grass_rlcompleter.sh] needs almost no installation but will pollute the environment. Grass-Complete currently requires Bash version 2.05 for proper install.

: '''Author:''' Alexandre Sorokine (grass-complete), Daniel Calvelo (grass_rlcompleter.sh)

==== g.name.sequence ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/general/g.name.sequence g.name.sequence] is a shell script which can print to <tt>stdout</tt> a sequential series of map names for use with modules like {{cmd|r.series}}. It is a wrapper around the UNIX <tt>seq</tt> power tool.

: '''Author:''' Hamish Bowman

==== g.region.grow ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/general/g.region.grow g.region.grow] is a shell script which expands or contracts the computational region by a fixed amount. It's a shortcut for "<tt>g.region n=n+X s=s-X e=e+X w=w-X</tt>".

: '''Author:''' Hamish Bowman

==== g.region.point ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/general/g.region.point g.region.point] is a shell script which resets the computational region to a square box around a given coordinate. It is intended for use within GRASS scripts to speed up processing by limiting expensive raster calculations to a small area of interest.

: '''Author:''' Hamish Bowman

==== g.linke_by_day ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.sun.tools/ g.linke_by_day] is a python script for [[r.sun]] which interpolates a Linke turbidity value for a given day of the year based on monthly values edited into the script.

: '''Author:''' Hamish Bowman

==== g.xlist ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/general/g.xlist g.xlist] is a C implementation of g.mlist. g.xlist searches for data files matching a pattern given by wildcards or POSIX Extended Regular Expressions. POSIX regex(3) functions are required.

: '''Author:''' Huidae Cho

==== g.xremove ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/general/g.xremove g.xremove] is a C implementation of g.mremove. g.xremove removes data files matching a pattern given by wildcards or POSIX Extended Regular Expressions. POSIX regex(3) functions are required.

: '''Author:''' Huidae Cho

==== g.region.ll ====

: [https://bitbucket.org/afrigeri/grass-addons g.region.ll] sets the region in a projected location using longitudes and latitudes.

: '''Author:''' Alessandro Frigeri

=== Imagery add-ons ===

See also

svn co https://svn.osgeo.org/grass/grass-addons/grass6/imagery

==== GIPE ====

GIPE (see also above in raster section) provides:
i.biomass, i.dn2potrad.l5, i.dn2potrad.l7, i.dn2ref.ast, i.eb.deltat, i.eb.disp, i.eb.eta, i.eb.evapfr, i.eb.g0, i.eb.h0, i.eb.h_SEBAL01, i.eb.h_SEBAL95, i.eb.h_iter, i.eb.molength, i.eb.netrad, i.eb.psi, i.eb.rah, i.eb.rohair, i.eb.ublend, i.eb.ustar, i.eb.wetdrypix, i.eb.z0m, i.eb.z0m0, i.evapo.PT, i.evapo.TSA, i.evapo.potrad, i.evapo.senay, i.evapo.time_integration, i.lmf, i.modis.stateqa, i.sattime, i.vi.grid, i.vi.mpi, i.water, i.wi

svn co https://svn.osgeo.org/grass/grass-addons/gipe/

: '''Author:''' Yann Chemin

==== i.despeckle ====

Applies SAR Speckle Filter to a raster power map. Currently LEE, KUAN, Enhanced Lee and GAMMA filter are implemented.

g.extension i.despeckle

==== i.homography ====

Rectifies an image by computing a coordinate transformation for each pixel in the image based on the control points created by i.linespoints. The approach uses homography extended for corresponding lines.

svn co https://svn.osgeo.org/grass/grass-addons/grass6/imagery/i.homography

: '''Author:''' Daniel Grasso, Bolzano, Italy, based on code written by Stefano Merler, ITC-irst, Italy
: '''Reference:''' M. Neteler, D. Grasso, I. Michelazzi, L. Miori, S. Merler, and C. Furlanello, 2005: An integrated toolbox for image registration, fusion and classification. International Journal of Geoinformatics, 1(1), pp. 51-61 [http://www.grassbook.org/neteler/papers/neteler2005_IJG_051-061_draft.pdf PDF]

==== i.linespoints ====

An imagery command that enables the user to mark coordinate system points as well as lines on an image to be rectified and then input the coordinates of each point for creation of a coordinate transformation matrix. The transformation matrix is needed as input for the GRASS program i.homography.

svn co https://svn.osgeo.org/grass/grass-addons/grass6/imagery/i.linespoints

: '''Author:''' Daniel Grasso, Bolzano, Italy, based on i.points

==== i.landsat.dehaze ====

Bandwise haze correction using tasscap4 (haze) and linear regression of a Landsat scene.

svn co https://svn.osgeo.org/grass/grass-addons/grass6/imagery/i.landsat.dehaze

: '''Author:''' Markus Neteler

==== i.landsat.toar ====

Transform calibrated digital number of Landsat products to top-of-atmosphere radiance or top-of-atmosphere reflectance and temperature (band 6 of the sensors TM and ETM+). Optionally, used to calculate the at-surface radiance or reflectance with atmospheric correction (DOS method).

--> moved to core GRASS (>= 6.4.2), see {{cmd|i.landsat.toar}}

: '''Author:''' E. Jorge Tizado

==== i.landsat.acca ====

Implements the Automated Cloud-Cover Assessment (ACCA) Algorithm from Irish (2000) with the constant values for pass filter one from Irish et al. (2006). To do this, it needs Landsat band numbers 2, 3, 4, 5, and 6 (or band 61 for Landsat-7 ETM+) which have already been processed from DN into reflectance and band-6 temperature with i.landsat.toar).

--> moved to core GRASS (>= 6.4.2), see {{cmd|i.landsat.acca}}

: '''Author:''' E. Jorge Tizado

==== i.landsat.trim ====

: [https://raw.github.com/amuriy/GRASS-scripts/72f039073ff55b006b7aecbaa7870fac193dd9b3/i.landsat.trim i.landsat.trim] is a shell-script for GRASS 6.4.*, that trims the "fringe" from the borders of Landsat images, for each band separately or with the MASK where coverage exists for all bands. Optionally saves vector footprints of trimmed rasters and MASK. Works with Landsat 5, Landsat 7 (SLC-on).

: '''Author:''' Alexander Muriy

==== i.points.auto ====

This module allows a search of GCP's on two raster-maps with differents levels of automation. The ''manual'' search is the default search, so it's possible to determine the GCP's manually with the mouse (like {{cmd|i.points}}). ''Semiautomated'' search: The user determines with the mouse some correspondent areas (with a discrete precision) in the two maps and the module searches itself the GCP's in these areas. ''Automated'' search: At the start of module the user has to load the maps that the algorithm uses to the search, so it is recommended to use the maps filtered with the filters DIVERSITY or STDDEV (of GRASS) with a window of 3x3 or 5x5 pixels. However, the algorithm sometimes works well with the original maps too.

Note: This code is basically an improved i.points (from 2004). Subsequent changes in i.points haven's been ported here yet.

svn co https://svn.osgeo.org/grass/grass-addons/grass6/imagery/i.points.auto

: '''Authors:''' based on i.points; additions by Ivan Michelazzi, Luca Miori (MSc theses at ITC-irst); Supervisors: Markus Neteler, Stefano Merler, ITC-irst 2003, 2004. [http://gisws.media.osaka-cu.ac.jp/grass04/viewpaper.php?id=37 PDF article]

==== i.points.reproj ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/imagery/i.points.reproj i.points.reproj] is a shell script that will use cs2cs to reproject the target coordinates of a group's POINTS file. By running i.rectify directly to the new target projection, a generation of resampling data loss can be avoided (versus i.rectify + r.proj). On the other hand, i.rectify does not calculate cell resolution well if the map is to be rotated ([http://intevation.de/rt/webrt?serial_num=3296 bug #3296]), in those cases i.rectify+r.proj may be the better option.

: '''Author:''' Hamish Bowman

==== i.plr.py ====

: [[I.plr.py|Probabilistic Label Relaxation]], written in Python

: '''Author:''' Georg Kaspar

==== i.pr ====

: Image classification: implements k-NN (multiclass), classification trees (multiclass), maximum likelihood (multiclass), Support Vector Machines (binary), bagging versions of all the base classifiers, AdaBoost for binary trees and support vector machines. It allows feature manipulation (normalization, principal components,...). It also implements feature selection techniques (RFE, E-RFE,...), statistical tests on variables, tools for resampling (cross-validation and bootstrap) and cost-sensitive techniques for trees and support vector machines.

: '''Author:''' Stefano Merler. Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/imagery/i.pr

==== i.spec.sam ====

: Spectral Angle mapping

: '''Author:''' Markus Neteler. Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/imagery/i.spec.sam/

==== i.spec.unmix ====

: Spectral unmixing

: '''Author:''' Markus Neteler. Available via SVN or {{cmd|g.extension}}:

svn co https://svn.osgeo.org/grass/grass-addons/grass6/imagery/i.spec.unmix/

==== i.topo.corr ====
: i.topo.corr is used to topographically correct reflectance from imagery files, e.g. obtained with i.landsat.toar (see above), using a sun illumination terrain model. This illumination model represents the cosine of the incident angle, i.e. the angle between the normal to the ground and the sun rays. It can be obtained with {{cmd|r.sun}} (parameter incidout), and then calculating its cosine with float precision. Correction methods: cosine, minnaert, percent, c-factor.

--> moved to core GRASS (>= 6.4.2), see {{cmd|i.topo.corr}}

: '''Author:''' E. Jorge Tizado

==== i.warp ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/imagery/i.warp i.warp] is a shell script that will use gdalwarp to rectify a raw input image using thin plate splines. The map should be imported into GRASS with r.in.gdal and GCPs set with i.points. Input is the raw image (GeoTIFF, JPEG, etc). Output is a GeoTIFF in the imagery group's target location's map projection. Requires a recent (early 2006) version of GRASS 6.1, or newer.

: '''Author:''' Hamish Bowman

=== Display add-ons ===

See also

svn co http://svn.osgeo.org/grass/grass-addons/grass6/display

==== d.anaglyph ====

[http://trac.osgeo.org/grass/browser/grass-addons/grass6/display/d.anaglyph d.anaglyph] is a module that will render [[Stereo_anaglyphs|stereographic anaglyph]] images in PNG format suitable for use with red/cyan glasses.

: '''Author:''' Hamish Bowman

==== d.barb ====

[http://trac.osgeo.org/grass/browser/grass-addons/grass6/display/d.barb d.barb] is a C module that will draw wind barbs, straw plots, and arrow plots from raster array or sparse vector point data. It can use either direction + magnitude, or u + v components as the input, and can produce a legend key. (''work in progress, but it's mostly there'')

: '''Author:''' Hamish Bowman

Example: [http://bambi.otago.ac.nz/hamish/grass/screenshots/narr-a_221_20100629_1800_000_10m_winds.png Screenshot]

==== d.edit.rast ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/display/d.edit.rast d.edit.rast] edits cells in an existing raster map displayed on the current monitor.

: '''Author:''' Huidae Cho

==== d.frame.quarter ====

: ('''obsolete''') [http://trac.osgeo.org/grass/browser/grass-addons/grass6/display/d.frame.split d.frame.quarter] is a shell script that will split the display into four quadrants (or sixths) using ''d.frame''. Individual frames are named ''uno, dos, tres, cuatro'', and ''full_screen''.
: Replaced by {{cmd|d.split.frame}} in main.

: '''Author:''' Hamish Bowman

==== d.frame.split ====

: ''d.frame.split moved into main archive as {{cmd|d.split.frame}}''

==== d.frontline ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/display/d.frontline d.frontline] is a shell script that draws frontlines on the graphics monitor using ''d.graph'' module and different types of symbols. Also it optionally saves frontline graphics to ''d.graph'' commands file and/or ''ps.map'' file (for later use with the "read" ''ps.map'' instruction)

: '''Author:''' Alexander Muriy

==== d.hyperlink ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/display/d.hyperlink d.hyperlink] is an interactive shell script that allows the viewing of hyperlinked images from a vector's attribute table in an external image viewer. Queries can be made via SQL statements or interactive mouse-clicking. The attribute table must be pre-populated with a column containing the image to link the vector to; the user also specifies the image folder in the current MAPSET where the images are located. The script currently supports gimp, Eye of Gnome, gthumb, gpdf, and Inkscape image viewers.

: '''Author: '''Eric Patton

==== d.mark ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/display/d.mark d.mark] is a shell script that quickly displays a marker on the display at a given coordinate.

: '''Author:''' Hamish Bowman

==== d.region.box ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/display/d.region.box d.region.box] is a shell script that quickly displays a box around the current region.

: '''Author:''' Hamish Bowman

==== d.stations ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/display/d.shortcuts d.stations] is a shell script that quickly displays vector points (or sites for GRASS 5.4 and below).

: '''Author:''' Hamish Bowman

==== d.varea ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/display/d.shortcuts d.varea] is a shell script that quickly displays vector areas.

: '''Author:''' Hamish Bowman

==== d.zoom.keys ====

[https://raw.github.com/amuriy/GRASS-scripts/master/d.zoom.keys d.zoom.keys] is a shell (+awk) script that allows to change the current geographic region settings interactively, with a keyboard. Can use navigation in X-monitor (requires <xev> and <xdotool>) or terminal.

NOTE: tested normally only on Linux (Ubuntu 10.04), on other systems <awk> and other tools may behave differently.

: '''Author:''' Alexander Muriy

Also available via SVN or {{cmd|g.extension}}:

https://svn.osgeo.org/grass/grass-addons/grass6/display/d.zoom.keys/

==== pd-GRASS ====

: [http://www.ornl.gov/sci/gist/software/grass/ pd-GRASS]: Parallel Display for GRASS GIS

: '''Author:''' Alex Sorokine

==== [[IconSymbols]] ====

* [[IconSymbols|Symbols]] which can be used with ''d.vect, d.graph'', and ''ps.map''.

==== p.in.labels ====

: [http://tekmap.ns.ca/blog/import_label p.in.labels] is a program to import ASCII xyz (where z is a label) files as GRASS labels. Reads from stdin or existing file.

: '''Author:''' Bob Covill

=== Postscript add-ons ===

* ''See also [[ps.map scripts|ps.map samples and templates]]''.

==== ps.atlas ====

: [http://trac.osgeo.org/grass/browser/grass-addons/grass6/postscript/ps.atlas ps.atlas] is a shell script that makes more maps on current region according to input *.psmap file. General map can be stored as vector file. The resulting *.eps maps can be automatically converted to *.pdf files.

: '''Author:''' Jachym Cepicky

==== ps.output ====

: [https://trac.osgeo.org/grass/browser/grass-addons/grass6/postscript/ps.output ps.output] is much like {{cmd|ps.map}} but with advanced decorations and ability for translucency. Here you can find a [[Ps.output|tutorial]].

: '''Author:''' Jorge Tizado

==== [[AreaFillPatterns]] ====

* Hatches for ps.map's vareas

=== wxGUI add-ons ===

See GRASS 7

=== Dempster-Shafer modelling ===

See: http://svn.osgeo.org/grass/grass-addons/grass6/dst/

Modules: dst.predict.run, m.dst.create, m.dst.source, m.dst.update, m.dst.view, r.categorize, r.dst.combine, r.dst.predict.bpn, v.random.sample, v.report.dist

Reference:
* P. Verhagen, H. Kamermans, M. van Leusen & B. Ducke (2010). ''New developments in archaeological predictive modelling''. In: T. Bloemers, H. Kars, A. van der Valk & M. Wijnen (eds.): ''The Cultural Landscape & Heritage Paradox. Protection and Development of the Dutch Archaeological-Historical Landscape and its European Dimension'' (Landscape & Heritage Studies Proceedings), pp. 431-444. ([http://www.academia.edu/368596/P._Verhagen_H._Kamermans_M._van_Leusen_and_B._Ducke_2010_._New_developments_in_archaeological_predictive_modelling._In_T._Bloemers_H._Kars_A._van_der_Valk_and_M._Wijnen_eds._The_Cultural_Landscape_and_Heritage_Paradox._Protection_and_Development_of_the_Dutch_Archaeological-Historical_Landscape_and_its_European_Dimension_Landscape_and_Heritage_Studies_Proceedings_pp._431-444 PDF])

===GRASS and UMN Mapserver===

* [http://www.mail-archive.com/mapserver-users@lists.umn.edu/msg00086.html See interesting posting]
* See wiki [[GRASS and MapServer]] page

{{AddOns}}

GRASS Community Sprint Prague 2013

2013-05-02T09:25:13Z

⚠️Benducke: /* In person */

{{toc|right}}
The GRASS GIS [[team]] will organize the '''4th GRASS Developer and Power User Meeting, aka 'GRASS GIS Community Sprint'''' from '''July 12 to July 18, 2013'''. The sprint is following the [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2013 Geoinformatics conference], 11-12 July 2013, Czech Technical University in {{wikipedia|Prague}}, {{wikipedia|Czech Republic}}.


'''Important dates:'''

* 11 (Thusday) - 12 (Friday) July 2013: [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2013 Geoinformatics conference]

* '''12 (Friday) - 18 (Thusday) July 2013: GRASS GIS Community Sprint''' @ [http://www.fsv.cvut.cz/ FCE CTU]

== Purpose ==

This fourth edition of the GRASS GIS Community Sprint 2013 is a great occasion for folks to support the development by actively contributing to the source code, manuals or likewise. The '''community''' sprint is a get-together for GRASS project members and supporters and related [http://www.osgeo.org OSGeo] projects to make decisions and tackle larger problems. For this meeting, we welcome people committed to improving the GRASS GIS project and the interfaces to [[QGIS GRASS Cookbook|QGIS]], [[GDAL]], [[PostGIS]], [[R statistics]], [[GRASS and Sextante|Sextante, gvSIG]], OGC Services (esp. [[WPS]]) and more. This includes developers, documenters, bug reporters, translators and others.

For this meeting, we welcome people committed to improving the GRASS GIS and related projects. This includes developers, document writers, wish and bug reporters, translators etc.

== Sponsors ==

We welcome '''financial contributions''' to support the meeting and we are looking for sponsors to cover costs such as meals or to help reducing travelling and accommodation expenses for GRASS developers with far arrival If you are interested to sponsor the GRASS Community Sprint, please read about

:::'''sponsoring the GRASS project at [http://grass.osgeo.org/donations http://grass.osgeo.org/donations]'''

For questions, please contact [[User:Neteler|Markus Neteler]] <tt><neteler at osgeo.org></tt>. Any surplus at the end of the event will be turned over to the GRASS GIS project.

This fourth GRASS Community Sprint is a great occasion for you to support the development of GRASS. With your contribution you'll enable more developers to meet. The community sprint is an important opportunity for the GRASS developers to discuss and collaboratively resolve bugs, plan the direction for the project and work on new features. Please see below for the more detailed agenda. The developers and contributors are donating their valuable time, so it would be great if in-kind funding can be made available from within the community to cover out-of-pocket expenses. All of the work that takes place at the community sprint will be directly contributed back into the GRASS project to the benefit of everyone who uses it.

=== Thanks to our sponsors ===

We are grateful for the support which we have received to organize this GRASS Community Sprint:


== Timing ==

'''When''': 12-18 July, 2013

Of course you are invited to join or leave the community sprint whenever you want.

'''Duration''': tbd

* Friday (12. July) is day of arrival
** First meeting in the afternoon (after the [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2013 Geoinformatics conference]) to define the agenda
* Saturday to Wednesday
** Full days
* Thursday (18. July) is day of departure
** Probably hacking for people with a flight later in the evening

== Venue ==
[[Image:logo_cvut.jpg|130px|left]]
Department of Mapping and Cartography 
[http://www.fsv.cvut.cz Faculty of Civil Engineering] 
[http://www.cvut.cz Czech Technical University in Prague], {{wikipedia|Czech Republic}} 
[http://geoinformatics.fsv.cvut.cz/gwiki/Room_B367 Room B367] 

'''[http://geoinformatics.fsv.cvut.cz/gwiki/Where_you_can_find_us Location & Transportations]'''

Prague has an international [http://www.prg.aero/en/ airport] and is also reachable by train, bus or car.

== Accommodation and Costs ==

Participants should plan for the following costs:

* The participation is free of charge
* Travel to Prague, variable depending on where you come from
* Accommodation and meals (with the donated sponsorship money we will try to cover some expenses of the participants)
'''Please note''': The currency in Czech Republic is {{wikipedia|Czech crown}} (CZK, koruna, Kč). 100 Czech crowns are about 4 Euros (see [http://www.cnb.cz/en/financial_markets/foreign_exchange_market/exchange_rate_fixing/daily.jsp current rates]).

'''[http://geoinformatics.fsv.cvut.cz/gwiki/Accommodation_in_Prague Accommodation in Prague]'''

:* [http://geoinformatics.fsv.cvut.cz/gwiki/Accommodation_in_Prague#Masarykova_Kolej_Hotel Masarykova Kolej Hotel]
:* [http://geoinformatics.fsv.cvut.cz/gwiki/Accommodation_in_Prague#Hotel_DAP Hotel DAP]
:* [http://geoinformatics.fsv.cvut.cz/gwiki/Accommodation_in_Prague#Hotel_Krystal Hotel Krystal]
:* [http://geoinformatics.fsv.cvut.cz/gwiki/Accommodation_in_Prague#Pension_Hanspaulka Pension Hanspaulka]
:* [http://geoinformatics.fsv.cvut.cz/gwiki/Accommodation_in_Prague#Hotel_Silenzio Hotel Silenzio]
:* [http://geoinformatics.fsv.cvut.cz/gwiki/Accommodation_in_Prague#Student_hostels_.28CTU.29 Student hostels (CTU)]
:* Special offer: ''sleeping for free in the kindergarten'' (30min by city urban mass transportation from the university campus, sleeping bag required, kitchen and WC available, no showers, in working days available only from 8 p.m. to 8 a.m.), contact [[User:Landa|Martin Landa]] for details
:* See also http://www.hotel.cz/praha-6/accommodation/

Please let us know your time of arrival and leaving, so we can book for the accommodations and organize the logistics.

Financial support: (partial) travel grants can be payed upon request thanks to our sponsors!

== Weather and Common Item Prices ==

* In July the weather in Prague is usually warm ([http://www.prague-spot.com/climate 20 or more degrees by day])
* A espresso coffee is about 25 CZK (1 euro), a beer (half of liter) in a common pub is around 30 CZK (1 euro 20 cents), can be more in special pubs. In Prague you can have a full meal (see {{wikipedia|Czech cuisine}} for details) for 100 - 150 CZK (4 - 6 euros), but beware of tourist restaurants, the price can easily rise. It's quite easy to find in Prague also Italian or Chinese restaurants.

== Agenda - What we plan to do ==

'''Note:''' The program is generally open for your ideas. Please write an email to the [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developer list] to discuss your contribution.

Further details about the action items you '''find [[Talk:GRASS Community Sprint Prague 2013|here]]''' and below. Topics cover non-technical, semi-technical, and technical issues.

=== Timeline ===

==== Friday, 12 July ====
* ''(time to be defined)'': Kick-off in the Faculty of Civil Engineering, building B, room 367 (3rd floor, [http://geoinformatics.fsv.cvut.cz/gwiki/Where_you_can_find_us map])
* Participants presentation


==== Saturday, 13 July ====

* 9:00-evening


==== Sunday, 14 July ====

* 9:00-evening


==== Monday, 15 July ====

* 9:00-evening


==== Tuesday, 16 July ====

* 9:00-evening


==== Wednesday, 17 July ====

* 9:00-evening
* '''30 YEARS OF GRASS GIS''' party!!

==== Thursday, 18 July ====

* Last meeting
* Farewell and have a good trip home

== Participation ==

We are planning for an attendance of 20 people (i.e., coding places) but of course you are welcome to join us and bring new ideas with you: we'll make more places available. Please add your name here or contact [[User:Landa|Martin Landa]] <tt><landa.martin at gmail.com></tt>:

=== In person ===

{|class="wikitable sortable" border="2" cellspacing="0" cellpadding="4" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse; background-color:#edf9c7; font-size:95%; empty-cells:show;"
!width=50px|'''Number'''
!width=130px|'''Participant '''
!width=100px|'''Country'''
!width=100px|'''Arrival'''
!width=100px|'''Departure'''
!'''Topic'''
!width=75px|'''T-Shirt'''
!'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
|Czech Republic
| July 12
| July 18
| Toolbox concept, vector engine in GRASS 7, wxGUI, PostGIS Topology support, 3D topology
| L
|
|-
|2
| [[User:Neteler|Markus Neteler]]
| Italy
| July 12
| July 18
| Varia
| M
|
|-
|3
| [[User:Helena|Helena Mitasova]]
| USA
| July 16 pm
| July 18
| Data exchange, metadata, GRASS7 data sets, temporal data
| M
|
|-
|4
| [[User:benducke|Benjamin Ducke]]
| Germany
| July 15 (+/- 1)
| July 18 (+/- 1)
| 3D interpolation in GRASS 7 (GSoC), misc.
| M
|-
|5
| and you ...
|
|
|
|
|
|
|-
|}

=== Via IRC chat or hangout===

: [irc://freenode/grass #grass] on Freenode
: [http://www.google.com/+/learnmore/hangouts/ G+ hangout]
:: (to be investigated; smartphones only? (''not sure, but I don't think so'')
:: do you have to be signed up with a Google+ social media account?
:: is Jitsi on a desktop computer compatible? --''not sure, but Jisti offers its own work-alike free multi-person video chat for XMPP(Jabber compatibles) which is not limited to 10 people: [https://jitsi.org/Projects/JitsiVideobridge VideoBridge]'')

For details, see [[IRC]]

Please add yourself here below (please add also your gmail account for G+ hangout):

* [[User:Landa|Martin Landa]], [http://www.timeanddate.com/worldclock/city.html?n=204 timezone]. Gmail is <landa.martin@> expanded
* ...

'''Timing of hangout meetings:'''

* Date, time: [http://doodle.com/f2qfqixqeqkkmskh doodle-poll]

=== Collaborative document scratching ===

(Power) users from all over the world are kindly invited to assist with testing of new and existing functionality. To collect results and notes, we set up an interactive, collaborative editing tool which works in real-time:

Please check http://titanpad.com/I51nq1SrNc

== Individual Preparation ==

* Bring your own computer
* Bring {{wikipedia|AC adapter|power connector adapter}} if needed (Czech Republic: 230V, 50Hz, {{wikipedia|File:Euro-Flachstecker_2.jpg|Type C Europlugs}} are common and also {{wikipedia|File:French_plug_and_socket.jpg|Type E}})
* Install subversion and the compiler tools, and come with a working GRASS development environment if possible.

== Broadcast & Video ==

During the event :)

== Photos ==

Also during the event :)

== FAQ ==

* '''How was it last time?'''
** Very nice, see [[GRASS Community Sprint Genova 2013]]!
* ''Is the GRASS Community Sprint just a coding event?''
** It is mainly a coding and documentation event. It is a working session for people who are already participants in the GRASS project and/or are committed to improving the GRASS project.
** On demand we can do some presentations of current working GRASS implementation and new upcoming features to spread the idea of Open Source GIS software
* ''Is the GRASS Community Sprint for developers only?''
** No: anybody can help, with testing, checking out bugs and fixes, documentation and more.
* ''Where can I get help and more information about the community sprint?''
** Contact [[User:Landa|Martin Landa]] <tt><landa.martin at gmail.com></tt>

== Press Release ==

''(to be done)''


[[Category: Workshops]]

GRASS SoC Ideas 2013

2013-05-02T09:05:30Z

⚠️Benducke: /* Improve GRASS' kriging and 3D interpolation capabilities */

<center>
[[Image:grasslogo_vector_small.png|link=http://grass.osgeo.org]] @ [[Image:Gsoc-2013-logo-color.jpg|250px|link=http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2013]] @ [[Image:OSGeo 220pix.png|link=http://www.osgeo.org]]
</center>

__TOC__

== About ==

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code_2013 Google Summer of Code 2013] (see the [http://www.google-melange.com/document/show/gsoc_program/google/gsoc2013/help_page#2._What_is_the_program_timeline timeline]). Here we will list project ideas and and other information related to the GRASS GSoC projects.

== Ideas ==

* '''Also review ideas from''' [[GRASS SoC Ideas 2009#Ideas|2009]], [[GRASS SoC Ideas 2010#Ideas|2010]], [[GRASS SoC Ideas 2011#Ideas|2011]] and [[GRASS SoC Ideas 2012#Ideas|2012]] which are still open.

* Project ideas of '''your own''' are also most welcome and often the best.

=== General ===

* Implement a buffered binary balanced search tree using external memory: Rationale: some modules and library functions use a binary search tree, which can lead to out-of-memory errors for large datasets. A buffered binary balanced search tree using external memory would solve this problem and enhance the capability of GRASS to work with large datasets on limited hardware resources.

* [[Parallel_GRASS_jobs|Parallelize]] CPU-heavy modules using [[OpenMP]], OpenCL ([[GPU]]), and/or pthreads.

* If you're really stuck for ideas, [https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&group=component&order=priority&col=id&col=summary&col=status&col=type&col=owner&col=priority&col=milestone&type=enhancement hunt around the wish list in the trac system].

* Clean-room write a LGPL or BSD/MIT-X GRASS data format plugin for GDAL/OGR. An option should exist to support both GRASS 6 and 7 versions of the format.
: Why is a new plugin needed? Add here

* Improve and fix bugs in the QGIS GRASS Toolbox. Generally make it smoother to pass projects and workflows between the two.
: Or simply use [[GRASS and Sextante|Sextante plugin in QGIS]] which does this already

=== Symbology / Cartography ===

* Allow display of a vector legend in the map display (equivalent to current {{cmd|d.legend}} implementation for rasters)

* Expand [[IconSymbols|symbology]] and re-classify groups
:: ''note that SoC only accepts coding projects, not graphics design or documentation projects.''
:* Add svg/eps support to a d.* module and {{Cmd|ps.map}} would be quite helpful. See the {{Cmd|d.graph}} help page and {{Cmd|ps.map}}'s "eps" and "vpoints" instructions. The first step would be to write a stand-alone tool in C to create d.graph commands; the second step would be to add as a new option in ''d.graph''; a third step would be to backport this to GRASS 6's graphics API. See also {{trac|733}} wish re. implementing Bézier curves in the display drivers.
:: '''Willing to co-mentor:''' Hamish

* Rework the complete set of thematic cartography tools such as {{Cmd|d.vect.thematic}} and {{Cmd|d.thematic.area}} and the related classification routines. This would comprise:
** Revising the classification algorithms already implemented and possibly adding new ones (kmeans, Jenks)
** Replace the existing d.vect.thematic script with a C-based module (in the likes of d.thematic.area) combing thematic cartography of points, lines and areas
** Include representation of legend of the thematic map
** Use [http://colorbrewer2.org/ colorbrewer] rules to make classifications pretty
** Implement one or several specific GUI interface(s) to this new module
:: ''note that since d.vect.thematic was written {{Cmd|d.vect}} has added DB-column based sizing, rotation, and other tasks making parts of d.vect.thematic ready for much simplification.''
:* Generalized ASCII table input for {{Cmd|d.legend}} (see {{trac|89}} wish)
:* Histogram sidebar support for {{Cmd|d.legend}} and {{Cmd|ps.map}} (see {{trac|1049}} wish)
:: '''Willing to co-mentor d.legend bits:''' Hamish

=== Imagery ===

* Based on the work on [[GRASS_GSoC_2012_Image_Segmentation|segmentation]] in GSoC 2012 develop routines for object-based (or region-based) image classification. This probably entails:
** Characterizing segments. This includes producing statistics such as mean, median, variance of the segmented data within each delineated segment (customized interface to r.statistics2).
** Classifying segments based on the characteristics and (possibly) training areas
** Interface with other modules in a consistent workflow (i.cluster, r.fuzzy, etc)

* Implement hierarchical classification tools (e.g. being able to create a large class "forest" with subclasses of different types of forests). Hierarchical classification is already used internally by i.gensigset/i.smap. Hierarchical segmentation can currently be done by using the output of a previous run of i.segment as input for the next run of i.segment with increased threshold.

* Interface with the [http://www.orfeo-toolbox.org/otb/ Orfeo toolbox (OTB)], which is an open source, [http://www.itk.org ITK]-based, C++ library of (spatial) image processing library. OTB implements a very wide set of interesting features for anybody working with raster data - in particular satellite imagery: radiometric corrections, orthorectification, filtering, feature extraction, image segmentation, classification, change detection, etc.

=== Vector ===

# Line intersection: implement an efficient algorithm based on literature review, focusing on the [http://en.wikipedia.org/wiki/Bentley-Ottmann_algorithm Bentley-Ottmann algorithm] and its derivates. The best or best two should be implemented. Coupled to the problem of calculating line intersections is the problem of calculating segment intersections, currently implemented in [http://grass.osgeo.org/programming7/vector_2Vlib_2intersect_8c.html#ab4f5f3d99742378f0f284966f59bafe7 Vect_segment_intersection()] and [http://grass.osgeo.org/programming7/linecros_8c.html#a4fb52c4fc60df4fcae5e676134f08be9 dig_find_intersection()], which could also be replaced with more efficient algorithms.
#* Rationale: the current function Vect_line_intersection() is "home-brew" and rather slow for lines with many segments, whereas the Bentley-Ottmann algorithm can find line intersections in logarithmic time per intersection.
#* Requirements: at least interest in, preferably knowledge of the art of searching and sorting (search trees, priority queues, heaps).
#* Implementation goals: One function to search for intersections between two lines, ignoring self-intersections, and another function to test one single line for self-intersections. The API and output should be compatible with the current Vect_line_intersection() function. Optionally an alternative to Vect_segment_intersection().
# ''Your suggestion here!''

'''Willing to Mentor:''' Markus Metz

=== Temporal GIS Algebra for raster and vector data ===

We (Soeren Gebbert and Thomas Leppelt) would like to develop a temporal GIS algebra for raster and vector data in GRASS7.

Role:
* '''Mentor:''' Soeren Gebbert
* '''GSoC Student:''' Thomas Leppelt

Implementation goals:

* Spatio-temporal vector algebra module t.vect.mapcalc
** The algebra will be based on vector map operations provided from {{Cmd|v.overlay}} (and, or, xor, not), {{Cmd|v.buffer}} (buff_point, buff_line, buff_area), {{Cmd|v.patch}} (patch), ... , temporal variables (day of year, weekday, datum, time, ...) and temporal topology relations (predecessor, successor, follows, equals, ...)
** The resulting module will be able to process space time vector datasets using expressions like:

<source lang="bash">
# Compute the intersection between the space time vector datasets A and B
# from maps with equal time stamps. The STVDS A is used as temporal reference.
# A new STVDS C will be created with the same time stamps as A.
t.vect.mapcalc inputs=A,B timeref=A output=C expr="C = if(equal(B), and(A,B))"

time |STVDS|STVDS|STVDS
stamp | A | B | C
-------------------------------------
Jan 2001 | a1 | b1 | v.overlay ain=a1 bin=b1 op=and out=c1
Feb 2001 | a2 | |
Mar 2001 | | b2 |
Apr 2001 | a3 | |
May 2001 | a4 | b3 | v.overlay ain=a4 bin=b3 op=and out=c2
Jun 2001 | | b4 |

# Nested operations are supported and temporal neighborhood computation
t.vect.mapcalc input=A,B,C tempref=A output=D \
expr="D = if(successor(B) && predecessor(C), and(A, xor(successor(B), buff_point(predecessor(C), 100)))"

# Date and time can be used in the expression
t.vect.mapcalc input=A,B timeref=A output=C \
expr="C = if(start_year() >= 2001 && start_month() > 6, and(A,B), not(A,B))"
</source>

* Spatio-temporal raster algebra module t.rast.mapcalc
** The algebra will be based on the existing {{Cmd|r.mapcalc}} raster map algebra, temporal variables (day of year, weekday, datum, time, ...) and temporal topology relations (predecessor, successor, follows, equals, ...)
{{GSoC}}
** The resulting module will be able to process space time raster datasets using expressions like:

<source lang="bash">
# Compute the sum between the space time raster datasets A and B
# from maps with equal time stamps. The STRDS A is used as temporal reference.
# A new STRDS C will be created with the same time stamps as A.
t.rast.mapcalc inputs=A,B timeref=A output=C expr="C = if(equal(B), A + B)"

# Spatio-temporal neighborhood computation. STRDS C will have the same time stamps as A.
t.rast.mapcalc input=B timeref=A output=C \
expr="C = if(successor(B) && predecessor(B), (successor(B)[0,0] + B[0,0] + predecessor(B)[0,0])/3.0, B[0,0])"
</source>

* The GRASS GIS temporal framework will be utilized and the pygrass module interface
* PLY will be used for lexical analysis and parser generation
* Temporal algebra will be equivalent for booth modules with about 60 internal variables and functions

=== Improve GRASS' kriging and 3D interpolation capabilities ===

One of GRASS' most outstanding features is its support for 3D raster (voxel) data. In fact, GRASS offers more functionality for 3D volumetric data processing than many expensive proprietary solutions. This GSoC project aims to improve on GRASS' existing strengths by significantly enhancing the methods for interpolation of data in voxel space. Currently, GRASS offers spline-based interpolation of 3D vector points to 3D voxel data. We plan to add the following (see also notes below):

* 3D geostatistics/kriging
* 3D interpolation using radial basis functions (RBF)
* transition probability models (TBM)
* stratigraphic modeling

These improved 3D interpolation capabilities would combine ideally with the 3D processing modules already present in GRASS (flexible 3D map algebra, export to VTK format for visualization, 3D vector data manipulation, etc.).

If this project can be realized as planned, it will allow GRASS to establish itself as the open source tool of choice for applications in geology, geophysics, soil science and archaeology, all of which have a need to model subsurface soil structures and properties based on 3D sampling points. These areas of application are currently dominated by expensive and inflexible proprietary tools, which is why we feel that this project could make a real difference for open source users.

'''Available mentors:'''

* Benjamin Ducke
* Sören Gebbert

'''Notes on 3D kriging''':
Since GRASS currently lacks native geostatistical capabilities, this project will cover 3D ''and'' 2D variograms, kriging interpolation, etc. There are already efforts underway in the GRASS community to supply complete geostatistical functionality and we expect our GSoC student to make full use of them (see [http://lists.osgeo.org/pipermail/grass-dev/2013-April/063389.html]), minimzing the time this GSoC project will have to spent on the 3D kriging component.

'''Notes on radial basis functions (RBF)''':
RBF are straight-forward interpolation functions. Most GIS users will be aware of Inverse Distance Weighting (e.g. GRASS has [http://grass.osgeo.org/grass70/manuals/v.surf.idw.html v.surf.idw]), which is just one specific case of RBF. In the context of 3D interpolation, RBF provide simple and efficient interpolators useful for dense 3D samples (or for producing incomplete models from sparse samples).

'''Notes on transition probability models (TBM)''':
TBMs allow to interpolate category (integer) data, such as soil classes in 3D space. Naturally, the result of such an interpolation will not be as accurate as that of interpolation of continuous data via splines or kriging. However, soil horizons, layers etc. are very common data in soil science and geology (borehole samples!) and there is currently no robust method for interpolating such data in GRASS. There is a FORTRAN implementation of TBM called T-PROGS (by Steven F. Carle) that is in the public domain. T-PROGS could be run from within GRASS as a command line tool or translated to C and converted into a "real" GRASS module (see [http://www.xmswiki.com/xms/GMS:T-PROGS]; see also [http://chl.erdc.usace.army.mil/chl.aspx?p=s&a=ARTICLES;37&g=50]).

'''Notes on stratigraphic modeling''':
Another approach to soil horizon interpolation, that may be easy to implement in GRASS, is documented here: [http://chl.erdc.usace.army.mil/chl.aspx?p=s&a=ARTICLES;41&g=50]. Basically, this involves taking 2D cross sections of soil horizons and extruding them into a 3D model in the most straight-forward way. This is something that is often done manually by soil scientists and archaeologists, but could be done more efficiently and transparently using a simple algorithm.

See also these GRASS mailing list posts for further information:

'''Further information'''

http://lists.osgeo.org/pipermail/grass-user/2010-January/054246.html

http://lists.osgeo.org/pipermail/grass-dev/2013-April/063389.html

GRASS SoC Ideas 2013

2013-05-02T07:34:51Z

⚠️Benducke: /* Improve GRASS' kriging and 3D interpolation capabilities */

<center>
[[Image:grasslogo_vector_small.png|link=http://grass.osgeo.org]] @ [[Image:Gsoc-2013-logo-color.jpg|250px|link=http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2013]] @ [[Image:OSGeo 220pix.png|link=http://www.osgeo.org]]
</center>

__TOC__

== About ==

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code_2013 Google Summer of Code 2013] (see the [http://www.google-melange.com/document/show/gsoc_program/google/gsoc2013/help_page#2._What_is_the_program_timeline timeline]). Here we will list project ideas and and other information related to the GRASS GSoC projects.

== Ideas ==

* '''Also review ideas from''' [[GRASS SoC Ideas 2009#Ideas|2009]], [[GRASS SoC Ideas 2010#Ideas|2010]], [[GRASS SoC Ideas 2011#Ideas|2011]] and [[GRASS SoC Ideas 2012#Ideas|2012]] which are still open.

* Project ideas of '''your own''' are also most welcome and often the best.

=== General ===

* Implement a buffered binary balanced search tree using external memory: Rationale: some modules and library functions use a binary search tree, which can lead to out-of-memory errors for large datasets. A buffered binary balanced search tree using external memory would solve this problem and enhance the capability of GRASS to work with large datasets on limited hardware resources.

* [[Parallel_GRASS_jobs|Parallelize]] CPU-heavy modules using [[OpenMP]], OpenCL ([[GPU]]), and/or pthreads.

* If you're really stuck for ideas, [https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&group=component&order=priority&col=id&col=summary&col=status&col=type&col=owner&col=priority&col=milestone&type=enhancement hunt around the wish list in the trac system].

* Clean-room write a LGPL or BSD/MIT-X GRASS data format plugin for GDAL/OGR. An option should exist to support both GRASS 6 and 7 versions of the format.
: Why is a new plugin needed? Add here

* Improve and fix bugs in the QGIS GRASS Toolbox. Generally make it smoother to pass projects and workflows between the two.
: Or simply use [[GRASS and Sextante|Sextante plugin in QGIS]] which does this already

=== Symbology / Cartography ===

* Allow display of a vector legend in the map display (equivalent to current {{cmd|d.legend}} implementation for rasters)

* Expand [[IconSymbols|symbology]] and re-classify groups
:: ''note that SoC only accepts coding projects, not graphics design or documentation projects.''
:* Add svg/eps support to a d.* module and {{Cmd|ps.map}} would be quite helpful. See the {{Cmd|d.graph}} help page and {{Cmd|ps.map}}'s "eps" and "vpoints" instructions. The first step would be to write a stand-alone tool in C to create d.graph commands; the second step would be to add as a new option in ''d.graph''; a third step would be to backport this to GRASS 6's graphics API. See also {{trac|733}} wish re. implementing Bézier curves in the display drivers.
:: '''Willing to co-mentor:''' Hamish

* Rework the complete set of thematic cartography tools such as {{Cmd|d.vect.thematic}} and {{Cmd|d.thematic.area}} and the related classification routines. This would comprise:
** Revising the classification algorithms already implemented and possibly adding new ones (kmeans, Jenks)
** Replace the existing d.vect.thematic script with a C-based module (in the likes of d.thematic.area) combing thematic cartography of points, lines and areas
** Include representation of legend of the thematic map
** Use [http://colorbrewer2.org/ colorbrewer] rules to make classifications pretty
** Implement one or several specific GUI interface(s) to this new module
:: ''note that since d.vect.thematic was written {{Cmd|d.vect}} has added DB-column based sizing, rotation, and other tasks making parts of d.vect.thematic ready for much simplification.''
:* Generalized ASCII table input for {{Cmd|d.legend}} (see {{trac|89}} wish)
:* Histogram sidebar support for {{Cmd|d.legend}} and {{Cmd|ps.map}} (see {{trac|1049}} wish)
:: '''Willing to co-mentor d.legend bits:''' Hamish

=== Imagery ===

* Based on the work on [[GRASS_GSoC_2012_Image_Segmentation|segmentation]] in GSoC 2012 develop routines for object-based (or region-based) image classification. This probably entails:
** Characterizing segments. This includes producing statistics such as mean, median, variance of the segmented data within each delineated segment (customized interface to r.statistics2).
** Classifying segments based on the characteristics and (possibly) training areas
** Interface with other modules in a consistent workflow (i.cluster, r.fuzzy, etc)

* Implement hierarchical classification tools (e.g. being able to create a large class "forest" with subclasses of different types of forests). Hierarchical classification is already used internally by i.gensigset/i.smap. Hierarchical segmentation can currently be done by using the output of a previous run of i.segment as input for the next run of i.segment with increased threshold.

* Interface with the [http://www.orfeo-toolbox.org/otb/ Orfeo toolbox (OTB)], which is an open source, [http://www.itk.org ITK]-based, C++ library of (spatial) image processing library. OTB implements a very wide set of interesting features for anybody working with raster data - in particular satellite imagery: radiometric corrections, orthorectification, filtering, feature extraction, image segmentation, classification, change detection, etc.

=== Vector ===

# Line intersection: implement an efficient algorithm based on literature review, focusing on the [http://en.wikipedia.org/wiki/Bentley-Ottmann_algorithm Bentley-Ottmann algorithm] and its derivates. The best or best two should be implemented. Coupled to the problem of calculating line intersections is the problem of calculating segment intersections, currently implemented in [http://grass.osgeo.org/programming7/vector_2Vlib_2intersect_8c.html#ab4f5f3d99742378f0f284966f59bafe7 Vect_segment_intersection()] and [http://grass.osgeo.org/programming7/linecros_8c.html#a4fb52c4fc60df4fcae5e676134f08be9 dig_find_intersection()], which could also be replaced with more efficient algorithms.
#* Rationale: the current function Vect_line_intersection() is "home-brew" and rather slow for lines with many segments, whereas the Bentley-Ottmann algorithm can find line intersections in logarithmic time per intersection.
#* Requirements: at least interest in, preferably knowledge of the art of searching and sorting (search trees, priority queues, heaps).
#* Implementation goals: One function to search for intersections between two lines, ignoring self-intersections, and another function to test one single line for self-intersections. The API and output should be compatible with the current Vect_line_intersection() function. Optionally an alternative to Vect_segment_intersection().
# ''Your suggestion here!''

'''Willing to Mentor:''' Markus Metz

=== Temporal GIS Algebra for raster and vector data ===

We (Soeren Gebbert and Thomas Leppelt) would like to develop a temporal GIS algebra for raster and vector data in GRASS7.

Role:
* '''Mentor:''' Soeren Gebbert
* '''GSoC Student:''' Thomas Leppelt

Implementation goals:

* Spatio-temporal vector algebra module t.vect.mapcalc
** The algebra will be based on vector map operations provided from {{Cmd|v.overlay}} (and, or, xor, not), {{Cmd|v.buffer}} (buff_point, buff_line, buff_area), {{Cmd|v.patch}} (patch), ... , temporal variables (day of year, weekday, datum, time, ...) and temporal topology relations (predecessor, successor, follows, equals, ...)
** The resulting module will be able to process space time vector datasets using expressions like:

<source lang="bash">
# Compute the intersection between the space time vector datasets A and B
# from maps with equal time stamps. The STVDS A is used as temporal reference.
# A new STVDS C will be created with the same time stamps as A.
t.vect.mapcalc inputs=A,B timeref=A output=C expr="C = if(equal(B), and(A,B))"

time |STVDS|STVDS|STVDS
stamp | A | B | C
-------------------------------------
Jan 2001 | a1 | b1 | v.overlay ain=a1 bin=b1 op=and out=c1
Feb 2001 | a2 | |
Mar 2001 | | b2 |
Apr 2001 | a3 | |
May 2001 | a4 | b3 | v.overlay ain=a4 bin=b3 op=and out=c2
Jun 2001 | | b4 |

# Nested operations are supported and temporal neighborhood computation
t.vect.mapcalc input=A,B,C tempref=A output=D \
expr="D = if(successor(B) && predecessor(C), and(A, xor(successor(B), buff_point(predecessor(C), 100)))"

# Date and time can be used in the expression
t.vect.mapcalc input=A,B timeref=A output=C \
expr="C = if(start_year() >= 2001 && start_month() > 6, and(A,B), not(A,B))"
</source>

* Spatio-temporal raster algebra module t.rast.mapcalc
** The algebra will be based on the existing {{Cmd|r.mapcalc}} raster map algebra, temporal variables (day of year, weekday, datum, time, ...) and temporal topology relations (predecessor, successor, follows, equals, ...)
{{GSoC}}
** The resulting module will be able to process space time raster datasets using expressions like:

<source lang="bash">
# Compute the sum between the space time raster datasets A and B
# from maps with equal time stamps. The STRDS A is used as temporal reference.
# A new STRDS C will be created with the same time stamps as A.
t.rast.mapcalc inputs=A,B timeref=A output=C expr="C = if(equal(B), A + B)"

# Spatio-temporal neighborhood computation. STRDS C will have the same time stamps as A.
t.rast.mapcalc input=B timeref=A output=C \
expr="C = if(successor(B) && predecessor(B), (successor(B)[0,0] + B[0,0] + predecessor(B)[0,0])/3.0, B[0,0])"
</source>

* The GRASS GIS temporal framework will be utilized and the pygrass module interface
* PLY will be used for lexical analysis and parser generation
* Temporal algebra will be equivalent for booth modules with about 60 internal variables and functions

=== Improve GRASS' kriging and 3D interpolation capabilities ===

One of GRASS' most outstanding features is its support for 3D raster (voxel) data.
This GSoC project aims to significantly enhance the methods for interpolation data in voxel space.
Currently, GRASS offers spline-based interpolation of 3D vector points to 3D voxel data.
We plan to add the following:

* 3D geostatistics/kriging
* 3D interpolation using radial basis functions (RBF)
* transition probability models (TBM)
* stratigraphic modeling

'''Available mentors:'''

* Benjamin Ducke
* Sören Gebbert

'''Notes on 3D kriging''':
Since GRASS currently lacks native geostatistical capabilities, this project will cover 3D 'and' 2D variograms, kriging interpolation, etc. There are already efforts underway in the GRASS community to supply substantial, geostatistical functionality and we expect this project to make full use of them (see [http://lists.osgeo.org/pipermail/grass-dev/2013-April/063389.html]).

'''Notes on radial basis functions (RBF)''':
RBF are straight-forward interpolation functions. Most GIS users will be aware of Inverse Distance Weighting, which is just one specific case of RBF. In 3D interpolation, RBF provide simple and efficient interpolators useful for dense 3D samples (or for producing incomplete models from sparse samples).

'''Notes on transition probability models (TBM)''':
TBMs allow to interpolate category (integer) data, such as soil classes in 3D space. Naturally, the results of such an interpolation will not be as accurate or useful as that of interpolation continuous data via splines or kriging. However, soil horizons, layers et al. are very common data in soil sciences and geology (bore hole samples!) and there is currently no robust method for interpolating such data in GRASS. There is a FORTRAN implementation of TBM called T-PROGS (by Steven F. Carle) that is in the public domain. T-PROGS could be run from within GRASS as a command line tool or translated to C and converted into a "real" GRASS module (see [http://www.xmswiki.com/xms/GMS:T-PROGS]; see also [http://chl.erdc.usace.army.mil/chl.aspx?p=s&a=ARTICLES;37&g=50]).

'''Notes on stratigraphic modeling''':
Another approach to soil horizon interpolation, that may be easy to implement in GRASS is documented here: [http://chl.erdc.usace.army.mil/chl.aspx?p=s&a=ARTICLES;41&g=50].

See also these GRASS mailing list posts for further information:

'''Further information'''

http://lists.osgeo.org/pipermail/grass-user/2010-January/054246.html

http://lists.osgeo.org/pipermail/grass-dev/2013-April/063389.html

GRASS SoC Ideas 2013

2013-05-01T15:14:17Z

⚠️Benducke: /* Improve GRASS' kriging and 3D interpolation capabilities */

<center>
[[Image:grasslogo_vector_small.png|link=http://grass.osgeo.org]] @ [[Image:Gsoc-2013-logo-color.jpg|250px|link=http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2013]] @ [[Image:OSGeo 220pix.png|link=http://www.osgeo.org]]
</center>

__TOC__

== About ==

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code_2013 Google Summer of Code 2013] (see the [http://www.google-melange.com/document/show/gsoc_program/google/gsoc2013/help_page#2._What_is_the_program_timeline timeline]). Here we will list project ideas and and other information related to the GRASS GSoC projects.

== Ideas ==

* '''Also review ideas from''' [[GRASS SoC Ideas 2009#Ideas|2009]], [[GRASS SoC Ideas 2010#Ideas|2010]], [[GRASS SoC Ideas 2011#Ideas|2011]] and [[GRASS SoC Ideas 2012#Ideas|2012]] which are still open.

* Project ideas of '''your own''' are also most welcome and often the best.

=== General ===

* Implement a buffered binary balanced search tree using external memory: Rationale: some modules and library functions use a binary search tree, which can lead to out-of-memory errors for large datasets. A buffered binary balanced search tree using external memory would solve this problem and enhance the capability of GRASS to work with large datasets on limited hardware resources.

* [[Parallel_GRASS_jobs|Parallelize]] CPU-heavy modules using [[OpenMP]], OpenCL ([[GPU]]), and/or pthreads.

* If you're really stuck for ideas, [https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&group=component&order=priority&col=id&col=summary&col=status&col=type&col=owner&col=priority&col=milestone&type=enhancement hunt around the wish list in the trac system].

* Clean-room write a LGPL or BSD/MIT-X GRASS data format plugin for GDAL/OGR. An option should exist to support both GRASS 6 and 7 versions of the format.
: Why is a new plugin needed? Add here

* Improve and fix bugs in the QGIS GRASS Toolbox. Generally make it smoother to pass projects and workflows between the two.
: Or simply use [[GRASS and Sextante|Sextante plugin in QGIS]] which does this already

=== Symbology / Cartography ===

* Allow display of a vector legend in the map display (equivalent to current {{cmd|d.legend}} implementation for rasters)

* Expand [[IconSymbols|symbology]] and re-classify groups
:: ''note that SoC only accepts coding projects, not graphics design or documentation projects.''
:* Add svg/eps support to a d.* module and {{Cmd|ps.map}} would be quite helpful. See the {{Cmd|d.graph}} help page and {{Cmd|ps.map}}'s "eps" and "vpoints" instructions. The first step would be to write a stand-alone tool in C to create d.graph commands; the second step would be to add as a new option in ''d.graph''; a third step would be to backport this to GRASS 6's graphics API. See also {{trac|733}} wish re. implementing Bézier curves in the display drivers.
:: Willing to co-mentor: Hamish

* Rework the complete set of thematic cartography tools such as {{Cmd|d.vect.thematic}} and {{Cmd|d.thematic.area}} and the related classification routines. This would comprise:
** Revising the classification algorithms already implemented and possibly adding new ones (kmeans, Jenks)
** Replace the existing d.vect.thematic script with a C-based module (in the likes of d.thematic.area) combing thematic cartography of points, lines and areas
** Include representation of legend of the thematic map
** Use [http://colorbrewer2.org/ colorbrewer] rules to make classifications pretty
** Implement one or several specific GUI interface(s) to this new module
:: ''note that since d.vect.thematic was written {{Cmd|d.vect}} has added DB-column based sizing, rotation, and other tasks making parts of d.vect.thematic ready for much simplification.''
:* Generalized ASCII table input for {{Cmd|d.legend}} (see {{trac|89}} wish)
:* Histogram sidebar support for {{Cmd|d.legend}} and {{Cmd|ps.map}} (see {{trac|1049}} wish)
:: Willing to co-mentor d.legend bits: Hamish

=== Imagery ===

* Based on the work on [[GRASS_GSoC_2012_Image_Segmentation|segmentation]] in GSoC 2012 develop routines for object-based (or region-based) image classification. This probably entails:
** Characterizing segments. This includes producing statistics such as mean, median, variance of the segmented data within each delineated segment (customized interface to r.statistics2).
** Classifying segments based on the characteristics and (possibly) training areas
** Interface with other modules in a consistent workflow (i.cluster, r.fuzzy, etc)

* Implement hierarchical classification tools (e.g. being able to create a large class "forest" with subclasses of different types of forests). Hierarchical classification is already used internally by i.gensigset/i.smap. Hierarchical segmentation can currently be done by using the output of a previous run of i.segment as input for the next run of i.segment with increased threshold.

* Interface with the [http://www.orfeo-toolbox.org/otb/ Orfeo toolbox (OTB)], which is an open source, [http://www.itk.org ITK]-based, C++ library of (spatial) image processing library. OTB implements a very wide set of interesting features for anybody working with raster data - in particular satellite imagery: radiometric corrections, orthorectification, filtering, feature extraction, image segmentation, classification, change detection, etc.

=== Vector ===

# Line intersection: implement an efficient algorithm based on literature review, focusing on the [http://en.wikipedia.org/wiki/Bentley-Ottmann_algorithm Bentley-Ottmann algorithm] and its derivates. The best or best two should be implemented. Coupled to the problem of calculating line intersections is the problem of calculating segment intersections, currently implemented in [http://grass.osgeo.org/programming7/vector_2Vlib_2intersect_8c.html#ab4f5f3d99742378f0f284966f59bafe7 Vect_segment_intersection()] and [http://grass.osgeo.org/programming7/linecros_8c.html#a4fb52c4fc60df4fcae5e676134f08be9 dig_find_intersection()], which could also be replaced with more efficient algorithms.
#* Rationale: the current function Vect_line_intersection() is "home-brew" and rather slow for lines with many segments, whereas the Bentley-Ottmann algorithm can find line intersections in logarithmic time per intersection.
#* Requirements: at least interest in, preferably knowledge of the art of searching and sorting (search trees, priority queues, heaps).
#* Implementation goals: One function to search for intersections between two lines, ignoring self-intersections, and another function to test one single line for self-intersections. The API and output should be compatible with the current Vect_line_intersection() function. Optionally an alternative to Vect_segment_intersection().
# ''Your suggestion here!''

'''Willing to Mentor:''' Markus Metz

=== Temporal GIS Algebra for raster and vector data ===

We (Soeren Gebbert and Thomas Leppelt) would like to develop a temporal GIS algebra for raster and vector data in GRASS7.

Role:
* Mentor: Soeren Gebbert
* GSoC Student: Thomas Leppelt

Implementation goals:

* Spatio-temporal vector algebra module t.vect.mapcalc
** The algebra will be based on vector map operations provided from {{Cmd|v.overlay}} (and, or, xor, not), {{Cmd|v.buffer}} (buff_point, buff_line, buff_area), {{Cmd|v.patch}} (patch), ... , temporal variables (day of year, weekday, datum, time, ...) and temporal topology relations (predecessor, successor, follows, equals, ...)
** The resulting module will be able to process space time vector datasets using expressions like:

<source lang="bash">
# Compute the intersection between the space time vector datasets A and B
# from maps with equal time stamps. The STVDS A is used as temporal reference.
# A new STVDS C will be created with the same time stamps as A.
t.vect.mapcalc inputs=A,B timeref=A output=C expr="C = if(equal(B), and(A,B))"

time |STVDS|STVDS|STVDS
stamp | A | B | C
-------------------------------------
Jan 2001 | a1 | b1 | v.overlay ain=a1 bin=b1 op=and out=c1
Feb 2001 | a2 | |
Mar 2001 | | b2 |
Apr 2001 | a3 | |
May 2001 | a4 | b3 | v.overlay ain=a4 bin=b3 op=and out=c2
Jun 2001 | | b4 |

# Nested operations are supported and temporal neighborhood computation
t.vect.mapcalc input=A,B,C tempref=A output=D \
expr="D = if(successor(B) && predecessor(C), and(A, xor(successor(B), buff_point(predecessor(C), 100)))"

# Date and time can be used in the expression
t.vect.mapcalc input=A,B timeref=A output=C \
expr="C = if(start_year() >= 2001 && start_month() > 6, and(A,B), not(A,B))"
</source>

* Spatio-temporal raster algebra module t.rast.mapcalc
** The algebra will be based on the existing {{Cmd|r.mapcalc}} raster map algebra, temporal variables (day of year, weekday, datum, time, ...) and temporal topology relations (predecessor, successor, follows, equals, ...)
{{GSoC}}
** The resulting module will be able to process space time raster datasets using expressions like:

<source lang="bash">
# Compute the sum between the space time raster datasets A and B
# from maps with equal time stamps. The STRDS A is used as temporal reference.
# A new STRDS C will be created with the same time stamps as A.
t.rast.mapcalc inputs=A,B timeref=A output=C expr="C = if(equal(B), A + B)"

# Spatio-temporal neighborhood computation. STRDS C will have the same time stamps as A.
t.rast.mapcalc input=B timeref=A output=C \
expr="C = if(successor(B) && predecessor(B), (successor(B)[0,0] + B[0,0] + predecessor(B)[0,0])/3.0, B[0,0])"
</source>

* The GRASS GIS temporal framework will be utilized and the pygrass module interface
* PLY will be used for lexical analysis and parser generation
* Temporal algebra will be equivalent for booth modules with about 60 internal variables and functions

=== Improve GRASS' kriging and 3D interpolation capabilities ===

One of GRASS' most outstanding features is its support for 3D raster (voxel) data.
This GSoC project aims to significantly enhance the methods for interpolation data in voxel space.
Currently, GRASS offers spline-based interpolation of 3D vector points to 3D voxel data.
We plan to add the following:

* 3D geostatistics/kriging
* 3D interpolation using radial basis functions (RBF)
* transition probability models (TBM)
* stratigraphic modeling

Available mentors:

* Benjamin Ducke

'''Notes on 3D kriging''':
Since GRASS currently lacks native geostatistical capabilities, this project will cover 3D 'and' 2D variograms, kriging interpolation, etc. There are already efforts underway in the GRASS community to supply substantial, geostatistical functionality and we expect this project to make full use of them (see [http://lists.osgeo.org/pipermail/grass-dev/2013-April/063389.html]).

'''Notes on radial basis functions (RBF)''':
RBF are straight-forward interpolation functions. Most GIS users will be aware of Inverse Distance Weighting, which is just one specific case of RBF. In 3D interpolation, RBF provide simple and efficient interpolators useful for dense 3D samples (or for producing incomplete models from sparse samples).

'''Notes on transition probability models (TBM)''':
TBMs allow to interpolate category (integer) data, such as soil classes in 3D space. Naturally, the results of such an interpolation will not be as accurate or useful as that of interpolation continuous data via splines or kriging. However, soil horizons, layers et al. are very common data in soil sciences and geology (bore hole samples!) and there is currently no robust method for interpolating such data in GRASS. There is a FORTRAN implementation of TBM called T-PROGS (by Steven F. Carle) that is in the public domain. T-PROGS could be run from within GRASS as a command line tool or translated to C and converted into a "real" GRASS module (see [http://www.xmswiki.com/xms/GMS:T-PROGS]; see also [http://chl.erdc.usace.army.mil/chl.aspx?p=s&a=ARTICLES;37&g=50]).

'''Notes on stratigraphic modeling''':
Another approach to soil horizon interpolation, that may be easy to implement in GRASS is documented here: http://chl.erdc.usace.army.mil/chl.aspx?p=s&a=ARTICLES;41&g=50.

See also these GRASS mailing list posts for further information:

'''Further information'''

http://lists.osgeo.org/pipermail/grass-user/2010-January/054246.html

http://lists.osgeo.org/pipermail/grass-dev/2013-April/063389.html

GRASS SoC Ideas 2013

2013-05-01T15:09:58Z

⚠️Benducke: /* Temporal GIS Algebra for raster and vector data */

<center>
[[Image:grasslogo_vector_small.png|link=http://grass.osgeo.org]] @ [[Image:Gsoc-2013-logo-color.jpg|250px|link=http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2013]] @ [[Image:OSGeo 220pix.png|link=http://www.osgeo.org]]
</center>

__TOC__

== About ==

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code_2013 Google Summer of Code 2013] (see the [http://www.google-melange.com/document/show/gsoc_program/google/gsoc2013/help_page#2._What_is_the_program_timeline timeline]). Here we will list project ideas and and other information related to the GRASS GSoC projects.

== Ideas ==

* '''Also review ideas from''' [[GRASS SoC Ideas 2009#Ideas|2009]], [[GRASS SoC Ideas 2010#Ideas|2010]], [[GRASS SoC Ideas 2011#Ideas|2011]] and [[GRASS SoC Ideas 2012#Ideas|2012]] which are still open.

* Project ideas of '''your own''' are also most welcome and often the best.

=== General ===

* Implement a buffered binary balanced search tree using external memory: Rationale: some modules and library functions use a binary search tree, which can lead to out-of-memory errors for large datasets. A buffered binary balanced search tree using external memory would solve this problem and enhance the capability of GRASS to work with large datasets on limited hardware resources.

* [[Parallel_GRASS_jobs|Parallelize]] CPU-heavy modules using [[OpenMP]], OpenCL ([[GPU]]), and/or pthreads.

* If you're really stuck for ideas, [https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&group=component&order=priority&col=id&col=summary&col=status&col=type&col=owner&col=priority&col=milestone&type=enhancement hunt around the wish list in the trac system].

* Clean-room write a LGPL or BSD/MIT-X GRASS data format plugin for GDAL/OGR. An option should exist to support both GRASS 6 and 7 versions of the format.
: Why is a new plugin needed? Add here

* Improve and fix bugs in the QGIS GRASS Toolbox. Generally make it smoother to pass projects and workflows between the two.
: Or simply use [[GRASS and Sextante|Sextante plugin in QGIS]] which does this already

=== Symbology / Cartography ===

* Allow display of a vector legend in the map display (equivalent to current {{cmd|d.legend}} implementation for rasters)

* Expand [[IconSymbols|symbology]] and re-classify groups
:: ''note that SoC only accepts coding projects, not graphics design or documentation projects.''
:* Add svg/eps support to a d.* module and {{Cmd|ps.map}} would be quite helpful. See the {{Cmd|d.graph}} help page and {{Cmd|ps.map}}'s "eps" and "vpoints" instructions. The first step would be to write a stand-alone tool in C to create d.graph commands; the second step would be to add as a new option in ''d.graph''; a third step would be to backport this to GRASS 6's graphics API. See also {{trac|733}} wish re. implementing Bézier curves in the display drivers.
:: Willing to co-mentor: Hamish

* Rework the complete set of thematic cartography tools such as {{Cmd|d.vect.thematic}} and {{Cmd|d.thematic.area}} and the related classification routines. This would comprise:
** Revising the classification algorithms already implemented and possibly adding new ones (kmeans, Jenks)
** Replace the existing d.vect.thematic script with a C-based module (in the likes of d.thematic.area) combing thematic cartography of points, lines and areas
** Include representation of legend of the thematic map
** Use [http://colorbrewer2.org/ colorbrewer] rules to make classifications pretty
** Implement one or several specific GUI interface(s) to this new module
:: ''note that since d.vect.thematic was written {{Cmd|d.vect}} has added DB-column based sizing, rotation, and other tasks making parts of d.vect.thematic ready for much simplification.''
:* Generalized ASCII table input for {{Cmd|d.legend}} (see {{trac|89}} wish)
:* Histogram sidebar support for {{Cmd|d.legend}} and {{Cmd|ps.map}} (see {{trac|1049}} wish)
:: Willing to co-mentor d.legend bits: Hamish

=== Imagery ===

* Based on the work on [[GRASS_GSoC_2012_Image_Segmentation|segmentation]] in GSoC 2012 develop routines for object-based (or region-based) image classification. This probably entails:
** Characterizing segments. This includes producing statistics such as mean, median, variance of the segmented data within each delineated segment (customized interface to r.statistics2).
** Classifying segments based on the characteristics and (possibly) training areas
** Interface with other modules in a consistent workflow (i.cluster, r.fuzzy, etc)

* Implement hierarchical classification tools (e.g. being able to create a large class "forest" with subclasses of different types of forests). Hierarchical classification is already used internally by i.gensigset/i.smap. Hierarchical segmentation can currently be done by using the output of a previous run of i.segment as input for the next run of i.segment with increased threshold.

* Interface with the [http://www.orfeo-toolbox.org/otb/ Orfeo toolbox (OTB)], which is an open source, [http://www.itk.org ITK]-based, C++ library of (spatial) image processing library. OTB implements a very wide set of interesting features for anybody working with raster data - in particular satellite imagery: radiometric corrections, orthorectification, filtering, feature extraction, image segmentation, classification, change detection, etc.

=== Vector ===

# Line intersection: implement an efficient algorithm based on literature review, focusing on the [http://en.wikipedia.org/wiki/Bentley-Ottmann_algorithm Bentley-Ottmann algorithm] and its derivates. The best or best two should be implemented. Coupled to the problem of calculating line intersections is the problem of calculating segment intersections, currently implemented in [http://grass.osgeo.org/programming7/vector_2Vlib_2intersect_8c.html#ab4f5f3d99742378f0f284966f59bafe7 Vect_segment_intersection()] and [http://grass.osgeo.org/programming7/linecros_8c.html#a4fb52c4fc60df4fcae5e676134f08be9 dig_find_intersection()], which could also be replaced with more efficient algorithms.
#* Rationale: the current function Vect_line_intersection() is "home-brew" and rather slow for lines with many segments, whereas the Bentley-Ottmann algorithm can find line intersections in logarithmic time per intersection.
#* Requirements: at least interest in, preferably knowledge of the art of searching and sorting (search trees, priority queues, heaps).
#* Implementation goals: One function to search for intersections between two lines, ignoring self-intersections, and another function to test one single line for self-intersections. The API and output should be compatible with the current Vect_line_intersection() function. Optionally an alternative to Vect_segment_intersection().
# ''Your suggestion here!''

'''Willing to Mentor:''' Markus Metz

=== Temporal GIS Algebra for raster and vector data ===

We (Soeren Gebbert and Thomas Leppelt) would like to develop a temporal GIS algebra for raster and vector data in GRASS7.

Role:
* Mentor: Soeren Gebbert
* GSoC Student: Thomas Leppelt

Implementation goals:

* Spatio-temporal vector algebra module t.vect.mapcalc
** The algebra will be based on vector map operations provided from {{Cmd|v.overlay}} (and, or, xor, not), {{Cmd|v.buffer}} (buff_point, buff_line, buff_area), {{Cmd|v.patch}} (patch), ... , temporal variables (day of year, weekday, datum, time, ...) and temporal topology relations (predecessor, successor, follows, equals, ...)
** The resulting module will be able to process space time vector datasets using expressions like:

<source lang="bash">
# Compute the intersection between the space time vector datasets A and B
# from maps with equal time stamps. The STVDS A is used as temporal reference.
# A new STVDS C will be created with the same time stamps as A.
t.vect.mapcalc inputs=A,B timeref=A output=C expr="C = if(equal(B), and(A,B))"

time |STVDS|STVDS|STVDS
stamp | A | B | C
-------------------------------------
Jan 2001 | a1 | b1 | v.overlay ain=a1 bin=b1 op=and out=c1
Feb 2001 | a2 | |
Mar 2001 | | b2 |
Apr 2001 | a3 | |
May 2001 | a4 | b3 | v.overlay ain=a4 bin=b3 op=and out=c2
Jun 2001 | | b4 |

# Nested operations are supported and temporal neighborhood computation
t.vect.mapcalc input=A,B,C tempref=A output=D \
expr="D = if(successor(B) && predecessor(C), and(A, xor(successor(B), buff_point(predecessor(C), 100)))"

# Date and time can be used in the expression
t.vect.mapcalc input=A,B timeref=A output=C \
expr="C = if(start_year() >= 2001 && start_month() > 6, and(A,B), not(A,B))"
</source>

* Spatio-temporal raster algebra module t.rast.mapcalc
** The algebra will be based on the existing {{Cmd|r.mapcalc}} raster map algebra, temporal variables (day of year, weekday, datum, time, ...) and temporal topology relations (predecessor, successor, follows, equals, ...)
{{GSoC}}
** The resulting module will be able to process space time raster datasets using expressions like:

<source lang="bash">
# Compute the sum between the space time raster datasets A and B
# from maps with equal time stamps. The STRDS A is used as temporal reference.
# A new STRDS C will be created with the same time stamps as A.
t.rast.mapcalc inputs=A,B timeref=A output=C expr="C = if(equal(B), A + B)"

# Spatio-temporal neighborhood computation. STRDS C will have the same time stamps as A.
t.rast.mapcalc input=B timeref=A output=C \
expr="C = if(successor(B) && predecessor(B), (successor(B)[0,0] + B[0,0] + predecessor(B)[0,0])/3.0, B[0,0])"
</source>

* The GRASS GIS temporal framework will be utilized and the pygrass module interface
* PLY will be used for lexical analysis and parser generation
* Temporal algebra will be equivalent for booth modules with about 60 internal variables and functions

=== Improve GRASS' kriging and 3D interpolation capabilities ===

One of GRASS' most outstanding features is its support for 3D raster (voxel) data.
This GSoC project aims to significantly enhance the methods for interpolation data in voxel space.
Currently, GRASS offers spline-based interpolation of 3D vector points to 3D voxel data.
We plan to add the following:

* 3D geostatistics/kriging
* 3D interpolation using radial basis functions (RBF)
* transition probability models (TBM)
* stratigraphic modeling

'''Notes on 3D kriging'''
Since GRASS currently lacks native geostatistical capabilities, this project will cover 3D 'and' 2D variograms, kriging interpolation, etc. There are already efforts underway in the GRASS community to supply substantial, geostatistical functionality and we expect this project to make full use of them (see [http://lists.osgeo.org/pipermail/grass-dev/2013-April/063389.html]).

'''Notes on radial basis functions (RBF)'''
RBF are straight-forward interpolation functions. Most GIS users will be aware of Inverse Distance Weighting, which is just one specific case of RBF. In 3D interpolation, RBF provide simple and efficient interpolators useful for dense 3D samples (or for producing incomplete models from sparse samples).

'''Notes on transition probability models (TBM)'''
TBMs allow to interpolate category (integer) data, such as soil classes in 3D space. Naturally, the results of such an interpolation will not be as accurate or useful as that of interpolation continuous data via splines or kriging. However, soil horizons, layers et al. are very common data in soil sciences and geology (bore hole samples!) and there is currently no robust method for interpolating such data in GRASS. There is a FORTRAN implementation of TBM called T-PROGS (by Steven F. Carle) that is in the public domain. T-PROGS could be run from within GRASS as a command line tool or translated to C and converted into a "real" GRASS module (see [http://www.xmswiki.com/xms/GMS:T-PROGS]; see also [http://chl.erdc.usace.army.mil/chl.aspx?p=s&a=ARTICLES;37&g=50]).

'''Notes on stratigraphic modeling'''
Another approach to soil horizon interpolation, that may be easy to implement in GRASS is documented here: http://chl.erdc.usace.army.mil/chl.aspx?p=s&a=ARTICLES;41&g=50.

See also these GRASS mailing list posts for further information:

'''Further information'''
http://lists.osgeo.org/pipermail/grass-user/2010-January/054246.html

http://lists.osgeo.org/pipermail/grass-dev/2013-April/063389.html

GRASS 7 ideas collection

2011-11-16T19:36:13Z

⚠️Benducke: /* 3D topology */

{{MoveToTrac}}

See also: http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== Maintenance of repository ==

For GRASS 7 development is used [http://svn.osgeo.org/grass/grass/trunk/ svn-trunk], for GRASS 6 development is used separated SVN branch [https://svn.osgeo.org/grass/grass/branches/develbranch_6 develbranch_6].

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

== Terminology ==

See [[GRASS 7 Terminology]].

== List of new features in GRASS 7 (already implemented) ==

See http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== API to access algorithms in modules ==

We need to better expose the "knowledge" which is contained at module level. We want to have it accessible via API, exposed in various programming languages such as C, Python, Perl, Java, ..

Update 1/2011: Python ctypes interface available

== Raster ==

See also
* [[Replacement raster format]].
* [http://trac.osgeo.org/grass/wiki/Grass7/RasterLib/ListOfFunctions Function name changes from GRASS 6 to GRASS 7]

=== Library ===
* allowing nulls to be embedded
* Insert 'vertical' 2d rasters (e.g. [http://woodshole.er.usgs.gov/project-pages/longislandsound/images/Ghist_square2.jpg geophysical survey data])
* Rewrite library from scratch. See [http://lists.osgeo.org/pipermail/grass-dev/2006-August/025153.html suggestions]
* <strike>Split libgis into [http://trac.osgeo.org/grass/wiki/Grass7RasterLib G_() part and Rast_() part]</strike> - done.
* <strike>[http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" via GDAL]</strike> - done.

Raster map history:
* In 7.0, the fields of the history structure are dynamically allocated. You have to use Rast_set_history() or Rast_format_history() to set fields. The the HIST_* constants have to be used.

=== Modules ===

==== rename ====
* rename r.in.gdal to r.import - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename r.out.gdal to r.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* <strike>rename r.volume 'data' parameter to something more standard like 'input'</strike>

==== remove ====
* Remove r.bitpattern since r.mapcalc does it more nicely now
* Remove r.in.arc and r.out.arc, '''if''' a [http://intevation.de/rt/webrt?serial_num=4897 related bug in r.in.gdal] is fixed. The [http://bugzilla.remotesensing.org/show_bug.cgi?id=1071 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.
: see delta comment about r.out.tiff below, sometimes the simple stuff works best! --HB
:: Ditto.

* remove '''r.resample''' and <strike>'''r.bilinear'''</strike> in favor of '''r.resamp.interp'''
: TODO: double-check that r.resample is in fact fully replaced by 'r.resamp.interp's method=nearest'. ie check that an alternate useful method is not lost.
* <strike>remove '''r.univar.sh'''; newly implemented '''r.univar''' features cover it</strike> '''done.'''

* remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [http://intevation.de/rt/webrt?serial_num=3680 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 [https://svn.qgis.org/trac/ticket/348 QGIS bug#348]) --HB
:: However: code duplication, maintenance overhead, user confussion (more entries in GUI, more manual pages, why are there modules doing the same?).

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

==== Merge ====

* merge {{cmd|r.surf.idw}} and {{cmd|r.surf.idw2}}
: while r.surf.idw will only output CELL maps, it is Very Fast. (or that is to say, ''r.surf.idw2'' is Very Slow)

* {{cmd|r.mode}}, {{cmd|r.statistics}}, {{cmd|r.univar.sh}}, {{cmd|r.univar}}(2) - maybe they can be reduced to just r.statistics and r.univar? See [http://intevation.de/rt/webrt?serial_num=1848 RT #1848] and a [http://grass.itc.it/pipermail/grass-dev/2006-November/027665.html thread on the GRASS dev list]

* <strike> {{cmd|r.sum}}, {{cmd|r.average}}, {{cmd|r.median}}, have been removed, as equivalent functionality is available via r.statistics{,2,3}.</strike>

* {{cmd|r.resamp.rst}}: merge into {{cmd|r.resamp.interp}} to make resolution management identical to the other modules
: HB: eh? the options and algorithm are nothing alike.
:: MS: I meant that r.resamp.rst could be a subset of r.resamp.interp (yet another resampling algorithm next to nearest, bilinear, bicubic). I haven't considered that the number of rst options would make r.resamp.interp user interface much less clear. Maybe not such a good idea after all - user interface wise.

* {{cmd|r.in.wms}} and {{cmd|r.in.srtm}} into {{cmd|r.in.gdal}} thanks to native support for [http://www.gdal.org/frmt_wms.html WMS] and [http://www.gdal.org/frmt_various.html#SRTMHGT SRTM] in GDAL 1.5
: HB: just be careful that the GDAL version is as featureful and grid/cell center correct as the r.in.* versions. I suspect it might not be. r.in.wms needs further python rewrite with full XML and HTTP library support.

* {{cmd|r.buffer}} and {{cmd|r.grow}}
: HB: why? they do two fundamentally different things, and both work quite nicely right now. One works in cell space, the other geographic space (especially for lat/lon).
:: MS: Right. The 2 modules do different things. But it would be usefull if r.grow supported distance in units and r.buffer in cells. Could both share same code for distance options?

==== fix ====
* fix lseek() usage for Large File Support: see [http://grass.itc.it/pipermail/grass-dev/2006-December/028231.html 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)
* r.random should be split into 2 modules: one for generating a raster map with random points (alike v.random), and the other for sampling a raster map (alike v.what.rast). Vector functionality should be droped from r.random - a dupe of existing vector modules. -i and -z flags should be droped.
* v.random -z: read zmin and zmax from region settings, drop zmin and zmax. I.e. treat Z coord same as X,Y.

==== Good coding practice ====

* Input handling:

/* Define the different options */
input1 = G_define_standard_option(G_OPT_R_INPUT) ;
input1->key = _("albedo");
input1->description =_("Name of the Albedo map [0.0-1.0]");
input1->answer =_("albedo");
input1->guisection = _("Required");

In here you can find G_define_standard_option(G_OPT_R_INPUT) assuming
already those:
input1->type = TYPE_STRING;
input1->required = YES;
input1->gisprompt =_("old,cell,raster") ;

If your input is not required to run the module, you just create the
following line:
input1->required = NO;

* In a similar way, metadata/history storage:

G_short_history(result1, "raster", &history);
G_command_history(&history);
G_write_history(result1,&history);

* This is the standard incantation, but I have to find timestamp(), and
more details metadata maybe like sensor type for a start, or
source/origin of data... Can we make metadata having elements
(history->processing, history->timestamp, history->source(or
history->origin), etc?) then it could be filled up specifically.

* Or color palettes application is nice:

/* Color table for biomass */
G_init_colors(&colors);
G_add_color_rule(0,0,0,0,1,255,255,255,&colors);

* Changes (from Glynn):
I would prefer it if G_open_*_new() simply called
G_fatal_error() themselves if an error occurred. It's not as if there's
any reasonable alternative way to handle the error.

* Changes:

input = G_define_option(G_OPT_F(D?)_INPUT) ;
input->key =_("parameter");
input->type = TYPE_DOUBLE;
input->required = YES;
input->gisprompt =_("value, parameter");
input->description=_("Value of the parameter");
/*input->answer =_("0.000");*/
input->guisection = _("Required");

I could also think similarly for non-GRASS files actually
(configuration files sometimes need to be loaded separately)

== Vector ==
=== Radim's TODO list ===

[http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Vector TODO list]
* Particularly important: "Keep topology and spatial index in file instead of in memory" --ML
* v.in.ogr: split long boundaries to speed up topology cleaning. Implemented in GRASS 7, partial backport to GRASS 6.5 possible.
{|
||
[[Image:V.in.ogr_speed.png|400px|thumb|left|v.in.ogr speed comparison]]
|}

=== Library ===
* 2d 'vertical' vector data (e.g. [http://sofia.usgs.gov/publications/maps/florida_geology/Txsectionbh.jpg 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 [http://sourceforge.net/mailarchive/message.php?msg_name=340505ef0601170244n1b5fe25bhd0a3eba7342b78d4%40mail.gmail.com 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 - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.out.ogr to v.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.mkgrid to v.grid - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.univar.sh to v.db.univar ([http://grass.itc.it/pipermail/grass-dev/2007-May/030883.html comment])

==== remove ====

* Remove [http://intevation.de/rt/webrt?serial_num=3600 doubled units in v.to.db GUI]

==== merge ====
* merge v.select and v.overlay
: needs discussion, they are doing fundamentally different things --HB

* merge {{cmd|v.sample}} and {{cmd|v.what.rast}}
: See a feature request <strike>[http://wald.intevation.org/tracker/index.php?func=detail&aid=506&group_id=21&atid=188 #506]</strike> in GForge.
: see also {{cmd|v.rast.stats}} and {{AddonCmd|v.what.rast.buffer}} addon

==== fix ====
* Fix the [http://intevation.de/rt/webrt?serial_num=3623 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 ??)
* <strike>implement Douglas-Peucker generalization ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/ C code file])to substitute prune tool of v.clean ([http://grass.itc.it/pipermail/grass-dev/2007-May/thread.html#31446 done]?, see also GSoC)</strike>
** This is done. [http://grass.osgeo.org/grass63/manuals/html63_user/v.generalize.html 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

=== 3D topology ===

Currently, GRASS' topological cleaning is 2D only. This will regularly corrupt 3D data that is actually topologically correct in 3D space, but appears incorrect in 2D space (e.g. 3D polygons that ''appear'' to overlap or have zero-area in the X-Y geographic reference plane). Therefore, ''v.clean'' in GRASS 7 should become more competent at handling 3D topology. This is a sketch of how to implement the same level of topology support that 2D geometries currently have in 3D space.

====Problem structure====

The classes of potential topological errors depend on the geometry type (point, line, polygon), in 3D just as in 2D. Each more complex geometry type inherits the potential problems of the less complex types, and adds its own.

*3D topological problems for points reduce to coincidence in 3D space.
*3D topological problems for lines are over- and undershoots as well as duplicate vertices. These are completely equivalent to the same problem in 2D space.
*3D topological problems for polygons appear much more complex, as they include areal overlap in 3D, and shared boundaries between adjacent polygons. But this complexity can be reduced significantly. Only polygons that lie in the same plane (including a small error margin -- could be implemented just like the minimum error option in ''v.clean'') can get into topological trouble with each other: if two polygons do not lie in the same plane, then by definition they cannot overlap, only intersect. (It is open to debate, whether an intersection of polygons in 3D space would constitute a topological error.) Likewise, adjacent polygons can only have a shared boundary if they are neighbors on the same plane.

====Basic approach====

As a result, the topological cleaning could proceed as follows.

#All 3D polygons need to be '''planar''', i.e. all of their vertices must lie on the same plane. If they are not, then this is a topological error, and the polygon needs to be planarized by ''v.clean'' (add a "planarize" action -- also potentially useful for other geometry types). Planarization is done by first calculating the plane equation of the polygon (a simple equation that defines the location and orientation of a best-fit 2D plane through all vertices) and then reprojecting each of its original vertices to the plane defined by the plane equation (it could make sense to store the plane equations as part of the topological data structure). Planarization needs to be carried out for both boundaries and islands.
#Once planarized, all polygons can be subjected to the exact same topological cleaning as 2D polygons:
##After planarization, group all polygons that lie on the same plane.
##For each "plane group": reproject all vertices to the geographic X-Y reference plane. Run the topological cleaning just like for 2D polygons, but preserve the Z coordinates.
##Then revert the projection of all vertices back to the group's original reference plane, using the plane equation.
##Do the same with the next "plane group" until all polygons have been processed.
#Faces (3D triangles) are primitives that are part of more complex 3D geometries (including TINs and 3D hulls). Topological problems involving such geometries are too complex to handle in GIS. Thus, faces should not be checked for overlap. GRASS GIS should just assume that faces are part of complex geometries that are not to be subjected to analytical treatment, but simple tasks, such as visualization, only. Therefore, only basic cleaning (check for duplicate coordinates, zero-area triangles, etc.) should be carried out. Faces are always planar by definition.
#The areas and centroids of both faces and planar polygons can be calculated in 3D space just as they can be calculated in 2D space.

====Implementation details====

A simple algorithm for computing the plane equation of a set of vertices is <missing URL> available in the form of Newell's Method. This method requires three points to define a plane. This requirement is met by even the most simply polygons. However <missing URL>: "Newell's method is known to fail if the 3 points are chosen around a concave corner - the normal of the resulting plane will point in the direction opposite to the expected one." (This should be avoidable by taking three vertices at the extreme edges.)

Since the planar equation is a best-fit model, not always an exact solution, a warning should be issued if an error threshold is reached.

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* <strike>Add new partial differential equation (PDE) library with OpenMP support</strike> (GRASS 6.3)

=== Modules ===

* g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [http://intevation.de/rt/webrt?serial_num=3009].
: controversial, needs more discussion --HB
* g.region
** [http://grass.itc.it/pipermail/grassuser/2007-February/038337.html Glynn's notes] - cleaning the print flags and new <tt>print=</tt> option
** <strike>Support '''vector's 3rd''' dimension in '''g.region vect= [-a]''', '''[res=]''', like the 2d extents are (or should be)</strike> see [http://trac.osgeo.org/grass/ticket/121 trac #121]

== Database ==
=== Library ===

* <strike>establish SQLite as default DBMI driver for vector attribute storage (DBF is too limited).</strike> '''done May 2008.'''

=== Modules ===
* allow cross-mapset database access, i.e. parse the '@mapset' notation appended to vector names (requires access via possibly different DBMI drivers)

==== rename ====
* rename db.in.ogr to db.import

== Imagery ==

Page has been moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib

== 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 ==

The page moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/DisplayLib

== Postscript ==
=== Modules ===
ps.map
* remove scale parameter
: -> from the command line, not the map instruction
* rename sizecol to sizecolumn (remove the given warning)
* use PAL/JPAL [http://geosysin.iict.ch/PAL cartographic labelling library] (GPL, C++ language, JNI wrapper)

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 [http://intevation.de/rt/webrt?serial_num=2969 '''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 [http://grass.itc.it/pipermail/grass-dev/2007-August/032607.html 1].

* Eliminate Init.sh. Glynn explains on [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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 [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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."
: Actually, I (Glynn) no longer think it's that simple. If other users can create directories within your mapset, they can create directories which you cannot remove, and in which you cannot add, remove or modify files. And this is quite likely to happen: most users will have a umask of 0022 or worse, meaning that other users (i.e. you) cannot modify any files or directories which they create.

== Data management ==

* store vertical units on per-map base, using code from [http://www.gnu.org/software/units/ 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 [http://lists.maptools.org/pipermail/gdal-dev/2005-October/006857.html 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? [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d r.rast4d]

== Visualization ==

* better support for faces and kernels in libgis
: not really Visualization, but....

== CLI ==

=== Parameters standardization ===

* Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup documents/parameter_proposal.txt]

=== Flags standardization ===

* Get rid of 'quiet/verbose' flags, preparation in GRASS 6, e.g.:
<pre>
/* 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"));
}
</pre>

== GUI ==

* Multiplatform
* Fast, minimalist, number of windows reduced
* Novice, ...., Expert profiles for the GUI (with reduced features), tailored for use cases, e.g. 3D models of a risk map,
* link from application to the relevant wiki online support, so that non-programmers can contribute to GRASS support
* compile wiki online content and help pages into a offline version of help pages for usage in GRASS without internet access.
* Manageable also from command line via d.* modules
* Facilitating easy development of custom GUI application based on GRASS
* <strike>drop '''d.m'''</strike> {{done}}
* <strike>drop '''gis.m'''</strike> {{done}}

* → [[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 -- <cite> frankie at #grass irc</cite>
** 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 -- <cite> frankie at #grass irc</cite>
* Creating $HOME/.grass7 directory for {{done}}
** Custom fonts
** r.li and other modules temp. files
** GEM addons installation {{done}}
** Default path for custom scripts
** Custom symbols and EPS fill patterns
** Custom color maps
** Add here new item...

* [[GRASS repository layout proposal]]

== User Wishes ==

''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[User:MarisN|MarisN]] 12:00, 4 August 2006 (CEST)
* here are some examples to get inspired (apparently that's already possible):
** [http://skagit.meas.ncsu.edu/~helena/publwork/grasskey02/grass02talk10.html dynamic surfaces and volumes]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/cenntenial/water01dsmall.gif some water]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/balsam/fanimwalk.gif particles]
** [http://www.fhpv.unipo.sk/kagerr/pracovnici/hofierka/pv_results.html solar radiation and energy]
* Convince the users to use ParaView [http://www.paraview.org] for sophisticated animations --[[User:Huhabla|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 [http://www.llnl.gov/visit/ VisIt software], it should be able to read GRASS maps directly via GDAL

== Complete GRASS Test Suite: see activity on [[Test_Suite | Test Suite development page]] ==
* base a comprehensive test suite on [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/?C=M;O=D Soeren's GRASS Test Suite]
* automated error checking on all modules to catch data corruption issues

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS 7 ideas collection

2011-11-16T12:34:53Z

⚠️Benducke: /* Implementation details */

{{MoveToTrac}}

See also: http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== Maintenance of repository ==

For GRASS 7 development is used [http://svn.osgeo.org/grass/grass/trunk/ svn-trunk], for GRASS 6 development is used separated SVN branch [https://svn.osgeo.org/grass/grass/branches/develbranch_6 develbranch_6].

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

== Terminology ==

See [[GRASS 7 Terminology]].

== List of new features in GRASS 7 (already implemented) ==

See http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== API to access algorithms in modules ==

We need to better expose the "knowledge" which is contained at module level. We want to have it accessible via API, exposed in various programming languages such as C, Python, Perl, Java, ..

Update 1/2011: Python ctypes interface available

== Raster ==

See also
* [[Replacement raster format]].
* [http://trac.osgeo.org/grass/wiki/Grass7/RasterLib/ListOfFunctions Function name changes from GRASS 6 to GRASS 7]

=== Library ===
* allowing nulls to be embedded
* Insert 'vertical' 2d rasters (e.g. [http://woodshole.er.usgs.gov/project-pages/longislandsound/images/Ghist_square2.jpg geophysical survey data])
* Rewrite library from scratch. See [http://lists.osgeo.org/pipermail/grass-dev/2006-August/025153.html suggestions]
* <strike>Split libgis into [http://trac.osgeo.org/grass/wiki/Grass7RasterLib G_() part and Rast_() part]</strike> - done.
* <strike>[http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" via GDAL]</strike> - done.

Raster map history:
* In 7.0, the fields of the history structure are dynamically allocated. You have to use Rast_set_history() or Rast_format_history() to set fields. The the HIST_* constants have to be used.

=== Modules ===

==== rename ====
* rename r.in.gdal to r.import - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename r.out.gdal to r.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* <strike>rename r.volume 'data' parameter to something more standard like 'input'</strike>

==== remove ====
* Remove r.bitpattern since r.mapcalc does it more nicely now
* Remove r.in.arc and r.out.arc, '''if''' a [http://intevation.de/rt/webrt?serial_num=4897 related bug in r.in.gdal] is fixed. The [http://bugzilla.remotesensing.org/show_bug.cgi?id=1071 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.
: see delta comment about r.out.tiff below, sometimes the simple stuff works best! --HB
:: Ditto.

* remove '''r.resample''' and <strike>'''r.bilinear'''</strike> in favor of '''r.resamp.interp'''
: TODO: double-check that r.resample is in fact fully replaced by 'r.resamp.interp's method=nearest'. ie check that an alternate useful method is not lost.
* <strike>remove '''r.univar.sh'''; newly implemented '''r.univar''' features cover it</strike> '''done.'''

* remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [http://intevation.de/rt/webrt?serial_num=3680 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 [https://svn.qgis.org/trac/ticket/348 QGIS bug#348]) --HB
:: However: code duplication, maintenance overhead, user confussion (more entries in GUI, more manual pages, why are there modules doing the same?).

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

==== Merge ====

* merge {{cmd|r.surf.idw}} and {{cmd|r.surf.idw2}}
: while r.surf.idw will only output CELL maps, it is Very Fast. (or that is to say, ''r.surf.idw2'' is Very Slow)

* {{cmd|r.mode}}, {{cmd|r.statistics}}, {{cmd|r.univar.sh}}, {{cmd|r.univar}}(2) - maybe they can be reduced to just r.statistics and r.univar? See [http://intevation.de/rt/webrt?serial_num=1848 RT #1848] and a [http://grass.itc.it/pipermail/grass-dev/2006-November/027665.html thread on the GRASS dev list]

* <strike> {{cmd|r.sum}}, {{cmd|r.average}}, {{cmd|r.median}}, have been removed, as equivalent functionality is available via r.statistics{,2,3}.</strike>

* {{cmd|r.resamp.rst}}: merge into {{cmd|r.resamp.interp}} to make resolution management identical to the other modules
: HB: eh? the options and algorithm are nothing alike.
:: MS: I meant that r.resamp.rst could be a subset of r.resamp.interp (yet another resampling algorithm next to nearest, bilinear, bicubic). I haven't considered that the number of rst options would make r.resamp.interp user interface much less clear. Maybe not such a good idea after all - user interface wise.

* {{cmd|r.in.wms}} and {{cmd|r.in.srtm}} into {{cmd|r.in.gdal}} thanks to native support for [http://www.gdal.org/frmt_wms.html WMS] and [http://www.gdal.org/frmt_various.html#SRTMHGT SRTM] in GDAL 1.5
: HB: just be careful that the GDAL version is as featureful and grid/cell center correct as the r.in.* versions. I suspect it might not be. r.in.wms needs further python rewrite with full XML and HTTP library support.

* {{cmd|r.buffer}} and {{cmd|r.grow}}
: HB: why? they do two fundamentally different things, and both work quite nicely right now. One works in cell space, the other geographic space (especially for lat/lon).
:: MS: Right. The 2 modules do different things. But it would be usefull if r.grow supported distance in units and r.buffer in cells. Could both share same code for distance options?

==== fix ====
* fix lseek() usage for Large File Support: see [http://grass.itc.it/pipermail/grass-dev/2006-December/028231.html 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)
* r.random should be split into 2 modules: one for generating a raster map with random points (alike v.random), and the other for sampling a raster map (alike v.what.rast). Vector functionality should be droped from r.random - a dupe of existing vector modules. -i and -z flags should be droped.
* v.random -z: read zmin and zmax from region settings, drop zmin and zmax. I.e. treat Z coord same as X,Y.

==== Good coding practice ====

* Input handling:

/* Define the different options */
input1 = G_define_standard_option(G_OPT_R_INPUT) ;
input1->key = _("albedo");
input1->description =_("Name of the Albedo map [0.0-1.0]");
input1->answer =_("albedo");
input1->guisection = _("Required");

In here you can find G_define_standard_option(G_OPT_R_INPUT) assuming
already those:
input1->type = TYPE_STRING;
input1->required = YES;
input1->gisprompt =_("old,cell,raster") ;

If your input is not required to run the module, you just create the
following line:
input1->required = NO;

* In a similar way, metadata/history storage:

G_short_history(result1, "raster", &history);
G_command_history(&history);
G_write_history(result1,&history);

* This is the standard incantation, but I have to find timestamp(), and
more details metadata maybe like sensor type for a start, or
source/origin of data... Can we make metadata having elements
(history->processing, history->timestamp, history->source(or
history->origin), etc?) then it could be filled up specifically.

* Or color palettes application is nice:

/* Color table for biomass */
G_init_colors(&colors);
G_add_color_rule(0,0,0,0,1,255,255,255,&colors);

* Changes (from Glynn):
I would prefer it if G_open_*_new() simply called
G_fatal_error() themselves if an error occurred. It's not as if there's
any reasonable alternative way to handle the error.

* Changes:

input = G_define_option(G_OPT_F(D?)_INPUT) ;
input->key =_("parameter");
input->type = TYPE_DOUBLE;
input->required = YES;
input->gisprompt =_("value, parameter");
input->description=_("Value of the parameter");
/*input->answer =_("0.000");*/
input->guisection = _("Required");

I could also think similarly for non-GRASS files actually
(configuration files sometimes need to be loaded separately)

== Vector ==
=== Radim's TODO list ===

[http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Vector TODO list]
* Particularly important: "Keep topology and spatial index in file instead of in memory" --ML
* v.in.ogr: split long boundaries to speed up topology cleaning. Implemented in GRASS 7, partial backport to GRASS 6.5 possible.
{|
||
[[Image:V.in.ogr_speed.png|400px|thumb|left|v.in.ogr speed comparison]]
|}

=== Library ===
* 2d 'vertical' vector data (e.g. [http://sofia.usgs.gov/publications/maps/florida_geology/Txsectionbh.jpg 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 [http://sourceforge.net/mailarchive/message.php?msg_name=340505ef0601170244n1b5fe25bhd0a3eba7342b78d4%40mail.gmail.com 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 - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.out.ogr to v.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.mkgrid to v.grid - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.univar.sh to v.db.univar ([http://grass.itc.it/pipermail/grass-dev/2007-May/030883.html comment])

==== remove ====

* Remove [http://intevation.de/rt/webrt?serial_num=3600 doubled units in v.to.db GUI]

==== merge ====
* merge v.select and v.overlay
: needs discussion, they are doing fundamentally different things --HB

* merge {{cmd|v.sample}} and {{cmd|v.what.rast}}
: See a feature request <strike>[http://wald.intevation.org/tracker/index.php?func=detail&aid=506&group_id=21&atid=188 #506]</strike> in GForge.
: see also {{cmd|v.rast.stats}} and {{AddonCmd|v.what.rast.buffer}} addon

==== fix ====
* Fix the [http://intevation.de/rt/webrt?serial_num=3623 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 ??)
* <strike>implement Douglas-Peucker generalization ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/ C code file])to substitute prune tool of v.clean ([http://grass.itc.it/pipermail/grass-dev/2007-May/thread.html#31446 done]?, see also GSoC)</strike>
** This is done. [http://grass.osgeo.org/grass63/manuals/html63_user/v.generalize.html 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

=== 3D topology ===

Currently, GRASS' topological cleaning is 2D only. This will regularly corrupt 3D data that is actually topologically correct in 3D space, but appears incorrect in 2D space (e.g. 3D polygons that ''appear'' to overlap or have zero-area in the X-Y geographic reference plane). Therefore, ''v.clean'' in GRASS 7 should become more competent at handling 3D topology. This is a sketch of how to implement the same level of topology support that 2D geometries currently have in 3D space.

====Problem structure====

The classes of potential topological errors depend on the geometry type (point, line, polygon), in 3D just as in 2D. Each more complex geometry type inherits the potential problems of the less complex types, and adds its own.

*3D topological problems for points reduce to coincidence in 3D space.
*3D topological problems for lines are over- and undershoots as well as duplicate vertices. These are completely equivalent to the same problem in 2D space.
*3D topological problems for polygons appear much more complex, as they include overlap in 3D. But this complexity can be reduced significantly. Only polygons that lie in the same plane (including a small error margin -- could be implemented just like the minimum error option in ''v.clean'') can get into topological trouble with each other: if two polygons do not lie in the same plane, then by definition they cannot overlap, only intersect. (It is open to debate, whether an intersection of polygons in 3D space would constitute a topological error.)

====Basic approach====

As a result, the topological cleaning could proceed as follows.

#All 3D polygons need to be '''planar''', i.e. all of their vertices must lie on the same plane. If they are not, then this is a topological error, and the polygon needs to be planarized by ''v.clean'' (add a "planarize" action -- also potentially useful for other geometry types). Planarization is done by first calculating the plane equation of the polygon (a simple equation that defines the location and orientation of a best-fit 2D plane through all vertices) and then reprojecting each of its original vertices to the plane defined by the plane equation (it could make sense to store the plane equations as part of the topological data structure). Planarization needs to be carried out for both boundaries and islands.
#Once planarized, all polygons can be subjected to the exact same topological cleaning as 2D polygons:
##After planarization, group all polygons that lie on the same plane.
##For each "plane group": reproject all vertices to the geographic X-Y reference plane. Run the topological cleaning just like for 2D polygons, but preserve the Z coordinates.
##Then revert the projection of all vertices back to the group's original reference plane, using the plane equation.
##Do the same with the next "plane group" until all polygons have been processed.
#Faces (3D triangles) are primitives that are part of more complex 3D geometries (including TINs and 3D hulls). Topological problems involving such geometries are too complex to handle in GIS. Thus, faces should not be checked for overlap. GRASS GIS should just assume that faces are part of complex geometries that are not to be subjected to analytical treatment, but simple tasks, such as visualization, only. Therefore, only basic cleaning (check for duplicate coordinates, zero-area triangles, etc.) should be carried out. Faces are always planar by definition.
#The areas and centroids of both faces and planar polygons can be calculated in 3D space just as they can be calculated in 2D space.

====Implementation details====

A simple algorithm for computing the plane equation of a set of vertices is <missing URL> available in the form of Newell's Method. This method requires three points to define a plane. This requirement is met by even the most simply polygons. However <missing URL>: "Newell's method is known to fail if the 3 points are chosen around a concave corner - the normal of the resulting plane will point in the direction opposite to the expected one." (This should be avoidable by taking three vertices at the extreme edges.)

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* <strike>Add new partial differential equation (PDE) library with OpenMP support</strike> (GRASS 6.3)

=== Modules ===

* g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [http://intevation.de/rt/webrt?serial_num=3009].
: controversial, needs more discussion --HB
* g.region
** [http://grass.itc.it/pipermail/grassuser/2007-February/038337.html Glynn's notes] - cleaning the print flags and new <tt>print=</tt> option
** <strike>Support '''vector's 3rd''' dimension in '''g.region vect= [-a]''', '''[res=]''', like the 2d extents are (or should be)</strike> see [http://trac.osgeo.org/grass/ticket/121 trac #121]

== Database ==
=== Library ===

* <strike>establish SQLite as default DBMI driver for vector attribute storage (DBF is too limited).</strike> '''done May 2008.'''

=== Modules ===
* allow cross-mapset database access, i.e. parse the '@mapset' notation appended to vector names (requires access via possibly different DBMI drivers)

==== rename ====
* rename db.in.ogr to db.import

== Imagery ==

Page has been moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib

== 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 ==

The page moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/DisplayLib

== Postscript ==
=== Modules ===
ps.map
* remove scale parameter
: -> from the command line, not the map instruction
* rename sizecol to sizecolumn (remove the given warning)
* use PAL/JPAL [http://geosysin.iict.ch/PAL cartographic labelling library] (GPL, C++ language, JNI wrapper)

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 [http://intevation.de/rt/webrt?serial_num=2969 '''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 [http://grass.itc.it/pipermail/grass-dev/2007-August/032607.html 1].

* Eliminate Init.sh. Glynn explains on [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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 [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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."
: Actually, I (Glynn) no longer think it's that simple. If other users can create directories within your mapset, they can create directories which you cannot remove, and in which you cannot add, remove or modify files. And this is quite likely to happen: most users will have a umask of 0022 or worse, meaning that other users (i.e. you) cannot modify any files or directories which they create.

== Data management ==

* store vertical units on per-map base, using code from [http://www.gnu.org/software/units/ 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 [http://lists.maptools.org/pipermail/gdal-dev/2005-October/006857.html 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? [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d r.rast4d]

== Visualization ==

* better support for faces and kernels in libgis
: not really Visualization, but....

== CLI ==

=== Parameters standardization ===

* Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup documents/parameter_proposal.txt]

=== Flags standardization ===

* Get rid of 'quiet/verbose' flags, preparation in GRASS 6, e.g.:
<pre>
/* 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"));
}
</pre>

== GUI ==

* Multiplatform
* Fast, minimalist, number of windows reduced
* Novice, ...., Expert profiles for the GUI (with reduced features), tailored for use cases, e.g. 3D models of a risk map,
* link from application to the relevant wiki online support, so that non-programmers can contribute to GRASS support
* compile wiki online content and help pages into a offline version of help pages for usage in GRASS without internet access.
* Manageable also from command line via d.* modules
* Facilitating easy development of custom GUI application based on GRASS
* <strike>drop '''d.m'''</strike> {{done}}
* <strike>drop '''gis.m'''</strike> {{done}}

* → [[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 -- <cite> frankie at #grass irc</cite>
** 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 -- <cite> frankie at #grass irc</cite>
* Creating $HOME/.grass7 directory for {{done}}
** Custom fonts
** r.li and other modules temp. files
** GEM addons installation {{done}}
** Default path for custom scripts
** Custom symbols and EPS fill patterns
** Custom color maps
** Add here new item...

* [[GRASS repository layout proposal]]

== User Wishes ==

''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[User:MarisN|MarisN]] 12:00, 4 August 2006 (CEST)
* here are some examples to get inspired (apparently that's already possible):
** [http://skagit.meas.ncsu.edu/~helena/publwork/grasskey02/grass02talk10.html dynamic surfaces and volumes]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/cenntenial/water01dsmall.gif some water]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/balsam/fanimwalk.gif particles]
** [http://www.fhpv.unipo.sk/kagerr/pracovnici/hofierka/pv_results.html solar radiation and energy]
* Convince the users to use ParaView [http://www.paraview.org] for sophisticated animations --[[User:Huhabla|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 [http://www.llnl.gov/visit/ VisIt software], it should be able to read GRASS maps directly via GDAL

== Complete GRASS Test Suite: see activity on [[Test_Suite | Test Suite development page]] ==
* base a comprehensive test suite on [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/?C=M;O=D Soeren's GRASS Test Suite]
* automated error checking on all modules to catch data corruption issues

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS 7 ideas collection

2011-11-16T12:32:34Z

⚠️Benducke: /* 3D topology */

{{MoveToTrac}}

See also: http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== Maintenance of repository ==

For GRASS 7 development is used [http://svn.osgeo.org/grass/grass/trunk/ svn-trunk], for GRASS 6 development is used separated SVN branch [https://svn.osgeo.org/grass/grass/branches/develbranch_6 develbranch_6].

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

== Terminology ==

See [[GRASS 7 Terminology]].

== List of new features in GRASS 7 (already implemented) ==

See http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== API to access algorithms in modules ==

We need to better expose the "knowledge" which is contained at module level. We want to have it accessible via API, exposed in various programming languages such as C, Python, Perl, Java, ..

Update 1/2011: Python ctypes interface available

== Raster ==

See also
* [[Replacement raster format]].
* [http://trac.osgeo.org/grass/wiki/Grass7/RasterLib/ListOfFunctions Function name changes from GRASS 6 to GRASS 7]

=== Library ===
* allowing nulls to be embedded
* Insert 'vertical' 2d rasters (e.g. [http://woodshole.er.usgs.gov/project-pages/longislandsound/images/Ghist_square2.jpg geophysical survey data])
* Rewrite library from scratch. See [http://lists.osgeo.org/pipermail/grass-dev/2006-August/025153.html suggestions]
* <strike>Split libgis into [http://trac.osgeo.org/grass/wiki/Grass7RasterLib G_() part and Rast_() part]</strike> - done.
* <strike>[http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" via GDAL]</strike> - done.

Raster map history:
* In 7.0, the fields of the history structure are dynamically allocated. You have to use Rast_set_history() or Rast_format_history() to set fields. The the HIST_* constants have to be used.

=== Modules ===

==== rename ====
* rename r.in.gdal to r.import - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename r.out.gdal to r.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* <strike>rename r.volume 'data' parameter to something more standard like 'input'</strike>

==== remove ====
* Remove r.bitpattern since r.mapcalc does it more nicely now
* Remove r.in.arc and r.out.arc, '''if''' a [http://intevation.de/rt/webrt?serial_num=4897 related bug in r.in.gdal] is fixed. The [http://bugzilla.remotesensing.org/show_bug.cgi?id=1071 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.
: see delta comment about r.out.tiff below, sometimes the simple stuff works best! --HB
:: Ditto.

* remove '''r.resample''' and <strike>'''r.bilinear'''</strike> in favor of '''r.resamp.interp'''
: TODO: double-check that r.resample is in fact fully replaced by 'r.resamp.interp's method=nearest'. ie check that an alternate useful method is not lost.
* <strike>remove '''r.univar.sh'''; newly implemented '''r.univar''' features cover it</strike> '''done.'''

* remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [http://intevation.de/rt/webrt?serial_num=3680 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 [https://svn.qgis.org/trac/ticket/348 QGIS bug#348]) --HB
:: However: code duplication, maintenance overhead, user confussion (more entries in GUI, more manual pages, why are there modules doing the same?).

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

==== Merge ====

* merge {{cmd|r.surf.idw}} and {{cmd|r.surf.idw2}}
: while r.surf.idw will only output CELL maps, it is Very Fast. (or that is to say, ''r.surf.idw2'' is Very Slow)

* {{cmd|r.mode}}, {{cmd|r.statistics}}, {{cmd|r.univar.sh}}, {{cmd|r.univar}}(2) - maybe they can be reduced to just r.statistics and r.univar? See [http://intevation.de/rt/webrt?serial_num=1848 RT #1848] and a [http://grass.itc.it/pipermail/grass-dev/2006-November/027665.html thread on the GRASS dev list]

* <strike> {{cmd|r.sum}}, {{cmd|r.average}}, {{cmd|r.median}}, have been removed, as equivalent functionality is available via r.statistics{,2,3}.</strike>

* {{cmd|r.resamp.rst}}: merge into {{cmd|r.resamp.interp}} to make resolution management identical to the other modules
: HB: eh? the options and algorithm are nothing alike.
:: MS: I meant that r.resamp.rst could be a subset of r.resamp.interp (yet another resampling algorithm next to nearest, bilinear, bicubic). I haven't considered that the number of rst options would make r.resamp.interp user interface much less clear. Maybe not such a good idea after all - user interface wise.

* {{cmd|r.in.wms}} and {{cmd|r.in.srtm}} into {{cmd|r.in.gdal}} thanks to native support for [http://www.gdal.org/frmt_wms.html WMS] and [http://www.gdal.org/frmt_various.html#SRTMHGT SRTM] in GDAL 1.5
: HB: just be careful that the GDAL version is as featureful and grid/cell center correct as the r.in.* versions. I suspect it might not be. r.in.wms needs further python rewrite with full XML and HTTP library support.

* {{cmd|r.buffer}} and {{cmd|r.grow}}
: HB: why? they do two fundamentally different things, and both work quite nicely right now. One works in cell space, the other geographic space (especially for lat/lon).
:: MS: Right. The 2 modules do different things. But it would be usefull if r.grow supported distance in units and r.buffer in cells. Could both share same code for distance options?

==== fix ====
* fix lseek() usage for Large File Support: see [http://grass.itc.it/pipermail/grass-dev/2006-December/028231.html 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)
* r.random should be split into 2 modules: one for generating a raster map with random points (alike v.random), and the other for sampling a raster map (alike v.what.rast). Vector functionality should be droped from r.random - a dupe of existing vector modules. -i and -z flags should be droped.
* v.random -z: read zmin and zmax from region settings, drop zmin and zmax. I.e. treat Z coord same as X,Y.

==== Good coding practice ====

* Input handling:

/* Define the different options */
input1 = G_define_standard_option(G_OPT_R_INPUT) ;
input1->key = _("albedo");
input1->description =_("Name of the Albedo map [0.0-1.0]");
input1->answer =_("albedo");
input1->guisection = _("Required");

In here you can find G_define_standard_option(G_OPT_R_INPUT) assuming
already those:
input1->type = TYPE_STRING;
input1->required = YES;
input1->gisprompt =_("old,cell,raster") ;

If your input is not required to run the module, you just create the
following line:
input1->required = NO;

* In a similar way, metadata/history storage:

G_short_history(result1, "raster", &history);
G_command_history(&history);
G_write_history(result1,&history);

* This is the standard incantation, but I have to find timestamp(), and
more details metadata maybe like sensor type for a start, or
source/origin of data... Can we make metadata having elements
(history->processing, history->timestamp, history->source(or
history->origin), etc?) then it could be filled up specifically.

* Or color palettes application is nice:

/* Color table for biomass */
G_init_colors(&colors);
G_add_color_rule(0,0,0,0,1,255,255,255,&colors);

* Changes (from Glynn):
I would prefer it if G_open_*_new() simply called
G_fatal_error() themselves if an error occurred. It's not as if there's
any reasonable alternative way to handle the error.

* Changes:

input = G_define_option(G_OPT_F(D?)_INPUT) ;
input->key =_("parameter");
input->type = TYPE_DOUBLE;
input->required = YES;
input->gisprompt =_("value, parameter");
input->description=_("Value of the parameter");
/*input->answer =_("0.000");*/
input->guisection = _("Required");

I could also think similarly for non-GRASS files actually
(configuration files sometimes need to be loaded separately)

== Vector ==
=== Radim's TODO list ===

[http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Vector TODO list]
* Particularly important: "Keep topology and spatial index in file instead of in memory" --ML
* v.in.ogr: split long boundaries to speed up topology cleaning. Implemented in GRASS 7, partial backport to GRASS 6.5 possible.
{|
||
[[Image:V.in.ogr_speed.png|400px|thumb|left|v.in.ogr speed comparison]]
|}

=== Library ===
* 2d 'vertical' vector data (e.g. [http://sofia.usgs.gov/publications/maps/florida_geology/Txsectionbh.jpg 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 [http://sourceforge.net/mailarchive/message.php?msg_name=340505ef0601170244n1b5fe25bhd0a3eba7342b78d4%40mail.gmail.com 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 - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.out.ogr to v.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.mkgrid to v.grid - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.univar.sh to v.db.univar ([http://grass.itc.it/pipermail/grass-dev/2007-May/030883.html comment])

==== remove ====

* Remove [http://intevation.de/rt/webrt?serial_num=3600 doubled units in v.to.db GUI]

==== merge ====
* merge v.select and v.overlay
: needs discussion, they are doing fundamentally different things --HB

* merge {{cmd|v.sample}} and {{cmd|v.what.rast}}
: See a feature request <strike>[http://wald.intevation.org/tracker/index.php?func=detail&aid=506&group_id=21&atid=188 #506]</strike> in GForge.
: see also {{cmd|v.rast.stats}} and {{AddonCmd|v.what.rast.buffer}} addon

==== fix ====
* Fix the [http://intevation.de/rt/webrt?serial_num=3623 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 ??)
* <strike>implement Douglas-Peucker generalization ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/ C code file])to substitute prune tool of v.clean ([http://grass.itc.it/pipermail/grass-dev/2007-May/thread.html#31446 done]?, see also GSoC)</strike>
** This is done. [http://grass.osgeo.org/grass63/manuals/html63_user/v.generalize.html 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

=== 3D topology ===

Currently, GRASS' topological cleaning is 2D only. This will regularly corrupt 3D data that is actually topologically correct in 3D space, but appears incorrect in 2D space (e.g. 3D polygons that ''appear'' to overlap or have zero-area in the X-Y geographic reference plane). Therefore, ''v.clean'' in GRASS 7 should become more competent at handling 3D topology. This is a sketch of how to implement the same level of topology support that 2D geometries currently have in 3D space.

====Problem structure====

The classes of potential topological errors depend on the geometry type (point, line, polygon), in 3D just as in 2D. Each more complex geometry type inherits the potential problems of the less complex types, and adds its own.

*3D topological problems for points reduce to coincidence in 3D space.
*3D topological problems for lines are over- and undershoots as well as duplicate vertices. These are completely equivalent to the same problem in 2D space.
*3D topological problems for polygons appear much more complex, as they include overlap in 3D. But this complexity can be reduced significantly. Only polygons that lie in the same plane (including a small error margin -- could be implemented just like the minimum error option in ''v.clean'') can get into topological trouble with each other: if two polygons do not lie in the same plane, then by definition they cannot overlap, only intersect. (It is open to debate, whether an intersection of polygons in 3D space would constitute a topological error.)

====Basic approach====

As a result, the topological cleaning could proceed as follows.

#All 3D polygons need to be '''planar''', i.e. all of their vertices must lie on the same plane. If they are not, then this is a topological error, and the polygon needs to be planarized by ''v.clean'' (add a "planarize" action -- also potentially useful for other geometry types). Planarization is done by first calculating the plane equation of the polygon (a simple equation that defines the location and orientation of a best-fit 2D plane through all vertices) and then reprojecting each of its original vertices to the plane defined by the plane equation (it could make sense to store the plane equations as part of the topological data structure). Planarization needs to be carried out for both boundaries and islands.
#Once planarized, all polygons can be subjected to the exact same topological cleaning as 2D polygons:
##After planarization, group all polygons that lie on the same plane.
##For each "plane group": reproject all vertices to the geographic X-Y reference plane. Run the topological cleaning just like for 2D polygons, but preserve the Z coordinates.
##Then revert the projection of all vertices back to the group's original reference plane, using the plane equation.
##Do the same with the next "plane group" until all polygons have been processed.
#Faces (3D triangles) are primitives that are part of more complex 3D geometries (including TINs and 3D hulls). Topological problems involving such geometries are too complex to handle in GIS. Thus, faces should not be checked for overlap. GRASS GIS should just assume that faces are part of complex geometries that are not to be subjected to analytical treatment, but simple tasks, such as visualization, only. Therefore, only basic cleaning (check for duplicate coordinates, zero-area triangles, etc.) should be carried out. Faces are always planar by definition.
#The areas and centroids of both faces and planar polygons can be calculated in 3D space just as they can be calculated in 2D space.

====Implementation details====

A simple algorithm for computing the plane equation of a set of vertices is <missing URL> available in the form of Newell's Method. This method requires three points to define a plane. This requirement is met by even the most simply polygons. However <missing URL>: "Newell's method is known to fail if the 3 points are chosen around a concave corner - the normal of the resulting plane will point in the direction opposite to the expected one."

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* <strike>Add new partial differential equation (PDE) library with OpenMP support</strike> (GRASS 6.3)

=== Modules ===

* g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [http://intevation.de/rt/webrt?serial_num=3009].
: controversial, needs more discussion --HB
* g.region
** [http://grass.itc.it/pipermail/grassuser/2007-February/038337.html Glynn's notes] - cleaning the print flags and new <tt>print=</tt> option
** <strike>Support '''vector's 3rd''' dimension in '''g.region vect= [-a]''', '''[res=]''', like the 2d extents are (or should be)</strike> see [http://trac.osgeo.org/grass/ticket/121 trac #121]

== Database ==
=== Library ===

* <strike>establish SQLite as default DBMI driver for vector attribute storage (DBF is too limited).</strike> '''done May 2008.'''

=== Modules ===
* allow cross-mapset database access, i.e. parse the '@mapset' notation appended to vector names (requires access via possibly different DBMI drivers)

==== rename ====
* rename db.in.ogr to db.import

== Imagery ==

Page has been moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib

== 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 ==

The page moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/DisplayLib

== Postscript ==
=== Modules ===
ps.map
* remove scale parameter
: -> from the command line, not the map instruction
* rename sizecol to sizecolumn (remove the given warning)
* use PAL/JPAL [http://geosysin.iict.ch/PAL cartographic labelling library] (GPL, C++ language, JNI wrapper)

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 [http://intevation.de/rt/webrt?serial_num=2969 '''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 [http://grass.itc.it/pipermail/grass-dev/2007-August/032607.html 1].

* Eliminate Init.sh. Glynn explains on [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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 [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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."
: Actually, I (Glynn) no longer think it's that simple. If other users can create directories within your mapset, they can create directories which you cannot remove, and in which you cannot add, remove or modify files. And this is quite likely to happen: most users will have a umask of 0022 or worse, meaning that other users (i.e. you) cannot modify any files or directories which they create.

== Data management ==

* store vertical units on per-map base, using code from [http://www.gnu.org/software/units/ 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 [http://lists.maptools.org/pipermail/gdal-dev/2005-October/006857.html 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? [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d r.rast4d]

== Visualization ==

* better support for faces and kernels in libgis
: not really Visualization, but....

== CLI ==

=== Parameters standardization ===

* Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup documents/parameter_proposal.txt]

=== Flags standardization ===

* Get rid of 'quiet/verbose' flags, preparation in GRASS 6, e.g.:
<pre>
/* 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"));
}
</pre>

== GUI ==

* Multiplatform
* Fast, minimalist, number of windows reduced
* Novice, ...., Expert profiles for the GUI (with reduced features), tailored for use cases, e.g. 3D models of a risk map,
* link from application to the relevant wiki online support, so that non-programmers can contribute to GRASS support
* compile wiki online content and help pages into a offline version of help pages for usage in GRASS without internet access.
* Manageable also from command line via d.* modules
* Facilitating easy development of custom GUI application based on GRASS
* <strike>drop '''d.m'''</strike> {{done}}
* <strike>drop '''gis.m'''</strike> {{done}}

* → [[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 -- <cite> frankie at #grass irc</cite>
** 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 -- <cite> frankie at #grass irc</cite>
* Creating $HOME/.grass7 directory for {{done}}
** Custom fonts
** r.li and other modules temp. files
** GEM addons installation {{done}}
** Default path for custom scripts
** Custom symbols and EPS fill patterns
** Custom color maps
** Add here new item...

* [[GRASS repository layout proposal]]

== User Wishes ==

''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[User:MarisN|MarisN]] 12:00, 4 August 2006 (CEST)
* here are some examples to get inspired (apparently that's already possible):
** [http://skagit.meas.ncsu.edu/~helena/publwork/grasskey02/grass02talk10.html dynamic surfaces and volumes]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/cenntenial/water01dsmall.gif some water]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/balsam/fanimwalk.gif particles]
** [http://www.fhpv.unipo.sk/kagerr/pracovnici/hofierka/pv_results.html solar radiation and energy]
* Convince the users to use ParaView [http://www.paraview.org] for sophisticated animations --[[User:Huhabla|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 [http://www.llnl.gov/visit/ VisIt software], it should be able to read GRASS maps directly via GDAL

== Complete GRASS Test Suite: see activity on [[Test_Suite | Test Suite development page]] ==
* base a comprehensive test suite on [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/?C=M;O=D Soeren's GRASS Test Suite]
* automated error checking on all modules to catch data corruption issues

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS 7 ideas collection

2011-11-16T12:21:19Z

⚠️Benducke: /* 3D topology */

{{MoveToTrac}}

See also: http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== Maintenance of repository ==

For GRASS 7 development is used [http://svn.osgeo.org/grass/grass/trunk/ svn-trunk], for GRASS 6 development is used separated SVN branch [https://svn.osgeo.org/grass/grass/branches/develbranch_6 develbranch_6].

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

== Terminology ==

See [[GRASS 7 Terminology]].

== List of new features in GRASS 7 (already implemented) ==

See http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== API to access algorithms in modules ==

We need to better expose the "knowledge" which is contained at module level. We want to have it accessible via API, exposed in various programming languages such as C, Python, Perl, Java, ..

Update 1/2011: Python ctypes interface available

== Raster ==

See also
* [[Replacement raster format]].
* [http://trac.osgeo.org/grass/wiki/Grass7/RasterLib/ListOfFunctions Function name changes from GRASS 6 to GRASS 7]

=== Library ===
* allowing nulls to be embedded
* Insert 'vertical' 2d rasters (e.g. [http://woodshole.er.usgs.gov/project-pages/longislandsound/images/Ghist_square2.jpg geophysical survey data])
* Rewrite library from scratch. See [http://lists.osgeo.org/pipermail/grass-dev/2006-August/025153.html suggestions]
* <strike>Split libgis into [http://trac.osgeo.org/grass/wiki/Grass7RasterLib G_() part and Rast_() part]</strike> - done.
* <strike>[http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" via GDAL]</strike> - done.

Raster map history:
* In 7.0, the fields of the history structure are dynamically allocated. You have to use Rast_set_history() or Rast_format_history() to set fields. The the HIST_* constants have to be used.

=== Modules ===

==== rename ====
* rename r.in.gdal to r.import - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename r.out.gdal to r.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* <strike>rename r.volume 'data' parameter to something more standard like 'input'</strike>

==== remove ====
* Remove r.bitpattern since r.mapcalc does it more nicely now
* Remove r.in.arc and r.out.arc, '''if''' a [http://intevation.de/rt/webrt?serial_num=4897 related bug in r.in.gdal] is fixed. The [http://bugzilla.remotesensing.org/show_bug.cgi?id=1071 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.
: see delta comment about r.out.tiff below, sometimes the simple stuff works best! --HB
:: Ditto.

* remove '''r.resample''' and <strike>'''r.bilinear'''</strike> in favor of '''r.resamp.interp'''
: TODO: double-check that r.resample is in fact fully replaced by 'r.resamp.interp's method=nearest'. ie check that an alternate useful method is not lost.
* <strike>remove '''r.univar.sh'''; newly implemented '''r.univar''' features cover it</strike> '''done.'''

* remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [http://intevation.de/rt/webrt?serial_num=3680 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 [https://svn.qgis.org/trac/ticket/348 QGIS bug#348]) --HB
:: However: code duplication, maintenance overhead, user confussion (more entries in GUI, more manual pages, why are there modules doing the same?).

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

==== Merge ====

* merge {{cmd|r.surf.idw}} and {{cmd|r.surf.idw2}}
: while r.surf.idw will only output CELL maps, it is Very Fast. (or that is to say, ''r.surf.idw2'' is Very Slow)

* {{cmd|r.mode}}, {{cmd|r.statistics}}, {{cmd|r.univar.sh}}, {{cmd|r.univar}}(2) - maybe they can be reduced to just r.statistics and r.univar? See [http://intevation.de/rt/webrt?serial_num=1848 RT #1848] and a [http://grass.itc.it/pipermail/grass-dev/2006-November/027665.html thread on the GRASS dev list]

* <strike> {{cmd|r.sum}}, {{cmd|r.average}}, {{cmd|r.median}}, have been removed, as equivalent functionality is available via r.statistics{,2,3}.</strike>

* {{cmd|r.resamp.rst}}: merge into {{cmd|r.resamp.interp}} to make resolution management identical to the other modules
: HB: eh? the options and algorithm are nothing alike.
:: MS: I meant that r.resamp.rst could be a subset of r.resamp.interp (yet another resampling algorithm next to nearest, bilinear, bicubic). I haven't considered that the number of rst options would make r.resamp.interp user interface much less clear. Maybe not such a good idea after all - user interface wise.

* {{cmd|r.in.wms}} and {{cmd|r.in.srtm}} into {{cmd|r.in.gdal}} thanks to native support for [http://www.gdal.org/frmt_wms.html WMS] and [http://www.gdal.org/frmt_various.html#SRTMHGT SRTM] in GDAL 1.5
: HB: just be careful that the GDAL version is as featureful and grid/cell center correct as the r.in.* versions. I suspect it might not be. r.in.wms needs further python rewrite with full XML and HTTP library support.

* {{cmd|r.buffer}} and {{cmd|r.grow}}
: HB: why? they do two fundamentally different things, and both work quite nicely right now. One works in cell space, the other geographic space (especially for lat/lon).
:: MS: Right. The 2 modules do different things. But it would be usefull if r.grow supported distance in units and r.buffer in cells. Could both share same code for distance options?

==== fix ====
* fix lseek() usage for Large File Support: see [http://grass.itc.it/pipermail/grass-dev/2006-December/028231.html 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)
* r.random should be split into 2 modules: one for generating a raster map with random points (alike v.random), and the other for sampling a raster map (alike v.what.rast). Vector functionality should be droped from r.random - a dupe of existing vector modules. -i and -z flags should be droped.
* v.random -z: read zmin and zmax from region settings, drop zmin and zmax. I.e. treat Z coord same as X,Y.

==== Good coding practice ====

* Input handling:

/* Define the different options */
input1 = G_define_standard_option(G_OPT_R_INPUT) ;
input1->key = _("albedo");
input1->description =_("Name of the Albedo map [0.0-1.0]");
input1->answer =_("albedo");
input1->guisection = _("Required");

In here you can find G_define_standard_option(G_OPT_R_INPUT) assuming
already those:
input1->type = TYPE_STRING;
input1->required = YES;
input1->gisprompt =_("old,cell,raster") ;

If your input is not required to run the module, you just create the
following line:
input1->required = NO;

* In a similar way, metadata/history storage:

G_short_history(result1, "raster", &history);
G_command_history(&history);
G_write_history(result1,&history);

* This is the standard incantation, but I have to find timestamp(), and
more details metadata maybe like sensor type for a start, or
source/origin of data... Can we make metadata having elements
(history->processing, history->timestamp, history->source(or
history->origin), etc?) then it could be filled up specifically.

* Or color palettes application is nice:

/* Color table for biomass */
G_init_colors(&colors);
G_add_color_rule(0,0,0,0,1,255,255,255,&colors);

* Changes (from Glynn):
I would prefer it if G_open_*_new() simply called
G_fatal_error() themselves if an error occurred. It's not as if there's
any reasonable alternative way to handle the error.

* Changes:

input = G_define_option(G_OPT_F(D?)_INPUT) ;
input->key =_("parameter");
input->type = TYPE_DOUBLE;
input->required = YES;
input->gisprompt =_("value, parameter");
input->description=_("Value of the parameter");
/*input->answer =_("0.000");*/
input->guisection = _("Required");

I could also think similarly for non-GRASS files actually
(configuration files sometimes need to be loaded separately)

== Vector ==
=== Radim's TODO list ===

[http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Vector TODO list]
* Particularly important: "Keep topology and spatial index in file instead of in memory" --ML
* v.in.ogr: split long boundaries to speed up topology cleaning. Implemented in GRASS 7, partial backport to GRASS 6.5 possible.
{|
||
[[Image:V.in.ogr_speed.png|400px|thumb|left|v.in.ogr speed comparison]]
|}

=== Library ===
* 2d 'vertical' vector data (e.g. [http://sofia.usgs.gov/publications/maps/florida_geology/Txsectionbh.jpg 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 [http://sourceforge.net/mailarchive/message.php?msg_name=340505ef0601170244n1b5fe25bhd0a3eba7342b78d4%40mail.gmail.com 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 - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.out.ogr to v.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.mkgrid to v.grid - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.univar.sh to v.db.univar ([http://grass.itc.it/pipermail/grass-dev/2007-May/030883.html comment])

==== remove ====

* Remove [http://intevation.de/rt/webrt?serial_num=3600 doubled units in v.to.db GUI]

==== merge ====
* merge v.select and v.overlay
: needs discussion, they are doing fundamentally different things --HB

* merge {{cmd|v.sample}} and {{cmd|v.what.rast}}
: See a feature request <strike>[http://wald.intevation.org/tracker/index.php?func=detail&aid=506&group_id=21&atid=188 #506]</strike> in GForge.
: see also {{cmd|v.rast.stats}} and {{AddonCmd|v.what.rast.buffer}} addon

==== fix ====
* Fix the [http://intevation.de/rt/webrt?serial_num=3623 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 ??)
* <strike>implement Douglas-Peucker generalization ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/ C code file])to substitute prune tool of v.clean ([http://grass.itc.it/pipermail/grass-dev/2007-May/thread.html#31446 done]?, see also GSoC)</strike>
** This is done. [http://grass.osgeo.org/grass63/manuals/html63_user/v.generalize.html 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

=== 3D topology ===

Currently, GRASS' topological cleaning is 2D only. This will regularly butcher 3D data that is actually topologically correct in 3D space, but appears incorrect in 2D space (e.g. 3D polygons that ''appear'' to overlap or have zero-area in the X-Y geographic reference plane). Therefore, ''v.clean'' in GRASS 7 should become more competent at handling 3D topology. This is a sketch of how to implement the same level of topology support that 2D geometries currently have in 3D space.

====Problem structure====

The classes of potential topological errors depend on the geometry type (point, line, polygon), in 3D just as in 2D. Each more complex geometry type inherits the potential problems of the less complex types, and adds its own.

*3D topological problems for points reduce to coincidence in 3D space.
*3D topological problems for lines are over- and undershoots as well as duplicate vertices. These are completely equivalent to the same problem in 2D space.
*3D topological problems for polygons appear much more complex, as they include overlap in 3D. But this complexity can be reduced significantly. Only polygons that lie in the same plane (including a small error margin -- could be implemented just like the minimum error option in ''v.clean'') can get into topological trouble with each other: if two polygons do not lie in the same plane, then by definition they cannot overlap, only intersect. (It is open to debate, whether an intersection of polygons in 3D space would constitute a topological error.)

====Basic approach====

As a result, the topological cleaning could proceed as follows.

#All 3D polygons need to be '''planar''', i.e. all of their vertices must lie on the same plane. If they are not, then this is a topological error, and the polygon needs to be planarized by ''v.clean'' (add a "planarize" action -- also potentially useful for other geometry types). Planarization is done by first calculating the plane equation of the polygon (a simple equation that defines the location and orientation of a best-fit 2D plane through all vertices) and then reprojecting each of its original vertices to the plane defined by the plane equation (it could make sense to store the plane equations as part of the topological data structure). Planarization needs to be carried out for both boundaries and islands.
#Once planarized, all polygons can be subjected to the exact same topological cleaning as 2D polygons:
##After planarization, group all polygons that lie on the same plane.
##For each "plane group": reproject all vertices to the geographic X-Y reference plane. Run the topological cleaning just like for 2D polygons, but preserve the Z coordinates.
##Then revert the projection of all vertices back to the group's original reference plane, using the plane equation.
##Do the same with the next "plane group" until all polygons have been processed.
#Faces (3D triangles) are primitives that are part of more complex 3D geometries (including TINs and 3D hulls). Topological problems involving such geometries are too complex to handle in GIS. Thus, faces should not be checked for overlap. GRASS GIS should just assume that faces are part of complex geometries that are not to be subjected to analytical treatment, but simple tasks, such as visualization, only. Therefore, only basic cleaning (check for duplicate coordinates, zero-area triangles, etc.) should be carried out. Faces are always planar by definition.
#The areas and centroids of both faces and planar polygons can be calculated in 3D space just as they can be calculated in 2D space.

====Implementation details====

A simple algorithm for computing the plane equation of a set of vertices is <missing URL> available in the form of Newell's Method. This method requires three points to define a plane. This requirement is met by even the most simply polygons. However <missing URL>: "Newell's method is known to fail if the 3 points are chosen around a concave corner - the normal of the resulting plane will point in the direction opposite to the expected one."

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* <strike>Add new partial differential equation (PDE) library with OpenMP support</strike> (GRASS 6.3)

=== Modules ===

* g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [http://intevation.de/rt/webrt?serial_num=3009].
: controversial, needs more discussion --HB
* g.region
** [http://grass.itc.it/pipermail/grassuser/2007-February/038337.html Glynn's notes] - cleaning the print flags and new <tt>print=</tt> option
** <strike>Support '''vector's 3rd''' dimension in '''g.region vect= [-a]''', '''[res=]''', like the 2d extents are (or should be)</strike> see [http://trac.osgeo.org/grass/ticket/121 trac #121]

== Database ==
=== Library ===

* <strike>establish SQLite as default DBMI driver for vector attribute storage (DBF is too limited).</strike> '''done May 2008.'''

=== Modules ===
* allow cross-mapset database access, i.e. parse the '@mapset' notation appended to vector names (requires access via possibly different DBMI drivers)

==== rename ====
* rename db.in.ogr to db.import

== Imagery ==

Page has been moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib

== 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 ==

The page moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/DisplayLib

== Postscript ==
=== Modules ===
ps.map
* remove scale parameter
: -> from the command line, not the map instruction
* rename sizecol to sizecolumn (remove the given warning)
* use PAL/JPAL [http://geosysin.iict.ch/PAL cartographic labelling library] (GPL, C++ language, JNI wrapper)

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 [http://intevation.de/rt/webrt?serial_num=2969 '''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 [http://grass.itc.it/pipermail/grass-dev/2007-August/032607.html 1].

* Eliminate Init.sh. Glynn explains on [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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 [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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."
: Actually, I (Glynn) no longer think it's that simple. If other users can create directories within your mapset, they can create directories which you cannot remove, and in which you cannot add, remove or modify files. And this is quite likely to happen: most users will have a umask of 0022 or worse, meaning that other users (i.e. you) cannot modify any files or directories which they create.

== Data management ==

* store vertical units on per-map base, using code from [http://www.gnu.org/software/units/ 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 [http://lists.maptools.org/pipermail/gdal-dev/2005-October/006857.html 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? [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d r.rast4d]

== Visualization ==

* better support for faces and kernels in libgis
: not really Visualization, but....

== CLI ==

=== Parameters standardization ===

* Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup documents/parameter_proposal.txt]

=== Flags standardization ===

* Get rid of 'quiet/verbose' flags, preparation in GRASS 6, e.g.:
<pre>
/* 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"));
}
</pre>

== GUI ==

* Multiplatform
* Fast, minimalist, number of windows reduced
* Novice, ...., Expert profiles for the GUI (with reduced features), tailored for use cases, e.g. 3D models of a risk map,
* link from application to the relevant wiki online support, so that non-programmers can contribute to GRASS support
* compile wiki online content and help pages into a offline version of help pages for usage in GRASS without internet access.
* Manageable also from command line via d.* modules
* Facilitating easy development of custom GUI application based on GRASS
* <strike>drop '''d.m'''</strike> {{done}}
* <strike>drop '''gis.m'''</strike> {{done}}

* → [[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 -- <cite> frankie at #grass irc</cite>
** 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 -- <cite> frankie at #grass irc</cite>
* Creating $HOME/.grass7 directory for {{done}}
** Custom fonts
** r.li and other modules temp. files
** GEM addons installation {{done}}
** Default path for custom scripts
** Custom symbols and EPS fill patterns
** Custom color maps
** Add here new item...

* [[GRASS repository layout proposal]]

== User Wishes ==

''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[User:MarisN|MarisN]] 12:00, 4 August 2006 (CEST)
* here are some examples to get inspired (apparently that's already possible):
** [http://skagit.meas.ncsu.edu/~helena/publwork/grasskey02/grass02talk10.html dynamic surfaces and volumes]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/cenntenial/water01dsmall.gif some water]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/balsam/fanimwalk.gif particles]
** [http://www.fhpv.unipo.sk/kagerr/pracovnici/hofierka/pv_results.html solar radiation and energy]
* Convince the users to use ParaView [http://www.paraview.org] for sophisticated animations --[[User:Huhabla|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 [http://www.llnl.gov/visit/ VisIt software], it should be able to read GRASS maps directly via GDAL

== Complete GRASS Test Suite: see activity on [[Test_Suite | Test Suite development page]] ==
* base a comprehensive test suite on [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/?C=M;O=D Soeren's GRASS Test Suite]
* automated error checking on all modules to catch data corruption issues

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS 7 ideas collection

2011-11-16T11:48:46Z

⚠️Benducke: /* Problem structure */

{{MoveToTrac}}

See also: http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== Maintenance of repository ==

For GRASS 7 development is used [http://svn.osgeo.org/grass/grass/trunk/ svn-trunk], for GRASS 6 development is used separated SVN branch [https://svn.osgeo.org/grass/grass/branches/develbranch_6 develbranch_6].

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

== Terminology ==

See [[GRASS 7 Terminology]].

== List of new features in GRASS 7 (already implemented) ==

See http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== API to access algorithms in modules ==

We need to better expose the "knowledge" which is contained at module level. We want to have it accessible via API, exposed in various programming languages such as C, Python, Perl, Java, ..

Update 1/2011: Python ctypes interface available

== Raster ==

See also
* [[Replacement raster format]].
* [http://trac.osgeo.org/grass/wiki/Grass7/RasterLib/ListOfFunctions Function name changes from GRASS 6 to GRASS 7]

=== Library ===
* allowing nulls to be embedded
* Insert 'vertical' 2d rasters (e.g. [http://woodshole.er.usgs.gov/project-pages/longislandsound/images/Ghist_square2.jpg geophysical survey data])
* Rewrite library from scratch. See [http://lists.osgeo.org/pipermail/grass-dev/2006-August/025153.html suggestions]
* <strike>Split libgis into [http://trac.osgeo.org/grass/wiki/Grass7RasterLib G_() part and Rast_() part]</strike> - done.
* <strike>[http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" via GDAL]</strike> - done.

Raster map history:
* In 7.0, the fields of the history structure are dynamically allocated. You have to use Rast_set_history() or Rast_format_history() to set fields. The the HIST_* constants have to be used.

=== Modules ===

==== rename ====
* rename r.in.gdal to r.import - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename r.out.gdal to r.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* <strike>rename r.volume 'data' parameter to something more standard like 'input'</strike>

==== remove ====
* Remove r.bitpattern since r.mapcalc does it more nicely now
* Remove r.in.arc and r.out.arc, '''if''' a [http://intevation.de/rt/webrt?serial_num=4897 related bug in r.in.gdal] is fixed. The [http://bugzilla.remotesensing.org/show_bug.cgi?id=1071 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.
: see delta comment about r.out.tiff below, sometimes the simple stuff works best! --HB
:: Ditto.

* remove '''r.resample''' and <strike>'''r.bilinear'''</strike> in favor of '''r.resamp.interp'''
: TODO: double-check that r.resample is in fact fully replaced by 'r.resamp.interp's method=nearest'. ie check that an alternate useful method is not lost.
* <strike>remove '''r.univar.sh'''; newly implemented '''r.univar''' features cover it</strike> '''done.'''

* remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [http://intevation.de/rt/webrt?serial_num=3680 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 [https://svn.qgis.org/trac/ticket/348 QGIS bug#348]) --HB
:: However: code duplication, maintenance overhead, user confussion (more entries in GUI, more manual pages, why are there modules doing the same?).

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

==== Merge ====

* merge {{cmd|r.surf.idw}} and {{cmd|r.surf.idw2}}
: while r.surf.idw will only output CELL maps, it is Very Fast. (or that is to say, ''r.surf.idw2'' is Very Slow)

* {{cmd|r.mode}}, {{cmd|r.statistics}}, {{cmd|r.univar.sh}}, {{cmd|r.univar}}(2) - maybe they can be reduced to just r.statistics and r.univar? See [http://intevation.de/rt/webrt?serial_num=1848 RT #1848] and a [http://grass.itc.it/pipermail/grass-dev/2006-November/027665.html thread on the GRASS dev list]

* <strike> {{cmd|r.sum}}, {{cmd|r.average}}, {{cmd|r.median}}, have been removed, as equivalent functionality is available via r.statistics{,2,3}.</strike>

* {{cmd|r.resamp.rst}}: merge into {{cmd|r.resamp.interp}} to make resolution management identical to the other modules
: HB: eh? the options and algorithm are nothing alike.
:: MS: I meant that r.resamp.rst could be a subset of r.resamp.interp (yet another resampling algorithm next to nearest, bilinear, bicubic). I haven't considered that the number of rst options would make r.resamp.interp user interface much less clear. Maybe not such a good idea after all - user interface wise.

* {{cmd|r.in.wms}} and {{cmd|r.in.srtm}} into {{cmd|r.in.gdal}} thanks to native support for [http://www.gdal.org/frmt_wms.html WMS] and [http://www.gdal.org/frmt_various.html#SRTMHGT SRTM] in GDAL 1.5
: HB: just be careful that the GDAL version is as featureful and grid/cell center correct as the r.in.* versions. I suspect it might not be. r.in.wms needs further python rewrite with full XML and HTTP library support.

* {{cmd|r.buffer}} and {{cmd|r.grow}}
: HB: why? they do two fundamentally different things, and both work quite nicely right now. One works in cell space, the other geographic space (especially for lat/lon).
:: MS: Right. The 2 modules do different things. But it would be usefull if r.grow supported distance in units and r.buffer in cells. Could both share same code for distance options?

==== fix ====
* fix lseek() usage for Large File Support: see [http://grass.itc.it/pipermail/grass-dev/2006-December/028231.html 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)
* r.random should be split into 2 modules: one for generating a raster map with random points (alike v.random), and the other for sampling a raster map (alike v.what.rast). Vector functionality should be droped from r.random - a dupe of existing vector modules. -i and -z flags should be droped.
* v.random -z: read zmin and zmax from region settings, drop zmin and zmax. I.e. treat Z coord same as X,Y.

==== Good coding practice ====

* Input handling:

/* Define the different options */
input1 = G_define_standard_option(G_OPT_R_INPUT) ;
input1->key = _("albedo");
input1->description =_("Name of the Albedo map [0.0-1.0]");
input1->answer =_("albedo");
input1->guisection = _("Required");

In here you can find G_define_standard_option(G_OPT_R_INPUT) assuming
already those:
input1->type = TYPE_STRING;
input1->required = YES;
input1->gisprompt =_("old,cell,raster") ;

If your input is not required to run the module, you just create the
following line:
input1->required = NO;

* In a similar way, metadata/history storage:

G_short_history(result1, "raster", &history);
G_command_history(&history);
G_write_history(result1,&history);

* This is the standard incantation, but I have to find timestamp(), and
more details metadata maybe like sensor type for a start, or
source/origin of data... Can we make metadata having elements
(history->processing, history->timestamp, history->source(or
history->origin), etc?) then it could be filled up specifically.

* Or color palettes application is nice:

/* Color table for biomass */
G_init_colors(&colors);
G_add_color_rule(0,0,0,0,1,255,255,255,&colors);

* Changes (from Glynn):
I would prefer it if G_open_*_new() simply called
G_fatal_error() themselves if an error occurred. It's not as if there's
any reasonable alternative way to handle the error.

* Changes:

input = G_define_option(G_OPT_F(D?)_INPUT) ;
input->key =_("parameter");
input->type = TYPE_DOUBLE;
input->required = YES;
input->gisprompt =_("value, parameter");
input->description=_("Value of the parameter");
/*input->answer =_("0.000");*/
input->guisection = _("Required");

I could also think similarly for non-GRASS files actually
(configuration files sometimes need to be loaded separately)

== Vector ==
=== Radim's TODO list ===

[http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Vector TODO list]
* Particularly important: "Keep topology and spatial index in file instead of in memory" --ML
* v.in.ogr: split long boundaries to speed up topology cleaning. Implemented in GRASS 7, partial backport to GRASS 6.5 possible.
{|
||
[[Image:V.in.ogr_speed.png|400px|thumb|left|v.in.ogr speed comparison]]
|}

=== Library ===
* 2d 'vertical' vector data (e.g. [http://sofia.usgs.gov/publications/maps/florida_geology/Txsectionbh.jpg 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 [http://sourceforge.net/mailarchive/message.php?msg_name=340505ef0601170244n1b5fe25bhd0a3eba7342b78d4%40mail.gmail.com 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 - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.out.ogr to v.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.mkgrid to v.grid - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.univar.sh to v.db.univar ([http://grass.itc.it/pipermail/grass-dev/2007-May/030883.html comment])

==== remove ====

* Remove [http://intevation.de/rt/webrt?serial_num=3600 doubled units in v.to.db GUI]

==== merge ====
* merge v.select and v.overlay
: needs discussion, they are doing fundamentally different things --HB

* merge {{cmd|v.sample}} and {{cmd|v.what.rast}}
: See a feature request <strike>[http://wald.intevation.org/tracker/index.php?func=detail&aid=506&group_id=21&atid=188 #506]</strike> in GForge.
: see also {{cmd|v.rast.stats}} and {{AddonCmd|v.what.rast.buffer}} addon

==== fix ====
* Fix the [http://intevation.de/rt/webrt?serial_num=3623 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 ??)
* <strike>implement Douglas-Peucker generalization ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/ C code file])to substitute prune tool of v.clean ([http://grass.itc.it/pipermail/grass-dev/2007-May/thread.html#31446 done]?, see also GSoC)</strike>
** This is done. [http://grass.osgeo.org/grass63/manuals/html63_user/v.generalize.html 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

=== 3D topology ===

Currently, GRASS' topological cleaning is 2D only. This will regularly butcher 3D data that is actually topologically correct in 3D space, but appears incorrect in 2D space (e.g. 3D polygons that ''appear'' to overlap or have zero-area in the X-Y geographic reference plane). Therefore, ''v.clean'' in GRASS 7 should become more competent at handling 3D topology. This a sketch on how to implement the same level of topology support that 2D geometries currently have in 3D space.

====Problem structure====

The classes of potential topological errors depend on the geometry type (point, line, polygon), in 3D just as in 2D. Each more complex geometry type inherits the potential problems of the less complex types, and adds its own.

*3D topological problems for points reduce to coincidence in 3D space.
*3D topological problems for lines are over- and undershoots as well as duplicate vertices. These are completely equivalent to the same problem in 2D space.
*3D topological problems for polygons appear much more complex, as they include overlap in 3D. But this complexity can be reduced significantly. Only polygons that lie in the same plane (including a small error margin -- could be implemented just like the minimum error option in ''v.clean'') can get into topological trouble with each other: if two polygons do not lie in the same plane, then by definition they cannot overlap, only intersect. (It is open to debate, whether an intersection of polygons in 3D space would constitute a topological error.)

====Basic approach====

As a result, the topological cleaning could proceed as follows.

#All 3D polygons need to be '''planar''', i.e. all of their vertices must lie on the same plane. If they are not, then this is a topological error, and the polygon needs to be planarized by ''v.clean'' (add a "planarize" action -- also potentially useful for other geometry types). Planarization is done by first calculating the plane equation of the polygon (a simple equation that defines the location and orientation of a best-fit 2D plane through all vertices) and then reprojecting each of its original vertices to the plane defined by the plane equation (it could make sense to store the plane equations as part of the topological data structure). Planarization needs to be carried out for both boundaries and islands.
#Once planarized, all polygons can be subjected to the exact same topological cleaning as 2D polygons:
##After planarization, group all polygons that lie on the same plane.
##For each "plane group": reproject all vertices to the geographic X-Y reference plane. Run the topological cleaning just like for 2D polygons, but preserve the Z coordinates.
##Then revert the projection of all vertices back to the group's original reference plane, using the plane equation.
##Do the same with the next "plane group" until all polygons have been processed.
#Faces (3D triangles) are primitives that are part of more complex 3D geometries (including TINs and 3D hulls). Topological problems involving such geometries are too complex to handle in GIS. Thus, faces should not be checked for overlap. GRASS GIS should just assume that faces are part of complex geometries that are not to be subjected to analytical treatment, but simple tasks, such as visualization, only. Therefore, only basic cleaning (check for duplicate coordinates, zero-area triangles, etc.) should be carried out. Faces are always planar by definition.
#The areas and centroids of both faces and planar polygons can be calculated in 3D space just as they can be calculated in 2D space.

====Implementation details====

A simple algorithm for computing the plane equation of a set of vertices is <missing URL> available in the form of Newell's Method. This method requires three points to define a plane. This requirement is met by even the most simply polygons. However <missing URL>: "Newell's method is known to fail if the 3 points are chosen around a concave corner - the normal of the resulting plane will point in the direction opposite to the expected one."

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* <strike>Add new partial differential equation (PDE) library with OpenMP support</strike> (GRASS 6.3)

=== Modules ===

* g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [http://intevation.de/rt/webrt?serial_num=3009].
: controversial, needs more discussion --HB
* g.region
** [http://grass.itc.it/pipermail/grassuser/2007-February/038337.html Glynn's notes] - cleaning the print flags and new <tt>print=</tt> option
** <strike>Support '''vector's 3rd''' dimension in '''g.region vect= [-a]''', '''[res=]''', like the 2d extents are (or should be)</strike> see [http://trac.osgeo.org/grass/ticket/121 trac #121]

== Database ==
=== Library ===

* <strike>establish SQLite as default DBMI driver for vector attribute storage (DBF is too limited).</strike> '''done May 2008.'''

=== Modules ===
* allow cross-mapset database access, i.e. parse the '@mapset' notation appended to vector names (requires access via possibly different DBMI drivers)

==== rename ====
* rename db.in.ogr to db.import

== Imagery ==

Page has been moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib

== 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 ==

The page moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/DisplayLib

== Postscript ==
=== Modules ===
ps.map
* remove scale parameter
: -> from the command line, not the map instruction
* rename sizecol to sizecolumn (remove the given warning)
* use PAL/JPAL [http://geosysin.iict.ch/PAL cartographic labelling library] (GPL, C++ language, JNI wrapper)

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 [http://intevation.de/rt/webrt?serial_num=2969 '''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 [http://grass.itc.it/pipermail/grass-dev/2007-August/032607.html 1].

* Eliminate Init.sh. Glynn explains on [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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 [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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."
: Actually, I (Glynn) no longer think it's that simple. If other users can create directories within your mapset, they can create directories which you cannot remove, and in which you cannot add, remove or modify files. And this is quite likely to happen: most users will have a umask of 0022 or worse, meaning that other users (i.e. you) cannot modify any files or directories which they create.

== Data management ==

* store vertical units on per-map base, using code from [http://www.gnu.org/software/units/ 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 [http://lists.maptools.org/pipermail/gdal-dev/2005-October/006857.html 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? [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d r.rast4d]

== Visualization ==

* better support for faces and kernels in libgis
: not really Visualization, but....

== CLI ==

=== Parameters standardization ===

* Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup documents/parameter_proposal.txt]

=== Flags standardization ===

* Get rid of 'quiet/verbose' flags, preparation in GRASS 6, e.g.:
<pre>
/* 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"));
}
</pre>

== GUI ==

* Multiplatform
* Fast, minimalist, number of windows reduced
* Novice, ...., Expert profiles for the GUI (with reduced features), tailored for use cases, e.g. 3D models of a risk map,
* link from application to the relevant wiki online support, so that non-programmers can contribute to GRASS support
* compile wiki online content and help pages into a offline version of help pages for usage in GRASS without internet access.
* Manageable also from command line via d.* modules
* Facilitating easy development of custom GUI application based on GRASS
* <strike>drop '''d.m'''</strike> {{done}}
* <strike>drop '''gis.m'''</strike> {{done}}

* → [[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 -- <cite> frankie at #grass irc</cite>
** 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 -- <cite> frankie at #grass irc</cite>
* Creating $HOME/.grass7 directory for {{done}}
** Custom fonts
** r.li and other modules temp. files
** GEM addons installation {{done}}
** Default path for custom scripts
** Custom symbols and EPS fill patterns
** Custom color maps
** Add here new item...

* [[GRASS repository layout proposal]]

== User Wishes ==

''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[User:MarisN|MarisN]] 12:00, 4 August 2006 (CEST)
* here are some examples to get inspired (apparently that's already possible):
** [http://skagit.meas.ncsu.edu/~helena/publwork/grasskey02/grass02talk10.html dynamic surfaces and volumes]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/cenntenial/water01dsmall.gif some water]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/balsam/fanimwalk.gif particles]
** [http://www.fhpv.unipo.sk/kagerr/pracovnici/hofierka/pv_results.html solar radiation and energy]
* Convince the users to use ParaView [http://www.paraview.org] for sophisticated animations --[[User:Huhabla|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 [http://www.llnl.gov/visit/ VisIt software], it should be able to read GRASS maps directly via GDAL

== Complete GRASS Test Suite: see activity on [[Test_Suite | Test Suite development page]] ==
* base a comprehensive test suite on [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/?C=M;O=D Soeren's GRASS Test Suite]
* automated error checking on all modules to catch data corruption issues

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS 7 ideas collection

2011-11-16T11:48:21Z

⚠️Benducke: /* Problem structure */

{{MoveToTrac}}

See also: http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== Maintenance of repository ==

For GRASS 7 development is used [http://svn.osgeo.org/grass/grass/trunk/ svn-trunk], for GRASS 6 development is used separated SVN branch [https://svn.osgeo.org/grass/grass/branches/develbranch_6 develbranch_6].

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

== Terminology ==

See [[GRASS 7 Terminology]].

== List of new features in GRASS 7 (already implemented) ==

See http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== API to access algorithms in modules ==

We need to better expose the "knowledge" which is contained at module level. We want to have it accessible via API, exposed in various programming languages such as C, Python, Perl, Java, ..

Update 1/2011: Python ctypes interface available

== Raster ==

See also
* [[Replacement raster format]].
* [http://trac.osgeo.org/grass/wiki/Grass7/RasterLib/ListOfFunctions Function name changes from GRASS 6 to GRASS 7]

=== Library ===
* allowing nulls to be embedded
* Insert 'vertical' 2d rasters (e.g. [http://woodshole.er.usgs.gov/project-pages/longislandsound/images/Ghist_square2.jpg geophysical survey data])
* Rewrite library from scratch. See [http://lists.osgeo.org/pipermail/grass-dev/2006-August/025153.html suggestions]
* <strike>Split libgis into [http://trac.osgeo.org/grass/wiki/Grass7RasterLib G_() part and Rast_() part]</strike> - done.
* <strike>[http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" via GDAL]</strike> - done.

Raster map history:
* In 7.0, the fields of the history structure are dynamically allocated. You have to use Rast_set_history() or Rast_format_history() to set fields. The the HIST_* constants have to be used.

=== Modules ===

==== rename ====
* rename r.in.gdal to r.import - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename r.out.gdal to r.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* <strike>rename r.volume 'data' parameter to something more standard like 'input'</strike>

==== remove ====
* Remove r.bitpattern since r.mapcalc does it more nicely now
* Remove r.in.arc and r.out.arc, '''if''' a [http://intevation.de/rt/webrt?serial_num=4897 related bug in r.in.gdal] is fixed. The [http://bugzilla.remotesensing.org/show_bug.cgi?id=1071 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.
: see delta comment about r.out.tiff below, sometimes the simple stuff works best! --HB
:: Ditto.

* remove '''r.resample''' and <strike>'''r.bilinear'''</strike> in favor of '''r.resamp.interp'''
: TODO: double-check that r.resample is in fact fully replaced by 'r.resamp.interp's method=nearest'. ie check that an alternate useful method is not lost.
* <strike>remove '''r.univar.sh'''; newly implemented '''r.univar''' features cover it</strike> '''done.'''

* remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [http://intevation.de/rt/webrt?serial_num=3680 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 [https://svn.qgis.org/trac/ticket/348 QGIS bug#348]) --HB
:: However: code duplication, maintenance overhead, user confussion (more entries in GUI, more manual pages, why are there modules doing the same?).

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

==== Merge ====

* merge {{cmd|r.surf.idw}} and {{cmd|r.surf.idw2}}
: while r.surf.idw will only output CELL maps, it is Very Fast. (or that is to say, ''r.surf.idw2'' is Very Slow)

* {{cmd|r.mode}}, {{cmd|r.statistics}}, {{cmd|r.univar.sh}}, {{cmd|r.univar}}(2) - maybe they can be reduced to just r.statistics and r.univar? See [http://intevation.de/rt/webrt?serial_num=1848 RT #1848] and a [http://grass.itc.it/pipermail/grass-dev/2006-November/027665.html thread on the GRASS dev list]

* <strike> {{cmd|r.sum}}, {{cmd|r.average}}, {{cmd|r.median}}, have been removed, as equivalent functionality is available via r.statistics{,2,3}.</strike>

* {{cmd|r.resamp.rst}}: merge into {{cmd|r.resamp.interp}} to make resolution management identical to the other modules
: HB: eh? the options and algorithm are nothing alike.
:: MS: I meant that r.resamp.rst could be a subset of r.resamp.interp (yet another resampling algorithm next to nearest, bilinear, bicubic). I haven't considered that the number of rst options would make r.resamp.interp user interface much less clear. Maybe not such a good idea after all - user interface wise.

* {{cmd|r.in.wms}} and {{cmd|r.in.srtm}} into {{cmd|r.in.gdal}} thanks to native support for [http://www.gdal.org/frmt_wms.html WMS] and [http://www.gdal.org/frmt_various.html#SRTMHGT SRTM] in GDAL 1.5
: HB: just be careful that the GDAL version is as featureful and grid/cell center correct as the r.in.* versions. I suspect it might not be. r.in.wms needs further python rewrite with full XML and HTTP library support.

* {{cmd|r.buffer}} and {{cmd|r.grow}}
: HB: why? they do two fundamentally different things, and both work quite nicely right now. One works in cell space, the other geographic space (especially for lat/lon).
:: MS: Right. The 2 modules do different things. But it would be usefull if r.grow supported distance in units and r.buffer in cells. Could both share same code for distance options?

==== fix ====
* fix lseek() usage for Large File Support: see [http://grass.itc.it/pipermail/grass-dev/2006-December/028231.html 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)
* r.random should be split into 2 modules: one for generating a raster map with random points (alike v.random), and the other for sampling a raster map (alike v.what.rast). Vector functionality should be droped from r.random - a dupe of existing vector modules. -i and -z flags should be droped.
* v.random -z: read zmin and zmax from region settings, drop zmin and zmax. I.e. treat Z coord same as X,Y.

==== Good coding practice ====

* Input handling:

/* Define the different options */
input1 = G_define_standard_option(G_OPT_R_INPUT) ;
input1->key = _("albedo");
input1->description =_("Name of the Albedo map [0.0-1.0]");
input1->answer =_("albedo");
input1->guisection = _("Required");

In here you can find G_define_standard_option(G_OPT_R_INPUT) assuming
already those:
input1->type = TYPE_STRING;
input1->required = YES;
input1->gisprompt =_("old,cell,raster") ;

If your input is not required to run the module, you just create the
following line:
input1->required = NO;

* In a similar way, metadata/history storage:

G_short_history(result1, "raster", &history);
G_command_history(&history);
G_write_history(result1,&history);

* This is the standard incantation, but I have to find timestamp(), and
more details metadata maybe like sensor type for a start, or
source/origin of data... Can we make metadata having elements
(history->processing, history->timestamp, history->source(or
history->origin), etc?) then it could be filled up specifically.

* Or color palettes application is nice:

/* Color table for biomass */
G_init_colors(&colors);
G_add_color_rule(0,0,0,0,1,255,255,255,&colors);

* Changes (from Glynn):
I would prefer it if G_open_*_new() simply called
G_fatal_error() themselves if an error occurred. It's not as if there's
any reasonable alternative way to handle the error.

* Changes:

input = G_define_option(G_OPT_F(D?)_INPUT) ;
input->key =_("parameter");
input->type = TYPE_DOUBLE;
input->required = YES;
input->gisprompt =_("value, parameter");
input->description=_("Value of the parameter");
/*input->answer =_("0.000");*/
input->guisection = _("Required");

I could also think similarly for non-GRASS files actually
(configuration files sometimes need to be loaded separately)

== Vector ==
=== Radim's TODO list ===

[http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Vector TODO list]
* Particularly important: "Keep topology and spatial index in file instead of in memory" --ML
* v.in.ogr: split long boundaries to speed up topology cleaning. Implemented in GRASS 7, partial backport to GRASS 6.5 possible.
{|
||
[[Image:V.in.ogr_speed.png|400px|thumb|left|v.in.ogr speed comparison]]
|}

=== Library ===
* 2d 'vertical' vector data (e.g. [http://sofia.usgs.gov/publications/maps/florida_geology/Txsectionbh.jpg 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 [http://sourceforge.net/mailarchive/message.php?msg_name=340505ef0601170244n1b5fe25bhd0a3eba7342b78d4%40mail.gmail.com 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 - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.out.ogr to v.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.mkgrid to v.grid - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.univar.sh to v.db.univar ([http://grass.itc.it/pipermail/grass-dev/2007-May/030883.html comment])

==== remove ====

* Remove [http://intevation.de/rt/webrt?serial_num=3600 doubled units in v.to.db GUI]

==== merge ====
* merge v.select and v.overlay
: needs discussion, they are doing fundamentally different things --HB

* merge {{cmd|v.sample}} and {{cmd|v.what.rast}}
: See a feature request <strike>[http://wald.intevation.org/tracker/index.php?func=detail&aid=506&group_id=21&atid=188 #506]</strike> in GForge.
: see also {{cmd|v.rast.stats}} and {{AddonCmd|v.what.rast.buffer}} addon

==== fix ====
* Fix the [http://intevation.de/rt/webrt?serial_num=3623 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 ??)
* <strike>implement Douglas-Peucker generalization ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/ C code file])to substitute prune tool of v.clean ([http://grass.itc.it/pipermail/grass-dev/2007-May/thread.html#31446 done]?, see also GSoC)</strike>
** This is done. [http://grass.osgeo.org/grass63/manuals/html63_user/v.generalize.html 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

=== 3D topology ===

Currently, GRASS' topological cleaning is 2D only. This will regularly butcher 3D data that is actually topologically correct in 3D space, but appears incorrect in 2D space (e.g. 3D polygons that ''appear'' to overlap or have zero-area in the X-Y geographic reference plane). Therefore, ''v.clean'' in GRASS 7 should become more competent at handling 3D topology. This a sketch on how to implement the same level of topology support that 2D geometries currently have in 3D space.

====Problem structure====

The classes of topological errors depend on the geometry type (point, line, polygon), in 3D just as in 2D. Each more complex geometry type inherits the potential problems of the less complex types, and adds its own.

*3D topological problems for points reduce to coincidence in 3D space.
*3D topological problems for lines are over- and undershoots as well as duplicate vertices. These are completely equivalent to the same problem in 2D space.
*3D topological problems for polygons appear much more complex, as they include overlap in 3D. But this complexity can be reduced significantly. Only polygons that lie in the same plane (including a small error margin -- could be implemented just like the minimum error option in ''v.clean'') can get into topological trouble with each other: if two polygons do not lie in the same plane, then by definition they cannot overlap, only intersect. (It is open to debate, whether an intersection of polygons in 3D space would constitute a topological error.)

====Basic approach====

As a result, the topological cleaning could proceed as follows.

#All 3D polygons need to be '''planar''', i.e. all of their vertices must lie on the same plane. If they are not, then this is a topological error, and the polygon needs to be planarized by ''v.clean'' (add a "planarize" action -- also potentially useful for other geometry types). Planarization is done by first calculating the plane equation of the polygon (a simple equation that defines the location and orientation of a best-fit 2D plane through all vertices) and then reprojecting each of its original vertices to the plane defined by the plane equation (it could make sense to store the plane equations as part of the topological data structure). Planarization needs to be carried out for both boundaries and islands.
#Once planarized, all polygons can be subjected to the exact same topological cleaning as 2D polygons:
##After planarization, group all polygons that lie on the same plane.
##For each "plane group": reproject all vertices to the geographic X-Y reference plane. Run the topological cleaning just like for 2D polygons, but preserve the Z coordinates.
##Then revert the projection of all vertices back to the group's original reference plane, using the plane equation.
##Do the same with the next "plane group" until all polygons have been processed.
#Faces (3D triangles) are primitives that are part of more complex 3D geometries (including TINs and 3D hulls). Topological problems involving such geometries are too complex to handle in GIS. Thus, faces should not be checked for overlap. GRASS GIS should just assume that faces are part of complex geometries that are not to be subjected to analytical treatment, but simple tasks, such as visualization, only. Therefore, only basic cleaning (check for duplicate coordinates, zero-area triangles, etc.) should be carried out. Faces are always planar by definition.
#The areas and centroids of both faces and planar polygons can be calculated in 3D space just as they can be calculated in 2D space.

====Implementation details====

A simple algorithm for computing the plane equation of a set of vertices is <missing URL> available in the form of Newell's Method. This method requires three points to define a plane. This requirement is met by even the most simply polygons. However <missing URL>: "Newell's method is known to fail if the 3 points are chosen around a concave corner - the normal of the resulting plane will point in the direction opposite to the expected one."

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* <strike>Add new partial differential equation (PDE) library with OpenMP support</strike> (GRASS 6.3)

=== Modules ===

* g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [http://intevation.de/rt/webrt?serial_num=3009].
: controversial, needs more discussion --HB
* g.region
** [http://grass.itc.it/pipermail/grassuser/2007-February/038337.html Glynn's notes] - cleaning the print flags and new <tt>print=</tt> option
** <strike>Support '''vector's 3rd''' dimension in '''g.region vect= [-a]''', '''[res=]''', like the 2d extents are (or should be)</strike> see [http://trac.osgeo.org/grass/ticket/121 trac #121]

== Database ==
=== Library ===

* <strike>establish SQLite as default DBMI driver for vector attribute storage (DBF is too limited).</strike> '''done May 2008.'''

=== Modules ===
* allow cross-mapset database access, i.e. parse the '@mapset' notation appended to vector names (requires access via possibly different DBMI drivers)

==== rename ====
* rename db.in.ogr to db.import

== Imagery ==

Page has been moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib

== 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 ==

The page moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/DisplayLib

== Postscript ==
=== Modules ===
ps.map
* remove scale parameter
: -> from the command line, not the map instruction
* rename sizecol to sizecolumn (remove the given warning)
* use PAL/JPAL [http://geosysin.iict.ch/PAL cartographic labelling library] (GPL, C++ language, JNI wrapper)

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 [http://intevation.de/rt/webrt?serial_num=2969 '''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 [http://grass.itc.it/pipermail/grass-dev/2007-August/032607.html 1].

* Eliminate Init.sh. Glynn explains on [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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 [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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."
: Actually, I (Glynn) no longer think it's that simple. If other users can create directories within your mapset, they can create directories which you cannot remove, and in which you cannot add, remove or modify files. And this is quite likely to happen: most users will have a umask of 0022 or worse, meaning that other users (i.e. you) cannot modify any files or directories which they create.

== Data management ==

* store vertical units on per-map base, using code from [http://www.gnu.org/software/units/ 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 [http://lists.maptools.org/pipermail/gdal-dev/2005-October/006857.html 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? [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d r.rast4d]

== Visualization ==

* better support for faces and kernels in libgis
: not really Visualization, but....

== CLI ==

=== Parameters standardization ===

* Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup documents/parameter_proposal.txt]

=== Flags standardization ===

* Get rid of 'quiet/verbose' flags, preparation in GRASS 6, e.g.:
<pre>
/* 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"));
}
</pre>

== GUI ==

* Multiplatform
* Fast, minimalist, number of windows reduced
* Novice, ...., Expert profiles for the GUI (with reduced features), tailored for use cases, e.g. 3D models of a risk map,
* link from application to the relevant wiki online support, so that non-programmers can contribute to GRASS support
* compile wiki online content and help pages into a offline version of help pages for usage in GRASS without internet access.
* Manageable also from command line via d.* modules
* Facilitating easy development of custom GUI application based on GRASS
* <strike>drop '''d.m'''</strike> {{done}}
* <strike>drop '''gis.m'''</strike> {{done}}

* → [[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 -- <cite> frankie at #grass irc</cite>
** 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 -- <cite> frankie at #grass irc</cite>
* Creating $HOME/.grass7 directory for {{done}}
** Custom fonts
** r.li and other modules temp. files
** GEM addons installation {{done}}
** Default path for custom scripts
** Custom symbols and EPS fill patterns
** Custom color maps
** Add here new item...

* [[GRASS repository layout proposal]]

== User Wishes ==

''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[User:MarisN|MarisN]] 12:00, 4 August 2006 (CEST)
* here are some examples to get inspired (apparently that's already possible):
** [http://skagit.meas.ncsu.edu/~helena/publwork/grasskey02/grass02talk10.html dynamic surfaces and volumes]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/cenntenial/water01dsmall.gif some water]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/balsam/fanimwalk.gif particles]
** [http://www.fhpv.unipo.sk/kagerr/pracovnici/hofierka/pv_results.html solar radiation and energy]
* Convince the users to use ParaView [http://www.paraview.org] for sophisticated animations --[[User:Huhabla|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 [http://www.llnl.gov/visit/ VisIt software], it should be able to read GRASS maps directly via GDAL

== Complete GRASS Test Suite: see activity on [[Test_Suite | Test Suite development page]] ==
* base a comprehensive test suite on [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/?C=M;O=D Soeren's GRASS Test Suite]
* automated error checking on all modules to catch data corruption issues

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS 7 ideas collection

2011-11-16T11:47:00Z

⚠️Benducke: /* Basic approach */

{{MoveToTrac}}

See also: http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== Maintenance of repository ==

For GRASS 7 development is used [http://svn.osgeo.org/grass/grass/trunk/ svn-trunk], for GRASS 6 development is used separated SVN branch [https://svn.osgeo.org/grass/grass/branches/develbranch_6 develbranch_6].

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

== Terminology ==

See [[GRASS 7 Terminology]].

== List of new features in GRASS 7 (already implemented) ==

See http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== API to access algorithms in modules ==

We need to better expose the "knowledge" which is contained at module level. We want to have it accessible via API, exposed in various programming languages such as C, Python, Perl, Java, ..

Update 1/2011: Python ctypes interface available

== Raster ==

See also
* [[Replacement raster format]].
* [http://trac.osgeo.org/grass/wiki/Grass7/RasterLib/ListOfFunctions Function name changes from GRASS 6 to GRASS 7]

=== Library ===
* allowing nulls to be embedded
* Insert 'vertical' 2d rasters (e.g. [http://woodshole.er.usgs.gov/project-pages/longislandsound/images/Ghist_square2.jpg geophysical survey data])
* Rewrite library from scratch. See [http://lists.osgeo.org/pipermail/grass-dev/2006-August/025153.html suggestions]
* <strike>Split libgis into [http://trac.osgeo.org/grass/wiki/Grass7RasterLib G_() part and Rast_() part]</strike> - done.
* <strike>[http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" via GDAL]</strike> - done.

Raster map history:
* In 7.0, the fields of the history structure are dynamically allocated. You have to use Rast_set_history() or Rast_format_history() to set fields. The the HIST_* constants have to be used.

=== Modules ===

==== rename ====
* rename r.in.gdal to r.import - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename r.out.gdal to r.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* <strike>rename r.volume 'data' parameter to something more standard like 'input'</strike>

==== remove ====
* Remove r.bitpattern since r.mapcalc does it more nicely now
* Remove r.in.arc and r.out.arc, '''if''' a [http://intevation.de/rt/webrt?serial_num=4897 related bug in r.in.gdal] is fixed. The [http://bugzilla.remotesensing.org/show_bug.cgi?id=1071 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.
: see delta comment about r.out.tiff below, sometimes the simple stuff works best! --HB
:: Ditto.

* remove '''r.resample''' and <strike>'''r.bilinear'''</strike> in favor of '''r.resamp.interp'''
: TODO: double-check that r.resample is in fact fully replaced by 'r.resamp.interp's method=nearest'. ie check that an alternate useful method is not lost.
* <strike>remove '''r.univar.sh'''; newly implemented '''r.univar''' features cover it</strike> '''done.'''

* remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [http://intevation.de/rt/webrt?serial_num=3680 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 [https://svn.qgis.org/trac/ticket/348 QGIS bug#348]) --HB
:: However: code duplication, maintenance overhead, user confussion (more entries in GUI, more manual pages, why are there modules doing the same?).

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

==== Merge ====

* merge {{cmd|r.surf.idw}} and {{cmd|r.surf.idw2}}
: while r.surf.idw will only output CELL maps, it is Very Fast. (or that is to say, ''r.surf.idw2'' is Very Slow)

* {{cmd|r.mode}}, {{cmd|r.statistics}}, {{cmd|r.univar.sh}}, {{cmd|r.univar}}(2) - maybe they can be reduced to just r.statistics and r.univar? See [http://intevation.de/rt/webrt?serial_num=1848 RT #1848] and a [http://grass.itc.it/pipermail/grass-dev/2006-November/027665.html thread on the GRASS dev list]

* <strike> {{cmd|r.sum}}, {{cmd|r.average}}, {{cmd|r.median}}, have been removed, as equivalent functionality is available via r.statistics{,2,3}.</strike>

* {{cmd|r.resamp.rst}}: merge into {{cmd|r.resamp.interp}} to make resolution management identical to the other modules
: HB: eh? the options and algorithm are nothing alike.
:: MS: I meant that r.resamp.rst could be a subset of r.resamp.interp (yet another resampling algorithm next to nearest, bilinear, bicubic). I haven't considered that the number of rst options would make r.resamp.interp user interface much less clear. Maybe not such a good idea after all - user interface wise.

* {{cmd|r.in.wms}} and {{cmd|r.in.srtm}} into {{cmd|r.in.gdal}} thanks to native support for [http://www.gdal.org/frmt_wms.html WMS] and [http://www.gdal.org/frmt_various.html#SRTMHGT SRTM] in GDAL 1.5
: HB: just be careful that the GDAL version is as featureful and grid/cell center correct as the r.in.* versions. I suspect it might not be. r.in.wms needs further python rewrite with full XML and HTTP library support.

* {{cmd|r.buffer}} and {{cmd|r.grow}}
: HB: why? they do two fundamentally different things, and both work quite nicely right now. One works in cell space, the other geographic space (especially for lat/lon).
:: MS: Right. The 2 modules do different things. But it would be usefull if r.grow supported distance in units and r.buffer in cells. Could both share same code for distance options?

==== fix ====
* fix lseek() usage for Large File Support: see [http://grass.itc.it/pipermail/grass-dev/2006-December/028231.html 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)
* r.random should be split into 2 modules: one for generating a raster map with random points (alike v.random), and the other for sampling a raster map (alike v.what.rast). Vector functionality should be droped from r.random - a dupe of existing vector modules. -i and -z flags should be droped.
* v.random -z: read zmin and zmax from region settings, drop zmin and zmax. I.e. treat Z coord same as X,Y.

==== Good coding practice ====

* Input handling:

/* Define the different options */
input1 = G_define_standard_option(G_OPT_R_INPUT) ;
input1->key = _("albedo");
input1->description =_("Name of the Albedo map [0.0-1.0]");
input1->answer =_("albedo");
input1->guisection = _("Required");

In here you can find G_define_standard_option(G_OPT_R_INPUT) assuming
already those:
input1->type = TYPE_STRING;
input1->required = YES;
input1->gisprompt =_("old,cell,raster") ;

If your input is not required to run the module, you just create the
following line:
input1->required = NO;

* In a similar way, metadata/history storage:

G_short_history(result1, "raster", &history);
G_command_history(&history);
G_write_history(result1,&history);

* This is the standard incantation, but I have to find timestamp(), and
more details metadata maybe like sensor type for a start, or
source/origin of data... Can we make metadata having elements
(history->processing, history->timestamp, history->source(or
history->origin), etc?) then it could be filled up specifically.

* Or color palettes application is nice:

/* Color table for biomass */
G_init_colors(&colors);
G_add_color_rule(0,0,0,0,1,255,255,255,&colors);

* Changes (from Glynn):
I would prefer it if G_open_*_new() simply called
G_fatal_error() themselves if an error occurred. It's not as if there's
any reasonable alternative way to handle the error.

* Changes:

input = G_define_option(G_OPT_F(D?)_INPUT) ;
input->key =_("parameter");
input->type = TYPE_DOUBLE;
input->required = YES;
input->gisprompt =_("value, parameter");
input->description=_("Value of the parameter");
/*input->answer =_("0.000");*/
input->guisection = _("Required");

I could also think similarly for non-GRASS files actually
(configuration files sometimes need to be loaded separately)

== Vector ==
=== Radim's TODO list ===

[http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Vector TODO list]
* Particularly important: "Keep topology and spatial index in file instead of in memory" --ML
* v.in.ogr: split long boundaries to speed up topology cleaning. Implemented in GRASS 7, partial backport to GRASS 6.5 possible.
{|
||
[[Image:V.in.ogr_speed.png|400px|thumb|left|v.in.ogr speed comparison]]
|}

=== Library ===
* 2d 'vertical' vector data (e.g. [http://sofia.usgs.gov/publications/maps/florida_geology/Txsectionbh.jpg 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 [http://sourceforge.net/mailarchive/message.php?msg_name=340505ef0601170244n1b5fe25bhd0a3eba7342b78d4%40mail.gmail.com 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 - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.out.ogr to v.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.mkgrid to v.grid - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.univar.sh to v.db.univar ([http://grass.itc.it/pipermail/grass-dev/2007-May/030883.html comment])

==== remove ====

* Remove [http://intevation.de/rt/webrt?serial_num=3600 doubled units in v.to.db GUI]

==== merge ====
* merge v.select and v.overlay
: needs discussion, they are doing fundamentally different things --HB

* merge {{cmd|v.sample}} and {{cmd|v.what.rast}}
: See a feature request <strike>[http://wald.intevation.org/tracker/index.php?func=detail&aid=506&group_id=21&atid=188 #506]</strike> in GForge.
: see also {{cmd|v.rast.stats}} and {{AddonCmd|v.what.rast.buffer}} addon

==== fix ====
* Fix the [http://intevation.de/rt/webrt?serial_num=3623 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 ??)
* <strike>implement Douglas-Peucker generalization ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/ C code file])to substitute prune tool of v.clean ([http://grass.itc.it/pipermail/grass-dev/2007-May/thread.html#31446 done]?, see also GSoC)</strike>
** This is done. [http://grass.osgeo.org/grass63/manuals/html63_user/v.generalize.html 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

=== 3D topology ===

Currently, GRASS' topological cleaning is 2D only. This will regularly butcher 3D data that is actually topologically correct in 3D space, but appears incorrect in 2D space (e.g. 3D polygons that ''appear'' to overlap or have zero-area in the X-Y geographic reference plane). Therefore, ''v.clean'' in GRASS 7 should become more competent at handling 3D topology. This a sketch on how to implement the same level of topology support that 2D geometries currently have in 3D space.

====Problem structure====

*3D topological problems for points reduce to coincidence in 3D space.
*3D topological problems for lines are over- and undershoots as well as duplicate vertices. These are completely equivalent to the same problem in 2D space.
*3D topological problems for polygons appear much more complex, as they include overlap in 3D. But this complexity can be reduced significantly. Only polygons that lie in the same plane (including a small error margin -- could be implemented just like the minimum error option in ''v.clean'') can get into topological trouble with each other: if two polygons do not lie in the same plane, then by definition they cannot overlap, only intersect. (It is open to debate, whether an intersection of polygons in 3D space would constitute a topological error.)

====Basic approach====

As a result, the topological cleaning could proceed as follows.

#All 3D polygons need to be '''planar''', i.e. all of their vertices must lie on the same plane. If they are not, then this is a topological error, and the polygon needs to be planarized by ''v.clean'' (add a "planarize" action -- also potentially useful for other geometry types). Planarization is done by first calculating the plane equation of the polygon (a simple equation that defines the location and orientation of a best-fit 2D plane through all vertices) and then reprojecting each of its original vertices to the plane defined by the plane equation (it could make sense to store the plane equations as part of the topological data structure). Planarization needs to be carried out for both boundaries and islands.
#Once planarized, all polygons can be subjected to the exact same topological cleaning as 2D polygons:
##After planarization, group all polygons that lie on the same plane.
##For each "plane group": reproject all vertices to the geographic X-Y reference plane. Run the topological cleaning just like for 2D polygons, but preserve the Z coordinates.
##Then revert the projection of all vertices back to the group's original reference plane, using the plane equation.
##Do the same with the next "plane group" until all polygons have been processed.
#Faces (3D triangles) are primitives that are part of more complex 3D geometries (including TINs and 3D hulls). Topological problems involving such geometries are too complex to handle in GIS. Thus, faces should not be checked for overlap. GRASS GIS should just assume that faces are part of complex geometries that are not to be subjected to analytical treatment, but simple tasks, such as visualization, only. Therefore, only basic cleaning (check for duplicate coordinates, zero-area triangles, etc.) should be carried out. Faces are always planar by definition.
#The areas and centroids of both faces and planar polygons can be calculated in 3D space just as they can be calculated in 2D space.

====Implementation details====

A simple algorithm for computing the plane equation of a set of vertices is <missing URL> available in the form of Newell's Method. This method requires three points to define a plane. This requirement is met by even the most simply polygons. However <missing URL>: "Newell's method is known to fail if the 3 points are chosen around a concave corner - the normal of the resulting plane will point in the direction opposite to the expected one."

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* <strike>Add new partial differential equation (PDE) library with OpenMP support</strike> (GRASS 6.3)

=== Modules ===

* g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [http://intevation.de/rt/webrt?serial_num=3009].
: controversial, needs more discussion --HB
* g.region
** [http://grass.itc.it/pipermail/grassuser/2007-February/038337.html Glynn's notes] - cleaning the print flags and new <tt>print=</tt> option
** <strike>Support '''vector's 3rd''' dimension in '''g.region vect= [-a]''', '''[res=]''', like the 2d extents are (or should be)</strike> see [http://trac.osgeo.org/grass/ticket/121 trac #121]

== Database ==
=== Library ===

* <strike>establish SQLite as default DBMI driver for vector attribute storage (DBF is too limited).</strike> '''done May 2008.'''

=== Modules ===
* allow cross-mapset database access, i.e. parse the '@mapset' notation appended to vector names (requires access via possibly different DBMI drivers)

==== rename ====
* rename db.in.ogr to db.import

== Imagery ==

Page has been moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib

== 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 ==

The page moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/DisplayLib

== Postscript ==
=== Modules ===
ps.map
* remove scale parameter
: -> from the command line, not the map instruction
* rename sizecol to sizecolumn (remove the given warning)
* use PAL/JPAL [http://geosysin.iict.ch/PAL cartographic labelling library] (GPL, C++ language, JNI wrapper)

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 [http://intevation.de/rt/webrt?serial_num=2969 '''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 [http://grass.itc.it/pipermail/grass-dev/2007-August/032607.html 1].

* Eliminate Init.sh. Glynn explains on [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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 [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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."
: Actually, I (Glynn) no longer think it's that simple. If other users can create directories within your mapset, they can create directories which you cannot remove, and in which you cannot add, remove or modify files. And this is quite likely to happen: most users will have a umask of 0022 or worse, meaning that other users (i.e. you) cannot modify any files or directories which they create.

== Data management ==

* store vertical units on per-map base, using code from [http://www.gnu.org/software/units/ 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 [http://lists.maptools.org/pipermail/gdal-dev/2005-October/006857.html 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? [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d r.rast4d]

== Visualization ==

* better support for faces and kernels in libgis
: not really Visualization, but....

== CLI ==

=== Parameters standardization ===

* Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup documents/parameter_proposal.txt]

=== Flags standardization ===

* Get rid of 'quiet/verbose' flags, preparation in GRASS 6, e.g.:
<pre>
/* 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"));
}
</pre>

== GUI ==

* Multiplatform
* Fast, minimalist, number of windows reduced
* Novice, ...., Expert profiles for the GUI (with reduced features), tailored for use cases, e.g. 3D models of a risk map,
* link from application to the relevant wiki online support, so that non-programmers can contribute to GRASS support
* compile wiki online content and help pages into a offline version of help pages for usage in GRASS without internet access.
* Manageable also from command line via d.* modules
* Facilitating easy development of custom GUI application based on GRASS
* <strike>drop '''d.m'''</strike> {{done}}
* <strike>drop '''gis.m'''</strike> {{done}}

* → [[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 -- <cite> frankie at #grass irc</cite>
** 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 -- <cite> frankie at #grass irc</cite>
* Creating $HOME/.grass7 directory for {{done}}
** Custom fonts
** r.li and other modules temp. files
** GEM addons installation {{done}}
** Default path for custom scripts
** Custom symbols and EPS fill patterns
** Custom color maps
** Add here new item...

* [[GRASS repository layout proposal]]

== User Wishes ==

''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[User:MarisN|MarisN]] 12:00, 4 August 2006 (CEST)
* here are some examples to get inspired (apparently that's already possible):
** [http://skagit.meas.ncsu.edu/~helena/publwork/grasskey02/grass02talk10.html dynamic surfaces and volumes]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/cenntenial/water01dsmall.gif some water]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/balsam/fanimwalk.gif particles]
** [http://www.fhpv.unipo.sk/kagerr/pracovnici/hofierka/pv_results.html solar radiation and energy]
* Convince the users to use ParaView [http://www.paraview.org] for sophisticated animations --[[User:Huhabla|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 [http://www.llnl.gov/visit/ VisIt software], it should be able to read GRASS maps directly via GDAL

== Complete GRASS Test Suite: see activity on [[Test_Suite | Test Suite development page]] ==
* base a comprehensive test suite on [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/?C=M;O=D Soeren's GRASS Test Suite]
* automated error checking on all modules to catch data corruption issues

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS 7 ideas collection

2011-11-16T11:30:09Z

⚠️Benducke: /* Implementation details */

{{MoveToTrac}}

See also: http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== Maintenance of repository ==

For GRASS 7 development is used [http://svn.osgeo.org/grass/grass/trunk/ svn-trunk], for GRASS 6 development is used separated SVN branch [https://svn.osgeo.org/grass/grass/branches/develbranch_6 develbranch_6].

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

== Terminology ==

See [[GRASS 7 Terminology]].

== List of new features in GRASS 7 (already implemented) ==

See http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== API to access algorithms in modules ==

We need to better expose the "knowledge" which is contained at module level. We want to have it accessible via API, exposed in various programming languages such as C, Python, Perl, Java, ..

Update 1/2011: Python ctypes interface available

== Raster ==

See also
* [[Replacement raster format]].
* [http://trac.osgeo.org/grass/wiki/Grass7/RasterLib/ListOfFunctions Function name changes from GRASS 6 to GRASS 7]

=== Library ===
* allowing nulls to be embedded
* Insert 'vertical' 2d rasters (e.g. [http://woodshole.er.usgs.gov/project-pages/longislandsound/images/Ghist_square2.jpg geophysical survey data])
* Rewrite library from scratch. See [http://lists.osgeo.org/pipermail/grass-dev/2006-August/025153.html suggestions]
* <strike>Split libgis into [http://trac.osgeo.org/grass/wiki/Grass7RasterLib G_() part and Rast_() part]</strike> - done.
* <strike>[http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" via GDAL]</strike> - done.

Raster map history:
* In 7.0, the fields of the history structure are dynamically allocated. You have to use Rast_set_history() or Rast_format_history() to set fields. The the HIST_* constants have to be used.

=== Modules ===

==== rename ====
* rename r.in.gdal to r.import - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename r.out.gdal to r.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* <strike>rename r.volume 'data' parameter to something more standard like 'input'</strike>

==== remove ====
* Remove r.bitpattern since r.mapcalc does it more nicely now
* Remove r.in.arc and r.out.arc, '''if''' a [http://intevation.de/rt/webrt?serial_num=4897 related bug in r.in.gdal] is fixed. The [http://bugzilla.remotesensing.org/show_bug.cgi?id=1071 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.
: see delta comment about r.out.tiff below, sometimes the simple stuff works best! --HB
:: Ditto.

* remove '''r.resample''' and <strike>'''r.bilinear'''</strike> in favor of '''r.resamp.interp'''
: TODO: double-check that r.resample is in fact fully replaced by 'r.resamp.interp's method=nearest'. ie check that an alternate useful method is not lost.
* <strike>remove '''r.univar.sh'''; newly implemented '''r.univar''' features cover it</strike> '''done.'''

* remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [http://intevation.de/rt/webrt?serial_num=3680 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 [https://svn.qgis.org/trac/ticket/348 QGIS bug#348]) --HB
:: However: code duplication, maintenance overhead, user confussion (more entries in GUI, more manual pages, why are there modules doing the same?).

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

==== Merge ====

* merge {{cmd|r.surf.idw}} and {{cmd|r.surf.idw2}}
: while r.surf.idw will only output CELL maps, it is Very Fast. (or that is to say, ''r.surf.idw2'' is Very Slow)

* {{cmd|r.mode}}, {{cmd|r.statistics}}, {{cmd|r.univar.sh}}, {{cmd|r.univar}}(2) - maybe they can be reduced to just r.statistics and r.univar? See [http://intevation.de/rt/webrt?serial_num=1848 RT #1848] and a [http://grass.itc.it/pipermail/grass-dev/2006-November/027665.html thread on the GRASS dev list]

* <strike> {{cmd|r.sum}}, {{cmd|r.average}}, {{cmd|r.median}}, have been removed, as equivalent functionality is available via r.statistics{,2,3}.</strike>

* {{cmd|r.resamp.rst}}: merge into {{cmd|r.resamp.interp}} to make resolution management identical to the other modules
: HB: eh? the options and algorithm are nothing alike.
:: MS: I meant that r.resamp.rst could be a subset of r.resamp.interp (yet another resampling algorithm next to nearest, bilinear, bicubic). I haven't considered that the number of rst options would make r.resamp.interp user interface much less clear. Maybe not such a good idea after all - user interface wise.

* {{cmd|r.in.wms}} and {{cmd|r.in.srtm}} into {{cmd|r.in.gdal}} thanks to native support for [http://www.gdal.org/frmt_wms.html WMS] and [http://www.gdal.org/frmt_various.html#SRTMHGT SRTM] in GDAL 1.5
: HB: just be careful that the GDAL version is as featureful and grid/cell center correct as the r.in.* versions. I suspect it might not be. r.in.wms needs further python rewrite with full XML and HTTP library support.

* {{cmd|r.buffer}} and {{cmd|r.grow}}
: HB: why? they do two fundamentally different things, and both work quite nicely right now. One works in cell space, the other geographic space (especially for lat/lon).
:: MS: Right. The 2 modules do different things. But it would be usefull if r.grow supported distance in units and r.buffer in cells. Could both share same code for distance options?

==== fix ====
* fix lseek() usage for Large File Support: see [http://grass.itc.it/pipermail/grass-dev/2006-December/028231.html 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)
* r.random should be split into 2 modules: one for generating a raster map with random points (alike v.random), and the other for sampling a raster map (alike v.what.rast). Vector functionality should be droped from r.random - a dupe of existing vector modules. -i and -z flags should be droped.
* v.random -z: read zmin and zmax from region settings, drop zmin and zmax. I.e. treat Z coord same as X,Y.

==== Good coding practice ====

* Input handling:

/* Define the different options */
input1 = G_define_standard_option(G_OPT_R_INPUT) ;
input1->key = _("albedo");
input1->description =_("Name of the Albedo map [0.0-1.0]");
input1->answer =_("albedo");
input1->guisection = _("Required");

In here you can find G_define_standard_option(G_OPT_R_INPUT) assuming
already those:
input1->type = TYPE_STRING;
input1->required = YES;
input1->gisprompt =_("old,cell,raster") ;

If your input is not required to run the module, you just create the
following line:
input1->required = NO;

* In a similar way, metadata/history storage:

G_short_history(result1, "raster", &history);
G_command_history(&history);
G_write_history(result1,&history);

* This is the standard incantation, but I have to find timestamp(), and
more details metadata maybe like sensor type for a start, or
source/origin of data... Can we make metadata having elements
(history->processing, history->timestamp, history->source(or
history->origin), etc?) then it could be filled up specifically.

* Or color palettes application is nice:

/* Color table for biomass */
G_init_colors(&colors);
G_add_color_rule(0,0,0,0,1,255,255,255,&colors);

* Changes (from Glynn):
I would prefer it if G_open_*_new() simply called
G_fatal_error() themselves if an error occurred. It's not as if there's
any reasonable alternative way to handle the error.

* Changes:

input = G_define_option(G_OPT_F(D?)_INPUT) ;
input->key =_("parameter");
input->type = TYPE_DOUBLE;
input->required = YES;
input->gisprompt =_("value, parameter");
input->description=_("Value of the parameter");
/*input->answer =_("0.000");*/
input->guisection = _("Required");

I could also think similarly for non-GRASS files actually
(configuration files sometimes need to be loaded separately)

== Vector ==
=== Radim's TODO list ===

[http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Vector TODO list]
* Particularly important: "Keep topology and spatial index in file instead of in memory" --ML
* v.in.ogr: split long boundaries to speed up topology cleaning. Implemented in GRASS 7, partial backport to GRASS 6.5 possible.
{|
||
[[Image:V.in.ogr_speed.png|400px|thumb|left|v.in.ogr speed comparison]]
|}

=== Library ===
* 2d 'vertical' vector data (e.g. [http://sofia.usgs.gov/publications/maps/florida_geology/Txsectionbh.jpg 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 [http://sourceforge.net/mailarchive/message.php?msg_name=340505ef0601170244n1b5fe25bhd0a3eba7342b78d4%40mail.gmail.com 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 - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.out.ogr to v.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.mkgrid to v.grid - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.univar.sh to v.db.univar ([http://grass.itc.it/pipermail/grass-dev/2007-May/030883.html comment])

==== remove ====

* Remove [http://intevation.de/rt/webrt?serial_num=3600 doubled units in v.to.db GUI]

==== merge ====
* merge v.select and v.overlay
: needs discussion, they are doing fundamentally different things --HB

* merge {{cmd|v.sample}} and {{cmd|v.what.rast}}
: See a feature request <strike>[http://wald.intevation.org/tracker/index.php?func=detail&aid=506&group_id=21&atid=188 #506]</strike> in GForge.
: see also {{cmd|v.rast.stats}} and {{AddonCmd|v.what.rast.buffer}} addon

==== fix ====
* Fix the [http://intevation.de/rt/webrt?serial_num=3623 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 ??)
* <strike>implement Douglas-Peucker generalization ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/ C code file])to substitute prune tool of v.clean ([http://grass.itc.it/pipermail/grass-dev/2007-May/thread.html#31446 done]?, see also GSoC)</strike>
** This is done. [http://grass.osgeo.org/grass63/manuals/html63_user/v.generalize.html 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

=== 3D topology ===

Currently, GRASS' topological cleaning is 2D only. This will regularly butcher 3D data that is actually topologically correct in 3D space, but appears incorrect in 2D space (e.g. 3D polygons that ''appear'' to overlap or have zero-area in the X-Y geographic reference plane). Therefore, ''v.clean'' in GRASS 7 should become more competent at handling 3D topology. This a sketch on how to implement the same level of topology support that 2D geometries currently have in 3D space.

====Problem structure====

*3D topological problems for points reduce to coincidence in 3D space.
*3D topological problems for lines are over- and undershoots as well as duplicate vertices. These are completely equivalent to the same problem in 2D space.
*3D topological problems for polygons appear much more complex, as they include overlap in 3D. But this complexity can be reduced significantly. Only polygons that lie in the same plane (including a small error margin -- could be implemented just like the minimum error option in ''v.clean'') can get into topological trouble with each other: if two polygons do not lie in the same plane, then by definition they cannot overlap, only intersect. (It is open to debate, whether an intersection of polygons in 3D space would constitute a topological error.)

====Basic approach====

As a result, the topological cleaning could proceed as follows.

#All 3D polygons need to be '''planar''', i.e. all of their vertices must lie on the same plane. If they are not, then this is a topological error, and the polygon needs to be planarized by ''v.clean'' (add a "planarize" action -- also potentially useful for other geometry types). Planarization is done by first calculating the plane equation of the polygon (a simple equation that defines the location and orientation of a best-fit 2D plane through all vertices) and then reprojecting each of its original vertices to the plane defined by the plane equation (it could make sense to store the plane equations as part of the topological data structure). Planarization needs to be carried out for both boundaries and islands.
#Once planarized, all polygons can be subjected to the exact same topological cleaning as 2D polygons:
##After planarization, group all polygons that lie on the same plane.
##For each "plane group": reproject all vertices to the geographic X-Y reference plane. Run the topological cleaning just like for 2D polygons, but preserve the Z coordinates.
##Then revert the projection of all vertices back to the group's original reference plane, using the plane equation.
##Do the same with the next "plane group" until all polygons have been processed.
#Faces (3D triangles) are primitives that are part of more complex 3D geometries (including TINs and 3D hulls). Topological problems involving such geometries are too complex to handle in GIS. Thus, should not be checked for overlap. GRASS GIS should just assume that faces are part of complex geometries that are not to be subjected to analytical treatment, but simple tasks, such as visualization, only. Therefore, only basic cleaning (check for duplicate coordinates, zero-area triangles, etc.) will be carried out. Faces are always planar by definition.
#The areas and centroids of both faces and planar polygons can be calculated in 3D space just as they can be calculated in 2D space.

====Implementation details====

A simple algorithm for computing the plane equation of a set of vertices is <missing URL> available in the form of Newell's Method. This method requires three points to define a plane. This requirement is met by even the most simply polygons. However <missing URL>: "Newell's method is known to fail if the 3 points are chosen around a concave corner - the normal of the resulting plane will point in the direction opposite to the expected one."

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* <strike>Add new partial differential equation (PDE) library with OpenMP support</strike> (GRASS 6.3)

=== Modules ===

* g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [http://intevation.de/rt/webrt?serial_num=3009].
: controversial, needs more discussion --HB
* g.region
** [http://grass.itc.it/pipermail/grassuser/2007-February/038337.html Glynn's notes] - cleaning the print flags and new <tt>print=</tt> option
** <strike>Support '''vector's 3rd''' dimension in '''g.region vect= [-a]''', '''[res=]''', like the 2d extents are (or should be)</strike> see [http://trac.osgeo.org/grass/ticket/121 trac #121]

== Database ==
=== Library ===

* <strike>establish SQLite as default DBMI driver for vector attribute storage (DBF is too limited).</strike> '''done May 2008.'''

=== Modules ===
* allow cross-mapset database access, i.e. parse the '@mapset' notation appended to vector names (requires access via possibly different DBMI drivers)

==== rename ====
* rename db.in.ogr to db.import

== Imagery ==

Page has been moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib

== 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 ==

The page moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/DisplayLib

== Postscript ==
=== Modules ===
ps.map
* remove scale parameter
: -> from the command line, not the map instruction
* rename sizecol to sizecolumn (remove the given warning)
* use PAL/JPAL [http://geosysin.iict.ch/PAL cartographic labelling library] (GPL, C++ language, JNI wrapper)

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 [http://intevation.de/rt/webrt?serial_num=2969 '''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 [http://grass.itc.it/pipermail/grass-dev/2007-August/032607.html 1].

* Eliminate Init.sh. Glynn explains on [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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 [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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."
: Actually, I (Glynn) no longer think it's that simple. If other users can create directories within your mapset, they can create directories which you cannot remove, and in which you cannot add, remove or modify files. And this is quite likely to happen: most users will have a umask of 0022 or worse, meaning that other users (i.e. you) cannot modify any files or directories which they create.

== Data management ==

* store vertical units on per-map base, using code from [http://www.gnu.org/software/units/ 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 [http://lists.maptools.org/pipermail/gdal-dev/2005-October/006857.html 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? [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d r.rast4d]

== Visualization ==

* better support for faces and kernels in libgis
: not really Visualization, but....

== CLI ==

=== Parameters standardization ===

* Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup documents/parameter_proposal.txt]

=== Flags standardization ===

* Get rid of 'quiet/verbose' flags, preparation in GRASS 6, e.g.:
<pre>
/* 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"));
}
</pre>

== GUI ==

* Multiplatform
* Fast, minimalist, number of windows reduced
* Novice, ...., Expert profiles for the GUI (with reduced features), tailored for use cases, e.g. 3D models of a risk map,
* link from application to the relevant wiki online support, so that non-programmers can contribute to GRASS support
* compile wiki online content and help pages into a offline version of help pages for usage in GRASS without internet access.
* Manageable also from command line via d.* modules
* Facilitating easy development of custom GUI application based on GRASS
* <strike>drop '''d.m'''</strike> {{done}}
* <strike>drop '''gis.m'''</strike> {{done}}

* → [[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 -- <cite> frankie at #grass irc</cite>
** 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 -- <cite> frankie at #grass irc</cite>
* Creating $HOME/.grass7 directory for {{done}}
** Custom fonts
** r.li and other modules temp. files
** GEM addons installation {{done}}
** Default path for custom scripts
** Custom symbols and EPS fill patterns
** Custom color maps
** Add here new item...

* [[GRASS repository layout proposal]]

== User Wishes ==

''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[User:MarisN|MarisN]] 12:00, 4 August 2006 (CEST)
* here are some examples to get inspired (apparently that's already possible):
** [http://skagit.meas.ncsu.edu/~helena/publwork/grasskey02/grass02talk10.html dynamic surfaces and volumes]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/cenntenial/water01dsmall.gif some water]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/balsam/fanimwalk.gif particles]
** [http://www.fhpv.unipo.sk/kagerr/pracovnici/hofierka/pv_results.html solar radiation and energy]
* Convince the users to use ParaView [http://www.paraview.org] for sophisticated animations --[[User:Huhabla|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 [http://www.llnl.gov/visit/ VisIt software], it should be able to read GRASS maps directly via GDAL

== Complete GRASS Test Suite: see activity on [[Test_Suite | Test Suite development page]] ==
* base a comprehensive test suite on [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/?C=M;O=D Soeren's GRASS Test Suite]
* automated error checking on all modules to catch data corruption issues

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS 7 ideas collection

2011-11-16T11:29:33Z

⚠️Benducke: /* Vector */

{{MoveToTrac}}

See also: http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== Maintenance of repository ==

For GRASS 7 development is used [http://svn.osgeo.org/grass/grass/trunk/ svn-trunk], for GRASS 6 development is used separated SVN branch [https://svn.osgeo.org/grass/grass/branches/develbranch_6 develbranch_6].

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

== Terminology ==

See [[GRASS 7 Terminology]].

== List of new features in GRASS 7 (already implemented) ==

See http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

== API to access algorithms in modules ==

We need to better expose the "knowledge" which is contained at module level. We want to have it accessible via API, exposed in various programming languages such as C, Python, Perl, Java, ..

Update 1/2011: Python ctypes interface available

== Raster ==

See also
* [[Replacement raster format]].
* [http://trac.osgeo.org/grass/wiki/Grass7/RasterLib/ListOfFunctions Function name changes from GRASS 6 to GRASS 7]

=== Library ===
* allowing nulls to be embedded
* Insert 'vertical' 2d rasters (e.g. [http://woodshole.er.usgs.gov/project-pages/longislandsound/images/Ghist_square2.jpg geophysical survey data])
* Rewrite library from scratch. See [http://lists.osgeo.org/pipermail/grass-dev/2006-August/025153.html suggestions]
* <strike>Split libgis into [http://trac.osgeo.org/grass/wiki/Grass7RasterLib G_() part and Rast_() part]</strike> - done.
* <strike>[http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup GRASS raster "live links" via GDAL]</strike> - done.

Raster map history:
* In 7.0, the fields of the history structure are dynamically allocated. You have to use Rast_set_history() or Rast_format_history() to set fields. The the HIST_* constants have to be used.

=== Modules ===

==== rename ====
* rename r.in.gdal to r.import - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename r.out.gdal to r.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* <strike>rename r.volume 'data' parameter to something more standard like 'input'</strike>

==== remove ====
* Remove r.bitpattern since r.mapcalc does it more nicely now
* Remove r.in.arc and r.out.arc, '''if''' a [http://intevation.de/rt/webrt?serial_num=4897 related bug in r.in.gdal] is fixed. The [http://bugzilla.remotesensing.org/show_bug.cgi?id=1071 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.
: see delta comment about r.out.tiff below, sometimes the simple stuff works best! --HB
:: Ditto.

* remove '''r.resample''' and <strike>'''r.bilinear'''</strike> in favor of '''r.resamp.interp'''
: TODO: double-check that r.resample is in fact fully replaced by 'r.resamp.interp's method=nearest'. ie check that an alternate useful method is not lost.
* <strike>remove '''r.univar.sh'''; newly implemented '''r.univar''' features cover it</strike> '''done.'''

* remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [http://intevation.de/rt/webrt?serial_num=3680 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 [https://svn.qgis.org/trac/ticket/348 QGIS bug#348]) --HB
:: However: code duplication, maintenance overhead, user confussion (more entries in GUI, more manual pages, why are there modules doing the same?).

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

==== Merge ====

* merge {{cmd|r.surf.idw}} and {{cmd|r.surf.idw2}}
: while r.surf.idw will only output CELL maps, it is Very Fast. (or that is to say, ''r.surf.idw2'' is Very Slow)

* {{cmd|r.mode}}, {{cmd|r.statistics}}, {{cmd|r.univar.sh}}, {{cmd|r.univar}}(2) - maybe they can be reduced to just r.statistics and r.univar? See [http://intevation.de/rt/webrt?serial_num=1848 RT #1848] and a [http://grass.itc.it/pipermail/grass-dev/2006-November/027665.html thread on the GRASS dev list]

* <strike> {{cmd|r.sum}}, {{cmd|r.average}}, {{cmd|r.median}}, have been removed, as equivalent functionality is available via r.statistics{,2,3}.</strike>

* {{cmd|r.resamp.rst}}: merge into {{cmd|r.resamp.interp}} to make resolution management identical to the other modules
: HB: eh? the options and algorithm are nothing alike.
:: MS: I meant that r.resamp.rst could be a subset of r.resamp.interp (yet another resampling algorithm next to nearest, bilinear, bicubic). I haven't considered that the number of rst options would make r.resamp.interp user interface much less clear. Maybe not such a good idea after all - user interface wise.

* {{cmd|r.in.wms}} and {{cmd|r.in.srtm}} into {{cmd|r.in.gdal}} thanks to native support for [http://www.gdal.org/frmt_wms.html WMS] and [http://www.gdal.org/frmt_various.html#SRTMHGT SRTM] in GDAL 1.5
: HB: just be careful that the GDAL version is as featureful and grid/cell center correct as the r.in.* versions. I suspect it might not be. r.in.wms needs further python rewrite with full XML and HTTP library support.

* {{cmd|r.buffer}} and {{cmd|r.grow}}
: HB: why? they do two fundamentally different things, and both work quite nicely right now. One works in cell space, the other geographic space (especially for lat/lon).
:: MS: Right. The 2 modules do different things. But it would be usefull if r.grow supported distance in units and r.buffer in cells. Could both share same code for distance options?

==== fix ====
* fix lseek() usage for Large File Support: see [http://grass.itc.it/pipermail/grass-dev/2006-December/028231.html 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)
* r.random should be split into 2 modules: one for generating a raster map with random points (alike v.random), and the other for sampling a raster map (alike v.what.rast). Vector functionality should be droped from r.random - a dupe of existing vector modules. -i and -z flags should be droped.
* v.random -z: read zmin and zmax from region settings, drop zmin and zmax. I.e. treat Z coord same as X,Y.

==== Good coding practice ====

* Input handling:

/* Define the different options */
input1 = G_define_standard_option(G_OPT_R_INPUT) ;
input1->key = _("albedo");
input1->description =_("Name of the Albedo map [0.0-1.0]");
input1->answer =_("albedo");
input1->guisection = _("Required");

In here you can find G_define_standard_option(G_OPT_R_INPUT) assuming
already those:
input1->type = TYPE_STRING;
input1->required = YES;
input1->gisprompt =_("old,cell,raster") ;

If your input is not required to run the module, you just create the
following line:
input1->required = NO;

* In a similar way, metadata/history storage:

G_short_history(result1, "raster", &history);
G_command_history(&history);
G_write_history(result1,&history);

* This is the standard incantation, but I have to find timestamp(), and
more details metadata maybe like sensor type for a start, or
source/origin of data... Can we make metadata having elements
(history->processing, history->timestamp, history->source(or
history->origin), etc?) then it could be filled up specifically.

* Or color palettes application is nice:

/* Color table for biomass */
G_init_colors(&colors);
G_add_color_rule(0,0,0,0,1,255,255,255,&colors);

* Changes (from Glynn):
I would prefer it if G_open_*_new() simply called
G_fatal_error() themselves if an error occurred. It's not as if there's
any reasonable alternative way to handle the error.

* Changes:

input = G_define_option(G_OPT_F(D?)_INPUT) ;
input->key =_("parameter");
input->type = TYPE_DOUBLE;
input->required = YES;
input->gisprompt =_("value, parameter");
input->description=_("Value of the parameter");
/*input->answer =_("0.000");*/
input->guisection = _("Required");

I could also think similarly for non-GRASS files actually
(configuration files sometimes need to be loaded separately)

== Vector ==
=== Radim's TODO list ===

[http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Vector TODO list]
* Particularly important: "Keep topology and spatial index in file instead of in memory" --ML
* v.in.ogr: split long boundaries to speed up topology cleaning. Implemented in GRASS 7, partial backport to GRASS 6.5 possible.
{|
||
[[Image:V.in.ogr_speed.png|400px|thumb|left|v.in.ogr speed comparison]]
|}

=== Library ===
* 2d 'vertical' vector data (e.g. [http://sofia.usgs.gov/publications/maps/florida_geology/Txsectionbh.jpg 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 [http://sourceforge.net/mailarchive/message.php?msg_name=340505ef0601170244n1b5fe25bhd0a3eba7342b78d4%40mail.gmail.com 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 - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.out.ogr to v.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.mkgrid to v.grid - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.univar.sh to v.db.univar ([http://grass.itc.it/pipermail/grass-dev/2007-May/030883.html comment])

==== remove ====

* Remove [http://intevation.de/rt/webrt?serial_num=3600 doubled units in v.to.db GUI]

==== merge ====
* merge v.select and v.overlay
: needs discussion, they are doing fundamentally different things --HB

* merge {{cmd|v.sample}} and {{cmd|v.what.rast}}
: See a feature request <strike>[http://wald.intevation.org/tracker/index.php?func=detail&aid=506&group_id=21&atid=188 #506]</strike> in GForge.
: see also {{cmd|v.rast.stats}} and {{AddonCmd|v.what.rast.buffer}} addon

==== fix ====
* Fix the [http://intevation.de/rt/webrt?serial_num=3623 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 ??)
* <strike>implement Douglas-Peucker generalization ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/ C code file])to substitute prune tool of v.clean ([http://grass.itc.it/pipermail/grass-dev/2007-May/thread.html#31446 done]?, see also GSoC)</strike>
** This is done. [http://grass.osgeo.org/grass63/manuals/html63_user/v.generalize.html 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

=== 3D topology ===

Currently, GRASS' topological cleaning is 2D only. This will regularly butcher 3D data that is actually topologically correct in 3D space, but appears incorrect in 2D space (e.g. 3D polygons that ''appear'' to overlap or have zero-area in the X-Y geographic reference plane). Therefore, ''v.clean'' in GRASS 7 should become more competent at handling 3D topology. This a sketch on how to implement the same level of topology support that 2D geometries currently have in 3D space.

====Problem structure====

*3D topological problems for points reduce to coincidence in 3D space.
*3D topological problems for lines are over- and undershoots as well as duplicate vertices. These are completely equivalent to the same problem in 2D space.
*3D topological problems for polygons appear much more complex, as they include overlap in 3D. But this complexity can be reduced significantly. Only polygons that lie in the same plane (including a small error margin -- could be implemented just like the minimum error option in ''v.clean'') can get into topological trouble with each other: if two polygons do not lie in the same plane, then by definition they cannot overlap, only intersect. (It is open to debate, whether an intersection of polygons in 3D space would constitute a topological error.)

====Basic approach====

As a result, the topological cleaning could proceed as follows.

#All 3D polygons need to be '''planar''', i.e. all of their vertices must lie on the same plane. If they are not, then this is a topological error, and the polygon needs to be planarized by ''v.clean'' (add a "planarize" action -- also potentially useful for other geometry types). Planarization is done by first calculating the plane equation of the polygon (a simple equation that defines the location and orientation of a best-fit 2D plane through all vertices) and then reprojecting each of its original vertices to the plane defined by the plane equation (it could make sense to store the plane equations as part of the topological data structure). Planarization needs to be carried out for both boundaries and islands.
#Once planarized, all polygons can be subjected to the exact same topological cleaning as 2D polygons:
##After planarization, group all polygons that lie on the same plane.
##For each "plane group": reproject all vertices to the geographic X-Y reference plane. Run the topological cleaning just like for 2D polygons, but preserve the Z coordinates.
##Then revert the projection of all vertices back to the group's original reference plane, using the plane equation.
##Do the same with the next "plane group" until all polygons have been processed.
#Faces (3D triangles) are primitives that are part of more complex 3D geometries (including TINs and 3D hulls). Topological problems involving such geometries are too complex to handle in GIS. Thus, should not be checked for overlap. GRASS GIS should just assume that faces are part of complex geometries that are not to be subjected to analytical treatment, but simple tasks, such as visualization, only. Therefore, only basic cleaning (check for duplicate coordinates, zero-area triangles, etc.) will be carried out. Faces are always planar by definition.
#The areas and centroids of both faces and planar polygons can be calculated in 3D space just as they can be calculated in 2D space.

====Implementation details====

A simple algorithm for computing the plane equation of a set of vertices is <missing URL> available in the form of Newell's Method]. This method requires three points to define a plane. This requirement is met by even the most simply polygons. However <missing URL>: "Newell's method is known to fail if the 3 points are chosen around a concave corner - the normal of the resulting plane will point in the direction opposite to the expected one."

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* <strike>Add new partial differential equation (PDE) library with OpenMP support</strike> (GRASS 6.3)

=== Modules ===

* g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [http://intevation.de/rt/webrt?serial_num=3009].
: controversial, needs more discussion --HB
* g.region
** [http://grass.itc.it/pipermail/grassuser/2007-February/038337.html Glynn's notes] - cleaning the print flags and new <tt>print=</tt> option
** <strike>Support '''vector's 3rd''' dimension in '''g.region vect= [-a]''', '''[res=]''', like the 2d extents are (or should be)</strike> see [http://trac.osgeo.org/grass/ticket/121 trac #121]

== Database ==
=== Library ===

* <strike>establish SQLite as default DBMI driver for vector attribute storage (DBF is too limited).</strike> '''done May 2008.'''

=== Modules ===
* allow cross-mapset database access, i.e. parse the '@mapset' notation appended to vector names (requires access via possibly different DBMI drivers)

==== rename ====
* rename db.in.ogr to db.import

== Imagery ==

Page has been moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib

== 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 ==

The page moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/DisplayLib

== Postscript ==
=== Modules ===
ps.map
* remove scale parameter
: -> from the command line, not the map instruction
* rename sizecol to sizecolumn (remove the given warning)
* use PAL/JPAL [http://geosysin.iict.ch/PAL cartographic labelling library] (GPL, C++ language, JNI wrapper)

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 [http://intevation.de/rt/webrt?serial_num=2969 '''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 [http://grass.itc.it/pipermail/grass-dev/2007-August/032607.html 1].

* Eliminate Init.sh. Glynn explains on [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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 [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y 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."
: Actually, I (Glynn) no longer think it's that simple. If other users can create directories within your mapset, they can create directories which you cannot remove, and in which you cannot add, remove or modify files. And this is quite likely to happen: most users will have a umask of 0022 or worse, meaning that other users (i.e. you) cannot modify any files or directories which they create.

== Data management ==

* store vertical units on per-map base, using code from [http://www.gnu.org/software/units/ 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 [http://lists.maptools.org/pipermail/gdal-dev/2005-October/006857.html 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? [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d r.rast4d]

== Visualization ==

* better support for faces and kernels in libgis
: not really Visualization, but....

== CLI ==

=== Parameters standardization ===

* Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup documents/parameter_proposal.txt]

=== Flags standardization ===

* Get rid of 'quiet/verbose' flags, preparation in GRASS 6, e.g.:
<pre>
/* 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"));
}
</pre>

== GUI ==

* Multiplatform
* Fast, minimalist, number of windows reduced
* Novice, ...., Expert profiles for the GUI (with reduced features), tailored for use cases, e.g. 3D models of a risk map,
* link from application to the relevant wiki online support, so that non-programmers can contribute to GRASS support
* compile wiki online content and help pages into a offline version of help pages for usage in GRASS without internet access.
* Manageable also from command line via d.* modules
* Facilitating easy development of custom GUI application based on GRASS
* <strike>drop '''d.m'''</strike> {{done}}
* <strike>drop '''gis.m'''</strike> {{done}}

* → [[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 -- <cite> frankie at #grass irc</cite>
** 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 -- <cite> frankie at #grass irc</cite>
* Creating $HOME/.grass7 directory for {{done}}
** Custom fonts
** r.li and other modules temp. files
** GEM addons installation {{done}}
** Default path for custom scripts
** Custom symbols and EPS fill patterns
** Custom color maps
** Add here new item...

* [[GRASS repository layout proposal]]

== User Wishes ==

''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[User:MarisN|MarisN]] 12:00, 4 August 2006 (CEST)
* here are some examples to get inspired (apparently that's already possible):
** [http://skagit.meas.ncsu.edu/~helena/publwork/grasskey02/grass02talk10.html dynamic surfaces and volumes]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/cenntenial/water01dsmall.gif some water]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/balsam/fanimwalk.gif particles]
** [http://www.fhpv.unipo.sk/kagerr/pracovnici/hofierka/pv_results.html solar radiation and energy]
* Convince the users to use ParaView [http://www.paraview.org] for sophisticated animations --[[User:Huhabla|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 [http://www.llnl.gov/visit/ VisIt software], it should be able to read GRASS maps directly via GDAL

== Complete GRASS Test Suite: see activity on [[Test_Suite | Test Suite development page]] ==
* base a comprehensive test suite on [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/?C=M;O=D Soeren's GRASS Test Suite]
* automated error checking on all modules to catch data corruption issues

[[Category:Development]]
[[Category:Release Roadmap]]

AddOns

2009-09-28T14:21:08Z

⚠️Benducke:

This page contains references to user contributions and add-ons (the original GRASS GIS software can be downloaded [http://grass.osgeo.org/download/index.php here]).

__TOC__

== AddOns source code repository ==

The AddOns source code is hosted in [http://svn.osgeo.org/grass/grass-addons/ GRASS-AddOns SVN repository].

To checkout:

svn checkout <nowiki>https://svn.osgeo.org/grass/grass-addons/</nowiki> grass-addons

Please read [http://trac.osgeo.org/grass/wiki/HowToContribute#WriteaccesstotheGRASS-Addons-SVNrepository How to get write access to the GRASS-Addons-SVN repository] and contact the [http://lists.osgeo.org/mailman/listinfo/grass-dev grass-dev] mailing list if you would like to host your module there.

== Building and installing Addons ==

* see the [[Compile and Install#Addons]] wiki page

== Adding something new ==

Please announce your add-on to the GRASS users' mailing list so that others may be aware of your work. Also please consider adding your module to one of the [[Applications]] pages.

=== Copyright and licensing information ===

''Please be sure to include copyright and licensing information in the header comments of your code so that others may know how they can use, extend, modify, and redistribute your work.''

e.g. at the top of a shell script:
<pre>
#!/bin/sh
############################################################################
#
# MODULE: v.in.e00
#
# AUTHOR(S): Markus Neteler, Otto Dassau
#
# PURPOSE: Import E00 data into a GRASS vector map
# Imports single and split E00 files (.e00, .e01, .e02 ...)
#
# COPYRIGHT: (c) 2004, 2005 GDF Hannover bR, http://www.gdf-hannover.de
#
# This program is free software under the GNU General Public
# License (>=v2). Read the file COPYING that comes with GRASS
# for details.
#
#############################################################################
#
# REQUIREMENTS:
# - avcimport: http://avce00.maptools.org

[script follows]
</pre>

=== Coding standards ===

Please have a look at our [http://grass.osgeo.org/grass63/source/SUBMITTING_SCRIPTS Shell script coding standards] before submitting here.

There are other coding standards given for modules written in C, Tcl/Tk, and Python''(?)'' located in the GRASS source code.

=== Documenting your code ===

You can have an help page template auto-generated by using the GRASS [[module command line parser | command line parser]] with the <tt>--html-description</tt> command line option. Please, see also the [http://grass.ibiblio.org/grass63/manuals/html63_user/g.parser.html g.parser help page]

== Miscellaneous Add-ons ==

* [http://trac.osgeo.org/grass/browser/grass-addons/misc/utm_which_zone utm_which_zone.sh] is a shell script to determine UTM zone from Lat/Lon input. Requires [http://www.octave.org Octave] or Matlab to be installed. A shell-only version is [http://dcalvelo.free.fr/grass/utm_which_zone_sh.sh available] which only requires awk. '''Authors''': Hamish Bowman (Octave part), Markus Neteler (shell script wrapper), Daniel Calvelo (sh+awk version)

* Perl scripts for converting data forth and back between Excel files and PostgreSQL: [http://dcalvelo.free.fr/grass/pg2xls.pl pg2xls.pl] reads data from PostgreSQL and produces an excel workbook; [http://dcalvelo.free.fr/grass/xls2sql.pl xls2sql.pl] reads excel files and outputs SQL statements to be fed into an RDBMS. Both scripts need modules from [http://www.cpan.org CPAN], especially [http://search.cpan.org/dist/Spreadsheet-ParseExcel/ Spreadsheet::ParseExcel] for xls2sql.pl and [http://search.cpan.org/~tmtm/Spreadsheet-WriteExcel-FromDB Spreadsheet::WriteExcel::FromDB] and its dependencies for pg2sql.pl. Check the source headers for more info. '''Authors:''' Daniel Calvelo (xls2sql.pl), Markus Neteler (pg2xls.pl)

* [http://dream.lrrl.arch.tu-muenchen.de/~wqual/perl/dbf2sql.tgz dbf2sql] is a Perl script for translating dbf-tables into a sql-command. dbf-tables are read using dbfdump-command from dbd-xbase-perl module ([http://search.cpan.org/~janpaz/DBD-XBase-0.241/ dbd::xbase] and [http://search.cpan.org/~jv/Getopt-Long-2.35/lib/Getopt/Long.pm getopt::long] have to be installed from CPAN first). There are problems, if the last column of the table contains characters. Suggestions for improvements welcome! '''Author:'''Wolfgang Qual

* [http://www.igc.usp.br/pessoais/guano/downloads/azimuth2.c azimuth2.c] is a small C program to calculate the azimuth and length of vector lines exported by GRASS-GIS as ASCII files (like this: v.out.ascii input=vector output=ascii format=standard). It is useful for create rose diagrams of lineament maps. Improvements on the original code after suggestions by Örs Téglásy, Hungary. '''Author:''' Carlos Henrique Grohmann

==GRASS 4.x==

===Raster add-ons for GRASS 4===

* MAGICAL Software: The MAGICAL software comprises a suite of three programs that provide a multi-agent simulation extension for the GRASS GIS software. http://www.ucl.ac.uk/~tcrnmar/simulation/magical/magical.html

==GRASS 5.x==

===Vector add-ons for GRASS 5===

* See here: http://grass.osgeo.org/download/addons.php

===Raster add-ons for GRASS 5===

* See here: http://grass.osgeo.org/download/addons.php

* [http://www.valledemexico.ambitiouslemon.com/gwmodelling.html r.gmtg] The groundwater modelling tool for grass. A module to use MODFLOW within GRASS. '''Author''': Jaime Carrera

* [http://www.bowdoin.edu/~ltoma/research.html r.terracost] Scalable approach for computing least-cost-path surfaces on massive grid terrains. For GRASS 5.3. '''Lead author''': Laura Toma
:Newer version available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.terracost

==GRASS 6.x==

=== Vector add-ons ===

See also

svn co https://svn.osgeo.org/grass/grass-addons/vector

==== v.adehabitat.clusthr, v.adehabitat.kernelUD, v.adehabitat.mcp ====

: Tools to calculate home ranges of animals
: '''Author:''' Clement Calenge

Available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/vector/adehabitat

==== v.append ====

: [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.append v.append] is a shell script combining two vector files AND their associated attribute tables. The vector files should be of the same type and, for best results, should have identically formatted attribute tables.

: '''Author:''' Michael Barton

==== v.autokrige ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.autokrige/v.autokrige.py v.autokrige] achieves automatic ordinary kriging from GRASS sites (vector point data), using R with spgrass6 (RGRASS) and automap packages.

: '''Author:''' Mathieu Grelier

==== v.breach ====

: [http://www.sieczka.org/programy_en.html v.breach] creates vector maps of lines and points of continously lowering elevation down the input watercourses, based on the input raster DEM.

: '''Author:''' Maciej Sieczka

==== v.colors ====

: {{cmd|v.colors}} ''moved into main archive''

==== v.count.points.sh ====

: [http://wiki.iosa.it/dokuwiki/spatial_analysis:feature_count v.count.points.sh] counts point features in areas, generates table good as input to d.vect.chart.

: '''Author:''' Stefano Costa

==== v.digatt ====

: [http://phygeo7.geo.uni-augsburg.de/gis2/scripts/v.digatt v.digatt] (shell script) Interactively assign numeric table attributes to series of vector objects. It is meant to be effective by avoiding to type in the attribute value for all single objects again and again. The user is prompted for typing in an attribute value which is assigned to all objects selected by mouseclick afterwards. Next the display is redrawn after updating the table column. Zooming allows to change the region before the old value can be reused or a new one can be typed in (or copied by mouse from another object) in order to assign it to the next series of objects etc. It is tested not very extensively yet. Therefore better work with a copy of your map and consider using v.digit or d.what.vect -e alternatively. [http://phygeo7.geo.uni-augsburg.de/gis2/scripts/v.digatt.png screenshot].

: '''Author:''' Andreas Philipp

==== v.dip ====

: [http://marcin.slodkowski.googlepages.com/v.dip.tgz v.dip] creates points of thickness vectors from the vectors of strike and dip angles. The v.dip is the main ANSI C core program. Program so-called v.dip can run without GRASS environment.

: '''Author:''' Marcin Slodkowski

==== v.flip ====

: [http://www.sieczka.org/programy_en.html v.flip] flips the direction of selected vector lines (redundant since GRASS 6.3 - there is "v.edit tool=flip").

: '''Author:''' Maciej Sieczka

==== v.group ====

: [http://www.shockfamily.net/cedric/grass/v.group v.group] generates a new vector map with the same geometry as an existing map. The new map has categories and a table based on grouping by the values in certain columns of the existing map's table. The values in these columns are preserved in the table for the new map. It's like a v.reclass that preserves data.

: '''Author:''' Cedric Shock

==== v.in.gama ====

: Converts [http://www.gnu.org/software/gama/ GNU GaMa] XML output file to a GRASS vector map layer.

:'''Author:''' Martin Landa

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.in.gama

==== v.in.geoplot ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.in.geoplot v.in.geoplot] converts a [http://www.geoscan-research.co.uk/page9.html/ Geoplot] ASCII export file to a GRASS vector map layer.

:'''Author:''' Benjamin Ducke

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.in.geoplot

==== v.in.gshhs ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.in.gshhs v.in.gshhs] imports [http://www.soest.hawaii.edu/wessel/gshhs/gshhs.html GSHHS] shorelines into a GRASS vector map. GSHHS data are automatically reprojected to the current location.

:'''Authors:''' several, updated to GRASS 6 by Markus Metz

==== v.in.ncdc ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.in.ncdc v.in.ncdc] imports an [http://www.ncdc.noaa.gov NCDC] stn file (station data) into a GRASS vector map.

: '''Author:''' Huidae Cho

==== v.in.postgis ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.in.postgis/v.in.postgis.py v.in.postgis] Create a GRASS layer from any sql query on PostGIS data.

: '''Author:''' Mathieu Grelier

==== v.in.osm ====

: [http://kripton.kripserver.net/software/v.in.osm/ v.in.osm]: OpenStreetMap import into GRASS. Yet only supports deprecated API 0.4, will be modified to work with API 0.5 some time soon.

: '''Author:''' Jannis Achstetter

: See also [http://hamish.bowman.googlepages.com/gpsdrivefiles#osm osm2grass.sh] by H Bowman

==== v.in.ovl ====

: [http://grasslab.gisix.com/scripts/v.in.ovl/ v.in.ovl] is a shell script that imports an ASCII vector file created with TOP10|25|50 or similar products.

: '''Author:''' Peter Löwe

==== v.krige ====

: [[V.krige_GSoC_2009 | v.krige]] aims to integrate R functions for kriging (packages automap, gstat, geoR) in a trasparent way. '''Still beta''': testing welcome.

: '''Author:''' Anne Ghisla, as Google Summer of Code 2009 project

: See also [[GRASS_AddOns#v.autokrige]] by Mathieu Grelier

==== v.lda ====

: [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.lda v.lda] is a shell script for calculating Ian Johnson's (U. Sidney) Local Density Analysis values to measure clustering of point data at different neighborhood radii. There is an option to create a simple line graph of the results. There have been reports of problems creating the line graph on Cygwin installations of GRASS.

==== v.line.center ====

: [http://www.sieczka.org/programy_en.html v.line.center] creates a points vector map with each point located in the middle of the length of the input vector line.

: '''Author:''' Maciej Sieczka

==== v.lmeasure ====

: [http://ngeo.de/grassstuff/v.lmeasure v.lmeasure] and [http://ngeo.de/grassstuff/v.revlmeasure v.revlmeasure] are two perl scripts that place equidistant vector points along a given arbitrary vector line starting from the beginning or end of the vector line, respectively. Resulting vector points are labeled with the distance from origin.

: '''Author:''' Mats Schuh

==== v.out.ascii.db ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.out.ascii.db v.out.ascii.db] is a shell script for exporting vector point data coordinates and selected attribute columns to either a file or to the console.
: ''Superseded in GRASS 6.4 by the new v.out.ascii columns= option.''

: '''Author:''' Hamish Bowman

==== v.out.ascii.mat ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.out.ascii.mat v.out.ascii.mat] is a shell script for exporting vector polygon and polyline data into an ASCII text file suitable for loading into Matlab (or [http://www.gnu.org/software/octave/ Octave]).

: '''Author:''' Hamish Bowman

==== v.out.gmt ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.out.gmt v.out.gmt] is a shell script that exports a polygon vector file into GMT xy file. psbasemap code was copied from Hamish's r.out.gmt.

: '''Author:''' Huidae Cho, Hamish Bowman, Dylan Beaudette

==== v.out.kml ====

: [http://grasslab.gisix.com/scripts/v.out.kml/ v.out.kml] is a shell script that exports a vector file into a KML file for Google Earth or Worldwind.

: '''Author:''' Peter Löwe

==== v.out.svg ====

: [http://svg.cc/grass/index.html v.out.svg] is a module that exports SVG notation along with optional attribute data directly from GRASS 6.x vector layers. Now part of [http://svn.osgeo.org/grass/grass/trunk/vector/v.out.svg/ grass6-svn].

: '''Author:''' Klaus Förster

==== v.random.cover ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.random.cover v.random.cover] is a shell script for creating random points constrained within an irregularly shaped vector area. (v.random places points only in current region rectangle). Optionally the user can upload raster values at the points. See also '<tt>r.random cover= vector_output=</tt>'

: '''Author:''' Hamish Bowman

==== v.rasterbounds ====

: [http://les-ejk.cz/programs v.rasterbounds] is a shell script for creating polygon-vector file of rasterfile boundaries. The best version of GRASS is 6.1+. If you are using GRASS < 6.1, you have to be in the same mapset as your raster maps are from.

: '''Author:''' Jachym Cepicky

==== v.sample.buffer [broken link, please update or delete]====

: [http://www.clubwebcanada.ca/twiens/v.sample.buffer.tgz v.sample.buffer] is a shell script that samples rasters in buffers of a specified size around features in a specified vector file. Sampling results are added as attributes to the vector file. This script was designed for sampling vegetation indices and DEM derived attributes for bird point counts. Sampling results can be one or more basic statistics such as mean, range, max, etc.

: '''Author:''' Trevor Wiens

==== v.select.region ====

: [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/v.select.region.tar.bz2 v.select.region] is a shell script that prints out the names of all vectors matching an input search pattern that has geometry (points, line, areas) that fall within a region bounded by an existing vector map, or within the current Grass region.

: '''Author:''' Eric Patton

==== v.selmany ====

: [http://svn.osgeo.org/grass/grass-addons/vector/v.selmany/v.selmany v.selmany] is a shell script that allows to interactively select a set of vector objects on a given layer, then assign them attribute values in a connected database table. The script runs on the command line prompt and within a graphic monitor ; it does not work with DBF driver.

: '''Author:''' Vincent Bain

==== v.surf.icw ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.surf.icw v.surf.icw] is an IDW interpolation method using true distance cost instead of euclidean shortest distance, i.e. ''as the fish swims around an island'' not ''as the bird flies''. This will cleanly travel around hard barriers and a cost surface map may be used to model expensive-cross barriers. Input data points do not need direct line of sight to be considered, but should be kept to less than one hundred as the module becomes very computationally expensive. A number of radial basis function options are available. ([http://grass.osgeo.org/wiki/Image:Inlets_03_SurfSal_icw_big.png screenshot])

: '''Author:''' Hamish Bowman

==== v.surf.idwpow ====

: [http://www.geospatial.it/allegri/grass/v.surf.idwpow.zip v.surf.idwpow] integrates the common v.surf.idw algorithm with the exponential parameter for the distance weights

: '''Author:''' Giovanni Allegri

==== v.surf.krige [deprecated: use v.autokrige instead] ====

: v.surf.krige is a script that do a surface interpolation from vector point data by Kriging method. The interpolated value of a cell is determined by using an omnidirectional variogram model fitted starting from model parameter given by user shown from the experimental semi variogram produced by v.variogram. The script can perform also the Leave-One-out cross validation to test the variogram model "fitted by eye" and an automatic fitted variogram model. The cross validation helps the user to choose the best variogram model to interpolate own data.

: '''Author:''' Pierluigi De Rosa.

==== v.strahler ====

: [http://www.pois.org/florian/downloads/grass/v.strahler.tgz v.strahler] is a module that calculates the Strahler Order for all lines of a given dendritic network.

: '''Author:''' Florian Kindl. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.strahler

==== v.swathwidth ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.swathwidth v.swathwidth] creates a vector map representing the sea bottom coverage of a multibeam (swath) sonar survey.
: ([http://david.p.finlayson.googlepages.com/swathwidth Screenshots])

: '''Authors:''' David Finlayson, Hamish Bowman

==== v.thickness ====

: [http://marcin.slodkowski.googlepages.com/v.thickness.tgz v.thickness] creates points of thickness vectors from the vectors of strike and dip angles.The v.thickness is GUI GRASS script for v.dip.

: '''Author:''' Marcin Slodkowski

==== v.trees3d ====

: [http://les-ejk.cz/programs/ v.trees3d] is a module for making 3D trees from input vector point file.

: '''Author:''' Jachym Cepicky

==== v.trimesh ====
: [http://www.valledemexico.ambitiouslemon.com/vtrimesh.html v.trimesh] creates a triangular mesh from a vector map using areal constraints for refinement. It uses Jonathan Shewchuk's Triangle library.

: '''Author:''' Jaime Carrera

==== v.what.rast.buffer ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.what.rast.buffer v.what.rast.buffer] is a script that calculates univariate statistics of raster map(s) from buffers around vector points. Results are written to a file. Resolution is taken from each input map.
: ''see also the [http://starspan.casil.ucdavis.edu StarSpan] software

: '''Author:''' Hamish Bowman

==== v.variogram [deprecated: use v.autokrige instead] ====

: v.variogram is a script that create an omnidirectional experimental semi-variogram. This scripts require R-statistics software installed on your machine. Now the script is updated to run on spgrass6 >= 0.3 and sp >= 0.9 [http://grass.osgeo.org/pipermail/statsgrass/2006-October/000455.html reply].

: '''Author:''' Ivan Marchesini, Pierluigi De Rosa.

==== AniMove ====

: [http://www.faunalia.it/animov/ AniMove] is software for analysis of animal movement and ranging behaviour using QGIS+GRASS+R.

:'''Authors:''' Support by Faunalia.it

==== Utilities ====

===== Shapemerge =====

: [http://perrygeo.googlecode.com/svn/trunk/gis-bin/shpmerge.sh shpmerge] merges all the shapefiles in the current directory into a single output shapefile

:'''Authors:''' Perrygeo

=== Raster add-ons ===

See also

svn co <nowiki>https://svn.osgeo.org/grass/grass-addons/raster</nowiki>

==== r.bilateral ====

: [http://les-ejk.cz/files/programs/grass/r.bilateral.tgz r.bilateral] Bilateral filter is an edge-preserving filter, which combines domain and range filtering. It is written in C language.

: '''Author:''' Jachym Cepicky

==== r.boxcount ====

: r.boxcount and r.boxcount.sh calculate the fractal dimension for a given map. These are versions for grass6 of [http://www.ucl.ac.uk/~tcrnmar/ Mark Lake's modules] for grass43.

: '''Authors:''' Mark Lake, grass6 port: Florian Kindl.

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.boxcount/
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.boxcount.sh/

==== r.burn.frict ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.burn.frict r.burn.frict] converts vector geometries to raster cells, using a simple anti-aliasing method to close "gaps" between diagonal cells. Useful for "burning" vector geometries into a friction surface, making sure that simulated movement does not "slip" through converted cells that have only diagonal neighbours.

:'''Author:''' Benjamin Ducke

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.burn.frict

==== r.colors.quantiles ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.colors.quantiles/r.colors.quantiles r.colors.quantiles] is a shell script used to create raster colors rules based on nquantiles. It uses R and spgrass6 package (RGRASS).

: '''Authors:''' Mathieu Grelier

==== r.colors.stddev ====

: [http://hamish.bowman.googlepages.com/grass_color_maps r.colors.stddev] ''moved into main archive''

==== r.cpt2grass ====

: [http://hamish.bowman.googlepages.com/grass_color_maps r.cpt2grass] is a GRASS script for importing a [http://www.soest.hawaii.edu/gmt/ GMT] .cpt color table into GRASS. It can save to a text file suitable for r.colors or automatically apply the color table to a raster map. For a large collection of GMT .cpt files see http://sview01.wiredworkplace.net/pub/cpt-city/
: Other palette ideas from [http://geography.uoregon.edu/datagraphics/color_scales.htm Univ. Oregon] and [http://oceancolor.gsfc.nasa.gov/PRODUCTS/colorbars.html NASA/Goddard's OceanColor] (latter partially translated for use with GRASS on the [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.colors.tools/palettes grass-addons SVN]).

: '''Author:''' Hamish Bowman

==== r.csr ====

: [http://www.chrisgarstin.com/stuff/r.csr r.csr] integrates several Grass programs to produce colored, shaded-relief rasters in one step. Accepts single or multiple elevation/bathymetry maps as input; optionally will fill data holidays with 3x3 median filter, multiple times, if required; can apply color maps from a) input raster, b) another raster in MAPSET, or c) from a rules file; otherwise, rainbow colorbar is applied. Output colored, shaded-relief rasters can optionally be exported to tiff format if the appropriate flag is given. Shading parameters can be modified, though useful defaults are given.

: '''Author:''' Eric Patton

==== r.cva ====

: [http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html r.cva] is a cumulative viewshed analysis module. It is an advanced version of the {{cmd|r.los}} program.

: '''Author:''' [http://www.ucl.ac.uk/~tcrnmar/ Mark Lake]

==== r.denoise ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.denoise r.denoise] denoises (smooths/despeckles) topographic data, particular DEMs derived from radar data (including SRTM), using Xianfang Sun's [http://www.cs.cf.ac.uk/meshfiltering/index_files/Page342.htm denoising algorithm]. It is designed to preserve sharp edges and to denoise with minimal changes to the original data. See the [http://personalpages.manchester.ac.uk/staff/john.stevenson/mdenoise/r.denoise.html manual pages] for details. Further information on Sun's denoising algorithm, including an example, is available [http://personalpages.manchester.ac.uk/staff/john.stevenson/mdenoise here].

: '''Author:''' John Stevenson

==== r.dominant_dir.m and r.calc_terraflow_dir.m ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.terraflow.tools dominant_dir.m and calc_terraflow_dir.m] are two Matlab scripts for determining the dominant flow direction from a r.terraflow MFD map and converting into a GRASS aspect map for use with d.rast.arrow, etc.

: '''Author:''' Hamish Bowman

==== r.eucdist ====

: [http://david.p.finlayson.googlepages.com/r.eucdist r.eucdist] creates a raster map estimating the euclidean distance from known cells.

: '''Author:''' David Finlayson

==== r.fragment ====

: [http://www.chrisgarstin.com/stuff/r.fragment r.fragment] fragments a raster into a user-defined set of smaller tiles according to an input number of rows and columns.
: '''Author:''' Eric Patton

==== r.game_of_life ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.game_of_life r.game_of_life] is a shell script which runs Conway's classic Game of Life using GRASS raster modules. It is meant to demonstrate how easy it is to program cellular automata in GRASS as well as various 3D raster volume and time series visualization techniques.

: '''Author:''' Hamish Bowman

==== r.gauss ====

: [http://www.les-ejk.cz/files/programs/grass/r.gauss.tgz r.gauss] is Gaussian and Laplacian of Gaussian filter for GRASS. It is written in C language.

:'''Author:''' Jachym Cepicky

==== r.gradgrid4 ====

: [http://www.uibk.ac.at/geographie/personal/mergili/gradgrid4.zip gradgrid4] is a tool for interpolating values of discrete data points to a raster map, applying a local regression approach with a predictor raster. The model is based on shell and python scripts as well as an R batchfile. It was tested on Fedora Core 6 with GRASS 6.2.1 and R 2.5.1, but should work under most UNIX systems. After unzipping the gradgrid4 folder, store it at any place in your local file system. In the subfolder docs you can find a manual and a publication draft with a detailed description of the concept and the example of an application. The subfolder testloc constitutes a GRASS location with test data.

: '''Author:''' Martin Mergili

==== r.in.onearth ====

: [http://www-pool.math.tu-berlin.de/~soeren/grass/modules/ r.in.onearth] for download and import satellite images direct from the NASA onearth WMS server into GRASS.

: '''Author:''' Soeren Gebbert

==== r.in.wms (.py) ====

: [http://les-ejk.cz/files/programs/grass/r.in.wms.tgz r.in.wms] for download and import maps direct from WMS servers into GRASS. This script is written in Python Programming language. Note GRASS 6.2+ provides a shell script version of r.in.wms, take care of which one is actually being run.

: '''Author:''' Jachym Cepicky

==== r.inund.fluv ====

: [https://svn.osgeo.org/grass/grass-addons/raster/r.inund.fluv/ r.inund.fluv]This command allows to obtain a fluvial potentially inundation map given a high-resolution DTM of the area surrounding the river and a water surface profile calculated through an 1-D hydrodinamic model.

: '''Authors:''' Roberto Marzocchi, Bianca Federici, Domenico Sguerso

==== r.isoregions ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.isoregions/r.isoregions r.isoregions] allows isoregions creation from a GRASS raster map.

: '''Authors:''' Mathieu Grelier

==== r.interp.mask ====

: [http://david.p.finlayson.googlepages.com/r.interp.mask r.interp.mask] Creates a user-specified buffer around interpolation points that can be used as a MASK to prevent or clip excessive extrapolation artifacts. This works much better than a standard convex hull around the points.

: '''Author:''' David Finlayson

==== r.li ====

: [http://www.faunalia.it/download/r_li/ r.li] is a more flexible and faster replacement of the old r.le. '''''Moved into 6.3-SVN'''''.

: '''Authors:''' Claudio Porta, Davide Spano, Serena Pallecchi, [http://www.faunalia.it Faunalia]

==== r.local_max.pl ====

: [http://les-ejk.cz/files/programs/local_max.pl Local maxima] is a Perl script for <code>r.mapcalc</code>. It detects local maxima of the image.

: '''Author:''' Jachym Cepicky

==== r.mandelbrot ====

: [http://grasslab.gisix.com/scripts/r.mandelbrot r.mandelbrot] is a shell script to calculate the Mandelbrot set.- for GRASS versions 6.X.

: '''Author:''' Peter Löwe

==== mcda====

: mcda suite is a toolset for geographics multi-criteria decision aiding and data analysis based on ELECTRE (r.mcda.electre), REGIME (r.mcda.regime) and FUZZY (r.mcda.fuzzy) algorithm. The module r.roughset is also included for geographics rough set analisys and knowledge discovery based on rough set library. It is written in C language for GRASS versions 6.X.

: '''Author:''' Gianluca Massei (g_massa@libero.it ) - Antonio Boggia

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/mcda/

==== r.mlv ====

: [http://les-ejk.cz/files/programs/grass/r.mlv.tgz r.mlv] is Mean of least variance filter for GRASS. It is an edge-preserving (or even edge-enhacing) filter, which should serve for removing additive noise from images. It is written in C language.

: '''Author:''' Jachym Cepicky

==== r.out.jpeg ====

: [http://www.geospatial.it/allegri/grass/r.out.jpeg_ r.out.jpeg] is a simple GRASS script to export georeferenced JPEG images from rasters, keeping the associated color table. It is a two-step export: first a ppm file is created, then it is converted to jpeg usgin the "convert" command from ImageMagick

: '''Author:''' Giovanni Allegri

==== r.out.gmap ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.out.gmap r.out.gmap] outputs GRASS raster map into set of image tiles
following the tiling scheme of Google Maps and Microsoft Virtual Earth.
 Read more in the OSGeo Journal [http://www.osgeo.org/journal Volume 5 (2009, to appear)]

: '''Author:''' Tomas Cebecauer

==== r.out.gmt ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.out.gmt r.out.gmt] is a GRASS script for exporting a GRASS raster map into a [http://www.soest.hawaii.edu/gmt/ GMT] grid file. It also creates a GMT color table from the data and can generate some GMT commands for plotting a postscript file. (code is experimental, but functional) see also http://169.237.35.250/~dylan/grass_user_group/#GMT_and_GRASS-overview

: '''Authors:''' Hamish Bowman, Dylan Beaudette

==== r.out.gmt2 ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.out.gmt2 r.out.gmt2] is a modified version of Hamish's r.out.gmt. Added options for title, xlabel, ylabel, comment, and map width. Removed any settings that can be changed by gmtset for more flexibility.

: '''Author:''' Huidae Cho, Hamish Bowman, Dylan Beaudette

==== r.pack ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.pack r.pack and r.unpack] are two GRASS scripts for transfering raster maps to another computer as a single file.

: '''Author:''' Hamish Bowman

==== r.roughness ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.roughness/r.roughness.sh r.roughness.sh] is a shell script to calculate the surface roughness of a DEM, using r.surf.area and v.surf.rst. (for GRASS versions 6.1 and above)

[http://www.igc.usp.br/pessoais/guano/downloads/r.roughness60 r.roughness60] - for GRASS versions 6.0.X

[http://trac.osgeo.org/grass/browser/grass-addons/raster/r.roughness/r.roughness.window.area r.roughness.window.area] - calculate surface roughness as the ratio of real (surface) area and planar area, using a moving-window approach.

[http://trac.osgeo.org/grass/browser/grass-addons/raster/r.roughness/r.roughness.window.vector r.roughness.window.vector] - calculate surface roughness as vector dispersion, using a moving-window approach. Resulting maps are: Vector Strength (R) and Inverted Fisher's k parameter.

[http://trac.osgeo.org/grass/browser/grass-addons/raster/r.roughness/r.roughness.window.vector.html r.roughness.window.vector.html] - provisional help page for r.roughness.window.vector.

: '''Author:''' Carlos Henrique Grohmann

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.roughness/

==== r.roughset ====

: r.roughset is a module for geographics rough set analisys and knowledge discovery based on rough set library. It is written in C language for GRASS versions 6.X.

: '''Author:''' Gianluca Massei (g_massa@libero.it ) - Antonio Boggia

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/mcda/r.roughset/

==== r.smoothpatch ====

: [http://david.p.finlayson.googlepages.com/r.smoothpatch r.smoothpatch] creates a composite of two rasters using a distance-weighted average across the transition to smooth the edges.

: '''Author:''' David Finlayson

==== r.soils.texture ====

: r.soils.texture is a module to define soils texture from sand and clay raster file with a schema text file (now FAO,USDA and ISSS are available). It is written in C language. - for GRASS versions 6.x - For bugs and suggest: g_massa@libero.it

:'''Author:''' Gianluca Massei

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.soils.texture/

==== r.stream.basins ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.basins r.stream.basins] delineate basins according users input. It extends r.water.outlet funcionality to extracting more than one basin at one step. Module uses as input direction map produced by r.watershed and stream network produced by r.stream.extract, r.watershed, r.stream order or custom user input. More in tutorial on grass-wiki pages.

: '''Author:''' Jarek Jasiewicz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.basins

==== r.stream.distance ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.distance r.stream.distance] Calculates downslope distance and downslope elevation difference between current cell and stream or outlet cells. It uses r.watershed direction map, r.watershed or r.stream.extract stream map and optionally DEM as input.

: '''Author:''' Jarek Jasiewicz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.distance

==== r.stream.extract ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.extract r.stream.extract] extracts topologically clean stream networks from input elevation and optionally accumulation maps. Output is available as raster and vector and can be used as input for the other r.stream.* modules by Jarek Jasiewicz.

: '''Author:''' Markus Metz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.extract

==== r.stream.order ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.order r.stream.order] orders stream network outputed by r.watershed or r.stream.extract according Sthrahler, Shreve, Horton and Hack ordering systems. It require as input stream and direction map and optionally accumulation map. It handle both SFD nad MFD modes but all data must come from the same procedure.

: '''Author:''' Jarek Jasiewicz, Markus Metz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.order

==== r.stream.stats ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.stats r.stream.stats] calculate Hortonian statistics for Stahler or Horton stream network created by r.stream.order. It uses r.watershed direction map, DEM and r.stream.order's Stahler or Horton stream network as input. It outputs calculated statistics to standard output.

: '''Author:''' Jarek Jasiewicz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.stats

==== r.surf.nnbathy ====

: [http://www.sieczka.org/programy_en.html r.surf.nnbathy] interpolates a surface from a raster input using Pavel Sakov's [http://code.google.com/p/nn-c/ nn] natural neighbor interpolation library. Provides triangulation, Sibson natural neighbor interpolation and non-Sibsonian interpolation.

: '''Author:''' Maciej Sieczka

==== r.surf.volcano ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.surf.volcano r.surf.volcano] creates an artificial surface resembling a seamount or cone volcano. The user can alter the size and shape of the mountain and optionally roughen its surface. Available decay functions are polynomial, Gaussian, Lorentzian, logarithmic, and exponential.

: '''Author:''' Hamish Bowman

==== r.terracost ====

[http://www.bowdoin.edu/~ltoma/research.html r.terracost] Scalable approach for computing least-cost-path surfaces on massive grid terrains. '''Lead author''': Laura Toma

Available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.terracost

==== r.tileset ====

: ''{{cmd|r.tileset}} moved into main archive''

==== r.traveltime ====

: [http://jesbergwetter.twoday.net/stories/4845555/ r.traveltime] computes the travel time of surface runoff to an outlet. The program starts at the basin outlet and calculates the travel time at each raster cell recursively. A drainage area related threhold considers even surface and also channel runoff. Travel times are derived by assuming kinematic wave approximation. The results can be used to derive a time-area function. This might be usefull for precipitation-runoff calculations (estimation of flood predictions) with a lumped hydrologic model (user-specified unit hydrograph).

: '''Author:''' Kristian Förster

==== r.univar.zonal ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.univar2.zonal r.univar.zonal] is similar to r.univar, but calculates statistics separately for each category(zone) present in the separate input map used to define zones (zonal statistics). The output can be like the one of r.univar or in easier to read table format and can be written to a file.

: '''Author:''' Markus Metz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.univar2.zonal

==== r.viewshed ====

: r.viewshed is a module for extremely fast line of sight analysis (replaces the slow r.los). It is written in C language for GRASS versions 6.X/7.x.

: '''Author:''' Laura Toma, USA

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.viewshed

Once {{trac|390}} is solved, it will substitute r.los.

==== r.xtent ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.xtent r.xtent] computes a raster map layer representing the Voronoi diagram, weighted Voronoi diagram or a more complex territorial partitioning of space around points (centers) in a vector input map, based on the XTENT formula.

:'''Author:''' Benjamin Ducke

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.xtent

==== r.zc.pl ====

: [http://les-ejk.cz/files/programs/zc.pl Zero crossing] is a simple Perl script, finds the ,,zero crossings`` from the Laplacian of Gaussian filter (see above). It is really very simple, the edges don't need to be really on that pixel, where they are detected, no interpolation is performed.

: '''Author:''' Jachym Cepicky

==== GIPE ====

: The GRASS Image Processing Environment (GIPE) has USLE, Energy-balance and radiance-reflectance correction models.

: '''Author:''' Yann Chemin (unless specified otherwise).

svn co https://svn.osgeo.org/grass/grass-addons/gipe

Remark: This is progressively moved to main GRASS SVN (aka GRASS 7)

:* r.hydro.CASC2D, ported from GRASS 5.x version, is temporarily here waiting to return to main GRASS.

:* r.soiltex2prop creates porosity, Saturated Hydraulic conductivity (Ksat) and wetting front pressure head (Hf) from percentage of sand and clay after Rawls et al., 1990. This is a must for r.hydro.CASC2D.

:* i.biomass creates biomass growth map from fPAR, lightuse efficiency, water availability (or evap.fraction), Lat, doy and tsw.

:* i.dn2ref.l7, r.dn2ref.ast create top of atmosphere reflectance for Landsat 7ETM+ and ASTER. These modules also have a flag for radiance output. Updated i.dn2ref.l7 to read .met calibration file.

:* i.dn2full.l[5,7] is an attempt to get all bands of Landsat[5,7] calibrated and corrected to either reflectance or temperature, reads only the .met file.

:* i.dn2potrad.l[5,7] is an attempt to get ET potential from DN of Landsat 7 (Careful! No Atmospheric correction!).

:* i.eb.* are a set of 10+ GRASS modules that together perform the main functions of the SEBAL model (Bastiaanssen, 1995). Those functions include (but are not limited to) Soil heat flux, sensible heat flux, net radiation, evaporative fraction at satellite overpass, diurnal actual evapotranspiration, momentum roughness length, etc. These modules are also part of any Energy-Balance related processing.

:* i.evapo.potrad creates diurnal Potential evapotranspiration assuming all net radiation becomes ET, according to SEBAL model (Bastiaanssen, 1995). This module also has a flag for diurnal net radiation as required by SEBAL in i.eb.eta.

:* i.evapo.SENAY creates actual evapotranspiration following the regional method of Senay (2007).

:* i.lmf creates a Local Maximum Fitting on the temporal dimension of the multi-date input dataset, working, but more precision still to be added.

:* i.vi.mpi is the mpi version of i.vi for cluster GRASS GIS education (no speed up here!) '''Author:''' Shamim Akhter

:* i.modis.stateqa extracts State Quality Assessment information from Modis 500m (MOD09A) products.

:* i.water creates a Water Mask from NDVI and Albedo, or specifically for Modis: NDVI and Band 7.

:* i.wi creates a given Water Index (only one so far).

==== HydroFOSS ====

: HydroFOSS - a GIS embedded approach for Free & Open Source Hydrological modeling.

: '''Author:''' Massimiliano Cannata

svn co https://svn.osgeo.org/grass/grass-addons/HydroFOSS/

==== Hikereport ====

: python script that computes length, cumulative uphill and downhill, average slopes on an interactively drawn path. Based on r.profile's output.

: '''Author:''' Stefano Negri

http://tracce.wordpress.com/?attachment_id=71

=== Misc add-ons===

==== m.eigensystem ====

m.eigensystem - Computes eigen values and eigen vectors for square matrices.

: http://svn.osgeo.org/grass/grass-addons/misc/m.eigensystem/

: '''Author:''' Michael Shapiro

===Database add-ons===
==== db.join ====

: Table joining: join one table into another through common attributes

: '''Author:''' Markus Neteler. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/database/db.join/
or
g.extension db.join

===General add-ons===

==== g.laptop.sh ====

: [http://www.nature-consult.de/dassau/g.laptop/g.laptop.sh g.laptop.sh] is an interactive shell script to extract raster and vector data from current Location into a new one. Data can be copied or extracted in current or original resolution and region extend. This script was written to extract smaller parts of a GRASS location to be able to present them on a laptop without the necessity to transfer huge data. Maps do not have to be in the same mapset.

: '''Author:''' Otto Dassau

==== Readline completion ====

: '''''Readline completion''''' for GRASS commands under the bash shell: [http://www.sorokine.info/grass-complete/ grass-complete] won't clutter the environment but needs to be installed; [http://dcalvelo.free.fr/grass/grass_rlcompleter.sh grass_rlcompleter.sh] needs almost no installation but will pollute the environment. Grass-Complete currently requires Bash version 2.05 for proper install.

: '''Author:''' Alexandre Sorokine (grass-complete), Daniel Calvelo (grass_rlcompleter.sh)

==== g.region.point ====

: [http://trac.osgeo.org/grass/browser/grass-addons/general/g.region.point g.region.point] is a shell script which resets the computational region to a square box around a given coordinate. It is intended for use within GRASS scripts to speed up processing by limiting expensive raster calculations to a small area of interest.

: '''Author:''' Hamish Bowman

==== g.linke_by_day ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.sun.tools/ g.linke_by_day] is a python script for [[r.sun]] which interpolates a Linke turbidity value for a given day of the year based on monthly values edited into the script.

: '''Author:''' Hamish Bowman

==== g.xlist ====

: [http://trac.osgeo.org/grass/browser/grass-addons/general/g.xlist g.xlist] is a C implementation of g.mlist. g.xlist searches for data files matching a pattern given by wildcards or POSIX Extended Regular Expressions. POSIX regex(3) functions are required.

: '''Author:''' Huidae Cho

==== g.xremove ====

: [http://trac.osgeo.org/grass/browser/grass-addons/general/g.xremove g.xremove] is a C implementation of g.mremove. g.xremove removes data files matching a pattern given by wildcards or POSIX Extended Regular Expressions. POSIX regex(3) functions are required.

: '''Author:''' Huidae Cho

=== Imagery add-ons ===

See also

svn co https://svn.osgeo.org/grass/grass-addons/imagery

==== GIPE ====

GIPE (see also above in raster section) provides:
i.biomass, i.dn2potrad.l5, i.dn2potrad.l7, i.dn2ref.ast, i.eb.deltat, i.eb.disp, i.eb.eta, i.eb.evapfr, i.eb.g0, i.eb.h0, i.eb.h_SEBAL01, i.eb.h_SEBAL95, i.eb.h_iter, i.eb.molength, i.eb.netrad, i.eb.psi, i.eb.rah, i.eb.rohair, i.eb.ublend, i.eb.ustar, i.eb.wetdrypix, i.eb.z0m, i.eb.z0m0, i.evapo.PT, i.evapo.TSA, i.evapo.potrad, i.evapo.senay, i.evapo.time_integration, i.lmf, i.modis.stateqa, i.sattime, i.vi.grid, i.vi.mpi, i.water, i.wi

svn co https://svn.osgeo.org/grass/grass-addons/gipe/

: '''Author:''' Yann Chemin

==== i.landsat.toar ====

Transform calibrated digital number of Landsat products to top-of-atmosphere radiance or top-of-atmosphere reflectance and temperature (band 6 of the sensors TM and ETM+). Optionally, used to calculate the at-surface radiance or reflectance with atmospheric correction (DOS method).

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.landsat.toar

: '''Author:''' E. Jorge Tizado

==== i.points.reproj ====

: [http://trac.osgeo.org/grass/browser/grass-addons/imagery/i.points.reproj i.points.reproj] is a shell script that will use cs2cs to reproject the target coordinates of a group's POINTS file. By running i.rectify directly to the new target projection, a generation of resampling data loss can be avoided (versus i.rectify + r.proj). On the other hand, i.rectify does not calculate cell resolution well if the map is to be rotated ([http://intevation.de/rt/webrt?serial_num=3296 bug #3296]), in those cases i.rectify+r.proj may be the better option.

: '''Author:''' Hamish Bowman

==== i.plr.py ====

: [[I.plr.py|Probabilistic Label Relaxation]], written in Python

: '''Author:''' Georg Kaspar

==== i.pr ====

: Image classification: implements k-NN (multiclass), classification trees (multiclass), maximum likelihood (multiclass), Support Vector Machines (binary), bagging versions of all the base classifiers, AdaBoost for binary trees and support vector machines. It allows feature manipulation (normalization, principal components,...). It also implements feature selection techniques (RFE, E-RFE,...), statistical tests on variables, tools for resampling (cross-validation and bootstrap) and cost-sensitive techniques for trees and support vector machines.

: '''Author:''' Stefano Merler. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.pr

==== i.spec.sam ====

: Spectral Angle mapping

: '''Author:''' Markus Neteler. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.spec.sam/

==== i.spec.unmix ====

: Spectral unmixing

: '''Author:''' Markus Neteler. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.spec.unmix/

==== i.warp ====

: [http://trac.osgeo.org/grass/browser/grass-addons/imagery/i.warp i.warp] is a shell script that will use gdalwarp to rectify a raw input image using thin plate splines. The map should be imported into GRASS with r.in.gdal and GCPs set with i.points. Input is the raw image (GeoTIFF, JPEG, etc). Output is a GeoTIFF in the imagery group's target location's map projection. Requires a recent (early 2006) version of GRASS 6.1, or newer.

: '''Author:''' Hamish Bowman

=== Display add-ons ===

See also

svn co https://svn.osgeo.org/grass/grass-addons/display

==== d.edit.rast ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.edit.rast d.edit.rast] edits cells in an existing raster map displayed on the current monitor.

: '''Author:''' Huidae Cho

==== d.frame.quarter ====

: ('''obsolete''') [http://trac.osgeo.org/grass/browser/grass-addons/display/d.frame.split d.frame.quarter] is a shell script that will split the display into four quadrants (or sixths) using ''d.frame''. Individual frames are named ''uno, dos, tres, cuatro'', and ''full_screen''.
: Replaced by {{cmd|d.split.frame}} in main.

: '''Author:''' Hamish Bowman

==== d.frame.split ====

: ''d.frame.split moved into main archive as {{cmd|d.split.frame}}''

==== d.hyperlink ====

: [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/d.hyperlink.tar.bz2 d.hyperlink] is an interactive shell script that allows the viewing of hyperlinked images from a vector's attribute table in an external image viewer. Queries can be made via SQL statements or interactive mouse-clicking. The attribute table must be pre-populated with a column containing the image to link the vector to; the user also specifies the image folder in the current MAPSET where the images are located. The script currently supports gimp, Eye of Gnome, gthumb, gpdf, and Inkscape image viewers.

: '''Author: '''Eric Patton

==== d.mark ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.shortcuts d.mark] is a shell script that quickly displays a marker on the display at a given coordinate.

: '''Author:''' Hamish Bowman

==== d.region.box ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.region.box d.region.box] is a shell script that quickly displays a box around the current region.

: '''Author:''' Hamish Bowman

==== d.stations ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.shortcuts d.stations] is a shell script that quickly displays vector points (or sites for GRASS 5.4 and below).

: '''Author:''' Hamish Bowman

==== d.varea ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.shortcuts d.varea] is a shell script that quickly displays vector areas.

: '''Author:''' Hamish Bowman

==== pd-GRASS ====

: [http://www.ornl.gov/sci/gist/software/grass/ pd-GRASS]: Parallel Display for GRASS GIS

: '''Author:''' Alex Sorokine

==== [[IconSymbols]] ====

* [[IconSymbols|Symbols]] which can be used with ''d.vect, d.graph'', and ''ps.map''.

=== Postscript add-ons ===

''See also [[ps.map scripts|ps.map samples and templates]]''.

==== ps.atlas ====

: [http://les-ejk.cz/programs/grass/ps.atlas ps.atlas] is a shell script that makes more maps on current region according to input *.psmap file. General map can be stored as vector file. The resulting *.eps maps can be automatically converted to *.pdf files.

: '''Author:''' Jachym Cepicky

==== [[AreaFillPatterns]] ====

* Hatches for ps.map's vareas

===GRASS and UMN Mapserver===

* [http://www.mail-archive.com/mapserver-users@lists.umn.edu/msg00086.html See interesting posting]

[[Category:Community]]
[[Category:Development]]
[[Category:Documentation]]
[[Category:Installation]]

Spatial SQL

2009-05-08T15:10:03Z

⚠️Benducke: Created page with ''''!!! THIS PAGE IS HEAVILY UNDER CONSTRUCTION !!!''' In recent years, many DBMS have learned to store and manage spatial data directly. Clearly, having feature geometries store...'

'''!!! THIS PAGE IS HEAVILY UNDER CONSTRUCTION !!!'''

In recent years, many DBMS have learned to store and manage spatial data directly. Clearly,
having feature geometries stored alongside their attribute data in one table makes data management
a lot easier in many ways:

*make use of advanced capabilities provided by powerful DBMS engines: user authentication, data
integrity and backup, replication mechanisms, fast indexing, full SQL support, triggers, etc.
*easily manage 1:m and m:n relationships directly in the database
*use external front-ends to ease entry of attribute data while managing geometries in the GIS
*never worry again about breaking the relationship between features and attribute records
*drop restrictions imposed by file-based storage (maximum size, data table limits, slowness)
*transfer data from one system to another without loss of information using SQL dumps
*dramatically improve data access times
*limit data to be held in memory by importing only spatial subregions from the DBMS
*create central data repositories where layers will always be found in the same place
*etc., etc.

While GRASS GIS does not currently support any spatial DBMS directly, it can still interface
them using the OGR-provided drivers and v.in.ogr/v.out.ogr for data import/export.
Several open source databases are supported this way:

PostgreSQL (with the PostGIS extension)
MySQL (Spatial)
SQLite

In addition, the OGR-supplied command line tool "ogr2ogr" can be used to manage all OGR-supported
data sources directly, including

=== SQLite ===

SQLite is a light-weight, embeddable database. It works using single, fully portable files.
Without the need to set up a complex client/server DBMS, it still provides a powerful
data storage back-end:

http://www.sqlite.org

SQLiteStudio is a highly recommended application to manage SQLite databases of any kind:

http://www.sqlitestudio.org

There is a document that outlines how to store spatial data in an SQLite database:

http://trac.osgeo.org/fdo/wiki/FDORfc16

The OGR SQLite driver can store spatial data in an SQLite table in a straight-forward manner:

http://www.gdal.org/ogr/drv_sqlite.html

ogr2ogr
-------

Creation of new database and dumping of 3D Shapefile points into it works. 3D info is preserved,
it is OK to not have any SRS info. In that case, an empty references table will be created
and the SRID for the geometries table will be set to NULL.

Creation of new table in an existing database using the "-update" option works. It is necessary
to also use -nln <name> to specify the new table name.

However, it is possible to manually drop the metadata table and the database keeps working as
expected.

Creation of a new database with DSCO "METADATA=no" does ''not'' work. This is a known bug to be fixed
in GDAL 1.7.0.

French special chars from the DBF file were not preserved. Any attribute fields with a special
character will come out as empty strings (not NULL!). Encoding used to save the DBF file was
ISO-8859-1. UTF-8 encoding worked fine. Original NULL fields are preserved correctly.

v.out.ogr
---------

This module is currently (GRASS 6.4.0 RC4) not able to correctly export data to an SQLite DB.

A quick, dirty hack allowed opening of an OGR data source in update mode, as required for
existing database (not only SQLite DBs!):

papszDSCO = dsco->answers;
Ogr_ds = OGR_Dr_CreateDataSource(Ogr_driver, dsn_opt->answer, papszDSCO);

/* Some OGR drivers do not support overwriting existing sources
or creating new ones.

Note: this is just a blind attempt, as we don't really know, why
the call to OGR_Dr_CreateDataSource() failed in the first place!

Maybe it would be better to have an "-u" flag here to open an existing
DS in update mode (like ogr2ogr does)?
*/
if (Ogr_ds == NULL) {
if (!strcmp (frmt_opt->answer, "SQLite") ||
!strcmp (frmt_opt->answer, "PostgreSQL") ||
!strcmp (frmt_opt->answer, "MySQL")) {
G_message(_("Attempting to open existing OGR data source.\n"));
Ogr_ds =
OGR_Dr_Open(Ogr_driver, dsn_opt->answer, TRUE);
}
}

CSLDestroy(papszDSCO);
if (Ogr_ds == NULL)
G_fatal_error(_("Unable to open OGR data source '%s'"),
dsn_opt->answer);

For new databases, only the first geometry gets stored correctly, all subsequent ones generate
a useless error message:

ERROR 1: sqlite3_step() failed:
SQL logic error or missing database

Adding a new table to an existing DB fails for unknown reasons. The OGR driver creates the
table itself with the correct structure, but not a single geometry is written into it.
The module bails out here (main.c):

CSLDestroy(papszLCO);
if (Ogr_layer == NULL)
G_fatal_error(_("Unable to create OGR layer"));

v.in.ogr
--------

Import of 3D point data w/o projection information into a region with UTM system worked using:

v.in.ogr dsn=tmp3.sqlite layer=finds_xyz output=tmp2 -oz --o

Import of UTF-8 encoded attribute strings worked fine. There was a warning about text fields
being truncated to a maximimum length of 255 chars. However, none of the fields exceeded 100 chars,
anyway.

Import of layers from a database without metadata tables works fine.

Conclusions
-----------

The result is a mixed bag. While the OGR driver itself works fine with some small
glitches that can be worked around, export of data directly from GRASS using
v.out.ogr is currently impossible. Import using v.in.ogr, however works well.

GRASS' v.out.ogr module needs a "-u" (update flag) to open existing data sources
in update mode. It remains useless in its current state.

The SQLite support will be significantly improved in GDAL 1.7.0. At least support for
SpatiaLite geometry BLOBs will be added, perhaps also AutoDesk's format in the future.

It is unclear if/how OGR handles character encodings other than UTF-8 correctly!
When exporting data as UTF from e.g. OOo Calc, double the field length for text fields, since
we are dealing with 16-Bit units!

It might be possible to compile GDAL with GRASS support and use ogr2ogr to access GRASS
vector data instead of v.in.ogr/v.out.ogr. However, there might be limits in the OGR
driver's capabilities plus we'd get that circular linking nightmare again!

The message about truncation issued by v.in.ogr is worrying, since that seemingly
needs to be handled by OGR itself, however we could easily add an option to specify
maximum field length to v.in.ogr (maybe also a function that catches strings which
are too long and were thus truncated?).

''Note:'' the source code for v.out.ogr contains a note that support for kernel type
geometries has not yet been implemented. I am not currently sure about v.in.ogr and kernels.

GRASS Documents

2009-05-08T14:46:05Z

⚠️Benducke: /* General */

== Usage ==
===== [[Faq|FAQ]] =====
===== [http://grass.osgeo.org/gdp/manuals.php GRASS Manual pages] =====

===== [http://grass.osgeo.org/gdp/tutorials.php GRASS Tutorials] =====
* [[GRASS 5 Tutorial]]
* [[GRASS 6 Tutorial]]
** [http://www.ing.unitn.it/~grass/docs/tutorial_62_en/index.html GRASS 6.2.3 tutorial] by Ciolli, Tattoni, Vitti, Zottele, and Zatelli.
* [[Common Tasks]]
* [http://www.grassbook.org/ GRASS Book] with new educational data set download

===== Training media =====

* [[GRASS_Education_%28Free_GIS_education%29#Teaching_Materials| Courses, training videos, presentations, etc.]] contributed by the community.

=== Help with tasks ===

* Help with [[data formats]]

* Help with the [[module command line parser]]
* Help with [[RST Spline Surfaces]]
* [[Help with 3D]]

* Help with [[Image_processing|Imagery and satellite]] data

* Help with [[LIDAR|LIDAR and swath bathymetry]] data

* Help with [[Time series]]

* Help with creating [[Movies|Movies and animations]]

* Help with [[vector network analysis]]

* Help with [[GPS]] applications

* [[Trace vector contours from a scanned map]]

* [[Digitizing Area Features]]

==== Other ====

* [http://grass.osgeo.org/gdp/index.php GRASS Documentation project] (huge amount of information for many versions of GRASS spanning the last 15 years; relevant content needs to be moved into this Wiki [''please help!''])

* [[GRASS_Education_%28Free_GIS_education%29#Teaching_Materials | Teaching materials]] contributed by the community (Tutorials, courseware, training videos, etc.)

* [[GRASS raster semantics]]
* [[Vector Database Management]] Help
* GRASS [[Vectordata#GRASS_6_Vector_Architecture | vectordata]] (topological)

== General ==
===== [[GRASS Citation Repository]] =====
===== [[Tips and Tricks]] =====
===== Cartography =====
* [[Ps.map_scripts|ps.map cartographic output examples]]
* [[GRASS_and_GMT|Export]] to the [http://gmt.soest.hawaii.edu/ GMT] software package for publication quality cartography

===== [[SQL]] support in GRASS GIS =====

===== [[Spatial SQL]] support in GRASS GIS =====

== Installation ==
* [[Installation Guide]] for binary packages
* [[Compile and Install]] from SVN source code repository (the latest and greatest...)
* [[Compile and install GRASS and QGIS with GDAL/OGR Plugin]] (e.g., to enable QGIS to read GRASS data directly)
* [[GRASS AddOns]] (User contributions)

== Development ==
* Programming: see document list at [[Development]].
* [[GRASS Translation Glossary]]
* [[GRASS Module Porting List]] (check here if you don't find a certain command in GRASS 6)
* [[Development#Linking GRASS to external languages|Linking GRASS to external languages]]

== Geostatistics ==
* [[How to interpolate point value using kriging method with R and GRASS 6]]