GRASS-Wiki - User contributions [en]

Parallelizing Scripts

2015-10-16T19:32:49Z

⚠️DylanBeaudette: /* GNU Parallel */

=== Bourne shell script ===
* '''Poor-man's multithreading''' using Bourne shell script & backgrounding. WARNING: not all GRASS modules and scripts are safe to have other things happening in the same mapset while they are running. Try at your own risk after performing a suitable safety audit. e.g. Make sure {{cmd|g.region}} is not run, externally changing the region settings.

Example 1:
<source lang="bash">
# note: pgrep may only be available on Linux
for map in `g.mlist rast pat=stress*.[uv]` ; do
if [ `pgrep -c r.surf.nnbathy` -lt 5 ] ; then
r.surf.nnbathy in="$map" out="$map.nn" &
else
r.surf.nnbathy in="$map" out="$map.nn"
fi
done
wait
</source>

Example 2:
<source lang="bash">
### r.sun mode 1 loop ###
SUNRISE=7.67
SUNSET=16.33
STEP=0.01
# | wc -l 867

if [ -z "$WORKERS" ] ; then
WORKERS=4
fi

DAY=355
for TIME in `seq $SUNRISE $STEP $SUNSET` ; do
echo "time=$TIME"
CMD="r.sun -s elevin=gauss day=$DAY time=$TIME \
beam_rad=rad1_test.${DAY}_${TIME}_beam --quiet"

# poor man's multi-threading for a multi-core CPU
MODULUS=`echo "$TIME $STEP $WORKERS" | awk '{print $1 % ($2 * $3)}'`
if [ "$MODULUS" = "$STEP" ] || [ "$TIME" = "$SUNSET" ] ; then
# stall to let the background jobs finish
$CMD
sleep 2
wait
#while [ `pgrep -c r.sun` -ne 0 ] ; do
# sleep 5
#done
else
$CMD &
fi
done
wait # wait for background jobs to finish to avoid race conditions
</source>

* This approach has been used in the {{AddonCmd|r3.in.xyz}} addon script.
* Another example using r.sun Mode 2 can be found on the [[r.sun]] wiki page.
* See the {{cmd|i.landsat.rgb|version=65}} and {{cmd|i.oif|version=65}} examples in 6.5svn.

Backgrounding code which sets environment variables with `eval` requires the use of grouping within ()s:
<source lang="bash">
eval `(
r.univar -ge map="$RED" percentile=95 | grep '^percentile_' | sed -e 's/^/R_/' &
r.univar -ge map="$GREEN" percentile=95 | grep '^percentile_' | sed -e 's/^/G_/' &
r.univar -ge map="$BLUE" percentile=95 | grep '^percentile_' | sed -e 's/^/B_/'
wait
)`
</source>

=== Python ===

* Due to the "GIL" in Python 2.x-3.0, pure python will only run on a single core, even when multi-threaded. All multithreading schemes & modules for (pure) Python are therefore wrappers around multiple system processes, which are a lot more expensive than threads to create and destroy. Thus it is more efficient to create large high-level Python 'threads' (processes) than to bury them deep inside of a loop.

Example of multiprocessing at the GRASS module level:

Similar to the Bourne shell example above, but using the '''subprocess''' python module.
The {{Cmd|i.oif|version=70}} script in GRASS7 is using this method.

<source lang="python">
bands = [1,2,3,4,5,7]

# run all bands in parallel
if "WORKERS" in os.environ:
workers = int(os.environ["WORKERS"])
else:
workers = 6

proc = {}
pout = {}

# spawn jobs in the background
for band in bands:
grass.debug("band %d, <%s> %% %d" % (band, image[band], band % workers))
proc[band] = grass.pipe_command('r.univar', flags = 'g', map = image[band])
if band % workers is 0:
# wait for the ones launched so far to finish
for bandp in bands[:band]:
if not proc[bandp].stdout.closed:
pout[bandp] = proc[bandp].communicate()[0]
proc[bandp].wait()

# wait for jobs to finish, collect the output
for band in bands:
if not proc[band].stdout.closed:
pout[band] = proc[band].communicate()[0]
proc[band].wait()

# parse the results
for band in bands:
kv = grass.parse_key_val(pout[band])
stddev[band] = float(kv['stddev'])
</source>

This can also be accomplished fairly simply by using tracking the number of workers available and using grass.start_command as long as another job can be performed:

<source lang="python">
import os
import multiprocessing as multi

import grass.script as grass

# Find number of workers that can be used on system. This variable could
# also be set manually.
workers = multi.cpu_count()
# This is only a set of examples for r.slope.aspect jobs where the maps are
# named serially.
jobs = range(20)

# Check if workers are already being used
if workers is 1 and "WORKERS" in os.environ:
workers = int(os.environ["WORKERS"])
if workers < 1:
workers = 1

# Initialize process dictionary
proc = {}

# Loop over jobs
for i in range(jobs):
# Insert job into dictinoary to keep track of it
proc[i] = grass.start_command('r.slope.aspect',
elevation='elev_' + str(i),
slope='slope_' + str(i))
# If the workers are used up, wait for all of them from the last group to
# finish.
if i % workers is 0:
for j in range(workers):
proc.[i - j].wait()

# Make sure all workers are finished.
for i in range(jobs):
if proc[i].wait() is not 0:
grass.fatal(_('Problem running analysis on evel_' + str(i) + '.')
</source>

=== GNU Parallel ===
* [http://www.gnu.org/software/parallel/ GNU Parallel] is an advanced version of {{wikipedia|xargs}} which makes it easy to write parallel shell scripts. On many Linux systems GNU parallel defaults to the "--tollef" style syntax. Adding the "--gnu" flag will cause GNU parallel to revert to native syntax. See also the unrelated C "parallel" program which comes with the Linux "moreutils" package. It is tighter but less featureful than GNU Parallel.

<source lang="bash">
### r.sun mode 1 loop ###
SUNRISE=7.67
SUNSET=16.33
STEP=0.01
# | wc -l 867

DAY=355

seq $SUNRISE $STEP $SUNSET | parallel -j+0 r.sun -s elevin=gauss day=$DAY \
time={} beam_rad=rad1_test.${DAY}_{}_beam --quiet
</source>

Another example using the standard GNU parallel syntax. The "-k" flag will ensure that data are written to the output file in the same order than input maps are processed.
<source lang="bash">
# extract raster data from a time-series stack at named vector location
t.rast.list -s my_raster_stack columns="id" | parallel -k --gnu r.what map="{}" points=my_vector_map > output.dat
</source>

When tasks are limited by disk I/O parallel processing may be counter productive. A I/O monitoring tool such as [http://dag.wiee.rs/home-made/dstat/ dstat] can help diagnose cases where the use of GNU parallel fails to saturate all available CPU cores. A solid state disk can usually help cases where dstat reports a "wait" value that is larger than about 10%.

GNU Parallel can also distribute work to other computers, see the video on how:
: http://www.youtube.com/watch?v=LlXDtd_pRaY

=== xargs ===
* {{wikipedia|xargs}} can be told to limit itself to a certain number of processes at once. The r.sun example is almost exactly as with GNU Parallel, except for `-P $CORES -n 1` instead of `-j+0`.

For example, convert a large number of Raster3D maps into 2D rasters:
<source lang="bash">
NUM_CORES=6
g.mlist rast3d | xargs -P $NUM_CORES -n 1 -I{} \
r3.to.rast -r in={} out={} --quiet
</source>

For another example, here we spit apart a PDF and convert each page to a PNG image:

<source lang="bash">
pdftk pdfmovie.pdf burst
NUM_CORES=6
ls -1 pg_*.pdf | xargs -P $NUM_CORES -n 1 -I{} \
sh -c "pdftoppm {} | pnmcut -width 1280 -height 1024 -left 0 -top 0 | \
pnmtopng > \`basename {} .pdf\`.png"
</source>

[[Category: Development]]
[[Category: Parallelization]]

Raster aggregate values

2010-08-26T15:49:18Z

⚠️DylanBeaudette: added some details regarding r.resamp.stats

'''Q:''' How can I calculate the average map values by spatial unit (grid)? For example, I would like to calculate the average slope by square kilometer for a given area.

'''A:''' Procedure outline:

* Make a slope map from the DEM with {{cmd|r.slope.aspect}} at the same resolution and bounds as the DEM. (run 'g.region rast=dem' first)
* Make the grid with {{cmd|v.mkgrid}}, with box=1000,1000 (assuming the location is meters-based)
* Draw a 1 km x 1 km grid ({{cmd|d.grid}}), and overlay the {{cmd|v.mkgrid}} vector map (area fill = none, or only display boundary features, colored red or so) just to verify where it will be and what it will look like.
* Run {{cmd|v.rast.stats}} to calculate stats for each grid box, and upload to that area's attribute table.

'''A:''' Another approach using {{cmd|r.resamp.stats}}:
* Generate a region that defines the required grid topology: extent, cell size, origin
* Zoom to that region, and set the resolution accordingly
* Aggregate slope values within each of the cells defined by this new region using {{cmd|r.resamp.stats}}
* The resulting raster will contain aggregate values of the input raster, using the new grid topology
* Optionally vectorize with {{cmd|r.to.vect}}

[[category: FAQ]]

Image processing

2008-12-13T17:41:58Z

⚠️DylanBeaudette: /* Radiometric preprocessing */

'''''This page needs review and enhancement from an expert! Thanks!'''''

== Introduction ==

Satellite imagery and orthophotos (aerial photographs) are handled in GRASS as raster maps and specialized tasks are performed using the '''imagery''' (i.*) modules. All general operations are handled by the raster modules.

* [http://grass.ibiblio.org/grass63/manuals/html63_user/imageryintro.html A short introduction to image processing] in GRASS 6
* Full [http://grass.ibiblio.org/gdp/imagery/grass4_image_processing.pdf GRASS 4.0 Image Processing manual] (PDF, 47 pages)
* [http://grass.ibiblio.org/grass63/manuals/html63_user/imagery.html Imagery module help pages]

* Data import is generally handled by the [http://grass.ibiblio.org/grass63/manuals/html63_user/r.in.gdal.html r.in.gdal] module

== Screenshots ==

* The [http://grass.ibiblio.org/screenshots/imagery.php imagery screenshots] page

== Importing ==

=== Satellite Data ===

==== Ocean Color ====
* [[MODIS]]
* [[MODIS#SeaWiFS|SeaWiFS]]

==== Sea Surface Temperature (SST) ====

* [[MODIS]]
* [[MODIS#Pathfinder_SST|Pathfinder AVHRR]]

=== Orthophotos ===

* See the i.ortho.photo modules

== Preprocessing ==

=== Geometric preprocessing/Georectification ===

* Tcl/Tk georectification tool is available from the File menu in the GUI.
* i.points, i.vpoints (scanned maps, satellite images)
* i.ortho.photo (aerial images)

A multi-band image may be grouped and georectified with a single set of ground control points. (i.group, i.target, i.rectify)

See also the [[Georeferencing]] wiki page

=== Radiometric preprocessing ===

* use r.mapcalc to apply gain/bias formula
* [[LANDSAT]]: you can also use i.landsat.toar from [[GRASS AddOns]]

=== Correction for atmospheric effects ===

* i.landsat.dehaze: simple dark-object/Tasseled Cap based haze minimization (from [[GRASS AddOns]])
* i.atcorr: more complex correction but based on atmospheric models

=== Correction for topographic/terrain effects ===

In rugged terrain, such correction might be useful to minimize negative effects.

* simple "cosine correction" using r.sunmask, r.mapcalc (tends to overshoot when slopes are high)
* Minnaert or other corrections with i.topo.corr (from [[GRASS AddOns]])

=== Cloud removal ===

* with i.landsat.acca (from [[GRASS AddOns]])

== Image classification ==

'''Classification methods in GRASS'''

{| {{table}}
| ||'''radiometric<BR>unsupervised'''||'''radiometric<BR>supervised 1'''||'''radiometric<BR>supervised 2'''||'''radiometric & geometric<BR>supervised'''
|-
| '''Preprocessing'''||i.cluster||i.class (monitor digitizing)||i.gensig (using training maps)||i.gensigset (using training maps)
|-
| '''Computation'''||i.maxlik||i.maxlik||i.maxlik||i.smap
|}

=== Interactive setup ===

* i.class - Generates spectral signatures for an image by allowing the user to outline regions of interest.
: The resulting signature file can be used as input for i.maxlik or as a seed signature file for i.cluster.

=== Processing ===

* i.cluster - Generates spectral signatures for land cover types in an image using a clustering algorithm.
: The resulting signature file is used as input for i.maxlik, to generate an unsupervised image classification.
* i.gensig - Generates statistics for i.maxlik from raster map layer.
* i.gensigset - Generate statistics for i.smap from raster map layer.

=== Unsupervised classification ===

* i.maxlik - Classifies the cell spectral reflectances in imagery data.
: Classification is based on the spectral signature information generated by either i.cluster, i.class, or i.gensig.

=== Supervised classification ===

* i.smap - Performs contextual (image segmentation) image classification using sequential maximum a posteriori (SMAP) estimation.

== Filtering ==

* i.fft, i.ifft, i.pca, r.mfilter, r.neighbors

== Enhancement ==

* i.landsat.rgb
* i.fusion.brovey
* i.oif

== Stereo anaglyphs ==

* see [[Stereo anaglyphs]]

== Ideas collection for improving GRASS' Image processing capabilities ==

Below modules need some tuning before being added to GRASS 6. Volunteers welcome.

=== Spectral unmixing ===

* [http://mpa.itc.it/markus/spectral_unmixing/ i.spec.unmix] (source code)

=== Spectral angle mapping ===

* [http://mpa.itc.it/markus/spectral_unmixing/ i.spec.sam] (source code)

=== Geocoding ===

* [http://trac.osgeo.org/grass/browser/grass-addons/imagery i.points.auto]: automated search of GCPs based on FFT correlation (as improved i.points)
* [http://trac.osgeo.org/grass/browser/grass-addons/imagery i.homography]: geocoding with lines (instead of points) with homography (as improved i.points; it was formerly called i.linespoints)
* support splines from GDAL (see [[GRASS_AddOns#Imagery_add-ons]])

=== Image classification ===

* [http://mpa.itc.it/merler/index.html#ml pr: C code for classification problems]
* GRASS implementation: i.pr.* source code is available [http://trac.osgeo.org/grass/browser/grass-addons/imagery here])

=== Stereo ===

This is stand-alone stereo modeling software (DEM extraction etc). Waits for integration into GRASS.
* http://grass.itc.it/outgoing/grass5/stereo-0.2b.tar.gz
* [http://grass.osgeo.org/gdp/stereo-grass/index.html Stereo Tutorial]

=== Lidar LAS format ===

LAS Tools by M. Isenburg: http://www.cs.unc.edu/~isenburg/lastools/

las2txt | r.in.xyz in=- fs=" "

(see [http://grass.osgeo.org/grass63/manuals/html63_user/r.in.xyz.html r.in.xyz])

=== Improving the existing code ===

It might be sensible to merge the various image libraries:

* GRASS 6 standard libs:
** lib/imagery/: standard lib, in use (i.* except for i.points3, i.rectify3)
** imagery/i.ortho.photo/libes/: standard lib, in use (i.ortho.photo, photo.*)
* GRASS 5 (! only) image3 lib:
** lib/image3/: never finished improvement which integrated the standard lib and the ortho lib. Seems to provide also ortho rectification for satellite data (i.points3, i.rectify3)
* GRASS 5/6 image proc commands:
** merge of i.points, i.vpoints, i.points3
** merge of i.rectify and i.rectify3
** addition of new resampling algorithms such as bilinear, cubic convolution (take from r.proj or upcoming r.resamp.aggreg)
** add other warping methods (maybe thin splines from GDAL?)
** implement/finish linewise ortho-rectification of satellite data

[[Category:Development]]

GIS Concepts

2008-12-13T17:40:03Z

⚠️DylanBeaudette: /* Imagery Data */

== Geodesy and Cartography ==
=== Background material ===

* [http://oceanservice.noaa.gov/education/kits/geodesy/welcome.html An introduction to Geodesy] from NOAA
* [http://en.wikipedia.org/wiki/Geodesy Wikipedia's Geodesy entry]
* [http://en.wikipedia.org/wiki/GIS Wikipedia's GIS entry]
* [http://www.nga.mil/portal/site/maritime/ Bowditch's American Practical Navigator] - (especially chapter 2)
* [http://earth-info.nima.mil/GandG/publications/ NGA Geodesy and Geophysics publications]
* [http://www.ordnancesurvey.co.uk/oswebsite/gps/information/coordinatesystemsinfo/guidecontents/index.html UK Ordnance Survey primer on coordinate system concepts] ([http://www.ordnancesurvey.co.uk/gps/docs/A_Guide_to_Coordinate_Systems_in_Great_Britain.pdf PDF])

=== Map projections ===

* [http://www.asprs.org/resources/grids/ ASPRS Grids and Datums]: detailed descriptions of national projections
* [http://www.mapref.org/ MapRef] - The Collection of Map Projections and Reference Systems for Europe
* [http://www.remotesensing.org/geotiff/proj_list/ Projections Transform Lists] (PROJ4)
* [http://www.dmap.co.uk/utmworld.htm UTM Zones]

EPSG:
* [http://www.epsg.org EPSG projection codes]
: [http://www.epsg-registry.org/ EPSG database search]
: [http://spatialreference.org/ Spatialreference community portal]

Projection galleries:
* [http://www.progonos.com/furuti/MapProj/CartIndex/cartIndex.html Map projection concepts] by Carlos Furuti
* [http://www.csiss.org/map-projections/index.html Map projection gallery] by Paul Anderson ([http://www.galleryofmapprojections.com/ old link])


=== Map datums ===

An extra calculation is needed when re-projecting maps and data between
two different co-ordinate systems (in addition to the re-projection) if
the two co-ordinate systems are based on different models of the
curvature of the earth. E.g. OSGB36 uses the Airy ellipsoid and WGS84 uses the WGS84 ellipsoid, which have slightly different sizes and shapes. The error is not large - generally a few hundred metres at most on the ground.
The datum transformation parameters describe this adjustment
mathematically.

As the transformation between any two datums is approximate and varies by location, different sets of parameters are often offered to give improved accuracy in different regions of a country. In general there is no one "correct" set of transformation parameters - indeed the accuracy changes over time due to tectonic movements in the Earth.

* [http://sourceforge.net/mailarchive/forum.php?thread_name=1190060064.27461.57.camel%40blackpad&forum_name=jump-pilot-devel A brief history of map datums] for the layman
* [http://www.colorado.edu/geography/gcraft/notes/datum/datum.html An introduction to geodetic datums] by Peter Dana
* [http://home.online.no/~sigurdhu/WGS84_Eng.html How WGS 84 defines the Earth]
* A discussion of [http://www.linz.govt.nz/geodetic/conversion-coordinates/geodetic-datum-conversion/nzgd1949-nzgd2000/index.aspx 3-term, 7-term, and NTv2 grid datum transformations] by Land Information New Zealand
: (besides the web page have a look at the PDF fact sheet and guide linked therein)


==How GRASS deals with geodetics==

As far as GRASS is concerned, an ellipsoid and a spheroid are the same thing, and ellipsoid is the prefered name.

As far as GRASS is concerned, a datum is made up of an ellipsoid and an origin.
Setting a datum is optional, but highly recommended.

GRASS uses a modified version of the [http://proj.maptools.org PROJ.4] library.

=== Modules controling a location's map projection ===
* [http://grass.osgeo.org/grass64/manuals/html64_user/g.proj.html g.proj] help page
* [http://grass.osgeo.org/grass64/manuals/html64_user/g.setproj.html g.setproj] help page

=== Modules for reprojecting GIS maps and data ===

* [http://grass.osgeo.org/grass64/manuals/html64_user/r.proj.html r.proj] for reprojecting raster maps
* [http://grass.osgeo.org/grass64/manuals/html64_user/v.proj.html v.proj] for reprojecting vector maps
* [http://grass.osgeo.org/grass64/manuals/html64_user/m.proj.html m.proj] for reprojecting a list of coordinate pairs

=== Modules for georectifying images ===

* [http://grass.osgeo.org/grass64/manuals/html64_user/r.region.html r.region] for resetting a raster map's bounds information
* gis.m GIS manager GeoReferencing tool (File menu)
* [http://grass.osgeo.org/grass64/manuals/html64_user/i.points.html i.points] and [http://grass.osgeo.org/grass64/manuals/html64_user/i.vpoints.html i.vpoints] for setting GCPs
* [http://grass.osgeo.org/grass64/manuals/html64_user/i.rectify.html i.rectify] for georectifying imagery
* [http://www.gdal.org GDALwarp] (use with gdal_translate, see the i.warp script in the wiki [[GRASS_AddOns#Imagery_add-ons|AddOns]] page)

;[[Georeferencing]]

==GIS Data types==

===Raster Data===

Data which occurs in a regularly spaced grid. e.g. a satellite image or digital terrain map.<BR>
Region settings determine the spatial extent and resolution of the grid.

;[http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html Raster Intro]
[[Replacement raster format]]

[[GRASS Raster Mask]]

[[GRASS raster semantics]]

===3D Raster Data (Voxel)===

A stack of 2D raster maps.

;[http://grass.osgeo.org/grass64/manuals/html64_user/raster3dintro.html Raster 3D Intro]

===Vector Data===

Data which occurs as a series of coordinates. e.g. a GPS position or coastline map. May be a point, line, area, etc in either 2D or 3D space. Generally independent of region settings.

;[http://grass.osgeo.org/grass64/manuals/html64_user/vectorintro.html Vector Intro]
[[Vectordata]]

=== Imagery Data ===
Pixelated photographic or satellite images, often imported from a
[http://en.wikipedia.org/wiki/GeoTIFF GeoTIFF] or PNG image file.

As far as the GIS is concerned this is just another raster map, but there are several modules specially tailored for rectification and processing common imagery types. e.g. ortho-photos or multi-channel [[LANDSAT]] data.

* [http://grass.osgeo.org/grass64/manuals/html64_user/imageryintro.html GRASS Imagery module introduction]

* The GRASS [[Image processing]] wiki page

===Site Data===
Old versions of GRASS (5 and earlier) treated point data separate to line and polygon data. GRASS 6 classes all vector data features the same. Convert old sites file data into GRASS 6 vector format with the GRASS 6 [http://grass.osgeo.org/grass64/manuals/html64_user/v.in.sites.html v.in.sites] or
[http://grass.osgeo.org/grass64/manuals/html64_user/v.in.sites.all.html v.in.sites.all] modules.

==Conversions between data types==

The following table is intended to catalog transformations from one type of data to another:<BR>
''[table is currently incomplete!]''

{| border="1"
| From / To
![http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html Raster]
![http://grass.osgeo.org/grass64/manuals/html64_user/raster3dintro.html 3D Raster]
![http://grass.osgeo.org/grass64/manuals/html64_user/vectorintro.html Vector]
|-
! Raster
| r.mapcalc
| r.to.rast3
| r.to.vect, v.sample, r.volume
|-
! 3D Raster
| r3.to.rast, r3.cross.rast
| r3.mapcalc
|
|-
! Vector
| v.to.rast, v.surf.rst, v.surf.idw
| v.vol.rst, v.vol.idw, v.to.rast3
| v.clean
|-
! Data
| r.in.*
| r3.in.*
| v.in.*
|}

==How a GRASS project is organized==

GRASS data is stored in a three level structure, the database, location and mapset. These can be found in a series of nested directories on the user's computer. All three must exist and are set at GRASS startup time.

===The Database===

The directory in which all GIS data is to be stored.

e.g. <tt>~/grassdata/</tt>

===The Location===

A ''location'' is a GRASS project consisting of an area, projection definition (or unprojected), a grouping of mapsets, all with the same projection settings. A location is a subdirectory of the GRASS ''database''.

e.g. world_lat_lon, utm_zone_59, or west_coast

A ''location'' contains one or many ''mapsets''.

===The Mapset===

A ''mapset'' contains map(s), it is a subdirectory of a ''location''.
Conceptually, if several mapsets are used in a location, they may be assigned to different users (each has one or several own mapsets to work in and cannot modify thos of other users), and/or it they are used to organize a project (''location'') by subareas or subprojects.
There are no specific organizational limitations.

There is always a PERMANENT mapset which is readable from all other mapsets within the same location. Read access to maps in other mapsets is managed with the 'g.mapsets' command or by adding the "@" symbol and mapset name (e.g. <tt>map@othermapset</tt>).

==Raster GIS Analysis==

===Simple Raster Math===

Sometimes when analyzing the relationship between two or more raster data sets, a relatively simple mathematical approach is best. One example using the {{cmd|r.mapcalc}} tool would be to look at changes between two raster data sets. By subtracting the values in these two data sets you can assume that resulting cells with a positive value have a positive change and those with a negative value have negative change. If the cell values have a zero value then there would be no change.

GRASS comes bundled with the {{cmd|r.mapcalc}} command line tool as well as a GUI interface for the tool accessible using the {{cmd|r.mapcalculator}} command. This GUI allows the user to easily assign raster maps to the variables used in the formulas and easily create mathematical strings that will result in a new raster data set containing the results.

[[Category:Development]]
[[Category:Community]]

LANDSAT

2008-12-13T17:37:45Z

⚠️DylanBeaudette: started page focused on LANDSAT data

=LANDSAT Pre-Processing=
Some notes from Yann Chemin:
1. on opening GRASS GIS, select create location from georeferenced file
2. use r.in.gdal to import in GRASS GIS.
3. in grass/add-ons look for any of these to correct from radiance to reflectance at top of atmosphere
* raster/i.landsat.toar
* gipe/i.dn2full.l5
* gipe/i.dn2full.l7

4. use i.atcorr too correct top of atmosphere to surface reflectance.

GRASS raster semantics

2008-09-05T00:33:04Z

⚠️DylanBeaudette: /* Raster to Vector Conversions */

A quick summary c/o Glynn Clements:

==Region Calculations==

Well, the region isn't limited to raster data; it may also affect some
vector operations.

The region's bounds describe a rectangle in two-dimensional space. For
raster operations, this rectangle is subdivided into a grid of
rectangular cells, so the region's bounds are aligned with the edges
of the outermost cells.

==Cell Locations==

Cells are areas, not points, so they don't have locations. Their
corners have locations, as do their centres.

A cell with array indices (i,j) (easting, northing) corresponds to the
rectangle:

{ (x,y) : west + i * ewres <= x < west + (i+1) * ewres,
north - (j+1) * nsres <= y < north - j * nsres }

whose centre is at:

(west + (i+1/2) * ewres, north - (j+1/2) * nsres)

[Subject to wrapping of longitude values in lat/lon locations.]

==Raster to Vector Conversions==

IIRC, {{cmd|r.to.vect}} uses the midpoints of the cell's edges (i.e. one
coordinate will be on a grid line, the other will be mid-way between
grid lines).

==Resampling==

The built-in nearest-neighbour resampling of raster data calculates
the centre of each region cell, and takes the value of the raster cell
in which that point falls.

If the point falls exactly upon a grid line, the exact result will be
determined by the direction of any rounding error.

[One consequence of this is that downsampling by a factor which is an
even integer will always sample exactly on the boundary between cells,
meaning that the result is ill-defined.]

{{cmd|r.resample}} uses the built-in resampling, so it should produce
identical results.

{{cmd|r.resamp.interp}} method=nearest uses the same algorithm, but not the
same code, so it may not produce identical results in cases which are
decided by the rounding of floating-point numbers.

For method=bilinear and method=bicubic, the raster values are treated
as samples at each raster cell's centre, defining a piecewise-
continuous surface. The resulting raster values are obtained by
sampling the surface at each region cell's centre.

As the algorithm only interpolates, and doesn't extrapolate, a margin
of 0.5 (for bilinear) or 1.5 (for bicubic) cells is lost from the
extent of the original raster. Any samples taken within this margin
will be null.

AFAIK, {{cmd|r.resamp.rst}} behaves similarly, i.e. it computes a surface
assuming that the values are samples at each raster cell's centre, and
samples the surface at each region cell's centre.

For {{cmd|r.resamp.stats}} without -w, the value of each region cell is the
chosen aggregate of the values from all of the raster cells whose
centres fall within the bounds of the region cell.

With -w, the samples are weighted according to the proportion of the
raster cell which falls within the bounds of the region cell, so the
result is normally[1] unaffected by rounding error (a miniscule
difference in the position of the boundary results in the addition or
subtraction of a sample weighted by a miniscule factor).

[1] The min and max aggregates can't use weights, so -w has no effect
for those.

==General Rules==

For the most part, the interpretation is the "obvious" one, given:

1. Cells are areas rather than points.
2. Operations which need a point (e.g. interpolation) use the cell's
centre.

==Developer Notes Rules==
From a programming perspective, the functions:

G_row_to_northing()
G_col_to_easting()
G_northing_to_row()
G_easting_to_col()

all transform floating-point values.

Passing integer row or column indices to the first two functions will
return the coordinates of the cell's top-left corner; for the centre
coordinates, pass row+0.5 and/or col+0.5.

Similarly, the last two functions will typically return non-integral
values; use floor() to discard the fractional part and obtain the row
or column index of the cell within which the point lies.

GRASS raster semantics

2008-09-05T00:32:03Z

⚠️DylanBeaudette: /* Resampling */

A quick summary c/o Glynn Clements:

==Region Calculations==

Well, the region isn't limited to raster data; it may also affect some
vector operations.

The region's bounds describe a rectangle in two-dimensional space. For
raster operations, this rectangle is subdivided into a grid of
rectangular cells, so the region's bounds are aligned with the edges
of the outermost cells.

==Cell Locations==

Cells are areas, not points, so they don't have locations. Their
corners have locations, as do their centres.

A cell with array indices (i,j) (easting, northing) corresponds to the
rectangle:

{ (x,y) : west + i * ewres <= x < west + (i+1) * ewres,
north - (j+1) * nsres <= y < north - j * nsres }

whose centre is at:

(west + (i+1/2) * ewres, north - (j+1/2) * nsres)

[Subject to wrapping of longitude values in lat/lon locations.]

==Raster to Vector Conversions==

IIRC, r.to.vect uses the midpoints of the cell's edges (i.e. one
coordinate will be on a grid line, the other will be mid-way between
grid lines).

==Resampling==

The built-in nearest-neighbour resampling of raster data calculates
the centre of each region cell, and takes the value of the raster cell
in which that point falls.

If the point falls exactly upon a grid line, the exact result will be
determined by the direction of any rounding error.

[One consequence of this is that downsampling by a factor which is an
even integer will always sample exactly on the boundary between cells,
meaning that the result is ill-defined.]

{{cmd|r.resample}} uses the built-in resampling, so it should produce
identical results.

{{cmd|r.resamp.interp}} method=nearest uses the same algorithm, but not the
same code, so it may not produce identical results in cases which are
decided by the rounding of floating-point numbers.

For method=bilinear and method=bicubic, the raster values are treated
as samples at each raster cell's centre, defining a piecewise-
continuous surface. The resulting raster values are obtained by
sampling the surface at each region cell's centre.

As the algorithm only interpolates, and doesn't extrapolate, a margin
of 0.5 (for bilinear) or 1.5 (for bicubic) cells is lost from the
extent of the original raster. Any samples taken within this margin
will be null.

AFAIK, {{cmd|r.resamp.rst}} behaves similarly, i.e. it computes a surface
assuming that the values are samples at each raster cell's centre, and
samples the surface at each region cell's centre.

For {{cmd|r.resamp.stats}} without -w, the value of each region cell is the
chosen aggregate of the values from all of the raster cells whose
centres fall within the bounds of the region cell.

With -w, the samples are weighted according to the proportion of the
raster cell which falls within the bounds of the region cell, so the
result is normally[1] unaffected by rounding error (a miniscule
difference in the position of the boundary results in the addition or
subtraction of a sample weighted by a miniscule factor).

[1] The min and max aggregates can't use weights, so -w has no effect
for those.

==General Rules==

For the most part, the interpretation is the "obvious" one, given:

1. Cells are areas rather than points.
2. Operations which need a point (e.g. interpolation) use the cell's
centre.

==Developer Notes Rules==
From a programming perspective, the functions:

G_row_to_northing()
G_col_to_easting()
G_northing_to_row()
G_easting_to_col()

all transform floating-point values.

Passing integer row or column indices to the first two functions will
return the coordinates of the cell's top-left corner; for the centre
coordinates, pass row+0.5 and/or col+0.5.

Similarly, the last two functions will typically return non-integral
values; use floor() to discard the fractional part and obtain the row
or column index of the cell within which the point lies.

GRASS raster semantics

2008-09-04T15:45:20Z

⚠️DylanBeaudette: first draft of a page describing how cells/pixels are referenced in GRASS GIS

A quick summary c/o Glynn Clements:

==Region Calculations==

Well, the region isn't limited to raster data; it may also affect some
vector operations.

The region's bounds describe a rectangle in two-dimensional space. For
raster operations, this rectangle is subdivided into a grid of
rectangular cells, so the region's bounds are aligned with the edges
of the outermost cells.

==Cell Locations==

Cells are areas, not points, so they don't have locations. Their
corners have locations, as do their centres.

A cell with array indices (i,j) (easting, northing) corresponds to the
rectangle:

{ (x,y) : west + i * ewres <= x < west + (i+1) * ewres,
north - (j+1) * nsres <= y < north - j * nsres }

whose centre is at:

(west + (i+1/2) * ewres, north - (j+1/2) * nsres)

[Subject to wrapping of longitude values in lat/lon locations.]

==Raster to Vector Conversions==

IIRC, r.to.vect uses the midpoints of the cell's edges (i.e. one
coordinate will be on a grid line, the other will be mid-way between
grid lines).

==Resampling==

The built-in nearest-neighbour resampling of raster data calculates
the centre of each region cell, and takes the value of the raster cell
in which that point falls.

If the point falls exactly upon a grid line, the exact result will be
determined by the direction of any rounding error.

[One consequence of this is that downsampling by a factor which is an
even integer will always sample exactly on the boundary between cells,
meaning that the result is ill-defined.]

'''r.resample''' uses the built-in resampling, so it should produce
identical results.

'''r.resamp.interp''' method=nearest uses the same algorithm, but not the
same code, so it may not produce identical results in cases which are
decided by the rounding of floating-point numbers.

For method=bilinear and method=bicubic, the raster values are treated
as samples at each raster cell's centre, defining a piecewise-
continuous surface. The resulting raster values are obtained by
sampling the surface at each region cell's centre.

As the algorithm only interpolates, and doesn't extrapolate, a margin
of 0.5 (for bilinear) or 1.5 (for bicubic) cells is lost from the
extent of the original raster. Any samples taken within this margin
will be null.

AFAIK, '''r.resamp.rst''' behaves similarly, i.e. it computes a surface
assuming that the values are samples at each raster cell's centre, and
samples the surface at each region cell's centre.

For '''r.resamp.stats''' without -w, the value of each region cell is the
chosen aggregate of the values from all of the raster cells whose
centres fall within the bounds of the region cell.

With -w, the samples are weighted according to the proportion of the
raster cell which falls within the bounds of the region cell, so the
result is normally[1] unaffected by rounding error (a miniscule
difference in the position of the boundary results in the addition or
subtraction of a sample weighted by a miniscule factor).

[1] The min and max aggregates can't use weights, so -w has no effect
for those.

==General Rules==

For the most part, the interpretation is the "obvious" one, given:

1. Cells are areas rather than points.
2. Operations which need a point (e.g. interpolation) use the cell's
centre.

==Developer Notes Rules==
From a programming perspective, the functions:

G_row_to_northing()
G_col_to_easting()
G_northing_to_row()
G_easting_to_col()

all transform floating-point values.

Passing integer row or column indices to the first two functions will
return the coordinates of the cell's top-left corner; for the centre
coordinates, pass row+0.5 and/or col+0.5.

Similarly, the last two functions will typically return non-integral
values; use floor() to discard the fractional part and obtain the row
or column index of the cell within which the point lies.

GIS Concepts

2008-09-04T15:41:58Z

⚠️DylanBeaudette: /* Raster Data */

== Geodesy and Cartography ==
=== Background material ===

* [http://oceanservice.noaa.gov/education/kits/geodesy/welcome.html An introduction to Geodesy] from NOAA
* [http://en.wikipedia.org/wiki/Geodesy Wikipedia's Geodesy entry]
* [http://en.wikipedia.org/wiki/GIS Wikipedia's GIS entry]
* [http://earth-info.nima.mil/GandG/publications/ NGA Geodesy and Geophysics publications]
* [http://www.ordnancesurvey.co.uk/oswebsite/gps/information/coordinatesystemsinfo/guidecontents/index.html UK Ordnance Survey primer on coordinate system concepts] ([http://www.ordnancesurvey.co.uk/gps/docs/A_Guide_to_Coordinate_Systems_in_Great_Britain.pdf PDF])

=== Map projections ===

* [http://www.asprs.org/resources/grids/ ASPRS Grids and Datums]: detailed descriptions of national projections
* [http://www.mapref.org/ MapRef] - The Collection of Map Projections and Reference Systems for Europe
* [http://www.remotesensing.org/geotiff/proj_list/ Projections Transform Lists] (PROJ4)
* [http://www.dmap.co.uk/utmworld.htm UTM Zones]

EPSG:
* [http://www.epsg.org EPSG projection codes]
: [http://www.epsg-registry.org/ EPSG database search]
: [http://spatialreference.org/ Spatialreference community portal]

Projection galleries:
* [http://www.progonos.com/furuti/MapProj/CartIndex/cartIndex.html Map projection concepts] by Carlos Furuti
* [http://www.galleryofmapprojections.com Map projection gallery] by Paul Anderson

=== Map datums ===

* [http://www.colorado.edu/geography/gcraft/notes/datum/datum.html An introduction to geodetic datums] by Peter Dana
* [http://home.online.no/~sigurdhu/WGS84_Eng.html How WGS 84 defines the Earth]
* A discussion of [http://www.linz.govt.nz/core/surveysystem/geodeticinfo/conversions/datums/nzgd1949-nzgd2000/index.html 3-term, 7-term, and NTv2 grid datum transformations] by Land Information New Zealand
: (besides the web page have a look at the PDF fact sheet and guide linked therein)


==How GRASS deals with geodetics==

As far as GRASS is concerned, an ellipsoid and a spheroid are the same thing, and ellipsoid is the prefered name.

As far as GRASS is concerned, a datum is made up of an ellipsoid and an origin.
Setting a datum is optional, but highly recommended.

GRASS uses a modified version of the [http://proj.maptools.org PROJ.4] library.

=== Modules controling a location's map projection ===
* [http://grass.osgeo.org/grass64/manuals/html64_user/g.proj.html g.proj] help page
* [http://grass.osgeo.org/grass64/manuals/html64_user/g.setproj.html g.setproj] help page

=== Modules for reprojecting GIS maps and data ===

* [http://grass.osgeo.org/grass64/manuals/html64_user/r.proj.html r.proj] for reprojecting raster maps
* [http://grass.osgeo.org/grass64/manuals/html64_user/v.proj.html v.proj] for reprojecting vector maps
* [http://grass.osgeo.org/grass64/manuals/html64_user/m.proj.html m.proj] for reprojecting a list of coordinate pairs

=== Modules for georectifying images ===

* [http://grass.osgeo.org/grass64/manuals/html64_user/r.region.html r.region] for resetting a raster map's bounds information
* gis.m GIS manager GeoReferencing tool (File menu)
* [http://grass.osgeo.org/grass64/manuals/html64_user/i.points.html i.points] and [http://grass.osgeo.org/grass64/manuals/html64_user/i.vpoints.html i.vpoints] for setting GCPs
* [http://grass.osgeo.org/grass64/manuals/html64_user/i.rectify.html i.rectify] for georectifying imagery
* [http://www.gdal.org GDALwarp] (use with gdal_translate, see the i.warp script in the wiki [[GRASS_AddOns#Imagery_add-ons|AddOns]] page)

;[[Georeferencing]]

==GIS Data types==

===Raster Data===

Data which occurs in a regularly spaced grid. e.g. a satellite image or digital terrain map.<BR>
Region settings determine the spatial extent and resolution of the grid.

;[http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html Raster Intro]
[[Replacement_raster_format]]
[[GRASS_Raster_Mask]]

[[GRASS_pixel_rules]]

===3D Raster Data (Voxel)===

A stack of 2D raster maps.

;[http://grass.osgeo.org/grass64/manuals/html64_user/raster3dintro.html Raster 3D Intro]

===Vector Data===

Data which occurs as a series of coordinates. e.g. a GPS position or coastline map. May be a point, line, area, etc in either 2D or 3D space. Generally independent of region settings.

;[http://grass.osgeo.org/grass64/manuals/html64_user/vectorintro.html Vector Intro]
[[Vectordata]]

=== Imagery Data ===
Pixelated photographic or satellite images, often imported from a
[http://en.wikipedia.org/wiki/GeoTIFF GeoTIFF] or PNG image file.

As far as the GIS is concerned this is just another raster map, but there are several modules specially tailored for rectification and processing common imagery types. e.g. ortho-photos or multi-channel LANDSAT data.

* [http://grass.osgeo.org/grass64/manuals/html64_user/imageryintro.html GRASS Imagery module introduction]

* The GRASS [[Image processing]] wiki page

===Site Data===
Old versions of GRASS (5 and earlier) treated point data separate to line and polygon data. GRASS 6 classes all vector data features the same. Convert old sites file data into GRASS 6 vector format with the GRASS 6 [http://grass.osgeo.org/grass64/manuals/html64_user/v.in.sites.html v.in.sites] or
[http://grass.osgeo.org/grass64/manuals/html64_user/v.in.sites.all.html v.in.sites.all] modules.

==Conversions between data types==

The following table is intended to catalog transformations from one type of data to another:<BR>
''[table is currently incomplete!]''

{| border="1"
| From / To
![http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html Raster]
![http://grass.osgeo.org/grass64/manuals/html64_user/raster3dintro.html 3D Raster]
![http://grass.osgeo.org/grass64/manuals/html64_user/vectorintro.html Vector]
|-
! Raster
| r.mapcalc
| r.to.rast3
| r.to.vect, v.sample, r.volume
|-
! 3D Raster
| r3.to.rast, r3.cross.rast
| r3.mapcalc
|
|-
! Vector
| v.to.rast, v.surf.rst, v.surf.idw
| v.vol.rst, v.vol.idw, v.to.rast3
| v.clean
|-
! Data
| r.in.*
| r3.in.*
| v.in.*
|}

==How a GRASS project is organized==

GRASS data is stored in a three level structure, the database, location and mapset. These can be found in a series of nested directories on the user's computer. All three must exist and are set at GRASS startup time.

===The Database===

The directory in which all GIS data is to be stored.

e.g. <tt>~/grassdata/</tt>

===The Location===

A ''location'' is a GRASS project consisting of an area, projection definition (or unprojected), a grouping of mapsets, all with the same projection settings. A location is a subdirectory of the GRASS ''database''.

e.g. world_lat_lon, utm_zone_59, or west_coast

A ''location'' contains one or many ''mapsets''.

===The Mapset===

A ''mapset'' contains map(s), it is a subdirectory of a ''location''.
Conceptually, if several mapsets are used in a location, they may be assigned to different users (each has one or several own mapsets to work in and cannot modify thos of other users), and/or it they are used to organize a project (''location'') by subareas or subprojects.
There are no specific organizational limitations.

There is always a PERMANENT mapset which is readable from all other mapsets within the same location. Read access to maps in other mapsets is managed with the 'g.mapsets' command or by adding the "@" symbol and mapset name (e.g. <tt>map@othermapset</tt>).

==How the Open Source software development model works==

GRASS differs from many other GIS software packages used in the professional world in that it is developed and distributed by users for users; mostly on a volunteer basis, in the open, and is given away for free.

Emphasis is placed on interoperability and unlimited access to data as well as software flexibility and evolution rate (both added features and bug minimization).

''Free'' can have many meanings, as the links below illustrate, and within a project there is often a spectrum of philosophies and goals amongst developers. But it works - Free Software has revolutionized many sectors of the computing world over the last few years and continues to do so today.

* [http://www.gnu.org/philosophy/philosophy.html Philosophy of the Free Software Movement]
* [http://www.opensource.org The Open Source Initiative has a good explanation]
* [http://www.fsf.org The Free Software Foundation]
* [http://www.gnu.org/copyleft/gpl.html The GNU General Public License]

==Raster GIS Analysis==

===Simple Raster Math===

Sometimes when analyzing the relationship between two or more raster data sets, a relatively simple mathematical approach is best. One example using the r.mapcalc tool would be to look at changes between two raster data sets. By subtracting the values in these two data sets you can assume that resulting cells with a positive value have a possitive change and those with a negative value have negative change. If the cell values have a zero value then there would be no change.

GRASS comes bundled with the r.mapcalc tool as well as the d.m GUI interface for the tool accessable using the r.mapcalculator command. This GUI allows the user to easily assign raster sets to the variables used in the formulas and easily create mathematical strings that will result in a new raster data set containing the results.

[[Category:Development]]
[[Category:Community]]

Soil Science

2008-05-20T15:39:11Z

⚠️DylanBeaudette: New page: ''this page is a work in progress'' == Tools for soil scientists == === Terrain Analysis === === Climatic Surfaces === === Microclimate Decomposition ===

''this page is a work in progress''

== Tools for soil scientists ==

=== Terrain Analysis ===

=== Climatic Surfaces ===

=== Microclimate Decomposition ===

Applications

2008-05-20T15:37:01Z

⚠️DylanBeaudette:

Many people are doing many things with GRASS.

It is encouraged that interested parties add contacts, tips, scripts, references, and partake in general discussion on the following free-form pages. Click on a subject and start editing, or add a new interest group! Anyone can contribute to the wiki pages, just register yourself an account.

* [[Archeology]]
* [[Environmental Protection and Monitoring]]
* [[Geology]]
* [[Hydrologic Sciences]] - including ice cover
* [[Marine Science]]
* [[Meteorology]]
* [[Natural Hazards]]
* [[Public Health]]
* [[Search and Rescue]]
* [[Soil Science]]
* [[Wildlife Zoology]]
* ''Add your interest here ...''

GRASS 7 ideas collection

2008-04-19T18:29:20Z

⚠️DylanBeaudette: /* User Wishes */

{{MoveToTrac}}
== Maintenance of repository ==

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

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

== Raster ==

See also [[Replacement raster format]]

=== Library ===
* allowing nulls to be embedded
* Split libgis into G_() part and Rast_() part
* Rewrite library from scratch. See [http://grass.itc.it/pipermail/grass-dev/2006-August/025025.html suggestions]
* Insert 'vertical' 2d rasters (e.g. [http://woodshole.er.usgs.gov/project-pages/longislandsound/images/Ghist_square2.jpg geophysical survey data])
* [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]

=== Modules ===

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

==== remove ====
* Remove r.bitpattern since r.mapcalc does it more nicely now
* Remove r.in.arc and r.out.arc, '''if''' a [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.

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

* remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [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

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

==== Merge ====

* merge '''r.surf.idw''' and '''r.surf.idw2'''
: while r.surf.idw will only output CELL maps, it is Very Fast.

* r.sum, r.mode, r.median, r.average, r.statistics, r.univar, r.univar2 - maybe they can be reduced to just r.statistics and r.univar? See [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]

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

* r.in.wms and r.in.srtm into r.in.gdal thanks to native support for [http://www.gdal.org/frmt_wms.html WMS] and [http://www.gdal.org/frmt_various.html#SRTMHGT SRTM] in GDAL 1.5
* '''r.buffer''' and '''r.grow'''

==== 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)

== 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

=== 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
* rename v.out.ogr to v.export
* rename v.mkgrid to v.grid
* 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 v.sample and v.what.rast
: See a feature request [http://wald.intevation.org/tracker/index.php?func=detail&aid=506&group_id=21&atid=188 #506] in GForge.

==== 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 ??)
* 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)
* Rewrite vector labeling. Needs more placement control options (may be db field value based), label overlaping prevention would be also good. May be we could borrow some ideas from MapServer? (ongoing: v.label.sa)
* v.what.vect - rename parameters "vector" to "map", "qvector" to "qmap"
* v.type - change type= option to from= and to=.(code's already in there)

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

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* <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
** Support '''vector's 3rd''' dimension in '''g.region vect= [-a]''', '''[res=]''', like the 2d extents are (or should be).

== Database ==
=== Library ===

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

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

== Imagery ==
=== Library ===

Do merge of image libraries:

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

=== Modules ===

* merge of i.points, i.vpoints, i.points3
: drop these altogether? (loss of interactive XDRIVER)
* merge of i.rectify and i.rectify3
: maybe depend on gdalwarp C API for this?
* addition of new resampling algorithms such as bilinear, cubic convolution (take from r.proj?)
* add other warping methods (maybe thin splines from GDAL?)
* implement/finish linewise ortho-rectification of satellite data
* Depreciate tape functions in next major revision of GRASS and create a tape module that accomplishes tape access.

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

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

== Display ==

=== New display architecture ===

''Comments from Glynn Clements (from [http://www.nabble.com/Cairo-monitor-driver-tf4620004.html#a13206009 here]):''

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

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

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

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

=== Library ===
* Drop support for interactive xmon modules

=== Modules ===
* d.font etc.
** Huidae Cho merged d.text.freetype and d.text into d.text.new; drop them and rename d.text.new into d.text
** merge d.font and d.font.freetype too
: now done in 6.3?

* d.vect
** consolidate parameter names (attrcol, wcolumn, rgb_column)
: how?

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

* remove d.m

* d.legend, d.barscale, d.text, etc: make at=0,0 origin identical!
: FWIW, I copied the d.legend at= syntax from d.frame --HB

== Postscript ==
=== Modules ===
ps.map
* remove scale parameter
: -> from the command line, not the map instruction
* rename sizecol to sizecolumn (remove the given warning)

See also "New display architecture" comments above.

== Parser ==

* "Add another semantic meaning to the parser system for a type safe enumerated list" (Cedric's words commenting the bug that [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."

== 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?

== Visualization ==

* better support for faces and kernels in libgis
: not really Visualization, but....

== CLI ==

* Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup documents/parameter_proposal.txt]

* 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
* Manageable also from command line via d.* modules
* Facilitating easy development of custom GUI application based on GRASS

* → [[WxPython-based GUI for GRASS]]

== Conceptual changes ==

* File organization in binaries:
** the grass etc dir is a mess... module should maintain arch-deps and arch-indep things in different paths -- <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
** Custom fonts
** r.li and other modules temp. files
** GEM addons installation
** Default path for custom scripts
** Custom symbols and EPS fill patterns
** Custom color maps
** Add here new item

== User Wishes ==

''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[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 ==
* 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

2008-04-19T18:25:26Z

⚠️DylanBeaudette: /* Modules */

{{MoveToTrac}}
== Maintenance of repository ==

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

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

== Raster ==

See also [[Replacement raster format]]

=== Library ===
* allowing nulls to be embedded
* Split libgis into G_() part and Rast_() part
* Rewrite library from scratch. See [http://grass.itc.it/pipermail/grass-dev/2006-August/025025.html suggestions]
* Insert 'vertical' 2d rasters (e.g. [http://woodshole.er.usgs.gov/project-pages/longislandsound/images/Ghist_square2.jpg geophysical survey data])
* [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]

=== Modules ===

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

==== remove ====
* Remove r.bitpattern since r.mapcalc does it more nicely now
* Remove r.in.arc and r.out.arc, '''if''' a [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.

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

* remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [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

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

==== Merge ====

* merge '''r.surf.idw''' and '''r.surf.idw2'''
: while r.surf.idw will only output CELL maps, it is Very Fast.

* r.sum, r.mode, r.median, r.average, r.statistics, r.univar, r.univar2 - maybe they can be reduced to just r.statistics and r.univar? See [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]

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

* r.in.wms and r.in.srtm into r.in.gdal thanks to native support for [http://www.gdal.org/frmt_wms.html WMS] and [http://www.gdal.org/frmt_various.html#SRTMHGT SRTM] in GDAL 1.5
* '''r.buffer''' and '''r.grow'''

==== 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)

== 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

=== 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
* rename v.out.ogr to v.export
* rename v.mkgrid to v.grid
* 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 v.sample and v.what.rast
: See a feature request [http://wald.intevation.org/tracker/index.php?func=detail&aid=506&group_id=21&atid=188 #506] in GForge.

==== 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 ??)
* 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)
* Rewrite vector labeling. Needs more placement control options (may be db field value based), label overlaping prevention would be also good. May be we could borrow some ideas from MapServer? (ongoing: v.label.sa)
* v.what.vect - rename parameters "vector" to "map", "qvector" to "qmap"
* v.type - change type= option to from= and to=.(code's already in there)

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

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* <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
** Support '''vector's 3rd''' dimension in '''g.region vect= [-a]''', '''[res=]''', like the 2d extents are (or should be).

== Database ==
=== Library ===

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

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

== Imagery ==
=== Library ===

Do merge of image libraries:

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

=== Modules ===

* merge of i.points, i.vpoints, i.points3
: drop these altogether? (loss of interactive XDRIVER)
* merge of i.rectify and i.rectify3
: maybe depend on gdalwarp C API for this?
* addition of new resampling algorithms such as bilinear, cubic convolution (take from r.proj?)
* add other warping methods (maybe thin splines from GDAL?)
* implement/finish linewise ortho-rectification of satellite data
* Depreciate tape functions in next major revision of GRASS and create a tape module that accomplishes tape access.

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

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

== Display ==

=== New display architecture ===

''Comments from Glynn Clements (from [http://www.nabble.com/Cairo-monitor-driver-tf4620004.html#a13206009 here]):''

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

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

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

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

=== Library ===
* Drop support for interactive xmon modules

=== Modules ===
* d.font etc.
** Huidae Cho merged d.text.freetype and d.text into d.text.new; drop them and rename d.text.new into d.text
** merge d.font and d.font.freetype too
: now done in 6.3?

* d.vect
** consolidate parameter names (attrcol, wcolumn, rgb_column)
: how?

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

* remove d.m

* d.legend, d.barscale, d.text, etc: make at=0,0 origin identical!
: FWIW, I copied the d.legend at= syntax from d.frame --HB

== Postscript ==
=== Modules ===
ps.map
* remove scale parameter
: -> from the command line, not the map instruction
* rename sizecol to sizecolumn (remove the given warning)

See also "New display architecture" comments above.

== Parser ==

* "Add another semantic meaning to the parser system for a type safe enumerated list" (Cedric's words commenting the bug that [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."

== 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?

== Visualization ==

* better support for faces and kernels in libgis
: not really Visualization, but....

== CLI ==

* Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup documents/parameter_proposal.txt]

* 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
* Manageable also from command line via d.* modules
* Facilitating easy development of custom GUI application based on GRASS

* → [[WxPython-based GUI for GRASS]]

== Conceptual changes ==

* File organization in binaries:
** the grass etc dir is a mess... module should maintain arch-deps and arch-indep things in different paths -- <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
** Custom fonts
** r.li and other modules temp. files
** GEM addons installation
** Default path for custom scripts
** Custom symbols and EPS fill patterns
** Custom color maps
** Add here new item

== User Wishes ==

''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[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

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS Metadata Management

2008-04-19T18:21:04Z

⚠️DylanBeaudette: /* Metadata management ideas for future versions of GRASS */

== Metadata support ==

=== Raster ===
* [http://grass.itc.it/grass63/manuals/html63_user/r.support.html r.support] (r.support history="long text" now functional, it does line wrapping)
* [[Replacement_raster_format#Meta-data_support|Metadata support in GRASS raster library notes]]

=== Vector ===
* [http://mpa.itc.it/markus/grass63progman/Vector_Library.html#head_file_format 'head' file format]
* TODO: tool to edit this head file needed. In the future this may be provided by <code>v.support</code> (which has not yet been written). (Reference: http://grass.itc.it/pipermail/grassuser/2007-February/038323.html)

Comments on a vector map can be added manually by editing <code>$MAPSET/vector/$MAPNAME/hist</code>.

== Metadata management ideas for future versions of GRASS ==

=== Unified XML-based approach for raster/vector/imagery ===
* store relevant metadata in an XML-based format, along with creation/modification history
* a new directory '$maspset/metadata/' could house this information
* would probably require major re-write of the raster/vector history mechanism
* generic reading/writing of XML data (don't we already have this functionality somewhere...)

== Links ==
* [http://www.eurogeographics.org/eng/documents/draftINSPIREMetadataIRv2_20070202.pdf DT Metadata – Draft Implementing Rules for Metadata]

[[Category:Development]]

GRASS 7 ideas collection

2007-12-07T03:39:43Z

⚠️DylanBeaudette: /* merge */

== Maintenance of grass7/ repository ==

Issue: only new code should go into grass7/. How to link into the existing GRASS 6 code?

Solutions:

# link script as used for grass6/ (make mix) -> nuisance
# start new repository from scratch in SVN using migrated CVS repos to maintain history; bulk-reformat the code with "indent"

== Raster ==

See also [[Replacement raster format]]

=== Library ===
* allowing nulls to be embedded
* Split libgis into G_() part and Rast_() part
* Rewrite library from scratch. See [http://grass.itc.it/pipermail/grass-dev/2006-August/025025.html suggestions]
* Insert 'vertical' 2d rasters (e.g. [http://woodshole.er.usgs.gov/project-pages/longislandsound/images/Ghist_square2.jpg geophysical survey data])
* [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]

=== Modules ===

==== rename ====
* rename r.in.gdal to r.import
* rename r.out.gdal to r.export

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

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

* remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [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

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

==== merge ====
* merge '''r.surf.idw''' and '''r.surf.idw2'''
* r.sum, r.mode, r.median, r.average, r.statistics, r.univar, r.univar2 - maybe they can be reduced to just r.statistics and r.univar? See [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]
* r.resamp.rst: merge into r.resamp.interp to make resolution management identical to the other modules
* r.in.wms and r.in.srtm into r.in.gdal thanks to native support for [http://www.gdal.org/frmt_wms.html WMS] and [http://www.gdal.org/frmt_various.html#SRTMHGT SRTM] in GDAL 1.5

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

== 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

=== 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)

=== Modules ===

==== rename ====
* rename v.in.ogr to v.import
* rename v.out.ogr to v.export
* rename v.mkgrid to v.grid
* rename v.univar.sh to v.db.univar ([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 v.sample and v.what.rast
: See a feature request [http://wald.intevation.org/tracker/index.php?func=detail&aid=506&group_id=21&atid=188 #506] in GForge.

==== 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 ??)
* 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)
* Rewrite vector labeling. Needs more placement control options (may be db field value based), label overlaping 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)

== 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

== Database ==
=== Library ===

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

=== Modules ===

== Imagery ==
=== Library ===

Do merge of image libraries:

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

=== Modules ===

* merge of i.points, i.vpoints, i.points3
: drop these altogether? (loss of interactive XDRIVER)
* merge of i.rectify and i.rectify3
: maybe depend on gdalwarp C API for this?
* addition of new resampling algorithms such as bilinear, cubic convolution (take from r.proj?)
* add other warping methods (maybe thin splines from GDAL?)
* implement/finish linewise ortho-rectification of satellite data
* Depreciate tape functions in next major revision of GRASS and create a tape module that accomplishes tape access.

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

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

== Display ==

=== New display architecture ===

''Comments from Glynn Clements (from [http://www.nabble.com/Cairo-monitor-driver-tf4620004.html#a13206009 here]):''

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

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

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

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

=== Library ===
* Drop support for interactive xmon modules

=== Modules ===
* d.font etc.
** Huidae Cho merged d.text.freetype and d.text into d.text.new; drop them and rename d.text.new into d.text
** merge d.font and d.font.freetype too
: now done in 6.3?

* d.vect
** consolidate parameter names (attrcol, wcolumn, rgb_column)
: how?

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

* remove d.m

* d.legend, d.barscale, d.text, etc: make at=0,0 origin identical!
: FWIW, I copied the d.legend at= syntax from d.frame --HB

== Postscript ==
=== Modules ===
ps.map
* remove scale parameter
: -> from the command line, not the map instruction
* rename sizecol to sizecolumn (remove the given warning)

See also "New display architecture" comments above.

== Parser ==

* "Add another semantic meaning to the parser system for a type safe enumerated list" (Cedric's words commenting the bug that [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."

== 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?

== Visualization ==

* better support for faces and kernels in libgis
: not really Visualization, but....

== CLI ==

* Fix the parameters and flags. Make it a concept. See proposal in GRASS 5 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/documents/parameter_proposal.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup documents/parameter_proposal.txt]

* 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
* Manageable also from command line via d.* modules
* Facilitating easy development of custom GUI application based on GRASS

* → [[WxPython-based GUI for GRASS]]

== Conceptual changes ==

* File organization in binaries:
** the grass etc dir is a mess... module should maintain arch-deps and arch-indep things in different paths -- <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
** Custom fonts
** r.li and other modules temp. files
** GEM addons installation
** Default path for custom scripts
** Custom symbols and EPS fill patterns
** Custom color maps
** Add here new item

== User Wishes ==

''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[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 diskussion
* Or use [http://www.llnl.gov/visit/ VisIt software], it should be able to read GRASS maps directly via GDAL

[[Category:Development]]
[[Category:Release Roadmap]]

About GRASS

2006-12-21T21:08:00Z

⚠️DylanBeaudette: /* Soil Science */

This wiki page is initially for organizing the writing of a GRASS entry for the "''Springer Encyclopedia of GIS''", in future this wiki page will contain the article itself.

=== The entry structure ===
The Structure of the entry is given by springer. I received a .tex file which I fill with the text when this text is reviewd by the community (and my wife because she's an english teacher :-)).

=== Inspiration ===

* The Wikipedia entry (GNU Free Documentation License; probably '''do not reuse''' any content)<BR>http://en.wikipedia.org/wiki/GRASS_GIS

=== Issues ===

* Who owns the copyright for the article? Springer? The author(s)?
The Contract says:
The author hereby grants and assigns to Springer- Verlag the sole right to publish, distribute and sell... the contribution and parts thereof...

Springer verlag will take ... either in his own name or in that of the author any necessary steps to protect these rights against infringement by third parties. It will have the copyright notice inserted into all editions of the work according to the provisions of the Universal Copyright Convention and dutifully take care of all formalities in this connections, either in its own name or in that of the author.

* Should the article be wholly original or can it be derived (cut and pasted) from existing GRASS texts (e.g. the GRASS logo; website content)?
I supose we should write something new and shouldn't cut & paste because of the following point.

* If cut&pasted, does that put the existing GRASS website text etc at risk? (let's avoid a Eric Weisstein's MathWorld vs. CRC Press style nightmare [http://mathworld.wolfram.com/about/erics_commentary.html])
see above

* Can we reuse the text? (e.g. publish it here on the wiki or as an article in a future GRASSNews newsletter)
I will ask the people at springer

=== What needs to be done? ===
The original deadline is December 29, but we can submit it by Jan. 8. But I try to finish it until the end of december, because the next abstract deadline for me is in mid of January...

the entry should be 8-12 pages - here is an example:
http://refworks.springer.com/mrw/fileadmin/pdf/GIS/VoronoiEncy

Here is some additional information:
http://refworks.springer.com/geograph/

Here are the templates:
http://refworks.springer.com/geograph/

And here is a list of other entries (as of 2006-11-21)
http://www.carto.net/neumann/temp/gis_encyclopedia_toc.pdf

=== The Entry ===

* screenshots needed? if so, how many?
* no limit, but I think we shouldn't include more than 3
* I would suggest some screenshots with 3d vector and 3d raster

==== Title: ====
GRASS

==== Author ====
Malte Halbey-Martin, Inst. of Geogr. Sciences, Free University Berlin, Germany

''Please put your name here when you have written something''

==== Synonyms ====
Geographic Resources Analysis Support Software, GRASS- GIS
(Geographic Information System)

==== Definition (fewer than 250 words)====
GRASS- GIS (Geographic Resources Analysis Support Software) is a GIS- software for geospatial analyses and modelling which has the capability to manage raster and vectordata. Additionally it supports three dimensional modelling with 3D raster voxel or 3D vector data and contains several image processing modules to manipulate remote sensing data. It comes along with visualization tools and interacts with other related software packages e. g. R- language, gstat and Quantum GIS. GRASS supports a variety of GIS formats due to the usage of the GDAL/OGR library. It also supports the OGC- conformal Simple Features.It can connect to databases via ODBC and supports spatial databases like PostGIS. GRASS datasets can be published on the internet with the UMN Mapserver.

The software is published under the conditions of the GNU General Public Licence (GPL) so anyone can see the source code, the internal structure of the program and the algorithms which are used. Every user can improve, modify, or extend GRASS for his own needs. A striking advantage of the program is that no licence fees have to be paid because of the terms of the GPL. Programmers all over the world contribute to the software. It is one of the biggest Open Source projects in the world (more than one million lines of source code).
GRASS runs on a variety of platforms like GNU/Linux, MS- Windows, MacOS X and POSIX compliant systems. It is completly written in C although a Java version also exist (JGRASS).

==== Historical Background ====
The history of GRASS reaches back until the early eighties. Initially GRASS was developed by the U.S. Army Construction Engineering Research Laboratory (CERL), Champaign, Illinois since 1982 due to the need of new landmanagement and environmental planing tools for military installations. The emphasis was taken on raster analyses and image processing, because the aim of the analyses were the estimatation of the impact of actions on continous surfaces like elevation or soils \cite{neteler2003opensourceGIS} and there were no adequate raster GIS software on the market at that time. Modules for vector processing were added later.

The first version of GRASS was released in 1984 \cite{VanWarren2004}. Because the development of GRASS was financed by taxes the program must have been published as public domain software following the US Americain law. The source code was completely published on the Internet during the late eighties which brought a significant input into the development of GRASS. The CERL withdrew from GRASS development in 1995. An international developer team overtook this task and in 1997 GRASS 4.2 was published by the Baylor University, Waco Texas, USA and GRASS 4.2.1 from the Institute of Physical Geography and Landscape Ecology, University of Hannover, Germany in 1999 under the terms of the GPL. In 1999 the work at version 5.0 were started and the headquarter of the "GRASS Developer Team" moved to the Instituto Trentino di Cultura (ITC-irst), Trento, Italy. GRASS 5.0 was released in 2002, version 6.0 in March 2005. The current stable version is 6.2 which was released at the end of October 2006 \cite{http://grass.itc.it/devel/grasshist.html}.

GRASS was a founding project of the Open Source Geospatial Foundation (OSGeo.org) which was established in February 2006 to support and build high-quality open source geospatial software.

==== Scientific fundamentals ====
===== Philosophy of GRASS =====

The most distinguishing feature of GRASS in comparison to other GIS- software is that the source code can be explored without any restrictions so everyone can study the algorithms which are used. This open structure allows everybody to contribute to the source code to improve GRASS or to extend it for his own needs. For this purpose GRASS provides a GIS- library and a free Programming Manual, which can be downloaded from the GRASS- project site (www.grass-irc.it). Therefore the user has full control of the analyses he does. Besides this point the GPL protects the contributing people of using their code in proprietary software where no free access to the source code is granted. Following the terms of the GPL all code which is based on GPL licensed code must be published again under the GPL.

GRASS offers the user the whole range of GIS functions and together with other (free) software tools it provides a complete and powerful GIS software infrastructure for low costs.

The design of GRASS is not meolithic as in other GIS software but modular and consists of several hundreds of stand alone modules which are loaded when they are called into a GRASS session.

===== Programming and extending GRASS =====
GRASS is written in C and comes along with a sophisticated and well documented C / C++ API \cite{GRASS2006}. As a side effect of the open source philosophy the user has the ability to learn how to develope own applications from existing modules by exploring their source code.

Besides that options GRASS owns the possibility to call the functions already implememented in GRASS with high level programming languages like Python. For that purpose a GRASS-SWIG interface is available which translates ANSI C / C++ declarations into multiple languages (Python, Perl). It contains also an integrated parser for scripting languages.

For easy creation of GRASS extensions it comes along with a extension manager so no source code is needed to build additional GRASS modules. To automate repeating tasks in GRASS shell scripts can be written.

===== Interoperability: GIS and Analysis Toolchain =====
GRASS is designed the way that it offers a highly and robust interoperability with outside applications, giving the user tremendous flexibility and efficiency for accomplishing analyses.

====== Relational Database Systems ======
GRASS can directly connect to relational database management systems (RDBMS) like SQlite, MySQL and PostgreSQL. It even supports PostGIS, the spatial extension of PostgreSQL. To other external RDBMS GRASS offers the connection via the ODBC driver(GRASS Manual). A way to connect to an Oracle / Spatial database is described here \cite{http://www.oracle.com/technology/pub/articles/mitasova-grass.html}.

====== Statistical Analysis ======
For statistic analyses of geodatasets R (a statistic environment, further explanation see \cite{www.r-project.org}) can be called within a GRASS session. Another software to perform geostatic procedures is gstat. For both software packages GRASS interfaces exist. Therefore gstat and R can directly use GRASS raster- and vector datasets and will do their calculations in the spatial region definied in GRASS. This combination offers a high potential for geostatistic analysis as shown by \cite{Bivand2000} and \cite{bivand00open}. GRASS can import and export Matlab binary (.mat) files (version 4) for processing numeric calculations outside GRASS.

====== Interoperability with other GIS Software ======
GRASS supports nearly all common GIS file formats to allow the user to use other GIS applications or external datasources because of its binding to the GDAL/OGR library and the support of the OGC Simple Features. Therefore the data excange between various applications and between several user is easy. The internal file structure implemented in GRASS, coupled with UNIX-style permissions and file locks, allows concurrant access to any given project. In this way, several individuals can share the resources of a single machine and dataset. GRASS works closly together with Quantum GIS. GRASS modules are accessible through a GRASS plugin in Quantum GIS.

====== 2D and 3D Visualization ======
While GRASS comes with fully functional 2D cartography and 3D visualization software (NVIZ), it interacts with other software tools to produce maps or to visualize geographic data sets. GRASS contains exportfilter for Generic Mapping Tool (GMT) files and various image formats so maps can be generated with external image manipulating programs.

For 3D visualization of 3D vector and raster datasets GRASS can export them in VTK (Visualization ToolKit) files which can be viewed in Paraview and script files for Povray, a raytracer to design 3D graphics. Aditional VRML (Virtual Reality Modeling Language) files can be created. Animations can be build with NVIZ or the external programs mentioned above.

====== Web Mapping ======
The UMN Mapserver can connect to GRASS and can read GRASS geodatasets directly. With the help of PyWPS (Python Web Processing Service, an implementation of the Web Processing Service standard from the Open Geospatial Consortium) GRASS modules are accessible via web interfaces easily. Thereby GRASS can serve as a backbone in WebGIS applications.

==== Key applications ====
GRASS is currently used around the world in academic and commercial settings as well as by many govermental agencies and environmental consulting companies. Due to the variety of spatial data and application fields this selection just gives an overview of applications where GRASS was adopted. A collection of papers describing a variety of applications where GRASS has been used can be found here \cite{grassconf2004}.

===== Archaeology =====
GIS is of growing importance in this domain. Therefore GRASS has been widely used in archaeology to support the survey of excavation areas or to simulate the behaviour of ancient agents. GRASS has been used to model the most suitable place to conduct a survey \cite{Brandt1992} in the netherlands. Following the assumption that the settlement actions of the ancient people shows regional patterns, locations most suitable for archaeologic sites can be derived. \cite{Ducke2002} used artificial neural networks as a tool to predict archaeological sites in East Germany. \cite{Lake1998} extented GRASS to automate cumulative viewshed analysis. They also shows how the potential of GIS increase when the software is modified for specific needs. For the modelling of pedestrian hunters and gantherers GRASS contains MAGICAL, which consists of three seperate GRASS modules \cite{Lake2001}. With that model one can simulate multiagent spatial behaviour. How much archaeological surveys can benefit from the incoorporation of GRASS is shown by \cite{Brandon1999}. \cite{Merlo2005} proposed how a GRASS based multidimensional GIS framework for archaeological excavations can be developed.

===== Biology =====
\cite{Tucker1997} used GRASS to model the bird distribution of three bird species in north-east England using a Bayesian rule-based approach. They linked data about habitat preferences and life-histry of the birds against physiogeographic and satellite data using GRASS.

For the Iberian Peninsula \cite{Garzon2006} have used GRASS to model the potential area of Pinus Sylvestris. They predict the habitat suitability with a machine learning software suite in GRASS GIS. They incorporated three machine learning technics (Tree-based Classification, Neural Networks and Random Forest). All three models show a larger potential area of P. sylvestris as the present one. In the Rocky Mountains National Park tree population parameters have been modeled by \cite{Baker1997} for the forest-tundra ecotone.

===== Environmental Modelling =====
GRASS offers a variety of technics to conduct environmental modelling tasks as described in \cite{Mitasova1995}. An overview of the potential of GRASS in environmental modelling is given from \cite{Mitchell2002}. Besides the ability to write own models GRASS has several kinds of models already implemented. It contains model for hydrologic modelling (Topmodel, SWAT, Storm Water Runoff, CASC2D), watershed calculations and floodplain analyis as well as erosion modelling (ANSWERS, AGNPS 5.0, KINEROS). Furthermore there are existing models for landscape ecological analysis and wildfire spreat simulations. GRASS has been widely used in environmental modelling because its strong raster and voxel processing capabilities.

===== Geography (Human / Physical) =====
GIS are used in a wide range of analysis in human and physical Geography because both directions makes extensivliy use of geodata or spatial geodatabases. Therefore GRASS as a GIS software is used in geographic surveys the world over.

===== Geology / Planetary Geology =====
\cite{Kajiyama2004} and \cite{Masumoto2006} used GRASS to derive 3D geological models in Japan. Kajiyama et al used a Digital elevation model (DEM) and a logical model of the geological structure to derive the surface boundaries of each geologic structure in the study area. From these data they built a 3D geological model.

GRASS has been also used in planetary geology. \cite{Frigeri2004} identified Wrinkle Ridges on Mars which can be an evidence of existing subsurface ice on the planet. They used Mars MGS and data from the Viking Mission. The mapping of geologic features from Mars data is done by \cite{Deuchler2004}. The ability to import the raw data from various Mars datasets and to reproject them in easy way is seen as a great benefit by the authors of this survey. The authors detected tectonic surface faults and assigned them to a geologic Mars region.

===== Geomorphology / Geomorphometry =====
Modules for surface analyses in GRASS offers the possibility to derive terrain parameters like slope, aspect, pcurve and tcurve in one step. \cite{Bivand1999} has shown how the geomorphology of a examplery study area in the Kosovo can be statistical analysed with GRASS and R. From a subset of GTOPO30 elevation date he performed various statistic computations on selected relief parameter leading to a classification of geomorpholic units. \cite{Grohmann2004} has used the combination of GRASS and R to perform morphometric analysis of a mountainous terrain in Brazil. With this package he derived morphometric parameters (hypsometry, slope, aspect, swat profiles, lineament and drainage density, surface roughness, isobase and hydraulig gradient) from DEMs and analysed these parameters statistically.

GRASS has also been used to define landslide succesiblity areas by \cite{Clerici2002}. They used a combination of GRASS with the gawk programming language to create landslide susceptibility maps of Parma River basin in Italy. They showed that even large datasets can be processed in GRASS fast and without problems.

===== Geostatistics =====
\cite{bivand00open} has used a combination of GRASS, R and postgreSQL to analyze various geodatasets. They have shown that these technics provide a powerful toolbox to analyse natural phenomena as well as socio-economic data.

===== Hydrologic Modelling =====
Hydrologic models can be easily parameterized with GRASS \cite{Savabi1995}. \cite{Cullmann2006} calculated a more appropriate flow time as an input for the flow analyisis of a river in East Germany based on WaSiM-ETH.
Besides the available models implemented in GRASS, own models can be realised in GRASS as shown by \cite{Frankenberger1999}. They incorporated a Soil Moisture Routing model which combines elevation, soil and landuse data and predicts soil moisture, evapotranspiration, saturation-excess overland flow and interflow for a watershed.

===== Oceanography =====
For nautical hydrographic surveys GRASS offers some helpful modules to generate bathymetric surfaces by the interpolation of sounding data. \cite{Kaitala2002} built up an environmental GIS database for the White Sea based on GRASS GIS incoorporating seveveral hydrological and chemical parameters to validate numerical ecosystem modeling with the purpose to evaluate effects of climate change and human impact on the ecosystem.

===== Landscape epidemiology and public health =====
With the help of GIS the spread of epidemics can be analysed or predicted. With GRASS the outbreak of the avian influenza in northern Italy in the winter 1999-2000 was examined by \cite{Manelli2006}. GRASS and R were used to map the distribution of the outbreaks of highly pathogenic avian influenza which was caused by a H7N1 subtype virus.

To predict the risk of Lyme Disease for the Italian province of Trento GRASS has been used in several studies. The distribution of ticks infected with Borrelia burgdorferi s.l. was analysed by \cite{rizzoli2002geographical} with a bootstrap aggregation model of tree based classifiers in GRASS. The occurence of ticks were cross-correlated with environmental data in the GIS. \cite{furlanello2003gis} developed a spatial model of the propability of ticks presence using machine learning technics incorporated in GRASS and R.

A combination of GRASS GIS, Mapserver and R is used by the Public health Applications in Remote Sensing (PHAiRS) NASA REASoN project \cite{Benedict}. The objective of this project is to offer official authorities dynamic informations on illnesses and conditions. Environmental and atmospheric conditions which affect public health are derived from NASA data sets in a way that local public health officials can use them for their decisions.

===== Precision Farming =====
The potential of GRASS for Precision Farming is shown in \cite{Haverland1999}. \cite{Mccauley1999} testet a combination of cotton grow models and GRASS for the development of a spatial simulation methodology for precision farming.

===== Remote Sensing =====
GRASS with its sophisticated raster processing capability and the already implemented image processing modules offers the user a high potential for processing remote sensing data for low costs. The existing modules include functions for image preparation, image classification and image ratios. The software has also some functions for creating Orthofotos and image enhancement. \cite{neteler2005imgToolbox} give an overview of the tools for image processing in GRASS.

The potential to detect objects from airbone Laser Scanning data for urban mapping and natural hazard analysis is described in \cite{Hoefle2006,Rutzinger2006}.

\cite{neteler2005modis} used GRASS to produce time series of MODIS NDVI/EVI and LST data for epidimiologic applicications.

===== Soil Science =====
\cite{Ameskamp1997} derived a three dimensional continous soil model with the help of GRASS. He used fuzzy sets to represent soil-landscape relations as fuzzy rules. With these rules he examined landscape information data which led into a three dimensional soil model.

* Romano, N. & Palladino, M. Prediction of soil water retention using soil physical data and terrain attributes Journal of Hydrology, 2002, 265, 56 - 75
* Numerical evaluation of ''aspect effect'' with r.sun (Dylan Beaudette [in progress])

===== Education =====
The GRASS community promote the teaching of GRASS and other FOSSGIS (Free and Open Source Software GIS) to train the next generation in this forward looking technics. For this purpose education material available on the GRASS wiki \cite{http://grass.gdf-hannover.de/wiki}.

==== Future directions ====
The development of GRASS as a native Windows application and the building of a new unified Graphical User Interface for Linux, Mac, Windows and Unix using WxWidgets and Python will certainly rise the distribution of the program. The prototype code is already working. Its advantages in modelling, price and extending makes GRASS a strong alternative to other GIS software. The increasing popularity will lead into an increasing development of the software. More people will contribute to the source code, bugtracking and documentation.
GRASS has some innovative functions already implemented (e. g. functions for network analysis like shortest path, route planing), waiting for new applications to be developed on top. For 3D modelling the infrastructure and moduls are in place for raster, vector and site data leading to an increasing usage in spatial modelling.

==== Cross References ====
1. Quantum GIS

2. PostGIS

3. UMN Map Server

4. OSGeo

5. Open GIS Consortium

==== Recommended Reading (5 - 15 entries) ====
* Neteler, M. & Mitasova, H. (2004): Open Source GIS: A Grass GIS Approach. 2nd Edition. Boston.<BR>(of course)

* GRASS GIS 6.0 Tutorial. GDF Hannover bR (2005). Version 1.2, 149 pages.<BR>http://www.gdf-hannover.de/media.php?id=0&lg=en

* GRASS Newsletters [http://grass.itc.it/newsletter/index.php]

* Lo, C.P. & Yeung, A.K.W. Concepts and Techniques of Geographic Information Systems Prentice Hall, 2006

* Robinson, A.H.; Morrison, J.L.; Muehrcke, P.C. & Guptil, S.C. Elements of Cartography John Wiley and Sons, 1995

* Haverland, G. (1999): Precision Farming and Linux: An Expose. Linux Journal.

* GRASS Programmer Manual (http://grass.itc.it/devel/index.php#prog)

==== Aditional definitions ====
If there are some definition in our text which would be worse mentioned in the Encyclopaedia...

=== Contact & Coordination===
<pre>
Malte Halbey-Martin
Free University Berlin
Dept. of Geosciences
Inst. of Geogr. Sciences
Malteserstr. 74-100
D-12249 Berlin, Germany
===============
tel: +49.30.83870409
fax: +49.30.83870755
email: malte at geog.fu-berlin.de
online: www.geog.fu-berlin.de/~malte
</pre>
=== Springer contact ===
<pre>
Jennifer Carlson / Andrea Schmidt
Development Editors
Springer
233 Spring Street
New York, NY 10016
===============
tel: 212.460.1666
fax: 212.460.1594
email: jennifer.carlson at springer.com
online: www.springer.com
</pre>

<pre>
Andreas Neumann <neumann at karto.baug.ethz.ch>
Institute of Cartography
ETH Zurich
Wolfgang-Paulistrasse 15
CH-8093 Zurich, Switzerland

Phone: ++41-44-633 3031, Fax: ++41-44-633 1153
e-mail: neumann at karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
</pre>

R statistics

2006-12-19T19:41:52Z

⚠️DylanBeaudette:

'''Q:''' How do I enjoy high quality statistic analysis in GRASS?

'''A:''' Well, GRASS has got an interface to the most powerful statistics analysis package around: R-stats (http://www.r-project.org)

First of all you need to add R to your system, the R version must be >= 1.9.1:

'''Debian GNU/Linux''' user, if you usually upgrade your system with apt-get, add to file /etc/apt/sources.list the line:

deb http://cran.r-project.org/bin/linux/debian woody main

or point it to a mirror site near you. Then run 'apt-get update' and 'apt-get upgrade', this will upgrade all debian packages (including R, with the newest release). Michele.

'''RedHat, Suse, Mandrake''' and similar distros: take the latest R rpm and install it

Once you have R in your system, take a look at http://grass.itc.it/statsgrass/grass_r_install.html. For the impatient just start it:

<pre>
> R

#and install packages directly from the net
pkgs <- c('akima', 'spgrass6', 'RODBC', 'VR')

install.packages(pkgs, dependencies=TRUE, type='source')
</pre>

'''See also''':

* Connecting R to RDBMS: http://grass.itc.it/statsgrass/r_and_dbms.html
* Using GRASS and R: http://grass.itc.it/statsgrass/grass_r_interface.html

[[Category:Installation]]
[[Category:FAQ]]

Common Tasks

2006-12-13T07:36:41Z

⚠️DylanBeaudette: /* GIS Tasks */

<h1> Mini-tutorials showcasing some common GIS taks </h1>

== Import/Export and Display ==

* Import and display SRTM elevation data
: ''r.in.srtm''
:* ''[http://grass.ibiblio/newsletter/GRASSNews_vol3.pdf GRASS Newsletter, 3, June 2005]''.
:* You can also get the SRTM data with a convenient web interface at http://srtm.csi.cgiar.org/. These come in 5 degree blocks and can be downloaded either as geotiff or ascii files.

* Import and display VMap0 Digital Chart of the World
: ''v.in.ogr''
:* ''[http://grass.ibiblio.org/newsletter/GRASSNews_vol3.pdf GRASS Newsletter, 3, June 2005]''.
:* If your region crosses the boundaries of a VMap0 block you can use the v.append command, available in the Grass addons section of this wiki, to combine vectors across the edges. It can take quite a while to complete.

* Import and display ETOPO2 world elevation and bathymetry dataset
: ''r.in.bin''
:* ''[http://grass.ibiblio/newsletter/GRASSNews_vol1.pdf Global dataset of bathymetry and topography. GRASS Newsletter, 1:8-11, August 2004.]''

=== General Import / Export ===
* Raster import and export with ''r.in.gdal'' / ''r.out.gdal''
:
:* ''r.in.gdal'' misc. tips
:* ''r.out.gdal'' data types, creation options, new flags

* Vector import and export with ''v.in.org'' / ''v.out.ogr''
:
:* ''v.in.ogr'' misc. tips, shapefile gotchas
:* ''v.out.ogr'' data types, dsn, new flags

== GIS Tasks ==

* Map (re-)projection
** r.proj and v.proj (snippets from manual pages)
** gdal_warp as an alternative for large, complex (re-)projection tasks
** ogr2ogr as an alternative to v.proj

* [[Georeferencing | Georectify a scanned raster image]]
** r.in.gdal into XY location
** GUI georectifier
** i.points + i.rectify (alternate method)

* [[Trace vector contours from a scanned map]]

* Create a DEM from contour lines and trig points
** r.surf.contour

* Create a DEM from x,y,z point data
** v.surf.rst
** v.surf.idw
** v.surf.bspline
** r.surf.nnbathy

* Create vector contour lines from a raster DEM
** r.contour

== 3D Visualization ==

* Use NVIZ to render a 3D image
nviz elevation.dem

* Use NVIZ to make a fly through movie
** see nviz keyframe animation panel help page
** [[Movies | Encoding Movies]]

* Use Paraview to render a 3D image
** r.out.vtk, v.out.vtk

== Raster operations ==

=== Creation ===

* slope, aspect and surface parameters
** r.slope.aspect
** r.param.scale

* Create a shaded relief map
** r.shaded relief

* drape semi-transparent land use map over shaded relief map
** d.his

=== Analysis ===

* cost surface analysis
** r.cost
** r.drain (fun examples)
** r.walk (fun examples) [how output is different]

== Vector operations ==

* Disolve interior lines
** v.dissolve

== Hardcopy and Presention Graphics Creation ==

* Create a high quality hardcopy plot
** Creating PostScript with [[Ps.map_scripts | ps.map]]
** export to GMT

[[Category:Documentation]]
[[Category:FAQ]]

Common Tasks

2006-12-13T07:36:32Z

⚠️DylanBeaudette: /* GIS Tasks */

Common Tasks

2006-12-13T07:32:38Z

⚠️DylanBeaudette: /* Raster operations */

<h1> Mini-tutorials showcasing some common GIS taks </h1>

== Import/Export and Display ==

* Import and display SRTM elevation data
: ''r.in.srtm''
:* ''[http://grass.ibiblio/newsletter/GRASSNews_vol3.pdf GRASS Newsletter, 3, June 2005]''.
:* You can also get the SRTM data with a convenient web interface at http://srtm.csi.cgiar.org/. These come in 5 degree blocks and can be downloaded either as geotiff or ascii files.

* Import and display VMap0 Digital Chart of the World
: ''v.in.ogr''
:* ''[http://grass.ibiblio.org/newsletter/GRASSNews_vol3.pdf GRASS Newsletter, 3, June 2005]''.
:* If your region crosses the boundaries of a VMap0 block you can use the v.append command, available in the Grass addons section of this wiki, to combine vectors across the edges. It can take quite a while to complete.

* Import and display ETOPO2 world elevation and bathymetry dataset
: ''r.in.bin''
:* ''[http://grass.ibiblio/newsletter/GRASSNews_vol1.pdf Global dataset of bathymetry and topography. GRASS Newsletter, 1:8-11, August 2004.]''

=== General Import / Export ===
* Raster import and export with ''r.in.gdal'' / ''r.out.gdal''
:
:* ''r.in.gdal'' misc. tips
:* ''r.out.gdal'' data types, creation options, new flags

* Vector import and export with ''v.in.org'' / ''v.out.ogr''
:
:* ''v.in.ogr'' misc. tips, shapefile gotchas
:* ''v.out.ogr'' data types, dsn, new flags

== GIS Tasks ==

* [[Georeferencing | Georectify a scanned raster image]]
** r.in.gdal into XY location
** GUI georectifier
** i.points + i.rectify (alternate method)

* [[Trace vector contours from a scanned map]]

* Create a DEM from contour lines and trig points
** r.surf.contour

* Create a DEM from x,y,z point data
** v.surf.rst
** v.surf.idw
** v.surf.bspline
** r.surf.nnbathy

* Create vector contour lines from a raster DEM
** r.contour

== 3D Visualization ==

* Use NVIZ to render a 3D image
nviz elevation.dem

* Use NVIZ to make a fly through movie
** see nviz keyframe animation panel help page
** [[Movies | Encoding Movies]]

* Use Paraview to render a 3D image
** r.out.vtk, v.out.vtk

== Raster operations ==

=== Creation ===

* slope, aspect and surface parameters
** r.slope.aspect
** r.param.scale

* Create a shaded relief map
** r.shaded relief

* drape semi-transparent land use map over shaded relief map
** d.his

=== Analysis ===

* cost surface analysis
** r.cost
** r.drain (fun examples)
** r.walk (fun examples) [how output is different]

== Vector operations ==

* Disolve interior lines
** v.dissolve

== Hardcopy and Presention Graphics Creation ==

* Create a high quality hardcopy plot
** Creating PostScript with [[Ps.map_scripts | ps.map]]
** export to GMT

[[Category:Documentation]]
[[Category:FAQ]]

Common Tasks

2006-12-13T07:29:31Z

⚠️DylanBeaudette: /* Import/Export and Display */

<h1> Mini-tutorials showcasing some common GIS taks </h1>

== Import/Export and Display ==

* Import and display SRTM elevation data
: ''r.in.srtm''
:* ''[http://grass.ibiblio/newsletter/GRASSNews_vol3.pdf GRASS Newsletter, 3, June 2005]''.
:* You can also get the SRTM data with a convenient web interface at http://srtm.csi.cgiar.org/. These come in 5 degree blocks and can be downloaded either as geotiff or ascii files.

* Import and display VMap0 Digital Chart of the World
: ''v.in.ogr''
:* ''[http://grass.ibiblio.org/newsletter/GRASSNews_vol3.pdf GRASS Newsletter, 3, June 2005]''.
:* If your region crosses the boundaries of a VMap0 block you can use the v.append command, available in the Grass addons section of this wiki, to combine vectors across the edges. It can take quite a while to complete.

* Import and display ETOPO2 world elevation and bathymetry dataset
: ''r.in.bin''
:* ''[http://grass.ibiblio/newsletter/GRASSNews_vol1.pdf Global dataset of bathymetry and topography. GRASS Newsletter, 1:8-11, August 2004.]''

=== General Import / Export ===
* Raster import and export with ''r.in.gdal'' / ''r.out.gdal''
:
:* ''r.in.gdal'' misc. tips
:* ''r.out.gdal'' data types, creation options, new flags

* Vector import and export with ''v.in.org'' / ''v.out.ogr''
:
:* ''v.in.ogr'' misc. tips, shapefile gotchas
:* ''v.out.ogr'' data types, dsn, new flags

== GIS Tasks ==

* [[Georeferencing | Georectify a scanned raster image]]
** r.in.gdal into XY location
** GUI georectifier
** i.points + i.rectify (alternate method)

* [[Trace vector contours from a scanned map]]

* Create a DEM from contour lines and trig points
** r.surf.contour

* Create a DEM from x,y,z point data
** v.surf.rst
** v.surf.idw
** v.surf.bspline
** r.surf.nnbathy

* Create vector contour lines from a raster DEM
** r.contour

== 3D Visualization ==

* Use NVIZ to render a 3D image
nviz elevation.dem

* Use NVIZ to make a fly through movie
** see nviz keyframe animation panel help page
** [[Movies | Encoding Movies]]

* Use Paraview to render a 3D image
** r.out.vtk, v.out.vtk

== Raster operations ==

* Create a shaded relief map
** r.shaded relief

* drape semi-transparent land use map over shaded relief map
** d.his

== Vector operations ==

* Disolve interior lines
** v.dissolve

== Hardcopy and Presention Graphics Creation ==

* Create a high quality hardcopy plot
** Creating PostScript with [[Ps.map_scripts | ps.map]]
** export to GMT

[[Category:Documentation]]
[[Category:FAQ]]

Common Tasks

2006-12-13T07:28:36Z

⚠️DylanBeaudette: /* Import/Export and Display */

<h1> Mini-tutorials showcasing some common GIS taks </h1>

== Import/Export and Display ==

* Import and display SRTM elevation data
: ''r.in.srtm''
:* ''[http://grass.ibiblio/newsletter/GRASSNews_vol3.pdf GRASS Newsletter, 3, June 2005]''.
:* You can also get the SRTM data with a convenient web interface at http://srtm.csi.cgiar.org/. These come in 5 degree blocks and can be downloaded either as geotiff or ascii files.

* Import and display VMap0 Digital Chart of the World
: ''v.in.ogr''
:* ''[http://grass.ibiblio.org/newsletter/GRASSNews_vol3.pdf GRASS Newsletter, 3, June 2005]''.
:* If your region crosses the boundaries of a VMap0 block you can use the v.append command, available in the Grass addons section of this wiki, to combine vectors across the edges. It can take quite a while to complete.

* Import and display ETOPO2 world elevation and bathymetry dataset
: ''r.in.bin''
:* ''[http://grass.ibiblio/newsletter/GRASSNews_vol1.pdf Global dataset of bathymetry and topography. GRASS Newsletter, 1:8-11, August 2004.]''

* General raster import and export with ''r.in.gdal'' / ''r.out.gdal''
:
:* ''r.in.gdal'' misc. tips
:* ''r.out.gdal'' data types, creation options, new flags

* General vector import and export with ''v.in.org'' / ''v.out.ogr''
:
:* ''v.in.ogr'' misc. tips, shapefile gotchas
:* ''v.out.ogr'' data types, dsn, new flags

== GIS Tasks ==

* [[Georeferencing | Georectify a scanned raster image]]
** r.in.gdal into XY location
** GUI georectifier
** i.points + i.rectify (alternate method)

* [[Trace vector contours from a scanned map]]

* Create a DEM from contour lines and trig points
** r.surf.contour

* Create a DEM from x,y,z point data
** v.surf.rst
** v.surf.idw
** v.surf.bspline
** r.surf.nnbathy

* Create vector contour lines from a raster DEM
** r.contour

== 3D Visualization ==

* Use NVIZ to render a 3D image
nviz elevation.dem

* Use NVIZ to make a fly through movie
** see nviz keyframe animation panel help page
** [[Movies | Encoding Movies]]

* Use Paraview to render a 3D image
** r.out.vtk, v.out.vtk

== Raster operations ==

* Create a shaded relief map
** r.shaded relief

* drape semi-transparent land use map over shaded relief map
** d.his

== Vector operations ==

* Disolve interior lines
** v.dissolve

== Hardcopy and Presention Graphics Creation ==

* Create a high quality hardcopy plot
** Creating PostScript with [[Ps.map_scripts | ps.map]]
** export to GMT

[[Category:Documentation]]
[[Category:FAQ]]

Trace vector contours from a scanned map

2006-12-13T07:22:10Z

⚠️DylanBeaudette: /* Convert to vector map */

== Import ==

* Import a scanned map image. To save processing later you might want to mask out obvious text and other noise in a paint program first.
r.in.gdal

* [[Georeferencing | Georectify]] map using GUI georectifier or i.points + i.rectify
* Switch to target location
* We now have a registered raster map containing a 300 dpi scan of our A0 sized paper map

== Convert to vector map ==

* Check how many categories (map colors)
r.info chart
: ''8 colors''

* Zoom to the map's bounds
g.region rast=chart

* Display map (command line version)
d.mon x0
d.rast chart

* Query map values (command line version)
d.what.rast
: ''black is category 1''

* Create a reclass map, with just the black lines
r.reclass in=chart out=chart_black << EOF
1 = 1 black
EOF

* Thin the lines to be 1 raster cell wide
r.thin in=chart_black out=chart_black.thinned

* Sometimes it helps to "grow" the contours before thinning, especially when the scan is not of high quality and contours have "breaks" in them. Note that you may have to repeatedly try different radius values to get the desired effect.
r.grown in=chart out=chart_grown radius=n_cells

* Convert raster lines to vector lines
r.to.vect -s in=chart_black.thinned out=chart_lines

== Clean vector map ==

* Remove any dangles smaller than 1km
v.clean in=chart_lines out=chart_lines_cleaned tool=rmdangle thresh=1000

* Remove known grid lines
v.mkgrid
v.buffer
v.overlay ain=scanned_lines bin=buffered_grid operator=not

* Clean by hand in with the digitizing tool
v.digit
:or the [http://qgis.org QGIS] GRASS vector editor

* Connect lines which were broken at dangles
v.build.polylines -q in=chart_lines_cleaned out=chart_polyline

== Remove short line segments ==

* Add category numbers to lines
v.category in=chart_polyline out=chart_polyline_cat type=line

* Create a DB table to hold line length values
v.db.addtable chart_polyline_cat columns="length_km DOUBLE PRECISION"

* Upload line lengths to DB table
v.to.db chart_polyline_cat type=line option=length units=k column=length_km

* Extract line features longer than 5km (cleans out the noise)
v.extract in=chart_polyline_cat out=chart_lines_5km type=line where="length_km > 5"

== View ==

* Display result over raster chart (command line version)
d.vect chart_lines_5km color=red width=2

* Export as a shapefile
v.out.ogr in=chart_lines_5km dsn=chart_lines_gt5km

* View shapefile in [http://qgis.org QuantumGIS]
qgis chart_lines_gt5km/chart_lines_5km_crop.shp

''Done!''

[[Category:Documentation]]
[[Category:FAQ]]

About GRASS

2006-12-12T22:51:03Z

⚠️DylanBeaudette: /* Soil Science */

This wiki page is initially for organizing the writing of a GRASS entry for the "''Springer Encyclopedia of GIS''", in future this wiki page will contain the article itself.

=== The entry structure ===
The Structure of the entry is given by springer. I received a .tex file which I fill with the text when this text is reviewd by the community (and my wife because she's an english teacher :-)).

=== Inspiration ===

* The Wikipedia entry (GNU Free Documentation License; probably '''do not reuse''' any content)<BR>http://en.wikipedia.org/wiki/GRASS_GIS

=== Issues ===

* Who owns the copyright for the article? Springer? The author(s)?
The Contract says:
The author hereby grants and assigns to Springer- Verlag the sole right to publish, distribute and sell... the contribution and parts thereof...

Springer verlag will take ... either in his own name or in that of the author any necessary steps to protect these rights against infringement by third parties. It will have the copyright notice inserted into all editions of the work according to the provisions of the Universal Copyright Convention and dutifully take care of all formalities in this connections, either in its own name or in that of the author.

* Should the article be wholly original or can it be derived (cut and pasted) from existing GRASS texts (e.g. the GRASS logo; website content)?
I supose we should write something new and shouldn't cut & paste because of the following point.

* If cut&pasted, does that put the existing GRASS website text etc at risk? (let's avoid a Eric Weisstein's MathWorld vs. CRC Press style nightmare [http://mathworld.wolfram.com/about/erics_commentary.html])
see above

* Can we reuse the text? (e.g. publish it here on the wiki or as an article in a future GRASSNews newsletter)
I will ask the people at springer

=== What needs to be done? ===
The deadline is something about 'late december, after Christmas'

the entry should be 8-12 pages - here is an example:
http://refworks.springer.com/mrw/fileadmin/pdf/GIS/VoronoiEncy

Here is some additional information:
http://refworks.springer.com/geograph/

Here are the templates:
http://refworks.springer.com/geograph/

And here is a list of other entries (as of 2006-11-21)
http://www.carto.net/neumann/temp/gis_encyclopedia_toc.pdf

=== The Entry ===

* screenshots needed? if so, how many?
* no limit, but I think we shouldn't include more than 3
* I would suggest some screenshots with 3d vector and 3d raster

==== Title: ====
GRASS

==== Author ====
Malte Halbey-Martin, Inst. of Geogr. Sciences, Free University Berlin, Germany

''Please put your name here when you have written something''

==== Synonyms ====
Geographic Resources Analysis Support Software, GRASS- GIS
(Geographic Information System)

==== Definition (fewer than 250 words)====
GRASS- GIS (Geographic Resources Analysis Support Software) is a GIS- software for geospatial analyses and modelling which has the capability to manage raster and vectordata. Additionally it supports three dimensional modelling with 3D raster voxel or 3D vector data and contains several image processing modules to manipulate remote sensing data. It comes along with visualization tools and interacts with other related software packages e. g. R- language, gstat and Quantum GIS. GRASS supports a variety of GIS formats due to the usage of the GDAL/OGR library. It also supports the OGC- conformal Simple Features.It can connect to databases via ODBC and supports spatial databases like PostGIS. GRASS datasets can be published on the internet with the UMN Mapserver.

The software is published under the conditions of the GNU General Public Licence (GPL) so anyone can see the source code, the internal structure of the program and the algorithms which are used. Every user can improve, modify, or extend GRASS for his own needs. A striking advantage of the program is that no licence fees have to be paid because of the terms of the GPL. Programmers all over the world contribute to the software. It is one of the biggest Open Source projects in the world (more than one million lines of source code).
GRASS runs on a variety of platforms like GNU/Linux, MS- Windows, MacOS X and POSIX compliant systems. It is completly written in C although a Java version also exist (JGRASS).

==== Historical Background (fewer than 500 words) ====
The history of GRASS reaches back until the early eighties. Initially GRASS was developed by the U.S. Army Construction Engineering Research Laboratory (CERL), Champaign, Illinois since 1982 due to the need of new landmanagement and environmental planing tools for military installations. The emphasis was taken on raster analyses and image processing, because the aim of the analyses were the estimatation of the impact of actions on continous surfaces like elevation or soils(Neteler & Mitasova 2004) and there were no adequate raster GIS software on the market at that time. Modules for vector processing were added later.

The first version of GRASS was released in 1984 (Vanderfelt 1994). The source code was completely published on the Internet during the late eighties which brought a significant input into the development of GRASS. The CERL withdrew from GRASS development in 1995. An international developer team overtook this task and in 1997 GRASS 4.2 was published by the Baylor University, Waco Texas, USA and GRASS 4.2.1 from the Institute of Physical Geography and Landscape Ecology, University of Hannover, Germany in 1999 under the terms of the GPL. In 1999 the work at version 5.0 were started and the headquarter of the "GRASS Developer Team" moved to the Instituto Trentino di Cultura (ITC-irst), Trento, Italy. GRASS 5.0 was released in 2002, version 6.0 in March 2005. The current stable version is 6.2 which was released at the end of October 2006 (http://grass.itc.it/devel/grasshist.html).

''Tabelle Vanderfelt 1994???''

''maybe we should add some mayor steps of the development...''

''see GRASS history page: http://grass.itc.it/devel/grasshist.html''

==== Scientific fundamentals ====
===== Philosophy of GRASS =====

The most distinguishing feature of GRASS in comparison to other GIS- software is that the source code can be explored without any restrictions so everyone can study the algorithms which are used. This open structure allows everybody to contribute to the source code to improve GRASS or to extend it for his own needs. For this purpose GRASS provides a GIS- library and a free Programming Manual, which can be downloaded from the GRASS- project site (www.grass-irc.it). Therefore the user has full control of the analyses he does. Besides this point the GPL protects the contributing people of using their code in proprietary software where no free access to the source code is granted. Following the terms of the GPL all code which is based on GPL licensed code must be published again under the GPL (cite GPL?).

GRASS offers the user the whole range of GIS functions and together with other (free) software tools it provides a complete and powerful GIS software infrastructure for low costs.

===== Programming and extending GRASS =====
''I wonder if I'm the right person to write that because of the lack of programming skills''

GRASS is written in C and comes along with a sophisticated and well documented C / C++ API (Cite Programming Manual). As a side effect of the open source philosophy the user has the ability to learn how to develope own applications from existing modules by exploring their source code.

Besides that options GRASS owns the possibility to call the functions already implememented in GRASS with high level programming languages like Python. For that purpose a GRASS-SWIG interface is available which translates ANSI C / C++ declarations into multiple languages (Python, Perl). It contains also an integrated parser for scripting languages.

For easy creation of GRASS extensions it comes along with a extension manager so no source code is needed to build additional GRASS modules. To automate repeating tasks in GRASS shell scripts can be written.

===== Interoperability: GIS and Analysis Toolchain =====
GRASS is designed the way that it offers a highly and robust interoperability with outside applications, giving the user tremendous flexibility and efficiency for accomplishing analyses.

====== Relational Database Systems ======
GRASS can directly connect to relational database management systems (RDBMS) like SQlite, MySQL and PostgreSQL. It even supports PostGIS, the spatial extension of PostgreSQL. To other external RDBMS GRASS offers the connection via the ODBC driver (cite GRASS Manual). A way to connect to an Oracle (? / Spatial ?) database is described by Mitasova, Neteler & Holl (http://www.oracle.com/technology/pub/articles/mitasova-grass.html).

* <strike>Oracle</strike> (there is no direct Oracle driver in GRASS)

''I thought it would be important for GIS users to know, that there's the possibility to connect to oracle...''
''is this accomplished through GDAL ?''
''when I got it right from the article above one has to compile GDAL/ogr from source with OCI bindings...''

====== Statistical Analysis ======
For statistic analyses of geodatasets R (a statistic environment, further explanation see www.r-project.org) can be called within a GRASS session. Another software to perform geostatic procedures is gstat. For both software packages GRASS interfaces exist. Therefore gstat and R can directly use GRASS raster- and vector datasets and will do their calculations in the spatial region definied in GRASS. This combination offers a high potential for geostatistic analysis as shown by Bivand (2000) and Bivand & Neteler (2000). GRASS can import and export Matlab binary (.mat) files (version 4) for processing numeric calculations outside GRASS.

====== Interoperability with other GIS Software ======
GRASS supports nearly all common GIS file formats to allow the user to use other GIS applications or external datasources because of its binding to the GDAL/OGR library and the support of the OGC Simple Features. Therefore the data excange between various applications and between several user is easy. The database ('''clarify differences between RDBMS''') structure implemented in GRASS, coupled with UNIX-style permissions and file locks, allows concurrant access to any given project. In this way, several individuals can share the resources of a single machine and dataset. GRASS works closly together with Quantum GIS. GRASS modules are accessible through a GRASS plugin in Quantum GIS.

====== 2D and 3D Visualization ======
While GRASS comes with fully functional 2D cartography and 3D visualization software (NVIZ), it interacts with other software tools to produce maps or to visualize geographic data sets. GRASS contains exportfilter for Generic Mapping Tool (GMT) files and various image formats so maps can be generated with external image manipulating programs.

For 3D visualization of 3D vector and raster datasets GRASS can export them in VTK (Visualization ToolKit) files which can be viewed in Paraview and script files for Povray, a raytracer to design 3D graphics. Aditional VRML (Virtual Reality Modeling Language) files can be created. Animations can be build with NVIZ or the external programs mentioned above.

====== Web Mapping ======
The UMN Mapserver can connect to GRASS and can read GRASS geodatasets directly. With the help of PyWPS (Python Web Processing Service, an implementation of the Web Processing Service standard from the Open Geospatial Consortium) GRASS modules are accessible via web interfaces easily. Thereby GRASS can serve as a backbone in WebGIS applications.

==== Key applications ====
GRASS is currently used around the world in academic and commercial settings as well as by many govermental agencies and environmental consulting companies. Due to the variety of spatial data and application fields this selection just gives an overview of applications where GRASS was adopted.

===== Archaeology =====

* Benjamin Ducke
* Mark Lake

===== Biology =====

Tucker et al (1997) used GRASS to model the bird distribution of three bird species in north-east England using a Bayesian rule-based approach. They linked data about habitat preferences and life-histry of the birds against physiogeographic and satellite data using GRASS.

For the Iberian Peninsula Garzon et al 2006 have used GRASS to model the potential area of Pinus Sylvestris. They predict the habitat suitability with a machine learning software suite in GRASS GIS. They incorporated three machine learning technics (Tree-based Classification, Neural Networks and Random Forest). All three models show a larger potential area of P. sylvestris as the present one. In the Rocky Mountains National Park tree population parameters have been modeled by Baker et al 1997 for the forest-tundra ecotone.

===== Environmental Modelling =====

===== Geography (Human / Physical) =====

===== Geology / Planetary Geology =====

Kajiyama et al 2004 and Masumoto et al used GRASS to derive 3D geological models in Japan. Kajiyama et al used a Digital elevation model (DEM) and a logical model of the geological structure to derive the surface boundaries of each geologic structure in the study area. From these data they built a 3D geological model.

GRASS has been also used in planetary geology. Frigeri et al identified Wrinkle Ridges on Mars which can be an evidence of existing subsurface ice on the planet. They used Mars MGS and data from the Viking Mission. The mapping of geologic features from Mars data is done by Deuchler et al (2004). The ability to import the raw data from various Mars datasets and to reproject them in easy way is seen as a great benefit by the authors of this survey. The authors detected tectonic surface faults and assigned them to a geologic Mars region.

===== Geomorphology \ Geomorphometry =====
* Analysis of mountainous terrain (Carlos Henrique Grohmann Computers & Geosciences, 30 (9-10):1055-1067)
* Landscape / landform classification (Bivand, R. Integrating GRASS 5.0 and R: GIS and modern statistics Computers & Geosciences, 2000, 26, 1043–1052.)

===== Geostatistics =====
* gstat
* R (see article in GRASS Newsletter vol 3)

===== Hydrologic Modelling =====

===== Hydrographic Surveys (nautical) =====

===== Landscape epidemiology and public health =====

===== Network analysis =====

===== Planning =====

===== Precision Farming =====
* Haverland
* Goddard et al

===== Remote Sensing =====

===== Soil Science =====
* Three-dimensional Rule-based Continuous Soil Modelling ([http://www.is.informatik.uni-kiel.de/~ma/trcs/thesis.html Martin Ameskamp PhD thesis])
* Landscape scale modeling of soil properties (Dylan Beaudette [in progress])
* Numerical evaluation of ''aspect effect'' with r.sun (Dylan Beaudette [in progress])

===== Education =====

==== Future directions ====
The development of GRASS as a native Windows application and the building of a new unified Graphical User Interface for Linux, Mac, Windows and Unix using WxWidgets and Python will certainly rise the distribution of the program. The prototype code is already working. Its advantages in modelling, price and extending makes GRASS a strong alternative to other GIS software. The increasing popularity will lead into an increasing development of the software. More people will contribute to the source code, bugtracking and documentation.
GRASS has some innovative functions already implemented (e. g. functions for network analysis like shortest path, route planing), waiting for new applications to be developed on top. For 3D modelling the infrastructure and moduls are in place for raster, vector and site data leading to an increasing usage in spatial modelling.

==== Cross References ====
1. Quantum GIS ?

2. PostGIS?

3. UMN Map Server ?

4. Open GIS Consortium

==== Recommended Reading (5 - 15 entries) ====
* Neteler, M. & Mitasova, H. (2004): Open Source GIS: A Grass GIS Approach. 2nd Edition. Boston.<BR>(of course)

* GRASS GIS 6.0 Tutorial. GDF Hannover bR (2005). Version 1.2, 149 pages.<BR>http://www.gdf-hannover.de/media.php?id=0&lg=en

* GRASS Newsletters [http://grass.itc.it/newsletter/index.php]

* Lo, C.P. & Yeung, A.K.W. Concepts and Techniques of Geographic Information Systems Prentice Hall, 2006

* Robinson, A.H.; Morrison, J.L.; Muehrcke, P.C. & Guptil, S.C. Elements of Cartography John Wiley and Sons, 1995

* Haverland, G. (1999): Precision Farming and Linux: An Expose. Linux Journal.

* GRASS Programmer Manual (http://grass.itc.it/devel/index.php#prog)

==== Aditional definitions ====
If there are some definition in our text which would be worse mentioned in the Encyclopaedia...

=== Contact & Coordination===
<pre>
Malte Halbey-Martin
Free University Berlin
Dept. of Geosciences
Inst. of Geogr. Sciences
Malteserstr. 74-100
D-12249 Berlin, Germany
===============
tel: +49.30.83870409
fax: +49.30.83870755
email: malte at geog.fu-berlin.de
online: www.geog.fu-berlin.de/~malte
</pre>
=== Springer contact ===
<pre>
Jennifer Carlson / Andrea Schmidt
Development Editors
Springer
233 Spring Street
New York, NY 10016
===============
tel: 212.460.1666
fax: 212.460.1594
email: jennifer.carlson at springer.com
online: www.springer.com
</pre>

<pre>
Andreas Neumann <neumann at karto.baug.ethz.ch>
Institute of Cartography
ETH Zurich
Wolfgang-Paulistrasse 15
CH-8093 Zurich, Switzerland

Phone: ++41-44-633 3031, Fax: ++41-44-633 1153
e-mail: neumann at karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
</pre>

About GRASS

2006-12-12T22:50:46Z

⚠️DylanBeaudette: /* Soil Science */

This wiki page is initially for organizing the writing of a GRASS entry for the "''Springer Encyclopedia of GIS''", in future this wiki page will contain the article itself.

=== The entry structure ===
The Structure of the entry is given by springer. I received a .tex file which I fill with the text when this text is reviewd by the community (and my wife because she's an english teacher :-)).

=== Inspiration ===

* The Wikipedia entry (GNU Free Documentation License; probably '''do not reuse''' any content)<BR>http://en.wikipedia.org/wiki/GRASS_GIS

=== Issues ===

* Who owns the copyright for the article? Springer? The author(s)?
The Contract says:
The author hereby grants and assigns to Springer- Verlag the sole right to publish, distribute and sell... the contribution and parts thereof...

Springer verlag will take ... either in his own name or in that of the author any necessary steps to protect these rights against infringement by third parties. It will have the copyright notice inserted into all editions of the work according to the provisions of the Universal Copyright Convention and dutifully take care of all formalities in this connections, either in its own name or in that of the author.

* Should the article be wholly original or can it be derived (cut and pasted) from existing GRASS texts (e.g. the GRASS logo; website content)?
I supose we should write something new and shouldn't cut & paste because of the following point.

* If cut&pasted, does that put the existing GRASS website text etc at risk? (let's avoid a Eric Weisstein's MathWorld vs. CRC Press style nightmare [http://mathworld.wolfram.com/about/erics_commentary.html])
see above

* Can we reuse the text? (e.g. publish it here on the wiki or as an article in a future GRASSNews newsletter)
I will ask the people at springer

=== What needs to be done? ===
The deadline is something about 'late december, after Christmas'

the entry should be 8-12 pages - here is an example:
http://refworks.springer.com/mrw/fileadmin/pdf/GIS/VoronoiEncy

Here is some additional information:
http://refworks.springer.com/geograph/

Here are the templates:
http://refworks.springer.com/geograph/

And here is a list of other entries (as of 2006-11-21)
http://www.carto.net/neumann/temp/gis_encyclopedia_toc.pdf

=== The Entry ===

* screenshots needed? if so, how many?
* no limit, but I think we shouldn't include more than 3
* I would suggest some screenshots with 3d vector and 3d raster

==== Title: ====
GRASS

==== Author ====
Malte Halbey-Martin, Inst. of Geogr. Sciences, Free University Berlin, Germany

''Please put your name here when you have written something''

==== Synonyms ====
Geographic Resources Analysis Support Software, GRASS- GIS
(Geographic Information System)

==== Definition (fewer than 250 words)====
GRASS- GIS (Geographic Resources Analysis Support Software) is a GIS- software for geospatial analyses and modelling which has the capability to manage raster and vectordata. Additionally it supports three dimensional modelling with 3D raster voxel or 3D vector data and contains several image processing modules to manipulate remote sensing data. It comes along with visualization tools and interacts with other related software packages e. g. R- language, gstat and Quantum GIS. GRASS supports a variety of GIS formats due to the usage of the GDAL/OGR library. It also supports the OGC- conformal Simple Features.It can connect to databases via ODBC and supports spatial databases like PostGIS. GRASS datasets can be published on the internet with the UMN Mapserver.

The software is published under the conditions of the GNU General Public Licence (GPL) so anyone can see the source code, the internal structure of the program and the algorithms which are used. Every user can improve, modify, or extend GRASS for his own needs. A striking advantage of the program is that no licence fees have to be paid because of the terms of the GPL. Programmers all over the world contribute to the software. It is one of the biggest Open Source projects in the world (more than one million lines of source code).
GRASS runs on a variety of platforms like GNU/Linux, MS- Windows, MacOS X and POSIX compliant systems. It is completly written in C although a Java version also exist (JGRASS).

==== Historical Background (fewer than 500 words) ====
The history of GRASS reaches back until the early eighties. Initially GRASS was developed by the U.S. Army Construction Engineering Research Laboratory (CERL), Champaign, Illinois since 1982 due to the need of new landmanagement and environmental planing tools for military installations. The emphasis was taken on raster analyses and image processing, because the aim of the analyses were the estimatation of the impact of actions on continous surfaces like elevation or soils(Neteler & Mitasova 2004) and there were no adequate raster GIS software on the market at that time. Modules for vector processing were added later.

The first version of GRASS was released in 1984 (Vanderfelt 1994). The source code was completely published on the Internet during the late eighties which brought a significant input into the development of GRASS. The CERL withdrew from GRASS development in 1995. An international developer team overtook this task and in 1997 GRASS 4.2 was published by the Baylor University, Waco Texas, USA and GRASS 4.2.1 from the Institute of Physical Geography and Landscape Ecology, University of Hannover, Germany in 1999 under the terms of the GPL. In 1999 the work at version 5.0 were started and the headquarter of the "GRASS Developer Team" moved to the Instituto Trentino di Cultura (ITC-irst), Trento, Italy. GRASS 5.0 was released in 2002, version 6.0 in March 2005. The current stable version is 6.2 which was released at the end of October 2006 (http://grass.itc.it/devel/grasshist.html).

''Tabelle Vanderfelt 1994???''

''maybe we should add some mayor steps of the development...''

''see GRASS history page: http://grass.itc.it/devel/grasshist.html''

==== Scientific fundamentals ====
===== Philosophy of GRASS =====

The most distinguishing feature of GRASS in comparison to other GIS- software is that the source code can be explored without any restrictions so everyone can study the algorithms which are used. This open structure allows everybody to contribute to the source code to improve GRASS or to extend it for his own needs. For this purpose GRASS provides a GIS- library and a free Programming Manual, which can be downloaded from the GRASS- project site (www.grass-irc.it). Therefore the user has full control of the analyses he does. Besides this point the GPL protects the contributing people of using their code in proprietary software where no free access to the source code is granted. Following the terms of the GPL all code which is based on GPL licensed code must be published again under the GPL (cite GPL?).

GRASS offers the user the whole range of GIS functions and together with other (free) software tools it provides a complete and powerful GIS software infrastructure for low costs.

===== Programming and extending GRASS =====
''I wonder if I'm the right person to write that because of the lack of programming skills''

GRASS is written in C and comes along with a sophisticated and well documented C / C++ API (Cite Programming Manual). As a side effect of the open source philosophy the user has the ability to learn how to develope own applications from existing modules by exploring their source code.

Besides that options GRASS owns the possibility to call the functions already implememented in GRASS with high level programming languages like Python. For that purpose a GRASS-SWIG interface is available which translates ANSI C / C++ declarations into multiple languages (Python, Perl). It contains also an integrated parser for scripting languages.

For easy creation of GRASS extensions it comes along with a extension manager so no source code is needed to build additional GRASS modules. To automate repeating tasks in GRASS shell scripts can be written.

===== Interoperability: GIS and Analysis Toolchain =====
GRASS is designed the way that it offers a highly and robust interoperability with outside applications, giving the user tremendous flexibility and efficiency for accomplishing analyses.

====== Relational Database Systems ======
GRASS can directly connect to relational database management systems (RDBMS) like SQlite, MySQL and PostgreSQL. It even supports PostGIS, the spatial extension of PostgreSQL. To other external RDBMS GRASS offers the connection via the ODBC driver (cite GRASS Manual). A way to connect to an Oracle (? / Spatial ?) database is described by Mitasova, Neteler & Holl (http://www.oracle.com/technology/pub/articles/mitasova-grass.html).

* <strike>Oracle</strike> (there is no direct Oracle driver in GRASS)

''I thought it would be important for GIS users to know, that there's the possibility to connect to oracle...''
''is this accomplished through GDAL ?''
''when I got it right from the article above one has to compile GDAL/ogr from source with OCI bindings...''

====== Statistical Analysis ======
For statistic analyses of geodatasets R (a statistic environment, further explanation see www.r-project.org) can be called within a GRASS session. Another software to perform geostatic procedures is gstat. For both software packages GRASS interfaces exist. Therefore gstat and R can directly use GRASS raster- and vector datasets and will do their calculations in the spatial region definied in GRASS. This combination offers a high potential for geostatistic analysis as shown by Bivand (2000) and Bivand & Neteler (2000). GRASS can import and export Matlab binary (.mat) files (version 4) for processing numeric calculations outside GRASS.

====== Interoperability with other GIS Software ======
GRASS supports nearly all common GIS file formats to allow the user to use other GIS applications or external datasources because of its binding to the GDAL/OGR library and the support of the OGC Simple Features. Therefore the data excange between various applications and between several user is easy. The database ('''clarify differences between RDBMS''') structure implemented in GRASS, coupled with UNIX-style permissions and file locks, allows concurrant access to any given project. In this way, several individuals can share the resources of a single machine and dataset. GRASS works closly together with Quantum GIS. GRASS modules are accessible through a GRASS plugin in Quantum GIS.

====== 2D and 3D Visualization ======
While GRASS comes with fully functional 2D cartography and 3D visualization software (NVIZ), it interacts with other software tools to produce maps or to visualize geographic data sets. GRASS contains exportfilter for Generic Mapping Tool (GMT) files and various image formats so maps can be generated with external image manipulating programs.

For 3D visualization of 3D vector and raster datasets GRASS can export them in VTK (Visualization ToolKit) files which can be viewed in Paraview and script files for Povray, a raytracer to design 3D graphics. Aditional VRML (Virtual Reality Modeling Language) files can be created. Animations can be build with NVIZ or the external programs mentioned above.

====== Web Mapping ======
The UMN Mapserver can connect to GRASS and can read GRASS geodatasets directly. With the help of PyWPS (Python Web Processing Service, an implementation of the Web Processing Service standard from the Open Geospatial Consortium) GRASS modules are accessible via web interfaces easily. Thereby GRASS can serve as a backbone in WebGIS applications.

==== Key applications ====
GRASS is currently used around the world in academic and commercial settings as well as by many govermental agencies and environmental consulting companies. Due to the variety of spatial data and application fields this selection just gives an overview of applications where GRASS was adopted.

===== Archaeology =====

* Benjamin Ducke
* Mark Lake

===== Biology =====

Tucker et al (1997) used GRASS to model the bird distribution of three bird species in north-east England using a Bayesian rule-based approach. They linked data about habitat preferences and life-histry of the birds against physiogeographic and satellite data using GRASS.

For the Iberian Peninsula Garzon et al 2006 have used GRASS to model the potential area of Pinus Sylvestris. They predict the habitat suitability with a machine learning software suite in GRASS GIS. They incorporated three machine learning technics (Tree-based Classification, Neural Networks and Random Forest). All three models show a larger potential area of P. sylvestris as the present one. In the Rocky Mountains National Park tree population parameters have been modeled by Baker et al 1997 for the forest-tundra ecotone.

===== Environmental Modelling =====

===== Geography (Human / Physical) =====

===== Geology / Planetary Geology =====

Kajiyama et al 2004 and Masumoto et al used GRASS to derive 3D geological models in Japan. Kajiyama et al used a Digital elevation model (DEM) and a logical model of the geological structure to derive the surface boundaries of each geologic structure in the study area. From these data they built a 3D geological model.

GRASS has been also used in planetary geology. Frigeri et al identified Wrinkle Ridges on Mars which can be an evidence of existing subsurface ice on the planet. They used Mars MGS and data from the Viking Mission. The mapping of geologic features from Mars data is done by Deuchler et al (2004). The ability to import the raw data from various Mars datasets and to reproject them in easy way is seen as a great benefit by the authors of this survey. The authors detected tectonic surface faults and assigned them to a geologic Mars region.

===== Geomorphology \ Geomorphometry =====
* Analysis of mountainous terrain (Carlos Henrique Grohmann Computers & Geosciences, 30 (9-10):1055-1067)
* Landscape / landform classification (Bivand, R. Integrating GRASS 5.0 and R: GIS and modern statistics Computers & Geosciences, 2000, 26, 1043–1052.)

===== Geostatistics =====
* gstat
* R (see article in GRASS Newsletter vol 3)

===== Hydrologic Modelling =====

===== Hydrographic Surveys (nautical) =====

===== Landscape epidemiology and public health =====

===== Network analysis =====

===== Planning =====

===== Precision Farming =====
* Haverland
* Goddard et al

===== Remote Sensing =====

===== Soil Science =====
* Three-dimensional Rule-based Continuous Soil Modelling (Martin Ameskamp PhD thesis)
* Landscape scale modeling of soil properties (Dylan Beaudette [in progress])
* Numerical evaluation of ''aspect effect'' with r.sun (Dylan Beaudette [in progress])

===== Education =====

==== Future directions ====
The development of GRASS as a native Windows application and the building of a new unified Graphical User Interface for Linux, Mac, Windows and Unix using WxWidgets and Python will certainly rise the distribution of the program. The prototype code is already working. Its advantages in modelling, price and extending makes GRASS a strong alternative to other GIS software. The increasing popularity will lead into an increasing development of the software. More people will contribute to the source code, bugtracking and documentation.
GRASS has some innovative functions already implemented (e. g. functions for network analysis like shortest path, route planing), waiting for new applications to be developed on top. For 3D modelling the infrastructure and moduls are in place for raster, vector and site data leading to an increasing usage in spatial modelling.

==== Cross References ====
1. Quantum GIS ?

2. PostGIS?

3. UMN Map Server ?

4. Open GIS Consortium

==== Recommended Reading (5 - 15 entries) ====
* Neteler, M. & Mitasova, H. (2004): Open Source GIS: A Grass GIS Approach. 2nd Edition. Boston.<BR>(of course)

* GRASS GIS 6.0 Tutorial. GDF Hannover bR (2005). Version 1.2, 149 pages.<BR>http://www.gdf-hannover.de/media.php?id=0&lg=en

* GRASS Newsletters [http://grass.itc.it/newsletter/index.php]

* Lo, C.P. & Yeung, A.K.W. Concepts and Techniques of Geographic Information Systems Prentice Hall, 2006

* Robinson, A.H.; Morrison, J.L.; Muehrcke, P.C. & Guptil, S.C. Elements of Cartography John Wiley and Sons, 1995

* Haverland, G. (1999): Precision Farming and Linux: An Expose. Linux Journal.

* GRASS Programmer Manual (http://grass.itc.it/devel/index.php#prog)

==== Aditional definitions ====
If there are some definition in our text which would be worse mentioned in the Encyclopaedia...

=== Contact & Coordination===
<pre>
Malte Halbey-Martin
Free University Berlin
Dept. of Geosciences
Inst. of Geogr. Sciences
Malteserstr. 74-100
D-12249 Berlin, Germany
===============
tel: +49.30.83870409
fax: +49.30.83870755
email: malte at geog.fu-berlin.de
online: www.geog.fu-berlin.de/~malte
</pre>
=== Springer contact ===
<pre>
Jennifer Carlson / Andrea Schmidt
Development Editors
Springer
233 Spring Street
New York, NY 10016
===============
tel: 212.460.1666
fax: 212.460.1594
email: jennifer.carlson at springer.com
online: www.springer.com
</pre>

<pre>
Andreas Neumann <neumann at karto.baug.ethz.ch>
Institute of Cartography
ETH Zurich
Wolfgang-Paulistrasse 15
CH-8093 Zurich, Switzerland

Phone: ++41-44-633 3031, Fax: ++41-44-633 1153
e-mail: neumann at karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
</pre>

GRASS Education (Free GIS education)

2006-12-10T01:55:37Z

⚠️DylanBeaudette: /* Tutorials */

__TOC__

Please modify current topics and content and/or add your own ideas and contributions

== Teaching Concepts ==

* [[Gis_Concepts|Basic GIS concepts]]
* [[GRASS_Help#First_Day_Documentation | GRASS First-day documentation ]]

== Teaching Materials ==

=== Seminars & Presentations ===

* GIS seminar: The GRASS GIS software at Politecnico di Milano, Polo Regionale di Como, 30 May 2006 (6h). Introduction to GRASS 6 and QGIS ([http://mpa.itc.it/markus/como2006/index.html Slides PDF/ODP/HTML])

* [http://wiki.osgeo.org/index.php/Library OSGeo Library]: Presentations and educational material

=== Tutorials ===

* [[Import NoaaEnc]] Mini-tutorial

* [http://www.star.ait.ac.th/~yann/star Tutorials by Yann Chemin]: Small tutorials to get started in GRASS GIS and GRASS integration with QGIS.
** [http://rslultra.star.ait.ac.th/~yann/star/GMS_training.pdf GMS Training Manual] (PDF, 4.3mb), covering:
*** QGIS introduction
*** QGIS GRASS plugin
*** GRASS GIS introduction
*** GRASS GIS DEM manipulations
*** GRASS GIS habitat analysis exercise

* [http://casoilresource.lawr.ucdavis.edu/drupal/node/95 Several Tutorials and Examples] mostly related toward soil science and hydrology

=== Workshops ===

* [[GRASS_related_workshops_and_presentations]] held at Lausanne, Switzerland, September 12-15th 2006

=== Training Videos ===

* GRASS 6.3 feature tour:<BR>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/grass63feature_tour.html
* The GRASS startup screen (select or create location, mapset,..) '''[TODO]'''
* Using the gis.m GUI '''[TODO]'''

==== How to create them ====

* A short vnc2swf usage tutorial is available here:<BR>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/vnc2swf_usage.html

Soeren used [http://www.unixuser.org/~euske/vnc2swf/ vnc2swf] to record that flash movie.

The installation is easy if you have a Linux dist which provides all
needed python packages (pyGames and others I don't remember).

You would need a VNC-Server installed (not too tricky normaly). The installation of vnc is easy. There are a lot of free vncserver and
clients out there in the internet.

'''[list some here]'''

To record a vnc session is not very complicated:
* First you have to run a vnc server and the client.
* The next step is to start vnc2swf.py with the address of the vncserver and a file name.

== See Also ==

* [http://wiki.osgeo.org/index.php/Education_Committee_Work_Program OSGeo.org Education Committee Work Program]

== Technical Aspects ==

== Current Restrictions ==

People want to upload their course material including PDFs, powerpoint presentations, Flash tutorial movies, course material, lecture notes,
etc.. Because this wiki only supports text and simple graphics files, we have to find a solution to enable password controlled upload of large files. For this reason it is necessary to provide a decicated general Free-GIS education server to support GRASS and Free GIS teaching and education efforts.

From our point of view a natural home for Free-GIS-Edu documentation, video tutorials, presentations, PDFs, etc. could be:

* [http://wald.intevation.org Intevation's Gforge server]
* [https://www.osgeo.org OSGeo Server]
* [http://freegis.org Intevation's FreeGIS.org]

GRASS Education (Free GIS education)

2006-12-10T01:55:19Z

⚠️DylanBeaudette: /* Tutorials */

__TOC__

Please modify current topics and content and/or add your own ideas and contributions

== Teaching Concepts ==

* [[Gis_Concepts|Basic GIS concepts]]
* [[GRASS_Help#First_Day_Documentation | GRASS First-day documentation ]]

== Teaching Materials ==

=== Seminars & Presentations ===

* GIS seminar: The GRASS GIS software at Politecnico di Milano, Polo Regionale di Como, 30 May 2006 (6h). Introduction to GRASS 6 and QGIS ([http://mpa.itc.it/markus/como2006/index.html Slides PDF/ODP/HTML])

* [http://wiki.osgeo.org/index.php/Library OSGeo Library]: Presentations and educational material

=== Tutorials ===

* [[Import NoaaEnc]] Mini-tutorial

* [http://www.star.ait.ac.th/~yann/star Tutorials by Yann Chemin]: Small tutorials to get started in GRASS GIS and GRASS integration with QGIS.
** [http://rslultra.star.ait.ac.th/~yann/star/GMS_training.pdf GMS Training Manual] (PDF, 4.3mb), covering:
*** QGIS introduction
*** QGIS GRASS plugin
*** GRASS GIS introduction
*** GRASS GIS DEM manipulations
*** GRASS GIS habitat analysis exercise

* [http://casoilresource.lawr.ucdavis.edu/drupal/node/95 Several Tutorials and Examples] mostly geard toward soil science

=== Workshops ===

* [[GRASS_related_workshops_and_presentations]] held at Lausanne, Switzerland, September 12-15th 2006

=== Training Videos ===

* GRASS 6.3 feature tour:<BR>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/grass63feature_tour.html
* The GRASS startup screen (select or create location, mapset,..) '''[TODO]'''
* Using the gis.m GUI '''[TODO]'''

==== How to create them ====

* A short vnc2swf usage tutorial is available here:<BR>http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/vnc2swf_usage.html

Soeren used [http://www.unixuser.org/~euske/vnc2swf/ vnc2swf] to record that flash movie.

The installation is easy if you have a Linux dist which provides all
needed python packages (pyGames and others I don't remember).

You would need a VNC-Server installed (not too tricky normaly). The installation of vnc is easy. There are a lot of free vncserver and
clients out there in the internet.

'''[list some here]'''

To record a vnc session is not very complicated:
* First you have to run a vnc server and the client.
* The next step is to start vnc2swf.py with the address of the vncserver and a file name.

== See Also ==

* [http://wiki.osgeo.org/index.php/Education_Committee_Work_Program OSGeo.org Education Committee Work Program]

== Technical Aspects ==

== Current Restrictions ==

People want to upload their course material including PDFs, powerpoint presentations, Flash tutorial movies, course material, lecture notes,
etc.. Because this wiki only supports text and simple graphics files, we have to find a solution to enable password controlled upload of large files. For this reason it is necessary to provide a decicated general Free-GIS education server to support GRASS and Free GIS teaching and education efforts.

From our point of view a natural home for Free-GIS-Edu documentation, video tutorials, presentations, PDFs, etc. could be:

* [http://wald.intevation.org Intevation's Gforge server]
* [https://www.osgeo.org OSGeo Server]
* [http://freegis.org Intevation's FreeGIS.org]

GRASS Citation Repository

2006-12-10T01:51:16Z

⚠️DylanBeaudette: /* Helpful tools */

'''Preferred format:''' [http://en.wikipedia.org/wiki/BibTeX BibTeX]

'''How to cite GRASS GIS:'''

Please cite GRASS when using the software in your work. Here are some choices depending on the version used:

* GRASS Development Team, 2006. Geographic Resources Analysis Support System (GRASS) Software. ITC-irst, Trento, Italy. http://grass.itc.it
* GRASS Development Team, 2006. Geographic Resources Analysis Support System (GRASS) Programmer's Manual. ITC-irst, Trento, Italy. Electronic document: http://grass.itc.it/devel/index.php
* GRASS Development Team, 2005. GRASS 6.0 Users Manual. ITC-irst, Trento, Italy. Electronic document: http://grass.itc.it/grass60/manuals/html_grass60/
* GRASS Development Team, 2002. GRASS 5.0 Users Manual. ITC-irst, Trento, Italy. Electronic document: http://grass.itc.it/gdp/html_grass5/
* U.S. Army CERL, 1993. GRASS 4.1 Reference Manual. U.S. Army Corps of Engineers, Construction Engineering Research Laboratories, Champaign, Illinois, 1-425.

BibTeX entry:
<pre>
@Manual{GRASS_GIS_software,
title = {Geographic Resources Analysis Support System (GRASS GIS) Software},
author = {{GRASS Development Team}},
organization = {ITC-irst},
address = {Trento, Italy},
year = {2006},
url = {http://grass.itc.it},
}
</pre>

* [[Citations for specific modules]]

* Citations of [[GRASS in the wild]] (add your publications here)

* Newsletter citations
** [[Newsletter citations Vol1]]
** [[Newsletter citations Vol2]]
** [[Newsletter citations Vol3]]
** [[Newsletter citations Vol4]]

* [[Historical citations]]

* Master file of all citations for download ''(todo once we have collected enough)''

==== Helpful tools ====
* [http://scholar.google.com Google Scholar] - [http://scholar.google.com/scholar?q=GRASS+GIS Search for "GRASS GIS"]
* [http://www.citeulike.org CiteULike] - [http://www.citeulike.org/search/all?f=abstract&q=grass+gis Search for "GRASS GIS"]
* [http://www.scripps.edu/~cdputnam/software/bibutils/ Bibutils] bibliography conversion utilities
* [http://gbib.seul.org Gbib BibTeX editor] for GTK+Gnome
* [http://jabref.sourceforge.net/ JabRef] Multi-platform, multi-format bibliography tool

[[Category:Documentation]]

Tips and Tricks

2006-12-10T01:48:22Z

⚠️DylanBeaudette: /* Exporting GRASS maps to GMT */

==Tips and Tricks==

===Using QGIS as a frontend to GRASS===

QGIS can run as a frontend to GRASS. There is support for displaying maps, editing maps, and execution of simple GIS functions. The GDAL/OGR library is a requirement for that (but for GRASS anyway):

* QGIS homepage: http://qgis.org
* GDAL homepage: http://www.gdal.org

To use the two together, the GDAL-GRASS plugin must be installed:

* [[Compile and install GRASS and QGIS with GDAL/OGR Plugin]]

Test that the GDAL-GRASS plugin is available with this command:<BR>
<pre>
gdalinfo --formats
</pre>
Look for a line like "GRASS (ro): GRASS Database Rasters (5.7+)"

Enable the QGIS GRASS plugin from QGIS: <br>
<pre>
GUI: Plugins / Plugin Manager / Check the GRASS checkbox
</pre>

The GRASS toolbar should now be visible.
While not a firm requirement, it is easier to start QGIS from within a GRASS session.

* [http://wiki.qgis.org/qgiswiki/GrassCookbook QGIS GRASS Cookbook] - Recipes for common tasks

===Importing SRTM30plus data===

SRTM30plus data consists of 33 files of global topography in the same format as the SRTM30 products distributed by the USGS EROS data center. The grid resolution is 30 second which is roughly one kilometer.

Land data are based on the 1-km averages of topography derived from the USGS SRTM30 grided DEM data product created with data from the NASA Shuttle Radar Topography Mission. GTOPO30 data are used for high latitudes where SRTM data are not available.

Ocean data are based on the Smith and Sandwell global 2-minute grid between latitudes +/- 72 degrees. Higher resolution grids have been added from the LDEO Ridge Multibeam Synthesis Project and the NGDC Coastal Relief Model. Arctic bathymetry is from the International Bathymetric Chart of the Oceans (IBCAO).

All data are derived from public domain sources and these data are also in the public domain.

GRASS 6 script <code>r.in.srtm</code> described in GRASSNews vol. 3 won't work with this dataset (as it was made for the original SRTM HGT files). But you can import SRTM30plus tiles into GRASS this way:

r.in.bin -sb input=e020n40.Bathmetry.srtm output=e020n40_topex bytes=2 north=40 south=-10 east=60 west=20 r=6000 c=4800
r.colors e020n40_topex rules=etopo2

; Source
: GRASS Users Mailing List http://grass.itc.it/pipermail/grassuser/2005-August/030018.html
; Getting SRTM30plus tiles
: ftp://topex.ucsd.edu/pub/srtm30_plus/data

===Exporting GRASS maps to GMT===

GMT (Generic Mapping Tools) is a Free software package for creating publication quality cartography.

GMT homepage: http://gmt.soest.hawaii.edu

Exporting GRASS maps to GMT: http://169.237.35.250/~dylan/grass_user_group/#GMT_and_GRASS-overview
<BR>(Supplied by the GRASS Users Group of Davis, California)

Currently there are several *.out.GMT permutations, several in different languages (bash, python, etc.), and each of which with relative pros/cons. An effort to unify these approaches would save much of the current difficulties in moving complex raster+vector data into a GMT-friendly format. A simple road map toward this goal is outlined:

====Proper conversion of GRASS raster color data into GMT compatible CPT files====
David Finlayson's [http://david.p.finlayson.googlepages.com/gisscripts r.out.gmt.py] does a nice job of this. Once we decide on an optimal language to implement the routines in this may need translation.

====Proper conversion of GRASS raster data to GMT compatible binary grids====
A combination of r.out.bin | xyz2grd can accomplish this. Several attempts at generalizing this procedure have been proposed: [http://david.p.finlayson.googlepages.com/gisscripts r.out.gmt.py], [http://bambi.otago.ac.nz/hamish/grass/r.out.gmt r.out.gmt] (Hamish and Dylan), [http://169.237.35.250/~dylan/grass_user_group/r.out.gmt.sh r.out.gmt.sh] (Dylan, based Hamish's work).

====Proper conversion of GRASS vector data to GMT compatible ascii files====
There is currently an effort (with some funding!), see some of the chatter on the GRASS and GMT mailing lists:
[http://grass.itc.it/pipermail/grassuser/2006-April/033659.html GRASS-list]
[http://www.nabble.com/Ideas-needed-regarding-OGR-reformatter-for-GMT-vector-(point-multiline)-files.-t2605255.html GMT-help]

====Automatic conversion of symbology data stored in a gis.m or QGIS saved state to GMT options====
Ideas expressed on various mailing list, haven't seem much since. It ''should'' be a relatively simple excercise in XML parsing to convert symbology stored in a QGIS project file into something that GMT can use.

====General approach====
Since GMT relies on a sequence of specialized programs to "build-up" a postscript file, some thought must be put into how the conversion should take place. As usual, form should follow function- maximum flexibility, robustness, and accuracy being primary objectives. However, a simple means of creating high quality 2D maps would be a tremendous (I think) addition to the GRASS toolset. Especially since this is something frequently cited by critics. --[[User:DylanBeaudette|DylanBeaudette]] 02:47, 10 December 2006 (CET)

1. should we continue down the well troden path of single-use, highly efficient programs for the various conversion steps: i.e v.out.GMT, r.out.GMT, etc.?

2. should there be a unified approach to the process: something akin to ps.map - ''GMT.map'' ?

===Interfacing R-Statistics with GRASS===

* All the necessary functions for the GRASS 6 interface are now in packages on CRAN, so that on Linux/Unix (or Mac OSX) installing rgdal from source with PROJ4 and GDAL installed, or Windows installing from binary, the required packages are: sp; maptools (now includes spmaptools); rgdal (now includes spGDAL, spproj); spgrass6 - now all on CRAN.

* http://grass.ibiblio.org/statsgrass/index.php#grassR

* R-Statistics homepage http://www.r-project.org

* R Spatial Projects http://sal.uiuc.edu/csiss/Rgeo//

* http://r-spatial.sourceforge.net/xtra/xtra.RHnw.html#spgrass6

* Neural Networks with GRASS and R (posted by Markus Neteler on the grass-user mailing list) http://www.uam.es/proyectosinv/Mclim/pdf/MBenito_EcoMod.pdf

* Using R and GRASS with cygwin: It is possible to use Rterm inside the GRASS shell in cygwin, just as in Unix/Linux or OSX. You should not, however, start Rterm from a cygwin xterm, because Rterm is not expecting to be run in an xterm under Windows, and loses its input. If you use the regular cygwin bash shell, but need to start display windows, start X from within GRASS with startx &, and then start Rterm in the same cygwin shell, not in the xterm.

===Using GRASS with an on-line Web-GIS===

see:

* [[GRASS and MapServer]]
* [[GRASS and PHP]]
* [[GRASS and Python]]

(please expand)

===Starting and running GRASS from a script===

See [[GRASS and Shell]].

===Running GRASS remotely on OS X===

Tiger (OS 10.4) changed the default configuration of SSH from previous versions of OS X. You can no longer start an ssh session with the -X flag and display the Tcl/Tk components of the GRASS GUI remotely. If you are running grass on OS X (10.4) between hosts on a network (i.e. running it on one machine but displaying it on another), you will need to use the "trusted forwarding" mode of SSH in order for the Tcl/Tk generated graphics, such as d.m or gis.m in order for the GUI graphics to make it through your connection. This can be done using the -Y flag when you start the ssh session:

ssh -Y remotehost

or add this to ~/.ssh/config:

Host hostname
ForwardX11 yes
ForwardX11Trusted yes

Using the -X flag, or simply turning on X11Forwarding in the SSH configuration files, is not enough: the symptoms in this case are that a d.mon window will function fine, but none of the Tcl/Tk dialogues will work, failing with an error message complaining either about Wish not behaving as expected, or a "Bad Atom".

[[Category:Documentation]]

Tips and Tricks

2006-12-10T01:48:02Z

⚠️DylanBeaudette: /* General approach */

Tips and Tricks

2006-12-10T01:47:38Z

⚠️DylanBeaudette: /* Exporting GRASS maps to GMT */

==Tips and Tricks==

===Using QGIS as a frontend to GRASS===

QGIS can run as a frontend to GRASS. There is support for displaying maps, editing maps, and execution of simple GIS functions. The GDAL/OGR library is a requirement for that (but for GRASS anyway):

* QGIS homepage: http://qgis.org
* GDAL homepage: http://www.gdal.org

To use the two together, the GDAL-GRASS plugin must be installed:

* [[Compile and install GRASS and QGIS with GDAL/OGR Plugin]]

Test that the GDAL-GRASS plugin is available with this command:<BR>
<pre>
gdalinfo --formats
</pre>
Look for a line like "GRASS (ro): GRASS Database Rasters (5.7+)"

Enable the QGIS GRASS plugin from QGIS: <br>
<pre>
GUI: Plugins / Plugin Manager / Check the GRASS checkbox
</pre>

The GRASS toolbar should now be visible.
While not a firm requirement, it is easier to start QGIS from within a GRASS session.

* [http://wiki.qgis.org/qgiswiki/GrassCookbook QGIS GRASS Cookbook] - Recipes for common tasks

===Importing SRTM30plus data===

SRTM30plus data consists of 33 files of global topography in the same format as the SRTM30 products distributed by the USGS EROS data center. The grid resolution is 30 second which is roughly one kilometer.

Land data are based on the 1-km averages of topography derived from the USGS SRTM30 grided DEM data product created with data from the NASA Shuttle Radar Topography Mission. GTOPO30 data are used for high latitudes where SRTM data are not available.

Ocean data are based on the Smith and Sandwell global 2-minute grid between latitudes +/- 72 degrees. Higher resolution grids have been added from the LDEO Ridge Multibeam Synthesis Project and the NGDC Coastal Relief Model. Arctic bathymetry is from the International Bathymetric Chart of the Oceans (IBCAO).

All data are derived from public domain sources and these data are also in the public domain.

GRASS 6 script <code>r.in.srtm</code> described in GRASSNews vol. 3 won't work with this dataset (as it was made for the original SRTM HGT files). But you can import SRTM30plus tiles into GRASS this way:

r.in.bin -sb input=e020n40.Bathmetry.srtm output=e020n40_topex bytes=2 north=40 south=-10 east=60 west=20 r=6000 c=4800
r.colors e020n40_topex rules=etopo2

; Source
: GRASS Users Mailing List http://grass.itc.it/pipermail/grassuser/2005-August/030018.html
; Getting SRTM30plus tiles
: ftp://topex.ucsd.edu/pub/srtm30_plus/data

===Exporting GRASS maps to GMT===

GMT (Generic Mapping Tools) is a Free software package for creating publication quality cartography.

GMT homepage: http://gmt.soest.hawaii.edu

Exporting GRASS maps to GMT: http://169.237.35.250/~dylan/grass_user_group/#GMT_and_GRASS-overview
<BR>(Supplied by the GRASS Users Group of Davis, California)

Currently there are several *.out.GMT permutations, several in different languages (bash, python, etc.), and each of which with relative pros/cons. An effort to unify these approaches would save much of the current difficulties in moving complex raster+vector data into a GMT-friendly format. A simple road map toward this goal is outlined:

====Proper conversion of GRASS raster color data into GMT compatible CPT files====
David Finlayson's [http://david.p.finlayson.googlepages.com/gisscripts r.out.gmt.py] does a nice job of this. Once we decide on an optimal language to implement the routines in this may need translation.

====Proper conversion of GRASS raster data to GMT compatible binary grids====
A combination of r.out.bin | xyz2grd can accomplish this. Several attempts at generalizing this procedure have been proposed: [http://david.p.finlayson.googlepages.com/gisscripts r.out.gmt.py], [http://bambi.otago.ac.nz/hamish/grass/r.out.gmt r.out.gmt] (Hamish and Dylan), [http://169.237.35.250/~dylan/grass_user_group/r.out.gmt.sh r.out.gmt.sh] (Dylan, based Hamish's work).

====Proper conversion of GRASS vector data to GMT compatible ascii files====
There is currently an effort (with some funding!), see some of the chatter on the GRASS and GMT mailing lists:
[http://grass.itc.it/pipermail/grassuser/2006-April/033659.html GRASS-list]
[http://www.nabble.com/Ideas-needed-regarding-OGR-reformatter-for-GMT-vector-(point-multiline)-files.-t2605255.html GMT-help]

====Automatic conversion of symbology data stored in a gis.m or QGIS saved state to GMT options====
Ideas expressed on various mailing list, haven't seem much since. It ''should'' be a relatively simple excercise in XML parsing to convert symbology stored in a QGIS project file into something that GMT can use.

====General approach====
Since GMT relies on a sequence of specialized programs to "build-up" a postscript file, some thought must be put into how the conversion should take place. As usual, form should follow function- maximum flexibility, robustness, and accuracy being primary objectives. However, a simple means of creating high quality 2D maps would be a tremendous (I think) addition to the GRASS toolset. Especially since this is something frequently cited by critics. --[[User:DylanBeaudette|DylanBeaudette]] 02:47, 10 December 2006 (CET)

1. should we continue down the well troden path of single-use, highly efficient programs for the various conversion steps: i.e v.out.GMT, r.out.GMT, etc.?
2. should there be a unified approach to the process: something akin to ps.map - ''GMT.map'' ?

===Interfacing R-Statistics with GRASS===

* All the necessary functions for the GRASS 6 interface are now in packages on CRAN, so that on Linux/Unix (or Mac OSX) installing rgdal from source with PROJ4 and GDAL installed, or Windows installing from binary, the required packages are: sp; maptools (now includes spmaptools); rgdal (now includes spGDAL, spproj); spgrass6 - now all on CRAN.

* http://grass.ibiblio.org/statsgrass/index.php#grassR

* R-Statistics homepage http://www.r-project.org

* R Spatial Projects http://sal.uiuc.edu/csiss/Rgeo//

* http://r-spatial.sourceforge.net/xtra/xtra.RHnw.html#spgrass6

* Neural Networks with GRASS and R (posted by Markus Neteler on the grass-user mailing list) http://www.uam.es/proyectosinv/Mclim/pdf/MBenito_EcoMod.pdf

* Using R and GRASS with cygwin: It is possible to use Rterm inside the GRASS shell in cygwin, just as in Unix/Linux or OSX. You should not, however, start Rterm from a cygwin xterm, because Rterm is not expecting to be run in an xterm under Windows, and loses its input. If you use the regular cygwin bash shell, but need to start display windows, start X from within GRASS with startx &, and then start Rterm in the same cygwin shell, not in the xterm.

===Using GRASS with an on-line Web-GIS===

see:

* [[GRASS and MapServer]]
* [[GRASS and PHP]]
* [[GRASS and Python]]

(please expand)

===Starting and running GRASS from a script===

See [[GRASS and Shell]].

===Running GRASS remotely on OS X===

Tiger (OS 10.4) changed the default configuration of SSH from previous versions of OS X. You can no longer start an ssh session with the -X flag and display the Tcl/Tk components of the GRASS GUI remotely. If you are running grass on OS X (10.4) between hosts on a network (i.e. running it on one machine but displaying it on another), you will need to use the "trusted forwarding" mode of SSH in order for the Tcl/Tk generated graphics, such as d.m or gis.m in order for the GUI graphics to make it through your connection. This can be done using the -Y flag when you start the ssh session:

ssh -Y remotehost

or add this to ~/.ssh/config:

Host hostname
ForwardX11 yes
ForwardX11Trusted yes

Using the -X flag, or simply turning on X11Forwarding in the SSH configuration files, is not enough: the symptoms in this case are that a d.mon window will function fine, but none of the Tcl/Tk dialogues will work, failing with an error message complaining either about Wish not behaving as expected, or a "Bad Atom".

[[Category:Documentation]]

Tips and Tricks

2006-12-10T01:39:05Z

⚠️DylanBeaudette: /* Exporting GRASS maps to GMT */

==Tips and Tricks==

===Using QGIS as a frontend to GRASS===

QGIS can run as a frontend to GRASS. There is support for displaying maps, editing maps, and execution of simple GIS functions. The GDAL/OGR library is a requirement for that (but for GRASS anyway):

* QGIS homepage: http://qgis.org
* GDAL homepage: http://www.gdal.org

To use the two together, the GDAL-GRASS plugin must be installed:

* [[Compile and install GRASS and QGIS with GDAL/OGR Plugin]]

Test that the GDAL-GRASS plugin is available with this command:<BR>
<pre>
gdalinfo --formats
</pre>
Look for a line like "GRASS (ro): GRASS Database Rasters (5.7+)"

Enable the QGIS GRASS plugin from QGIS: <br>
<pre>
GUI: Plugins / Plugin Manager / Check the GRASS checkbox
</pre>

The GRASS toolbar should now be visible.
While not a firm requirement, it is easier to start QGIS from within a GRASS session.

* [http://wiki.qgis.org/qgiswiki/GrassCookbook QGIS GRASS Cookbook] - Recipes for common tasks

===Importing SRTM30plus data===

SRTM30plus data consists of 33 files of global topography in the same format as the SRTM30 products distributed by the USGS EROS data center. The grid resolution is 30 second which is roughly one kilometer.

Land data are based on the 1-km averages of topography derived from the USGS SRTM30 grided DEM data product created with data from the NASA Shuttle Radar Topography Mission. GTOPO30 data are used for high latitudes where SRTM data are not available.

Ocean data are based on the Smith and Sandwell global 2-minute grid between latitudes +/- 72 degrees. Higher resolution grids have been added from the LDEO Ridge Multibeam Synthesis Project and the NGDC Coastal Relief Model. Arctic bathymetry is from the International Bathymetric Chart of the Oceans (IBCAO).

All data are derived from public domain sources and these data are also in the public domain.

GRASS 6 script <code>r.in.srtm</code> described in GRASSNews vol. 3 won't work with this dataset (as it was made for the original SRTM HGT files). But you can import SRTM30plus tiles into GRASS this way:

r.in.bin -sb input=e020n40.Bathmetry.srtm output=e020n40_topex bytes=2 north=40 south=-10 east=60 west=20 r=6000 c=4800
r.colors e020n40_topex rules=etopo2

; Source
: GRASS Users Mailing List http://grass.itc.it/pipermail/grassuser/2005-August/030018.html
; Getting SRTM30plus tiles
: ftp://topex.ucsd.edu/pub/srtm30_plus/data

===Exporting GRASS maps to GMT===

GMT (Generic Mapping Tools) is a Free software package for creating publication quality cartography.

GMT homepage: http://gmt.soest.hawaii.edu

Exporting GRASS maps to GMT: http://169.237.35.250/~dylan/grass_user_group/#GMT_and_GRASS-overview
<BR>(Supplied by the GRASS Users Group of Davis, California)

Currently there are several *.out.GMT permutations, several in different languages (bash, python, etc.), and each of which with relative pros/cons. An effort to unify these approaches would save much of the current difficulties in moving complex raster+vector data into a GMT-friendly format. A simple road map toward this goal is outlined:

====Proper conversion of GRASS raster color data into GMT compatible CPT files====
David Finlayson's [http://david.p.finlayson.googlepages.com/gisscripts r.out.gmt.py] does a nice job of this.

====Proper conversion of GRASS raster data to GMT compatible binary grids====
A combination of r.out.bin | xyz2grd can accomplish this. Several attempts at generalizing this procedure have been proposed: [http://david.p.finlayson.googlepages.com/gisscripts r.out.gmt.py], [http://bambi.otago.ac.nz/hamish/grass/r.out.gmt r.out.gmt] (Hamish and Dylan), [http://169.237.35.250/~dylan/grass_user_group/r.out.gmt.sh r.out.gmt.sh] (Dylan, based Hamish's work).

====Proper conversion of GRASS vector data to GMT compatible ascii files====
There is currently an effort (with some funding!), see some of the chatter on the GRASS and GMT mailing lists:
[http://grass.itc.it/pipermail/grassuser/2006-April/033659.html]
[http://www.nabble.com/Ideas-needed-regarding-OGR-reformatter-for-GMT-vector-(point-multiline)-files.-t2605255.html]

====Automatic conversion of symbology data stored in a gis.m or QGIS saved state to GMT options====

===Interfacing R-Statistics with GRASS===

* All the necessary functions for the GRASS 6 interface are now in packages on CRAN, so that on Linux/Unix (or Mac OSX) installing rgdal from source with PROJ4 and GDAL installed, or Windows installing from binary, the required packages are: sp; maptools (now includes spmaptools); rgdal (now includes spGDAL, spproj); spgrass6 - now all on CRAN.

* http://grass.ibiblio.org/statsgrass/index.php#grassR

* R-Statistics homepage http://www.r-project.org

* R Spatial Projects http://sal.uiuc.edu/csiss/Rgeo//

* http://r-spatial.sourceforge.net/xtra/xtra.RHnw.html#spgrass6

* Neural Networks with GRASS and R (posted by Markus Neteler on the grass-user mailing list) http://www.uam.es/proyectosinv/Mclim/pdf/MBenito_EcoMod.pdf

* Using R and GRASS with cygwin: It is possible to use Rterm inside the GRASS shell in cygwin, just as in Unix/Linux or OSX. You should not, however, start Rterm from a cygwin xterm, because Rterm is not expecting to be run in an xterm under Windows, and loses its input. If you use the regular cygwin bash shell, but need to start display windows, start X from within GRASS with startx &, and then start Rterm in the same cygwin shell, not in the xterm.

===Using GRASS with an on-line Web-GIS===

see:

* [[GRASS and MapServer]]
* [[GRASS and PHP]]
* [[GRASS and Python]]

(please expand)

===Starting and running GRASS from a script===

See [[GRASS and Shell]].

===Running GRASS remotely on OS X===

Tiger (OS 10.4) changed the default configuration of SSH from previous versions of OS X. You can no longer start an ssh session with the -X flag and display the Tcl/Tk components of the GRASS GUI remotely. If you are running grass on OS X (10.4) between hosts on a network (i.e. running it on one machine but displaying it on another), you will need to use the "trusted forwarding" mode of SSH in order for the Tcl/Tk generated graphics, such as d.m or gis.m in order for the GUI graphics to make it through your connection. This can be done using the -Y flag when you start the ssh session:

ssh -Y remotehost

or add this to ~/.ssh/config:

Host hostname
ForwardX11 yes
ForwardX11Trusted yes

Using the -X flag, or simply turning on X11Forwarding in the SSH configuration files, is not enough: the symptoms in this case are that a d.mon window will function fine, but none of the Tcl/Tk dialogues will work, failing with an error message complaining either about Wish not behaving as expected, or a "Bad Atom".

[[Category:Documentation]]

Tips and Tricks

2006-12-10T01:26:07Z

⚠️DylanBeaudette: /* Exporting GRASS maps to GMT */

==Tips and Tricks==

===Using QGIS as a frontend to GRASS===

QGIS can run as a frontend to GRASS. There is support for displaying maps, editing maps, and execution of simple GIS functions. The GDAL/OGR library is a requirement for that (but for GRASS anyway):

* QGIS homepage: http://qgis.org
* GDAL homepage: http://www.gdal.org

To use the two together, the GDAL-GRASS plugin must be installed:

* [[Compile and install GRASS and QGIS with GDAL/OGR Plugin]]

Test that the GDAL-GRASS plugin is available with this command:<BR>
<pre>
gdalinfo --formats
</pre>
Look for a line like "GRASS (ro): GRASS Database Rasters (5.7+)"

Enable the QGIS GRASS plugin from QGIS: <br>
<pre>
GUI: Plugins / Plugin Manager / Check the GRASS checkbox
</pre>

The GRASS toolbar should now be visible.
While not a firm requirement, it is easier to start QGIS from within a GRASS session.

* [http://wiki.qgis.org/qgiswiki/GrassCookbook QGIS GRASS Cookbook] - Recipes for common tasks

===Importing SRTM30plus data===

SRTM30plus data consists of 33 files of global topography in the same format as the SRTM30 products distributed by the USGS EROS data center. The grid resolution is 30 second which is roughly one kilometer.

Land data are based on the 1-km averages of topography derived from the USGS SRTM30 grided DEM data product created with data from the NASA Shuttle Radar Topography Mission. GTOPO30 data are used for high latitudes where SRTM data are not available.

Ocean data are based on the Smith and Sandwell global 2-minute grid between latitudes +/- 72 degrees. Higher resolution grids have been added from the LDEO Ridge Multibeam Synthesis Project and the NGDC Coastal Relief Model. Arctic bathymetry is from the International Bathymetric Chart of the Oceans (IBCAO).

All data are derived from public domain sources and these data are also in the public domain.

GRASS 6 script <code>r.in.srtm</code> described in GRASSNews vol. 3 won't work with this dataset (as it was made for the original SRTM HGT files). But you can import SRTM30plus tiles into GRASS this way:

r.in.bin -sb input=e020n40.Bathmetry.srtm output=e020n40_topex bytes=2 north=40 south=-10 east=60 west=20 r=6000 c=4800
r.colors e020n40_topex rules=etopo2

; Source
: GRASS Users Mailing List http://grass.itc.it/pipermail/grassuser/2005-August/030018.html
; Getting SRTM30plus tiles
: ftp://topex.ucsd.edu/pub/srtm30_plus/data

===Exporting GRASS maps to GMT===

GMT (Generic Mapping Tools) is a Free software package for creating publication quality cartography.

GMT homepage: http://gmt.soest.hawaii.edu

Exporting GRASS maps to GMT: http://169.237.35.250/~dylan/grass_user_group/#GMT_and_GRASS-overview
<BR>(Supplied by the GRASS Users Group of Davis, California)

Currently there are several *.out.GMT permutations, several in different languages (bash, python, etc.), and each of which with relative pros/cons. An effort to unify these approaches would save much of the current difficulties in moving complex raster+vector data into a GMT-friendly format. A simple road map toward this goal is outlined:
====Proper conversion of GRASS raster color data into GMT compatible CPT files====
David Finlayson's [http://david.p.finlayson.googlepages.com/gisscripts r.out.gmt.py] does a nice job of this.

===Interfacing R-Statistics with GRASS===

* All the necessary functions for the GRASS 6 interface are now in packages on CRAN, so that on Linux/Unix (or Mac OSX) installing rgdal from source with PROJ4 and GDAL installed, or Windows installing from binary, the required packages are: sp; maptools (now includes spmaptools); rgdal (now includes spGDAL, spproj); spgrass6 - now all on CRAN.

* http://grass.ibiblio.org/statsgrass/index.php#grassR

* R-Statistics homepage http://www.r-project.org

* R Spatial Projects http://sal.uiuc.edu/csiss/Rgeo//

* http://r-spatial.sourceforge.net/xtra/xtra.RHnw.html#spgrass6

* Neural Networks with GRASS and R (posted by Markus Neteler on the grass-user mailing list) http://www.uam.es/proyectosinv/Mclim/pdf/MBenito_EcoMod.pdf

* Using R and GRASS with cygwin: It is possible to use Rterm inside the GRASS shell in cygwin, just as in Unix/Linux or OSX. You should not, however, start Rterm from a cygwin xterm, because Rterm is not expecting to be run in an xterm under Windows, and loses its input. If you use the regular cygwin bash shell, but need to start display windows, start X from within GRASS with startx &, and then start Rterm in the same cygwin shell, not in the xterm.

===Using GRASS with an on-line Web-GIS===

see:

* [[GRASS and MapServer]]
* [[GRASS and PHP]]
* [[GRASS and Python]]

(please expand)

===Starting and running GRASS from a script===

See [[GRASS and Shell]].

===Running GRASS remotely on OS X===

Tiger (OS 10.4) changed the default configuration of SSH from previous versions of OS X. You can no longer start an ssh session with the -X flag and display the Tcl/Tk components of the GRASS GUI remotely. If you are running grass on OS X (10.4) between hosts on a network (i.e. running it on one machine but displaying it on another), you will need to use the "trusted forwarding" mode of SSH in order for the Tcl/Tk generated graphics, such as d.m or gis.m in order for the GUI graphics to make it through your connection. This can be done using the -Y flag when you start the ssh session:

ssh -Y remotehost

or add this to ~/.ssh/config:

Host hostname
ForwardX11 yes
ForwardX11Trusted yes

Using the -X flag, or simply turning on X11Forwarding in the SSH configuration files, is not enough: the symptoms in this case are that a d.mon window will function fine, but none of the Tcl/Tk dialogues will work, failing with an error message complaining either about Wish not behaving as expected, or a "Bad Atom".

[[Category:Documentation]]

About GRASS

2006-12-10T01:10:14Z

⚠️DylanBeaudette: minor edits, addition of content

About GRASS

2006-12-10T01:00:21Z

⚠️DylanBeaudette: /* Key applications */

Project jobs

2006-12-10T00:54:30Z

⚠️DylanBeaudette: /* Interested people */

== Jobs in the GRASS project ==

- draft -

The growing infrastructure and extended user support requires more efforts to integrate user contributions and to keep things running. This page contains a list of jobs for which we seek volunteers. These jobs descriptions may appear a bit formal, but shall illustrate the needs.

=== Translations manager ===

The translations manager is responsible for maintaining the translation of GRASS messages
([http://grass.itc.it/devel/i18n.php translation page; [http://grass.itc.it/mailman/listinfo/translations mailing list])

Skills:
* knowledge (or willingness to learn use) of translation tools (kbabel, poEDIT)
* familiarity (or willingness to learn use) with CVS (see [[Working with CVS|instructions]])
* no programming skills required
Tasks:
* work with GRASS CVS-Head (latest GRASS)
* merging translation contributions (with 'msgmerge' of .po files or simply use [http://mpa.itc.it/markus/useful/po_merge.sh po_merge.sh])
* invite translators to contribute (ask regularly, find new), make then use recent GRASS
* create template files for new languages ('make pot')
* update existing translations '''after''' having received latest submissions from translators ('make update-po')
* keep headers of .po files intact and up-to-date
* add new translators to AUTHORS file in source code
Estimated workload:
* in average: 1-2h per week or less

=== Web site contributors ===

Several Web site contributors are desired to update pages and to improve the current structure. A future goal could be the move to a CMS system such as Drupal which would be a major effort.

Skills:
* knowledge of standard HTML (a single PHP function is used to construct menus)
* willingness to use plain text editors to write pages (to avoid that HTML cruft creeps in)
* familiarity (or willingness to learn use) with GRASS Web site CVS (see [[Working with CVS|instructions]])
* no programming skills required
Tasks:
* update outdated pages
* think about and implement "user stories" to make site more attractive
* think about and implement translation of important pages
* simplify structure
* add new screenshots with credits/CC license)
* regularly check if mirror sites work
Estimated workload:
* in average: 1-x h per week

=== Public relations manager ===

Despite the continuous growths of the user community, we seek for "GRASS GIS awareness" especially for public administration and companies. A multi-language brochure is needed to promote GRASS in a more effective way. Funding for a high quality print is to be defined.

Skills:
* communication and design skills
Tasks:
* find like-minded people to form a GRASS promotion group
* communicate the existence of the GRASS project
* design of a multi-language brochure (both PDF and printed) in collaboration with the [http://wiki.osgeo.org/index.php?title=VisCom OSGeo-VisCom team]
* create material to illustrate the GRASS functionality
* contact public administration and professionals in a non-spammy way
* collect success stories and render them usable for the Web site

=== Wiki manager ===

The GRASS wiki (your are using it at the moment) requires a continuous monitoring.

Skills:
* basic knowledge of mediawiki usage
* no programming skills required
Tasks:
* update outdated pages
* simplify structure where needed (merge pages)
* clean up [[:Special:Lonelypages|Orphaned pages]] (link, merge or remove)
* keep [[:Special:Categories|Categories]] up to date (add at bottom of pages where needed)
* keep an eye on spammers
Estimated workload:
* in average: 1h per week

== Interested people ==

While we have to figure out the process, here a list of interested people. Please add yourself:

* Malte Halbey-Martin: Public relations Manager + Web site contributor
* Dylan Beaudette: Web site contributor (familiar with Drupal CMS)

About GRASS

2006-12-04T17:15:59Z

⚠️DylanBeaudette: /* Recommended Reading (5 - 15 entries) */

About GRASS

2006-12-04T17:12:44Z

⚠️DylanBeaudette: /* Interoperability: GIS and Anlysis Toolchain */

About GRASS

2006-12-04T17:10:33Z

⚠️DylanBeaudette:

About GRASS

2006-12-04T17:08:05Z

⚠️DylanBeaudette: /* Key applications */

About GRASS

2006-12-04T17:05:08Z

⚠️DylanBeaudette: /* Historical Background (fewer than 500 words) */

About GRASS

2006-12-04T17:04:45Z

⚠️DylanBeaudette: /* Historical Background (fewer than 500 words) */