GRASS-Wiki - User contributions [en]

Documentation and Education Working Group

2023-10-30T18:41:25Z

⚠️Cmbarton:

Documentation and education working group is established to coordinate the development of documentation and education materials to meet the needs of a wide range of GRASS users.

== Scope ==
* coordinate development of documentation and education materials
* coordinate development of sample datasets and localized datasets
* decide on best formats and place for documentation, tutorials
* develop onboarding materials for contributors of documentation and education materials

== Members ==
Let us know who you are and what are your interests and topics you want to discuss and develop as part of this group.

; [https://wiki.osgeo.org/wiki/User:Helena Helena Mitasova] (working group coordinator)
: Professor at North Carolina State University
: Interested in wiki pages cleanup, manual pages updates, integration of GRASS in courses, localized data sets

; [https://wiki.osgeo.org/wiki/Anna_Petrasova Anna Petrasova]
: Researcher, educator and software developer at North Carolina State University
: Topics of interest include developing tutorials and workshops in Jupyter Notebooks, onboarding materials

; Eric Patton
:

; Florian Betz
:

; Hernán De Angelis
:

; Micha Silver
:

; Titus Kiprutto
:

; Paulo van Breugel
:

; Brendan Harmon
:

; [https://spatial-ecology.net/docs/build/html/COURSETRAINERS/trainers.html#giuseppe-amatulli-phd:Giuseppe Amatulli]
: Research scientist at School of the Environment, Yale University. Educator at Spatial Ecology
: Topics of interest include developing tutorials and workshops in GRASS

; [https://cmbarton.github.io Michael Barton]
: Professor in the School of Human Evolution & Social Change, and School of Complex Adaptive Systems at Arizona State University.
: I am a complex systems scientist who combines anthropology, archaeology, earth science, and information technologies to study long-term dynamics and interactions of people and landscapes in the Anthropocene. I also maintain the [https://cmbarton.github.io/grass-mac GRASS for Mac site]. Topics of interest include using open source software in the classroom, improving documentation pages, developing localized data sets for learning GRASS, using GRASS geospatial tools in other platforms.

; Massimo Di Stefano
:

; Carlos Grohmann
:

To be added to this working group, please contact the group coordinator.

== Communication Channels ==
* [https://lists.osgeo.org/mailman/listinfo/grass-user grass-user] and [https://lists.osgeo.org/mailman/listinfo/grass-dev grass-dev] mailing lists
* [https://github.com/OSGeo/grass OSGeo/grass GitHub issues and pull requests] and [https://github.com/orgs/OSGeo/projects/3 GitHub project]
* [https://app.gitter.im/#/room/#grassgis_documentation:gitter.im grassgis/documentation gitter room]

[[Category:Community]]
[[Category:Working_Groups]]

Documentation and Education Working Group

2023-10-30T18:22:39Z

⚠️Cmbarton: /* Updated info for Michael Barton */

Documentation and education working group is established to coordinate the development of documentation and education materials to meet the needs of a wide range of GRASS users.

== Scope ==
* coordinate development of documentation and education materials
* coordinate development of sample datasets and localized datasets
* decide on best formats and place for documentation, tutorials
* develop onboarding materials for contributors of documentation and education materials

== Members ==
Let us know who you are and what are your interests and topics you want to discuss and develop as part of this group.

; [https://wiki.osgeo.org/wiki/User:Helena Helena Mitasova] (working group coordinator)
: Professor at North Carolina State University
: Interested in wiki pages cleanup, manual pages updates, integration of GRASS in courses, localized data sets

; [https://wiki.osgeo.org/wiki/Anna_Petrasova Anna Petrasova]
: Researcher, educator and software developer at North Carolina State University
: Topics of interest include developing tutorials and workshops in Jupyter Notebooks, onboarding materials

; Eric Patton
:

; Florian Betz
:

; Hernán De Angelis
:

; Micha Silver
:

; Titus Kiprutto
:

; Paulo van Breugel
:

; Brendan Harmon
:

; [https://spatial-ecology.net/docs/build/html/COURSETRAINERS/trainers.html#giuseppe-amatulli-phd:Giuseppe Amatulli]
: Research scientist at School of the Environment, Yale University. Educator at Spatial Ecology
: Topics of interest include developing tutorials and workshops in GRASS

; [https://cmbarton.github.io Michael Barton]
: Professor in the School of Human Evolution & Social Change, and School of Complex Adaptive Systems at Arizona State University.
: I am a complex systems scientist who combines anthropology, archaeology, earth science, and information technologies to study long-term dynamics and interactions of people and landscapes in the Anthropocene. I also maintain the [https://cmbarton.github.io/grass-mac GRASS for Mac site].

; Massimo Di Stefano
:

; Carlos Grohmann
:

To be added to this working group, please contact the group coordinator.

== Communication Channels ==
* [https://lists.osgeo.org/mailman/listinfo/grass-user grass-user] and [https://lists.osgeo.org/mailman/listinfo/grass-dev grass-dev] mailing lists
* [https://github.com/OSGeo/grass OSGeo/grass GitHub issues and pull requests] and [https://github.com/orgs/OSGeo/projects/3 GitHub project]
* [https://app.gitter.im/#/room/#grassgis_documentation:gitter.im grassgis/documentation gitter room]

[[Category:Community]]
[[Category:Working_Groups]]

Global datasets

2023-07-10T21:50:49Z

⚠️Cmbarton: /* Climatic data */

= Raster data =

== Elevation data ==

=== ASTER topography (GDEM V1) ===

Improved ASTER GDEM 1 from 2009:

GDEM global 30m elevation calculated from stereo-pair images collected by the Terra satellite.
''"This is the most complete, consistent global digital elevation data yet made available to the world."''
This is a very new dataset, at version 1 (treat as ''experimental''). Accuracy will be improved in forthcoming versions (validation with SRTM, etc.; [http://blog.neteler.org/aster-gdem-30m-quality-assessment/ see assessment here] and [http://www.viewfinderpanoramas.org/reviews.html#aster here]).

* ''[https://lpdaac.usgs.gov/lpdaac/about/news_archive/monday_june_22_20092 pre-release announcement]''
* [http://www.nasa.gov/home/hqnews/2009/jun/HQ_09-150_ASTER_Topographic_Map.html NASA press release]
* [https://wist.echo.nasa.gov/~wist/api/imswelcome/ Warehouse Inventory Search Tool] or [http://www.gdem.aster.ersdac.or.jp/search.jsp Easy search tool] (Data download)

'''Tutorial:''' [[ASTER topography]]

''See also: [http://blog.neteler.org/aster-gdem-30m-quality-assessment/ ASTER GDEM 30m quality assessment]''

=== ASTER topography (GDEM V2) ===

Improved ASTER GDEM 2 from 2011:
* https://lpdaac.usgs.gov/products/aster_products_table/astgtm

The ASTER GDEM covers land surfaces between 83°N and 83°S and is comprised of 22,702 tiles. Tiles that contain at least 0.01% land area are included. The ASTER GDEM is distributed as Geographic Tagged Image File Format (GeoTIFF) files with geographic coordinates (latitude, longitude). The data are posted on a '''1 arc-second''' (approximately '''30–m at the equator''') grid and referenced to the 1984 World Geodetic System (WGS84)/ 1996 Earth Gravitational Model (EGM96) geoid.

'''Notes:''' this DEM can be rather well filtered and smoothed with the [http://personalpages.manchester.ac.uk/staff/neil.mitchell/mdenoise/ Sun's denoising algorithm] (using GDAL and free / open source program <mdenoise> or simply GRASS add-on {{AddonCmd|r.denoise}}.

Experiments showed that the best smoothing of ASTER GDEM 2 is reached with such parameters of <mdenoise>:
* threshold = 0.8
* iterations = 10-20

Also filtering with {{cmd|r.neighbors}} by "average" method and window size >=5 is quite useful to remove some noise from DEM.

''See also: [http://www.isprs2012.org/abstract/299.asp Validation of the ASTER Global Digital Elevation Model Version 2 over the Conterminous United States]''

=== ACE2 ===

The ACE2 Global Digital Elevation Model is available at 3", 30" and 5' spatial resolutions.

* http://tethys.eaprs.cse.dmu.ac.uk/ACE2/

Import example:
r.in.bin -f input="00N105E_3S.ACE2" output="ACE2_00N105E" bytes=4 \
order="native" north=15 south=0 east=120 west=105 \
rows=18000 cols=18000

=== CleanTOPO2 (DEM) ===

* [http://www.shadedrelief.com/cleantopo2/ CleanTOPO2 download]: Edited SRTM30 Plus World Elevation Data

Import in GRASS:
r.in.gdal CleanTOPO2.tif out=cleanTOPO2.tmp -l -o
g.region rast=cleanTOPO2 -p -g
# rescale from odd integer values to true world values
r.rescale cleanTOPO2.tmp out=cleanTOPO2 to=-10701,8248
r.colors cleanTOPO2_final col=terrain

[[Image:CleanTOPO2_map.png|thumb|center|300px|Rescaled ClearTOPO2 map]]

=== EGM2008 Geoid Data (Earth Gravitational Model) ===

Global 2.5 Minute Geoid Undulations:
* download GIS Format at http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/egm08_gis.html

[[Image:Trentino_egm2008_map_5m_resampled.jpg|thumb|center|300px|Geoid undulations in Trentino, Italy]]

Verifications of points can be done with the http://geographiclib.sourceforge.net/cgi-bin/GeoidEval

=== ETOPO (DEM) ===

The ETOPO datasets provide global topography and bathymetry at 1', 2', and 5' per-cell resolutions.

==== ETOPO1 (DEM) ====

* http://www.ngdc.noaa.gov/mgg/global/

* '''The ''cell registered'' version can be loaded directly into a lat/lon location'''. GRASS raster data is cell registered (see the [[GRASS raster semantics]] page)

* Special care must be taken with the ''grid registered'' version. It can not be loaded directly into a lat/lon location as the parameters found in the .hdr file exceed the limits of polar coordinate space: they have N,S rows which go 1/2 a cell beyond 90 latitude, when considered in the ''cell registered'' convention.
: So the data needs to have those 90deg N,S rows cropped away, and while we're at it we crop away a redundant overlapping column at 180 longitude. To do this we have to first tell the GIS a little fib during import to squeeze the data into lat/lon space, then crop away the spurious rows and column, then finally reset the resulting map's bounds to its true extent.

<source lang="bash">
# Import grid registered binary float, fibbing about its true extent
r.in.bin -f in=etopo1_bed_g.flt out=etopo1_bed_g.raw \
n=90 s=-90 e=180 w=-180 rows=10801 cols=21601 anull=-9999

# reduce the working region by 1 cell
g.region rast=etopo1_bed_g.raw
eval `g.region -g`
g.region n=n-$nsres s=s+$nsres e=e-$ewres -p

# save smaller raster and remove original
r.mapcalc "etopo1_bed_g.crop = etopo1_bed_g.raw"
g.remove etopo1_bed_g.raw

# re-establish the correct bounds, now that they'll fit
r.region etopo1_bed_g.crop n=89:59:30N s=89:59:30S w=179:59:30E e=179:59:30E
g.region rast=etopo1_bed_g.crop

# check that N,S,E,W and Res are all nice and clean:
r.info etopo1_bed_g.crop

# looks good, so accept the results by resetting the map name
g.rename etopo1_bed_g.crop,etopo1_bed_g

# set to use appropriate color rules
r.colors etopo1_bed_g color=etopo2

# set the 'units' metadata field (for elevation data contained within the map)
r.support etopo1_bed_g units=meters
</source>

* For the problematic ''grid registered'' version, the resulting {{cmd|r.info}} report should look like:
| Rows: 10799 |
| Columns: 21600 |
| Total Cells: 233258400 |
| Projection: Latitude-Longitude |
| N: 89:59:30N S: 89:59:30S Res: 0:01 |
| E: 179:59:30E W: 179:59:30E Res: 0:01 |
| Range of data: min = -10898 max = 8271 |
(the east and west bounds of the map touch 1/2 a cell west of 180 longitude)

* For the problematic ''grid registered'' version, since the data's grid is 1/2 a cell shifted from nicely rounded 1 arc-minutes (0:01), you'll need to ensure that the mapset's region preserves that alignment after zooming or panning:
g.region align=etopo1_bed_g -p
: (or oversample and set the region resolution to 1/2 arc-minutes (0:00:30), which will be four times as slow)

==== ETOPO2 (DEM) ====

* See the ETOPO2 (2' global) article by M.H. Bowman in the [http://grass.osgeo.org/newsletter/GRASSNews_vol1.pdf GRASS Newsletter, 1:8-11, August 2004].
: [http://www.ngdc.noaa.gov/mgg/fliers/01mgg04.html ETOPO2v2 data download] (take for example the ETOPO2v2g_f4_LSB.flt file)

=== GTOPO30 (DEM) ===

* Data [http://eros.usgs.gov/#/Find_Data/Products_and_Data_Available/gtopo30_info download] - Import with {{cmd|r.in.gdal}}.

''Note:'' To avoid that the GTOPO30 data are read incorrectly, you can add a new line "PIXELTYPE SIGNEDINT" in the .HDR to force interpretation of the file as signed rather than unsigned integers. Then the .DEM file can be imported. Finally, e.g. the 'terrain' color table can be assigned to the imported map with r.colors.

=== Global Multi-resolution Terrain Elevation Data 2010 (GMTED2010) ===

* Data download: [https://lta.cr.usgs.gov/GMTED2010 Web] and [http://topotools.cr.usgs.gov/GMTED_viewer/gmted2010_global_grids.php FTP] - Import with {{cmd|r.in.gdal}}. See also [https://erouault.blogspot.de/2011/12/seamless-access-to-remote-global-multi.html related GDAL blog post]

Tiles: Import of GMTED2010 tiles in GRASS GIS:

r.in.gdal 30N000E_20101117_gmted_mea075.tif out=gmted2010_30N000E_20101117
r.colors gmted2010_30N000E_20101117 color=elevation
g.region rast=gmted2010_30N000E_20101117
r.relief input=gmted2010_30N000E_20101117 output=gmted2010_30N000E_20101117.shade
r.shade shade=gmted2010_30N000E_20101117.shade color=gmted2010_30N000E_20101117 \
output=gmted2010_30N000E_20101117_shaded
d.mon wx0
d.rast gmted2010_30N000E_20101117_shaded
d.grid 1 color=red textcolor=red

[[Image:Gmted2010_30N000E_20101117_shaded.png|thumb|center|300px|GMTED2010 example: Trento - Garda Lake - Verona area (Northern Italy)]]

Full maps:

# mean elevation global GMTED2010 map, 30 arc-sec
wget http://edcintl.cr.usgs.gov/downloads/sciweb1/shared/topo/downloads/GMTED/Grid_ZipFiles/mn30_grd.zip
unzip mn30_grd.zip

Important: the GMTED2010 map exceeds the -180°..+180° range due to the [https://pubs.usgs.gov/of/2011/1073/pdf/of2011-1073.pdf GMTED2010 pixel geometry] (PDF). Note that this cannot be handled in GRASS GIS < 7.4. Please update to GRASS GIS 7.4 or newer.

=== GEBCO Bathymetric Chart ===

* The General Bathymetric Chart of the Oceans (original 1' release 2003, new 1' and 30" releases 2008, new 15" released 2020)
: http://www.gebco.net/data_and_products/gridded_bathymetry_data/
: http://www.bodc.ac.uk/data/online_delivery/gebco/

The GEBCO_2020 is available in NetCDF or GeoTIFF format.

{{cmd|r.in.gdal}} can be used to import the GMT netCDF files directly, or if that doesn't work you can use GMT tools to convert to an old-style native GMT format and import that with {{cmd|r.in.bin}}.
: example: (GEBCO 2003 1' data)

# convert to an old style GMT binary .grd using grdreformat
$ grdreformat 3n24s47w14w.grd 3n24s47w14w_Native.grd=bs

# then import into GRASS,
GRASS> r.in.bin -h -s bytes=2 in=3n24s47w14w_Native.grd out=3n24s47w14w

# and set some nice colors
GRASS> r.colors 3n24s47w14w rules=- << EOF
nv magenta
0% black
-7740 0:0:168
0 84:176:248
0 40:124:0
522 68:148:24
1407 148:228:108
1929 232:228:108
2028 232:228:92
2550 228:160:32
2724 216:116:8
2730 grey
2754 grey
2760 252:252:252
2874 252:252:252
2883 192:192:192
2913 192:192:192
100% 252:252:252
EOF

=== Global Multi-Resolution Topography (GMRT DEM) ===
: ''From Columbia University's Lamont-Doherty Earth Observatory''
(it is reported that this is what Google Maps uses for their global bathymetry)

* Global ~1 arc-second (~90 m) topography using multi-beam and satellite data in the oceans combined with SRTM on land.
* Full information at: http://www.marine-geo.org/portals/gmrt/
* Accessible via [http://www.geomapapp.org/ GeoMapApp] or [http://www.virtualocean.org/ Virtual Ocean] software.
* Very convenient to download into GRASS via wget:

export `g.region -g`
wget "http://www.marine-geo.org/cgi-bin/getgridB?west=${w}&east=${e}&south=${s}&north=${n}&resolution=1" -O /tmp/test.grd
r.in.gdal /tmp/test.grd output=GMRT -o
rm /tmp/test.grd

* Note: Downloaded file contains no projection information, but is EPSG:4326 (WGS84 Geographic). The file size is limited, but lower resolution (resolution=2,4,8) data can be downloaded for larger areas.

=== NASADEM ===

1-arc second (~30 m @ equator) global only-land.

https://lpdaac.usgs.gov/news/release-nasadem-data-products/

See also {{AddonCmd|r.in.nasadem|version=7}} addon

=== Smith and Sandwell DEM ===

* Merge info here from the [[Marine Science]] wiki page

=== SRTM DEM ===

[http://www2.jpl.nasa.gov/srtm/ Space Shuttle Radar Topography Mission] - several SRTM Data Products are available:
* Original data - SRTM 3 V001 arc-seconds Non-Void Filled elevation data (US: 1 arc-second (approximately 30 meters); outside the US at 3 arc-seconds (approximately 90 meters))
* SRTM V003 3 Arc-Second Global Void Filled elevation data, with voids filled using interpolation algorithms in conjunction with other sources of elevation data (US: 1 arc-second (approximately 30 meters); outside the US at 3 arc-seconds (approximately 90 meters))
** SRTM V3 tiles at 3 arc seconds resolution from: http://e4ftl01.cr.usgs.gov/SRTM/SRTMGL3.003/2000.02.11/ - or simply use {{AddonCmd|r.in.srtm.region}}
* '''SRTM V003 1 Arc-Second Global elevation data''' offer worldwide coverage of '''void filled''' data at a resolution of 1 arc-second (30 meters) and provide open distribution of this high-resolution global data set.
** [http://earthexplorer.usgs.gov/ EarthExplorer] can be used to search, preview, and download Shuttle Radar Topography Mission (SRTM) 1 Arc-Second Global data. The collections are located under the Digital Elevation category.
** FTP download: http://e4ftl01.cr.usgs.gov/SRTM/SRTMGL1.003/2000.02.11/ - or simply use {{AddonCmd|r.in.srtm.region}}
** Web-based [http://dwtkns.com/srtm30m/ 30-Meter SRTM Tile Downloader] (select from map)

Import:
* Using {{cmd|r.in.gdal}} or {{cmd|r.import}} or {{cmd|r.in.srtm}} or {{AddonCmd|r.in.srtm.region}}
* see [[HOWTO import SRTM elevation data]], focused on the SRTM 3 arc-seconds Non-Void Filled elevation data

=== SRTM15+ DEM ===

SRTM15+ data consists of 33 files of global topography in the same format as the SRTM30plus products. The grid resolution is 15 seconds which is roughly 500 m at the equator.

https://topex.ucsd.edu/WWW_html/srtm15_plus.html

=== SRTM30plus data DEM ===

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 seconds which is roughly one kilometer (1 km).

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 {{{cmd|r.in.srtm}}} 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.Bathymetry.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://lists.osgeo.org/pipermail/grass-user/2005-August/030063.html
; Getting as SRTM30plus tiles: ftp://topex.ucsd.edu/pub/srtm30_plus/srtm30/data/
; Getting as SRTM30plus huge file: ftp://topex.ucsd.edu/pub/srtm30_plus/topo30/
; SRTMPLUS WCS server: http://svn.osgeo.org/gdal/trunk/autotest/gdrivers/data/srtmplus.wcs (read with {{cmd|r.external}})

=== SRTM Water Body Database SRTMSWBD V003 ===

SRTM Water Body Database V003
* Format documentation: https://lpdaac.usgs.gov/dataset_discovery/measures/measures_products_table/srtmswbd_v003
* FTP raster data (30m res water bodies): http://e4ftl01.cr.usgs.gov/SRTM/SRTMSWBD.003/

Import into GRASS GIS 7 (lat-long location):
r.in.bin -sb input=N00E108.raw output=N00E108_swbd bytes=1 north=0 south=-10 east=108 west=98 r=3601 c=3601 <<= DRAFT - TODO fix n,s,e,w - calculate from filename

=== TanDEM-X DEM ===

This is a 90 m only-land DEM.
Data from 2010-12-12 through 2015-01-16

https://geoservice.dlr.de/data-assets/ju28hc7pui09.html

== Soil data ==

=== Harmonized World Soil Database (HWSD Database) ===

Download: http://webarchive.iiasa.ac.at/Research/LUC/External-World-soil-database/HTML/

[http://webarchive.iiasa.ac.at/Research/LUC/External-World-soil-database/HTML/DataDesc.html?sb=12 Spatial reference system:] [http://spatialreference.org/ref/epsg/4326/ EPSG:4326] (LatLong WGS84)

Import:
grass70 -c EPSG:4326 ~/grassdata/hwsd
# -e: expand location to dataset; -o: override (missing) projection in input dataset:
r.in.gdal input=hwsd.bil output=hwSoil -e -o
g.region raster=hwSoil -p
r.category hwSoil

The data is distributed with an MSAccess .mdb which contains additional data for each of the categories in the raster file. Opening the file in access, the data is found in the query "HWSD_Q". Save this query in .csv format (with a name like "HWSD_Q.csv") so that it may then be imported into GRASS. After that, it is necessary to replace the commas with dots (find & replace) in the .csv file. Before you can import it, you also need a file "HWSD_Q.csvt", which contains a single line listing the type for each column in the database:
"Integer","String","Integer","Integer","Integer","String","Integer","Integer","Real","Integer","String","Integer","String","Integer","String","Integer","Integer","Integer","Integer","Integer","Integer","Integer","Integer","Integer","Integer","Integer","Integer","Integer","Integer","Integer","Integer","Real","Real","Real","Real","Real","Real","Real","Real","Real","Real","Real","Real","Integer","Integer","Integer","Integer","Integer","Real","Real","Real","Real","Real","Real","Real","Real","Real","Real","Real","Real"

With both the .csv and the .csvt file in the same directory, you can then import them into GRASS:
db.in.ogr input=~/grassdata/hwsd/HWSD_Q.csv output=hwsdData

The data cannot be connected directly to the raster, it must be converted to a vector first:
g.region raster=hwSoil
r.to.vect -v input=hwSoil output=hwSoil feature=area
v.db.droptable hwSoil
db.droptable -f hwSoil # delete the table completely

Note that the table includes multiple rows for each polygon, corresponding
to the dominant and various numbers of subdominant soils. To select only
the dominant soil layer:

db.select table=hwsdData sql='select * from hwsdData where SEQ = 1' \
output=domSoil.csv separator=,

This saves a copy of the table that contains only the dominant soil type for each polygon as domSoil.csv. This needs to be reloaded into the GRASS database. Since it has the same columns as HWSD_Q.csv, we can use the labels for that file:

cp HWSD_Q.csvt domSoil.csvt

Then we can load domSoil.csv:

db.in.ogr \
input=~/grassdata/downloads/harmonized_world_soil_database/domSoil.csv \
output=domSoil

Now at last we can connect the database to the vector file:

v.db.connect -o map=hwsd table=domSoil driver=sqlite key=MU_GLOBAL

To create a new raster map taking the values from the table:
g.region raster=hwSoil ## make sure we get the whole map
v.to.rast in=hwSoil out=T_SAND col=T_SAND

=== SoilGrids.org 250m soil taxonomy map ===

SoilGrids is a system for automated soil mapping based on global soil profile and environmental covariate data. SoilGrids represents a collection of updatable soil property and class maps of the world at 1 km and 250 m spatial resolution produced using automated soil mapping based on machine learning algorithms. It aims at becoming OpenStreetMap and/or OpenWeatherMap for soil data. SoilGrids predictions are updated on a regular basis (at least every few months). For more details about the SoilGrids system, please refer to the SoilGrids project site: https://www.soilgrids.org/#/?layer=geonode:taxnwrb_250m

<source lang="bash">
URL=ftp://ftp.soilgrids.org/data/recent/TAXNWRB_250m_ll.tif

# the Soilgrids GeoTIFF data suffer from a resolution precision problem since they were produced with SAGA:
# resolution is stored as 0.002083333000000 while it should be 0.002083333333333, hence the geometry is not fully correct
# this likely originates from Soilgrids being processed in SAGA which cuts decimals after the 10th decimal place, hence comes with a precision problem

export NAME=`basename $URL .tif`
wget $URL
</source>

OLD OLD OLD start --
<source>
# see below for the better way how to fix SoilGrids data
gdal_translate --config GDAL_CACHEMAX 2000 -a_ullr $COORDS -co "COMPRESS=DEFLATE" $NAME.tif ${NAME}_fixed.tif
gdalinfo ${NAME}_fixed.tif

grass72 -c ${NAME}_fixed.tif ~/grassdata/latlong --exec r.import input=${NAME}_fixed.tif output=${NAME}
</source>
-- OLD OLD OLD end

New fix & import method:

Starting with '''GRASS GIS 7.4.x''', there is new flag in {{cmd|r.in.gdal}} to auto-adjust such small resolution precision issues: '''-a''' ''- Auto-adjustment for lat/lon. Attempt to fix small precision errors in resolution and extents.''

<source lang="bash">
r.in.gdal -a input=TAXNWRB_250m_ll.tif output=TAXNWRB_250m_ll
</source>

== Landcover data ==

=== ESA Globcover dataset ===

Download: http://due.esrin.esa.int/page_globcover.php

Or via command line:
wget http://due.esrin.esa.int/files/Globcover2009_V2.3_Global_.zip
unzip Globcover2009_V2.3_Global_.zip
# rm -f Globcover2009_V2.3_Global_.zip

Note, also a coloured version of the map in GeoTIFF format is available at: http://due.esrin.esa.int/files/GLOBCOVER_L4_200901_200912_V2.3.color.tif

Unfortunately the Globcover map exceeds the -180°..+180° range etc, indicating a shift of the map (see also [http://www.cosmo-model.org/content/tasks/workGroups/wg3b/meetings/2012-soilveg/EXTPAR-GLOBCOVER.pdf this assessment by DWD]):
<pre>
gdalinfo GLOBCOVER_L4_200901_200912_V2.3.tif
Driver: GTiff/GeoTIFF
Files: GLOBCOVER_L4_200901_200912_V2.3.tif
Size is 129600, 55800
Coordinate System is:
GEOGCS["WGS 84",
...
Origin = (-180.001388888888897,90.001388888888883)
...
Corner Coordinates:
Upper Left (-180.0013889, 90.0013889) (180d 0' 5.00"W, 90d 0' 5.00"N)
Lower Left (-180.0013889, -64.9986111) (180d 0' 5.00"W, 64d59'55.00"S)
Upper Right ( 179.9986111, 90.0013889) (179d59'55.00"E, 90d 0' 5.00"N)
Lower Right ( 179.9986111, -64.9986111) (179d59'55.00"E, 64d59'55.00"S)
Center ( -0.0013889, 12.5013889) ( 0d 0' 5.00"W, 12d30' 5.00"N)
...
</pre>

How to fix this?

'''Option 1:''' You can use the -l flag of {{cmd|r.in.gdal}} to constrain the map coordinates to legal values ([https://pvanb.wordpress.com/2011/05/10/importing-global-rasters-in-grass-gives-me-illegal-latitude-for-north-message/ ref]. But the resulting pixels will no longer have the original resolution. We will not do that.

'''Option 2:''' Shift the Globcover map slightly into the right position using [http://www.gdal.org/gdal_translate.html gdal_translate]:

<pre>
# coords are shifted, fix raster map
# -a_ullr Assign/override the georeferenced bounds of the output file
# use larger cache and compress result
gdal_translate --config GDAL_CACHEMAX 1200 -a_ullr -180 90 180 -65 \
-co "COMPRESS=LZW" GLOBCOVER_L4_200901_200912_V2.3.tif GLOBCOVER_L4_200901_200912_V2.3_fixed.tif

# result:
gdalinfo GLOBCOVER_L4_200901_200912_V2.3_fixed.tif
...
Origin = (-180.000000000000000,90.000000000000000)
Pixel Size = (0.002777777777778,-0.002777777777778)
...
Corner Coordinates:
Upper Left (-180.0000000, 90.0000000) (180d 0' 0.00"W, 90d 0' 0.00"N)
Lower Left (-180.0000000, -65.0000000) (180d 0' 0.00"W, 65d 0' 0.00"S)
Upper Right ( 180.0000000, 90.0000000) (180d 0' 0.00"E, 90d 0' 0.00"N)
Lower Right ( 180.0000000, -65.0000000) (180d 0' 0.00"E, 65d 0' 0.00"S)
Center ( 0.0000000, 12.5000000) ( 0d 0' 0.01"E, 12d30' 0.00"N)
</pre>

Voilà! Now we can import the map into GRASS GIS:

r.in.gdal input=GLOBCOVER_L4_200901_200912_V2.3_fixed.tif output=esa_globcover2009

'''Legend conversion''': The ZIP file contains a XLS table describing the classes and the RGB colors. Using ogr2ogr can directly convert XLS --> CSV:

ogr2ogr -f CSV Globcover2009_Legend.csv Globcover2009_Legend.xls

'''Applying the legend:'''

# suppress table header and only consider category value and label, apply on the fly:
cat Globcover2009_Legend.csv | grep -v '^Value' | cut -d',' -f1-2 | r.category esa_globcover2009 separator=comma rules=-
# verify (0E, 0N is the Atlantic Ocean)
r.what esa_globcover2009 coor=0,0 -f
0|0||210|Water bodies

=== Global Forest Change ===

* http://earthenginepartners.appspot.com/science-2013-global-forest
* Download info on: http://earthenginepartners.appspot.com/science-2013-global-forest/download_v1.3.html

== Imagery ==

=== AVHRR ===

* see the [[AVHRR]] wiki page

=== Blue Marble imagery ===

NASA's Blue Marble is a 500m-8 degree per-cell world wide visual image of the Earth from space, with the clouds removed.

* see the [[Blue Marble]] wiki page

=== EO-1 imagery ===

(Earth Observing-1)
* "''Advanced Land Imager (ALI) provides image data from ten spectral bands (band designations). The instrument operates in a pushbroom fashion, with a spatial resolution of 30 meters for the multispectral bands and 10 meters for the panchromatic band.''"
:-- http://eros.usgs.gov/products/satellite/eo1.php
* On-board Atmospheric Corrections

=== Global Land Cover Characteristics ===

USGS ''et al.'' generated dataset at 1km resolution. Provides global landcover characteristics.

* see the [[Global Land Cover Characteristics]] wiki page

=== LANDSAT imagery ===

Since October 1, 2008 all Landsat 7 ETM+ scenes held in the [http://landsat.usgs.gov/ USGS EROS archive] are available for download at no charge.
* Download via the [http://glovis.usgs.gov/ Glovis] online search tool (req. Java)
* Download via the USGS's [http://edcsns17.cr.usgs.gov/EarthExplorer/ EarthExplorer] interface

==== Import Modules ====

* {{cmd|r.in.gdal}} - Main import tool for complete multiband scenes
* {{cmd|r.in.wms}} - Download data covering current map region via WMS server
* [[GRASS_AddOns#r.in.onearth|r.in.onearth]] - WMS frontend for NASA's OnEarth Global Landsat Mosaic

==== Color balancing modules ====
* {{cmd|i.landsat.rgb}} (GRASS 6.x) | {{cmd|i.colors.enhance|version=70}} (GRASS 7.x) - Color balancing/enhancement tool

==== See also ====

* Processing tips can be found on the [[LANDSAT]] wiki page

=== ESA Sentinel imagery ===

The [https://grass.osgeo.org/grass-stable/manuals/addons/i.sentinel.html i.sentinel] toolbox of addons provides
a complete suite for downloading, importing and preprocessing Sentinel imagery.

For direct access, all Sentinel 1 and 2 data is available for download from the [https://scihub.copernicus.eu/ Open Access Hub]

* via the [https://scihub.copernicus.eu/dhus/#/home online interactive interface]
* via the [https://scihub.copernicus.eu/twiki/do/view/SciHubWebPortal/APIHubDescription API]

Other pre-processing tools are available at:
* http://step.esa.int/main/ Scientific Toolbox Exploitation Platform
* https://github.com/Fernerkundung/awesome-sentinel ("Awesome Sentinel" - list of tools)

=== Miscellaneous ===

==== Data sources ====

* Some datasource links: http://www.ruf.rice.edu/~ben/gmt.html
* [http://www.geotorrent.org/browse.php Geotorrent.org]

==== Import Modules ====
* The {{cmd|r.in.gdal}} modules may be used to import data of [http://www.gdal.org/formats_list.html many formats], including GMT netCDF
* The {{cmd|r.in.bin}} module may be used to import raw binary files

=== MODIS imagery ===

* see the [[MODIS]] wiki page

=== Natural Earth imagery ===

* [http://www.naturalearthdata.com/ Natural Earth II]: World environment map in natural color. GeoTIFF (use the {{cmd|r.in.gdal}} module)
* see also 1:10 million, 1:50 million and 1:110million scale maps from http://www.naturalearthdata.com/

=== Earth at Night: nightlight maps ===

* Earth at Night: Flat Maps https://earthobservatory.nasa.gov/features/NightLights/page3.php (GeoTIFFs)

=== Orthoimagery ===

* [http://worldwindcentral.com/wiki/Sources_of_free_orthoimagery Sources of free orthoimagery]

=== Pathfinder AVHRR SST imagery ===

* see the Pathfinder [[AVHRR]] SST wiki page

=== QuickBird imagery ===

* See the [[QuickBird]] wiki page

=== SeaWiFS imagery ===

* see the [[SeaWiFS]] wiki page

=== SPOT Vegetation imagery ===

SPOT Vegetation (1km) global: NDVI data sets

* [http://free.vgt.vito.be/ SPOT Vegetation (1km, global) NDVI data set server]
* for import, see {{cmd|i.in.spotvgt}}

=== True Marble imagery ===

* [http://www.unearthedoutdoors.net/global_data/true_marble/download True Marble]: 250m world wide visual image of the Earth from space, with the clouds removed. GeoTIFF (use the {{cmd|r.in.gdal}} module)

== Climatic data ==

=== OGC WCS - Albedo example ===

TODO: update this example e.g. to http://demo.mapserver.org/cgi-bin/wcs?SERVICE=wcs&VERSION=1.0.0&REQUEST=GetCapabilities

GRASS imports OGC Web Coverage Service data. Example server (please suggest a better one!)
<WCS_GDAL>
<ServiceURL>http://laits.gmu.edu/cgi-bin/NWGISS/NWGISS?</ServiceURL>
<CoverageName>AUTUMN.hdf</CoverageName>
<Timeout>90</Timeout>
<Resample>nearest</Resample>
</WCS_GDAL>

Save this as albedo.xml. Import into a LatLong WGS84 location:
r.in.gdal albedo.xml out=albedo

Unfortunately this server sends out the map shifted by 0.5 pixel. This requires a fix to the map boundary coordinates:
r.region albedo n=90 s=-90 w=-180 e=180

Now apply color table and look at the map:
r.colors albedo color=byr
d.mon x0
d.rast albedo

=== SNODAS maps ===

[http://nsidc.org/data/docs/noaa/g02158_snodas_snow_cover_model/index.html Snow Data Assimilation System] data that support hydrological modeling and analysis. First download the data, and untar them (once for each month, and once for each day), and you should get pairs of “.dat” and “.Hdr” files. The data files are stored in flat 16-bit binary format, so assuming that “snowdas_in.dat” is the name of the input file, at the GRASS prompt:

r.in.bin -bs bytes=2 rows=3351 cols=6935 north=52.874583333332339 \
south=24.949583333333454 east=-66.942083333334011 west=-124.733749999998366 \
anull=-9999 input=snowdas_input.dat output=snowdas

=== CHELSA climate maps ===

CHELSA – Climatologies at high resolution for the earth’s land surface areas is a high resolution (30 arc sec) climate data set for the earth land surface areas currently under development, see http://chelsa-climate.org/

Version 1.1 has some coordinate issues originating from SAGA being used (coordinate precision issue), see http://chelsa-climate.org/known-issues/

<source lang="shell">
# WARNING: dirty hack - Better wait for the new release V1.2 of CHELSA!

for i in `ls /scratch/chelsa_climate/*.zip` ; do
unzip $i
NAME=`basename $i .zip`
gdal_translate --config GDAL_CACHEMAX 2000 -a_ullr -180 84 180 -90 -co "COMPRESS=DEFLATE" $NAME.tif ${NAME}_fixed.tif
rm -f $NAME.tif
done
</source>

=== WorldClim maps ===

[http://www.worldclim.org/ WorldClim] is a set of global climate layers (climate grids) with a spatial resolution of a square kilometer. Besides long-term average climate layers (representing the period 1950 - 2000) it also includes projections for future conditions based on downscaled global climate model (GCM) data from CMIP5 (IPPC Fifth Assessment) and projections of past conditions (downscaled global climate model output).
* Load into a Lat/Lon WGS84 location (EPSG:4326)
* The data set is provided in two formats: BIL and ESRI Grd. Import with {{cmd|r.in.bin}} or {{cmd|r.in.gdal}}. Version 1.4 has some coordinate issues:

a) BIL: binary format is 2 byte integer. Multiply by 10 using {{cmd|r.mapcalc}} to convert units. See http://www.worldclim.org/format.htm for more information and the [[MODIS]] help page for example of converting raw to data units. Note that the file header is missing a line. To fix:

# fix WorldClim's BIL; tmean example
for i in $(seq 1 12); do echo “PIXELTYPE SIGNEDINT” >>tmean$i.hdr; done

b) ESRI grd files: Note that the WorldClim ESRI grd files suffer from a quality issue of coordinate precision. See [https://lists.osgeo.org/pipermail/grass-user/2011-January/059358.html here] for a solution.

# fix WorldClim's ESRI Grd; tmean example
export GDAL_CACHEMAX=2000
mkdir -p ~/tmp/
# fix broken WorldClim files, see https://lists.osgeo.org/pipermail/grass-user/2011-January/059358.html
# note: 60S, not 90S
for i in $(seq 1 12); do gdal_translate -a_ullr -180 90 180 -60 tmean_$i $HOME/tmp/tmean_${i}_fixed.tif; done
#
# import
for i in $(seq 1 12) ; do r.in.gdal input=$HOME/tmp/tmean_${i}_fixed.tif out=tmp --o ; g.region raster=tmp -p ; r.mapcalc "tmean_${i} = 0.1 * tmp" --o ; r.colors tmean_${i} color=celsius ; done
#
# clean up
g.remove raster name=tmp -f
rm -f ~/tmp/tmean_?_fixed.tif ; rm -f ~/tmp/tmean_??_fixed.tif

=== Africlim maps ===

[https://www.york.ac.uk/environment/research/kite/resources/ Africlim] provides four baseline data sets for current climate, including:
* CRU CL 2.0
* WorldClim v1.4
* TAMSAT TARCAT v2.0 (rainfall only)
* CHIRPS v1.8 (rainfall only).

It furthermore provides data sets with projections of future climates based on combinations of ten general circulation models (GCMs), downscaled using five regional climate models (RCMs) and the four above mentioned contemporary baselines, under two representative concentration pathways of the IPCC-AR5 (RCP4.5 and RCP8.5). The data layers are available as GeoTIF files at spatial resolutions of 10', 5', 2.5', 1' and 30".

=== PaleoClim maps ===
[http://www.paleoclim.org PaleoClim] provides free, high-resolution paleoclimate data for use in biological modeling and GIS.

The data are available at 3 different spatial resolutions; from 2.5 arc-minutes (~5 km), 5 arc-minutes (~10 km), and 10 arc-minutes (~20 km). The CHELSA data are also available in 30 arc-seconds (~1 km). Each download is a “zip” file containing up to 19 GeoTiff (.tif) files, one for each of the bioclimatic variables.

'''Bioclimatic parameters'''

From the high-resolution monthly temperature and precipitation values, a set of derived parameters were calculated, broadly used in ecological applications. These bioclimatic variables are derived from the monthly mean temperature (or minimum and maximum temperature, depending on their availability) and precipitation values. They are specifically developed for species distribution modelling and related ecological applications . The procedure for generating bioclimatic variables followed WorldClim and used the ‘biovars’ function of the R package dismo. Output bioclimate layers were saved as individual GeoTiffs (*tif) and projected in the WGS 1984 projection.

Bio_1=Annual Mean Temperature [°C*10] 
Bio_2=Mean Diurnal Range [°C] 
Bio_3=Isothermality [Bio_2/Bio_7] 
Bio_4=Temperature Seasonality [standard deviation*100] 
Bio_5=Max Temperature of Warmest Month [°C*10] 
Bio_6=Min Temperature of Coldest Month [°C*10] 
Bio_7=Temperature Annual Range [°C*10] 
Bio_8=Mean Temperature of Wettest Quarter [°C*10] 
Bio_9=Mean Temperature of Driest Quarter [°C*10] 
Bio_10=Mean Temperature of Warmest Quarter [°C*10] 
Bio_11=Mean Temperature of Coldest Quarter [°C*10] 
Bio_12=Annual Precipitation [mm/year] 
Bio_13=Precipitation of Wettest Month [mm/month] 
Bio_14=Precipitation of Driest Month [mm/month] 
Bio_15=Precipitation Seasonality [coefficient of variation]v
Bio_16=Precipitation of Wettest Quarter [mm/quarter] 
Bio_17=Precipitation of Driest Quarter [mm/quarter] 
Bio_18=Precipitation of Warmest Quarter [mm/quarter] 
Bio_19=Precipitation of Coldest Quarter [mm/quarter] 

'''Time Periods Represented (bp)'''

Pleistocene: late-Holocene, Meghalayan (4.2-0.3 ka) 
Pleistocene: mid-Holocene, Northgrippian (8.326-4.2 ka) 
Pleistocene: early-Holocene, Greenlandian (11.7-8.326 ka) 
Pleistocene: Younger Dryas Stadial (12.9-11.7 ka) 
Pleistocene: Bølling-Allerød ( 14.7-12.9 ka) 
Pleistocene: Heinrich Stadial 1 (17.0-14.7 ka) 
Pleistocene: Last Interglacial (ca. 130 ka) 
Pleistocene: MIS19 (ca. 787 ka) 
Pliocene: mid-Pliocene warm period (3.205 Ma) 
Pliocene: M2 (ca. 3.3 Ma)

== Population maps ==

=== WorldPop ===

* http://www.worldpop.org.uk/

=== Gridded Population of the World ===

* http://sedac.ciesin.columbia.edu/gpw/global.jsp

Import with {{cmd|r.in.gdal}}, assign population color table with {{cmd|r.colors}}

== Topographic maps ==
=== Soviet topographic maps ===

* [http://en.poehali.org/maps Soviet topographic maps] as geocoded GeoTIFFs

= Vector data =

=== Natural Earth ===

* http://www.naturalearthdata.com/ data scaled for 1:10 million, 1:50 million and 1:110million

=== CDC Geographic Boundary and Public Health Maps ===

* http://www.cdc.gov/epiinfo/maps.htm

=== Global Administrative Areas ===

* GADM is a database of the location of the world's administrative areas (boundaries) available in shapefiles.
: http://gadm.org (extracted by country [http://gadm.org/country here])

* World Borders Dataset including ISO 3166-1 Country codes available in shapefiles.
: http://thematicmapping.org/downloads/world_borders.php
* Free GIS data from Mapping Hacks
: http://mappinghacks.com/data/

=== GSHHS World Coastline ===

GSHHS is a high resolution shoreline dataset. It is derived from data in the public domain and licensed as GPL. The shorelines are constructed entirely from hierarchically arranged closed polygons. It is closely linked to the [[GMT]] project.

==== Availability ====

* Download the original data set from http://www.soest.hawaii.edu/pwessel/gshhg/index.html. Also available at http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhg/latest/.

* The data set, or parts from it, can be extracted from [http://www.ngdc.noaa.gov/mgg/shorelines/shorelines.html NOAA's shoreline extractor].
:For GRASS 6 you can download 1:250,000 shoreline data from NOAA's site in Mapgen format, which can be imported with the {{cmd|v.in.mapgen}} module.

* '''ESRI Shapefiles''' of the latest version are available at http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhg/latest/. The old 1.6 version is available at ftp://ftp.ihg.uni-duisburg.de/GIS/GISData/GSHHS/.

==== Import ====

* Import with the GRASS6 add-on module {{AddonCmd|v.in.gshhs}}

=== OpenStreetMap ===

See the [[OpenStreetMap]] wiki page.

==== Administrative boundaries from OpenStreetMap ====

For a convenient download in GeoJSON and SHAPE, see https://wambachers-osm.website/boundaries/

(using the amost invisible triangle, you can pop out details of a country down to admin level 8)

=== SALB ===

Second Administrative Level Boundaries: ''"The SALB dataset is a global digital dataset consisting of digital maps and codes that can be downloaded on a country by country basis."''

* http://www.who.int/whosis/database/gis/salb/salb_home.htm

=== VMap0 ===

1:1 million vector data. Formerly known as ''Digital Chart of the World''

* see the two articles in [http://grass.osgeo.org/newsletter/index.php ''GRASS Newsletter vol. 3 (June 2005)'']

Check the [http://en.wikipedia.org/wiki/Vector_Map Wikipedia page] on VMAP, see the links at the bottom of that article to shapefile versions of VMAP0 and VMAP1. Those look like the versions that were, several years ago, on a NIMA (predecessor to NGA, and successor to the Defense Mapping Agency that managed the Digital Chart of the World and VMAP project) Website. Many GRASS users may prefer the shapefiles to the original Vector Product Format data.

* [http://gis-lab.info/qa/vmap0-eng.html VMap0 data in ESRI shape format]

= See also =

* [http://spatial-analyst.net/wiki/index.php?title=Global_datasets Global datasets] list by T. Hengl (with dataset download)
* http://freegisdata.rtwilson.com/
* The FreeGIS.org database: http://www.freegis.org/database/
* http://finder.geocommons.com/
* http://wiki.openstreetmap.org/wiki/Potential_Datasources
* http://www.geonames.org/data-sources.html
* [http://ckan.net/tag/read/geo Open Knowledge Foundation link collection]
* [http://openweathermap.org/ Open Weather Map] free weather data and forecast API suitable for any cartographic services like web and smartphones applications. Ideology is inspired by OpenStreetMap and Wikipedia that make information free and available for everybody.

=== Metadata Catalogues ===
Catalog Service for the Web (CSW) is an OGC standard for offering access to catalogues of geospatial information over the Internet (HTTP). CSW allow for discovering, browsing, and querying metadata about data, services, and similar resources. A list of Metadata Catalogues / CSW services from member states of the European Union can be found here: 
* [http://inspire-geoportal.ec.europa.eu/INSPIRERegistry/ http://inspire-geoportal.ec.europa.eu/INSPIRERegistry/] 
And here: [http://inspire-geoportal.ec.europa.eu/discovery/ http://inspire-geoportal.ec.europa.eu/discovery/] one can search European Metadata Catalogues online.

=== European datasets ===

* [[European datasets]]
* [http://preview.grid.unep.ch/index3.php?preview=data&lang=eng Global Risk Data Platform]
* [http://open-data.europa.eu/open-data/data/ European Commission Opendata Portal]: 5800+ datasets
* [http://eca.knmi.nl/download/ensembles/download.php E-OBS] This is the download page for the ENSEMBLES daily gridded observational dataset for precipitation, temperature and sea level pressure in Europe
* [http://mars.jrc.ec.europa.eu/mars/About-us/AGRI4CAST/Data-distribution MARS @ JRC] Temperature, vapour pressure, rainfall, relative humidity, cloud cover, solar radiation, wind speed.
* [http://www.efas.eu/ EFAS @ JRC] is a High resolution pan-European dataset for hydrologic modelling.
* [http://data.jrc.ec.europa.eu/ JRC Data Portal] In this catalogue, you can find an inventory of data that produced by the JRC in accordance with the JRC data policy. The content is continuously updated and shall not be seen as a complete inventory of JRC data. Currently, the inventory describes only a small subset of JRC data.

=== US datasets ===

* [[NLCD Land Cover|NLCD: National land cover database]]
* [[CUSP Coastline|CUSP: NOAA Continually Updated Shoreline]]

=== National datasets ===

* [http://asdd.ga.gov.au/asdd/tech/zap/basic.html Australian Spatial Data Directory]
* [http://aekos.org.au/home Australian Ecological Knowledge and Observation System]
* [http://wiki.gfoss.it/index.php/GIS_Open_Data Italian Geodata collection]
* [http://koordinates.com/ New Zealand] data from Koordinates.com
* United States from NOAA/USGSs data portal (FIXME: link?)
* [http://geodata.gov.gr/geodata/ Greek Public Geodata] (in Greek)

=== Various datasets worldwide ===

* [http://geospatial.edublogs.org/ GEOSPATIAL DATA REPORT]: Finding and Using GIS Data
* [http://www.edenextdata.com/?q=data Edenext data portal]: Land Cover, Transport networks, Elevation, Orthoimagery, Human health and safety, Species Distribution, Atmospheric Conditions and Meteorological Geographical Features, Training Program Presentations and Data, Utility and governmental services, Hydrography, Soil, Bio geographical regions, Population distribution and Demographics
* [http://gdex.cr.usgs.gov/gdex/ Global Data Explorer USGS]: ASTER, SRTM, GTOPO etc
* [http://www.landcover.org/ landcover]
* [http://www.gripweb.org/gripweb/?q=data-information GRIPWEB’s Data & Informational Portal]: hazard & risk
* [http://sedac.ciesin.columbia.edu/data/sets/browse SEDAC]: Agriculture, Climate, Conservation, Framework Data, Governance, Hazards, Health, Infrastructure, Land Use, Marine and Coastal, Population, Poverty, Remote Sensing, Sustainability, Urban, Water
* [http://www.preventionweb.net/english/professional/maps/?pid:6&pih:2 Prevention Web]: hazard & risk
* [http://data.un.org/Default.aspx UNdata]: UN database
* [http://www.undp.org/content/undp/en/home.html UNDP home page]
* [http://www.cgiar-csi.org/data global climatic data]
* [http://csi.cgiar.org/cgiargeospatialtools.asp cosortium for spatial information CGIAR-CSI GeoSpatial Toolkits]
* [http://freegisdata.rtwilson.com/ Links to over 300 sites providing freely available geographic datasets]
* [http://www.diva-gis.org/Data Free Spatial Data]
* [http://edc2.usgs.gov/glcc/globe_int.php Global Land Cover Characteristics Data Base Version 2.0]
* [http://opentopo.sdsc.edu/gridsphere/gridsphere?cid=datasets A Portal to High-Resolution Topography Data and Tools]
* [http://www.metoffice.gov.uk/hadobs/hadghcnd/ HadGHCND] is a gridded daily temperature dataset based upon near-surface maximum (TX) and minimum (TN) temperature observations.

=== WMS servers ===

* See [[WMS]] page

=== River discharge data ===

* [http://www.bafg.de/GRDC/EN/Home/homepage_node.html Global Runoff Data Centre]
* [http://www.sage.wisc.edu/riverdata/ Global River Discharge Database]
* [http://csdms.colorado.edu/wiki/River_discharge_data CSDMS]

[[Category: Geodata]]
[[Category: Import]]

Installation Guide

2020-07-01T19:22:08Z

⚠️Cmbarton: /* macOS */ fixing section heading

== General ==
:''For compilation of GRASS GIS source code, see [[Compile and Install]]''
This page explains the installation of GRASS binaries.

GRASS GIS requires a workstation running either some flavor of UNIX conforming to POSIX standards like Linux, Mac OS X, Solaris, IRIX, or BSD or MS-Windows. It is also possible to run GRASS in MS Windows by using UNIX translation software such as [[Cygwin]] or natively with MingGW. Ideally, you should have at least 500 Mb for data and 512 Mb RAM. The source code package needs around 270 MB uncompressed. The resulting binaries may need between 20 MB and 180 MB depending on your platform. During a full compilation you may need temporarily up to 150MB including the source code.

The [http://grass.osgeo.org/download/ Software Download Section] of the main GRASS web site contains the latest binaries and source code for all supported platforms. That site also has general directions for installing GRASS manually. However, installation is slightly different on each operating system. Here you can find user-contributed pointers for installing GRASS on specific platforms. In particular, many operating systems have package management utilities that can greatly simplify GRASS installation.

== MS Windows ==

:''The official page [http://grass.osgeo.org/download/software/ms-windows/ GRASS GIS Download for MS-Windows]''

* Native winGRASS packages (including the installer) are provided [http://grass.osgeo.org/grass64/binary/mswindows/native/ here]. See also [[WinGRASS Current Status]].

* winGRASS/Cygwin packages are provided [http://grass.osgeo.org/grass64/binary/mswindows/cygwin/ here] (requires [[Cygwin]] UNIX emulator, see there).

* QGIS including native winGRASS packages are provided [http://www.qgis.org/wiki/Download here].

* Install using [http://trac.osgeo.org/osgeo4w/ OSGeo4W installer] (GRASS 6 needs to be checked in the "Express" install. GRASS 7 needs to be selected in the "Advanced" installation.)

== GNU/Linux ==

:''The official page [http://grass.osgeo.org/download/software/linux/ GRASS GIS Download for GNU/Linux]''

=== Debian ===

A binary version of GRASS is available from the apt repository. As root type:

apt-get install grass grass-doc

This is the easiest way to install GRASS on Debian. If you choose to install a binary version manually from the main web site, be sure to follow the instructions for making symlinks found as a note to the [[http://grass.osgeo.org/grass64/binary/linux/snapshot/ 6.4 weekly snapshot]] release.

==== DebianGis ====

There is also the wonderful [http://wiki.debian.org/DebianGis DebianGIS] project which has a more recent GRASS version with its related packages. Read here for more [[GRASS in Debian |details]]

==== Compiling GRASS from source ====

* See [[Compile and Install]] of Source Code

=== Installation on Fedora ===

[https://admin.fedoraproject.org/pkgdb/acls/name/grass Fedoraproject] provides RPM-packages for stable releases prepared to install on Fedora systems:

<source lang="bash">
yum install grass
</source>

=== Mandriva ===

* [http://sophie.zarb.org/srpm/cooker,ia64/grass Mandriva] provides PROJ/GDAL/GRASS RPMs. Newer versions they are in the "backports" section:

urpmi grass

=== openSUSE ===

* [http://download.opensuse.org/repositories/Application:/Geo/ openSUSE] provides GRASS and related RPM-packages.

'''GRASS 6:''' To install GRASS 6 release on openSUSE:

From terminal:

<source lang="bash">
sudo zypper ar http://download.opensuse.org/repositories/Application:/Geo/openSUSE_12.3/ GEO
sudo zypper refresh
sudo zypper install grass
</source>

Alternatively, one can use the '''One-Click installer''':
http://software.opensuse.org/package/grass

'''GRASS 7:''' To install the latest GRASS 7 SVN snapshot:

<source lang="bash">
sudo zypper refresh
sudo zypper install grass7
</source>

Alternatively, one can use the '''One-Click installer''':
http://software.opensuse.org/package/grass7

=== Red Hat Enterprise Linux (RHEL, CentOS and Scientific Linux) ===

* [http://wiki.osgeo.org/wiki/Enterprise_Linux_GIS Enterprise Linux] offers GRASS and related binaries

<source lang="bash">
yum install grass
</source>

=== Ubuntu ===

GRASS Binaries are available from apt/synaptic. From a terminal type:

sudo apt-get install grass grass-doc

or alternatively, search for and install these packages from Synaptic. This is the easy way to get GRASS on your system. Even if you choose to install binaries from another source, you may want to install this version just so that all (most) dependencies are installed as painlessly as possible.

To get the latest version of GRASS on Ubuntu, compile the code from source. See the [[Compile and Install]] section for a shell script that makes this easy.

=== Slackware ===

Slackware 12 packages for GRASS binary distributions and additional libraries are available from [http://repository.slacky.eu/slackware-12.2/scientific/grass The Italian Slackware Community] (release version) and [http://geni.ath.cx/grass.html#_Slackware_12_binary_distributions here] (SVN version).

=== Raspberry Pi ===

:''See the main page [[Raspberry Pi]].''

=== MacOS ===

Precompiled GRASS 6 and GRASS 7 packages for macOS can be found [http://grass.osgeo.org/download/software/mac-osx/ here]. These are distributed as zipped *.dmg packages. Opening the dmg prompts the user to simply drag and drop the app into the Applications folder. In fact, they '''must''' be installed into the Applications folder and may not run properly in other locations.

A brief introduction to how to install via [https://www.macports.org MacPorts]: [[Compiling on macOS using MacPorts]].

[[Category:Documentation]]
[[Category:Installation]]

Installation Guide

2020-07-01T19:21:42Z

⚠️Cmbarton: /* macOS */ Fixed formatting of the section heading

== General ==
:''For compilation of GRASS GIS source code, see [[Compile and Install]]''
This page explains the installation of GRASS binaries.

GRASS GIS requires a workstation running either some flavor of UNIX conforming to POSIX standards like Linux, Mac OS X, Solaris, IRIX, or BSD or MS-Windows. It is also possible to run GRASS in MS Windows by using UNIX translation software such as [[Cygwin]] or natively with MingGW. Ideally, you should have at least 500 Mb for data and 512 Mb RAM. The source code package needs around 270 MB uncompressed. The resulting binaries may need between 20 MB and 180 MB depending on your platform. During a full compilation you may need temporarily up to 150MB including the source code.

The [http://grass.osgeo.org/download/ Software Download Section] of the main GRASS web site contains the latest binaries and source code for all supported platforms. That site also has general directions for installing GRASS manually. However, installation is slightly different on each operating system. Here you can find user-contributed pointers for installing GRASS on specific platforms. In particular, many operating systems have package management utilities that can greatly simplify GRASS installation.

== MS Windows ==

:''The official page [http://grass.osgeo.org/download/software/ms-windows/ GRASS GIS Download for MS-Windows]''

* Native winGRASS packages (including the installer) are provided [http://grass.osgeo.org/grass64/binary/mswindows/native/ here]. See also [[WinGRASS Current Status]].

* winGRASS/Cygwin packages are provided [http://grass.osgeo.org/grass64/binary/mswindows/cygwin/ here] (requires [[Cygwin]] UNIX emulator, see there).

* QGIS including native winGRASS packages are provided [http://www.qgis.org/wiki/Download here].

* Install using [http://trac.osgeo.org/osgeo4w/ OSGeo4W installer] (GRASS 6 needs to be checked in the "Express" install. GRASS 7 needs to be selected in the "Advanced" installation.)

== GNU/Linux ==

:''The official page [http://grass.osgeo.org/download/software/linux/ GRASS GIS Download for GNU/Linux]''

=== Debian ===

A binary version of GRASS is available from the apt repository. As root type:

apt-get install grass grass-doc

This is the easiest way to install GRASS on Debian. If you choose to install a binary version manually from the main web site, be sure to follow the instructions for making symlinks found as a note to the [[http://grass.osgeo.org/grass64/binary/linux/snapshot/ 6.4 weekly snapshot]] release.

==== DebianGis ====

There is also the wonderful [http://wiki.debian.org/DebianGis DebianGIS] project which has a more recent GRASS version with its related packages. Read here for more [[GRASS in Debian |details]]

==== Compiling GRASS from source ====

* See [[Compile and Install]] of Source Code

=== Installation on Fedora ===

[https://admin.fedoraproject.org/pkgdb/acls/name/grass Fedoraproject] provides RPM-packages for stable releases prepared to install on Fedora systems:

<source lang="bash">
yum install grass
</source>

=== Mandriva ===

* [http://sophie.zarb.org/srpm/cooker,ia64/grass Mandriva] provides PROJ/GDAL/GRASS RPMs. Newer versions they are in the "backports" section:

urpmi grass

=== openSUSE ===

* [http://download.opensuse.org/repositories/Application:/Geo/ openSUSE] provides GRASS and related RPM-packages.

'''GRASS 6:''' To install GRASS 6 release on openSUSE:

From terminal:

<source lang="bash">
sudo zypper ar http://download.opensuse.org/repositories/Application:/Geo/openSUSE_12.3/ GEO
sudo zypper refresh
sudo zypper install grass
</source>

Alternatively, one can use the '''One-Click installer''':
http://software.opensuse.org/package/grass

'''GRASS 7:''' To install the latest GRASS 7 SVN snapshot:

<source lang="bash">
sudo zypper refresh
sudo zypper install grass7
</source>

Alternatively, one can use the '''One-Click installer''':
http://software.opensuse.org/package/grass7

=== Red Hat Enterprise Linux (RHEL, CentOS and Scientific Linux) ===

* [http://wiki.osgeo.org/wiki/Enterprise_Linux_GIS Enterprise Linux] offers GRASS and related binaries

<source lang="bash">
yum install grass
</source>

=== Ubuntu ===

GRASS Binaries are available from apt/synaptic. From a terminal type:

sudo apt-get install grass grass-doc

or alternatively, search for and install these packages from Synaptic. This is the easy way to get GRASS on your system. Even if you choose to install binaries from another source, you may want to install this version just so that all (most) dependencies are installed as painlessly as possible.

To get the latest version of GRASS on Ubuntu, compile the code from source. See the [[Compile and Install]] section for a shell script that makes this easy.

=== Slackware ===

Slackware 12 packages for GRASS binary distributions and additional libraries are available from [http://repository.slacky.eu/slackware-12.2/scientific/grass The Italian Slackware Community] (release version) and [http://geni.ath.cx/grass.html#_Slackware_12_binary_distributions here] (SVN version).

=== Raspberry Pi ===

:''See the main page [[Raspberry Pi]].''

=== macOS ===

Precompiled GRASS 6 and GRASS 7 packages for macOS can be found [http://grass.osgeo.org/download/software/mac-osx/ here]. These are distributed as zipped *.dmg packages. Opening the dmg prompts the user to simply drag and drop the app into the Applications folder. In fact, they '''must''' be installed into the Applications folder and may not run properly in other locations.

A brief introduction to how to install via [https://www.macports.org MacPorts]: [[Compiling on macOS using MacPorts]].

[[Category:Documentation]]
[[Category:Installation]]

Installation Guide

2020-07-01T19:19:14Z

⚠️Cmbarton: /* macOS */ added information about installing binaries.

== General ==
:''For compilation of GRASS GIS source code, see [[Compile and Install]]''
This page explains the installation of GRASS binaries.

GRASS GIS requires a workstation running either some flavor of UNIX conforming to POSIX standards like Linux, Mac OS X, Solaris, IRIX, or BSD or MS-Windows. It is also possible to run GRASS in MS Windows by using UNIX translation software such as [[Cygwin]] or natively with MingGW. Ideally, you should have at least 500 Mb for data and 512 Mb RAM. The source code package needs around 270 MB uncompressed. The resulting binaries may need between 20 MB and 180 MB depending on your platform. During a full compilation you may need temporarily up to 150MB including the source code.

The [http://grass.osgeo.org/download/ Software Download Section] of the main GRASS web site contains the latest binaries and source code for all supported platforms. That site also has general directions for installing GRASS manually. However, installation is slightly different on each operating system. Here you can find user-contributed pointers for installing GRASS on specific platforms. In particular, many operating systems have package management utilities that can greatly simplify GRASS installation.

== MS Windows ==

:''The official page [http://grass.osgeo.org/download/software/ms-windows/ GRASS GIS Download for MS-Windows]''

* Native winGRASS packages (including the installer) are provided [http://grass.osgeo.org/grass64/binary/mswindows/native/ here]. See also [[WinGRASS Current Status]].

* winGRASS/Cygwin packages are provided [http://grass.osgeo.org/grass64/binary/mswindows/cygwin/ here] (requires [[Cygwin]] UNIX emulator, see there).

* QGIS including native winGRASS packages are provided [http://www.qgis.org/wiki/Download here].

* Install using [http://trac.osgeo.org/osgeo4w/ OSGeo4W installer] (GRASS 6 needs to be checked in the "Express" install. GRASS 7 needs to be selected in the "Advanced" installation.)

== GNU/Linux ==

:''The official page [http://grass.osgeo.org/download/software/linux/ GRASS GIS Download for GNU/Linux]''

=== Debian ===

A binary version of GRASS is available from the apt repository. As root type:

apt-get install grass grass-doc

This is the easiest way to install GRASS on Debian. If you choose to install a binary version manually from the main web site, be sure to follow the instructions for making symlinks found as a note to the [[http://grass.osgeo.org/grass64/binary/linux/snapshot/ 6.4 weekly snapshot]] release.

==== DebianGis ====

There is also the wonderful [http://wiki.debian.org/DebianGis DebianGIS] project which has a more recent GRASS version with its related packages. Read here for more [[GRASS in Debian |details]]

==== Compiling GRASS from source ====

* See [[Compile and Install]] of Source Code

=== Installation on Fedora ===

[https://admin.fedoraproject.org/pkgdb/acls/name/grass Fedoraproject] provides RPM-packages for stable releases prepared to install on Fedora systems:

<source lang="bash">
yum install grass
</source>

=== Mandriva ===

* [http://sophie.zarb.org/srpm/cooker,ia64/grass Mandriva] provides PROJ/GDAL/GRASS RPMs. Newer versions they are in the "backports" section:

urpmi grass

=== openSUSE ===

* [http://download.opensuse.org/repositories/Application:/Geo/ openSUSE] provides GRASS and related RPM-packages.

'''GRASS 6:''' To install GRASS 6 release on openSUSE:

From terminal:

<source lang="bash">
sudo zypper ar http://download.opensuse.org/repositories/Application:/Geo/openSUSE_12.3/ GEO
sudo zypper refresh
sudo zypper install grass
</source>

Alternatively, one can use the '''One-Click installer''':
http://software.opensuse.org/package/grass

'''GRASS 7:''' To install the latest GRASS 7 SVN snapshot:

<source lang="bash">
sudo zypper refresh
sudo zypper install grass7
</source>

Alternatively, one can use the '''One-Click installer''':
http://software.opensuse.org/package/grass7

=== Red Hat Enterprise Linux (RHEL, CentOS and Scientific Linux) ===

* [http://wiki.osgeo.org/wiki/Enterprise_Linux_GIS Enterprise Linux] offers GRASS and related binaries

<source lang="bash">
yum install grass
</source>

=== Ubuntu ===

GRASS Binaries are available from apt/synaptic. From a terminal type:

sudo apt-get install grass grass-doc

or alternatively, search for and install these packages from Synaptic. This is the easy way to get GRASS on your system. Even if you choose to install binaries from another source, you may want to install this version just so that all (most) dependencies are installed as painlessly as possible.

To get the latest version of GRASS on Ubuntu, compile the code from source. See the [[Compile and Install]] section for a shell script that makes this easy.

=== Slackware ===

Slackware 12 packages for GRASS binary distributions and additional libraries are available from [http://repository.slacky.eu/slackware-12.2/scientific/grass The Italian Slackware Community] (release version) and [http://geni.ath.cx/grass.html#_Slackware_12_binary_distributions here] (SVN version).

=== Raspberry Pi ===

:''See the main page [[Raspberry Pi]].''

== macOS ==

Precompiled GRASS 6 and GRASS 7 packages for macOS can be found [http://grass.osgeo.org/download/software/mac-osx/ here]. These are distributed as zipped *.dmg packages. Opening the dmg prompts the user to simply drag and drop the app into the Applications folder. In fact, they '''must''' be installed into the Applications folder and may not run properly in other locations.

A brief introduction to how to install via [https://www.macports.org MacPorts]: [[Compiling on macOS using MacPorts]].

[[Category:Documentation]]
[[Category:Installation]]

Compiling on macOS using Anaconda

2020-06-05T16:39:32Z

⚠️Cmbarton: added a note about Miniconda Python installation.

== Using Anaconda to Create a Binary Mac App for GRASS ==
These instructions are for creating a self-contained Mac app, including all dependencies, with GRASS 7.9 and Anaconda. You can modify them if you don't need some of the steps. Some of the steps you won't need to repeat (e.g., creating an anaconda environment). You must first install the [https://www.anaconda.com '''Anaconda package'''] for Python. You will of course need to download a copy of the [https://grass.osgeo.org/download/ '''GRASS source code''']. You will also need to install Apple's '''XCode''' and the '''command-line tools''' to compile sofware. This workflow can be used with MacOS 10.14 and 10.15. It may work with other versions, but has not been tested.

You will need to work from the '''Mac terminal''' to compile GRASS of course. This tutorial assumes you are familiare with this command line interface.

This process also requires some patches and other supporting files. You can download these here: [[File:Grass_macapp_anaconda_supporting_files.zip]]

=== 1. Create a Mac app shell (I have uploaded an example for GRASS 7.9 you can use as is, modified from shells created by Eric Hutton). ===
This can be modified serve for different versions of GRASS by altering the last line of the script that launches GRASS in the app shell. To do this, you will need to look inside the app by Ctrl-clicking on it and selecting ''''"show package contents"'''', which reveals the app as a folder with other folders and files inside.

For example, to make a shell for GRASS 7.8, copy the uploaded ''''GRASS-7.9.app'''' and rename it to ''''GRASS-7.8.app''''
Then show package contents for ''''GRASS-7.8.app'''' and use a text editor to modify the last line of the file ''''../GRASS-7.8.app/Contents/MacOS/Grass.sh'''' to refer to GRASS 7.8

change: "$GRASS_PYTHON" "$GISBASE/bin/grass79" "-gui" "$@"
to: "$GRASS_PYTHON" "$GISBASE/bin/grass78" "-gui" "$@"

Also, use a text editor to modify ''''../GRASS-7.9.app/Contents/Info.plist''' to change all references to 7.9 to 7.8.

=== 2. Create an Anaconda environment for Python 3.6.10 ===
This may not be strictly necessary, but I am doing it make sure that my builds use Python 3 instead of Python 2.7, which is still what ships with the Mac.

Anaconda defaults to Python 3.7.6, which will not compile GRASS properly. This makes it more complicated than needed, requiring some workarounds. I've tried this with multiple versions of Python 3 (anaconda has them all the way up to 3.8.2), but the highest version that seems to give consistently successful results is 3.6.10. This will probably change in the future so that you can use a higher version of Python.

Here is how to create an Anaconda environment for Python 3.6.10. You only need to do this once for each environment you want to use.
<pre>
conda create anaconda_p36 python==3.6.10 anaconda
</pre>

=== 3. Activate the Anaconda Python 3.6.10 environment ===
<pre>
conda activate anaconda_p36
</pre>
You can activate any previously created Anaconda environment in this way

=== 4. Copy the Mac app shell to /Applications ===
<pre>
cp -r ../GRASS-7.9.app /Applications/GRASS-7.9.app
</pre>

=== 5. Download the Python 3 miniconda installer and use it to install a minimal anaconda environment into the Mac app shell ===
Even if you are working in an Anaconda environment with Python 3.6.10, miniconda currently installs Python 3.7.6 into the Mac app shell. So you will need to downgrade this in step 7 below. This will probably change in the future so that miniconda installs a higher Python version.

<pre>
curl https://repo.continuum.io/miniconda/Miniconda3-latest-MacOSX-x86_64.sh > miniconda3.sh
bash ./miniconda3.sh -b -f -p /Applications/GRASS-7.9.app/Contents/Resources
</pre>

=== 6. Export the path to the GRASS Mac app shell so that subsequent operations use the environment of that shell ===

<pre>
export PATH=/Applications/GRASS-7.9.app/Contents/Resources/bin:$PATH
</pre>

=== 7. Install GRASS dependencies into Mac app shell, including Python 3.6.10 ===
A requirements file can make all of these dependencies easier to install. One is included in the supporting files package. This will downgrade Python from v. 3.7.6 installed by miniconda to the more useable 3.6.10.
<pre>
conda install --yes -p "/Applications/GRASS-7.9.app/Contents/Resources" --file=requirements_wxp4p36.txt -c conda-forge
</pre>

=== 8. Create a symlink to Python so that pythonw can find it (may become unneeded in the future) ===
Grass launches Python through the pythonw script. But the script does not point to the correct location for Python (which is in fact in 2 different places). This seems to be a bug in Python < 3.7.4 or how anaconda installs it. It puts the python launch file in the wrong place. So a symlink is needed. Hopefully this will go away when we can use Python > 3.7.6, which seems to put python in the correct place, and the place that pythonw points to.
<pre>
ln -sf /Applications/GRASS-7.8.app/Contents/Resources/python.app/pythonapp/Contents/* /Applications/GRASS-7.8.app/Contents/Resources/python.app/Contents
</pre>

=== 9. cd to the grass source folder and apply patches to configure and make files ===
Eric Hutton at CSDMS worked out these patches and I modified one needed to use Python 3. Maybe they can be worked into the source code so that they are no longer needed. I will upload the patches along with the app shell and requirements file.
<pre>
patch -p0 < aclocal.m4.patch
patch -p0 < configure.patch
patch -p0 < install.make.patch
patch -p0 < loader.py.patch
patch -p0 < module.make.patch
patch -p0 < platform.make.in.patch
patch -p0 < rules.make.patch
patch -p0 < shlib.make.patch
</pre>

=== 10. Configure, make, and install ===
An example configure script is included in the grass supporting files package. It flags all dependencies and sets the correct path so that they can be found. '''Important''': this configure script has a hard path to the SDK (software developer kit) that comes with XCode. You can set different path if you've put you SDK in a different place.
<pre>
bash ../configure.sh
make -j4 GDAL_DYNAMIC=
make -j4 install
</pre>

Assuming there were no errors, you should now be able to run and test the GRASS-7.9.app in your /Applications folder

=== 11. Clean up ===
This removes unneeded anaconda package installer files and some other large files that are irrelevant for GRASS. It makes the app much smaller (though still large because of Python, wxPython, and other dependencies are packaged inside)

<pre>
conda clean --all -y
rm -r /Applications/GRASS-7.9.app/Contents/Resources/mkspecs
rm -r /Applications/GRASS-7.9.app/Contents/Resources/phrasebooks
rm -r /Applications/GRASS-7.9.app/Contents/Resources/pkgs
rm -r /Applications/GRASS-7.9.app/Contents/Resources/plugins
rm -r /Applications/GRASS-7.9.app/Contents/Resources/qml
rm -r /Applications/GRASS-7.9.app/Contents/Resources/resources
rm -r /Applications/GRASS-7.9.app/Contents/Resources/translations
rm /Applications/GRASS-7.9.app/Contents/Resources/lib/libQt*
</pre>

== Optional: create a binary distribution package ==
=== 12. Set up folder to make a binary package for distribution ===
Put a copy of the new GRASS app and a symlink to the /Applications folder into a new folder that will become the distribution package.

<pre>
mkdir ../binary_pkg/grass-7.9
cd ../binary_pkg/grass-7.9
cp -R /Applications/GRASS-7.9.app ./
ln -s /Applications Applications
</pre>

=== 13. Use Disk Utility to make a distribution package ===
* Open disk Utility
* From the make file/new image menu, select image from from folder
* Point it to the folder with the app and symlink to /Applications and tell it to make an image ''''GRASS-7.9.dmg''''.

[[Category:Development]]
[[Category:Documentation]]
[[Category:Installation]]

Compiling on macOS using Anaconda

2020-06-03T17:35:01Z

⚠️Cmbarton: adding links to related pages and improving URL formatting

== Using Anaconda to Create a Binary Mac App for GRASS ==
These instructions are for creating a self-contained Mac app, including all dependencies, with GRASS 7.9 and Anaconda. You can modify them if you don't need some of the steps. Some of the steps you won't need to repeat (e.g., creating an anaconda environment). You must first install the [https://www.anaconda.com '''Anaconda package'''] for Python. You will of course need to download a copy of the [https://grass.osgeo.org/download/ '''GRASS source code''']. You will also need to install Apple's '''XCode''' and the '''command-line tools''' to compile sofware. This workflow can be used with MacOS 10.14 and 10.15. It may work with other versions, but has not been tested.

You will need to work from the '''Mac terminal''' to compile GRASS of course. This tutorial assumes you are familiare with this command line interface.

This process also requires some patches and other supporting files. You can download these here: [[File:Grass_macapp_anaconda_supporting_files.zip]]

=== 1. Create a Mac app shell (I have uploaded an example for GRASS 7.9 you can use as is, modified from shells created by Eric Hutton). ===
This can be modified serve for different versions of GRASS by altering the last line of the script that launches GRASS in the app shell. To do this, you will need to look inside the app by Ctrl-clicking on it and selecting ''''"show package contents"'''', which reveals the app as a folder with other folders and files inside.

For example, to make a shell for GRASS 7.8, copy the uploaded ''''GRASS-7.9.app'''' and rename it to ''''GRASS-7.8.app''''
Then show package contents for ''''GRASS-7.8.app'''' and use a text editor to modify the last line of the file ''''../GRASS-7.8.app/Contents/MacOS/Grass.sh'''' to refer to GRASS 7.8

change: "$GRASS_PYTHON" "$GISBASE/bin/grass79" "-gui" "$@"
to: "$GRASS_PYTHON" "$GISBASE/bin/grass78" "-gui" "$@"

Also, use a text editor to modify ''''../GRASS-7.9.app/Contents/Info.plist''' to change all references to 7.9 to 7.8.

=== 2. Create an Anaconda environment for Python 3.6.10 ===
This may not be strictly necessary, but I am doing it make sure that my builds use Python 3 instead of Python 2.7, which is still what ships with the Mac.

Anaconda defaults to Python 3.7.6, which will not compile GRASS properly. This makes it more complicated than needed, requiring some workarounds. I've tried this with multiple versions of Python 3 (anaconda has them all the way up to 3.8.2), but the highest version that seems to give consistently successful results is 3.6.10. This will probably change in the future so that you can use a higher version of Python.

Here is how to create an Anaconda environment for Python 3.6.10. You only need to do this once for each environment you want to use.
<pre>
conda create anaconda_p36 python==3.6.10 anaconda
</pre>

=== 3. Activate the Anaconda Python 3.6.10 environment ===
<pre>
conda activate anaconda_p36
</pre>
You can activate any previously created Anaconda environment in this way

=== 4. Copy the Mac app shell to /Applications ===
<pre>
cp -r ../GRASS-7.9.app /Applications/GRASS-7.9.app
</pre>

=== 5. Download the Python 3 miniconda installer and use it to install a minimal anaconda environment into the Mac app shell ===

<pre>
curl https://repo.continuum.io/miniconda/Miniconda3-latest-MacOSX-x86_64.sh > miniconda3.sh
bash ./miniconda3.sh -b -f -p /Applications/GRASS-7.9.app/Contents/Resources
</pre>

=== 6. Export the path to the GRASS Mac app shell so that subsequent operations use the environment of that shell ===

<pre>
export PATH=/Applications/GRASS-7.9.app/Contents/Resources/bin:$PATH
</pre>

=== 7. Install GRASS dependencies into Mac app shell, including Python 3.6.10 ===
A requirements file can make all of these dependencies easier to install. One is included in the supporting files package. This will downgrade Python from v. 3.7.6 installed by miniconda to the more useable 3.6.10.
<pre>
conda install --yes -p "/Applications/GRASS-7.9.app/Contents/Resources" --file=requirements_wxp4p36.txt -c conda-forge
</pre>

=== 8. Create a symlink to Python so that pythonw can find it (may become unneeded in the future) ===
Grass launches Python through the pythonw script. But the script does not point to the correct location for Python (which is in fact in 2 different places). This seems to be a bug in Python < 3.7.4 or how anaconda installs it. It puts the python launch file in the wrong place. So a symlink is needed. Hopefully this will go away when we can use Python > 3.7.6, which seems to put python in the correct place, and the place that pythonw points to.
<pre>
ln -sf /Applications/GRASS-7.8.app/Contents/Resources/python.app/pythonapp/Contents/* /Applications/GRASS-7.8.app/Contents/Resources/python.app/Contents
</pre>

=== 9. cd to the grass source folder and apply patches to configure and make files ===
Eric Hutton at CSDMS worked out these patches and I modified one needed to use Python 3. Maybe they can be worked into the source code so that they are no longer needed. I will upload the patches along with the app shell and requirements file.
<pre>
patch -p0 < aclocal.m4.patch
patch -p0 < configure.patch
patch -p0 < install.make.patch
patch -p0 < loader.py.patch
patch -p0 < module.make.patch
patch -p0 < platform.make.in.patch
patch -p0 < rules.make.patch
patch -p0 < shlib.make.patch
</pre>

=== 10. Configure, make, and install ===
An example configure script is included in the grass supporting files package. It flags all dependencies and sets the correct path so that they can be found. '''Important''': this configure script has a hard path to the SDK (software developer kit) that comes with XCode. You can set different path if you've put you SDK in a different place.
<pre>
bash ../configure.sh
make -j4 GDAL_DYNAMIC=
make -j4 install
</pre>

Assuming there were no errors, you should now be able to run and test the GRASS-7.9.app in your /Applications folder

=== 11. Clean up ===
This removes unneeded anaconda package installer files and some other large files that are irrelevant for GRASS. It makes the app much smaller (though still large because of Python, wxPython, and other dependencies are packaged inside)

<pre>
conda clean --all -y
rm -r /Applications/GRASS-7.9.app/Contents/Resources/mkspecs
rm -r /Applications/GRASS-7.9.app/Contents/Resources/phrasebooks
rm -r /Applications/GRASS-7.9.app/Contents/Resources/pkgs
rm -r /Applications/GRASS-7.9.app/Contents/Resources/plugins
rm -r /Applications/GRASS-7.9.app/Contents/Resources/qml
rm -r /Applications/GRASS-7.9.app/Contents/Resources/resources
rm -r /Applications/GRASS-7.9.app/Contents/Resources/translations
rm /Applications/GRASS-7.9.app/Contents/Resources/lib/libQt*
</pre>

== Optional: create a binary distribution package ==
=== 12. Set up folder to make a binary package for distribution ===
Put a copy of the new GRASS app and a symlink to the /Applications folder into a new folder that will become the distribution package.

<pre>
mkdir ../binary_pkg/grass-7.9
cd ../binary_pkg/grass-7.9
cp -R /Applications/GRASS-7.9.app ./
ln -s /Applications Applications
</pre>

=== 13. Use Disk Utility to make a distribution package ===
* Open disk Utility
* From the make file/new image menu, select image from from folder
* Point it to the folder with the app and symlink to /Applications and tell it to make an image ''''GRASS-7.9.dmg''''.

[[Category:Development]]
[[Category:Documentation]]
[[Category:Installation]]

Compile and Install

2020-06-03T15:56:00Z

⚠️Cmbarton: add link to page on compiling Mac app with Anaconda

'''Disclaimer''': This page explains how to turn the GRASS GIS source code into an installable binary package ("compilation") for different operating systems. If you just want to get ready-to-use binaries, go [https://grass.osgeo.org/download/ here], otherwise read on...

== How to do compilation and installation of GRASS GIS? ==

Here we explain the procedure to compile GRASS from GitHub, but it also applies to official GRASS 7 releases.

''For installation of precompiled binary packages, see the main [[Installation Guide]].''

For detailed information on compilation, please see the [https://github.com/OSGeo/grass/blob/master/INSTALL INSTALL] file in the source code.

=== Prerequisites ===

==== Extra libraries ====
GRASS GIS needs at least two extra libraries: PROJ and GDAL/OGR. It is recommended to download them as ready-to-use packages for your software platform (Linux distribution, Windows, Mac...).

Other libraries needed to run GRASS are listed on the [http://htmlpreview.github.io/?https://github.com/OSGeo/grass/blob/master/REQUIREMENTS.html requirements page].

To compile, you will also need the respective "-devel" packages; see below for details.

==== Download GRASS GIS source code ====

First, [https://grass.osgeo.org/download/software/sources/ download the GRASS GIS source code].

=== Generic Compilation and installation procedure ===

* It is wise that compilation processes are carried out as a normal user: If you want to get the source code in a place where you do not have write permissions (e.g. in /usr/local/src/) just follow this:
cd /usr/local/src/
su -c 'mkdir grass7'
su -c 'chown yourlogin:yourgroup grass7'

Otherwise if you have permissions just continue as a normal user:
mkdir $HOME/src
cd $HOME/src/
git clone https://github.com/OSGeo/grass.git grass_master

* run configure with parameters to adapt the compile process to your own system. To see what options can be passed to it, run:
./configure --help | less


It may (!) look like this:

./configure \
--with-cxx \
--with-sqlite \
--with-python \
--with-geos \
--with-gdal=/usr/bin/gdal-config \
--with-cairo --with-cairo-ldflags=-lfontconfig \
--with-freetype \
--with-freetype-includes=/usr/include/freetype2 \
--with-proj --with-proj-share=/usr/share/proj

You may have to explicitly state the path for certain packages (i.e., gdal). The Unix 'locate' command will come in handy for finding the path of the package you need (you may have to run locate as root ex: sudo locate gdal-config).

Please note that the paths mentioned may widely vary due to the distribution used.
See [[Compile_and_Install#Platform_Specific_Notes|Platform Specific Notes]] below.

Depending on your needs it may be a good idea to include debugging hooks.
: See [[GRASS_Debugging#Compile_Time_Setup]].
CFLAGS="-ggdb -Wall -Werror-implicit-function-declaration" ./configure ...

At the end of configuration process you should get report not much different from this:

GRASS is now configured for: x86_64-pc-linux-gnu

Source directory: /home/user/software/grass_master
Build directory: /home/user/software/grass_master
Installation directory: ${prefix}/grass79
Startup script in directory:${exec_prefix}/bin
C compiler: gcc -O2 -march=native -std=gnu99 -fexceptions -fstack-protector -m64 -fdiagnostics-color
C++ compiler: c++ -g -Wall
Building shared libraries: yes
OpenGL platform: X11

MacOSX application: no
MacOSX architectures:
MacOSX SDK:

BLAS support: yes
BZIP2 support: no
C++ support: yes
Cairo support: yes
DWG support: no
FFTW support: yes
FreeType support: yes
GDAL support: yes
GEOS support: yes
[...]

* Let's compile it (takes a little while...)!
make -j2
* At the end, you should get report not much different from this:
----------------------------------------------------------------------
Following modules are missing the 'description.html' file in src code:
----------------------------------------------------------------------
GRASS GIS compilation log
-------------------------
Started compilation: Mon 19 Aug 2019 10:47:57 PM CEST
--
Errors in:
No errors detected.
--
Finished compilation: Mon 19 Aug 2019 10:55:12 PM CEST
(In case of errors please change into the directory with error and run 'make')

* If there is any error, change directory to directory with error and run "make" again. Report occurring bug to GRASS mailing list
* Once the installation process is finished, you're ready to install GRASS system wide.
su -c 'make install'
* enjoy GRASS:
grass79

=== What else? ===

If you want to use [http://www.qgis.org QGIS], then also compile the GRASS-GDAL/OGR plugin. This is also useful to access your GRASS-data
from other application using GDAL/OGR like [http://thuban.intevation.de thuban].
* [[Compile and install GRASS and QGIS with GDAL/OGR Plugin]] (enables QGIS to read GRASS data directly)

=== Compile and install GDAL-GRASS plugin ===

* See [[Compile and install GDAL-GRASS plugin]]

=== Platform Specific Notes ===

==== Linux ====

Linux comes in various flavours, i.e. distributions.

===== Distribution related packaging =====

* Arch Linux: https://github.com/czka/AUR-grass7
* Centos: https://src.fedoraproject.org/rpms/grass
* Debian: https://trac.osgeo.org/grass/wiki/DebianUbuntuPackaging
* EPEL: https://src.fedoraproject.org/rpms/grass
* Fedora: https://src.fedoraproject.org/rpms/grass
* Ubuntu: https://trac.osgeo.org/grass/wiki/DebianUbuntuPackaging

===== Generic procedure for Debian-based distributions (Ubuntu, ...) =====

WORK IN PROGRESS

1. Install official GRASS package

sudo apt install grass grass-dev

2. Enable source code download

# do backup first
sudo cp /etc/apt/sources.list /etc/apt/sources.list.orig
sudo sed -i '/^#\sdeb-src /s/^# *//' /etc/apt/sources.list

3. Install GRASS dependencies

sudo apt build-dep grass

4. Download GRASS source code

git clone https://github.com/osgeo/grass

5. Compile GRASS from source code

cd grass

Configure:

grass --config build | sh

Optionally install missing dependecies (can happen when official GRASS package is not compatible with GRASS master), eg.

sudo apt install libzstd-dev

Compile:

make -j2

6. Run locally or install

./bin.x86_64-pc-linux-gnu/grass79 --version

or

sudo make install
grass79 --version

===== Debian =====

* Official [http://wiki.debian.org/DebianGis DebianGIS] packaging control files, available on git server:
git://git.debian.org/git/pkg-grass/grass.git

http://anonscm.debian.org/cgit/pkg-grass/grass.git/

====== GRASS 6.1 on Debian Sarge ======

* [http://hamish.bowman.googlepages.com/debiangisfiles#compile Compiling GRASS 6.1-CVS on Debian/OldStable (aka 3.1, Sarge)]

====== GRASS 6.4 on Debian Lenny ======

Install needed packages:
apt-get install flex bison libreadline-dev libncurses5-dev lesstif2-dev debhelper dpatch libtiff4-dev \
tcl-dev tk-dev libfftw3-dev libxmu-dev libfreetype6-dev autoconf2.13 autotools-dev doxygen \
libmysqlclient15-dev graphviz libsqlite3-dev python-wxgtk2.8 libcairo2-dev libwxgtk2.8-dev \
python-dev libgdal1-dev libgdal1-1.5.0 libproj-dev libproj0 proj-bin proj-data mysql

# Important: avoid using CFLAGS="... -Werror-implicit-function-declaration" (also on later Debian versions), see {{trac|1684}}

Configure:
./configure \
--with-cxx \
--with-sqlite \
--with-postgres --with-postgres-includes=/usr/include/postgresql \
--with-mysql --with-mysql-includes=/usr/include/mysql --with-mysql-libs=/usr/lib/mysql \
--with-odbc \
--with-cairo \
--with-proj-share=/usr/share/proj \
--with-tcltk-includes=/usr/include/tcl8.4/ \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--with-motif --with-fftw --with-nls --with-python \
--with-x --x-libraries=/usr/lib/x86_64-linux-gnu

Compile:
make

Install:
sudo make install

====== GRASS 6.4 on Debian Jessie ======

Install needed packages:
apt-get install flex bison debhelper dpatch autoconf2.13 autotools-dev \
python-dev g++ gcc gettext graphviz libcairo2-dev libfftw3-dev tcl-dev tk-dev \
libfreetype6-dev libgdal1h libgdal1-dev libglu1-mesa-dev libglw1-mesa-dev \
libncurses5-dev libreadline-dev libsqlite3-dev libtiff5-dev \
libwxgtk3.0-dev libxmu-dev libxmu-headers libxt-dev mesa-common-dev \
libproj-dev proj-bin proj-data python-numpy python-wxgtk3.0 subversion wx-common zlib1g-dev \
netcdf-bin libnetcdf-dev libatlas-dev libgegl-dev doxygen postgresql mysql-server \
libgeotiff-dev libblas-dev libgeotiff-epsg libxmu-dev libxt-dev libx11-dev

# Important: avoid using CFLAGS="... -Werror-implicit-function-declaration" (also on later Debian versions), see {{trac|1684}}

Configure:
./configure \
--with-cxx \
--with-sqlite \
--with-postgres \
--with-odbc \
--with-cairo \
--with-geos \
--with-proj-share=/usr/share/proj \
--with-tcltk-includes=/usr/include/tcl8.6/ \
--with-mysql --with-mysql-includes=/usr/include/mysql --with-mysql-libs=/usr/lib/mysql \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--with-motif \
--with-fftw \
--with-nls \
--with-postgres-includes=/usr/include/postgresql \
--with-python \
--with-x --x-libraries=/usr/lib/x86_64-linux-gnu

Compile:
make

Install:
sudo make install

====== GRASS 7 on Debian Squeeze ======

Install needed packages:
apt-get install flex bison debhelper dpatch autoconf2.13 autotools-dev python-dev \
g++ gcc gettext graphviz libcairo2-dev libfftw3-dev libfreetype6-dev \
libgdal1 libgdal1-dev libglu1-mesa-dev libglw1-mesa-dev \
libncurses5-dev libproj-dev libreadline-dev libsqlite3-dev libtiff4-dev \
libwxgtk2.8-dev libxmu-dev libxmu-headers libxt-dev mesa-common-dev \
proj-bin proj-data python-numpy python-wxgtk2.8 subversion wx-common zlib1g-dev

Download source code:

svn checkout https://svn.osgeo.org/grass/grass/trunk grass_trunk

Configure:

cd grass_trunk/
CFLAGS="-Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused" \
CXXFLAGS="-Wall" \
./configure --prefix=/usr/local \
--with-gdal --with-proj --with-proj-share=/usr/share \
--with-glw --with-nls --with-readline \
--without-tcltk \
--with-cxx \
--enable-largefile \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--with-sqlite \
--with-cairo --with-python=/usr/bin/python2.6-config --with-wxwidgets \
--with-geos --with-pthread

Compile:
make

Install:
sudo make install # installs as /usr/local/bin/grass72

====== GRASS 7 on Debian Wheezy ======

Install needed packages:

# note: cmake and libboost-all-dev only needed for optional libLAS
sudo apt-get install cmake libboost-all-dev

sudo apt-get install flex bison debhelper dpatch autoconf2.13 autotools-dev \
python-dev g++ gcc gettext graphviz libcairo2-dev libfftw3-dev libfreetype6-dev \
libgdal1 libgdal1-dev libglu1-mesa-dev libglw1-mesa-dev libncurses5-dev libproj-dev \
libreadline-dev libtiff4-dev libwxgtk2.8-dev libxmu-dev libxmu-headers \
libxt-dev mesa-common-dev proj-bin proj-data python-numpy python-wxgtk2.8 subversion wx-common \
zlib1g-dev netcdf-bin libatlas-dev libgegl-dev opencl-headers ocl-icd-libopencl1 \
libsqlite3-dev postgresql python-sphinx python-gdal

Download and Install libLAS
wget http://download.osgeo.org/liblas/libLAS-1.7.0.tar.gz
tar -zxvf libLAS-1.7.0.tar.gz
cd libLAS-1.7.0/
mkdir makefiles
cd makefiles
cmake -G "Unix Makefiles" ../
make
sudo make install
sudo ldconfig
cd ../..

Download of GRASS GIS 7 source code:
wget http://grass.osgeo.org/grass78/source/grass-7.8.0.tar.gz
tar -zxvf grass-7.8.0.tar.gz

Configure:
cd grass-7.0.0
CFLAGS="-g -Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused" CXXFLAGS="-g -Wall" \
./configure \
--prefix=/usr/local \
--with-gdal \
--with-proj --with-proj-share=/usr/share \
--with-glw --with-nls --with-readline \
--with-cxx --enable-largefile \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--with-sqlite --with-cairo --with-python=/usr/bin/python-config \
--with-wxwidgets --with-geos --with-blas \
--with-lapack-includes=/usr/lib/lapack --with-liblas=yes \
--with-netcdf=/usr/bin/nc-config --with-odbc=yes \
--with-openmp=yes --with-pthread=yes --with-postgres=yes \
--with-postgres-includes=/usr/include/postgresql \
--with-postgres-libs=/usr/lib/postgresql

# --with-mysql=yes --with-mysql-includes=/usr/include/mysql \
# --with-mysql-libs=/usr/lib/mysql \

GRASS GIS 7 is now configured (example):

Source directory: /home/user/grass-7.0.0
Build directory: /home/user/grass-7.0.0
Installation directory: ${prefix}/grass-7.0.0
Startup script in directory:${exec_prefix}/bin
C compiler: gcc -g -Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused
C++ compiler: c++ -g -Wall
Building shared libraries: yes
OpenGL platform: X11
MacOSX application: no
MacOSX architectures:
MacOSX SDK:
BLAS support: yes
C++ support: yes
Cairo support: yes
DWG support: no
FFTW support: yes
FreeType support: yes
GDAL support: yes
GEOS support: yes
LAPACK support: no
Large File support (LFS): yes
libLAS support: yes
MySQL support: no
NetCDF support: yes
NLS support: yes
ODBC support: yes
OGR support: yes
OpenCL support: no
OpenGL support: yes
OpenMP support: yes
PNG support: yes
POSIX thread support: yes
PostgreSQL support: yes
Readline support: yes
Regex support: yes
SQLite support: yes
TIFF support: yes
wxWidgets support: yes
X11 support: no

Compile:
make -j2

Install:
sudo make install # installs as /usr/local/bin/grass70

Launch:
grass70

====== GRASS 7 on Debian Jessie ======

Install needed packages:
sudo apt-get install cmake libboost-all-dev flex bison debhelper dpatch autoconf2.13 \
autotools-dev python-dev g++ gcc gettext graphviz libcairo2-dev libfftw3-dev \
libfreetype6-dev libgdal1h libgdal1-dev libglu1-mesa-dev libglw1-mesa-dev \
libncurses5-dev libproj-dev libreadline-dev libsqlite3-dev libtiff5-dev \
libwxgtk3.0-dev libxmu-dev libxmu-headers libxt-dev mesa-common-dev \
proj-bin proj-data python-numpy python-wxgtk3.0 subversion wx-common zlib1g-dev \
netcdf-bin libnetcdf-dev libgegl-dev doxygen python-sphinx \
postgresql libgeotiff-dev libblas-dev mysql-server \
libatlas-dev liblapack3gf liblapack-dev
# opencl-headers ocl-icd-libopencl1 liblas-bin liblas-c-dev python-gdal

Download and compile libLAS (or simply install 'liblas-c-dev ', see above):
wget http://download.osgeo.org/liblas/libLAS-1.8.0.tar.bz2
tar xjf libLAS-1.8.0.tar.bz2
mkdir libLAS-1.8.0/makefiles
cd libLAS-1.8.0/makefiles
cmake -G "Unix Makefiles" ../
make
sudo make install

Download and compile GRASS 7:
# (check there for later version)
wget http://grass.osgeo.org/grass74/source/grass-7.4.0.tar.gz
tar xzfv grass-7.4.0.tar.gz
cd grass-7.4.0
CFLAGS="-g -Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused" \
CXXFLAGS="-g -Wall" \
./configure \
--prefix=/usr/local \
--with-gdal --with-proj --with-proj-share=/usr/share \
--with-glw --with-nls --with-readline \
--with-cxx --enable-largefile \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--with-sqlite --with-cairo --with-python=/usr/bin/python-config \
--with-wxwidgets --with-geos \
--with-blas --with-blas-includes=/usr/include/atlas/ \
--with-lapack --with-lapack-includes=/usr/include/atlas/ \
--with-netcdf=/usr/bin/nc-config --with-odbc=yes \
--with-openmp=yes --with-pthread=no --with-postgres=yes \
--with-postgres-includes=/usr/include/postgresql \
--with-postgres-libs=/usr/lib/postgresql \
--with-mysql=yes --with-mysql-includes=/usr/include/mysql \
--with-mysql-libs=/usr/lib/mysql
make -j2

Install:
sudo make install # installs as /usr/local/bin/grass74

====== GRASS 7 on Debian Stretch ======
(Updated from above with package changes required for Debian Stretch)

Install needed packages for GRASS 7.2 - 7.6:
apt-get install cmake libboost-all-dev flex bison debhelper dpatch autoconf2.13 autotools-dev \
python-dev g++ gcc gettext graphviz libcairo2-dev libfftw3-dev libfreetype6-dev libgdal20 \
libgdal-dev libglu1-mesa-dev libglw1-mesa-dev libncurses5-dev libproj-dev libreadline-dev \
libsqlite3-dev libtiff5-dev libwxgtk3.0-dev libxmu-dev libxmu-headers libxt-dev mesa-common-dev \
proj-bin proj-data python-numpy python-wxgtk3.0 python-wxtools wx-common zlib1g-dev netcdf-bin \
libnetcdf-dev libgegl-dev doxygen python-sphinx postgresql libgeotiff-dev libblas-dev \
mariadb-server libatlas-dev liblapack3 liblapack-dev opencl-headers ocl-icd-libopencl1 \
subversion liblas-bin liblas-c-dev python-gdal libpdal-dev libpdal-plugin-python pdal

Install needed packages for GRASS 7.8+ (Python 3 support!):
apt-get install cmake libboost-all-dev flex bison debhelper dpatch autoconf2.13 autotools-dev \
g++ gcc gettext graphviz libcairo2-dev libfftw3-dev libfreetype6-dev libgdal20 python3-dev \
libgdal-dev libglu1-mesa-dev libglw1-mesa-dev libproj-dev libreadline-dev libgeos-c1v5 \
libsqlite3-dev libtiff5-dev libwxgtk3.0-dev libxmu-dev libxmu-headers libxt-dev mesa-common-dev \
proj-bin proj-data python3-numpy python3-six wx-common zlib1g-dev netcdf-bin \
libnetcdf-dev libgegl-dev doxygen python3-sphinx postgresql libgeotiff-dev libblas-dev \
libatlas-dev liblapack3 liblapack-dev opencl-headers ocl-icd-libopencl1 \
subversion liblas-bin liblas-c-dev python3-gdal libpdal-dev libpdal-plugin-python pdal

# ? python3-wxgtk4.0 libmariadb

Download and unpack source code or fetch from GitHub: https://github.com/OSGeo/grass

Configuration:

CFLAGS="-Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused" \
CXXFLAGS="-Wall" \
./configure \
--prefix=/usr/local \
--with-gdal --with-proj --with-proj-share=/usr/share \
--with-glw --with-nls --with-readline \
--with-cxx --enable-largefile \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--with-sqlite --with-cairo --with-python=/usr/bin/python-config \
--with-wxwidgets --with-geos \
--with-blas --with-blas-includes=/usr/include/atlas/ \
--with-lapack --with-lapack-includes=/usr/include/atlas/ \
--with-netcdf=/usr/bin/nc-config --with-odbc=yes \
--with-openmp=yes --with-pthread=no --with-postgres=yes \
--with-postgres-includes=/usr/include/postgresql \
--with-postgres-libs=/usr/lib/postgresql \
--with-mysql=yes --with-mysql-includes=/usr/include/mysql

Compile:

make -j2

Install:

make install

====== GRASS 7 on Debian Buster ======

-- To be updated --

Install needed packages for GRASS 7.8+ (Python 3 support!):
apt-get install cmake libboost-all-dev flex bison debhelper dpatch autoconf2.13 autotools-dev \
g++ gcc gettext graphviz libcairo2-dev libfftw3-dev libfreetype6-dev libgdal20 python3-dev \
libgdal-dev libglu1-mesa-dev libglw1-mesa-dev libproj-dev libreadline-dev libgeos-c1v5 \
libsqlite3-dev libtiff5-dev libwxgtk3.0-dev libxmu-dev libxmu-headers libxt-dev mesa-common-dev \
proj-bin proj-data python3-numpy python3-six wx-common zlib1g-dev netcdf-bin \
libnetcdf-dev libgegl-dev doxygen python3-sphinx postgresql libgeotiff-dev libblas-dev \
liblapack3 liblapack-dev opencl-headers ocl-icd-libopencl1 \
subversion liblas-bin liblas-c-dev python3-gdal libpdal-dev libpdal-plugin-python pdal \
python3-wxgtk4.0 default-libmysqlclient-dev

Download and unpack source code or fetch from GitHub: https://github.com/OSGeo/grass

Configuration:

CFLAGS="-Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused" \
CXXFLAGS="-Wall" \
./configure \
--prefix=/usr/local \
--with-gdal --with-proj --with-proj-share=/usr/share \
--with-glw --with-nls --with-readline \
--with-cxx --enable-largefile \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--with-sqlite --with-cairo --with-python=/usr/bin/python-config \
--with-wxwidgets --with-geos \
--with-blas --with-blas-includes=/usr/include/atlas/ \
--with-lapack --with-lapack-includes=/usr/include/atlas/ \
--with-netcdf=/usr/bin/nc-config --with-odbc=yes \
--with-openmp=yes --with-pthread=no --with-postgres=yes \
--with-postgres-includes=/usr/include/postgresql \
--with-postgres-libs=/usr/lib/postgresql \
--with-mysql=yes --with-mysql-includes=/usr/include/mysql

Compile:

make -j2

Install:

make install

===== Ubuntu =====

There is a dedicated page on how to [[Compile_and_Install_Ubuntu | Compile the GRASS GIS source code & install it in Ubuntu]].

===== Linux Mint =====

The [[Compile_and_Install_Ubuntu | detailed compilation guide for Ubuntu]] may just work. Here is a short guide for Mint:
<source lang="bash">
# installation of required libraries and compile tools
sudo apt-get install\
build-essential flex make bison gcc libgcc1 g++ cmake ccache \
python python-dev python-opengl python-wxversion python-wxtools python-wxgtk3.0 python-dateutil \
libgsl-dev python-numpy wx3.0-headers wx-common libwxgtk3.0-dev libwxbase3.0-dev \
libncurses5-dev zlib1g-dev gettext libtiff5-dev libpnglite-dev libcairo2 libcairo2-dev \
sqlite3 libsqlite3-dev libpq-dev libreadline6 libreadline6-dev libfreetype6-dev \
libfftw3-3 libfftw3-dev libboost-thread-dev libboost-program-options-dev \
liblas-c-dev resolvconf libjasper-dev subversion libav-tools libavutil-dev \
ffmpeg2theora libffmpegthumbnailer-dev libavcodec-dev libxmu-dev libavformat-dev \
libswscale-dev checkinstall libglu1-mesa-dev libxmu-dev ghostscript
</source>

Next steps:
* download [https://grass.osgeo.org/download/software/sources/ GRASS GIS source code] (e.g. take the "Weekly 7.x-svn snapshot")
* unpack source code, change into the source code directory

<source lang="bash">
# now "configure" stop to prepare for compilation
CFLAGS="-Wall" ./configure \
--with-cxx --with-gdal \
--with-proj --with-proj-share=/usr/share/proj/ \
--with-geos --without-postgres \
--with-nls --with-opengl-includes=/usr/include/GL/ \
--with-fftw --with-freetype \
--with-freetype-includes=/usr/include/freetype2 --with-sqlite \
--with-python=/usr/bin/python2.7-config --with-wx=/usr/bin/wx-config \
--with-wxwidgets --with-cairo --enable-largefile

# compile GRASS GIS
make -j2

# install compiled GRASS GIS on system
sudo make install
</source>

===== Mandriva =====

Installation of dependencies (urpmi will ask you a few more):

'''Mandriva 2009:''' (take out the '64' everywhere if you are on 32bit)
# as root
urpmi flex bison zlib-devel tiff-devel png-devel tcl-devel tk-devel sqlite3-devel \
mesagl1-devel mesaglu1-devel lib64xmu6-devel gcc-c++ gettext \
lib64wxgtk2.8 lib64wxgtk2.8-devel lib64wxgtkgl2.8 wxgtk2.8 \
lib64wxPythonGTK2.8 lib64wxPythonGTK2.8-devel wxPythonGTK wxPythonGTK-wxversion
exit

'''Mandriva 2010:''' (take out the '64' everywhere if you are on 32bit) - see also [http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/grass/current/SPECS/ SPEC] file
# as root
# installation of PROJ and GDAL
urpmi proj proj-devel gdal gdal-devel gcc-gfortran lib64openssl1.0.0 \
lib64openssl1.0.0-devel postgresql8.4-devel lib64pq8.4

# installation of compilation environment
urpmi flex bison zlib-devel tiff-devel png-devel tcl-devel tk-devel sqlite3-devel \
lib64mesagl1-devel lib64mesaglu1-devel lib64xmu6-devel gcc-c++ gettext \
lib64wxgtk2.8 lib64wxgtk2.8-devel lib64wxgtkgl2.8 wxgtk2.8 \
lib64wxPythonGTK2.8 lib64wxPythonGTK2.8-devel wxPythonGTK wxPythonGTK-wxversion
exit

Then, to configure GRASS, run (64 bit stuff optional of course):
# as user
./configure \
--enable-64bit --with-libs=/usr/lib64 \
--with-cxx \
--with-gdal=/usr/local/bin/gdal-config \
--with-sqlite \
--with-nls \
--with-python \
--with-wxwidgets=/usr/lib/wxPython/bin/wx-config \
--with-fftw \
--with-ffmpeg --with-ffmpeg-includes="/usr/include/libav* /usr/include/libpostproc /usr/include/libswscale" \
--with-motif \
--with-mysql --with-mysql-includes=/usr/include/mysql --with-mysql-libs=/usr/lib64 \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--enable-largefile

# compilation (use -j2 ior -j4 parameter on multi-core CPUs to accelerate):
make

Installation:
su
# this will install into /usr/local/
make install
exit

===== Enterprise Linux =====

Enterprise Linux (EL) and derivatives (that is, Red Hat Enterprise Linux, CentOS and Scientific Linux) is a popular and robust platform for servers and computing-heavy workstations, and is therefore a good fit for GIS specific requirements.

See: http://wiki.osgeo.org/wiki/Enterprise_Linux_GIS

===== Scientific Linux =====

See Centos

===== CentOS =====

You first need to add the EPEL repository for PROJ.4 and GDAL, see [https://fedoraproject.org/wiki/EPEL/FAQ#How_can_I_install_the_packages_from_the_EPEL_software_repository.3F here]

<strike>
Preparation '''Centos 5''' (old):
yum install epel-release

# Note: CentOS 5 comes with Python 2.4 which lacks python-config, hence two extra tweaks are needed.
yum install flex bison zlib-devel tcl-devel tk-devel gcc-c++ gettext \
libtiff-devel libpng-devel sqlite-devel \
mesa-libGL-devel mesa-libGLU-devel mesa-libGLw-devel \
mesa-libOSMesa-devel libXmu-devel python-devel gtk2-devel\
ncurses-devel postgresql-devel make
</strike>

Preparation '''Centos 6''' | '''Scientific Linux 6''':
yum install epel-release

yum install flex bison make zlib-devel gcc-c++ gettext \
sqlite-devel mesa-libGL-devel mesa-libGLU-devel \
libXmu-devel libX11-devel fftw-devel libtiff-devel \
lesstif-devel python-devel numpy wxPython wxGTK-devel \
proj proj-devel proj-epsg proj-nad libxml2 gdal gdal-devel geos geos-devel \
python-dateutil python-imaging python-matplotlib python-argparse
# only GRASS GIS 6: install also tcl-devel tk-devel

Preparation '''Centos 7''' | '''Scientific Linux 7''':
yum install epel-release

yum install flex bison make zlib-devel gcc-c++ gettext \
sqlite-devel mesa-libGL-devel mesa-libGLU-devel \
libXmu-devel libX11-devel fftw-devel libtiff-devel \
lesstif-devel python-devel numpy wxPython wxGTK-devel \
proj proj-devel proj-epsg proj-nad libxml2 gdal gdal-devel geos geos-devel \
netcdf netcdf-devel blas-devel lapack-devel atlas-devel \
python-dateutil python-imaging python-matplotlib python-sphinx \
doxygen subversion

Preparation '''Centos 8''' | '''Scientific Linux 8''':
dnf install epel-release

Note, GDAL isn't yet in EPEL8, see https://bugzilla.redhat.com/show_bug.cgi?id=1741567
dnf install flex bison make zlib-devel gcc-c++ gettext \
sqlite-devel mesa-libGL-devel mesa-libGLU-devel \
libXmu-devel libX11-devel fftw-devel libtiff-devel \
python3-devel python3-numpy wxGTK3-devel \
proj proj-devel proj-datumgrid libxml2 \
geos geos-devel \
netcdf netcdf-devel atlas-devel \
python3-dateutil python3-imaging python3-matplotlib \
subversion --skip-broken

GDAL is available on Fedora COPR here: https://copr.fedorainfracloud.org/coprs/neteler/GDAL/builds/
dnf copr enable neteler/GDAL
dnf update
dnf install gdal gdal-libs gdal-python-tools python3-gdal gdal-devel

'''GRASS GIS 7 compilation and installation'''

[https://grass.osgeo.org/grass-stable/source/snapshot/ Download source code] (e.g., --> "Download latest 7.8 code)" and configure GRASS 7 (suggestion: save this as script):

./configure \
--with-cxx \
--enable-largefile \
--with-proj --with-proj-share=/usr/share/proj \
--with-gdal=/usr/bin/gdal-config \
--with-sqlite \
--with-python \
--with-cairo --with-cairo-ldflags=-lfontconfig \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--with-wxwidgets=/usr/bin/wx-config \
--with-openmp \
--with-blas --with-blas-includes=/usr/include/atlas-x86_64-base/ \
--with-lapack --with-lapack-includes=/usr/include/atlas-x86_64-base/ \
--with-fftw \
--with-geos \
--with-netcdf \
--without-ffmpeg \
--without-mysql \
--without-postgres \
--without-odbc \
--without-fftw

Compile:
make
or on a multicore system (number depends of available cores):
make -j4

For a system wide installation, run as root user:
make install
OR simply run it directly from the source code directory (substitute ARCH with i686 or x86_64):

bin.$ARCH/grass78 -gui

In this case, for convenience, add it to the search path:
mkdir $HOME/bin
cd $HOME/bin
# example:
ln -s $HOME/software/grass78_release/bin.i686-pc-linux-gnu/grass78 .

Now use it subsequently with
grass78 -gui

'''Installation grass78 on a HPC system with '''Centos 7''' and no root privileges:'''
This assumes that python3, fftw, proj, gdal and geos are available on the HPC system, either as modules or as installed software.

Download and prepare some dependencies (freetypes and zstd)
mkdir -p $HOME/grass/freetypes
cd $HOME/grass/freetypes
wget path/to/freetype-2.9.1.tar.gz
tar -xf freetype-2.9.1.tar.gz

mkdir $HOME/grass/zstd
cd mkdir $HOME/grass/zstd
wget path/to/v1.4.4/zstd-1.4.4.tar.gz
tar -xf zstd-1.4.4.tar.gz
make install PREFIX=./

Add the ZSTD path to your LD_LIBRARY_PATH

tee -a $HOME/.bashrc > /dev/null << EOT
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/grass/zstd/zstd-1.4.4/lib
EOT

The configure command could look like this
./configure \
-prefix=$HOME/grass \
--enable-64bit --with-fftw-includes=/path/to/fftw/include/ \
--with-fftw-libs=/path/to/fftw/lib/ \
--with-freetype-includes=$HOME/grass/freetypes/freetype-2.9.1/include/ \
--with-netcdf --with-geos --with-blas --with-lapack --with-postgres \
--with-zstd-includes=$HOME/grass/zstd/zstd-1.4.4/lib/ \
--with-zstd-libs=$HOME/grass/zstd/zstd-1.4.4/lib/ \
--with-gdal=/path/to/gdal-config # This could be the path to a gdal version compiled from source

Finally usual:
make; make install

===== Gentoo =====

./configure \
--with-freetype=yes --with-freetype-includes="/usr/include/freetype2/"

See also http://packages.gentoo.org/package/sci-geosciences/grass

===== Funtoo =====

{{MovedToTrac|FuntooLinux}}

===== Fedora =====

====== GRASS GIS 6 on Fedora ======

'''Preparation''' for the compilation of GRASS GIS 6 source code (F16-F21):

yum install proj-devel gdal-devel sqlite-devel ffmpeg-devel mesa-libGL-devel \
mesa-libGLU-devel libXmu-devel libX11-devel tcl-devel tk-devel geos \
fftw-devel libtiff-devel lesstif-devel python-devel numpy wxPython wxGTK-devel \
gcc gcc-c++ bison flex ncurses-devel proj-epsg proj-nad xml2 subversion

''Note 1: that currently gdal-devel has (too) many dependencies and may lead to a massive download of extra packages (200 on a fresh Fedora 16 install). Hopefully solved in later Fedora versions.''

''Note 2: the optional ffmpeg-devel comes from the rpmfusion-free repository ([http://rpmfusion.org/Configuration/ configuration]).''

'''Download''' the source code:
* GRASS GIS 6: [http://grass.osgeo.org/download/software/sources/ release package] - [http://grass.osgeo.org/grass64/source/snapshot/ weekly snapshot] - [http://trac.osgeo.org/grass/wiki/DownloadSource#GRASS6.4 SVN repository]

'''Configure''': This is an ''example'' how to configure the source code on a Fedora system:

./configure \
--with-cxx \
--with-gdal=/usr/bin/gdal-config \
--with-proj --with-proj-share=/usr/share/proj \
--with-sqlite \
--with-nls \
--with-geos \
--with-wxwidgets=/usr/bin/wx-config \
--with-python=/usr/bin/python-config \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--enable-largefile \
--without-odbc \
--with-fftw

Extra: If you also want '''FFMPEG''' support - it requires 'yum install fftw-devel'. Then add to the configuration lines above:

--with-ffmpeg --with-ffmpeg-includes="/usr/include/ffmpeg /usr/include/ffmpeg/libav* /usr/include/ffmpeg/libpostproc /usr/include/ffmpeg/libswscale" \

Finally '''compile''' the configured source code:
make
or on multicore (number depends of available cores):
make -j4
and
make install # requires root permissions unless you become owner of /usr/local/

Then use GRASS GIS 6 and enjoy!

====== GRASS GIS 7 on Fedora ======

'''Preparation''' for the compilation of GRASS GIS 7.8+ source code (F20-F30):

dnf install gcc gcc-c++ bison flex ncurses-devel gettext proj-epsg proj-devel proj-nad \
gdal gdal-devel sqlite-devel xml2 mesa-libGL-devel \
fftw-devel mesa-libGLU-devel libXmu-devel libX11-devel geos geos-devel \
libtiff-devel python3-devel numpy wxPython wxGTK3-devel subversion \
python3-dateutil python3-imaging python3-matplotlib-wx doxygen python3-sphinx \
libzstd-devel libzstd python3-six python3-numpy python3-wxpython4 \
proj-datumgrid proj-datumgrid-europe proj-datumgrid-north-america proj-datumgrid-world proj-datumgrid-oceania

# optionally also: netcdf-devel postgresql-devel
# atlas-devel lapack-devel lapack-devel
# laszip laszip-devel

''Note 1: the optional ffmpeg-devel comes from the rpmfusion-free repository ([http://rpmfusion.org/Configuration/ configuration]).''

'''Download''' the source code:
* GRASS GIS 7: [https://grass.osgeo.org/grass78/source/snapshot/ weekly snapshot] - [http://trac.osgeo.org/grass/wiki/DownloadSource#GRASS7 GitHub repository]

'''Configure''': This is an example how to configure the source code on a Fedora system:

./configure \
--with-cxx \
--with-gdal=/usr/bin/gdal-config \
--with-proj --with-proj-share=/usr/share/proj \
--with-geos \
--with-sqlite \
--with-nls \
--with-wxwidgets=/usr/bin/wx-config \
--with-fftw \
--with-cairo --with-cairo-ldflags=-lfontconfig \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--enable-largefile \
--without-odbc

''Extra 1:'' If you also want '''FFMPEG support''' - it requires 'dnf install fftw-devel' from the rpmfusion-free repository. Then add to the configuration lines above:

--with-ffmpeg --with-ffmpeg-includes="/usr/include/ffmpeg /usr/include/ffmpeg/libav* /usr/include/ffmpeg/libpostproc /usr/include/ffmpeg/libswscale" \

''Extra 2:'' For '''LAPACK/BLAS support''' (addons i.spec.unmix, v.kriging etc), install "dnf install lapack lapack-devel blas blas-devel atlas atlas-devel". Then add to the configuration lines above:
--with-blas --with-blas-includes=/usr/include/atlas-x86_64-base/ \
--with-lapack --with-lapack-includes=/usr/include/atlas-x86_64-base/ \

''Extra 3:'' For '''ZSTD support''' (Zstandard compression algorithm), first install "dnf install libzstd libzstd-devel zstd". After installing the zstd related packages, add to the configuration lines above:
--with-zstd \

Finally '''compile''' the configured source code:
make
or on multicore (number depends of available cores):
make -j4
and
make install # requires root permissions unless you become owner of /usr/local/

Then use GRASS GIS 7 and enjoy!

===== openSUSE =====

To build GRASS on openSUSE:

''Application:Geo'' repo to be added (see [https://software.opensuse.org//download.html?project=Application%3AGeo&package=gdal Install package Application:Geo]

<source lang="bash">
# example for Leap 42 version:
sudo zypper addrepo http://download.opensuse.org/repositories/Application:Geo/openSUSE_Leap_42.3/Application:Geo.repo
sudo zypper refresh
</source>

RPM packages to be installed:
<source lang="bash">
sudo zypper install bison flex freetype2-devel fftw3-devel gcc-c++ \
libgdal-devel libgeos-devel libjpeg-devel libpng-devel libtiff-devel \
man proj libproj-devel readline-devel netcdf-devel ncurses-devel \
mysql-devel postgresql-devel sqlite-devel unixODBC-devel \
tcl-devel tk-devel xorg-x11-Mesa-devel libXmu-devel \
python-numpy python-dateutil python-devel python-opengl \
python-wxWidgets python-xml python-dateutil wxWidgets-devel \
zlib-devel doxygen python-sphinx
</source>

Source code configuration:
<source lang="bash">
./configure \
--enable-largefile \
--with-proj-share=/usr/share/proj \
--with-cxx \
--with-lapack=yes \
--with-x \
--with-motif \
--with-gdal=/usr/bin/gdal-config \
--with-postgres --with-postgres-includes=/usr/include/pgsql \
--with-mysql --with-mysql-includes=/usr/include/mysql \
--with-fftw \
--with-readline \
--with-netcdf \
--with-curses \
--with-geos \
--with-nls \
--with-sqlite \
--with-freetype \
--with-freetype-includes=/usr/include/freetype2 \
--with-wxwidgets \
--with-odbc \
--with-python
</source>

Then compile with "make [-j2]".

===== Arch Linux =====

* <big>'''Easiest method : use AUR (Arch User Repository) package'''</big>
Up-to-date links to Arch Linux GRASS PKGBUILDs are on https://grass.osgeo.org/download/software/linux/.

Please note that at this time AUR package has a problem : a symlink of python2 is created to work with grass whereas executable script call python3 ... Workaround is to comment symlink in AUR GRASS PKGBUILD

* <big>'''Compile from source code'''</big>
If you want to compile it yourself, you could follow steps below :

Install dependencies :
pacman -S bzip2 cairo fftw fontconfig freetype2 gcc-libs gdal geos glibc glu libpng libtiff libx11 libgl netcdf pdal proj python-gdal python-numpy python-pillow python-wxpython readline zlib zstd

Download and extract sources : https://grass.osgeo.org/download/software/sources/

We can now start building GRASS 7

export PATH=~/usr/bin:$PATH && \
./configure \
--enable-debug \
--with-readline \
--with-freetype=yes \
--with-freetype-includes="/usr/include/freetype2/" \
--with-geos \
--with-odbc \
--with-pthread \
--with-fftw-includes="/usr/include/" \
--with-fftw-libs=/usr/lib/ \
--with-wxwidgets \
--with-postgres \
--with-pdal \
--with-netcdf \
--with-bzlib \
--with-zstd

Now let's compile and install it

make
make install

It's done, you can enjoy GRASS 7 in Arch, just type "grass78" (Please adjust version after grass) in the terminal to launch it.

===== RPM SPEC files =====
* [https://build.opensuse.org/package/show?package=grass&project=Application%3AGeo OpenSuSe]
* [http://pkgs.fedoraproject.org/cgit/rpms/grass.git/tree/grass.spec Fedora]
* ...

===== Zaurus =====

... see [http://wiki.debian.org/?GrassGISonZaurus here] for instructions

==== Mac OSX ====

===== Compilation and installation =====
* [[Compiling on MacOSX using homebrew]]
* [[Compiling on MacOSX using Anaconda]]
* [[Compiling on MacOSX]] (rather outdated)
* [[Compiling on MacOSX using Fink]] (rather outdated)
* [https://grass.osgeo.org/download/software/mac-osx/ official download site]
* [http://www.kyngchaos.com/software/frameworks#build_scripts build scripts for dependencies] (still relevant?)

Troubleshooting:
* solving errors at starting GRASS GIS: [[MacOSX GRASS errors]]

==== FreeBSD / NetBSD ====

The recommended compiler tools are GCC, GNU make, GNU coreutils (for install), and flex. All are available through the respective package managing tools (pkg_add for FreeBSD and pkgin install for NetBSD) and for recent *BSD versions most likely installed by default.

GRASS 6.x and GRASS 7 should compile on FreeBSD 8.0 or later and NetBSD 5.0 or later (maybe also on updated NetBSD 4.x).

It is highly recommended to install GDAL/OGR and PROJ4 first. These libraries and tools are available as [http://www.freebsd.org/ports/ ports for FreeBSD] and [http://www.pkgsrc.org/ packages for NetBSD].

Optional functionality is listed with ''./configure --help'', and related libraries and tools might need to be installed first.

You then may need to edit include/Make/Platform.make and set
ICONVLIB = -liconv

==== Solaris ====

* ''2008 Oct 15'': see [http://lists.osgeo.org/pipermail/grass-user/2008-October/047093.html this post on the grass mailing list]

===== 11 SPARC/i86pc =====

The recommended compiler tools are GCC, GNU make, GNU coreutils (for install), and flex. All are available through the Solaris package manager.

Most dependencies are available through the Solaris package manager. GDAL and proj4 can either be compiled from source or installed e.g. from [http://www.opencsw.org/ OpenCSW]. If packages are installed from OpenCSW, the linker flags need to be set with

LDFLAGS="-Wl,-R/opt/csw/lib -L/opt/csw/lib -Wl,-R/opt/csw/gxx/lib -L/opt/csw/gxx/lib"

See also the [http://www.opencsw.org/use-it/ OpenCSW documentation].

===== 10 SPARC/i86pc =====

* get gcc compiler and tools. There are several sources: Solaris Companion CD (SFW pkg, installs in /opt/sfw/), Blastwave ([http://www.blastwave.org], CSW pkg, installs in /opt/csw/) or Sunfreeware ([http://www.sunfreeware.com], SMC pkg, installs in /usr/local/).
Needed Packages from Sunfreeware: SMCbinut, SMCbison, SMCcoreu, SMCfindu, SMCflex, SMCgawk, SMCgcc, SMCgrep, SMCgzip, SMCless, SMClibt, SMClicon, SMCmake, SMCncurs, SMCproj, SMCsed, SMCtar, SMCtcl, SMCtiff, SMCtk, SMCunzip, SMCzlib.

* compile and install fftw-library ([http://www.fftw.org]). You need to re-compile the library with:

./configure --with-pic --enable-shared; make ; make install.

The pre-built packages don't work.

* compile and install gdal library (see documentation of gdal, [http://www.gdal.org]).

* compile and install any additional libraries (e. g. GEOS, [http://geos.refractions.net]).

* set compiler flags and path. e. g.:

# on ultra-sparc machine:
CFLAGS="-O3 -mcpu=v9"
CXXFLAGS="-O3 -mcpu=v9"
PATH="/usr/local/bin:/opt/sfw/bin:/usr/ccs/bin:/usr/bin:/usr/sbin"
export CFLAGS CXXFLAGS PATH

Path has to be changed for the packages (Sunfreeware: /usr/local/bin, Solaris Companion: /opt/sfw/bin, Blastwave: /opt/csw/bin).

* Next configure, e. g.:

./configure --with-postgres-includes=/usr/include/pgsql/ \
--with-postgres-libs=/usr/lib --with-postgres=yes \
--with-includes=/usr/local/include/ncurses

If you use n(ew)curses, you have to include the path /usr/local/include/ncurses.

then:

make
su
make install

If the shared libraries are not found at runtime of the modules, use 'crle' to add the paths of the libraries for the dynamic linker, e. g. as root:

crle -l /lib:/usr/lib:/usr/local/lib:/opt/sfw/lib:/usr/X11/lib

Be careful not to omit a library path, the system may be unusable if you forget the /lib path.

==== AIX ====

A recent [ftp://ftp.gnu.org/gnu/make/ GNU make] (>= 3.81) and GNU coreutils are required. These are available with the [http://www-03.ibm.com/systems/power/software/aix/linux/toolbox/download.html IBM AIX toolbox] or through third-party AIX software repositories, e.g. [http://www.bullfreeware.com/ bullfreeware] and [http://www.perzl.org/aix/ perzl.org]. Note that 'make' does not work, only 'gmake' works.

General instructions to compile on AIX are e.g. [http://www.perzl.org/aix/index.php?n=Main.Instructions here]

On AIX, compilation results by default in 32 bit applications and static libraries. The [http://www.ibm.com/developerworks/aix/library/au-gnu.html IBM documentation] explains how to build 64 bit applications and shared libraries with GCC.

'''GRASS 6: Using the IBM xlc compiler:'''
* ''see [http://thread.gmane.org/gmane.comp.gis.grass.user/32667 this mailing list thread]''

Mike wrote in 2009:

After attempting all the suggestions, I finally used
--disable-shared on the configure command, and all but
a handful of modules successfully compiled. I was able to
individually address the ones that failed through Makefile
edits and several small source code/header file edits.

The environment variables and configure command that worked were:
<pre>
# xlc compiler:
export PATH=/usr/local/bin:/opt/freeware/bin:$PATH
export OBJECT_MODE=64
export LIBICONV=/opt/freeware
export CC="xlc_r -q64"
export CFLAGS="-O -qstrict"
export CXX="xlC_r -q64"
export CXXFLAGS="-O -qstrict"
export AR="ar -X64"
export F77="xlf_r -q64"
export CPPFLAGS="-I/afs/isis/pkg/libpng/include -I/usr/local/include -I$LIBICONV/include -I/usr/lpp/X11/include/X11"
export LDFLAGS="-L/usr/local/lib -L$LIBICONV/lib -L/usr/lib -L/usr/X11R6/lib -lc"

./configure --prefix=/afs/isis/pkg/grass-6.4.0 \
--enable-64bit \
--disable-shared \
--with-includes="/usr/include/fontconfig /usr/include/X11 /usr/include/X11/Xft /usr/include/X11/ext" \
--x-includes=/usr/include/X11 \
--x-libraries=/usr/X11R6/lib \
--with-fftw-includes=/afs/isis/pkg/fftw-3.2.2/include \
--with-fftw-libs=/afs/isis/pkg/fftw-3.2.2/lib \
--with-gdal=/afs/isis/pkg/gdal/bin/gdal-config \
--with-proj-includes=/afs/isis/pkg/proj/include \
--with-proj-libs=/afs/isis/pkg/proj/lib \
--with-proj-share=/afs/isis/pkg/proj/share/proj \
--with-tcltk-includes=/usr/local/include \
--with-tcltk-libs=/usr/local/lib \
--with-opengl-includes=/usr/include/GL
</pre>

'''GRASS 7: Using the IBM xlc compiler:'''

Get and install (in this order):
* [ftp://ftp.gnu.org/gnu/tar/ GNU tar]
* [ftp://ftp.gnu.org/gnu/make/ GNU make] (>= 3.81)
* [http://www.sqlite.org SQLite]
* [http://trac.osgeo.org/proj/ PROJ.4] (for ./configure parameters, see [[Talk:Compile and Install|here]])
* [http://www.gdal.org GDAL] (for ./configure parameters, see [[Talk:Compile and Install|here]])
* [http://grass.osgeo.org/grass74/source/snapshot/ GRASS GIS 7]

The environment variables and configure command that worked:
<pre>
## AIX 5.x

export LIBPATH=/opt/freeware/lib64:/opt/freeware/lib
# make 'ar' happy
export OBJECT_MODE=64

PREFIX=$HOME/private/bin
./configure \
--prefix=$PREFIX \
--disable-shared \
--enable-largefile \
--with-cxx \
--with-proj-includes=$PREFIX/include/ \
--with-proj-libs=$PREFIX/lib/ \
--with-proj-share=$PREFIX/share/proj/ \
--with-sqlite \
--with-sqlite-includes=$PREFIX/include/ \
--with-sqlite-libs=$PREFIX/lib/ \
--with-tiff=no \
--with-png=no \
--with-fftw=no \
--with-cairo=no \
--with-freetype=no
</pre>

'''GRASS 7: Using the GNU gcc compiler:'''

Get and install (in this order):
* if needed, [ftp://ftp.gnu.org/gnu/tar/ GNU tar]
* if needed (the name is often 'gmake' and not 'make') [ftp://ftp.gnu.org/gnu/make/ GNU make] (>= 3.81)
* [http://www.sqlite.org SQLite]
* [http://trac.osgeo.org/proj/ PROJ.4] (for ./configure parameters, see [[Talk:Compile and Install|here]])
* [http://www.gdal.org GDAL] (for ./configure parameters, see [[Talk:Compile and Install|here]])
* [http://grass.osgeo.org/grass74/source/snapshot/ GRASS GIS 7]

The environment variables and configure command that worked for AIX 5.x:
<pre>
## AIX 5.x

export LIBPATH=/opt/freeware/lib64:/opt/freeware/lib
# make 'ar' happy
export OBJECT_MODE=64

PREFIX=$HOME/private/bin
CFLAGS='-ansi -D_ALL_SOURCE=1 -D_POSIX_SOURCE=1 -D_POSIX_C_SOURCE=200809L -Dinline=' ./configure \
--prefix=$PREFIX \
--disable-shared \
--enable-largefile \
--with-cxx \
--with-proj-includes=$PREFIX/include/ \
--with-proj-libs=$PREFIX/lib/ \
--with-proj-share=$PREFIX/share/proj/ \
--with-sqlite \
--with-sqlite-includes=$PREFIX/include/ \
--with-sqlite-libs=$PREFIX/lib/ \
--with-tiff=no \
--with-png=no \
--with-fftw=no \
--with-cairo=no \
--with-freetype=no
</pre>

The environment variables and configure command that worked for AIX 7.x:
<pre>
## AIX 7.x
export CC="gcc"
export CXX="g++"
PREFIX=$HOME/bin

LDFLAGS="-Wl,-bsvr4,-R,/opt/freeware/lib -L/opt/freeware/lib" CPPFLAGS="-I/opt/freeware/include" ./configure \
--prefix=$PREFIX \
--enable-largefile \
--enable-shared \
--with-includes=/opt/freeware/include --with-libs=/opt/freeware/lib \
--with-cxx \
--with-proj-includes=$PREFIX/include/ \
--with-proj-libs=$PREFIX/lib/ \
--with-proj-share=$PREFIX/share/proj/ \
--with-gdal=$PREFIX/bin/gdal-config \
--with-sqlite \
--with-sqlite-libs=$PREFIX/lib --with-sqlite-includes=$PREFIX/include \
--with-png=no \
--with-tiff=no \
--with-fftw=no \
--with-cairo=no \
--with-opengl=no \
--with-freetype=no
</pre>

==== MS-Windows ====

===== MS-Windows/Cygwin =====

* See the [[Cygwin]] wiki pages

===== MS-Windows/native =====

====== Compile ======

* [http://trac.osgeo.org/grass/wiki/CompileOnWindows GRASS Windows Native Binary Building Guide] (GRASS 6.4.x + 7.x)
* <strike>[http://www.webalice.it/marco.pasetti/grass/BuildFromSource.html GRASS Windows Native Binary Building Guide] (GRASS 6.3.x) </strike>
* See/adapt [http://blog.qgis.org/node/124 idea] for unattended install of QGIS (et al) from [http://trac.osgeo.org/osgeo4w/ OSGeo4W] from the QuantumGIS Blog.

See also [[WinGRASS Current Status]] for latest updates.

=== Common problems and solutions ===

During compilation, error can occur if certain packages are not installed. Here a list of problems with solution:

* error: X11/Xlib.h: No such file or directory
** this suggests that you don't have the X headers installed
** Solution: Install the libx11-dev package

* error: g.list: error while loading shared libraries: libgdal1.6.0.so.1: cannot open shared object file: No such file or directory
** this error appears in the shell right after the user clicks GUI's "Start GRASS" button. The GUI shows an error about geographic extent and gets closed afterwards.
** It happens when you launch bin.i686 executable on 64bit system. Be careful and choose the right architecture.

=== Static compilation ===

In order to get static rather than dynamically linked binaries, configure like this:

./configure --disable-shared --enable-static

This will however break the wxGUI and GRASS 7 completely because "ctypes" wants to link against shared libs, or there is something in the static libs that "ctypes" does not like.

=== Optimization ===

GCC and other compilers support [http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Optimize-Options.html#Optimize-Options optimization]

If you would like to set compiler optimisations, for a possibly faster binary, type (don't enter a ";" anywhere):

CFLAGS=-O ./configure
or,
setenv CFLAGS -O
./configure

whichever works on your shell. Use -O2 instead of -O if your compiler supports this (note: O is the letter, not zero). Using the "gcc" compiler, you can also specify processor specific flags (examples, please suggest better settings to us):

CFLAGS="-mcpu=athlon -O2" # AMD Athlon processor with code optimisations
CFLAGS="-march=amdfam10" # AMD Phenom II X4 64bit processor with gcc >=4.3
CFLAGS="-mcpu=pentium" # Intel Pentium processor
CFLAGS="-mcpu=pentium4" # Intel Pentium4 processor
CFLAGS="-O2 -msse -msse2 -mfpmath=sse -minline-all-stringops" # Intel XEON 64bit processor
CFLAGS="-mtune=nocona -m64 -minline-all-stringops" # Intel Pentium 64bit processor

To find out optional CFLAGS for your platform, enter:
gcc -dumpspecs

See also: http://gcc.gnu.org/

A real fast GRASS version (and small binaries) will be created with LDFLAGS set to "stripping" (but this disables debugging):

CFLAGS="-O2 -mcpu=<cpu_see_above> -Wall" LDFLAGS="-s" ./configure

=== Configure options and their meanings ===

For configure there are many options and some GRASS modules are built only if some options are set. Here are listed common configuration options with short explanation.

* --prefix=/path - Sets path where GRASS will be installed. GRASS will reside in /path/grass-version.
* --enable-largefile - Enables large (>2Gb on 32bit systems) support. For current large file support status look at [[Large File Support]] page.
* --with-cxx - Enables compilation of C++ code. Required for r.terraflow module.
* --with-readline - Enables readline support. If readline is enabled, you can use its history/editing facilities when entering r.mapcalc expressions on stdin.
* --with-glw - Enables GLw support. The GLw library provides OpenGL "canvas" widgets for Athena and Motif.

That switch is unnecessary for normal compilation. It's only
required for r3.showdspf, which isn't normally built; if you
want it, you have build it manually
(e.g. "make -C raster3d/r3.showdspf").
As similar functionality is now provided by NVIZ, r3.showdspf
is deprecated.
r3.showdspf uses the Motif widget (so you also need a
Motif library, e.g. Lesstif or OpenMotif).
[http://grass.itc.it/pipermail/grassuser/2006-December/037475.html Glynn Clements at GRASS-user mailing list]

=== Parallelized compilation on multi-core CPUs ===

You can dramatically accelerate the compilation of the GRASS code with the -j flag of "make" if you have a multi-core CPU system. This determines the maximum number of jobs to have running at once, so cores don't have to sit idle waiting for jobs on other cores to complete. A good rule of thumb for this value is <tt>number_of_cores * 1.5</tt>, but note that setting any higher than the actual number of cores will only affect the timing slightly. For example, on a dual-core processor:
make -j 4



== GRASS-GDAL plugin ==

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

== Addons ==

Please note that the installation of [[AddOns/GRASS_6|Addons]] can be easily done with the {{cmd|g.extension}} manager. The compile instructions below are aiming at own development.

=== Compiled modules ===

This is the general way which works for C modules as well as scripts (Python or Shell/Bash modules) which has HTML documentation.

'''Requirements:'''

Either:
* a binary GRASS package, or
* source code which has been prepared with:
./configure [opionally flags]
make libs

Each of the [[GRASS_AddOns|addon]] modules should come with a Makefile. To compile it, just run:
make MODULE_TOPDIR=/path/to/grass64/

Note that the <tt>/path/to/grass64</tt> has to be absolute, not relative.

If using Bash it may be useful to set that up as an alias:
alias gmake64='make MODULE_TOPDIR=/path/to/grass64/'

Installation (perhaps requires "sudo"):
make MODULE_TOPDIR=/path/to/grass64/ install

Note: Compiled addons may require a re-compilation if you changed/updated your GRASS standard binaries.

==== If binary comes with a -dev package ====

''(work in progress, this text states how it eventually will be :)''
Nowadays one does not need to the source code, nor compiling GRASS by oneself to be able to add add-ons. On Debian, you can just install the grass-dev package and then run:
make MODULE_TOPDIR=/usr/lib/grass64/ INST_DIR=/usr/lib/grass64/

The grass-dev package essentially provides GRASS's <tt>include</tt> header files and Make configuration files.

=== Scripts ===

If the addon module is a script, it is sufficient to copy it into the (GRASS binaries) path somewhere. Alternatively, install addons into a separate GRASS addons binaries/scripts directory which is easier to maintain. It avoids getting clobbered every time you reinstall GRASS. To use these separately stored scripts, set and export the GRASS_ADDON_PATH environment variable before starting GRASS and it will automatically be added to the module search path (see the {{cmd|variables}} help page). To simplify this, do for example:

# add in $HOME/.bashrc:
GRASS_ADDON_PATH=/usr/local/grass/addons/
export GRASS_ADDON_PATH

Make sure that the script is executable, then just call it in GRASS typing the filename. Python scripts need to be called writing the extension as well, like:

GRASS 6.5.svn (spearfish60):~ > v.krige.py

[[Category:Development]]
[[Category:Documentation]]
[[Category:Installation]]

Compiling on macOS using Anaconda

2020-06-02T23:59:30Z

⚠️Cmbarton: fix another mediawiki formatting issue

== Using Anaconda to Create a Binary Mac App for GRASS ==
These instructions are for creating a self-contained Mac app, including all dependencies, with GRASS 7.9 and Anaconda. You can modify them if you don't need some of the steps. Some of the steps you won't need to repeat (e.g., creating an anaconda environment). You must first install the '''Anaconda package''' for Python from (https://www.anaconda.com). You will of course need to download a copy of the '''GRASS source code''' from (https://grass.osgeo.org). You will also need to install Apple's '''XCode''' and the '''command-line tools''' to compile sofware. This workflow can be used with MacOS 10.14 and 10.15. It may work with other versions, but has not been tested.

You will need to work from the '''Mac terminal''' to compile GRASS of course. This tutorial assumes you are familiare with this command line interface.

This process also requires some patches and other supporting files. You can download these here: [[File:Grass_macapp_anaconda_supporting_files.zip]]

=== 1. Create a Mac app shell (I have uploaded an example for GRASS 7.9 you can use as is, modified from shells created by Eric Hutton). ===
This can be modified serve for different versions of GRASS by altering the last line of the script that launches GRASS in the app shell. To do this, you will need to look inside the app by Ctrl-clicking on it and selecting ''''"show package contents"'''', which reveals the app as a folder with other folders and files inside.

For example, to make a shell for GRASS 7.8, copy the uploaded ''''GRASS-7.9.app'''' and rename it to ''''GRASS-7.8.app''''
Then show package contents for ''''GRASS-7.8.app'''' and use a text editor to modify the last line of the file ''''../GRASS-7.8.app/Contents/MacOS/Grass.sh'''' to refer to GRASS 7.8

change: "$GRASS_PYTHON" "$GISBASE/bin/grass79" "-gui" "$@"
to: "$GRASS_PYTHON" "$GISBASE/bin/grass78" "-gui" "$@"

Also, use a text editor to modify ''''../GRASS-7.9.app/Contents/Info.plist''' to change all references to 7.9 to 7.8.

=== 2. Create an Anaconda environment for Python 3.6.10 ===
This may not be strictly necessary, but I am doing it make sure that my builds use Python 3 instead of Python 2.7, which is still what ships with the Mac.

Anaconda defaults to Python 3.7.6, which will not compile GRASS properly. This makes it more complicated than needed, requiring some workarounds. I've tried this with multiple versions of Python 3 (anaconda has them all the way up to 3.8.2), but the highest version that seems to give consistently successful results is 3.6.10. This will probably change in the future so that you can use a higher version of Python.

Here is how to create an Anaconda environment for Python 3.6.10. You only need to do this once for each environment you want to use.
<pre>
conda create anaconda_p36 python==3.6.10 anaconda
</pre>

=== 3. Activate the Anaconda Python 3.6.10 environment ===
<pre>
conda activate anaconda_p36
</pre>
You can activate any previously created Anaconda environment in this way

=== 4. Copy the Mac app shell to /Applications ===
<pre>
cp -r ../GRASS-7.9.app /Applications/GRASS-7.9.app
</pre>

=== 5. Download the Python 3 miniconda installer and use it to install a minimal anaconda environment into the Mac app shell ===

<pre>
curl https://repo.continuum.io/miniconda/Miniconda3-latest-MacOSX-x86_64.sh > miniconda3.sh
bash ./miniconda3.sh -b -f -p /Applications/GRASS-7.9.app/Contents/Resources
</pre>

=== 6. Export the path to the GRASS Mac app shell so that subsequent operations use the environment of that shell ===

<pre>
export PATH=/Applications/GRASS-7.9.app/Contents/Resources/bin:$PATH
</pre>

=== 7. Install GRASS dependencies into Mac app shell, including Python 3.6.10 ===
A requirements file can make all of these dependencies easier to install. One is included in the supporting files package. This will downgrade Python from v. 3.7.6 installed by miniconda to the more useable 3.6.10.
<pre>
conda install --yes -p "/Applications/GRASS-7.9.app/Contents/Resources" --file=requirements_wxp4p36.txt -c conda-forge
</pre>

=== 8. Create a symlink to Python so that pythonw can find it (may become unneeded in the future) ===
Grass launches Python through the pythonw script. But the script does not point to the correct location for Python (which is in fact in 2 different places). This seems to be a bug in Python < 3.7.4 or how anaconda installs it. It puts the python launch file in the wrong place. So a symlink is needed. Hopefully this will go away when we can use Python > 3.7.6, which seems to put python in the correct place, and the place that pythonw points to.
<pre>
ln -sf /Applications/GRASS-7.8.app/Contents/Resources/python.app/pythonapp/Contents/* /Applications/GRASS-7.8.app/Contents/Resources/python.app/Contents
</pre>

=== 9. cd to the grass source folder and apply patches to configure and make files ===
Eric Hutton at CSDMS worked out these patches and I modified one needed to use Python 3. Maybe they can be worked into the source code so that they are no longer needed. I will upload the patches along with the app shell and requirements file.
<pre>
patch -p0 < aclocal.m4.patch
patch -p0 < configure.patch
patch -p0 < install.make.patch
patch -p0 < loader.py.patch
patch -p0 < module.make.patch
patch -p0 < platform.make.in.patch
patch -p0 < rules.make.patch
patch -p0 < shlib.make.patch
</pre>

=== 10. Configure, make, and install ===
An example configure script is included in the grass supporting files package. It flags all dependencies and sets the correct path so that they can be found. '''Important''': this configure script has a hard path to the SDK (software developer kit) that comes with XCode. You can set different path if you've put you SDK in a different place.
<pre>
bash ../configure.sh
make -j4 GDAL_DYNAMIC=
make -j4 install
</pre>

Assuming there were no errors, you should now be able to run and test the GRASS-7.9.app in your /Applications folder

=== 11. Clean up ===
This removes unneeded anaconda package installer files and some other large files that are irrelevant for GRASS. It makes the app much smaller (though still large because of Python, wxPython, and other dependencies are packaged inside)

<pre>
conda clean --all -y
rm -r /Applications/GRASS-7.9.app/Contents/Resources/mkspecs
rm -r /Applications/GRASS-7.9.app/Contents/Resources/phrasebooks
rm -r /Applications/GRASS-7.9.app/Contents/Resources/pkgs
rm -r /Applications/GRASS-7.9.app/Contents/Resources/plugins
rm -r /Applications/GRASS-7.9.app/Contents/Resources/qml
rm -r /Applications/GRASS-7.9.app/Contents/Resources/resources
rm -r /Applications/GRASS-7.9.app/Contents/Resources/translations
rm /Applications/GRASS-7.9.app/Contents/Resources/lib/libQt*
</pre>

== Optional: create a binary distribution package
=== 12. Set up folder to make a binary package for distribution ===
Put a copy of the new GRASS app and a symlink to the /Applications folder into a new folder that will become the distribution package.

<pre>
mkdir ../binary_pkg/grass-7.9
cd ../binary_pkg/grass-7.9
cp -R /Applications/GRASS-7.9.app ./
ln -s /Applications Applications
</pre>

=== 13. Use Disk Utility to make a distribution package ===
* Open disk Utility
* From the make file/new image menu, select image from from folder
* Point it to the folder with the app and symlink to /Applications and tell it to make an image ''''GRASS-7.9.dmg''''.

Compiling on macOS using Anaconda

2020-06-02T23:57:34Z

⚠️Cmbarton: fixing some typos and added MacOS version info

== Using Anaconda to Create a Binary Mac App for GRASS ==
These instructions are for creating a self-contained Mac app, including all dependencies, with GRASS 7.9 and Anaconda. You can modify them if you don't need some of the steps. Some of the steps you won't need to repeat (e.g., creating an anaconda environment). You must first install the '''Anaconda package''' for Python from (https://www.anaconda.com). You will of course need to download a copy of the '''GRASS source code''' from (https://grass.osgeo.org). You will also need to install Apple's '''XCode''' and the '''command-line tools''' to compile sofware. This workflow can be used with MacOS 10.14 and 10.15. It may work with other versions, but has not been tested.

You will need to work from the '''Mac terminal''' to compile GRASS of course. This tutorial assumes you are familiare with this command line interface.

This process also requires some patches and other supporting files. You can download these here: [[File:Grass_macapp_anaconda_supporting_files.zip]]

=== 1. Create a Mac app shell (I have uploaded an example for GRASS 7.9 you can use as is, modified from shells created by Eric Hutton). ===
This can be modified serve for different versions of GRASS by altering the last line of the script that launches GRASS in the app shell. To do this, you will need to look inside the app by Ctrl-clicking on it and selecting ''''"show package contents"'''', which reveals the app as a folder with other folders and files inside.

For example, to make a shell for GRASS 7.8, copy the uploaded ''''GRASS-7.9.app'''' and rename it to ''''GRASS-7.8.app''''
Then show package contents for ''''GRASS-7.8.app'''' and use a text editor to modify the last line of the file ''''../GRASS-7.8.app/Contents/MacOS/Grass.sh'''' to refer to GRASS 7.8

change: "$GRASS_PYTHON" "$GISBASE/bin/grass79" "-gui" "$@"
to: "$GRASS_PYTHON" "$GISBASE/bin/grass78" "-gui" "$@"

Also, use a text editor to modify ''''../GRASS-7.9.app/Contents/Info.plist''' to change all references to 7.9 to 7.8.

=== 2. Create an Anaconda environment for Python 3.6.10 ===
This may not be strictly necessary, but I am doing it make sure that my builds use Python 3 instead of Python 2.7, which is still what ships with the Mac.

Anaconda defaults to Python 3.7.6, which will not compile GRASS properly. This makes it more complicated than needed, requiring some workarounds. I've tried this with multiple versions of Python 3 (anaconda has them all the way up to 3.8.2), but the highest version that seems to give consistently successful results is 3.6.10. This will probably change in the future so that you can use a higher version of Python.

Here is how to create an Anaconda environment for Python 3.6.10. You only need to do this once for each environment you want to use.
<pre>
conda create anaconda_p36 python==3.6.10 anaconda
</pre>

=== 3. Activate the Anaconda Python 3.6.10 environment ===
<pre>
conda activate anaconda_p36
</pre>
You can activate any previously created Anaconda environment in this way

=== 4. Copy the Mac app shell to /Applications ===
<pre>
cp -r ../GRASS-7.9.app /Applications/GRASS-7.9.app
</pre>

=== 5. Download the Python 3 miniconda installer and use it to install a minimal anaconda environment into the Mac app shell ===

<pre>
curl https://repo.continuum.io/miniconda/Miniconda3-latest-MacOSX-x86_64.sh > miniconda3.sh
bash ./miniconda3.sh -b -f -p /Applications/GRASS-7.9.app/Contents/Resources
</pre>

=== 6. Export the path to the GRASS Mac app shell so that subsequent operations use the environment of that shell ===

<pre>
export PATH=/Applications/GRASS-7.9.app/Contents/Resources/bin:$PATH
</pre>

=== 7. Install GRASS dependencies into Mac app shell, including Python 3.6.10 ===
A requirements file can make all of these dependencies easier to install. One is included in the supporting files package. This will downgrade Python from v. 3.7.6 installed by miniconda to the more useable 3.6.10.
<pre>
conda install --yes -p "/Applications/GRASS-7.9.app/Contents/Resources" --file=requirements_wxp4p36.txt -c conda-forge
</pre>

=== 8. Create a symlink to Python so that pythonw can find it (may become unneeded in the future) ===
Grass launches Python through the pythonw script. But the script does not point to the correct location for Python (which is in fact in 2 different places). This seems to be a bug in Python \< 3.7.4 or how anaconda installs it. It puts the python launch file in the wrong place. So a symlink is needed. Hopefully this will go away when we can use Python \> 3.7.6, which seems to put python in the correct place, and the place that pythonw points to.
<pre>
ln -sf /Applications/GRASS-7.8.app/Contents/Resources/python.app/pythonapp/Contents/* /Applications/GRASS-7.8.app/Contents/Resources/python.app/Contents
</pre>

=== 9. cd to the grass source folder and apply patches to configure and make files ===
Eric Hutton at CSDMS worked out these patches and I modified one needed to use Python 3. Maybe they can be worked into the source code so that they are no longer needed. I will upload the patches along with the app shell and requirements file.
<pre>
patch -p0 < aclocal.m4.patch
patch -p0 < configure.patch
patch -p0 < install.make.patch
patch -p0 < loader.py.patch
patch -p0 < module.make.patch
patch -p0 < platform.make.in.patch
patch -p0 < rules.make.patch
patch -p0 < shlib.make.patch
</pre>

=== 10. Configure, make, and install ===
An example configure script is included in the grass supporting files package. It flags all dependencies and sets the correct path so that they can be found. '''Important''': this configure script has a hard path to the SDK (software developer kit) that comes with XCode. You can set different path if you've put you SDK in a different place.
<pre>
bash ../configure.sh
make -j4 GDAL_DYNAMIC=
make -j4 install
</pre>

Assuming there were no errors, you should now be able to run and test the GRASS-7.9.app in your /Applications folder

=== 11. Clean up ===
This removes unneeded anaconda package installer files and some other large files that are irrelevant for GRASS. It makes the app much smaller (though still large because of Python, wxPython, and other dependencies are packaged inside)

<pre>
conda clean --all -y
rm -r /Applications/GRASS-7.9.app/Contents/Resources/mkspecs
rm -r /Applications/GRASS-7.9.app/Contents/Resources/phrasebooks
rm -r /Applications/GRASS-7.9.app/Contents/Resources/pkgs
rm -r /Applications/GRASS-7.9.app/Contents/Resources/plugins
rm -r /Applications/GRASS-7.9.app/Contents/Resources/qml
rm -r /Applications/GRASS-7.9.app/Contents/Resources/resources
rm -r /Applications/GRASS-7.9.app/Contents/Resources/translations
rm /Applications/GRASS-7.9.app/Contents/Resources/lib/libQt*
</pre>

== Optional: create a binary distribution package
=== 12. Set up folder to make a binary package for distribution ===
Put a copy of the new GRASS app and a symlink to the /Applications folder into a new folder that will become the distribution package.

<pre>
mkdir ../binary_pkg/grass-7.9
cd ../binary_pkg/grass-7.9
cp -R /Applications/GRASS-7.9.app ./
ln -s /Applications Applications
</pre>

=== 13. Use Disk Utility to make a distribution package ===
* Open disk Utility
* From the make file/new image menu, select image from from folder
* Point it to the folder with the app and symlink to /Applications and tell it to make an image ''''GRASS-7.9.dmg''''.

Compiling on macOS using Anaconda

2020-06-02T23:48:34Z

⚠️Cmbarton: fix link to uploaded file

== Using Anaconda to Create a Binary Mac App for GRASS ==
These instructions are for creating a self-contained Mac app, including all dependencies, with GRASS 7.9 and Anaconda. You can modify them if you don't need some of the steps. Some of the steps he '''Anaconda package''' for Python from (https://www.anaconda.com). You will of course need to download a copy of the '''GRASS source code''' from (https://grass.osgeo.org). You will also need to install Apple's '''XCode''' and the '''command-line tools''' to compile sofware.

You will need to work from the '''Mac terminal''' to compile GRASS of course. This tutorial assumes you are familiare with this command line interface.

This process also requires some patches and other supporting files. You can download these here: [[File:Grass_macapp_anaconda_supporting_files.zip]]

=== 1. Create a Mac app shell (I have uploaded an example for GRASS 7.9 you can use as is, modified from shells created by Eric Hutton). ===
This can be modified serve for different versions of GRASS by altering the last line of the script that launches GRASS in the app shell. To do this, you will need to look inside the app by Ctrl-clicking on it and selecting ''''"show package contents"'''', which reveals the app as a folder with other folders and files inside.

For example, to make a shell for GRASS 7.8, copy the uploaded ''''GRASS-7.9.app'''' and rename it to ''''GRASS-7.8.app''''
Then show package contents for ''''GRASS-7.8.app'''' and use a text editor to modify the last line of the file ''''../GRASS-7.8.app/Contents/MacOS/Grass.sh'''' to refer to GRASS 7.8

change: "$GRASS_PYTHON" "$GISBASE/bin/grass79" "-gui" "$@"
to: "$GRASS_PYTHON" "$GISBASE/bin/grass78" "-gui" "$@"

Also, use a text editor to modify ''''../GRASS-7.9.app/Contents/Info.plist''' to change all references to 7.9 to 7.8.

=== 2. Create an Anaconda environment for Python 3.6.10 ===
This may not be strictly necessary, but I am doing it make sure that my builds use Python 3 instead of Python 2.7, which is still what ships with the Mac.

Anaconda defaults to Python 3.7.6, which will not compile GRASS properly. This makes it more complicated than needed, requiring some workarounds. I've tried this with multiple versions of Python 3 (anaconda has them all the way up to 3.8.2), but the highest version that seems to give consistently successful results is 3.6.10. This will probably change in the future so that you can use a higher version of Python.

Here is how to create an Anaconda environment for Python 3.6.10. You only need to do this once for each environment you want to use.
<pre>
conda create anaconda_p36 python==3.6.10 anaconda
</pre>

=== 3. Activate the Anaconda Python 3.6.10 environment ===
<pre>
conda activate anaconda_p36
</pre>
You can activate any previously created Anaconda environment in this way

=== 4. Copy the Mac app shell to /Applications ===
<pre>
cp -r ../GRASS-7.9.app /Applications/GRASS-7.9.app
</pre>

=== 5. Download the Python 3 miniconda installer and use it to install a minimal anaconda environment into the Mac app shell ===

<pre>
curl https://repo.continuum.io/miniconda/Miniconda3-latest-MacOSX-x86_64.sh > miniconda3.sh
bash ./miniconda3.sh -b -f -p /Applications/GRASS-7.9.app/Contents/Resources
</pre>

=== 6. Export the path to the GRASS Mac app shell so that subsequent operations use the environment of that shell ===

<pre>
export PATH=/Applications/GRASS-7.9.app/Contents/Resources/bin:$PATH
</pre>

=== 7. Install GRASS dependencies into Mac app shell, including Python 3.6.10 ===
A requirements file can make all of these dependencies easier to install. One is included in the supporting files package. This will downgrade Python from v. 3.7.6 installed by miniconda to the more useable 3.6.10.
<pre>
conda install --yes -p "/Applications/GRASS-7.9.app/Contents/Resources" --file=requirements_wxp4p36.txt -c conda-forge
</pre>

=== 8. Create a symlink to Python so that pythonw can find it (may become unneeded in the future) ===
Grass launches Python through the pythonw script. But the script does not point to the correct location for Python (which is in fact in 2 different places). This seems to be a bug in Python \< 3.7.4 or how anaconda installs it. It puts the python launch file in the wrong place. So a symlink is needed. Hopefully this will go away when we can use Python \> 3.7.6, which seems to put python in the correct place, and the place that pythonw points to.
<pre>
ln -sf /Applications/GRASS-7.8.app/Contents/Resources/python.app/pythonapp/Contents/* /Applications/GRASS-7.8.app/Contents/Resources/python.app/Contents
</pre>

=== 9. cd to the grass source folder and apply patches to configure and make files ===
Eric Hutton at CSDMS worked out these patches and I modified one needed to use Python 3. Maybe they can be worked into the source code so that they are no longer needed. I will upload the patches along with the app shell and requirements file.
<pre>
patch -p0 < aclocal.m4.patch
patch -p0 < configure.patch
patch -p0 < install.make.patch
patch -p0 < loader.py.patch
patch -p0 < module.make.patch
patch -p0 < platform.make.in.patch
patch -p0 < rules.make.patch
patch -p0 < shlib.make.patch
</pre>

=== 10. Configure, make, and install ===
An example configure script is included in the grass supporting files package. It flags all dependencies and sets the correct path so that they can be found. '''Important''': this configure script has a hard path to the SDK (software developer kit) that comes with XCode. You can set different path if you've put you SDK in a different place.
<pre>
bash ../configure.sh
make -j4 GDAL_DYNAMIC=
make -j4 install
</pre>

Assuming there were no errors, you should now be able to run and test the GRASS-7.9.app in your /Applications folder

=== 11. Clean up ===
This removes unneeded anaconda package installer files and some other large files that are irrelevant for GRASS. It makes the app much smaller (though still large because of Python, wxPython, and other dependencies are packaged inside)

<pre>
conda clean --all -y
rm -r /Applications/GRASS-7.9.app/Contents/Resources/mkspecs
rm -r /Applications/GRASS-7.9.app/Contents/Resources/phrasebooks
rm -r /Applications/GRASS-7.9.app/Contents/Resources/pkgs
rm -r /Applications/GRASS-7.9.app/Contents/Resources/plugins
rm -r /Applications/GRASS-7.9.app/Contents/Resources/qml
rm -r /Applications/GRASS-7.9.app/Contents/Resources/resources
rm -r /Applications/GRASS-7.9.app/Contents/Resources/translations
rm /Applications/GRASS-7.9.app/Contents/Resources/lib/libQt*
</pre>

== Optional: create a binary distribution package
=== 12. Set up folder to make a binary package for distribution ===
Put a copy of the new GRASS app and a symlink to the /Applications folder into a new folder that will become the distribution package.

<pre>
mkdir ../binary_pkg/grass-7.9
cd ../binary_pkg/grass-7.9
cp -R /Applications/GRASS-7.9.app ./
ln -s /Applications Applications
</pre>

=== 13. Use Disk Utility to make a distribution package ===
* Open disk Utility
* From the make file/new image menu, select image from from folder
* Point it to the folder with the app and symlink to /Applications and tell it to make an image ''''GRASS-7.9.dmg''''.

Compiling on macOS using Anaconda

2020-06-02T23:48:02Z

⚠️Cmbarton: change how links are displayed

== Using Anaconda to Create a Binary Mac App for GRASS ==
These instructions are for creating a self-contained Mac app, including all dependencies, with GRASS 7.9 and Anaconda. You can modify them if you don't need some of the steps. Some of the steps he '''Anaconda package''' for Python from (https://www.anaconda.com). You will of course need to download a copy of the '''GRASS source code''' from (https://grass.osgeo.org). You will also need to install Apple's '''XCode''' and the '''command-line tools''' to compile sofware.

You will need to work from the '''Mac terminal''' to compile GRASS of course. This tutorial assumes you are familiare with this command line interface.

This process also requires some patches and other supporting files. You can download these here: [[Grass_macapp_anaconda_supporting_files.zip]]

=== 1. Create a Mac app shell (I have uploaded an example for GRASS 7.9 you can use as is, modified from shells created by Eric Hutton). ===
This can be modified serve for different versions of GRASS by altering the last line of the script that launches GRASS in the app shell. To do this, you will need to look inside the app by Ctrl-clicking on it and selecting ''''"show package contents"'''', which reveals the app as a folder with other folders and files inside.

For example, to make a shell for GRASS 7.8, copy the uploaded ''''GRASS-7.9.app'''' and rename it to ''''GRASS-7.8.app''''
Then show package contents for ''''GRASS-7.8.app'''' and use a text editor to modify the last line of the file ''''../GRASS-7.8.app/Contents/MacOS/Grass.sh'''' to refer to GRASS 7.8

change: "$GRASS_PYTHON" "$GISBASE/bin/grass79" "-gui" "$@"
to: "$GRASS_PYTHON" "$GISBASE/bin/grass78" "-gui" "$@"

Also, use a text editor to modify ''''../GRASS-7.9.app/Contents/Info.plist''' to change all references to 7.9 to 7.8.

=== 2. Create an Anaconda environment for Python 3.6.10 ===
This may not be strictly necessary, but I am doing it make sure that my builds use Python 3 instead of Python 2.7, which is still what ships with the Mac.

Anaconda defaults to Python 3.7.6, which will not compile GRASS properly. This makes it more complicated than needed, requiring some workarounds. I've tried this with multiple versions of Python 3 (anaconda has them all the way up to 3.8.2), but the highest version that seems to give consistently successful results is 3.6.10. This will probably change in the future so that you can use a higher version of Python.

Here is how to create an Anaconda environment for Python 3.6.10. You only need to do this once for each environment you want to use.
<pre>
conda create anaconda_p36 python==3.6.10 anaconda
</pre>

=== 3. Activate the Anaconda Python 3.6.10 environment ===
<pre>
conda activate anaconda_p36
</pre>
You can activate any previously created Anaconda environment in this way

=== 4. Copy the Mac app shell to /Applications ===
<pre>
cp -r ../GRASS-7.9.app /Applications/GRASS-7.9.app
</pre>

=== 5. Download the Python 3 miniconda installer and use it to install a minimal anaconda environment into the Mac app shell ===

<pre>
curl https://repo.continuum.io/miniconda/Miniconda3-latest-MacOSX-x86_64.sh > miniconda3.sh
bash ./miniconda3.sh -b -f -p /Applications/GRASS-7.9.app/Contents/Resources
</pre>

=== 6. Export the path to the GRASS Mac app shell so that subsequent operations use the environment of that shell ===

<pre>
export PATH=/Applications/GRASS-7.9.app/Contents/Resources/bin:$PATH
</pre>

=== 7. Install GRASS dependencies into Mac app shell, including Python 3.6.10 ===
A requirements file can make all of these dependencies easier to install. One is included in the supporting files package. This will downgrade Python from v. 3.7.6 installed by miniconda to the more useable 3.6.10.
<pre>
conda install --yes -p "/Applications/GRASS-7.9.app/Contents/Resources" --file=requirements_wxp4p36.txt -c conda-forge
</pre>

=== 8. Create a symlink to Python so that pythonw can find it (may become unneeded in the future) ===
Grass launches Python through the pythonw script. But the script does not point to the correct location for Python (which is in fact in 2 different places). This seems to be a bug in Python \< 3.7.4 or how anaconda installs it. It puts the python launch file in the wrong place. So a symlink is needed. Hopefully this will go away when we can use Python \> 3.7.6, which seems to put python in the correct place, and the place that pythonw points to.
<pre>
ln -sf /Applications/GRASS-7.8.app/Contents/Resources/python.app/pythonapp/Contents/* /Applications/GRASS-7.8.app/Contents/Resources/python.app/Contents
</pre>

=== 9. cd to the grass source folder and apply patches to configure and make files ===
Eric Hutton at CSDMS worked out these patches and I modified one needed to use Python 3. Maybe they can be worked into the source code so that they are no longer needed. I will upload the patches along with the app shell and requirements file.
<pre>
patch -p0 < aclocal.m4.patch
patch -p0 < configure.patch
patch -p0 < install.make.patch
patch -p0 < loader.py.patch
patch -p0 < module.make.patch
patch -p0 < platform.make.in.patch
patch -p0 < rules.make.patch
patch -p0 < shlib.make.patch
</pre>

=== 10. Configure, make, and install ===
An example configure script is included in the grass supporting files package. It flags all dependencies and sets the correct path so that they can be found. '''Important''': this configure script has a hard path to the SDK (software developer kit) that comes with XCode. You can set different path if you've put you SDK in a different place.
<pre>
bash ../configure.sh
make -j4 GDAL_DYNAMIC=
make -j4 install
</pre>

Assuming there were no errors, you should now be able to run and test the GRASS-7.9.app in your /Applications folder

=== 11. Clean up ===
This removes unneeded anaconda package installer files and some other large files that are irrelevant for GRASS. It makes the app much smaller (though still large because of Python, wxPython, and other dependencies are packaged inside)

<pre>
conda clean --all -y
rm -r /Applications/GRASS-7.9.app/Contents/Resources/mkspecs
rm -r /Applications/GRASS-7.9.app/Contents/Resources/phrasebooks
rm -r /Applications/GRASS-7.9.app/Contents/Resources/pkgs
rm -r /Applications/GRASS-7.9.app/Contents/Resources/plugins
rm -r /Applications/GRASS-7.9.app/Contents/Resources/qml
rm -r /Applications/GRASS-7.9.app/Contents/Resources/resources
rm -r /Applications/GRASS-7.9.app/Contents/Resources/translations
rm /Applications/GRASS-7.9.app/Contents/Resources/lib/libQt*
</pre>

== Optional: create a binary distribution package
=== 12. Set up folder to make a binary package for distribution ===
Put a copy of the new GRASS app and a symlink to the /Applications folder into a new folder that will become the distribution package.

<pre>
mkdir ../binary_pkg/grass-7.9
cd ../binary_pkg/grass-7.9
cp -R /Applications/GRASS-7.9.app ./
ln -s /Applications Applications
</pre>

=== 13. Use Disk Utility to make a distribution package ===
* Open disk Utility
* From the make file/new image menu, select image from from folder
* Point it to the folder with the app and symlink to /Applications and tell it to make an image ''''GRASS-7.9.dmg''''.

Compiling on macOS using Anaconda

2020-06-02T23:45:43Z

⚠️Cmbarton: add workflow to create Mac app binary using Anaconda

== Using Anaconda to Create a Binary Mac App for GRASS ==
These instructions are for creating a self-contained Mac app, including all dependencies, with GRASS 7.9 and Anaconda. You can modify them if you don't need some of the steps. Some of the steps he '''Anaconda package''' for Python from [https://www.anaconda.com](https://www.anaconda.com). You will of course need to download a copy of the '''GRASS source code''' from [https://grass.osgeo.org](https://grass.osgeo.org). You will also need to install Apple's '''XCode''' and the '''command-line tools''' to compile sofware.

You will need to work from the '''Mac terminal''' to compile GRASS of course. This tutorial assumes you are familiare with this command line interface.

This process also requires some patches and other supporting files. You can download these here: [[File:Grass_macapp_anaconda_supporting_files.zip]]

=== 1. Create a Mac app shell (I have uploaded an example for GRASS 7.9 you can use as is, modified from shells created by Eric Hutton). ===
This can be modified serve for different versions of GRASS by altering the last line of the script that launches GRASS in the app shell. To do this, you will need to look inside the app by Ctrl-clicking on it and selecting ''''"show package contents"'''', which reveals the app as a folder with other folders and files inside.

For example, to make a shell for GRASS 7.8, copy the uploaded ''''GRASS-7.9.app'''' and rename it to ''''GRASS-7.8.app''''
Then show package contents for ''''GRASS-7.8.app'''' and use a text editor to modify the last line of the file ''''../GRASS-7.8.app/Contents/MacOS/Grass.sh'''' to refer to GRASS 7.8

change: "$GRASS_PYTHON" "$GISBASE/bin/grass79" "-gui" "$@"
to: "$GRASS_PYTHON" "$GISBASE/bin/grass78" "-gui" "$@"

Also, use a text editor to modify ''''../GRASS-7.9.app/Contents/Info.plist''' to change all references to 7.9 to 7.8.

=== 2. Create an Anaconda environment for Python 3.6.10 ===
This may not be strictly necessary, but I am doing it make sure that my builds use Python 3 instead of Python 2.7, which is still what ships with the Mac.

Anaconda defaults to Python 3.7.6, which will not compile GRASS properly. This makes it more complicated than needed, requiring some workarounds. I've tried this with multiple versions of Python 3 (anaconda has them all the way up to 3.8.2), but the highest version that seems to give consistently successful results is 3.6.10. This will probably change in the future so that you can use a higher version of Python.

Here is how to create an Anaconda environment for Python 3.6.10. You only need to do this once for each environment you want to use.
<pre>
conda create anaconda_p36 python==3.6.10 anaconda
</pre>

=== 3. Activate the Anaconda Python 3.6.10 environment ===
<pre>
conda activate anaconda_p36
</pre>
You can activate any previously created Anaconda environment in this way

=== 4. Copy the Mac app shell to /Applications ===
<pre>
cp -r ../GRASS-7.9.app /Applications/GRASS-7.9.app
</pre>

=== 5. Download the Python 3 miniconda installer and use it to install a minimal anaconda environment into the Mac app shell ===

<pre>
curl https://repo.continuum.io/miniconda/Miniconda3-latest-MacOSX-x86_64.sh > miniconda3.sh
bash ./miniconda3.sh -b -f -p /Applications/GRASS-7.9.app/Contents/Resources
</pre>

=== 6. Export the path to the GRASS Mac app shell so that subsequent operations use the environment of that shell ===

<pre>
export PATH=/Applications/GRASS-7.9.app/Contents/Resources/bin:$PATH
</pre>

=== 7. Install GRASS dependencies into Mac app shell, including Python 3.6.10 ===
A requirements file can make all of these dependencies easier to install. One is included in the supporting files package. This will downgrade Python from v. 3.7.6 installed by miniconda to the more useable 3.6.10.
<pre>
conda install --yes -p "/Applications/GRASS-7.9.app/Contents/Resources" --file=requirements_wxp4p36.txt -c conda-forge
</pre>

=== 8. Create a symlink to Python so that pythonw can find it (may become unneeded in the future) ===
Grass launches Python through the pythonw script. But the script does not point to the correct location for Python (which is in fact in 2 different places). This seems to be a bug in Python \< 3.7.4 or how anaconda installs it. It puts the python launch file in the wrong place. So a symlink is needed. Hopefully this will go away when we can use Python \> 3.7.6, which seems to put python in the correct place, and the place that pythonw points to.
<pre>
ln -sf /Applications/GRASS-7.8.app/Contents/Resources/python.app/pythonapp/Contents/* /Applications/GRASS-7.8.app/Contents/Resources/python.app/Contents
</pre>

=== 9. cd to the grass source folder and apply patches to configure and make files ===
Eric Hutton at CSDMS worked out these patches and I modified one needed to use Python 3. Maybe they can be worked into the source code so that they are no longer needed. I will upload the patches along with the app shell and requirements file.
<pre>
patch -p0 < aclocal.m4.patch
patch -p0 < configure.patch
patch -p0 < install.make.patch
patch -p0 < loader.py.patch
patch -p0 < module.make.patch
patch -p0 < platform.make.in.patch
patch -p0 < rules.make.patch
patch -p0 < shlib.make.patch
</pre>

=== 10. Configure, make, and install ===
An example configure script is included in the grass supporting files package. It flags all dependencies and sets the correct path so that they can be found. '''Important''': this configure script has a hard path to the SDK (software developer kit) that comes with XCode. You can set different path if you've put you SDK in a different place.
<pre>
bash ../configure.sh
make -j4 GDAL_DYNAMIC=
make -j4 install
</pre>

Assuming there were no errors, you should now be able to run and test the GRASS-7.9.app in your /Applications folder

=== 11. Clean up ===
This removes unneeded anaconda package installer files and some other large files that are irrelevant for GRASS. It makes the app much smaller (though still large because of Python, wxPython, and other dependencies are packaged inside)

<pre>
conda clean --all -y
rm -r /Applications/GRASS-7.9.app/Contents/Resources/mkspecs
rm -r /Applications/GRASS-7.9.app/Contents/Resources/phrasebooks
rm -r /Applications/GRASS-7.9.app/Contents/Resources/pkgs
rm -r /Applications/GRASS-7.9.app/Contents/Resources/plugins
rm -r /Applications/GRASS-7.9.app/Contents/Resources/qml
rm -r /Applications/GRASS-7.9.app/Contents/Resources/resources
rm -r /Applications/GRASS-7.9.app/Contents/Resources/translations
rm /Applications/GRASS-7.9.app/Contents/Resources/lib/libQt*
</pre>

== Optional: create a binary distribution package
=== 12. Set up folder to make a binary package for distribution ===
Put a copy of the new GRASS app and a symlink to the /Applications folder into a new folder that will become the distribution package.

<pre>
mkdir ../binary_pkg/grass-7.9
cd ../binary_pkg/grass-7.9
cp -R /Applications/GRASS-7.9.app ./
ln -s /Applications Applications
</pre>

=== 13. Use Disk Utility to make a distribution package ===
* Open disk Utility
* From the make file/new image menu, select image from from folder
* Point it to the folder with the app and symlink to /Applications and tell it to make an image ''''GRASS-7.9.dmg''''.

File:Grass macapp anaconda supporting files.zip

2020-06-02T18:36:16Z

⚠️Cmbarton: Supporting files for workflow to create a binary Mac app for GRASS, using Anaconda

Supporting files for workflow to create a binary Mac app for GRASS, using Anaconda

MacOSX GRASS errors

2020-04-23T23:03:28Z

⚠️Cmbarton: updating issues and solutions

Here some problems reported by users along with solutions:

== Starting GRASS GIS on MacOSX, I get "image not found" ==

A) You may be lacking the installation of one or several "frameworks" (e.g. GDAL). Get them from here:

http://grass.osgeo.org/download/software/mac-osx/
--> Install the required framework packages first

This is not needed for binaries created for versions 7.2.2 and higher on the [http://grassmac.wikidot.com GRASS for Mac site] because all dependencies, including Python and wxPython are included in the binary app.

B) You are hit by the SIP - System Integrity Protection - security measure which prevents some software from being installed properly. Please see the internet for suggestions how to deal with that. Alternative: use "[[Compiling on MacOSX using homebrew|homebrew]]" to install GRASS GIS. This is no longer a problem in binaries created for versions 7.2.2 and higher on the [http://grassmac.wikidot.com GRASS for Mac site] because all dependencies, including Python and wxPython are included in the binary app.

== Starting GRASS GIS on MacOSX, I get "bad cpu type in executable" ==

It looks like a macports problem (maybe ''homebrew'' also uses /opt/local?) with their Python. A guess is that their python is 64bit-only, and GRASS is trying to run python 32bit because it couldn't find a 64bit wxpython because 64bit wxpython isn't existing yet in the stable release. 
Work-around: Edit the file ".bash_profile" in your HOME directory and add therein:

export GRASS_PYTHON=/usr/bin/python2.6
export GRASS_PYTHONWX=/usr/bin/pythonw2.6

The newest versions of GRASS 7.8.2 and up) are designed to work with Python 3. So you may want to install Python 3 and change the path for GRASS_PYTHON and GRASS_PYTHONWX accordingly

This is not a problem for binaries created for versions 7.2.2 and higher on the [http://grassmac.wikidot.com GRASS for Mac site] because all dependencies, including Python and wxPython are included in the binary app.

== When using g.extension, I get "fatal error: grass/gis.h: No such file or directory" ==

Hint: g.extension should indeed work. The main key is that you need to install the Xcode command line tools. This can be done either from the Xcode app (free from app store), or by downloading the command line tools installer separately (from an Apple developer account).

== When using g.extension after updating to MacOSX Mojave and Xcode 10, I get "fatal error: 'stdio.h' file not found" ==

Note: Updating to MacOSX Mojave and Xcode 10 moves the location of the c header files preventing some GRASS extensions from compiling.

Solution: Install the package file located at the below path to add c header files in /usr/include:

/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

'''Update'''

Fix this issue by updating ''/Applications/GRASS-7.6.app/Contents/Resources/include/Make/Platform.make''

By replacing all references to /Developer/SDKs/MacOSX10.9.sdk with the updated sdk path /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

'''Variables to Update'''

CFLAGS = -g -O2 -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
CXXFLAGS = -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
INCLUDE_DIRS = -I/Applications/GRASS-7.6.app/Contents/Resources/include
LINK_FLAGS = -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -L/Applications/GRASS-7.6.app/Contents/Resources/lib -Xlinker -rpath -Xlinker ${prefix}/lib -Xlinker -rpath -Xlinker ${RUN_GISBASE}/lib

MACOSX_SDK = -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

== Starting GRASS GIS on MacOSX, I get "AppleScript Error. Terminal got an error: Can't get window 1. (-1728)" ==

Note: Normally when Terminal is activated (running or not), it starts a new window if there is none open, but I've seen cases where it does not when you start Terminal when it was NOT running.

Solution: Try starting Terminal first, then start GRASS.

Note that it may still take a long time to launch the terminal and GRASS sometimes, for unknown reasons, especially for the first time after a new installation or update. Be patient.

== Starting GRASS GIS on MacOSX, I get "ERROR: unknown locale: UTF-8" ==

You need to add these two lines

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

to the file ".bash_profile" in your HOME directory. You can use any text editor to create/edit the file $HOME/.bash_profile (the same: ~/.bash_profile) and copy-paste the these two lines. Just be sure to save it as ".bash_profile" in your home directory.

== d.legend does not show numbers ==

Problem: d.legend and other text is not shown in the display!

Solution: You need to rescan the fonts available on your system:

g.mkfontcap -o

== 3D view error on MacOS (black screen) ==

Problem: 3D view error on MacOS (black screen)

Solution: compile GRASS GIS using [[Compiling on MacOSX using homebrew|homebrew]] libraries. The trick was to set --with-opengl=aqua, so it uses the opengl librarie from the system. Using --with-opengl=x11 results in the black screen.

== See also ==

* MacOSX GRASS Support forum: http://grassmac.wikidot.com/forum:start
* http://www.kyngchaos.com/software/support/faq
* [[WinGRASS errors]]

[[Category: FAQ]]
[[Category: Installation‏‎]]

Team

2016-11-23T16:40:24Z

⚠️Cmbarton: updated my listing and photo

The GRASS GIS project is an international team effort with scientists and developers participating from various fields. Below is a list of the current team.

All general queries concerning GRASS should be addressed to the respective [http://grass.osgeo.org/support/mailing-lists/ GRASS mailing lists]. If you miss yourself or somebody else on the lists below, please feel free to edit this Wiki page or send mail to the [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list].
__TOC__
== Current contributors to the development of the GRASS code ==

In alphabetical order; see for example [http://www.ohloh.net/p/grass_gis/contributors here] for contribution statistics.

{| class="wikitable sortable" border="1" style="margin: 1em auto 1em auto; text-align:left"
| width=200px | [[Image:Grasslogo vector small.png|100px|center]]
| '''Anna Kratochvílová''': GRASS 7 wxGUI development, Prague, CZ, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:benjamin.png|100px|center|center]]
| '''Benjamin Ducke''': extension manager, spatial statistics, archaeological applications, predictive modelling Location: Berlin, Germany, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Glynn Clements''': core development, UK, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list ]

|-
| [[Image:hamish.jpg|100px|center]]
| '''Hamish Bowman''': Development of display, PostScript, raster, and GPS modules as well as general sanitation of the code, help, and web pages. Location: Department of Marine Science, University of Otago. Dunedin, New Zealand mail: hamish_b AT yahoo com [http://hamish.bowman.googlepages.com/grassfiles http://hamish.bowman.googlepages.com/grassfiles]

|-
| [[Image:helena.jpg|100px|center]]
| '''Helena Mitasova''': surface and volume modeling and analysis (RST modules), topographic analysis, hydrologic and erosion modelling, assistance with visualization, working with students on new module development, testing, and bug fixing Location: Raleigh, North Carolina, USA, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list ][http://www4.ncsu.edu/~hmitaso/ http://www4.ncsu.edu/~hmitaso/]

|-
| [[Image:hellik.png|100px|center]]
| '''Helmut Kudrnovsky''': [http://grass.osgeo.org/grass64/binary/mswindows/native/ winGRASS packaging],german translation, Austria, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Huidae Cho''': Hydrologic modeling (TOPMODEL modules), DXF modules, FreeType support, Korean translation. Location: Atlanta, Georgia, USA mail: grass4u AT gmail com, IRC Nick: grass4u [http://idea.isnew.info http://idea.isnew.info]

|-
| [[Image:lucadelu.png|100px|center]]
| '''Luca Delucchi''': Python GRASS development (GUI and Modules), Documentation, Italian Translation, Location: Trento (Italy), mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Maris_nartiss.jpg|100px|center]]
| '''[[user:MarisN|Maris Nartiss]]''': Tcl/TK GUI development, Latvia, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Markus Metz''': GRASS 7 development, massive data processing, vector library, Italy + Germany, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:markus.jpg|100px|center]]
| '''Markus Neteler''': various contributions, coordination, main Web site and mailing lists maintenance, Location: Trento, Italy, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list], IRC Nick: markusN [http://www.grassbook.org/neteler/ http://www.grassbook.org/neteler/]

|-
| [[Image:mlanda.png|100px|center]]
| '''Martin Landa''': various contributions, vector engine improvements, [[wxGUI]], Location: Prague, Czech Republic Mail: landa.martin AT gmail.com Homepage: [http://geo.fsv.cvut.cz/~landa http://geo.fsv.cvut.cz/~landa]

|-
| [[Image:michael.jpg|100px|center]]
| '''Michael Barton ''': GRASS native GUI development, Mac binaries, Location: Tempe, Arizona, USA mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list ][http://www.public.asu.edu/~cmbarton/ http://www.public.asu.edu/~cmbarton/]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Moritz Lennert''': display tools, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Soeren Gebbert''': improvements of [http://www-pool.math.tu-berlin.de/~soeren/grass/ 3D functionality] mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Stepan Turek''': GRASS 7 wxGUI development, Prague, CZ, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Vaclav Petras''': GRASS 7 wxGUI development, Prague, CZ, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''William Kyngesburye''': [http://www.kyngchaos.com/software:grass/ Mac OS X packaging], USA, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Yann Chemin''': image processing, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Nikos Alexandris''': tester, contributed add-ons, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''''your name''': what-you-do, Location: xyz, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list], link: ''

|}

== Former or currently inactive developers ==

(in alphabetical order)

{| class="wikitable sortable" border="1" style="margin: 1em auto 1em auto; text-align:left"
| width=200px | [[Image:Grasslogo vector small.png|100px|center]]
| '''Bob Covill''' Role: visualization, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list ]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Brad Douglas''' Role: bug fixing, code portability, imagery modules Location: Fremont, California, USA, IRC Nick: bdouglas, mail: rez AT touchofmadness com

|-
| [[Image:cedric.jpg|100px|center]]
| '''Cedric Shock''' Role: user interface enhancements, debugging Location: Eugene, Oregon, USA, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list], [http://www.shockfamily.net/cedric/ http://www.shockfamily.net/cedric/]

|-
| [[Image:DaveSampson.png|100px|center]]
| '''Dave Sampson''' Role: tutorials, data sets & public data licensing, GRASS map gallery, Ottawa Chapter of OSGeo, Location: Ottawa, Ontario, Canada, mail: samper.d at gmail dot com [http://davidsampson.ca/ http://davidsampson.ca]

|-
| [[Image:jachym.png|100px|center]]
| '''Jachym Cepicky''' Role: bug fixing, support of 3D vectors, tester and translator, UI developer, Czech Republic, mail: jachym.cepicky AT gmail.com [http://les-ejk.cz/ http://les-ejk.cz/]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Jaroslav Hofierka''' Role: development of modules for solar irradiation, flow routing, surface and volume modelling and analysis (RST modules), hydrologic and erosion modelling, assistance with visualization Location: Presov, Slovakia, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list ]

|-
| [[Image:maciek.png|100px|center]]
| '''Maciej Sieczka''' Role: power user, testing Location: Wroclaw, Poland, mail: msieczka AT sieczka.org [http://www.sieczka.org/ http://www.sieczka.org]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Marco Pasetti''' Role: Microsoft Windows native binary port of GRASS Location: Brescia, Italy, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list], link: [http://grass.osgeo.org/grass64/binary/mswindows/native/ WinGRASS Project Homepage]

|-
| [[Image:Grasslogo vector small.png|100px|center]]
| '''Paul Kelly''' Role: Proj integration, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list ]

|-
| [[Image:radim.jpg|100px|center]]
| '''Radim Blazek''' Role: DBMI, vector engine core developer, Location: Trento, Italy till 2006, mail: [http://lists.osgeo.org/mailman/listinfo/grass-dev GRASS developers mailing list]

|-
| [[Image:scott.jpg|100px|center]]
| '''Scott Mitchell''' Role: tutorial and documentation development, web site maintenance, Ottawa User's Group, OSGeo Journal News and Events Editor Location: Ottawa, Ontario, Canada, mail: [http://lists.osgeo.org/mailman/listinfo/grass-web GRASS web site maintenance mailing list] [http://www.carleton.ca/~smitch http://www.carleton.ca/~smitch]

|}

== The following institutions are currently supporting the GRASS-Project ==

Please see our [http://grass.osgeo.org/donations/ GRASS sponsoring] page.

And a ''thank-you'' to:

* the many people who have contributed in the past
* the various users who have contributed bug reports and tested unstable GRASS versions;
* all the sites (and the people behind them) that provide mirrors for the GRASS web pages.

File:Michael.jpg

2016-11-23T16:38:32Z

⚠️Cmbarton: Cmbarton uploaded a new version of File:Michael.jpg

Identity

2015-01-29T12:15:31Z

⚠️Cmbarton:

= The need of a visual identity=
GRASS is still lacking a relevant, well tempered graphical identity. Some proposals are being discussed especially to design a new splash screen (and welcome banner). The full thread is [http://lists.osgeo.org/pipermail/grass-dev/2015-January/073157.html there].

This page is intended to initiate a place where tests and suggestions could be gathered.

== Logotype ==
===Graphics===
[http://grasswiki.osgeo.org/wiki/GRASS_Logo GRASS official logo] is a great starting point, as it has been here for ...ever?
Given the original vector file is somewhat irregular (twisted diamond, doubled vertices in grass, overlapping shapes) a ''cleaned'' light version is proposed.

[[File:GRASSGIS_logo_color.png|150px|thumbnail|center|GRASS GIS cleanup logo, color version]]

For consistency, it is important to use this logo ''as is'', i.e. not being tempted to distort it by any trick (shadows, bump mapping, blur, differential rescaling,...).

Itemisation should be limited to: 
* black (and grayscale) version;

[[File:GRASSGIS_logo_gray.png|150px|thumbnail|center|GRASS GIS cleanup logo, grayscale version]]

* white version, in case it should appear over a dark background/image.

[[File:GRASSGIS_logo_white.png|150px|thumbnail|center|GRASS GIS cleanup logo, white (sort of negative) version]]

===Tagline===
The ''historical'' one was : «The world's leading open source GIS». Several slogans were recently proposed:

- «Bringing advanced geospatial technologies to the world»;
- «Advanced geospatial technology for everyone»;
- «Opening advanced geospatial technologies to the world».
- ...

== Colors ==
===A grass green...===
The basic green color is defined as follows:

- 0,144,0 (rgb);
- 100,100,44 (cmyk);
- #009000 (html).

aplha channel is set to 1 (no transparency)

===...and a grayscale tone===
When required, a grayscale transposition is applied to green:

*either it is an opaque grey:
- 144,144,144 (rgb);
- 0,0,0,44 (cmyk);
- #909090 (html),

*or it is multiplied over background, with alpha transparency:
- 0,0,0,111 (rgba);
- 0,0,0,100,44 (cmyk);
- #0000006f (html).

The white version may as well be declined in opaque or transparent, then green is replaced with translucent white:
- 255,255,255,111 (rgba);
- 0,0,0,0,44 (cmyk);
- #ffffff6f (html).

== Typo ==
The logo can come with text. It uses two fonts. Add your suggestions...
===Main font===
GRASS GIS name, capitalized. Composed in [http://www.exljbris.com/fontin.html Fontin] regular, with a slightly negative approach. This font is designed by Jos Buivenga, and is [http://www.exljbris.com/eula.html free].
''Comment by ML: this seems to be free as in free beer, but not as in free speech (no distribution allowed. For an OSGeo project such as GRASS, I would prefer a really free font.''

Yes, I agree. Not that easy to find a fully developed font family (lots of ugly things in fact...). Let's have a look at [https://en.wikipedia.org/wiki/Fira_Sans this project]. It makes sense to confront a modern sans serif typeface, preferably light, to a very classical Garamond. See below tests number 5 and 6. Changing GRASS GIS to lowercase was done on purpose, my opinion is GRASS initials usage turned the word into an acronym, which does not need to be capitalized.

The Fira Sans is a nice clean font. GRASS IS an acronym of course (geographic resource analysis support system), but the lower case is fine after all these years and indeed looks good.

===Secondary font===
This typeface is used to display additional text, such as a ''motto'' or tagline. It is composed in [http://www.georgduffner.at/ebgaramond/index.html EB Garamond], a font designed by Georg Duffner, inspired by the famous historical typeface drawn hundreds of years ago by Claude Garamond. It is freely available, under the terms of the SIL Open Fonts License (ofl).

= Applications =
== GRASS GIS Splash screen==
=== Objective ===
Please refer to [http://lists.osgeo.org/pipermail/grass-dev/2015-January/073157.html this thread]

=== Proposals ===
Here are several tests, feel free to add yours of course.

[[File:GRASSGIS_splash1.jpg|350px|thumbnail|center|GRASS GIS splash screen with minimalist color logo+text]]
[[File:GRASSGIS_splash2.jpg|350px|thumbnail|center|GRASS GIS splash screen with white logo+tagline, metaphoric background image (to be refined)]]
[[File:GRASSGIS_splash3.jpg|350px|thumbnail|center|GRASS GIS splash screen with white logo+tagline, variation in the layout, personal background image (for the record)]]
[[File:GRASSGIS_splash4.jpg|350px|thumbnail|center|GRASS GIS splash screen with white logo+tagline, grassy world map background image (made from scratch in Blender)]]
[[File:GRASSGIS_splash5.jpg|350px|thumbnail|center|GRASS GIS splash screen with white logo+tagline, another attempt with Fira Sans as titling font]]
[[File:GRASSGIS_splash6.jpg|350px|thumbnail|center|GRASS GIS splash screen with color logo+tagline, Fira Sans titling in a more sobre composition]]

== GRASS GIS Welcome banner==

The welcome banner is the image displayed on top of the Welcome frame that pops up when launching GRASS. This image, if present, should be coherent with the graphic design.

=== Proposals ===
[[File:GRASSGIS_welcome_banner1.jpg|300px|thumbnail|center|GRASS GIS simple welcome banner]]
[[File:GRASSGIS_welcome_banner2.jpg|300px|thumbnail|center|GRASS GIS simple welcome banner with transparency (fails on dark bg desktop themes)]]
[[File:GRASSGIS_welcome_banner3.jpg|300px|thumbnail|center|GRASS GIS simple welcome banner, small logo, bigger text, works on every background tone]]

== What next ?==
add your suggestions...

[[Category: Development‏‎]]
[[Category: Branding]]
[[Category: Promotion]]

LIDAR

2013-02-24T22:55:09Z

⚠️Cmbarton: /* Analysis */

<h1> LIDAR and Multi-beam Swath bathymetry data </h1>

Point cloud data, as a type of representation of 3D surfaces, are usually produced by airborne or on-ground laser scanning, also known as Light Detection and Ranging (LiDAR). The data are often provided as sets of very dense (x, y, z) points or in a more complex, public file binary format called LAS that may include multiple returns as well as intensities. GRASS GIS supports basic and advanced lidar data processing and analysis.

== Modules ==

In this section various modules are introduced.

=== Import ===

* {{cmd|r.in.xyz}} - Create a raster map from an assemblage of many coordinates using univariate statistics. ([http://hamish.bowman.googlepages.com/grassfiles#xyz example])

* {{cmd|r.in.lidar}} - (GRASS 7 only; GRASS must be compiled with libLAS support) Create a raster map from a binary LAS format LiDAR file (*.las) using univariate statistics and filtering. r.in.lidar is based on r.in.xyz. In addition to the options of r.in.xyz, r.in.lidar provides some basic lidar point fileter options.

* {{cmd|v.in.ascii}} - Import data from an ASCII file to GRASS vector format.
: ''Due to memory overhead vector point imports will be limited to a few million data points unless topology and database creation is skipped with the '''-bt''' flags''. It may also be useful to clip the import file to only accept points falling within the current region by using the '''-r''' flag. See {{cmd|g.region}} for details on specifying the region bounds.

* {{cmd|v.in.lidar}} - (GRASS 7 only; GRASS must be compiled with libLAS support). Creates a vector points file from a binary LAS format LiDAR file (*.las or *.laz). r.in.lidar also can create a new location based on the LAS file, and can filter the input points by return and subregion.

=== Analysis ===

* {{cmd|v.outlier}} - Removes outliers from vector point data.

* {{cmd|v.lidar.edgedetection}} - Uses interpolation and edge detection to create a new vector points file of LiDAR data so that the resulting attribute table is reclassified with CAT=1 for points associated with the ground surface (i.e., terrain) and useful for interpolating a raster terrain (DEM) map, CAT=2 for points pertaining to edges of human-contructed objects, and CAT=3 for other points that could pertain to vegetation or other features.

* {{cmd|v.lidar.growing}} - Building contour determination and region growing algorithm for determining the building inside.

* {{cmd|v.lidar.correction}} - Correction of the v.lidar.growing output. It is the last of the three algorithms for LIDAR filtering.

''References:''

* Detailed description: [http://www.foss4g2006.org/getFile.py/access?contribId=48&sessionId=59&resId=7&materialId=slides&confId=1 here] (FOSS4G 2006)
* Summarised version: [http://geomatica.como.polimi.it/corsi/remote_sensing/LiDAR_filtering_with_GRASS-lab4.pdf here] (2010)
* Calibration of the filtering parameters (around 20 parameters) by integrating the USGS UCODE and GRASS, see [http://www.isprs.org/proceedings/XXXVIII/1_4_7-W5/paper/Brovelli-126.pdf here]

=== Surface generation ===

* {{cmd|v.surf.rst}} - Spatial approximation and topographic analysis using regularized spline with tension.

* {{cmd|v.surf.idw}} - Surface interpolation from vector point data by Inverse Distance Squared Weighting.

* {{cmd|v.surf.bspline}} - Surface interpolation from vector point data by bicubic or bilineal interpolation with Tykhonov regularization.

* {{cmd|r.fillnulls}} - Fills no-data areas in raster maps using v.surf.rst splines interpolation.

* {{AddonCmd|r.surf.nnbathy}} - Natural Neighbor interpolation using the 'nn' addon.

== Swath Bathymetry Tools ==

''see also the [[Marine_Science#Multibeam_sonar_processing]] wiki page''

* The [http://david.p.finlayson.googlepages.com/swathwidth v.swathwidth] module by David Finlayson for planning surveys. (development page)

* An example of [http://bambi.otago.ac.nz/hamish/grass/gdal/sidescan_warp.html post-processing scanned paper sidescan swaths] using thin plate spline warping with [http://www.gdal.org/ GDAL's] "<tt>gdalwarp -tps</tt>" function. (debugging page)

* [[MB-System|GRASS integration]] with [http://www.ldeo.columbia.edu/res/pi/MB-System/ MB-System] (GPL) software for processing Multibeam and Sidescan Sonar data. GRASS + [[MB-System|MBsys]] + [[GMT]] make a nice scriptable trio.

== LIDAR Tools ==

* {{cmd|r.terraflow}} - computation of flow direction, flow accumulation and other basic topographic terrain indices from massive raster digital elevation models (DEM). From the Duke University [http://terrain.cs.duke.edu/ STREAM] project.

* [http://mpa.itc.it/markus/grass61/demos/rlake/ Flood simulation] using {{cmd|r.lake}}. Includes fancy [[NVIZ]] visualization of Trento, Italy, by Markus Neteler.

* [http://www.cs.unc.edu/~isenburg/software/ LAStools] are a set of simple command line tools for converting to/from ASCII, viewing, comparing, and compressing LIDAR data. ''While free to use source code is available for older verions, newer versions are not open source, only work on MS Windows, and are no longer free for commercial or government use.''

* [http://www.liblas.org libLAS] ASPRS LiDAR data translation tools

* See also [[LIDAR#Analysis|LIDAR Analysis]]

== Micro-tutorial for LAS data import ==

''The following scripts are given for UNIX Bourne Shell; MS-Windows users should use the Msys terminal to use them.''

=== Preparation ===

==== Conversion of text files to LAS ====

[http://www.liblas.org/ libLAS] supports the following column types:
x - x coordinate
y - y coordinate
z - z coordinate
a - scan angle
i - intensity
n - number of returns for given pulse (1..n)
r - number of this return (1..r)
c - classification
u - user data (but only 1 byte)
p - point source ID
e - edge of flight line
d - direction of scan flag
t - GPS time
s - skip column

Sample text data such as:
returntime,pulse,east,north,height,intensity,stripe
549778.907200,1,673999.940,5099680.080,507.425,20.0,45105
...

can be converted to LAS format like this:
returntime - t
pulse - r
east - x
north - y
height - z
intensity - i
stripe - s

First parse (sanity check):
txt2las -parse trxyzis data.asc

Then convert:
txt2las -parse trxyzis -i data.asc -o data.las

While you may not need to do this conversion for GRASS import, the resulting files are way smaller than the uncompressed text files; additionally, they are in a defined format.

=== LAS Import ===

* Use the [http://www.liblas.org libLAS] utilities to import LAS data into GRASS.
* Data stored in text files can generally be imported directly into GRASS.

* The data used in the rest of this micro-tutorial can be found at [http://www.appliedimagery.com/downloads/sampledata/Serpent%20Mound%20Model%20LAS%20Data.las appliedimagery.com].

==== Import LAS as raster DEM ====

Check bounds and SRS:
$ lasinfo "Serpent_Mound_Model_LAS_Data.las"

[...]
Min X Y Z 289020.900000 4320942.610000 166.780000
Max X Y Z 290106.020000 4323641.570000 215.480000
Spatial Reference +proj=utm +zone=17 +ellps=WGS84 +units=m

After creating a suitable UTM zone 17 location (EPSG:32617)
set the region according to the information from lasinfo at 1m resolution, rounding grid outwards to align to whole meters:
GRASS> {{cmd|g.region}} n=4323641.57 s=4320942.61 w=289020.90 e=290106.02 res=1 -ap

Finally, import with {{cmd|r.in.xyz}} with data piped directly from the <tt>las2txt</tt> program and set a nice equalized color table:
BASEMAP="Serpent_Mound_Model_LAS"

las2txt --stdout --delimiter ' ' "${BASEMAP}_Data.las" | \
r.in.xyz in=- out=${BASEMAP}_Data fs=space method=mean

{{cmd|r.colors}} ${BASEMAP}_Data color=bcyr -e

The above example uses the default z-elevation level as the 3rd term, but by using the <tt>las2txt --parse</tt> command other fields (such as intensity) can be imported instead via "<tt>--parse xyi</tt>". Unfortunately there seem to be a number of versions of las2txt and each are called slightly differently. You might have to experiment a little to get the right incantation.

==== Import LAS as vector points in GRASS 6 ====

Region setting (establishing the grid) is not needed for vector features so we can go directly to the import step. To deal with millions of input points {{cmd|v.in.ascii}} should be run with the options to skip creation of an attribute database and building topology as these can consume large amounts of memory. Note that vector maps without topology built are somewhat limited in their ability to be processed. Most LIDAR specific modules have been adapted to not require
topology. Even so, after initial cleaning steps it is often more efficient to work with huge datasets in GRASS as raster data.

las2txt --stdout "${BASEMAP}_Data.las" | \
v.in.ascii -tbz z=3 out="${BASEMAP}_pts" fs=space

If topology was built, you can use {{cmd|d.vect}}'s -z flag to colorize by elevation value. Without topology you can still colorize, but you need to use color rules based on absolute elevations, not percentage of scale.

# display colorized points for data with built topology
d.vect map=lidar_pts size=1 -z zcolor=elevation

* After import as points you can then use the v.lidar tools to clean the data: {{cmd|v.lidar.correction}}, {{cmd|v.lidar.edgedetection}}, {{cmd|v.lidar.growing}}, and {{cmd|v.outlier}}.

* Vector points can be interpolated into raster DEMs with a number of modules, including {{cmd|v.surf.rst}}, {{cmd|v.surf.bspline}}, and {{cmd|v.surf.idw}}.

==== Import LAS in GRASS 7 ====

As vector points
* GRASS 7 offers the {{cmd|v.in.lidar|version=70}} command

As raster: map:
* {{cmd|r.in.lidar|version=70}} command

=== Clean imported raster DEM ===

(fill holes)

<source lang="bash">
# convert to vector points
r.to.vect -z feature=point in=${BASEMAP}_Data out=${BASEMAP}_pt

# interpolate using a regularized spline fit
# this is very slow, but produces very high quality output
v.surf.rst layer=0 in=${BASEMAP}_pt elev=${BASEMAP}.rst

# create 5m buffer area around original data points
r.buffer in=${BASEMAP}_Data out=${BASEMAP}.5m_buff dist=5

# crop interpolated DEM to only include areas nearby actual data
r.mapcalc "${BASEMAP}.filled = \
if( isnull(${BASEMAP}.5m_buff), null(), ${BASEMAP}.rst)"

# set colors to something nice
r.colors ${BASEMAP}.filled color=bcyr -e
</source>

Depending on your needs, {{cmd|r.fillnulls}}, {{cmd|v.surf.bspline}}, {{cmd|v.surf.idw}}, {{cmd|r.surf.idw}}, {{cmd|r.surf.idw2}}, or [[GRASS_AddOns#r.surf.nnbathy|r.surf.nnbathy]] may be faster than the {{cmd|v.surf.rst}} method.

=== Visualize raster DEM in 3D ===

nviz ${BASEMAP}.filled

* Set z-exag to 2.0
* In Visualize → Raster Surfaces set the fine (final) resolution to 1, and coarse (preview) resolution to 5.
* Set the height to 500.0, the perspective to 15.0, and drag the view-puck to the North-West and reasonably zoomed in.
: You should now be able to see the serpent:

[[Image:LAS_serpent_nviz.jpg|thumb|center|400px|The Great Serpent Mound, Adams County, Ohio, USA]]

It is possible to show vector points in 3D, but millions of them may make the program run slow. Topology is required ({{cmd|v.build}}). Tick the "3D" box in the Visualize → Vector points dialog.

=== LAS Export ===

==== Export to LAS ====

This is the reverse of the import step, but using {{cmd|v.out.ascii}} or {{cmd|r.out.xyz}} with ''txt2las''.
Because the v.out.ascii module exports category number which we are not interested in, we cut it away with the UNIX ''cut'' utility.

v.out.ascii ${BASEMAP}_pts fs=space | cut -f1-3 -d' ' \
> ${BASEMAP}_export.txt

txt2las --parse xyz -i ${BASEMAP}_export.txt

== Micro-tutorial for LIDAR data analysis ==

=== Simple analysis of single return data ===

Data source: North Carolina sample data set (Lidar data from 2001, near Raleigh, North Carolina). Download from
http://www.grassbook.org/ncexternal/
-> File: BE3720079200WC20020829m.txt 3.6M (lidar bare earth points [spm])

Scan input file for spatial extent. The -g flag shows the result in a convenient copy-paste format for {{cmd|g.region}}:
r.in.xyz BE3720079200WC20020829m.txt out=dummy -s -g

We use this output to set region, predefine 2m raster cells, and polish the odd coordinates with -a:
g.region n=222504.439000 s=219456.442000 e=640081.274000 w=637033.274000 res=2 -a -p

==== QUESTION 1: Are these Lidar data sufficiently dense? ====

We compute a raster map representing number of points per cell
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binn2m method=n

Look at the resulting raster map:
d.mon x0
d.font Vera
d.rast.leg lid_792_binn2m

Report point distribution in percent:
r.report lid_792_binn2m unit=p
r.univar lid_792_binn2m
# (sometimes do `r.null setnull=0` first)

Reduce the resolution to 6m to get at least one point per cell:
g.region res=6 -a -p
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binn6m method=n
d.rast.leg lid_792_binn6m
# ... a few holes remain but that's probably acceptable.

Compute raster maps representing mean elevation for each cell:
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binmean6m \
meth=mean
d.rast.leg lid_792_binmean6m

Compute range and variation:
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binrange6m \
meth=range
d.rast.leg lid_792_binrange6m
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binvar6m \
meth=coeff_var
d.rast.leg lid_792_binvar6m

Overlay other GIS maps to map of mean elevation:
d.rast.leg lid_792_binmean6m
d.vect streets_wake
d.vect lakes type=boundary
d.vect streams

Now we continue to work in a zoomed spatial subset of the area.

We import only points in the rural area without building topology and using z-coordinate for elevation:
g.region rural_1m -p
v.in.ascii -ztbr BE3720079200WC20020829m.txt \
out=elev_lidrural_bepts z=3

Clear monitor show black-white orthophoto:
d.erase -f
d.rast ortho_2001_t792_1m

We now use already prepared Lidar vector point maps:
* elev_lid792_bepts: Rural area (in tile 792), bare earth lidar point cloud
* elev_lidrural_mrpts: Rural area multiple return lidar point cloud

Look at ground data:
d.vect elev_lidrural_bepts siz=2 col=red

Look at "surface" data:
d.vect elev_lidrural_mrpts siz=1 col=green

Visualize 3D Lidar multi-return points:
nviz elev_lid792_1m point=elev_lidrural_mrpts
# Visualize -> Vector Points -> 3D points
# -> Icon size 2.25
# --> GRASS book p. 253, fig. 3.15 (see also screenshot [http://www.grassbook.org/about_menu3rd.php here])

==== DEM/DSM separation the simple way by selection of Lidar returns ====

Find out where we have multiple returns:
d.rast ortho_2001_t792_1m
d.vect elev_lidrural_mrpts where="return=1" col=red siz=2
d.vect elev_lidrural_mrpts where="return=2" col=green siz=3
d.vect elev_lidrural_mrpts where="return=3" col=blue
d.vect elev_lidrural_mrpts where="return=4" col=yellow

DTM: extract last return(s):
v.extract elev_lidrural_mrpts out=elev_lidrural_mrpts_first where="Return < 2"
nviz elev_lid792_1m point=elev_lidrural_mrpts_first

Interpolate to map and look at it:
v.surf.rst elev_lidrural_mrpts_first layer=0 elev=elev_lidrural_mrpts_DTM
nviz elev_lidrural_mrpts_DTM col=ortho_2001_t792_1m

DSM: extract first return(s):
v.extract elev_lidrural_mrpts out=elev_lidrural_mrpts_last where="Return > 2"
nviz elev_lid792_1m point=elev_lidrural_mrpts_last

Interpolate to map and look at it:
v.surf.rst elev_lidrural_mrpts_first layer=0 elev=elev_lidrural_mrpts_DSM
nviz elev_lidrural_mrpts_DSM col=ortho_2001_t792_1m

==== DEM/DSM separation the more complex way ====

''TODO: verify order of first and last returns in below text''

General procedure:
* Lidar point clouds (first and last return) are imported with {{cmd|v.in.ascii}} (-b flag to not build the topology).
* Outlier detection is done with {{cmd|v.outlier}} on both first and last return data (NB currently a selection of </=4 for soe/son in {{cmd|v.outlier}} results in an error message).
* Then, with {{cmd|v.lidar.edgedetection}}, edges are detected from last return data.
* The building are generated by {{cmd|v.lidar.growing}} from detected edges.
* The resulting data are post-processed with {{cmd|v.lidar.correction}}.
* Finally, the DTM and DSM are generated with {{cmd|v.surf.bspline}} (DTM: uses the 'v.lidar.correction' output; DSM: uses last return output from outlier detection).
* NB for {{cmd|v.outlier}}, {{cmd|v.lidar.edgedetection}} and {{cmd|v.surf.bspline}}, one spline steps equates to 1m. It is recommended as a starting point that the choice of spline step is roughly 3 or 4 times the planimetric resolution (potential grid resolution) of your data. Experiment from there to obtain better results.

export GRASS_OVERWRITE=1
v.extract elev_lidrural_mrpts out=elev_lidfirst_pts \
where="return = 1"
v.extract elev_lidrural_mrpts out=elev_lidlast_pts \
where="return >= 2"
d.vect elev_lidfirst_pts col=red
d.vect elev_lidlast_pts col=green

Outlier detection and separation into two maps
# 1st return
v.outlier elev_lidfirst_pts output=elev_lidfirst_clean \
outlier=elev_lidfirst_outl
d.erase
d.vect elev_lidfirst_clean siz=2
d.vect elev_lidfirst_outl col=red

2nd return
v.outlier elev_lidlast_pts output=elev_lidlast_clean \
outlier=elev_lidlast_outl
d.erase
d.vect elev_lidlast_clean siz=2
d.vect elev_lidlast_outl col=red
# -> no outliers visible

Run an edge detection on cleaned last return:
v.lidar.edgedetection elev_lidlast_clean \
out=elev_lidlast_edges

Buildings/vegetation are generated from detected edges (bug: you may need to specify the mapset):
v.lidar.growing elev_lidlast_edges@lidar out=elev_lidlast_grow \
first=elev_lidfirst_clean

Compare:
d.vect elev_lidlast_pts col=blue
d.vect elev_lidlast_grow col=green

Correction (this is applied twice):
v.lidar.correction elev_lidlast_grow out=elev_lidlast_corr1 \
terrain=elev_lidlast_terr1
v.lidar.correction elev_lidlast_corr1 out=elev_lid_dsm \
terrain=elev_lid_dtm

DEM and DSM are generated:
# Estimation of lambda_i parameter with cross validation (watch for RMS!)
# and note use of bicubic for DSM and bilinear for DTM here and below
v.surf.bspline -c elev_lid_dsm sie=100 sin=100 method=bicubic
v.surf.bspline -c elev_lid_dtm sie=100 sin=100 method=bilinear

# From the cross-validation, we select lambda with minimal RMS error:
# generate raster surfaces at 1m resolution
v.surf.bspline elev_lid_dsm raster=lidar_dsm lambda=0.1 method=bicubic
v.surf.bspline elev_lid_dtm raster=lidar_dtm lambda=0.0001 method=bilinear

d.rast lidar_dsm
d.rast lidar_dtm

nviz lidar_dsm,lidar_dtm \
col=ortho_2001_t792_1m,ortho_2001_t792_1m

...with the position slider you can visually separate DSM and DEM, increase z slider (Visualize -> Raster Surface -> Position).

=== Reclassification ===

As vector points
* {{cmd|v.reclass|version=70}} command

As raster map:
* {{cmd|r.reclass|version=70}} command

== Sample LIDAR data ==

=== Widely used in GRASS tutorials ===

* [http://www.grassbook.org/data_menu2nd.php Jockey's Ridge, NC, LIDAR dataset]
* [http://www.grassbook.org/data_menu3rd.php North Carolina OSGeo Edu data set] (includes multi-return LIDAR data)

=== Other ===

* United States Antarctic Resource Center: LIDAR High-resolution DEM Final DATA Downloads http://usarc.usgs.gov/lidar_dload.shtml

* LIDAR ALSM Research, Arizona State University Ative Tectonics, Research Group http://lidar.asu.edu/research.html and http://www.geongrid.org/science/lidar.html

* USGS Center for LIDAR Information Coordination and Knowledge (aka CLICK) - USGS LiDAR point cloud distribution site http://lidar.cr.usgs.gov

* Washington State Geospatial Data Archive, Mount Saint Helens - Lidar Data https://wagda.lib.washington.edu/data/type/elevation/lidar/st_helens/

* Puget Sound Lidar Consortium, public-domain high-resolution topography for western Washington http://pugetsoundlidar.ess.washington.edu/index.htm

* NOAA Topographic Change Mapping LIDAR Data Retrieval Tool (LDART) NOAA Coastal Services Center http://maps.csc.noaa.gov/TCM/

* Landmap, LIDAR Data from the Environment Agency http://www.landmap.ac.uk/lidar/lidar.html

* Northern California LIDAR data http://quake.usgs.gov/research/geology/lidar/ and http://core2.gsfc.nasa.gov/lidar/terrapoint/

* IDAHO GEOSPATIAL , Bare Earth LIDAR DEM Download - UTM http://inside.uidaho.edu/geodata/LiDAR/LiDARBareEarthDEM_DownloadUTM.htm

* EarthScope Spatial Data Explorer - A java application for querying, browsing, and acquiring data from the EarthScope Spatial Data Repository. Currently includes a number of LiDAR datasets. http://www.earthscope.org/data/lidar.php

* LIDAR Galley https://peoiewswebinfo.monmouth.army.mil/JPSD/LIDAR_Gallery.htm

* South Tyrol - Download of DTMs (Homepage in German or Italian) http://www.provinz.bz.it/raumordnung/grundkarten/utm/default_d.htm

* libLAS's sample file collection
:http://liblas.org/samples/

* NASA's Laser Vegetation Imaging Sensor (a.k.a. the Land, Vegetation, and Ice Sensor) or "LVIS"
:https://lvis.gsfc.nasa.gov

== Links ==

* [[Contour lines to DEM]] interpolation module trials
* [http://liblas.org/ libLAS] - LAS 1.0/1.1 ASPRS LiDAR data translation toolset
* [http://code.google.com/p/fullanalyze/ Fullanalyze] software based on MATIS

;Breaklines
* Not very well developed in GRASS so far, but we'd like to change that
* {{AddonCmd|v.surf.icw}} (only suitable for ~ 200 input points)
* [http://surfit.sourceforge.net/ SurfIt] (GPL, Tck/Tk)
* <strike>[http://surgeweb.sweb.cz/surgemain.htm SurGe] (Trial/shareware) </strike>
* [http://grasswiki.osgeo.org/wiki/TIN_with_breaklines v.triangle] add-on module for construction TIN with breaklines.

== Related publications ==

* Brovelli, M.A., Lucca, S., 2011. Filtering LiDAR with GRASS: overview of the method and comparisons with Terrascan. Italian Journal of Remote Sensing 93-105. ([http://www.aitjournal.com/articleView.aspx?ID=209 PDF])
* Brovelli, M.A., Cannata, M. & Longoni, U.M., 2004. LIDAR data filtering and DTM interpolation within GRASS. Transactions in GIS, 8(2), pp.155-174. [http://onlinelibrary.wiley.com/doi/10.1111/j.1467-9671.2004.00173.x/pdf PDF]
* Cebecauer, T., Hofierka, J. & Suri, M., 2002. Processing digital terrain models by regularized spline with tension: tuning interpolation parameters for different input datasets. In Proc. of the Open Source Free Software GIS -- GRASS users conference 2002, Trento, Italy, 11-13 September 2002. [http://www.ing.unitn.it/~grass/proceedings/proceedings/pdfs/Cebecauer_Tomas.pdf PDF]
* Mitasova, Helena et al., 2009. Raster-based analysis of coastal terrain dynamics from multitemporal Lidar data. Journal of Coastal Research, 25(2), pp.507-514.
* Mitasova, H, Mitas, L. & Harmon, R., 2005. Simultaneous spline approximation and topographic analysis for lidar elevation data in open-source GIS. Geoscience and Remote Sensing Letters, IEEE, 2(4), pp.379, 375. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.69.2934&rep=rep1&type=pdf PDF]
* Mitasova, H. et al., 2003. Spatio-temporal analysis of beach morphology using LIDAR, RTK-GPS and Open source GRASS GIS. In Proceedings Coastal Sediments. [http://skagit.meas.ncsu.edu/%7Ehelena/publwork/papers/pcoastsedp10.pdf PDF]

Search via [http://scholar.google.com/scholar?q=lidar+grass+gis Google Scholar]

== See also ==

* [http://knol.google.com/k/aerial-extraction-of-roof-surfaces-for-solar-analysis Aerial Extraction of Roof Surfaces for Solar Analysis]

[[Category:Documentation]]
[[Category: Interpolation]]
[[Category: Image processing]]
[[Category: Import]]
[[Category: Raster]]
[[Category: Vector]]

LIDAR

2013-02-24T22:43:57Z

⚠️Cmbarton: /* Import */

<h1> LIDAR and Multi-beam Swath bathymetry data </h1>

Point cloud data, as a type of representation of 3D surfaces, are usually produced by airborne or on-ground laser scanning, also known as Light Detection and Ranging (LiDAR). The data are often provided as sets of very dense (x, y, z) points or in a more complex, public file binary format called LAS that may include multiple returns as well as intensities. GRASS GIS supports basic and advanced lidar data processing and analysis.

== Modules ==

In this section various modules are introduced.

=== Import ===

* {{cmd|r.in.xyz}} - Create a raster map from an assemblage of many coordinates using univariate statistics. ([http://hamish.bowman.googlepages.com/grassfiles#xyz example])

* {{cmd|r.in.lidar}} - (GRASS 7 only; GRASS must be compiled with libLAS support) Create a raster map from a binary LAS format LiDAR file (*.las) using univariate statistics and filtering. r.in.lidar is based on r.in.xyz. In addition to the options of r.in.xyz, r.in.lidar provides some basic lidar point fileter options.

* {{cmd|v.in.ascii}} - Import data from an ASCII file to GRASS vector format.
: ''Due to memory overhead vector point imports will be limited to a few million data points unless topology and database creation is skipped with the '''-bt''' flags''. It may also be useful to clip the import file to only accept points falling within the current region by using the '''-r''' flag. See {{cmd|g.region}} for details on specifying the region bounds.

* {{cmd|v.in.lidar}} - (GRASS 7 only; GRASS must be compiled with libLAS support). Creates a vector points file from a binary LAS format LiDAR file (*.las or *.laz). r.in.lidar also can create a new location based on the LAS file, and can filter the input points by return and subregion.

=== Analysis ===

* {{cmd|v.outlier}} - Removes outliers from vector point data.

* {{cmd|v.lidar.edgedetection}} - Uses interpolation and edge detection to separate a vector points file of LiDAR data into 1) a vector file of points associated with the ground surface and useful for interpolating a raster terrain (DEM) map, 2) a vector file of points pertaining to human-contructed objects, and 3) a vector file of other points that could pertain to vegetation or other features.

* {{cmd|v.lidar.growing}} - Building contour determination and Region Growing algorithm for determining the building inside.

* {{cmd|v.lidar.correction}} - Correction of the v.lidar.growing output. It is the last of the three algorithms for LIDAR filtering.

''References:''

* Detailed description: [http://www.foss4g2006.org/getFile.py/access?contribId=48&sessionId=59&resId=7&materialId=slides&confId=1 here] (FOSS4G 2006)
* Summarised version: [http://geomatica.como.polimi.it/corsi/remote_sensing/LiDAR_filtering_with_GRASS-lab4.pdf here] (2010)
* Calibration of the filtering parameters (around 20 parameters) by integrating the USGS UCODE and GRASS, see [http://www.isprs.org/proceedings/XXXVIII/1_4_7-W5/paper/Brovelli-126.pdf here]

=== Surface generation ===

* {{cmd|v.surf.rst}} - Spatial approximation and topographic analysis using regularized spline with tension.

* {{cmd|v.surf.idw}} - Surface interpolation from vector point data by Inverse Distance Squared Weighting.

* {{cmd|v.surf.bspline}} - Surface interpolation from vector point data by bicubic or bilineal interpolation with Tykhonov regularization.

* {{cmd|r.fillnulls}} - Fills no-data areas in raster maps using v.surf.rst splines interpolation.

* {{AddonCmd|r.surf.nnbathy}} - Natural Neighbor interpolation using the 'nn' addon.

== Swath Bathymetry Tools ==

''see also the [[Marine_Science#Multibeam_sonar_processing]] wiki page''

* The [http://david.p.finlayson.googlepages.com/swathwidth v.swathwidth] module by David Finlayson for planning surveys. (development page)

* An example of [http://bambi.otago.ac.nz/hamish/grass/gdal/sidescan_warp.html post-processing scanned paper sidescan swaths] using thin plate spline warping with [http://www.gdal.org/ GDAL's] "<tt>gdalwarp -tps</tt>" function. (debugging page)

* [[MB-System|GRASS integration]] with [http://www.ldeo.columbia.edu/res/pi/MB-System/ MB-System] (GPL) software for processing Multibeam and Sidescan Sonar data. GRASS + [[MB-System|MBsys]] + [[GMT]] make a nice scriptable trio.

== LIDAR Tools ==

* {{cmd|r.terraflow}} - computation of flow direction, flow accumulation and other basic topographic terrain indices from massive raster digital elevation models (DEM). From the Duke University [http://terrain.cs.duke.edu/ STREAM] project.

* [http://mpa.itc.it/markus/grass61/demos/rlake/ Flood simulation] using {{cmd|r.lake}}. Includes fancy [[NVIZ]] visualization of Trento, Italy, by Markus Neteler.

* [http://www.cs.unc.edu/~isenburg/software/ LAStools] are a set of simple command line tools for converting to/from ASCII, viewing, comparing, and compressing LIDAR data. ''While free to use source code is available for older verions, newer versions are not open source, only work on MS Windows, and are no longer free for commercial or government use.''

* [http://www.liblas.org libLAS] ASPRS LiDAR data translation tools

* See also [[LIDAR#Analysis|LIDAR Analysis]]

== Micro-tutorial for LAS data import ==

''The following scripts are given for UNIX Bourne Shell; MS-Windows users should use the Msys terminal to use them.''

=== Preparation ===

==== Conversion of text files to LAS ====

[http://www.liblas.org/ libLAS] supports the following column types:
x - x coordinate
y - y coordinate
z - z coordinate
a - scan angle
i - intensity
n - number of returns for given pulse (1..n)
r - number of this return (1..r)
c - classification
u - user data (but only 1 byte)
p - point source ID
e - edge of flight line
d - direction of scan flag
t - GPS time
s - skip column

Sample text data such as:
returntime,pulse,east,north,height,intensity,stripe
549778.907200,1,673999.940,5099680.080,507.425,20.0,45105
...

can be converted to LAS format like this:
returntime - t
pulse - r
east - x
north - y
height - z
intensity - i
stripe - s

First parse (sanity check):
txt2las -parse trxyzis data.asc

Then convert:
txt2las -parse trxyzis -i data.asc -o data.las

While you may not need to do this conversion for GRASS import, the resulting files are way smaller than the uncompressed text files; additionally, they are in a defined format.

=== LAS Import ===

* Use the [http://www.liblas.org libLAS] utilities to import LAS data into GRASS.
* Data stored in text files can generally be imported directly into GRASS.

* The data used in the rest of this micro-tutorial can be found at [http://www.appliedimagery.com/downloads/sampledata/Serpent%20Mound%20Model%20LAS%20Data.las appliedimagery.com].

==== Import LAS as raster DEM ====

Check bounds and SRS:
$ lasinfo "Serpent_Mound_Model_LAS_Data.las"

[...]
Min X Y Z 289020.900000 4320942.610000 166.780000
Max X Y Z 290106.020000 4323641.570000 215.480000
Spatial Reference +proj=utm +zone=17 +ellps=WGS84 +units=m

After creating a suitable UTM zone 17 location (EPSG:32617)
set the region according to the information from lasinfo at 1m resolution, rounding grid outwards to align to whole meters:
GRASS> {{cmd|g.region}} n=4323641.57 s=4320942.61 w=289020.90 e=290106.02 res=1 -ap

Finally, import with {{cmd|r.in.xyz}} with data piped directly from the <tt>las2txt</tt> program and set a nice equalized color table:
BASEMAP="Serpent_Mound_Model_LAS"

las2txt --stdout --delimiter ' ' "${BASEMAP}_Data.las" | \
r.in.xyz in=- out=${BASEMAP}_Data fs=space method=mean

{{cmd|r.colors}} ${BASEMAP}_Data color=bcyr -e

The above example uses the default z-elevation level as the 3rd term, but by using the <tt>las2txt --parse</tt> command other fields (such as intensity) can be imported instead via "<tt>--parse xyi</tt>". Unfortunately there seem to be a number of versions of las2txt and each are called slightly differently. You might have to experiment a little to get the right incantation.

==== Import LAS as vector points in GRASS 6 ====

Region setting (establishing the grid) is not needed for vector features so we can go directly to the import step. To deal with millions of input points {{cmd|v.in.ascii}} should be run with the options to skip creation of an attribute database and building topology as these can consume large amounts of memory. Note that vector maps without topology built are somewhat limited in their ability to be processed. Most LIDAR specific modules have been adapted to not require
topology. Even so, after initial cleaning steps it is often more efficient to work with huge datasets in GRASS as raster data.

las2txt --stdout "${BASEMAP}_Data.las" | \
v.in.ascii -tbz z=3 out="${BASEMAP}_pts" fs=space

If topology was built, you can use {{cmd|d.vect}}'s -z flag to colorize by elevation value. Without topology you can still colorize, but you need to use color rules based on absolute elevations, not percentage of scale.

# display colorized points for data with built topology
d.vect map=lidar_pts size=1 -z zcolor=elevation

* After import as points you can then use the v.lidar tools to clean the data: {{cmd|v.lidar.correction}}, {{cmd|v.lidar.edgedetection}}, {{cmd|v.lidar.growing}}, and {{cmd|v.outlier}}.

* Vector points can be interpolated into raster DEMs with a number of modules, including {{cmd|v.surf.rst}}, {{cmd|v.surf.bspline}}, and {{cmd|v.surf.idw}}.

==== Import LAS in GRASS 7 ====

As vector points
* GRASS 7 offers the {{cmd|v.in.lidar|version=70}} command

As raster: map:
* {{cmd|r.in.lidar|version=70}} command

=== Clean imported raster DEM ===

(fill holes)

<source lang="bash">
# convert to vector points
r.to.vect -z feature=point in=${BASEMAP}_Data out=${BASEMAP}_pt

# interpolate using a regularized spline fit
# this is very slow, but produces very high quality output
v.surf.rst layer=0 in=${BASEMAP}_pt elev=${BASEMAP}.rst

# create 5m buffer area around original data points
r.buffer in=${BASEMAP}_Data out=${BASEMAP}.5m_buff dist=5

# crop interpolated DEM to only include areas nearby actual data
r.mapcalc "${BASEMAP}.filled = \
if( isnull(${BASEMAP}.5m_buff), null(), ${BASEMAP}.rst)"

# set colors to something nice
r.colors ${BASEMAP}.filled color=bcyr -e
</source>

Depending on your needs, {{cmd|r.fillnulls}}, {{cmd|v.surf.bspline}}, {{cmd|v.surf.idw}}, {{cmd|r.surf.idw}}, {{cmd|r.surf.idw2}}, or [[GRASS_AddOns#r.surf.nnbathy|r.surf.nnbathy]] may be faster than the {{cmd|v.surf.rst}} method.

=== Visualize raster DEM in 3D ===

nviz ${BASEMAP}.filled

* Set z-exag to 2.0
* In Visualize → Raster Surfaces set the fine (final) resolution to 1, and coarse (preview) resolution to 5.
* Set the height to 500.0, the perspective to 15.0, and drag the view-puck to the North-West and reasonably zoomed in.
: You should now be able to see the serpent:

[[Image:LAS_serpent_nviz.jpg|thumb|center|400px|The Great Serpent Mound, Adams County, Ohio, USA]]

It is possible to show vector points in 3D, but millions of them may make the program run slow. Topology is required ({{cmd|v.build}}). Tick the "3D" box in the Visualize → Vector points dialog.

=== LAS Export ===

==== Export to LAS ====

This is the reverse of the import step, but using {{cmd|v.out.ascii}} or {{cmd|r.out.xyz}} with ''txt2las''.
Because the v.out.ascii module exports category number which we are not interested in, we cut it away with the UNIX ''cut'' utility.

v.out.ascii ${BASEMAP}_pts fs=space | cut -f1-3 -d' ' \
> ${BASEMAP}_export.txt

txt2las --parse xyz -i ${BASEMAP}_export.txt

== Micro-tutorial for LIDAR data analysis ==

=== Simple analysis of single return data ===

Data source: North Carolina sample data set (Lidar data from 2001, near Raleigh, North Carolina). Download from
http://www.grassbook.org/ncexternal/
-> File: BE3720079200WC20020829m.txt 3.6M (lidar bare earth points [spm])

Scan input file for spatial extent. The -g flag shows the result in a convenient copy-paste format for {{cmd|g.region}}:
r.in.xyz BE3720079200WC20020829m.txt out=dummy -s -g

We use this output to set region, predefine 2m raster cells, and polish the odd coordinates with -a:
g.region n=222504.439000 s=219456.442000 e=640081.274000 w=637033.274000 res=2 -a -p

==== QUESTION 1: Are these Lidar data sufficiently dense? ====

We compute a raster map representing number of points per cell
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binn2m method=n

Look at the resulting raster map:
d.mon x0
d.font Vera
d.rast.leg lid_792_binn2m

Report point distribution in percent:
r.report lid_792_binn2m unit=p
r.univar lid_792_binn2m
# (sometimes do `r.null setnull=0` first)

Reduce the resolution to 6m to get at least one point per cell:
g.region res=6 -a -p
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binn6m method=n
d.rast.leg lid_792_binn6m
# ... a few holes remain but that's probably acceptable.

Compute raster maps representing mean elevation for each cell:
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binmean6m \
meth=mean
d.rast.leg lid_792_binmean6m

Compute range and variation:
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binrange6m \
meth=range
d.rast.leg lid_792_binrange6m
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binvar6m \
meth=coeff_var
d.rast.leg lid_792_binvar6m

Overlay other GIS maps to map of mean elevation:
d.rast.leg lid_792_binmean6m
d.vect streets_wake
d.vect lakes type=boundary
d.vect streams

Now we continue to work in a zoomed spatial subset of the area.

We import only points in the rural area without building topology and using z-coordinate for elevation:
g.region rural_1m -p
v.in.ascii -ztbr BE3720079200WC20020829m.txt \
out=elev_lidrural_bepts z=3

Clear monitor show black-white orthophoto:
d.erase -f
d.rast ortho_2001_t792_1m

We now use already prepared Lidar vector point maps:
* elev_lid792_bepts: Rural area (in tile 792), bare earth lidar point cloud
* elev_lidrural_mrpts: Rural area multiple return lidar point cloud

Look at ground data:
d.vect elev_lidrural_bepts siz=2 col=red

Look at "surface" data:
d.vect elev_lidrural_mrpts siz=1 col=green

Visualize 3D Lidar multi-return points:
nviz elev_lid792_1m point=elev_lidrural_mrpts
# Visualize -> Vector Points -> 3D points
# -> Icon size 2.25
# --> GRASS book p. 253, fig. 3.15 (see also screenshot [http://www.grassbook.org/about_menu3rd.php here])

==== DEM/DSM separation the simple way by selection of Lidar returns ====

Find out where we have multiple returns:
d.rast ortho_2001_t792_1m
d.vect elev_lidrural_mrpts where="return=1" col=red siz=2
d.vect elev_lidrural_mrpts where="return=2" col=green siz=3
d.vect elev_lidrural_mrpts where="return=3" col=blue
d.vect elev_lidrural_mrpts where="return=4" col=yellow

DTM: extract last return(s):
v.extract elev_lidrural_mrpts out=elev_lidrural_mrpts_first where="Return < 2"
nviz elev_lid792_1m point=elev_lidrural_mrpts_first

Interpolate to map and look at it:
v.surf.rst elev_lidrural_mrpts_first layer=0 elev=elev_lidrural_mrpts_DTM
nviz elev_lidrural_mrpts_DTM col=ortho_2001_t792_1m

DSM: extract first return(s):
v.extract elev_lidrural_mrpts out=elev_lidrural_mrpts_last where="Return > 2"
nviz elev_lid792_1m point=elev_lidrural_mrpts_last

Interpolate to map and look at it:
v.surf.rst elev_lidrural_mrpts_first layer=0 elev=elev_lidrural_mrpts_DSM
nviz elev_lidrural_mrpts_DSM col=ortho_2001_t792_1m

==== DEM/DSM separation the more complex way ====

''TODO: verify order of first and last returns in below text''

General procedure:
* Lidar point clouds (first and last return) are imported with {{cmd|v.in.ascii}} (-b flag to not build the topology).
* Outlier detection is done with {{cmd|v.outlier}} on both first and last return data (NB currently a selection of </=4 for soe/son in {{cmd|v.outlier}} results in an error message).
* Then, with {{cmd|v.lidar.edgedetection}}, edges are detected from last return data.
* The building are generated by {{cmd|v.lidar.growing}} from detected edges.
* The resulting data are post-processed with {{cmd|v.lidar.correction}}.
* Finally, the DTM and DSM are generated with {{cmd|v.surf.bspline}} (DTM: uses the 'v.lidar.correction' output; DSM: uses last return output from outlier detection).
* NB for {{cmd|v.outlier}}, {{cmd|v.lidar.edgedetection}} and {{cmd|v.surf.bspline}}, one spline steps equates to 1m. It is recommended as a starting point that the choice of spline step is roughly 3 or 4 times the planimetric resolution (potential grid resolution) of your data. Experiment from there to obtain better results.

export GRASS_OVERWRITE=1
v.extract elev_lidrural_mrpts out=elev_lidfirst_pts \
where="return = 1"
v.extract elev_lidrural_mrpts out=elev_lidlast_pts \
where="return >= 2"
d.vect elev_lidfirst_pts col=red
d.vect elev_lidlast_pts col=green

Outlier detection and separation into two maps
# 1st return
v.outlier elev_lidfirst_pts output=elev_lidfirst_clean \
outlier=elev_lidfirst_outl
d.erase
d.vect elev_lidfirst_clean siz=2
d.vect elev_lidfirst_outl col=red

2nd return
v.outlier elev_lidlast_pts output=elev_lidlast_clean \
outlier=elev_lidlast_outl
d.erase
d.vect elev_lidlast_clean siz=2
d.vect elev_lidlast_outl col=red
# -> no outliers visible

Run an edge detection on cleaned last return:
v.lidar.edgedetection elev_lidlast_clean \
out=elev_lidlast_edges

Buildings/vegetation are generated from detected edges (bug: you may need to specify the mapset):
v.lidar.growing elev_lidlast_edges@lidar out=elev_lidlast_grow \
first=elev_lidfirst_clean

Compare:
d.vect elev_lidlast_pts col=blue
d.vect elev_lidlast_grow col=green

Correction (this is applied twice):
v.lidar.correction elev_lidlast_grow out=elev_lidlast_corr1 \
terrain=elev_lidlast_terr1
v.lidar.correction elev_lidlast_corr1 out=elev_lid_dsm \
terrain=elev_lid_dtm

DEM and DSM are generated:
# Estimation of lambda_i parameter with cross validation (watch for RMS!)
# and note use of bicubic for DSM and bilinear for DTM here and below
v.surf.bspline -c elev_lid_dsm sie=100 sin=100 method=bicubic
v.surf.bspline -c elev_lid_dtm sie=100 sin=100 method=bilinear

# From the cross-validation, we select lambda with minimal RMS error:
# generate raster surfaces at 1m resolution
v.surf.bspline elev_lid_dsm raster=lidar_dsm lambda=0.1 method=bicubic
v.surf.bspline elev_lid_dtm raster=lidar_dtm lambda=0.0001 method=bilinear

d.rast lidar_dsm
d.rast lidar_dtm

nviz lidar_dsm,lidar_dtm \
col=ortho_2001_t792_1m,ortho_2001_t792_1m

...with the position slider you can visually separate DSM and DEM, increase z slider (Visualize -> Raster Surface -> Position).

=== Reclassification ===

As vector points
* {{cmd|v.reclass|version=70}} command

As raster map:
* {{cmd|r.reclass|version=70}} command

== Sample LIDAR data ==

=== Widely used in GRASS tutorials ===

* [http://www.grassbook.org/data_menu2nd.php Jockey's Ridge, NC, LIDAR dataset]
* [http://www.grassbook.org/data_menu3rd.php North Carolina OSGeo Edu data set] (includes multi-return LIDAR data)

=== Other ===

* United States Antarctic Resource Center: LIDAR High-resolution DEM Final DATA Downloads http://usarc.usgs.gov/lidar_dload.shtml

* LIDAR ALSM Research, Arizona State University Ative Tectonics, Research Group http://lidar.asu.edu/research.html and http://www.geongrid.org/science/lidar.html

* USGS Center for LIDAR Information Coordination and Knowledge (aka CLICK) - USGS LiDAR point cloud distribution site http://lidar.cr.usgs.gov

* Washington State Geospatial Data Archive, Mount Saint Helens - Lidar Data https://wagda.lib.washington.edu/data/type/elevation/lidar/st_helens/

* Puget Sound Lidar Consortium, public-domain high-resolution topography for western Washington http://pugetsoundlidar.ess.washington.edu/index.htm

* NOAA Topographic Change Mapping LIDAR Data Retrieval Tool (LDART) NOAA Coastal Services Center http://maps.csc.noaa.gov/TCM/

* Landmap, LIDAR Data from the Environment Agency http://www.landmap.ac.uk/lidar/lidar.html

* Northern California LIDAR data http://quake.usgs.gov/research/geology/lidar/ and http://core2.gsfc.nasa.gov/lidar/terrapoint/

* IDAHO GEOSPATIAL , Bare Earth LIDAR DEM Download - UTM http://inside.uidaho.edu/geodata/LiDAR/LiDARBareEarthDEM_DownloadUTM.htm

* EarthScope Spatial Data Explorer - A java application for querying, browsing, and acquiring data from the EarthScope Spatial Data Repository. Currently includes a number of LiDAR datasets. http://www.earthscope.org/data/lidar.php

* LIDAR Galley https://peoiewswebinfo.monmouth.army.mil/JPSD/LIDAR_Gallery.htm

* South Tyrol - Download of DTMs (Homepage in German or Italian) http://www.provinz.bz.it/raumordnung/grundkarten/utm/default_d.htm

* libLAS's sample file collection
:http://liblas.org/samples/

* NASA's Laser Vegetation Imaging Sensor (a.k.a. the Land, Vegetation, and Ice Sensor) or "LVIS"
:https://lvis.gsfc.nasa.gov

== Links ==

* [[Contour lines to DEM]] interpolation module trials
* [http://liblas.org/ libLAS] - LAS 1.0/1.1 ASPRS LiDAR data translation toolset
* [http://code.google.com/p/fullanalyze/ Fullanalyze] software based on MATIS

;Breaklines
* Not very well developed in GRASS so far, but we'd like to change that
* {{AddonCmd|v.surf.icw}} (only suitable for ~ 200 input points)
* [http://surfit.sourceforge.net/ SurfIt] (GPL, Tck/Tk)
* <strike>[http://surgeweb.sweb.cz/surgemain.htm SurGe] (Trial/shareware) </strike>
* [http://grasswiki.osgeo.org/wiki/TIN_with_breaklines v.triangle] add-on module for construction TIN with breaklines.

== Related publications ==

* Brovelli, M.A., Lucca, S., 2011. Filtering LiDAR with GRASS: overview of the method and comparisons with Terrascan. Italian Journal of Remote Sensing 93-105. ([http://www.aitjournal.com/articleView.aspx?ID=209 PDF])
* Brovelli, M.A., Cannata, M. & Longoni, U.M., 2004. LIDAR data filtering and DTM interpolation within GRASS. Transactions in GIS, 8(2), pp.155-174. [http://onlinelibrary.wiley.com/doi/10.1111/j.1467-9671.2004.00173.x/pdf PDF]
* Cebecauer, T., Hofierka, J. & Suri, M., 2002. Processing digital terrain models by regularized spline with tension: tuning interpolation parameters for different input datasets. In Proc. of the Open Source Free Software GIS -- GRASS users conference 2002, Trento, Italy, 11-13 September 2002. [http://www.ing.unitn.it/~grass/proceedings/proceedings/pdfs/Cebecauer_Tomas.pdf PDF]
* Mitasova, Helena et al., 2009. Raster-based analysis of coastal terrain dynamics from multitemporal Lidar data. Journal of Coastal Research, 25(2), pp.507-514.
* Mitasova, H, Mitas, L. & Harmon, R., 2005. Simultaneous spline approximation and topographic analysis for lidar elevation data in open-source GIS. Geoscience and Remote Sensing Letters, IEEE, 2(4), pp.379, 375. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.69.2934&rep=rep1&type=pdf PDF]
* Mitasova, H. et al., 2003. Spatio-temporal analysis of beach morphology using LIDAR, RTK-GPS and Open source GRASS GIS. In Proceedings Coastal Sediments. [http://skagit.meas.ncsu.edu/%7Ehelena/publwork/papers/pcoastsedp10.pdf PDF]

Search via [http://scholar.google.com/scholar?q=lidar+grass+gis Google Scholar]

== See also ==

* [http://knol.google.com/k/aerial-extraction-of-roof-surfaces-for-solar-analysis Aerial Extraction of Roof Surfaces for Solar Analysis]

[[Category:Documentation]]
[[Category: Interpolation]]
[[Category: Image processing]]
[[Category: Import]]
[[Category: Raster]]
[[Category: Vector]]

LIDAR

2013-02-24T22:25:21Z

⚠️Cmbarton: /* Analysis */

<h1> LIDAR and Multi-beam Swath bathymetry data </h1>

Point cloud data, as a type of representation of 3D surfaces, are usually produced by airborne or on-ground laser scanning, also known as Light Detection and Ranging (LiDAR). The data are often provided as sets of very dense (x, y, z) points or in a more complex, public file binary format called LAS that may include multiple returns as well as intensities. GRASS GIS supports basic and advanced lidar data processing and analysis.

== Modules ==

In this section various modules are introduced.

=== Import ===

* {{cmd|r.in.xyz}} - Create a raster map from an assemblage of many coordinates using univariate statistics. ([http://hamish.bowman.googlepages.com/grassfiles#xyz example])

* {{cmd|r.in.lidar}} - (GRASS 7 only) Create a raster map from a LAS format LiDAR file using univariate statistics and filtering. r.in.lidar is based on r.in.xyz. It can directly read a binary *.las file when GRASS is compiled with libLAS support. In addition to the options of r.in.xyz, r.in.lidar provides some basic lidar point fileter options.

* {{cmd|v.in.ascii}} - Import data from an ASCII file to GRASS vector format.
: ''Due to memory overhead vector point imports will be limited to a few million data points unless topology and database creation is skipped with the '''-bt''' flags''. It may also be useful to clip the import file to only accept points falling within the current region by using the '''-r''' flag. See {{cmd|g.region}} for details on specifying the region bounds.

* {{cmd|v.in.lidar}} - (GRASS 7 only). Creates a vector points file from a binary LAS format LiDAR file (*.las or *.laz). r.in.lidar also can create a new location based on the LAS file, and can filter the input points by return and subregion.

=== Analysis ===

* {{cmd|v.outlier}} - Removes outliers from vector point data.

* {{cmd|v.lidar.edgedetection}} - Uses interpolation and edge detection to separate a vector points file of LiDAR data into 1) a vector file of points associated with the ground surface and useful for interpolating a raster terrain (DEM) map, 2) a vector file of points pertaining to human-contructed objects, and 3) a vector file of other points that could pertain to vegetation or other features.

* {{cmd|v.lidar.growing}} - Building contour determination and Region Growing algorithm for determining the building inside.

* {{cmd|v.lidar.correction}} - Correction of the v.lidar.growing output. It is the last of the three algorithms for LIDAR filtering.

''References:''

* Detailed description: [http://www.foss4g2006.org/getFile.py/access?contribId=48&sessionId=59&resId=7&materialId=slides&confId=1 here] (FOSS4G 2006)
* Summarised version: [http://geomatica.como.polimi.it/corsi/remote_sensing/LiDAR_filtering_with_GRASS-lab4.pdf here] (2010)
* Calibration of the filtering parameters (around 20 parameters) by integrating the USGS UCODE and GRASS, see [http://www.isprs.org/proceedings/XXXVIII/1_4_7-W5/paper/Brovelli-126.pdf here]

=== Surface generation ===

* {{cmd|v.surf.rst}} - Spatial approximation and topographic analysis using regularized spline with tension.

* {{cmd|v.surf.idw}} - Surface interpolation from vector point data by Inverse Distance Squared Weighting.

* {{cmd|v.surf.bspline}} - Surface interpolation from vector point data by bicubic or bilineal interpolation with Tykhonov regularization.

* {{cmd|r.fillnulls}} - Fills no-data areas in raster maps using v.surf.rst splines interpolation.

* {{AddonCmd|r.surf.nnbathy}} - Natural Neighbor interpolation using the 'nn' addon.

== Swath Bathymetry Tools ==

''see also the [[Marine_Science#Multibeam_sonar_processing]] wiki page''

* The [http://david.p.finlayson.googlepages.com/swathwidth v.swathwidth] module by David Finlayson for planning surveys. (development page)

* An example of [http://bambi.otago.ac.nz/hamish/grass/gdal/sidescan_warp.html post-processing scanned paper sidescan swaths] using thin plate spline warping with [http://www.gdal.org/ GDAL's] "<tt>gdalwarp -tps</tt>" function. (debugging page)

* [[MB-System|GRASS integration]] with [http://www.ldeo.columbia.edu/res/pi/MB-System/ MB-System] (GPL) software for processing Multibeam and Sidescan Sonar data. GRASS + [[MB-System|MBsys]] + [[GMT]] make a nice scriptable trio.

== LIDAR Tools ==

* {{cmd|r.terraflow}} - computation of flow direction, flow accumulation and other basic topographic terrain indices from massive raster digital elevation models (DEM). From the Duke University [http://terrain.cs.duke.edu/ STREAM] project.

* [http://mpa.itc.it/markus/grass61/demos/rlake/ Flood simulation] using {{cmd|r.lake}}. Includes fancy [[NVIZ]] visualization of Trento, Italy, by Markus Neteler.

* [http://www.cs.unc.edu/~isenburg/software/ LAStools] are a set of simple command line tools for converting to/from ASCII, viewing, comparing, and compressing LIDAR data. ''While free to use source code is available for older verions, newer versions are not open source, only work on MS Windows, and are no longer free for commercial or government use.''

* [http://www.liblas.org libLAS] ASPRS LiDAR data translation tools

* See also [[LIDAR#Analysis|LIDAR Analysis]]

== Micro-tutorial for LAS data import ==

''The following scripts are given for UNIX Bourne Shell; MS-Windows users should use the Msys terminal to use them.''

=== Preparation ===

==== Conversion of text files to LAS ====

[http://www.liblas.org/ libLAS] supports the following column types:
x - x coordinate
y - y coordinate
z - z coordinate
a - scan angle
i - intensity
n - number of returns for given pulse (1..n)
r - number of this return (1..r)
c - classification
u - user data (but only 1 byte)
p - point source ID
e - edge of flight line
d - direction of scan flag
t - GPS time
s - skip column

Sample text data such as:
returntime,pulse,east,north,height,intensity,stripe
549778.907200,1,673999.940,5099680.080,507.425,20.0,45105
...

can be converted to LAS format like this:
returntime - t
pulse - r
east - x
north - y
height - z
intensity - i
stripe - s

First parse (sanity check):
txt2las -parse trxyzis data.asc

Then convert:
txt2las -parse trxyzis -i data.asc -o data.las

While you may not need to do this conversion for GRASS import, the resulting files are way smaller than the uncompressed text files; additionally, they are in a defined format.

=== LAS Import ===

* Use the [http://www.liblas.org libLAS] utilities to import LAS data into GRASS.
* Data stored in text files can generally be imported directly into GRASS.

* The data used in the rest of this micro-tutorial can be found at [http://www.appliedimagery.com/downloads/sampledata/Serpent%20Mound%20Model%20LAS%20Data.las appliedimagery.com].

==== Import LAS as raster DEM ====

Check bounds and SRS:
$ lasinfo "Serpent_Mound_Model_LAS_Data.las"

[...]
Min X Y Z 289020.900000 4320942.610000 166.780000
Max X Y Z 290106.020000 4323641.570000 215.480000
Spatial Reference +proj=utm +zone=17 +ellps=WGS84 +units=m

After creating a suitable UTM zone 17 location (EPSG:32617)
set the region according to the information from lasinfo at 1m resolution, rounding grid outwards to align to whole meters:
GRASS> {{cmd|g.region}} n=4323641.57 s=4320942.61 w=289020.90 e=290106.02 res=1 -ap

Finally, import with {{cmd|r.in.xyz}} with data piped directly from the <tt>las2txt</tt> program and set a nice equalized color table:
BASEMAP="Serpent_Mound_Model_LAS"

las2txt --stdout --delimiter ' ' "${BASEMAP}_Data.las" | \
r.in.xyz in=- out=${BASEMAP}_Data fs=space method=mean

{{cmd|r.colors}} ${BASEMAP}_Data color=bcyr -e

The above example uses the default z-elevation level as the 3rd term, but by using the <tt>las2txt --parse</tt> command other fields (such as intensity) can be imported instead via "<tt>--parse xyi</tt>". Unfortunately there seem to be a number of versions of las2txt and each are called slightly differently. You might have to experiment a little to get the right incantation.

==== Import LAS as vector points in GRASS 6 ====

Region setting (establishing the grid) is not needed for vector features so we can go directly to the import step. To deal with millions of input points {{cmd|v.in.ascii}} should be run with the options to skip creation of an attribute database and building topology as these can consume large amounts of memory. Note that vector maps without topology built are somewhat limited in their ability to be processed. Most LIDAR specific modules have been adapted to not require
topology. Even so, after initial cleaning steps it is often more efficient to work with huge datasets in GRASS as raster data.

las2txt --stdout "${BASEMAP}_Data.las" | \
v.in.ascii -tbz z=3 out="${BASEMAP}_pts" fs=space

If topology was built, you can use {{cmd|d.vect}}'s -z flag to colorize by elevation value. Without topology you can still colorize, but you need to use color rules based on absolute elevations, not percentage of scale.

# display colorized points for data with built topology
d.vect map=lidar_pts size=1 -z zcolor=elevation

* After import as points you can then use the v.lidar tools to clean the data: {{cmd|v.lidar.correction}}, {{cmd|v.lidar.edgedetection}}, {{cmd|v.lidar.growing}}, and {{cmd|v.outlier}}.

* Vector points can be interpolated into raster DEMs with a number of modules, including {{cmd|v.surf.rst}}, {{cmd|v.surf.bspline}}, and {{cmd|v.surf.idw}}.

==== Import LAS in GRASS 7 ====

As vector points
* GRASS 7 offers the {{cmd|v.in.lidar|version=70}} command

As raster: map:
* {{cmd|r.in.lidar|version=70}} command

=== Clean imported raster DEM ===

(fill holes)

<source lang="bash">
# convert to vector points
r.to.vect -z feature=point in=${BASEMAP}_Data out=${BASEMAP}_pt

# interpolate using a regularized spline fit
# this is very slow, but produces very high quality output
v.surf.rst layer=0 in=${BASEMAP}_pt elev=${BASEMAP}.rst

# create 5m buffer area around original data points
r.buffer in=${BASEMAP}_Data out=${BASEMAP}.5m_buff dist=5

# crop interpolated DEM to only include areas nearby actual data
r.mapcalc "${BASEMAP}.filled = \
if( isnull(${BASEMAP}.5m_buff), null(), ${BASEMAP}.rst)"

# set colors to something nice
r.colors ${BASEMAP}.filled color=bcyr -e
</source>

Depending on your needs, {{cmd|r.fillnulls}}, {{cmd|v.surf.bspline}}, {{cmd|v.surf.idw}}, {{cmd|r.surf.idw}}, {{cmd|r.surf.idw2}}, or [[GRASS_AddOns#r.surf.nnbathy|r.surf.nnbathy]] may be faster than the {{cmd|v.surf.rst}} method.

=== Visualize raster DEM in 3D ===

nviz ${BASEMAP}.filled

* Set z-exag to 2.0
* In Visualize → Raster Surfaces set the fine (final) resolution to 1, and coarse (preview) resolution to 5.
* Set the height to 500.0, the perspective to 15.0, and drag the view-puck to the North-West and reasonably zoomed in.
: You should now be able to see the serpent:

[[Image:LAS_serpent_nviz.jpg|thumb|center|400px|The Great Serpent Mound, Adams County, Ohio, USA]]

It is possible to show vector points in 3D, but millions of them may make the program run slow. Topology is required ({{cmd|v.build}}). Tick the "3D" box in the Visualize → Vector points dialog.

=== LAS Export ===

==== Export to LAS ====

This is the reverse of the import step, but using {{cmd|v.out.ascii}} or {{cmd|r.out.xyz}} with ''txt2las''.
Because the v.out.ascii module exports category number which we are not interested in, we cut it away with the UNIX ''cut'' utility.

v.out.ascii ${BASEMAP}_pts fs=space | cut -f1-3 -d' ' \
> ${BASEMAP}_export.txt

txt2las --parse xyz -i ${BASEMAP}_export.txt

== Micro-tutorial for LIDAR data analysis ==

=== Simple analysis of single return data ===

Data source: North Carolina sample data set (Lidar data from 2001, near Raleigh, North Carolina). Download from
http://www.grassbook.org/ncexternal/
-> File: BE3720079200WC20020829m.txt 3.6M (lidar bare earth points [spm])

Scan input file for spatial extent. The -g flag shows the result in a convenient copy-paste format for {{cmd|g.region}}:
r.in.xyz BE3720079200WC20020829m.txt out=dummy -s -g

We use this output to set region, predefine 2m raster cells, and polish the odd coordinates with -a:
g.region n=222504.439000 s=219456.442000 e=640081.274000 w=637033.274000 res=2 -a -p

==== QUESTION 1: Are these Lidar data sufficiently dense? ====

We compute a raster map representing number of points per cell
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binn2m method=n

Look at the resulting raster map:
d.mon x0
d.font Vera
d.rast.leg lid_792_binn2m

Report point distribution in percent:
r.report lid_792_binn2m unit=p
r.univar lid_792_binn2m
# (sometimes do `r.null setnull=0` first)

Reduce the resolution to 6m to get at least one point per cell:
g.region res=6 -a -p
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binn6m method=n
d.rast.leg lid_792_binn6m
# ... a few holes remain but that's probably acceptable.

Compute raster maps representing mean elevation for each cell:
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binmean6m \
meth=mean
d.rast.leg lid_792_binmean6m

Compute range and variation:
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binrange6m \
meth=range
d.rast.leg lid_792_binrange6m
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binvar6m \
meth=coeff_var
d.rast.leg lid_792_binvar6m

Overlay other GIS maps to map of mean elevation:
d.rast.leg lid_792_binmean6m
d.vect streets_wake
d.vect lakes type=boundary
d.vect streams

Now we continue to work in a zoomed spatial subset of the area.

We import only points in the rural area without building topology and using z-coordinate for elevation:
g.region rural_1m -p
v.in.ascii -ztbr BE3720079200WC20020829m.txt \
out=elev_lidrural_bepts z=3

Clear monitor show black-white orthophoto:
d.erase -f
d.rast ortho_2001_t792_1m

We now use already prepared Lidar vector point maps:
* elev_lid792_bepts: Rural area (in tile 792), bare earth lidar point cloud
* elev_lidrural_mrpts: Rural area multiple return lidar point cloud

Look at ground data:
d.vect elev_lidrural_bepts siz=2 col=red

Look at "surface" data:
d.vect elev_lidrural_mrpts siz=1 col=green

Visualize 3D Lidar multi-return points:
nviz elev_lid792_1m point=elev_lidrural_mrpts
# Visualize -> Vector Points -> 3D points
# -> Icon size 2.25
# --> GRASS book p. 253, fig. 3.15 (see also screenshot [http://www.grassbook.org/about_menu3rd.php here])

==== DEM/DSM separation the simple way by selection of Lidar returns ====

Find out where we have multiple returns:
d.rast ortho_2001_t792_1m
d.vect elev_lidrural_mrpts where="return=1" col=red siz=2
d.vect elev_lidrural_mrpts where="return=2" col=green siz=3
d.vect elev_lidrural_mrpts where="return=3" col=blue
d.vect elev_lidrural_mrpts where="return=4" col=yellow

DTM: extract last return(s):
v.extract elev_lidrural_mrpts out=elev_lidrural_mrpts_first where="Return < 2"
nviz elev_lid792_1m point=elev_lidrural_mrpts_first

Interpolate to map and look at it:
v.surf.rst elev_lidrural_mrpts_first layer=0 elev=elev_lidrural_mrpts_DTM
nviz elev_lidrural_mrpts_DTM col=ortho_2001_t792_1m

DSM: extract first return(s):
v.extract elev_lidrural_mrpts out=elev_lidrural_mrpts_last where="Return > 2"
nviz elev_lid792_1m point=elev_lidrural_mrpts_last

Interpolate to map and look at it:
v.surf.rst elev_lidrural_mrpts_first layer=0 elev=elev_lidrural_mrpts_DSM
nviz elev_lidrural_mrpts_DSM col=ortho_2001_t792_1m

==== DEM/DSM separation the more complex way ====

''TODO: verify order of first and last returns in below text''

General procedure:
* Lidar point clouds (first and last return) are imported with {{cmd|v.in.ascii}} (-b flag to not build the topology).
* Outlier detection is done with {{cmd|v.outlier}} on both first and last return data (NB currently a selection of </=4 for soe/son in {{cmd|v.outlier}} results in an error message).
* Then, with {{cmd|v.lidar.edgedetection}}, edges are detected from last return data.
* The building are generated by {{cmd|v.lidar.growing}} from detected edges.
* The resulting data are post-processed with {{cmd|v.lidar.correction}}.
* Finally, the DTM and DSM are generated with {{cmd|v.surf.bspline}} (DTM: uses the 'v.lidar.correction' output; DSM: uses last return output from outlier detection).
* NB for {{cmd|v.outlier}}, {{cmd|v.lidar.edgedetection}} and {{cmd|v.surf.bspline}}, one spline steps equates to 1m. It is recommended as a starting point that the choice of spline step is roughly 3 or 4 times the planimetric resolution (potential grid resolution) of your data. Experiment from there to obtain better results.

export GRASS_OVERWRITE=1
v.extract elev_lidrural_mrpts out=elev_lidfirst_pts \
where="return = 1"
v.extract elev_lidrural_mrpts out=elev_lidlast_pts \
where="return >= 2"
d.vect elev_lidfirst_pts col=red
d.vect elev_lidlast_pts col=green

Outlier detection and separation into two maps
# 1st return
v.outlier elev_lidfirst_pts output=elev_lidfirst_clean \
outlier=elev_lidfirst_outl
d.erase
d.vect elev_lidfirst_clean siz=2
d.vect elev_lidfirst_outl col=red

2nd return
v.outlier elev_lidlast_pts output=elev_lidlast_clean \
outlier=elev_lidlast_outl
d.erase
d.vect elev_lidlast_clean siz=2
d.vect elev_lidlast_outl col=red
# -> no outliers visible

Run an edge detection on cleaned last return:
v.lidar.edgedetection elev_lidlast_clean \
out=elev_lidlast_edges

Buildings/vegetation are generated from detected edges (bug: you may need to specify the mapset):
v.lidar.growing elev_lidlast_edges@lidar out=elev_lidlast_grow \
first=elev_lidfirst_clean

Compare:
d.vect elev_lidlast_pts col=blue
d.vect elev_lidlast_grow col=green

Correction (this is applied twice):
v.lidar.correction elev_lidlast_grow out=elev_lidlast_corr1 \
terrain=elev_lidlast_terr1
v.lidar.correction elev_lidlast_corr1 out=elev_lid_dsm \
terrain=elev_lid_dtm

DEM and DSM are generated:
# Estimation of lambda_i parameter with cross validation (watch for RMS!)
# and note use of bicubic for DSM and bilinear for DTM here and below
v.surf.bspline -c elev_lid_dsm sie=100 sin=100 method=bicubic
v.surf.bspline -c elev_lid_dtm sie=100 sin=100 method=bilinear

# From the cross-validation, we select lambda with minimal RMS error:
# generate raster surfaces at 1m resolution
v.surf.bspline elev_lid_dsm raster=lidar_dsm lambda=0.1 method=bicubic
v.surf.bspline elev_lid_dtm raster=lidar_dtm lambda=0.0001 method=bilinear

d.rast lidar_dsm
d.rast lidar_dtm

nviz lidar_dsm,lidar_dtm \
col=ortho_2001_t792_1m,ortho_2001_t792_1m

...with the position slider you can visually separate DSM and DEM, increase z slider (Visualize -> Raster Surface -> Position).

=== Reclassification ===

As vector points
* {{cmd|v.reclass|version=70}} command

As raster map:
* {{cmd|r.reclass|version=70}} command

== Sample LIDAR data ==

=== Widely used in GRASS tutorials ===

* [http://www.grassbook.org/data_menu2nd.php Jockey's Ridge, NC, LIDAR dataset]
* [http://www.grassbook.org/data_menu3rd.php North Carolina OSGeo Edu data set] (includes multi-return LIDAR data)

=== Other ===

* United States Antarctic Resource Center: LIDAR High-resolution DEM Final DATA Downloads http://usarc.usgs.gov/lidar_dload.shtml

* LIDAR ALSM Research, Arizona State University Ative Tectonics, Research Group http://lidar.asu.edu/research.html and http://www.geongrid.org/science/lidar.html

* USGS Center for LIDAR Information Coordination and Knowledge (aka CLICK) - USGS LiDAR point cloud distribution site http://lidar.cr.usgs.gov

* Washington State Geospatial Data Archive, Mount Saint Helens - Lidar Data https://wagda.lib.washington.edu/data/type/elevation/lidar/st_helens/

* Puget Sound Lidar Consortium, public-domain high-resolution topography for western Washington http://pugetsoundlidar.ess.washington.edu/index.htm

* NOAA Topographic Change Mapping LIDAR Data Retrieval Tool (LDART) NOAA Coastal Services Center http://maps.csc.noaa.gov/TCM/

* Landmap, LIDAR Data from the Environment Agency http://www.landmap.ac.uk/lidar/lidar.html

* Northern California LIDAR data http://quake.usgs.gov/research/geology/lidar/ and http://core2.gsfc.nasa.gov/lidar/terrapoint/

* IDAHO GEOSPATIAL , Bare Earth LIDAR DEM Download - UTM http://inside.uidaho.edu/geodata/LiDAR/LiDARBareEarthDEM_DownloadUTM.htm

* EarthScope Spatial Data Explorer - A java application for querying, browsing, and acquiring data from the EarthScope Spatial Data Repository. Currently includes a number of LiDAR datasets. http://www.earthscope.org/data/lidar.php

* LIDAR Galley https://peoiewswebinfo.monmouth.army.mil/JPSD/LIDAR_Gallery.htm

* South Tyrol - Download of DTMs (Homepage in German or Italian) http://www.provinz.bz.it/raumordnung/grundkarten/utm/default_d.htm

* libLAS's sample file collection
:http://liblas.org/samples/

* NASA's Laser Vegetation Imaging Sensor (a.k.a. the Land, Vegetation, and Ice Sensor) or "LVIS"
:https://lvis.gsfc.nasa.gov

== Links ==

* [[Contour lines to DEM]] interpolation module trials
* [http://liblas.org/ libLAS] - LAS 1.0/1.1 ASPRS LiDAR data translation toolset
* [http://code.google.com/p/fullanalyze/ Fullanalyze] software based on MATIS

;Breaklines
* Not very well developed in GRASS so far, but we'd like to change that
* {{AddonCmd|v.surf.icw}} (only suitable for ~ 200 input points)
* [http://surfit.sourceforge.net/ SurfIt] (GPL, Tck/Tk)
* <strike>[http://surgeweb.sweb.cz/surgemain.htm SurGe] (Trial/shareware) </strike>
* [http://grasswiki.osgeo.org/wiki/TIN_with_breaklines v.triangle] add-on module for construction TIN with breaklines.

== Related publications ==

* Brovelli, M.A., Lucca, S., 2011. Filtering LiDAR with GRASS: overview of the method and comparisons with Terrascan. Italian Journal of Remote Sensing 93-105. ([http://www.aitjournal.com/articleView.aspx?ID=209 PDF])
* Brovelli, M.A., Cannata, M. & Longoni, U.M., 2004. LIDAR data filtering and DTM interpolation within GRASS. Transactions in GIS, 8(2), pp.155-174. [http://onlinelibrary.wiley.com/doi/10.1111/j.1467-9671.2004.00173.x/pdf PDF]
* Cebecauer, T., Hofierka, J. & Suri, M., 2002. Processing digital terrain models by regularized spline with tension: tuning interpolation parameters for different input datasets. In Proc. of the Open Source Free Software GIS -- GRASS users conference 2002, Trento, Italy, 11-13 September 2002. [http://www.ing.unitn.it/~grass/proceedings/proceedings/pdfs/Cebecauer_Tomas.pdf PDF]
* Mitasova, Helena et al., 2009. Raster-based analysis of coastal terrain dynamics from multitemporal Lidar data. Journal of Coastal Research, 25(2), pp.507-514.
* Mitasova, H, Mitas, L. & Harmon, R., 2005. Simultaneous spline approximation and topographic analysis for lidar elevation data in open-source GIS. Geoscience and Remote Sensing Letters, IEEE, 2(4), pp.379, 375. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.69.2934&rep=rep1&type=pdf PDF]
* Mitasova, H. et al., 2003. Spatio-temporal analysis of beach morphology using LIDAR, RTK-GPS and Open source GRASS GIS. In Proceedings Coastal Sediments. [http://skagit.meas.ncsu.edu/%7Ehelena/publwork/papers/pcoastsedp10.pdf PDF]

Search via [http://scholar.google.com/scholar?q=lidar+grass+gis Google Scholar]

== See also ==

* [http://knol.google.com/k/aerial-extraction-of-roof-surfaces-for-solar-analysis Aerial Extraction of Roof Surfaces for Solar Analysis]

[[Category:Documentation]]
[[Category: Interpolation]]
[[Category: Image processing]]
[[Category: Import]]
[[Category: Raster]]
[[Category: Vector]]

LIDAR

2013-02-24T22:21:16Z

⚠️Cmbarton: /* Import */

<h1> LIDAR and Multi-beam Swath bathymetry data </h1>

Point cloud data, as a type of representation of 3D surfaces, are usually produced by airborne or on-ground laser scanning, also known as Light Detection and Ranging (LiDAR). The data are often provided as sets of very dense (x, y, z) points or in a more complex, public file binary format called LAS that may include multiple returns as well as intensities. GRASS GIS supports basic and advanced lidar data processing and analysis.

== Modules ==

In this section various modules are introduced.

=== Import ===

* {{cmd|r.in.xyz}} - Create a raster map from an assemblage of many coordinates using univariate statistics. ([http://hamish.bowman.googlepages.com/grassfiles#xyz example])

* {{cmd|r.in.lidar}} - (GRASS 7 only) Create a raster map from a LAS format LiDAR file using univariate statistics and filtering. r.in.lidar is based on r.in.xyz. It can directly read a binary *.las file when GRASS is compiled with libLAS support. In addition to the options of r.in.xyz, r.in.lidar provides some basic lidar point fileter options.

* {{cmd|v.in.ascii}} - Import data from an ASCII file to GRASS vector format.
: ''Due to memory overhead vector point imports will be limited to a few million data points unless topology and database creation is skipped with the '''-bt''' flags''. It may also be useful to clip the import file to only accept points falling within the current region by using the '''-r''' flag. See {{cmd|g.region}} for details on specifying the region bounds.

* {{cmd|v.in.lidar}} - (GRASS 7 only). Creates a vector points file from a binary LAS format LiDAR file (*.las or *.laz). r.in.lidar also can create a new location based on the LAS file, and can filter the input points by return and subregion.

=== Analysis ===

* {{cmd|v.outlier}} - Removes outliers from vector point data.

* {{cmd|v.lidar.edgedetection}} - Detect the object's edges from a LIDAR data set.

* {{cmd|v.lidar.growing}} - Building contour determination and Region Growing algorithm for determining the building inside.

* {{cmd|v.lidar.correction}} - Correction of the v.lidar.growing output. It is the last of the three algorithms for LIDAR filtering.

''References:''

* Detailed description: [http://www.foss4g2006.org/getFile.py/access?contribId=48&sessionId=59&resId=7&materialId=slides&confId=1 here] (FOSS4G 2006)
* Summarised version: [http://geomatica.como.polimi.it/corsi/remote_sensing/LiDAR_filtering_with_GRASS-lab4.pdf here] (2010)
* Calibration of the filtering parameters (around 20 parameters) by integrating the USGS UCODE and GRASS, see [http://www.isprs.org/proceedings/XXXVIII/1_4_7-W5/paper/Brovelli-126.pdf here]

=== Surface generation ===

* {{cmd|v.surf.rst}} - Spatial approximation and topographic analysis using regularized spline with tension.

* {{cmd|v.surf.idw}} - Surface interpolation from vector point data by Inverse Distance Squared Weighting.

* {{cmd|v.surf.bspline}} - Surface interpolation from vector point data by bicubic or bilineal interpolation with Tykhonov regularization.

* {{cmd|r.fillnulls}} - Fills no-data areas in raster maps using v.surf.rst splines interpolation.

* {{AddonCmd|r.surf.nnbathy}} - Natural Neighbor interpolation using the 'nn' addon.

== Swath Bathymetry Tools ==

''see also the [[Marine_Science#Multibeam_sonar_processing]] wiki page''

* The [http://david.p.finlayson.googlepages.com/swathwidth v.swathwidth] module by David Finlayson for planning surveys. (development page)

* An example of [http://bambi.otago.ac.nz/hamish/grass/gdal/sidescan_warp.html post-processing scanned paper sidescan swaths] using thin plate spline warping with [http://www.gdal.org/ GDAL's] "<tt>gdalwarp -tps</tt>" function. (debugging page)

* [[MB-System|GRASS integration]] with [http://www.ldeo.columbia.edu/res/pi/MB-System/ MB-System] (GPL) software for processing Multibeam and Sidescan Sonar data. GRASS + [[MB-System|MBsys]] + [[GMT]] make a nice scriptable trio.

== LIDAR Tools ==

* {{cmd|r.terraflow}} - computation of flow direction, flow accumulation and other basic topographic terrain indices from massive raster digital elevation models (DEM). From the Duke University [http://terrain.cs.duke.edu/ STREAM] project.

* [http://mpa.itc.it/markus/grass61/demos/rlake/ Flood simulation] using {{cmd|r.lake}}. Includes fancy [[NVIZ]] visualization of Trento, Italy, by Markus Neteler.

* [http://www.cs.unc.edu/~isenburg/software/ LAStools] are a set of simple command line tools for converting to/from ASCII, viewing, comparing, and compressing LIDAR data. ''While free to use source code is available for older verions, newer versions are not open source, only work on MS Windows, and are no longer free for commercial or government use.''

* [http://www.liblas.org libLAS] ASPRS LiDAR data translation tools

* See also [[LIDAR#Analysis|LIDAR Analysis]]

== Micro-tutorial for LAS data import ==

''The following scripts are given for UNIX Bourne Shell; MS-Windows users should use the Msys terminal to use them.''

=== Preparation ===

==== Conversion of text files to LAS ====

[http://www.liblas.org/ libLAS] supports the following column types:
x - x coordinate
y - y coordinate
z - z coordinate
a - scan angle
i - intensity
n - number of returns for given pulse (1..n)
r - number of this return (1..r)
c - classification
u - user data (but only 1 byte)
p - point source ID
e - edge of flight line
d - direction of scan flag
t - GPS time
s - skip column

Sample text data such as:
returntime,pulse,east,north,height,intensity,stripe
549778.907200,1,673999.940,5099680.080,507.425,20.0,45105
...

can be converted to LAS format like this:
returntime - t
pulse - r
east - x
north - y
height - z
intensity - i
stripe - s

First parse (sanity check):
txt2las -parse trxyzis data.asc

Then convert:
txt2las -parse trxyzis -i data.asc -o data.las

While you may not need to do this conversion for GRASS import, the resulting files are way smaller than the uncompressed text files; additionally, they are in a defined format.

=== LAS Import ===

* Use the [http://www.liblas.org libLAS] utilities to import LAS data into GRASS.
* Data stored in text files can generally be imported directly into GRASS.

* The data used in the rest of this micro-tutorial can be found at [http://www.appliedimagery.com/downloads/sampledata/Serpent%20Mound%20Model%20LAS%20Data.las appliedimagery.com].

==== Import LAS as raster DEM ====

Check bounds and SRS:
$ lasinfo "Serpent_Mound_Model_LAS_Data.las"

[...]
Min X Y Z 289020.900000 4320942.610000 166.780000
Max X Y Z 290106.020000 4323641.570000 215.480000
Spatial Reference +proj=utm +zone=17 +ellps=WGS84 +units=m

After creating a suitable UTM zone 17 location (EPSG:32617)
set the region according to the information from lasinfo at 1m resolution, rounding grid outwards to align to whole meters:
GRASS> {{cmd|g.region}} n=4323641.57 s=4320942.61 w=289020.90 e=290106.02 res=1 -ap

Finally, import with {{cmd|r.in.xyz}} with data piped directly from the <tt>las2txt</tt> program and set a nice equalized color table:
BASEMAP="Serpent_Mound_Model_LAS"

las2txt --stdout --delimiter ' ' "${BASEMAP}_Data.las" | \
r.in.xyz in=- out=${BASEMAP}_Data fs=space method=mean

{{cmd|r.colors}} ${BASEMAP}_Data color=bcyr -e

The above example uses the default z-elevation level as the 3rd term, but by using the <tt>las2txt --parse</tt> command other fields (such as intensity) can be imported instead via "<tt>--parse xyi</tt>". Unfortunately there seem to be a number of versions of las2txt and each are called slightly differently. You might have to experiment a little to get the right incantation.

==== Import LAS as vector points in GRASS 6 ====

Region setting (establishing the grid) is not needed for vector features so we can go directly to the import step. To deal with millions of input points {{cmd|v.in.ascii}} should be run with the options to skip creation of an attribute database and building topology as these can consume large amounts of memory. Note that vector maps without topology built are somewhat limited in their ability to be processed. Most LIDAR specific modules have been adapted to not require
topology. Even so, after initial cleaning steps it is often more efficient to work with huge datasets in GRASS as raster data.

las2txt --stdout "${BASEMAP}_Data.las" | \
v.in.ascii -tbz z=3 out="${BASEMAP}_pts" fs=space

If topology was built, you can use {{cmd|d.vect}}'s -z flag to colorize by elevation value. Without topology you can still colorize, but you need to use color rules based on absolute elevations, not percentage of scale.

# display colorized points for data with built topology
d.vect map=lidar_pts size=1 -z zcolor=elevation

* After import as points you can then use the v.lidar tools to clean the data: {{cmd|v.lidar.correction}}, {{cmd|v.lidar.edgedetection}}, {{cmd|v.lidar.growing}}, and {{cmd|v.outlier}}.

* Vector points can be interpolated into raster DEMs with a number of modules, including {{cmd|v.surf.rst}}, {{cmd|v.surf.bspline}}, and {{cmd|v.surf.idw}}.

==== Import LAS in GRASS 7 ====

As vector points
* GRASS 7 offers the {{cmd|v.in.lidar|version=70}} command

As raster: map:
* {{cmd|r.in.lidar|version=70}} command

=== Clean imported raster DEM ===

(fill holes)

<source lang="bash">
# convert to vector points
r.to.vect -z feature=point in=${BASEMAP}_Data out=${BASEMAP}_pt

# interpolate using a regularized spline fit
# this is very slow, but produces very high quality output
v.surf.rst layer=0 in=${BASEMAP}_pt elev=${BASEMAP}.rst

# create 5m buffer area around original data points
r.buffer in=${BASEMAP}_Data out=${BASEMAP}.5m_buff dist=5

# crop interpolated DEM to only include areas nearby actual data
r.mapcalc "${BASEMAP}.filled = \
if( isnull(${BASEMAP}.5m_buff), null(), ${BASEMAP}.rst)"

# set colors to something nice
r.colors ${BASEMAP}.filled color=bcyr -e
</source>

Depending on your needs, {{cmd|r.fillnulls}}, {{cmd|v.surf.bspline}}, {{cmd|v.surf.idw}}, {{cmd|r.surf.idw}}, {{cmd|r.surf.idw2}}, or [[GRASS_AddOns#r.surf.nnbathy|r.surf.nnbathy]] may be faster than the {{cmd|v.surf.rst}} method.

=== Visualize raster DEM in 3D ===

nviz ${BASEMAP}.filled

* Set z-exag to 2.0
* In Visualize → Raster Surfaces set the fine (final) resolution to 1, and coarse (preview) resolution to 5.
* Set the height to 500.0, the perspective to 15.0, and drag the view-puck to the North-West and reasonably zoomed in.
: You should now be able to see the serpent:

[[Image:LAS_serpent_nviz.jpg|thumb|center|400px|The Great Serpent Mound, Adams County, Ohio, USA]]

It is possible to show vector points in 3D, but millions of them may make the program run slow. Topology is required ({{cmd|v.build}}). Tick the "3D" box in the Visualize → Vector points dialog.

=== LAS Export ===

==== Export to LAS ====

This is the reverse of the import step, but using {{cmd|v.out.ascii}} or {{cmd|r.out.xyz}} with ''txt2las''.
Because the v.out.ascii module exports category number which we are not interested in, we cut it away with the UNIX ''cut'' utility.

v.out.ascii ${BASEMAP}_pts fs=space | cut -f1-3 -d' ' \
> ${BASEMAP}_export.txt

txt2las --parse xyz -i ${BASEMAP}_export.txt

== Micro-tutorial for LIDAR data analysis ==

=== Simple analysis of single return data ===

Data source: North Carolina sample data set (Lidar data from 2001, near Raleigh, North Carolina). Download from
http://www.grassbook.org/ncexternal/
-> File: BE3720079200WC20020829m.txt 3.6M (lidar bare earth points [spm])

Scan input file for spatial extent. The -g flag shows the result in a convenient copy-paste format for {{cmd|g.region}}:
r.in.xyz BE3720079200WC20020829m.txt out=dummy -s -g

We use this output to set region, predefine 2m raster cells, and polish the odd coordinates with -a:
g.region n=222504.439000 s=219456.442000 e=640081.274000 w=637033.274000 res=2 -a -p

==== QUESTION 1: Are these Lidar data sufficiently dense? ====

We compute a raster map representing number of points per cell
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binn2m method=n

Look at the resulting raster map:
d.mon x0
d.font Vera
d.rast.leg lid_792_binn2m

Report point distribution in percent:
r.report lid_792_binn2m unit=p
r.univar lid_792_binn2m
# (sometimes do `r.null setnull=0` first)

Reduce the resolution to 6m to get at least one point per cell:
g.region res=6 -a -p
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binn6m method=n
d.rast.leg lid_792_binn6m
# ... a few holes remain but that's probably acceptable.

Compute raster maps representing mean elevation for each cell:
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binmean6m \
meth=mean
d.rast.leg lid_792_binmean6m

Compute range and variation:
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binrange6m \
meth=range
d.rast.leg lid_792_binrange6m
r.in.xyz BE3720079200WC20020829m.txt out=lid_792_binvar6m \
meth=coeff_var
d.rast.leg lid_792_binvar6m

Overlay other GIS maps to map of mean elevation:
d.rast.leg lid_792_binmean6m
d.vect streets_wake
d.vect lakes type=boundary
d.vect streams

Now we continue to work in a zoomed spatial subset of the area.

We import only points in the rural area without building topology and using z-coordinate for elevation:
g.region rural_1m -p
v.in.ascii -ztbr BE3720079200WC20020829m.txt \
out=elev_lidrural_bepts z=3

Clear monitor show black-white orthophoto:
d.erase -f
d.rast ortho_2001_t792_1m

We now use already prepared Lidar vector point maps:
* elev_lid792_bepts: Rural area (in tile 792), bare earth lidar point cloud
* elev_lidrural_mrpts: Rural area multiple return lidar point cloud

Look at ground data:
d.vect elev_lidrural_bepts siz=2 col=red

Look at "surface" data:
d.vect elev_lidrural_mrpts siz=1 col=green

Visualize 3D Lidar multi-return points:
nviz elev_lid792_1m point=elev_lidrural_mrpts
# Visualize -> Vector Points -> 3D points
# -> Icon size 2.25
# --> GRASS book p. 253, fig. 3.15 (see also screenshot [http://www.grassbook.org/about_menu3rd.php here])

==== DEM/DSM separation the simple way by selection of Lidar returns ====

Find out where we have multiple returns:
d.rast ortho_2001_t792_1m
d.vect elev_lidrural_mrpts where="return=1" col=red siz=2
d.vect elev_lidrural_mrpts where="return=2" col=green siz=3
d.vect elev_lidrural_mrpts where="return=3" col=blue
d.vect elev_lidrural_mrpts where="return=4" col=yellow

DTM: extract last return(s):
v.extract elev_lidrural_mrpts out=elev_lidrural_mrpts_first where="Return < 2"
nviz elev_lid792_1m point=elev_lidrural_mrpts_first

Interpolate to map and look at it:
v.surf.rst elev_lidrural_mrpts_first layer=0 elev=elev_lidrural_mrpts_DTM
nviz elev_lidrural_mrpts_DTM col=ortho_2001_t792_1m

DSM: extract first return(s):
v.extract elev_lidrural_mrpts out=elev_lidrural_mrpts_last where="Return > 2"
nviz elev_lid792_1m point=elev_lidrural_mrpts_last

Interpolate to map and look at it:
v.surf.rst elev_lidrural_mrpts_first layer=0 elev=elev_lidrural_mrpts_DSM
nviz elev_lidrural_mrpts_DSM col=ortho_2001_t792_1m

==== DEM/DSM separation the more complex way ====

''TODO: verify order of first and last returns in below text''

General procedure:
* Lidar point clouds (first and last return) are imported with {{cmd|v.in.ascii}} (-b flag to not build the topology).
* Outlier detection is done with {{cmd|v.outlier}} on both first and last return data (NB currently a selection of </=4 for soe/son in {{cmd|v.outlier}} results in an error message).
* Then, with {{cmd|v.lidar.edgedetection}}, edges are detected from last return data.
* The building are generated by {{cmd|v.lidar.growing}} from detected edges.
* The resulting data are post-processed with {{cmd|v.lidar.correction}}.
* Finally, the DTM and DSM are generated with {{cmd|v.surf.bspline}} (DTM: uses the 'v.lidar.correction' output; DSM: uses last return output from outlier detection).
* NB for {{cmd|v.outlier}}, {{cmd|v.lidar.edgedetection}} and {{cmd|v.surf.bspline}}, one spline steps equates to 1m. It is recommended as a starting point that the choice of spline step is roughly 3 or 4 times the planimetric resolution (potential grid resolution) of your data. Experiment from there to obtain better results.

export GRASS_OVERWRITE=1
v.extract elev_lidrural_mrpts out=elev_lidfirst_pts \
where="return = 1"
v.extract elev_lidrural_mrpts out=elev_lidlast_pts \
where="return >= 2"
d.vect elev_lidfirst_pts col=red
d.vect elev_lidlast_pts col=green

Outlier detection and separation into two maps
# 1st return
v.outlier elev_lidfirst_pts output=elev_lidfirst_clean \
outlier=elev_lidfirst_outl
d.erase
d.vect elev_lidfirst_clean siz=2
d.vect elev_lidfirst_outl col=red

2nd return
v.outlier elev_lidlast_pts output=elev_lidlast_clean \
outlier=elev_lidlast_outl
d.erase
d.vect elev_lidlast_clean siz=2
d.vect elev_lidlast_outl col=red
# -> no outliers visible

Run an edge detection on cleaned last return:
v.lidar.edgedetection elev_lidlast_clean \
out=elev_lidlast_edges

Buildings/vegetation are generated from detected edges (bug: you may need to specify the mapset):
v.lidar.growing elev_lidlast_edges@lidar out=elev_lidlast_grow \
first=elev_lidfirst_clean

Compare:
d.vect elev_lidlast_pts col=blue
d.vect elev_lidlast_grow col=green

Correction (this is applied twice):
v.lidar.correction elev_lidlast_grow out=elev_lidlast_corr1 \
terrain=elev_lidlast_terr1
v.lidar.correction elev_lidlast_corr1 out=elev_lid_dsm \
terrain=elev_lid_dtm

DEM and DSM are generated:
# Estimation of lambda_i parameter with cross validation (watch for RMS!)
# and note use of bicubic for DSM and bilinear for DTM here and below
v.surf.bspline -c elev_lid_dsm sie=100 sin=100 method=bicubic
v.surf.bspline -c elev_lid_dtm sie=100 sin=100 method=bilinear

# From the cross-validation, we select lambda with minimal RMS error:
# generate raster surfaces at 1m resolution
v.surf.bspline elev_lid_dsm raster=lidar_dsm lambda=0.1 method=bicubic
v.surf.bspline elev_lid_dtm raster=lidar_dtm lambda=0.0001 method=bilinear

d.rast lidar_dsm
d.rast lidar_dtm

nviz lidar_dsm,lidar_dtm \
col=ortho_2001_t792_1m,ortho_2001_t792_1m

...with the position slider you can visually separate DSM and DEM, increase z slider (Visualize -> Raster Surface -> Position).

=== Reclassification ===

As vector points
* {{cmd|v.reclass|version=70}} command

As raster map:
* {{cmd|r.reclass|version=70}} command

== Sample LIDAR data ==

=== Widely used in GRASS tutorials ===

* [http://www.grassbook.org/data_menu2nd.php Jockey's Ridge, NC, LIDAR dataset]
* [http://www.grassbook.org/data_menu3rd.php North Carolina OSGeo Edu data set] (includes multi-return LIDAR data)

=== Other ===

* United States Antarctic Resource Center: LIDAR High-resolution DEM Final DATA Downloads http://usarc.usgs.gov/lidar_dload.shtml

* LIDAR ALSM Research, Arizona State University Ative Tectonics, Research Group http://lidar.asu.edu/research.html and http://www.geongrid.org/science/lidar.html

* USGS Center for LIDAR Information Coordination and Knowledge (aka CLICK) - USGS LiDAR point cloud distribution site http://lidar.cr.usgs.gov

* Washington State Geospatial Data Archive, Mount Saint Helens - Lidar Data https://wagda.lib.washington.edu/data/type/elevation/lidar/st_helens/

* Puget Sound Lidar Consortium, public-domain high-resolution topography for western Washington http://pugetsoundlidar.ess.washington.edu/index.htm

* NOAA Topographic Change Mapping LIDAR Data Retrieval Tool (LDART) NOAA Coastal Services Center http://maps.csc.noaa.gov/TCM/

* Landmap, LIDAR Data from the Environment Agency http://www.landmap.ac.uk/lidar/lidar.html

* Northern California LIDAR data http://quake.usgs.gov/research/geology/lidar/ and http://core2.gsfc.nasa.gov/lidar/terrapoint/

* IDAHO GEOSPATIAL , Bare Earth LIDAR DEM Download - UTM http://inside.uidaho.edu/geodata/LiDAR/LiDARBareEarthDEM_DownloadUTM.htm

* EarthScope Spatial Data Explorer - A java application for querying, browsing, and acquiring data from the EarthScope Spatial Data Repository. Currently includes a number of LiDAR datasets. http://www.earthscope.org/data/lidar.php

* LIDAR Galley https://peoiewswebinfo.monmouth.army.mil/JPSD/LIDAR_Gallery.htm

* South Tyrol - Download of DTMs (Homepage in German or Italian) http://www.provinz.bz.it/raumordnung/grundkarten/utm/default_d.htm

* libLAS's sample file collection
:http://liblas.org/samples/

* NASA's Laser Vegetation Imaging Sensor (a.k.a. the Land, Vegetation, and Ice Sensor) or "LVIS"
:https://lvis.gsfc.nasa.gov

== Links ==

* [[Contour lines to DEM]] interpolation module trials
* [http://liblas.org/ libLAS] - LAS 1.0/1.1 ASPRS LiDAR data translation toolset
* [http://code.google.com/p/fullanalyze/ Fullanalyze] software based on MATIS

;Breaklines
* Not very well developed in GRASS so far, but we'd like to change that
* {{AddonCmd|v.surf.icw}} (only suitable for ~ 200 input points)
* [http://surfit.sourceforge.net/ SurfIt] (GPL, Tck/Tk)
* <strike>[http://surgeweb.sweb.cz/surgemain.htm SurGe] (Trial/shareware) </strike>
* [http://grasswiki.osgeo.org/wiki/TIN_with_breaklines v.triangle] add-on module for construction TIN with breaklines.

== Related publications ==

* Brovelli, M.A., Lucca, S., 2011. Filtering LiDAR with GRASS: overview of the method and comparisons with Terrascan. Italian Journal of Remote Sensing 93-105. ([http://www.aitjournal.com/articleView.aspx?ID=209 PDF])
* Brovelli, M.A., Cannata, M. & Longoni, U.M., 2004. LIDAR data filtering and DTM interpolation within GRASS. Transactions in GIS, 8(2), pp.155-174. [http://onlinelibrary.wiley.com/doi/10.1111/j.1467-9671.2004.00173.x/pdf PDF]
* Cebecauer, T., Hofierka, J. & Suri, M., 2002. Processing digital terrain models by regularized spline with tension: tuning interpolation parameters for different input datasets. In Proc. of the Open Source Free Software GIS -- GRASS users conference 2002, Trento, Italy, 11-13 September 2002. [http://www.ing.unitn.it/~grass/proceedings/proceedings/pdfs/Cebecauer_Tomas.pdf PDF]
* Mitasova, Helena et al., 2009. Raster-based analysis of coastal terrain dynamics from multitemporal Lidar data. Journal of Coastal Research, 25(2), pp.507-514.
* Mitasova, H, Mitas, L. & Harmon, R., 2005. Simultaneous spline approximation and topographic analysis for lidar elevation data in open-source GIS. Geoscience and Remote Sensing Letters, IEEE, 2(4), pp.379, 375. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.69.2934&rep=rep1&type=pdf PDF]
* Mitasova, H. et al., 2003. Spatio-temporal analysis of beach morphology using LIDAR, RTK-GPS and Open source GRASS GIS. In Proceedings Coastal Sediments. [http://skagit.meas.ncsu.edu/%7Ehelena/publwork/papers/pcoastsedp10.pdf PDF]

Search via [http://scholar.google.com/scholar?q=lidar+grass+gis Google Scholar]

== See also ==

* [http://knol.google.com/k/aerial-extraction-of-roof-surfaces-for-solar-analysis Aerial Extraction of Roof Surfaces for Solar Analysis]

[[Category:Documentation]]
[[Category: Interpolation]]
[[Category: Image processing]]
[[Category: Import]]
[[Category: Raster]]
[[Category: Vector]]

Compiling on MacOSX

2013-02-03T19:02:55Z

⚠️Cmbarton: Instructions for compiling GRASS 6 and 7 on Mac OS X 10.8 to run on OS X 10.6 and up

Up-to-date compilation instructions are maintained in the source <tt>[http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/macosx/ReadMe.rtf?format=raw macosx/ReadMe.rtf]</tt>.
This builds a double-clickable application with "aqua" options where possible (Tcl/Tk, Python, OpenGL,...)
and leaves out obscure X11-only-based features that have newer system-agnostic options (like motif/xganim),
though these newer features may not be quite as fully-featured, yet.
The X11 display system ''is'' included, since it is simple to include and is still quite useful.

The method below is for the older X11-based compilation, and includes the X11 motif-based xganim.

To build Grass from source you can use the frameworks that are on :
http://www.kyngchaos.com/software:frameworks
great thanks to W.Kyngesburye.

After installing all the frameworks you can add some library such "motif" needed by Xganim, using fink or build the source code

Install from source the tcl-tk library : http://www.tcl.tk/software/tcltk/downloadnow84.tml in /usr/local

Postgres can be easily compiled from source.

Download a SVN version http://grass.osgeo.org/download/index.php

Then configure and make GRASS from SVN/source code snapshot :

<pre>
cd /path_to_grass_source

./configure --enable-sysv --with-x --with-opengl=x11 --without-odbc --with-cxx --with-freetype \
--with-freetype-includes=/Library/Frameworks/FreeType.framework/unix/include \
--with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib \
--with-gdal=/Library/Frameworks/GDAL.framework/Versions/1.5/Programs/gdal-config \
--with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include \
--with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib \
--with-proj-share=/Library/Frameworks/PROJ.framework/Versions/4.5/unix/share/ \
--with-tiff --with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include \
--with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib \
--with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include \
--with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib \
--with-sqlite --with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib \
--with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include \
--with-fftw --with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include \
--with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib \
--with-postgres-includes=/usr/local/pgsql/include --with-postgres-libs=/usr/local/pgsql/lib \
--with-freetype --with-freetype-includes=/Library/Frameworks/FreeType.framework/unix/include \
--with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib --with-python --with-readline \
--with-readline-includes=/sw/include/readline --with-readline-libs=/sw/lib --with-tcltk-includes=/usr/local/include \
--with-tcltk-libs=/usr/local/lib --with-blas --with-lapack \
--with-blas-includes=/System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Headers \
--with-lapack-includes=/System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Headers \
--with-motif --with-motif-includes=/sw/include --with-motif-libs=/sw/lib --with-glw

make
sudo make install
</pre>

'''COMPILING GRASS ON MAC OSX 10.8 TO RUN ON OSX 10.6 AND UP 64 BIT'''

Here are instructions on how to compile GRASS 6 and 7 on Mac OS X 10.8 so that it also runs in GRASS OS X 10.6 and up in 64 bit (but with 32 bit wxPython).

You must have Apple's developer tools installed, including the MacOSX10.6.sdk if you want your binary to run on OS X 10.6 as well as later versions of the OS

'''PREPARATION TO COMPILE (you only need to do this once)'''

''Step 1'': Python and wxPython:

Currently, do NOT install a 3rd party Python (e.g., from python.org) unless you know how to configure PYTHONPATH appropriately for GRASS and wxPython.

Mac OS X comes with Python 2.6 and OS X 10.7/10.8 comes with Python 2.6 and 2.7. This set up will use whatever your system comes with, but compiles wxPython to use Python 2.6

Install wxPython 2.8.12.1 for Python 2.6 (note that the installation directory must be correctly referenced in the configure script)

Create a script named "python" with the following in it and put it somewhere so it can be added to your path at compile time. For example, I put it in /Applications/python/bin32

<pre>
#!/bin/sh
exec arch -i386 pythonw2.6 "$@"
</pre>

This is to force python to run 32bit so wxpython tests work in configure (it also references the system python 2.6 and not 2.7).

''Step 2'': edit bundling code in ../grass7/macosx/

Make a script named "bundle.sh" with the following code:

<pre>
# DYLD_FRAMEWORK_PATH for bundled frameworks

sed -i '' -e 's,^export DYLD_LIBRARY_PATH$,&\
export DYLD_FRAMEWORK_PATH="\$GISBASE/lib",' \
${INST_DIR_TARGET}/grass.sh
</pre>

''Step 3'': Set up bundling to make GRASS binary package for distribution

Edit bundle.make to reference wxPython. This includes a copy of wxPython with the GRASS binary so it will run regardless of what version of wxPython the user has installed separately. It also bundles fftw3.

<pre>
...

WXPREFIX=/usr/local/lib/wxPython-unicode-2.8.12.1

bundle-macosx:
${INSTALL} ${WXPREFIX}/lib/libwx_macud-2.8.0.dylib ${INST_DIR_TARGET}/lib
${INSTALL} ${WXPREFIX}/lib/libwx_macud_gl-2.8.0.dylib ${INST_DIR_TARGET}/lib
${INSTALL} ${WXPREFIX}/lib/libwx_macud_stc-2.8.0.dylib ${INST_DIR_TARGET}/lib
${INSTALL} ${WXPREFIX}/lib/libwx_macud_gizmos-2.8.0.dylib ${INST_DIR_TARGET}/lib
${INSTALL} ${WXPREFIX}/lib/libwx_macud_gizmos_xrc-2.8.0.dylib ${INST_DIR_TARGET}/lib
cp -Rf ${WXPREFIX}/lib/python2.6/site-packages/wx-2.8-mac-unicode/wx ${INST_DIR_TARGET}/etc/python
cp -Rf ${WXPREFIX}/lib/python2.6/site-packages/wx-2.8-mac-unicode/wxPython ${INST_DIR_TARGET}/etc/python
cp -f ${WXPREFIX}/lib/python2.6/site-packages/wxversion.py ${INST_DIR_TARGET}/etc/python
sed -i '' -e 's/^GRASS_WXBUNDLED=.*/GRASS_WXBUNDLED=1/' ${INST_DIR_TARGET}/grass.sh
cp -Rf /Library/Frameworks/FFTW3.framework ${INST_DIR_TARGET}/lib/FFTW3.framework
/usr/bin/env INST_DIR_TARGET="${INST_DIR_TARGET}" ./bundle.sh
</pre>

You can bundle additional code if you desire. I also bundle gettext and LAS tools.

'''AT THE TIME OF COMPILATION (do this each time you compile)'''

''Step 1'': export the following prior to configuration. This makes GRASS run on OSX 10.6 as well as 10.7 and 10.8

<pre>
export MACOSX_DEPLOYMENT_TARGET=10.6

export PATH="/Applications/python/bin32:/System/Library/Frameworks/Python.framework/Versions/2.6/bin:$PATH"

export CXX=g++
</pre>

''Step 2'': configuration. Here is my configure script. This configures for both 32 and 64 bit. Because wxPython 2.8.x only runs 32 bit, it is configured to run in Python 2.6 32 bit. But the rest of GRASS will take advantage of the Mac 64 bit processing.

Here is my configuration script

<pre>
./configure --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk --with-freetype --with-freetype-includes="/Library/Frameworks/FreeType.framework/unix/include/freetype2 /Library/Frameworks/FreeType.framework/unix/include" --with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib --with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config --with-proj --with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj --with-geos=/Library/Frameworks/GEOS.framework/Versions/3/unix/bin/geos-config --with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include --with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib --with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include --with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib --with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include --with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib --with-cairo --with-cairo-includes="/Library/Frameworks/cairo.framework/unix/include/cairo /Library/Frameworks/cairo.framework/unix/include" --with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib --with-cairo-ldflags="-lcairo" --without-postgres --without-mysql --with-odbc --with-sqlite --with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib --with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include --with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include --with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-x --with-cxx --with-opengl=aqua --without-readline --prefix=/Applications/GRASS --enable-macosx-app --with-python --with-wxwidgets=/usr/local/lib/wxPython-unicode-2.8.12.1/bin/wx-config --with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers /Library/Frameworks/Tk.framework/Headers /Library/Frameworks/Tk.framework/PrivateHeaders" --with-tcltk-libs="/usr/local/tcltk_active/lib" --with-macosx-archs="i386 x86_64"
</pre>

''Step 3'': make

<pre>
make GDAL_DYNAMIC=

for GRASS 6, simply use make
</pre>

''Step 4'': create installation bundle

<pre>
make bindist
</pre>

[[Category:Development]]
[[Category:Documentation]]
[[Category:Installation]]

NetCDF

2012-02-15T21:06:33Z

⚠️Cmbarton: Added information about how to import NetCDF data into GRASS using r.in.gdal

Both netCDF import and export in GRASS GIS are basically driven by the [http://www.gdal.org GDAL library]. Note that GDAL library needs to be compiled with [http://www.gdal.org/frmt_netcdf.html netCDF support] to enable GRASS to read and write this format.

== netCDF import ==
The important key to importing NetCDF raster file via r.in.gdal is to specify the correct data '''subset''' in the ''input'' argument. NetCDF subset specifiers can be obtained from the output of gdalinfo.

For a file named sst.nc...

gdalinfo sst.nc

...will produce a lot of output, including lines that look like this:

SUBDATASET_3_NAME=NETCDF:"sst.nc":time_bnds

The input argument to r.in.gdal must contain all the information after the "=" in the format NETCDF:"[''path to file in double quotes'']":[''variable name'']. To import the '''time_bnds''' data from NetCDF file '''sst.nc''' into GRASS, you need to specify the input as follows:

r.in.gdal input=NETCDF:"sst.nc":time_bnds output=sst

The '''time_bnds''' subset may contain multiple data bands. Information about the bands in a subset can be obtained by running gdalinfo on just the subset

gdalinfo NETCDF:"sst.nc":time_bnds

...will produce output like this:

Band 22 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=645
NETCDF_time_units=days since 2001-1-1

You can specify the bands you want to extract using the ''bands='' argument of r.in.gdal

* also see the [[GMT]] page and {{cmd|r.in.gdal}}

== netCDF export ==

* see {{cmd|r.out.gdal}}

* As part of a Google Summer of Code 2009 project Andrea Antonello has put together a [http://code.google.com/p/jgrass/wiki/SummerOfCode2009 GUI controlled GRASS raster timeseries to netCDF export tool using uDig].

== Sample datasets and mini-tutorial ==

* (''contributions welcome'')

[[Category: FAQ]]
[[Category: Geodata]]

Archeology

2012-01-15T21:22:01Z

⚠️Cmbarton: /* Bibliography */

GRASS GIS is used in many archaeological projects.

== Mailing list threads ==

* [http://thread.gmane.org/gmane.comp.gis.grass.user/27990 Who's using GRASS for archaeological applications?]

== Data exchange ==

* {{AddonCmd|v.in.ply}}: import of PLY format (3D)
* {{cmd|v.in.dxf}}: import of DXF format (2D and 3D)
* {{cmd|v.out.dxf}}: export of DXF format (2D and 3D)
* many other formats..

== Georeferencing ==

* Georeferencing of point clouds: get your data from an arbitrary coordinates system into real world projections: {{cmd|v.rectify|version=70}}. It also perform 3D transformation (affine and polynomial). Working even with very large point clouds (several million points in a few minutes).

== Image processing ==

* see [[Image processing]]
* [[LIDAR]]

== Visualization ==

* see [[:Category:Visualization]]

== See also ==

=== Bibliography ===
* Ullah, I.I.T., 2011. [http://www.sciencedirect.com/science/article/pii/S0305440310003705 "A GIS method for assessing the zone of human-environmental impact around archaeological sites: a test case from the Late Neolithic of Wadi Ziqlâb, Jordan"]. Journal of Archaeological Science, 38(3), 623-632. doi:10.1016/j.jas.2010.10.015
* Barton, C.M., Ullah, I. & Mitasova, H., 2010. [http://sagunto.la.asu.edu:8080/medlandweb/Barton_etal2010.pdf ''Computational modeling and neolithic socioecological dynamics: A case study from southwest Asia']'. Am antiquity, 75(2), 364-386.
* Barton, C.M., Ullah, I, & Bergin, S, 2010. [http://rsta.royalsocietypublishing.org.ezproxy1.lib.asu.edu/content/368/1931/5275.abstract "Land use, water and Mediterranean landscapes: modelling long-term dynamics of complex socio-ecological systems"]. Philosophical Transactions of the Royal Society A: Mathematical, Physical and Engineering Sciences, 368(1931), 5275 -5297. doi:10.1098/rsta.2010.0193
* M. Neteler, 2009: ''[http://www.slideshare.net/markusN/grass-and-osgeo-a-framework-for-archeology GRASS GIS and OSGeo: A framework for archeology]'' (Invited keynote). Quarto Workshop Italiano [http://www.archeo-foss.org/ "Open Source, Free Software e Open Format nei processi di ricerca archeologica"], CNR di Roma, 27-28 April 2009
* Conolly, J., Lake, M., 2006. Geographical Information Systems in Archaeology (Cambridge Manuals in Archaeology) [ [http://www.amazon.co.uk/Geographical-Information-Systems-Archaeology-Cambridge/dp/0521797446/ Book] ]
* A. Bezzi, L. Bezzi, D. Francisci, R. Gietl, 2006. ''L'utilizzo di Voxel in campo archeologico'', Geomatics workbooks 6 [ [http://geomatica.como.polimi.it/workbooks/n6/list.php PDF] ]

=== Sample archeological data sets ===

* [http://www.tuarc.trentu.ca/~aspweb/en/downloads.shtml Antikythera Survey Project (ASP)]

=== Some archaeological links related to GRASS ===

* http://wiki.iosa.it/ Quantitative Archaeology Wiki (check out the "Spatial Analysis" section)
* http://arc-team-open-research.blogspot.com/ - GRASS and Blender in archaeology
* http://arkygeek.blogspot.com/
* http://www.arc-team.com/wiki/doku.php - ArcheOS - The first GNU/Linux distribution for archaeology ([http://www.arc-team.com/archeos/wiki/doku.php?id=screenshots screenshots])
* [http://undine-lieberwirth.info/?page_id=8 Voxels and GRASS] in Archeology (animations)
* http://tdx.cat/TESIS_UB/AVAILABLE/TDX-0720109-092434/ - PhD Dissertation about conflict archaeology, with extensive use of GRASS and QGIS.
* http://medland.asu.edu - Mediterranean Landscape Dynamics Project. Dynamic surface process modeling in GRASS coupled with agent-based modeling of agricultural land-use

[[Category:Applications]]
[[Category:Documentation]]

Archeology

2012-01-15T21:05:39Z

⚠️Cmbarton: /* Bibliography */

GRASS GIS is used in many archaeological projects.

== Mailing list threads ==

* [http://thread.gmane.org/gmane.comp.gis.grass.user/27990 Who's using GRASS for archaeological applications?]

== Data exchange ==

* {{AddonCmd|v.in.ply}}: import of PLY format (3D)
* {{cmd|v.in.dxf}}: import of DXF format (2D and 3D)
* {{cmd|v.out.dxf}}: export of DXF format (2D and 3D)
* many other formats..

== Georeferencing ==

* Georeferencing of point clouds: get your data from an arbitrary coordinates system into real world projections: {{cmd|v.rectify|version=70}}. It also perform 3D transformation (affine and polynomial). Working even with very large point clouds (several million points in a few minutes).

== Image processing ==

* see [[Image processing]]
* [[LIDAR]]

== Visualization ==

* see [[:Category:Visualization]]

== See also ==

=== Bibliography ===
* Barton, C.M., Ullah, I. & Mitasova, H., 2010. [http://sagunto.la.asu.edu:8080/medlandweb/Barton_etal2010.pdf ''Computational modeling and neolithic socioecological dynamics: A case study from southwest Asia']'. Am antiquity, 75(2), 364-386.
* Barton, C.M., Ullah, I, & Bergin, S, 2010. [http://rsta.royalsocietypublishing.org.ezproxy1.lib.asu.edu/content/368/1931/5275.abstract "Land use, water and Mediterranean landscapes: modelling long-term dynamics of complex socio-ecological systems"]. Philosophical Transactions of the Royal Society A: Mathematical, Physical and Engineering Sciences, 368(1931), 5275 -5297. doi:10.1098/rsta.2010.0193
* M. Neteler, 2009: ''[http://www.slideshare.net/markusN/grass-and-osgeo-a-framework-for-archeology GRASS GIS and OSGeo: A framework for archeology]'' (Invited keynote). Quarto Workshop Italiano [http://www.archeo-foss.org/ "Open Source, Free Software e Open Format nei processi di ricerca archeologica"], CNR di Roma, 27-28 April 2009
* Conolly, J., Lake, M., 2006. Geographical Information Systems in Archaeology (Cambridge Manuals in Archaeology) [ [http://www.amazon.co.uk/Geographical-Information-Systems-Archaeology-Cambridge/dp/0521797446/ Book] ]
* A. Bezzi, L. Bezzi, D. Francisci, R. Gietl, 2006. ''L'utilizzo di Voxel in campo archeologico'', Geomatics workbooks 6 [ [http://geomatica.como.polimi.it/workbooks/n6/list.php PDF] ]

=== Sample archeological data sets ===

* [http://www.tuarc.trentu.ca/~aspweb/en/downloads.shtml Antikythera Survey Project (ASP)]

=== Some archaeological links related to GRASS ===

* http://wiki.iosa.it/ Quantitative Archaeology Wiki (check out the "Spatial Analysis" section)
* http://arc-team-open-research.blogspot.com/ - GRASS and Blender in archaeology
* http://arkygeek.blogspot.com/
* http://www.arc-team.com/wiki/doku.php - ArcheOS - The first GNU/Linux distribution for archaeology ([http://www.arc-team.com/archeos/wiki/doku.php?id=screenshots screenshots])
* [http://undine-lieberwirth.info/?page_id=8 Voxels and GRASS] in Archeology (animations)
* http://tdx.cat/TESIS_UB/AVAILABLE/TDX-0720109-092434/ - PhD Dissertation about conflict archaeology, with extensive use of GRASS and QGIS.
* http://medland.asu.edu - Mediterranean Landscape Dynamics Project. Dynamic surface process modeling in GRASS coupled with agent-based modeling of agricultural land-use

[[Category:Applications]]
[[Category:Documentation]]

Archeology

2012-01-15T20:58:18Z

⚠️Cmbarton: /* Some archaeological links related to GRASS */

GRASS GIS is used in many archaeological projects.

== Mailing list threads ==

* [http://thread.gmane.org/gmane.comp.gis.grass.user/27990 Who's using GRASS for archaeological applications?]

== Data exchange ==

* {{AddonCmd|v.in.ply}}: import of PLY format (3D)
* {{cmd|v.in.dxf}}: import of DXF format (2D and 3D)
* {{cmd|v.out.dxf}}: export of DXF format (2D and 3D)
* many other formats..

== Georeferencing ==

* Georeferencing of point clouds: get your data from an arbitrary coordinates system into real world projections: {{cmd|v.rectify|version=70}}. It also perform 3D transformation (affine and polynomial). Working even with very large point clouds (several million points in a few minutes).

== Image processing ==

* see [[Image processing]]
* [[LIDAR]]

== Visualization ==

* see [[:Category:Visualization]]

== See also ==

=== Bibliography ===
* Barton, C.M., Ullah, I. & Mitasova, H., 2010. ''Computational modeling and neolithic socioecological dynamics: A case study from southwest Asia''. Am antiquity, 75(2), 364-386. [ [http://sagunto.la.asu.edu:8080/medlandweb/Barton_etal2010.pdf PDF] ]
* M. Neteler, 2009: ''[http://www.slideshare.net/markusN/grass-and-osgeo-a-framework-for-archeology GRASS GIS and OSGeo: A framework for archeology]'' (Invited keynote). Quarto Workshop Italiano [http://www.archeo-foss.org/ "Open Source, Free Software e Open Format nei processi di ricerca archeologica"], CNR di Roma, 27-28 April 2009
* Conolly, J., Lake, M., 2006. Geographical Information Systems in Archaeology (Cambridge Manuals in Archaeology) [ [http://www.amazon.co.uk/Geographical-Information-Systems-Archaeology-Cambridge/dp/0521797446/ Book] ]
* A. Bezzi, L. Bezzi, D. Francisci, R. Gietl, 2006. ''L'utilizzo di Voxel in campo archeologico'', Geomatics workbooks 6 [ [http://geomatica.como.polimi.it/workbooks/n6/list.php PDF] ]

=== Sample archeological data sets ===

* [http://www.tuarc.trentu.ca/~aspweb/en/downloads.shtml Antikythera Survey Project (ASP)]

=== Some archaeological links related to GRASS ===

* http://wiki.iosa.it/ Quantitative Archaeology Wiki (check out the "Spatial Analysis" section)
* http://arc-team-open-research.blogspot.com/ - GRASS and Blender in archaeology
* http://arkygeek.blogspot.com/
* http://www.arc-team.com/wiki/doku.php - ArcheOS - The first GNU/Linux distribution for archaeology ([http://www.arc-team.com/archeos/wiki/doku.php?id=screenshots screenshots])
* [http://undine-lieberwirth.info/?page_id=8 Voxels and GRASS] in Archeology (animations)
* http://tdx.cat/TESIS_UB/AVAILABLE/TDX-0720109-092434/ - PhD Dissertation about conflict archaeology, with extensive use of GRASS and QGIS.
* http://medland.asu.edu - Mediterranean Landscape Dynamics Project. Dynamic surface process modeling in GRASS coupled with agent-based modeling of agricultural land-use

[[Category:Applications]]
[[Category:Documentation]]

AddOns

2011-07-02T05:04:09Z

⚠️Cmbarton: /* Spatial Analysis Tools */

This page contains references to user contributions and add-ons (the original GRASS GIS software can be downloaded [http://grass.osgeo.org/download/ here]).

__TOC__

== AddOns source code repository ==

The AddOns source code is hosted in [http://svn.osgeo.org/grass/grass-addons/ GRASS-AddOns SVN repository].

To checkout:

svn checkout <nowiki>https://svn.osgeo.org/grass/grass-addons/</nowiki> grass-addons

Please read [http://trac.osgeo.org/grass/wiki/HowToContribute#WriteaccesstotheGRASS-Addons-SVNrepository How to get write access to the GRASS-Addons-SVN repository] and contact the [http://lists.osgeo.org/mailman/listinfo/grass-dev grass-dev] mailing list if you would like to host your module there.

== Building and installing Addons ==

See the [[Compile and Install#Addons|compile and install]] wiki page.

In GRASS 6.4 and newer you can use the {{cmd|g.extension}} module, e.g. to install <tt>r.fuzzy.system</tt> run:

g.extension extension=r.fuzzy.system

To remove installed Addons run

g.extension extension=r.fuzzy.system operation=remove

== Adding something new ==

Please announce your add-on to the GRASS users' mailing list so that others may be aware of your work. Also please consider adding your module to one of the [[Applications]] pages.

=== Copyright and licensing information ===

''Please be sure to include copyright and licensing information in the header comments of your code so that others may know how they can use, extend, modify, and redistribute your work.''

e.g. at the top of a shell script:
<pre>
#!/bin/sh
############################################################################
#
# MODULE: v.in.e00
#
# AUTHOR(S): Markus Neteler, Otto Dassau
#
# PURPOSE: Import E00 data into a GRASS vector map
# Imports single and split E00 files (.e00, .e01, .e02 ...)
#
# COPYRIGHT: (c) 2004, 2005 GDF Hannover bR, http://www.gdf-hannover.de
#
# This program is free software under the GNU General Public
# License (>=v2). Read the file COPYING that comes with GRASS
# for details.
#
#############################################################################
#
# REQUIREMENTS:
# - avcimport: http://avce00.maptools.org

[script follows]
</pre>

=== Coding standards ===

Please have a look at our [http://grass.osgeo.org/grass63/source/SUBMITTING_SCRIPTS Shell script coding standards] before submitting here.

There are other coding standards given for modules written in C, Tcl/Tk, and Python''(?)'' located in the GRASS source code.

=== Documenting your code ===

You can have an help page template auto-generated by using the GRASS [[module command line parser | command line parser]] with the <tt>--html-description</tt> command line option. Please, see also the [http://grass.ibiblio.org/grass63/manuals/html63_user/g.parser.html g.parser help page]

== Miscellaneous Add-ons ==

* [http://trac.osgeo.org/grass/browser/grass-addons/misc/utm_which_zone utm_which_zone.sh] is a shell script to determine UTM zone from Lat/Lon input. Requires [http://www.octave.org Octave] or Matlab to be installed. A shell-only version is [http://dcalvelo.free.fr/grass/utm_which_zone_sh.sh available] which only requires awk. '''Authors''': Hamish Bowman (Octave part), Markus Neteler (shell script wrapper), Daniel Calvelo (sh+awk version)

* Perl scripts for converting data forth and back between Excel files and PostgreSQL: [http://dcalvelo.free.fr/grass/pg2xls.pl pg2xls.pl] reads data from PostgreSQL and produces an excel workbook; [http://dcalvelo.free.fr/grass/xls2sql.pl xls2sql.pl] reads excel files and outputs SQL statements to be fed into an RDBMS. Both scripts need modules from [http://www.cpan.org CPAN], especially [http://search.cpan.org/dist/Spreadsheet-ParseExcel/ Spreadsheet::ParseExcel] for xls2sql.pl and [http://search.cpan.org/~tmtm/Spreadsheet-WriteExcel-FromDB Spreadsheet::WriteExcel::FromDB] and its dependencies for pg2sql.pl. Check the source headers for more info. '''Authors:''' Daniel Calvelo (xls2sql.pl), Markus Neteler (pg2xls.pl)

* [http://dream.lrrl.arch.tu-muenchen.de/~wqual/perl/dbf2sql.tgz dbf2sql] is a Perl script for translating dbf-tables into a sql-command. dbf-tables are read using dbfdump-command from dbd-xbase-perl module ([http://search.cpan.org/~janpaz/DBD-XBase-0.241/ dbd::xbase] and [http://search.cpan.org/~jv/Getopt-Long-2.35/lib/Getopt/Long.pm getopt::long] have to be installed from CPAN first). There are problems, if the last column of the table contains characters. Suggestions for improvements welcome! '''Author:'''Wolfgang Qual

* [http://www.igc.usp.br/pessoais/guano/downloads/azimuth2.c azimuth2.c] is a small C program to calculate the azimuth and length of vector lines exported by GRASS-GIS as ASCII files (like this: v.out.ascii input=vector output=ascii format=standard). It is useful for create rose diagrams of lineament maps. Improvements on the original code after suggestions by Örs Téglásy, Hungary. '''Author:''' Carlos Henrique Grohmann

==GRASS 6.x (current)==

=== Vector add-ons ===

See also

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

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

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

Available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/vector/adehabitat

==== v.append ====

: [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.append v.append] is a shell script combining two vector files AND their associated attribute tables. The vector files should be of the same type and, for best results, should have identically formatted attribute tables.

: '''Author:''' Michael Barton

==== v.autokrige ====

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

: '''Author:''' Mathieu Grelier

==== v.breach ====

: [http://www.sieczka.org/programy_en.html v.breach] creates vector maps of lines and points of continously lowering elevation down the input watercourses, based on the input raster DEM.

: '''Author:''' Maciej Sieczka

==== v.colors ====

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

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

: [http://wiki.iosa.it/dokuwiki/spatial_analysis:feature_count v.count.points.sh] counts point features in areas, generates table good as input to d.vect.chart.

: '''Author:''' Stefano Costa

==== v.digatt ====

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

: '''Author:''' Andreas Philipp

==== v.dip ====

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

: '''Author:''' Marcin Slodkowski

==== v.flip ====

: [http://www.sieczka.org/programy_en.html v.flip] flips the direction of selected vector lines (redundant since GRASS 6.3 - there is "v.edit tool=flip").

: '''Author:''' Maciej Sieczka

==== v.group ====

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

: '''Author:''' Cedric Shock

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

: v.in.redwg imports DWG files into GRASS.

:'''Author:''' Rodrigo Rodrigues da Silva

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

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

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

:'''Author:''' Martin Landa

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

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

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

: '''Author:''' Hamish Bowman

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

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

:'''Author:''' Benjamin Ducke

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

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

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

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

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

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

: '''Author:''' Trevor Wiens

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

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

:'''Author:''' Hamish Bowman

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

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

: '''Author:''' Huidae Cho

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

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

: '''Author:''' Mathieu Grelier

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

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

: '''Author:''' Jannis Achstetter

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

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

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

: '''Author:''' Hamish Bowman

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

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

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

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

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

: '''Author:''' Hamish Bowman

==== v.krige ====

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

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

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

==== Spatial Analysis Tools ====

===== v.lda.py =====

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

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

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

: [http://www.sieczka.org/programy_en.html v.line.center] creates a points vector map with each point located in the middle of the length of the input vector line.

: '''Author:''' Maciej Sieczka

==== v.lmeasure ====

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

: '''Author:''' Mats Schuh

==== v.mkhexgrid ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.mkhexgrid v.mkhexgrid] is a python script that creates a hexagonal grid the size of the selected region using user specified side lengths.

: '''Author:''' Trevor Wiens

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Hamish Bowman

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

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

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

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

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

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

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

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

: '''Author:''' Trevor Wiens

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

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

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

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

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

: '''Author:''' Hamish Bowman

==== v.profile ====

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

: '''Author:''' Maris Nartiss

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

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

: '''Author:''' Hamish Bowman

==== v.rasterbounds ====

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

: '''Author:''' Jachym Cepicky

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

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

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

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

: '''Author:''' Trevor Wiens

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

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

: '''Author:''' Eric Patton

==== v.selmany ====

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

: '''Author:''' Vincent Bain

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Giovanni Allegri

==== v.surf.krige [deprecated: use v.autokrige instead] ====

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

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

==== v.strahler ====

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

: '''Author:''' Florian Kindl. Available via SVN:

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

==== v.swathwidth ====

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

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

==== v.thickness ====

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

: '''Author:''' Marcin Slodkowski

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

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

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

==== v.trees3d ====

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

: '''Author:''' Jachym Cepicky

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

: '''Author:''' Jaime Carrera

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

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

: '''Author:''' Hamish Bowman

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

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

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

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

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.vect.stats v.vect.stats] counts the number of points falling into each polygon and optionally calculates statistics from numeric point attributes for each polygon. v.vect.stats is a C module and works with GRASS 6.4 and higher (see enclosed patches for 6.5 and 7.0).

: '''Author:''' Markus Metz

==== AniMove ====

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

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

==== Utilities ====

===== Shapemerge =====

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

:'''Authors:''' Perrygeo

=== Raster add-ons ===

See also

svn co <nowiki>https://svn.osgeo.org/grass/grass-addons/raster</nowiki>

==== Raplat ====

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

* Documentation: http://commsys.ijs.si/en/component/content/article/54-software/149-user-manual
* Software: http://commsys.ijs.si/en/software/grass-raplat

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

==== r.area ====

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

: '''Author:''' Jarek Jasiewicz

==== r.basin ====

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

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

Available via SVN:

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

==== r.bilateral ====

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

: '''Author:''' Jachym Cepicky

==== r.broscoe ====

r.broscoe.sh calculates waerden test and t test statistics for some values of threshold area on a single basin, according to A.J.Broscoe theory (1959).
See v.strahler package

Available via SVN:

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

==== r.boxcount ====

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

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

Available via SVN:

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

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

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

:'''Author:''' Benjamin Ducke

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

==== r.clump2 ====

: [https://trac.osgeo.org/grass/browser/grass-addons/raster/r.clump2 r.clump2] is a C module similar to r.clump. Differences are: diagonally adjacent cells are also clumped but can be excluded, NULL (nodata) cells are always excluded, and selective clumping with start coordinates is supported.

: '''Author:''' Markus Metz

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

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Authors:''' Mathieu Grelier

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

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

==== r.convergence ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.convergence r.convergence] calculate topographic convergence index, useful to detect lineamets represented by chanell/ridge system

: '''Author:''' Jarek Jasiewicz

==== r.cpt2grass ====

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

: '''Author:''' Hamish Bowman

==== r.csr ====

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

: '''Author:''' Eric Patton

==== r.cva ====

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

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

==== r.denoise ====

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

: '''Author:''' John Stevenson

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

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

: '''Author:''' Hamish Bowman

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

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

==== r.eucdist ====

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

: '''Author:''' David Finlayson

==== r.fragment ====

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

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

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

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

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

==== r.game_of_life ====

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

: '''Author:''' Hamish Bowman

==== r.gauss ====

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

:'''Author:''' Jachym Cepicky

==== r.gradgrid4 ====

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

: '''Author:''' Martin Mergili

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

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

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

Available via SVN:

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

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

: [http://blogs.tekmap.ns.ca/archives/458 r.in.mb] is a "GRASS/[[MB-System]] program designed to import ''mbio'' compatible multibeam sonar data directly into the GRASS GIS. The program is a modified version of {{cmd|r.in.xyz}}. Instead of reading an ASCII XYZ file, ''r.in.mb'' reads an MB-System compatible list file." It can do automatic reprojection and minor hole filling. The default is to import bathymetry data, but optionally amplitude or sidescan sonar data can be loaded instead.

: '''Author:''' Bob Covill

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

: [http://www-pool.math.tu-berlin.de/~soeren/grass/modules/ r.in.onearth] for download and import satellite images direct from the NASA onearth WMS server into GRASS.

: '''Author:''' Soeren Gebbert

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

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

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

Available via SVN:

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

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

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

: '''Author:''' Jachym Cepicky

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

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

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

==== r.isoregions ====

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

: '''Authors:''' Mathieu Grelier

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

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

: '''Author:''' David Finlayson

==== r.ipso ====

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

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

Available via SVN:

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

==== r.li ====

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

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

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

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

: '''Author:''' Jachym Cepicky

==== r.mandelbrot ====

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

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

==== mcda====

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

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

Available via SVN:

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

==== r.mlv ====

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

: '''Author:''' Jachym Cepicky

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

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

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

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

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

: '''Author:''' Giovanni Allegri

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

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

: '''Author:''' Tomas Cebecauer

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

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

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

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

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

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

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Hamish Bowman

==== r.pack ====

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

: '''Author:''' Hamish Bowman

==== r.pi ====

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

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

==== r.prominence ====

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

: '''Author:''' Benjamin Ducke

Available via SVN:

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

==== r.refine ====

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

==== r.rifs ====

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

: '''Author:''' Mark Lake

==== r.roughness ====

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

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

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

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

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

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

Available via SVN:

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

==== r.roughset ====

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

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

Available via SVN:

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

==== r.seg ====

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

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

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

: '''Author''' Alfonso Vitti

==== r.smoothpatch ====

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

: '''Author:''' David Finlayson

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

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

:'''Author:''' Gianluca Massei

Available via SVN:

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

==== r.stack ====

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

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

: '''Author:''' Markus Metz

Available via SVN:

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

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

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.order r.stream.order] orders stream network outputed by r.watershed or r.stream.extract according Sthrahler, Shreve, Horton and Hack ordering systems. It require as input stream and direction map and optionally accumulation map. It handle both SFD nad MFD modes but all data must come from the same procedure.

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

Available via SVN:

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

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

: [http://www.sieczka.org/programy_en.html r.surf.nnbathy] interpolates a surface from a raster input using Pavel Sakov's [http://code.google.com/p/nn-c/ nn] natural neighbor interpolation library. Provides triangulation, Sibson natural neighbor interpolation and non-Sibsonian interpolation.

: '''Author:''' Maciej Sieczka

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

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

: '''Author:''' Hamish Bowman

==== r.terracost ====

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

Available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.terracost

==== r.tileset ====

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

==== r.traveltime ====

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

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

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

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.univar.zonal r.univar.zonal] is similar to r.univar, but calculates statistics separately for each category(zone) present in the separate input map used to define zones (zonal statistics). The output can be like the one of r.univar or in easier to read table format and can be written to a file. This addon is only needed for GRASS 6.4, its functionality has been added to r.univar in 6.5 and 7.

: '''Author:''' Markus Metz

Available via SVN:

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

==== r.viewshed ====

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

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

Available via SVN:

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

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

==== r.wavelets ====

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

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

==== r.wf ====

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

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

Available via SVN:

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

==== r.xtent ====

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

:'''Author:''' Benjamin Ducke

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

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

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

: '''Author:''' Jachym Cepicky

==== GIPE ====

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==== HydroFOSS ====

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

: '''Author:''' Massimiliano Cannata

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

==== Hikereport ====

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

: '''Author:''' Stefano Negri

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

=== Misc add-ons===

==== m.eigensystem ====

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

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

: '''Author:''' Michael Shapiro

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

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

: '''Author:''' Markus Neteler. Available via SVN:

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

===General add-ons===

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

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

: '''Author:''' Markus Neteler

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

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

: '''Author:''' Otto Dassau

==== Readline completion ====

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

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

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

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

: '''Author:''' Hamish Bowman

==== g.linke_by_day ====

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

: '''Author:''' Hamish Bowman

==== g.xlist ====

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

: '''Author:''' Huidae Cho

==== g.xremove ====

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

: '''Author:''' Huidae Cho

=== Imagery add-ons ===

See also

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

==== GIPE ====

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

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

: '''Author:''' Yann Chemin

==== i.homography ====

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

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

: '''Author:''' Daniel Grasso, Bolzano, Italy, based on code written by Stefano Merler, ITC-irst, Italy

==== i.linespoints ====

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

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

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

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

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

Available also in GRASS 7.

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

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

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

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

Available also in GRASS 7.

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

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

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

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

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

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

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

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Georg Kaspar

==== i.pr ====

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

: '''Author:''' Stefano Merler. Available via SVN:

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

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

: Spectral Angle mapping

: '''Author:''' Markus Neteler. Available via SVN:

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

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

: Spectral unmixing

: '''Author:''' Markus Neteler. Available via SVN:

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

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

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.topo.corr

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

==== i.warp ====

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

: '''Author:''' Hamish Bowman

=== Display add-ons ===

See also

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

==== d.barb ====

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Huidae Cho

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

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

: '''Author:''' Hamish Bowman

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

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

==== d.frontline ====

: [http://cloud.github.com/downloads/amuriy/GRASS-scripts/d.frontline d.frontline] is a shell script that draws frontlines on the graphics monitor using ''d.graph'' module and different types of symbols. Also it optionally saves frontline graphics to ''d.graph'' commands file and/or ''ps.map'' file (for later use with the "read" ''ps.map'' instruction)

: '''Author:''' Alexander Muriy

==== d.hyperlink ====

: [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/d.hyperlink.tar.bz2 d.hyperlink] is an interactive shell script that allows the viewing of hyperlinked images from a vector's attribute table in an external image viewer. Queries can be made via SQL statements or interactive mouse-clicking. The attribute table must be pre-populated with a column containing the image to link the vector to; the user also specifies the image folder in the current MAPSET where the images are located. The script currently supports gimp, Eye of Gnome, gthumb, gpdf, and Inkscape image viewers.

: '''Author: '''Eric Patton

==== d.mark ====

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Hamish Bowman

==== d.stations ====

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

: '''Author:''' Hamish Bowman

==== d.varea ====

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

: '''Author:''' Hamish Bowman

==== pd-GRASS ====

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

: '''Author:''' Alex Sorokine

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

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

=== Postscript add-ons ===

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

==== ps.atlas ====

: [http://les-ejk.cz/programs/grass/ps.atlas ps.atlas] is a shell script that makes more maps on current region according to input *.psmap file. General map can be stored as vector file. The resulting *.eps maps can be automatically converted to *.pdf files.

: '''Author:''' Jachym Cepicky

==== ps.output ====

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

: '''Author:''' Jorge Tizado

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

* Hatches for ps.map's vareas

=== wxGUI add-ons ===

===GRASS and UMN Mapserver===

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

==GRASS 5.x (old)==

===Vector add-ons===

* See here: http://grass.osgeo.org/download/addons.php

===Raster add-ons===

* See here: http://grass.osgeo.org/download/addons.php

* [http://www.valledemexico.ambitiouslemon.com/gwmodelling.html r.gmtg] The groundwater modelling tool for grass. A module to use MODFLOW within GRASS. '''Author''': Jaime Carrera

* [http://www.bowdoin.edu/~ltoma/research.html r.terracost] Scalable approach for computing least-cost-path surfaces on massive grid terrains. For GRASS 5.3. '''Lead author''': Laura Toma
:Newer version available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.terracost

==GRASS 4.x (very old)==

===Raster add-ons===

* MAGICAL Software: The MAGICAL software comprises a suite of three programs that provide a multi-agent simulation extension for the GRASS GIS software. http://www.ucl.ac.uk/~tcrnmar/simulation/magical/magical.html

[[Category:Community]]
[[Category:Development]]
[[Category:Documentation]]
[[Category:Installation]]

AddOns

2011-07-02T05:03:48Z

⚠️Cmbarton: /* Spatial Analysis Tools */

This page contains references to user contributions and add-ons (the original GRASS GIS software can be downloaded [http://grass.osgeo.org/download/ here]).

__TOC__

== AddOns source code repository ==

The AddOns source code is hosted in [http://svn.osgeo.org/grass/grass-addons/ GRASS-AddOns SVN repository].

To checkout:

svn checkout <nowiki>https://svn.osgeo.org/grass/grass-addons/</nowiki> grass-addons

Please read [http://trac.osgeo.org/grass/wiki/HowToContribute#WriteaccesstotheGRASS-Addons-SVNrepository How to get write access to the GRASS-Addons-SVN repository] and contact the [http://lists.osgeo.org/mailman/listinfo/grass-dev grass-dev] mailing list if you would like to host your module there.

== Building and installing Addons ==

See the [[Compile and Install#Addons|compile and install]] wiki page.

In GRASS 6.4 and newer you can use the {{cmd|g.extension}} module, e.g. to install <tt>r.fuzzy.system</tt> run:

g.extension extension=r.fuzzy.system

To remove installed Addons run

g.extension extension=r.fuzzy.system operation=remove

== Adding something new ==

Please announce your add-on to the GRASS users' mailing list so that others may be aware of your work. Also please consider adding your module to one of the [[Applications]] pages.

=== Copyright and licensing information ===

''Please be sure to include copyright and licensing information in the header comments of your code so that others may know how they can use, extend, modify, and redistribute your work.''

e.g. at the top of a shell script:
<pre>
#!/bin/sh
############################################################################
#
# MODULE: v.in.e00
#
# AUTHOR(S): Markus Neteler, Otto Dassau
#
# PURPOSE: Import E00 data into a GRASS vector map
# Imports single and split E00 files (.e00, .e01, .e02 ...)
#
# COPYRIGHT: (c) 2004, 2005 GDF Hannover bR, http://www.gdf-hannover.de
#
# This program is free software under the GNU General Public
# License (>=v2). Read the file COPYING that comes with GRASS
# for details.
#
#############################################################################
#
# REQUIREMENTS:
# - avcimport: http://avce00.maptools.org

[script follows]
</pre>

=== Coding standards ===

Please have a look at our [http://grass.osgeo.org/grass63/source/SUBMITTING_SCRIPTS Shell script coding standards] before submitting here.

There are other coding standards given for modules written in C, Tcl/Tk, and Python''(?)'' located in the GRASS source code.

=== Documenting your code ===

You can have an help page template auto-generated by using the GRASS [[module command line parser | command line parser]] with the <tt>--html-description</tt> command line option. Please, see also the [http://grass.ibiblio.org/grass63/manuals/html63_user/g.parser.html g.parser help page]

== Miscellaneous Add-ons ==

* [http://trac.osgeo.org/grass/browser/grass-addons/misc/utm_which_zone utm_which_zone.sh] is a shell script to determine UTM zone from Lat/Lon input. Requires [http://www.octave.org Octave] or Matlab to be installed. A shell-only version is [http://dcalvelo.free.fr/grass/utm_which_zone_sh.sh available] which only requires awk. '''Authors''': Hamish Bowman (Octave part), Markus Neteler (shell script wrapper), Daniel Calvelo (sh+awk version)

* Perl scripts for converting data forth and back between Excel files and PostgreSQL: [http://dcalvelo.free.fr/grass/pg2xls.pl pg2xls.pl] reads data from PostgreSQL and produces an excel workbook; [http://dcalvelo.free.fr/grass/xls2sql.pl xls2sql.pl] reads excel files and outputs SQL statements to be fed into an RDBMS. Both scripts need modules from [http://www.cpan.org CPAN], especially [http://search.cpan.org/dist/Spreadsheet-ParseExcel/ Spreadsheet::ParseExcel] for xls2sql.pl and [http://search.cpan.org/~tmtm/Spreadsheet-WriteExcel-FromDB Spreadsheet::WriteExcel::FromDB] and its dependencies for pg2sql.pl. Check the source headers for more info. '''Authors:''' Daniel Calvelo (xls2sql.pl), Markus Neteler (pg2xls.pl)

* [http://dream.lrrl.arch.tu-muenchen.de/~wqual/perl/dbf2sql.tgz dbf2sql] is a Perl script for translating dbf-tables into a sql-command. dbf-tables are read using dbfdump-command from dbd-xbase-perl module ([http://search.cpan.org/~janpaz/DBD-XBase-0.241/ dbd::xbase] and [http://search.cpan.org/~jv/Getopt-Long-2.35/lib/Getopt/Long.pm getopt::long] have to be installed from CPAN first). There are problems, if the last column of the table contains characters. Suggestions for improvements welcome! '''Author:'''Wolfgang Qual

* [http://www.igc.usp.br/pessoais/guano/downloads/azimuth2.c azimuth2.c] is a small C program to calculate the azimuth and length of vector lines exported by GRASS-GIS as ASCII files (like this: v.out.ascii input=vector output=ascii format=standard). It is useful for create rose diagrams of lineament maps. Improvements on the original code after suggestions by Örs Téglásy, Hungary. '''Author:''' Carlos Henrique Grohmann

==GRASS 6.x (current)==

=== Vector add-ons ===

See also

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

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

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

Available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/vector/adehabitat

==== v.append ====

: [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.append v.append] is a shell script combining two vector files AND their associated attribute tables. The vector files should be of the same type and, for best results, should have identically formatted attribute tables.

: '''Author:''' Michael Barton

==== v.autokrige ====

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

: '''Author:''' Mathieu Grelier

==== v.breach ====

: [http://www.sieczka.org/programy_en.html v.breach] creates vector maps of lines and points of continously lowering elevation down the input watercourses, based on the input raster DEM.

: '''Author:''' Maciej Sieczka

==== v.colors ====

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

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

: [http://wiki.iosa.it/dokuwiki/spatial_analysis:feature_count v.count.points.sh] counts point features in areas, generates table good as input to d.vect.chart.

: '''Author:''' Stefano Costa

==== v.digatt ====

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

: '''Author:''' Andreas Philipp

==== v.dip ====

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

: '''Author:''' Marcin Slodkowski

==== v.flip ====

: [http://www.sieczka.org/programy_en.html v.flip] flips the direction of selected vector lines (redundant since GRASS 6.3 - there is "v.edit tool=flip").

: '''Author:''' Maciej Sieczka

==== v.group ====

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

: '''Author:''' Cedric Shock

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

: v.in.redwg imports DWG files into GRASS.

:'''Author:''' Rodrigo Rodrigues da Silva

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

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

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

:'''Author:''' Martin Landa

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

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

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

: '''Author:''' Hamish Bowman

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

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

:'''Author:''' Benjamin Ducke

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

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

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

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

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

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

: '''Author:''' Trevor Wiens

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

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

:'''Author:''' Hamish Bowman

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

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

: '''Author:''' Huidae Cho

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

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

: '''Author:''' Mathieu Grelier

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

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

: '''Author:''' Jannis Achstetter

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

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

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

: '''Author:''' Hamish Bowman

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

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

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

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

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

: '''Author:''' Hamish Bowman

==== v.krige ====

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

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

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

==== Spatial Analysis Tools ====

\t===== v.lda.py =====

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

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

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

: [http://www.sieczka.org/programy_en.html v.line.center] creates a points vector map with each point located in the middle of the length of the input vector line.

: '''Author:''' Maciej Sieczka

==== v.lmeasure ====

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

: '''Author:''' Mats Schuh

==== v.mkhexgrid ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.mkhexgrid v.mkhexgrid] is a python script that creates a hexagonal grid the size of the selected region using user specified side lengths.

: '''Author:''' Trevor Wiens

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Hamish Bowman

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

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

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

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

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

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

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

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

: '''Author:''' Trevor Wiens

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

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

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

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

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

: '''Author:''' Hamish Bowman

==== v.profile ====

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

: '''Author:''' Maris Nartiss

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

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

: '''Author:''' Hamish Bowman

==== v.rasterbounds ====

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

: '''Author:''' Jachym Cepicky

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

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

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

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

: '''Author:''' Trevor Wiens

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

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

: '''Author:''' Eric Patton

==== v.selmany ====

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

: '''Author:''' Vincent Bain

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Giovanni Allegri

==== v.surf.krige [deprecated: use v.autokrige instead] ====

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

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

==== v.strahler ====

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

: '''Author:''' Florian Kindl. Available via SVN:

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

==== v.swathwidth ====

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

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

==== v.thickness ====

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

: '''Author:''' Marcin Slodkowski

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

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

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

==== v.trees3d ====

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

: '''Author:''' Jachym Cepicky

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

: '''Author:''' Jaime Carrera

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

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

: '''Author:''' Hamish Bowman

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

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

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

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

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.vect.stats v.vect.stats] counts the number of points falling into each polygon and optionally calculates statistics from numeric point attributes for each polygon. v.vect.stats is a C module and works with GRASS 6.4 and higher (see enclosed patches for 6.5 and 7.0).

: '''Author:''' Markus Metz

==== AniMove ====

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

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

==== Utilities ====

===== Shapemerge =====

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

:'''Authors:''' Perrygeo

=== Raster add-ons ===

See also

svn co <nowiki>https://svn.osgeo.org/grass/grass-addons/raster</nowiki>

==== Raplat ====

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

* Documentation: http://commsys.ijs.si/en/component/content/article/54-software/149-user-manual
* Software: http://commsys.ijs.si/en/software/grass-raplat

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

==== r.area ====

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

: '''Author:''' Jarek Jasiewicz

==== r.basin ====

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

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

Available via SVN:

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

==== r.bilateral ====

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

: '''Author:''' Jachym Cepicky

==== r.broscoe ====

r.broscoe.sh calculates waerden test and t test statistics for some values of threshold area on a single basin, according to A.J.Broscoe theory (1959).
See v.strahler package

Available via SVN:

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

==== r.boxcount ====

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

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

Available via SVN:

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

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

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

:'''Author:''' Benjamin Ducke

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

==== r.clump2 ====

: [https://trac.osgeo.org/grass/browser/grass-addons/raster/r.clump2 r.clump2] is a C module similar to r.clump. Differences are: diagonally adjacent cells are also clumped but can be excluded, NULL (nodata) cells are always excluded, and selective clumping with start coordinates is supported.

: '''Author:''' Markus Metz

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

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Authors:''' Mathieu Grelier

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

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

==== r.convergence ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.convergence r.convergence] calculate topographic convergence index, useful to detect lineamets represented by chanell/ridge system

: '''Author:''' Jarek Jasiewicz

==== r.cpt2grass ====

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

: '''Author:''' Hamish Bowman

==== r.csr ====

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

: '''Author:''' Eric Patton

==== r.cva ====

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

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

==== r.denoise ====

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

: '''Author:''' John Stevenson

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

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

: '''Author:''' Hamish Bowman

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

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

==== r.eucdist ====

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

: '''Author:''' David Finlayson

==== r.fragment ====

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

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

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

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

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

==== r.game_of_life ====

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

: '''Author:''' Hamish Bowman

==== r.gauss ====

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

:'''Author:''' Jachym Cepicky

==== r.gradgrid4 ====

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

: '''Author:''' Martin Mergili

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

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

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

Available via SVN:

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

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

: [http://blogs.tekmap.ns.ca/archives/458 r.in.mb] is a "GRASS/[[MB-System]] program designed to import ''mbio'' compatible multibeam sonar data directly into the GRASS GIS. The program is a modified version of {{cmd|r.in.xyz}}. Instead of reading an ASCII XYZ file, ''r.in.mb'' reads an MB-System compatible list file." It can do automatic reprojection and minor hole filling. The default is to import bathymetry data, but optionally amplitude or sidescan sonar data can be loaded instead.

: '''Author:''' Bob Covill

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

: [http://www-pool.math.tu-berlin.de/~soeren/grass/modules/ r.in.onearth] for download and import satellite images direct from the NASA onearth WMS server into GRASS.

: '''Author:''' Soeren Gebbert

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

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

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

Available via SVN:

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

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

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

: '''Author:''' Jachym Cepicky

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

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

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

==== r.isoregions ====

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

: '''Authors:''' Mathieu Grelier

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

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

: '''Author:''' David Finlayson

==== r.ipso ====

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

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

Available via SVN:

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

==== r.li ====

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

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

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

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

: '''Author:''' Jachym Cepicky

==== r.mandelbrot ====

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

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

==== mcda====

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

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

Available via SVN:

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

==== r.mlv ====

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

: '''Author:''' Jachym Cepicky

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

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

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

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

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

: '''Author:''' Giovanni Allegri

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

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

: '''Author:''' Tomas Cebecauer

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

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

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

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

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

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

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Hamish Bowman

==== r.pack ====

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

: '''Author:''' Hamish Bowman

==== r.pi ====

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

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

==== r.prominence ====

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

: '''Author:''' Benjamin Ducke

Available via SVN:

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

==== r.refine ====

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

==== r.rifs ====

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

: '''Author:''' Mark Lake

==== r.roughness ====

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

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

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

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

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

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

Available via SVN:

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

==== r.roughset ====

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

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

Available via SVN:

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

==== r.seg ====

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

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

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

: '''Author''' Alfonso Vitti

==== r.smoothpatch ====

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

: '''Author:''' David Finlayson

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

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

:'''Author:''' Gianluca Massei

Available via SVN:

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

==== r.stack ====

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

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

: '''Author:''' Markus Metz

Available via SVN:

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

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

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.order r.stream.order] orders stream network outputed by r.watershed or r.stream.extract according Sthrahler, Shreve, Horton and Hack ordering systems. It require as input stream and direction map and optionally accumulation map. It handle both SFD nad MFD modes but all data must come from the same procedure.

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

Available via SVN:

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

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

: [http://www.sieczka.org/programy_en.html r.surf.nnbathy] interpolates a surface from a raster input using Pavel Sakov's [http://code.google.com/p/nn-c/ nn] natural neighbor interpolation library. Provides triangulation, Sibson natural neighbor interpolation and non-Sibsonian interpolation.

: '''Author:''' Maciej Sieczka

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

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

: '''Author:''' Hamish Bowman

==== r.terracost ====

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

Available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.terracost

==== r.tileset ====

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

==== r.traveltime ====

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

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

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

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.univar.zonal r.univar.zonal] is similar to r.univar, but calculates statistics separately for each category(zone) present in the separate input map used to define zones (zonal statistics). The output can be like the one of r.univar or in easier to read table format and can be written to a file. This addon is only needed for GRASS 6.4, its functionality has been added to r.univar in 6.5 and 7.

: '''Author:''' Markus Metz

Available via SVN:

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

==== r.viewshed ====

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

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

Available via SVN:

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

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

==== r.wavelets ====

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

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

==== r.wf ====

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

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

Available via SVN:

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

==== r.xtent ====

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

:'''Author:''' Benjamin Ducke

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

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

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

: '''Author:''' Jachym Cepicky

==== GIPE ====

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==== HydroFOSS ====

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

: '''Author:''' Massimiliano Cannata

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

==== Hikereport ====

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

: '''Author:''' Stefano Negri

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

=== Misc add-ons===

==== m.eigensystem ====

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

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

: '''Author:''' Michael Shapiro

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

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

: '''Author:''' Markus Neteler. Available via SVN:

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

===General add-ons===

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

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

: '''Author:''' Markus Neteler

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

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

: '''Author:''' Otto Dassau

==== Readline completion ====

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

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

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

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

: '''Author:''' Hamish Bowman

==== g.linke_by_day ====

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

: '''Author:''' Hamish Bowman

==== g.xlist ====

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

: '''Author:''' Huidae Cho

==== g.xremove ====

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

: '''Author:''' Huidae Cho

=== Imagery add-ons ===

See also

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

==== GIPE ====

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

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

: '''Author:''' Yann Chemin

==== i.homography ====

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

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

: '''Author:''' Daniel Grasso, Bolzano, Italy, based on code written by Stefano Merler, ITC-irst, Italy

==== i.linespoints ====

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

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

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

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

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

Available also in GRASS 7.

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

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

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

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

Available also in GRASS 7.

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

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

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

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

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

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

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

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Georg Kaspar

==== i.pr ====

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

: '''Author:''' Stefano Merler. Available via SVN:

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

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

: Spectral Angle mapping

: '''Author:''' Markus Neteler. Available via SVN:

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

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

: Spectral unmixing

: '''Author:''' Markus Neteler. Available via SVN:

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

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

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.topo.corr

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

==== i.warp ====

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

: '''Author:''' Hamish Bowman

=== Display add-ons ===

See also

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

==== d.barb ====

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Huidae Cho

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

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

: '''Author:''' Hamish Bowman

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

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

==== d.frontline ====

: [http://cloud.github.com/downloads/amuriy/GRASS-scripts/d.frontline d.frontline] is a shell script that draws frontlines on the graphics monitor using ''d.graph'' module and different types of symbols. Also it optionally saves frontline graphics to ''d.graph'' commands file and/or ''ps.map'' file (for later use with the "read" ''ps.map'' instruction)

: '''Author:''' Alexander Muriy

==== d.hyperlink ====

: [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/d.hyperlink.tar.bz2 d.hyperlink] is an interactive shell script that allows the viewing of hyperlinked images from a vector's attribute table in an external image viewer. Queries can be made via SQL statements or interactive mouse-clicking. The attribute table must be pre-populated with a column containing the image to link the vector to; the user also specifies the image folder in the current MAPSET where the images are located. The script currently supports gimp, Eye of Gnome, gthumb, gpdf, and Inkscape image viewers.

: '''Author: '''Eric Patton

==== d.mark ====

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Hamish Bowman

==== d.stations ====

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

: '''Author:''' Hamish Bowman

==== d.varea ====

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

: '''Author:''' Hamish Bowman

==== pd-GRASS ====

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

: '''Author:''' Alex Sorokine

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

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

=== Postscript add-ons ===

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

==== ps.atlas ====

: [http://les-ejk.cz/programs/grass/ps.atlas ps.atlas] is a shell script that makes more maps on current region according to input *.psmap file. General map can be stored as vector file. The resulting *.eps maps can be automatically converted to *.pdf files.

: '''Author:''' Jachym Cepicky

==== ps.output ====

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

: '''Author:''' Jorge Tizado

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

* Hatches for ps.map's vareas

=== wxGUI add-ons ===

===GRASS and UMN Mapserver===

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

==GRASS 5.x (old)==

===Vector add-ons===

* See here: http://grass.osgeo.org/download/addons.php

===Raster add-ons===

* See here: http://grass.osgeo.org/download/addons.php

* [http://www.valledemexico.ambitiouslemon.com/gwmodelling.html r.gmtg] The groundwater modelling tool for grass. A module to use MODFLOW within GRASS. '''Author''': Jaime Carrera

* [http://www.bowdoin.edu/~ltoma/research.html r.terracost] Scalable approach for computing least-cost-path surfaces on massive grid terrains. For GRASS 5.3. '''Lead author''': Laura Toma
:Newer version available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.terracost

==GRASS 4.x (very old)==

===Raster add-ons===

* MAGICAL Software: The MAGICAL software comprises a suite of three programs that provide a multi-agent simulation extension for the GRASS GIS software. http://www.ucl.ac.uk/~tcrnmar/simulation/magical/magical.html

[[Category:Community]]
[[Category:Development]]
[[Category:Documentation]]
[[Category:Installation]]

AddOns

2011-07-02T05:03:15Z

⚠️Cmbarton: /* Spatial Analysis Tools */

AddOns

2011-07-02T04:57:11Z

⚠️Cmbarton: /* v.lda.py */

This page contains references to user contributions and add-ons (the original GRASS GIS software can be downloaded [http://grass.osgeo.org/download/ here]).

__TOC__

== AddOns source code repository ==

The AddOns source code is hosted in [http://svn.osgeo.org/grass/grass-addons/ GRASS-AddOns SVN repository].

To checkout:

svn checkout <nowiki>https://svn.osgeo.org/grass/grass-addons/</nowiki> grass-addons

Please read [http://trac.osgeo.org/grass/wiki/HowToContribute#WriteaccesstotheGRASS-Addons-SVNrepository How to get write access to the GRASS-Addons-SVN repository] and contact the [http://lists.osgeo.org/mailman/listinfo/grass-dev grass-dev] mailing list if you would like to host your module there.

== Building and installing Addons ==

See the [[Compile and Install#Addons|compile and install]] wiki page.

In GRASS 6.4 and newer you can use the {{cmd|g.extension}} module, e.g. to install <tt>r.fuzzy.system</tt> run:

g.extension extension=r.fuzzy.system

To remove installed Addons run

g.extension extension=r.fuzzy.system operation=remove

== Adding something new ==

Please announce your add-on to the GRASS users' mailing list so that others may be aware of your work. Also please consider adding your module to one of the [[Applications]] pages.

=== Copyright and licensing information ===

''Please be sure to include copyright and licensing information in the header comments of your code so that others may know how they can use, extend, modify, and redistribute your work.''

e.g. at the top of a shell script:
<pre>
#!/bin/sh
############################################################################
#
# MODULE: v.in.e00
#
# AUTHOR(S): Markus Neteler, Otto Dassau
#
# PURPOSE: Import E00 data into a GRASS vector map
# Imports single and split E00 files (.e00, .e01, .e02 ...)
#
# COPYRIGHT: (c) 2004, 2005 GDF Hannover bR, http://www.gdf-hannover.de
#
# This program is free software under the GNU General Public
# License (>=v2). Read the file COPYING that comes with GRASS
# for details.
#
#############################################################################
#
# REQUIREMENTS:
# - avcimport: http://avce00.maptools.org

[script follows]
</pre>

=== Coding standards ===

Please have a look at our [http://grass.osgeo.org/grass63/source/SUBMITTING_SCRIPTS Shell script coding standards] before submitting here.

There are other coding standards given for modules written in C, Tcl/Tk, and Python''(?)'' located in the GRASS source code.

=== Documenting your code ===

You can have an help page template auto-generated by using the GRASS [[module command line parser | command line parser]] with the <tt>--html-description</tt> command line option. Please, see also the [http://grass.ibiblio.org/grass63/manuals/html63_user/g.parser.html g.parser help page]

== Miscellaneous Add-ons ==

* [http://trac.osgeo.org/grass/browser/grass-addons/misc/utm_which_zone utm_which_zone.sh] is a shell script to determine UTM zone from Lat/Lon input. Requires [http://www.octave.org Octave] or Matlab to be installed. A shell-only version is [http://dcalvelo.free.fr/grass/utm_which_zone_sh.sh available] which only requires awk. '''Authors''': Hamish Bowman (Octave part), Markus Neteler (shell script wrapper), Daniel Calvelo (sh+awk version)

* Perl scripts for converting data forth and back between Excel files and PostgreSQL: [http://dcalvelo.free.fr/grass/pg2xls.pl pg2xls.pl] reads data from PostgreSQL and produces an excel workbook; [http://dcalvelo.free.fr/grass/xls2sql.pl xls2sql.pl] reads excel files and outputs SQL statements to be fed into an RDBMS. Both scripts need modules from [http://www.cpan.org CPAN], especially [http://search.cpan.org/dist/Spreadsheet-ParseExcel/ Spreadsheet::ParseExcel] for xls2sql.pl and [http://search.cpan.org/~tmtm/Spreadsheet-WriteExcel-FromDB Spreadsheet::WriteExcel::FromDB] and its dependencies for pg2sql.pl. Check the source headers for more info. '''Authors:''' Daniel Calvelo (xls2sql.pl), Markus Neteler (pg2xls.pl)

* [http://dream.lrrl.arch.tu-muenchen.de/~wqual/perl/dbf2sql.tgz dbf2sql] is a Perl script for translating dbf-tables into a sql-command. dbf-tables are read using dbfdump-command from dbd-xbase-perl module ([http://search.cpan.org/~janpaz/DBD-XBase-0.241/ dbd::xbase] and [http://search.cpan.org/~jv/Getopt-Long-2.35/lib/Getopt/Long.pm getopt::long] have to be installed from CPAN first). There are problems, if the last column of the table contains characters. Suggestions for improvements welcome! '''Author:'''Wolfgang Qual

* [http://www.igc.usp.br/pessoais/guano/downloads/azimuth2.c azimuth2.c] is a small C program to calculate the azimuth and length of vector lines exported by GRASS-GIS as ASCII files (like this: v.out.ascii input=vector output=ascii format=standard). It is useful for create rose diagrams of lineament maps. Improvements on the original code after suggestions by Örs Téglásy, Hungary. '''Author:''' Carlos Henrique Grohmann

==GRASS 6.x (current)==

=== Vector add-ons ===

See also

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

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

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

Available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/vector/adehabitat

==== v.append ====

: [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.append v.append] is a shell script combining two vector files AND their associated attribute tables. The vector files should be of the same type and, for best results, should have identically formatted attribute tables.

: '''Author:''' Michael Barton

==== v.autokrige ====

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

: '''Author:''' Mathieu Grelier

==== v.breach ====

: [http://www.sieczka.org/programy_en.html v.breach] creates vector maps of lines and points of continously lowering elevation down the input watercourses, based on the input raster DEM.

: '''Author:''' Maciej Sieczka

==== v.colors ====

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

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

: [http://wiki.iosa.it/dokuwiki/spatial_analysis:feature_count v.count.points.sh] counts point features in areas, generates table good as input to d.vect.chart.

: '''Author:''' Stefano Costa

==== v.digatt ====

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

: '''Author:''' Andreas Philipp

==== v.dip ====

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

: '''Author:''' Marcin Slodkowski

==== v.flip ====

: [http://www.sieczka.org/programy_en.html v.flip] flips the direction of selected vector lines (redundant since GRASS 6.3 - there is "v.edit tool=flip").

: '''Author:''' Maciej Sieczka

==== v.group ====

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

: '''Author:''' Cedric Shock

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

: v.in.redwg imports DWG files into GRASS.

:'''Author:''' Rodrigo Rodrigues da Silva

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

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

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

:'''Author:''' Martin Landa

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

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

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

: '''Author:''' Hamish Bowman

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

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

:'''Author:''' Benjamin Ducke

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

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

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

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

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

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

: '''Author:''' Trevor Wiens

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

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

:'''Author:''' Hamish Bowman

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

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

: '''Author:''' Huidae Cho

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

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

: '''Author:''' Mathieu Grelier

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

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

: '''Author:''' Jannis Achstetter

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

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

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

: '''Author:''' Hamish Bowman

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

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

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

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

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

: '''Author:''' Hamish Bowman

==== v.krige ====

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

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

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

==== Spatial Analysis Tools ====

===== v.lda.py =====

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

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

: [http://www.sieczka.org/programy_en.html v.line.center] creates a points vector map with each point located in the middle of the length of the input vector line.

: '''Author:''' Maciej Sieczka

==== v.lmeasure ====

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

: '''Author:''' Mats Schuh

==== v.mkhexgrid ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.mkhexgrid v.mkhexgrid] is a python script that creates a hexagonal grid the size of the selected region using user specified side lengths.

: '''Author:''' Trevor Wiens

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Hamish Bowman

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

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

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

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

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

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

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

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

: '''Author:''' Trevor Wiens

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

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

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

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

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

: '''Author:''' Hamish Bowman

==== v.profile ====

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

: '''Author:''' Maris Nartiss

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

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

: '''Author:''' Hamish Bowman

==== v.rasterbounds ====

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

: '''Author:''' Jachym Cepicky

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

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

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

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

: '''Author:''' Trevor Wiens

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

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

: '''Author:''' Eric Patton

==== v.selmany ====

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

: '''Author:''' Vincent Bain

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Giovanni Allegri

==== v.surf.krige [deprecated: use v.autokrige instead] ====

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

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

==== v.strahler ====

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

: '''Author:''' Florian Kindl. Available via SVN:

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

==== v.swathwidth ====

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

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

==== v.thickness ====

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

: '''Author:''' Marcin Slodkowski

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

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

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

==== v.trees3d ====

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

: '''Author:''' Jachym Cepicky

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

: '''Author:''' Jaime Carrera

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

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

: '''Author:''' Hamish Bowman

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

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

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

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

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.vect.stats v.vect.stats] counts the number of points falling into each polygon and optionally calculates statistics from numeric point attributes for each polygon. v.vect.stats is a C module and works with GRASS 6.4 and higher (see enclosed patches for 6.5 and 7.0).

: '''Author:''' Markus Metz

==== AniMove ====

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

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

==== Utilities ====

===== Shapemerge =====

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

:'''Authors:''' Perrygeo

=== Raster add-ons ===

See also

svn co <nowiki>https://svn.osgeo.org/grass/grass-addons/raster</nowiki>

==== Raplat ====

GRASS-RaPlaT: The Radio Planning Tool for GRASS GIS system developed by support of Slovenian largest mobile operator Mobitel. It is especially designed for radio coverage calculation of GSM/UMTS systems, but can be applied also to other wireless systems in the frequency range 400 MHz – 2.4 GHz (e.g. TETRA, WiFi). Its structure is modular and characterized by high level of flexibility and adaptability.

* Documentation: http://commsys.ijs.si/en/component/content/article/54-software/149-user-manual
* Software: http://commsys.ijs.si/en/software/grass-raplat

: '''Author:''' Department of Communication Systems, Jozef Stefan Institue, Jamova 39, SI-1000 Ljubljana, Slovenia

==== r.area ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.area r.area] Very simple module. Calculate area size (in cells) for every individual category in input raster map and write number of cells as the value of each cell in the area. Optionally write a binary coverage map and set a minimum area threshold. Works well with {{cmd|r.clump}}.

: '''Author:''' Jarek Jasiewicz

==== r.basin ====

: [http://svn.osgeo.org/grass/grass-addons/raster/r.basin/ r.basin] Generates the main morphometric parameters of the basin starting from the digital elevation model and the coordinates of the basin's closing section.

: '''Author:''' Margherita Di Leo, Massimo Di Stefano

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.basin/

==== r.bilateral ====

: [http://les-ejk.cz/files/programs/grass/r.bilateral.tgz r.bilateral] Bilateral filter is an edge-preserving filter, which combines domain and range filtering. It is written in C language.

: '''Author:''' Jachym Cepicky

==== r.broscoe ====

r.broscoe.sh calculates waerden test and t test statistics for some values of threshold area on a single basin, according to A.J.Broscoe theory (1959).
See v.strahler package

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.strahler/

==== r.boxcount ====

: r.boxcount and r.boxcount.sh calculate the fractal dimension for a given map. These are versions for grass6 of [http://www.ucl.ac.uk/~tcrnmar/ Mark Lake's modules] for grass43.

: '''Authors:''' Mark Lake, grass6 port: Florian Kindl.

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.boxcount/
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.boxcount.sh/

==== r.burn.frict ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.burn.frict r.burn.frict] converts vector geometries to raster cells, using a simple anti-aliasing method to close "gaps" between diagonal cells. Useful for "burning" vector geometries into a friction surface, making sure that simulated movement does not "slip" through converted cells that have only diagonal neighbours.

:'''Author:''' Benjamin Ducke

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.burn.frict

==== r.clump2 ====

: [https://trac.osgeo.org/grass/browser/grass-addons/raster/r.clump2 r.clump2] is a C module similar to r.clump. Differences are: diagonally adjacent cells are also clumped but can be excluded, NULL (nodata) cells are always excluded, and selective clumping with start coordinates is supported.

: '''Author:''' Markus Metz

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.clump2

==== r.colors.out_vtk ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.colors.out_vtk r.colors.out_vtk] is a shell script used to export the color table associated with a raster map layer to a {{wikipedia|VTK}} XML file. (see also [[Help with 3D]])

: '''Author:''' Hamish Bowman

==== r.colors.quantiles ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.colors.quantiles/r.colors.quantiles r.colors.quantiles] is a shell script used to create raster colors rules based on nquantiles. It uses R and spgrass6 package (RGRASS).

: '''Authors:''' Mathieu Grelier

==== r.colors.stddev ====

: [http://hamish.bowman.googlepages.com/grass_color_maps r.colors.stddev] ''moved into main archive''

==== r.convergence ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.convergence r.convergence] calculate topographic convergence index, useful to detect lineamets represented by chanell/ridge system

: '''Author:''' Jarek Jasiewicz

==== r.cpt2grass ====

: [http://hamish.bowman.googlepages.com/grass_color_maps r.cpt2grass] is a GRASS script for importing a [http://www.soest.hawaii.edu/gmt/ GMT] .cpt color table into GRASS. It can save to a text file suitable for r.colors or automatically apply the color table to a raster map. For a large collection of GMT .cpt files see http://sview01.wiredworkplace.net/pub/cpt-city/
: Other palette ideas from [http://geography.uoregon.edu/datagraphics/color_scales.htm Univ. Oregon] and [http://oceancolor.gsfc.nasa.gov/PRODUCTS/colorbars.html NASA/Goddard's OceanColor] (latter partially translated for use with GRASS on the [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.colors.tools/palettes grass-addons SVN]).

: '''Author:''' Hamish Bowman

==== r.csr ====

: [https://svn.osgeo.org/grass/grass-addons/raster/r.csr r.csr] integrates several Grass programs to produce colored, shaded-relief rasters in one step. Accepts single or multiple elevation/bathymetry maps as input; optionally will fill data holidays with 3x3 median filter, multiple times, if required; can apply color maps from a) input raster, b) another raster in MAPSET, or c) from a rules file; otherwise, rainbow colorbar is applied. Output colored, shaded-relief rasters can optionally be exported to tiff format if the appropriate flag is given. Shading parameters can be modified, though useful defaults are given.

: '''Author:''' Eric Patton

==== r.cva ====

: [http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html r.cva] is a cumulative viewshed analysis module. It is an advanced version of the {{cmd|r.los}} program.

: '''Author:''' [http://www.ucl.ac.uk/~tcrnmar/ Mark Lake]

==== r.denoise ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.denoise r.denoise] denoises (smooths/despeckles) topographic data, particular DEMs derived from radar data (including SRTM), using Xianfang Sun's [http://www.cs.cf.ac.uk/meshfiltering/index_files/Page342.htm denoising algorithm]. It is designed to preserve sharp edges and to denoise with minimal changes to the original data. See the [http://personalpages.manchester.ac.uk/staff/john.stevenson/mdenoise/r.denoise.html manual pages] for details. Further information on Sun's denoising algorithm, including an example, is available [http://personalpages.manchester.ac.uk/staff/john.stevenson/mdenoise here].

: '''Author:''' John Stevenson

==== r.dominant_dir.m and r.calc_terraflow_dir.m ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.terraflow.tools dominant_dir.m and calc_terraflow_dir.m] are two Matlab scripts for determining the dominant flow direction from a r.terraflow MFD map and converting into a GRASS aspect map for use with d.rast.arrow, etc.

: '''Author:''' Hamish Bowman

==== r.diversity ====
: [http://svn.osgeo.org/grass/grass-addons/raster/r.diversity/ r.diversity] calculates selected diversity indices by calling various r.li commands.This script uses the [http://grass.osgeo.org/grass64/manuals/html64_user/r.li.pielou.html Pielou], [http://grass.osgeo.org/grass64/manuals/html64_user/r.li.renyi.html Renyi], [http://grass.osgeo.org/grass64/manuals/html64_user/r.li.shannon.html Shannon] and [http://grass.osgeo.org/grass64/manuals/html64_user/r.li.simpson.html Simpson] indices. The output is a map for each index.

: '''Author:''' Luca Delucchi, Duccio Rocchini

==== r.eucdist ====

: [http://david.p.finlayson.googlepages.com/r.eucdist r.eucdist] creates a raster map estimating the euclidean distance from known cells.

: '''Author:''' David Finlayson

==== r.fragment ====

: [http://www.chrisgarstin.com/stuff/r.fragment r.fragment] fragments a raster into a user-defined set of smaller tiles according to an input number of rows and columns.
: '''Author:''' Eric Patton

==== r.fuzzy ====
: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.fuzzy r.fuzzy] Calculates membership of every cell in raster according membership function defined by user.
: '''Author:''' Jarek Jasiewicz

==== r.fuzzy.logic ====
: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.fuzzy.logic r.fuzzy.logic] Perform fuzzy operators (AND, OR, NOT, IMP) on membership's map using T-norms and T-conorms for 6 most popular families.
: '''Author:''' Jarek Jasiewicz

==== r.fuzzy.system ====
: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.fuzzy.system r.fuzzy.system] Perform full fuzzy clasificationwith 6 most popular fuzzy logic families and few methods of deffuzification.
: '''Author:''' Jarek Jasiewicz

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.fuzzy.system

==== r.game_of_life ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.game_of_life r.game_of_life] is a shell script which runs Conway's classic Game of Life using GRASS raster modules. It is meant to demonstrate how easy it is to program cellular automata in GRASS as well as various 3D raster volume and time series visualization techniques.

: '''Author:''' Hamish Bowman

==== r.gauss ====

: [http://www.les-ejk.cz/files/programs/grass/r.gauss.tgz r.gauss] is Gaussian and Laplacian of Gaussian filter for GRASS. It is written in C language.

:'''Author:''' Jachym Cepicky

==== r.gradgrid4 ====

: [http://www.uibk.ac.at/geographie/personal/mergili/gradgrid4.zip gradgrid4] is a tool for interpolating values of discrete data points to a raster map, applying a local regression approach with a predictor raster. The model is based on shell and python scripts as well as an R batchfile. It was tested on Fedora Core 6 with GRASS 6.2.1 and R 2.5.1, but should work under most UNIX systems. After unzipping the gradgrid4 folder, store it at any place in your local file system. In the subfolder docs you can find a manual and a publication draft with a detailed description of the concept and the example of an application. The subfolder testloc constitutes a GRASS location with test data.

: '''Author:''' Martin Mergili

==== r.hazard.flood ====

: [http://svn.osgeo.org/grass/grass-addons/raster/r.hazard.flood/ r.hazard.flood] is an implementation of a fast procedure to detect flood prone areas. The exposure to flooding may be delineated by adopting a topographic index (TIm) computed from a DEM. The portion of a basin exposed to flood inundation is generally characterized by a TIm higher than a given threshold, tau. The threshold is automatically determinated from the cellsize. The proposed procedure may help in the delineation of flood prone areas especially in basins with marked topography. The use of the modified topographic index should not be considered as an alternative to standard hydrological-hydraulic simulations for flood mapping, but it may represent a useful and rapid tool for a preliminary delineation of flooding areas in ungauged basins and in areas where expensive and time consuming hydrological-hydraulic simulations are not affordable or economically convenient.

: '''Author:''' Margherita Di Leo

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.hazard.flood/

==== r.in.mb ====

: [http://blogs.tekmap.ns.ca/archives/458 r.in.mb] is a "GRASS/[[MB-System]] program designed to import ''mbio'' compatible multibeam sonar data directly into the GRASS GIS. The program is a modified version of {{cmd|r.in.xyz}}. Instead of reading an ASCII XYZ file, ''r.in.mb'' reads an MB-System compatible list file." It can do automatic reprojection and minor hole filling. The default is to import bathymetry data, but optionally amplitude or sidescan sonar data can be loaded instead.

: '''Author:''' Bob Covill

==== r.in.onearth ====

: [http://www-pool.math.tu-berlin.de/~soeren/grass/modules/ r.in.onearth] for download and import satellite images direct from the NASA onearth WMS server into GRASS.

: '''Author:''' Soeren Gebbert

==== r.in.swisstopo ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.in.swisstopo/ r.in.swisstopo] for importing swisstopo digital elevation model data into GRASS raster maps.

: '''Author:''' Jürgen Hansmann

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.in.swisstopo/

==== r.in.wms (.py) ====

: [http://les-ejk.cz/files/programs/grass/r.in.wms.tgz r.in.wms] for download and import maps direct from WMS servers into GRASS. This script is written in Python Programming language. Note GRASS 6.2+ provides a shell script version of r.in.wms, take care of which one is actually being run.

: '''Author:''' Jachym Cepicky

==== r.inund.fluv ====

: [https://svn.osgeo.org/grass/grass-addons/raster/r.inund.fluv/ r.inund.fluv]This command allows to obtain a fluvial potentially inundation map given a high-resolution DTM of the area surrounding the river and a water surface profile calculated through an 1-D hydrodinamic model.

: '''Authors:''' Roberto Marzocchi, Bianca Federici, Domenico Sguerso

==== r.isoregions ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.isoregions/r.isoregions r.isoregions] allows isoregions creation from a GRASS raster map.

: '''Authors:''' Mathieu Grelier

==== r.interp.mask ====

: [http://david.p.finlayson.googlepages.com/r.interp.mask r.interp.mask] Creates a user-specified buffer around interpolation points that can be used as a MASK to prevent or clip excessive extrapolation artifacts. This works much better than a standard convex hull around the points.

: '''Author:''' David Finlayson

==== r.ipso ====

: [http://svn.osgeo.org/grass/grass-addons/raster/r.ipso/ r.ipso] Produces the ipsometric and ipsographic curve related to a digital elevation model and prints the percentiles

: '''Authors:''' Margherita Di Leo, Massimo Di Stefano, Francesco Di Stefano

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.ipso/

==== r.li ====

: [http://www.faunalia.it/download/r_li/ r.li] is a more flexible and faster replacement of the old r.le. '''''Moved into 6.3-SVN'''''.

: '''Authors:''' Claudio Porta, Davide Spano, Serena Pallecchi, [http://www.faunalia.it Faunalia]

==== r.local_max.pl ====

: [http://les-ejk.cz/files/programs/local_max.pl Local maxima] is a Perl script for <code>r.mapcalc</code>. It detects local maxima of the image.

: '''Author:''' Jachym Cepicky

==== r.mandelbrot ====

: [http://grasslab.gisix.com/scripts/r.mandelbrot r.mandelbrot] is a shell script to calculate the Mandelbrot set.- for GRASS versions 6.X.

: '''Author:''' Peter Löwe

==== mcda====

: mcda suite is a toolset for geographics multi-criteria decision aiding and data analysis based on ELECTRE (r.mcda.electre), REGIME (r.mcda.regime) and FUZZY (r.mcda.fuzzy) algorithm. The module r.roughset is also included for geographics rough set analisys and knowledge discovery based on rough set library. It is written in C language for GRASS versions 6.X.

: '''Author:''' Gianluca Massei (g_massa@libero.it ) - Antonio Boggia

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/mcda/

==== r.mlv ====

: [http://les-ejk.cz/files/programs/grass/r.mlv.tgz r.mlv] is Mean of least variance filter for GRASS. It is an edge-preserving (or even edge-enhacing) filter, which should serve for removing additive noise from images. It is written in C language.

: '''Author:''' Jachym Cepicky

==== r.obstruction, r.planning.static, r.planning.cinematic ====

: [http://www.ing.unitn.it/~grass/software.html r.obstruction, r.planning.static, r.planning.cinematic]: r.obstruction creates a polar obstruction map from a DTM. r.planning.static performs a static planning for GPS and Glonass surveys using the obstruction map created with r.obstruction. r.planning.cinematic performs a cinematic planning for GPS and Glonass surveys. (University of Trento, Faculty of Engineering)

: '''Author:''' Daniele Carli, Dimitri D'Inca', Gianluca Fruet, Domenico Sguerso, Paolo Zatelli

==== r.out.jpeg ====

: [http://www.geospatial.it/allegri/grass/r.out.jpeg_ r.out.jpeg] is a simple GRASS script to export georeferenced JPEG images from rasters, keeping the associated color table. It is a two-step export: first a ppm file is created, then it is converted to jpeg usgin the "convert" command from ImageMagick

: '''Author:''' Giovanni Allegri

==== r.out.gmap ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.out.gmap r.out.gmap] outputs GRASS raster map into set of image tiles
following the tiling scheme of Google Maps and Microsoft Virtual Earth. Read more in the OSGeo Journal [http://www.osgeo.org/journal Volume 5 (2009, to appear)] see also [[#r.out.kml|r.out.kml]] and [[#v.out.kml|v.out.kml]]

: '''Author:''' Tomas Cebecauer

==== r.out.gmt ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.out.gmt r.out.gmt] is a GRASS script for exporting a GRASS raster map into a [http://www.soest.hawaii.edu/gmt/ GMT] grid file. It also creates a GMT color table from the data and can generate some GMT commands for plotting a postscript file. (code is experimental, but functional) see also http://169.237.35.250/~dylan/grass_user_group/#GMT_and_GRASS-overview

: '''Authors:''' Hamish Bowman, Dylan Beaudette

==== r.out.gmt2 ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.out.gmt2 r.out.gmt2] is a modified version of Hamish's r.out.gmt. Added options for title, xlabel, ylabel, comment, and map width. Removed any settings that can be changed by gmtset for more flexibility.

: '''Author:''' Huidae Cho, Hamish Bowman, Dylan Beaudette

==== r.out.kap_template ====

: [https://trac.osgeo.org/grass/browser/grass-addons/raster/r.out.kap_template r.out.kap_template] is a shell script that exports a raster map into a GeoTiff and a metadata text file suitable for use with KAP (BSB) raster nautical chart converter programs such as <tt>tif2bsb</tt> (after verifying that you are legally entitled to use such a tool).
: '''''This is EXPERIMENTAL software. NOT FOR NAVIGATIONAL USE.'''''
: For an easy to use data viewer, see also the [http://www.opencpn.org OpenCPN] free navigational software.

: '''Author:''' Hamish Bowman

==== r.out.kml ====

: [https://trac.osgeo.org/grass/browser/grass-addons/raster/r.out.kml r.out.kml] is a shell script that exports a raster map into a KML file and image for Google Earth or Worldwind. See also [[#v.out.kml|v.out.kml]] and [[#r.out.gmap|r.out.gmap]].

: '''Author:''' Hamish Bowman

==== r.pack ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.pack r.pack] and [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.unpack r.unpack] are two GRASS scripts for transferring raster maps to another computer as a single compressed file including color table etc.
: An earlier version has been renamed as [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.pack/experiment r.pack.mat] and [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.unpack/experiment r.unpack.mat].

: '''Author:''' Hamish Bowman

==== r.pi ====

: [https://svn.osgeo.org/grass/grass-addons/raster/r.pi/ r.pi] (raster patch index) provides various functions to analyse spatial attributes of a landscape. It has a focus on patch-based indices but delivers class-based indices as well. r.le and its successor r.li provide landscape indices.

: '''Authors:''' Programming: Elshad Shirinov, Scientific concept: Dr. Martin Wegmann

==== r.prominence ====

: '''r.prominence''' calculates the average difference between a central cell and its neighbors. It approximated the terrain 'ruggedness' by looking at average differences in elevation within a given neighborhood.

: '''Author:''' Benjamin Ducke

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.prominence/

==== r.refine ====

: [http://www.bowdoin.edu/~ltoma/research.html r.refine]: reduces a DEM to a TIN (takes as input a grid DEM and an error margin and simplifies it to the desired accuracy into a TIN)
Available via the source code repository [https://github.com/jonrtodd/r.refine]
: '''Authors:''' Laura Toma and Jonathan Todd

==== r.rifs ====

: [http://www.ucl.ac.uk/~tcrnmar/ r.rifs]: r.rifs generates a raster map and/or image of a fractal by means of the specified random iterated function system.

: '''Author:''' Mark Lake

==== r.roughness ====

[http://trac.osgeo.org/grass/browser/grass-addons/raster/r.roughness/r.roughness.sh r.roughness.sh] is a shell script to calculate the surface roughness of a DEM, using r.surf.area and v.surf.rst. (for GRASS versions 6.1 and above)

[http://www.igc.usp.br/pessoais/guano/downloads/r.roughness60 r.roughness60] - for GRASS versions 6.0.X

[http://trac.osgeo.org/grass/browser/grass-addons/raster/r.roughness/r.roughness.window.area r.roughness.window.area] - calculate surface roughness as the ratio of real (surface) area and planar area, using a moving-window approach.

[http://trac.osgeo.org/grass/browser/grass-addons/raster/r.roughness/r.roughness.window.vector r.roughness.window.vector] - calculate surface roughness as vector dispersion, using a moving-window approach. Resulting maps are: Vector Strength (R) and Inverted Fisher's k parameter.

[http://trac.osgeo.org/grass/browser/grass-addons/raster/r.roughness/r.roughness.window.vector.html r.roughness.window.vector.html] - provisional help page for r.roughness.window.vector.

: '''Author:''' Carlos Henrique Grohmann

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.roughness/

==== r.roughset ====

: r.roughset is a module for geographics rough set analisys and knowledge discovery based on rough set library. It is written in C language for GRASS versions 6.X.

: '''Author:''' Gianluca Massei (g_massa@libero.it ) - Antonio Boggia

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/mcda/r.roughset/

==== r.seg ====

: '''r.seg''' performs image segmentation and discontinuity detection (based on the Mumford-Shah variational model).
: The module generates a piece-wise smooth approximation of the input raster map and a raster map of the discontinuities of the output approximation. The discontinuities of the output approximation are preserved from being smoothed.
: See [http://www.ing.unitn.it/~vittia/sw here] for details and examples.

Available [http://www.ing.unitn.it/~vittia/sw here] and with improvements via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.seg/

: '''Author''' Alfonso Vitti

==== r.smoothpatch ====

: [http://david.p.finlayson.googlepages.com/r.smoothpatch r.smoothpatch] creates a composite of two rasters using a distance-weighted average across the transition to smooth the edges.

: '''Author:''' David Finlayson

==== r.soils.texture ====

: r.soils.texture is a module to define soils texture from sand and clay raster file with a schema text file (now FAO,USDA and ISSS are available). It is written in C language. - for GRASS versions 6.x - For bugs and suggest: g_massa@libero.it

:'''Author:''' Gianluca Massei

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.soils.texture/

==== r.stack ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stack r.stack] is a shell script used to patch all the raster maps in a time series (or burst 3D raster) together into a vertical stack, to aid mutli-map analyses in modules where group input is not yet available.

: '''Author:''' Hamish Bowman

==== r.stream.angle ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.angle r.stream.angle] Divide stream network into stright line segments according users input. It extends Module uses as input direction and stream netwokr map produced by r.watershed and stream.extract or custom user input. See description for details.

: '''Author:''' Jarek Jasiewicz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.angle

==== r.stream.basins ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.basins r.stream.basins] delineate basins according users input. It extends r.water.outlet funcionality to extracting more than one basin at one step. Module uses as input direction map produced stream network produced by r.stream.extract, r.watershed, r.stream order or custom user input. More in tutorial on grass-wiki pages.

: '''Author:''' Jarek Jasiewicz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.basins

==== r.stream.del ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.del r.stream.del] Calculates downslope length of first order streams and delete them if it length (in pixels) is lower than the treeshold. It also join false segments left by deletion into one with category of upper. It uses r.watershed direction map and r.watershed stream map as input. The module is added only for r.watershed module, r.stream.extract has deleting short streams build-in. During development of r.stream.* it will be probably abandoned due to duplicate functionality

: '''Author:''' Jarek Jasiewicz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.del

==== r.stream.distance ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.distance r.stream.distance] Calculates downslope distance and downslope elevation difference between current cell and stream or outlet cells. It uses r.watershed direction map, r.watershed or r.stream.extract stream map and optionally DEM as input.

: '''Author:''' Jarek Jasiewicz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.distance

==== r.stream.extract ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.extract r.stream.extract] extracts topologically clean stream networks from input elevation and optionally accumulation maps. Output is available as raster and vector and can be used as input for the other r.stream.* modules by Jarek Jasiewicz.

: '''Author:''' Markus Metz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.extract

==== r.stream.order ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.order r.stream.order] orders stream network outputed by r.watershed or r.stream.extract according Sthrahler, Shreve, Horton and Hack ordering systems. It require as input stream and direction map and optionally accumulation map. It handle both SFD nad MFD modes but all data must come from the same procedure.

: '''Author:''' Jarek Jasiewicz, Markus Metz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.order

==== r.stream.pos ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.pos r.stream.pos] Helper module for calculating local stream network properties and linear geostatistics. Mostly To use with R and other grass modules.

: '''Author:''' Jarek Jasiewicz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.pos

==== r.stream.stats ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.stats r.stream.stats] calculate Hortonian statistics for Stahler or Horton stream network created by r.stream.order. It uses r.watershed direction map, DEM and r.stream.order's Stahler or Horton stream network as input. It outputs calculated statistics to standard output.

: '''Author:''' Jarek Jasiewicz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.stats

==== r.surf.nnbathy ====

: [http://www.sieczka.org/programy_en.html r.surf.nnbathy] interpolates a surface from a raster input using Pavel Sakov's [http://code.google.com/p/nn-c/ nn] natural neighbor interpolation library. Provides triangulation, Sibson natural neighbor interpolation and non-Sibsonian interpolation.

: '''Author:''' Maciej Sieczka

==== r.surf.volcano ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.surf.volcano r.surf.volcano] creates an artificial surface resembling a seamount or cone volcano. The user can alter the size and shape of the mountain and optionally roughen its surface. Available decay functions are polynomial, Gaussian, Lorentzian, logarithmic, and exponential.

: '''Author:''' Hamish Bowman

==== r.terracost ====

[http://www.bowdoin.edu/~ltoma/research.html r.terracost] Scalable approach for computing least-cost-path surfaces on massive grid terrains. '''Lead author''': Laura Toma

Available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.terracost

==== r.tileset ====

: ''{{cmd|r.tileset}} moved into main archive''

==== r.traveltime ====

: [http://jesbergwetter.twoday.net/stories/4845555/ r.traveltime] computes the travel time of surface runoff to an outlet. The program starts at the basin outlet and calculates the travel time at each raster cell recursively. A drainage area related threhold considers even surface and also channel runoff. Travel times are derived by assuming kinematic wave approximation. The results can be used to derive a time-area function. This might be usefull for precipitation-runoff calculations (estimation of flood predictions) with a lumped hydrologic model (user-specified unit hydrograph).

: '''Author:''' Kristian Förster

==== r.univar.zonal ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.univar.zonal r.univar.zonal] is similar to r.univar, but calculates statistics separately for each category(zone) present in the separate input map used to define zones (zonal statistics). The output can be like the one of r.univar or in easier to read table format and can be written to a file. This addon is only needed for GRASS 6.4, its functionality has been added to r.univar in 6.5 and 7.

: '''Author:''' Markus Metz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.univar.zonal

==== r.viewshed ====

: r.viewshed is a module for extremely fast line of sight analysis (replaces the slow r.los). It is written in C language for GRASS versions 6.X/7.x.

: '''Author:''' Laura Toma, USA

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.viewshed

Once {{trac|390}} is solved, it will substitute r.los.

==== r.wavelets ====

: [http://www.ing.unitn.it/~grass/software.html r.wavelets]: This package contains wavelets decomposition and reconstruction modules for the GRASS GIS: r.owave.dec computes the orthogonal wavelet transform of a raster map. r.owave.rec reconstructs a raster map from an orthogonal wavelet transform. r.biowave.dec computes the biorthogonal wavelet transform of a raster map. r.biowave.rec reconstructs a raster map from a biorthogonal wavelet transform.

: '''Authors:''' Members of the University of Trento, Faculty of Engineering

==== r.wf ====

: [http://svn.osgeo.org/grass/grass-addons/raster/r.wf/ r.wf] produces the Width Function of a basin. The Width Function W(x) gives the number of the cells in a basin at a flow distance x from the outlet (it is also referred as distance-area function). The distance is not the euclidean one, but it is measured along the flowpath towards the outlet.

: '''Authors:''' Margherita Di Leo, Massimo Di Stefano, Francesco Di Stefano

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.wf/

==== r.xtent ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.xtent r.xtent] computes a raster map layer representing the Voronoi diagram, weighted Voronoi diagram or a more complex territorial partitioning of space around points (centers) in a vector input map, based on the XTENT formula.

:'''Author:''' Benjamin Ducke

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.xtent

==== r.zc.pl ====

: [http://les-ejk.cz/files/programs/zc.pl Zero crossing] is a simple Perl script, finds the ,,zero crossings`` from the Laplacian of Gaussian filter (see above). It is really very simple, the edges don't need to be really on that pixel, where they are detected, no interpolation is performed.

: '''Author:''' Jachym Cepicky

==== GIPE ====

: The GRASS Image Processing Environment (GIPE) has USLE, Energy-balance and radiance-reflectance correction models.

: '''Author:''' Yann Chemin (unless specified otherwise).

svn co https://svn.osgeo.org/grass/grass-addons/imagery/gipe

Remark: This is progressively moved to main GRASS SVN (aka GRASS 7)

:* r.hydro.CASC2D, ported from GRASS 5.x version, is temporarily here waiting to return to main GRASS.

:* r.soiltex2prop creates porosity, Saturated Hydraulic conductivity (Ksat) and wetting front pressure head (Hf) from percentage of sand and clay after Rawls et al., 1990. This is a must for r.hydro.CASC2D.

:* i.biomass creates biomass growth map from fPAR, lightuse efficiency, water availability (or evap.fraction), Lat, doy and tsw.

:* i.dn2ref.l7, r.dn2ref.ast create top of atmosphere reflectance for Landsat 7ETM+ and ASTER. These modules also have a flag for radiance output. Updated i.dn2ref.l7 to read .met calibration file.

:* i.dn2full.l[5,7] is an attempt to get all bands of Landsat[5,7] calibrated and corrected to either reflectance or temperature, reads only the .met file.

:* i.dn2potrad.l[5,7] is an attempt to get ET potential from DN of Landsat 7 (Careful! No Atmospheric correction!).

:* i.eb.* are a set of 10+ GRASS modules that together perform the main functions of the SEBAL model (Bastiaanssen, 1995). Those functions include (but are not limited to) Soil heat flux, sensible heat flux, net radiation, evaporative fraction at satellite overpass, diurnal actual evapotranspiration, momentum roughness length, etc. These modules are also part of any Energy-Balance related processing.

:* i.evapo.potrad creates diurnal Potential evapotranspiration assuming all net radiation becomes ET, according to SEBAL model (Bastiaanssen, 1995). This module also has a flag for diurnal net radiation as required by SEBAL in i.eb.eta.

:* i.evapo.SENAY creates actual evapotranspiration following the regional method of Senay (2007).

:* i.lmf creates a Local Maximum Fitting on the temporal dimension of the multi-date input dataset, working, but more precision still to be added.

:* i.vi.mpi is the mpi version of i.vi for cluster GRASS GIS education (no speed up here!) '''Author:''' Shamim Akhter

:* i.modis.stateqa extracts State Quality Assessment information from Modis 500m (MOD09A) products.

:* i.water creates a Water Mask from NDVI and Albedo, or specifically for Modis: NDVI and Band 7.

:* i.wi creates a given Water Index (only one so far).

==== HydroFOSS ====

: HydroFOSS - a GIS embedded approach for Free & Open Source Hydrological modeling.

: '''Author:''' Massimiliano Cannata

svn co https://svn.osgeo.org/grass/grass-addons/HydroFOSS/

==== Hikereport ====

: python script that computes length, cumulative uphill and downhill, average slopes on an interactively drawn path. Based on r.profile's output.

: '''Author:''' Stefano Negri

http://tracce.wordpress.com/?attachment_id=71

=== Misc add-ons===

==== m.eigensystem ====

m.eigensystem - Computes eigen values and eigen vectors for square matrices.

: http://svn.osgeo.org/grass/grass-addons/misc/m.eigensystem/

: '''Author:''' Michael Shapiro

===Database add-ons===
==== db.join ====

: Table joining: join one table into another through common attributes

: '''Author:''' Markus Neteler. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/database/db.join/
or
g.extension db.join

===General add-ons===

==== GRASS create location scripts ====

: [http://trac.osgeo.org/grass/browser/grass-addons/general/grass_create_location grass_create_location.sh] Script to generate a new GRASS location from GIS file (e.g. geoTIFF or SHAPE), wktfile or EPSG code.

: '''Author:''' Markus Neteler

==== g.laptop.sh ====

: [http://www.gbd-consult.de/dassau/grass/g.laptop/g.laptop.sh g.laptop.sh] is an interactive shell script to extract raster and vector data from current Location into a new one. Data can be copied or extracted in current or original resolution and region extend. This script was written to extract smaller parts of a GRASS location to be able to present them on a laptop without the necessity to transfer huge data. Maps do not have to be in the same mapset.

: '''Author:''' Otto Dassau

==== Readline completion ====

: '''''Readline completion''''' for GRASS commands under the bash shell: [http://www.sorokine.info/grass-complete/ grass-complete] won't clutter the environment but needs to be installed; [http://dcalvelo.free.fr/grass/grass_rlcompleter.sh grass_rlcompleter.sh] needs almost no installation but will pollute the environment. Grass-Complete currently requires Bash version 2.05 for proper install.

: '''Author:''' Alexandre Sorokine (grass-complete), Daniel Calvelo (grass_rlcompleter.sh)

==== g.region.point ====

: [http://trac.osgeo.org/grass/browser/grass-addons/general/g.region.point g.region.point] is a shell script which resets the computational region to a square box around a given coordinate. It is intended for use within GRASS scripts to speed up processing by limiting expensive raster calculations to a small area of interest.

: '''Author:''' Hamish Bowman

==== g.linke_by_day ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.sun.tools/ g.linke_by_day] is a python script for [[r.sun]] which interpolates a Linke turbidity value for a given day of the year based on monthly values edited into the script.

: '''Author:''' Hamish Bowman

==== g.xlist ====

: [http://trac.osgeo.org/grass/browser/grass-addons/general/g.xlist g.xlist] is a C implementation of g.mlist. g.xlist searches for data files matching a pattern given by wildcards or POSIX Extended Regular Expressions. POSIX regex(3) functions are required.

: '''Author:''' Huidae Cho

==== g.xremove ====

: [http://trac.osgeo.org/grass/browser/grass-addons/general/g.xremove g.xremove] is a C implementation of g.mremove. g.xremove removes data files matching a pattern given by wildcards or POSIX Extended Regular Expressions. POSIX regex(3) functions are required.

: '''Author:''' Huidae Cho

=== Imagery add-ons ===

See also

svn co https://svn.osgeo.org/grass/grass-addons/imagery

==== GIPE ====

GIPE (see also above in raster section) provides:
i.biomass, i.dn2potrad.l5, i.dn2potrad.l7, i.dn2ref.ast, i.eb.deltat, i.eb.disp, i.eb.eta, i.eb.evapfr, i.eb.g0, i.eb.h0, i.eb.h_SEBAL01, i.eb.h_SEBAL95, i.eb.h_iter, i.eb.molength, i.eb.netrad, i.eb.psi, i.eb.rah, i.eb.rohair, i.eb.ublend, i.eb.ustar, i.eb.wetdrypix, i.eb.z0m, i.eb.z0m0, i.evapo.PT, i.evapo.TSA, i.evapo.potrad, i.evapo.senay, i.evapo.time_integration, i.lmf, i.modis.stateqa, i.sattime, i.vi.grid, i.vi.mpi, i.water, i.wi

svn co https://svn.osgeo.org/grass/grass-addons/gipe/

: '''Author:''' Yann Chemin

==== i.homography ====

Rectifies an image by computing a coordinate transformation for each pixel in the image based on the control points created by i.linespoints. The approach uses homography extended for corresponding lines.

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.homography

: '''Author:''' Daniel Grasso, Bolzano, Italy, based on code written by Stefano Merler, ITC-irst, Italy

==== i.linespoints ====

An imagery command that enables the user to mark coordinate system points as well as lines on an image to be rectified and then input the coordinates of each point for creation of a coordinate transformation matrix. The transformation matrix is needed as input for the GRASS program i.homography.

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.linespoints

: '''Author:''' Daniel Grasso, Bolzano, Italy, based on i.points

==== i.landsat.toar ====

Transform calibrated digital number of Landsat products to top-of-atmosphere radiance or top-of-atmosphere reflectance and temperature (band 6 of the sensors TM and ETM+). Optionally, used to calculate the at-surface radiance or reflectance with atmospheric correction (DOS method).

Available also in GRASS 7.

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.landsat.toar

: '''Author:''' E. Jorge Tizado

==== i.landsat.acca ====

Implements the Automated Cloud-Cover Assessment (ACCA) Algorithm from Irish (2000) with the constant values for pass filter one from Irish et al. (2006). To do this, it needs Landsat band numbers 2, 3, 4, 5, and 6 (or band 61 for Landsat-7 ETM+) which have already been processed from DN into reflectance and band-6 temperature with i.landsat.toar).

Available also in GRASS 7.

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.landsat.acca

: '''Author:''' E. Jorge Tizado

==== i.points.auto ====

This module allows a search of GCP's on two raster-maps with differents levels of automation. The ''manual'' search is the default search, so it's possible to determine the GCP's manually with the mouse (like {{cmd|i.points}}). ''Semiautomated'' search: The user determines with the mouse some correspondent areas (with a discrete precision) in the two maps and the module searches itself the GCP's in these areas. ''Automated'' search: At the start of module the user has to load the maps that the algorithm uses to the search, so it is recommended to use the maps filtered with the filters DIVERSITY or STDDEV (of GRASS) with a window of 3x3 or 5x5 pixels. However, the algorithm sometimes works well with the original maps too.

Note: This code is basically an improved i.points (from 2004). Subsequent changes in i.points haven's been ported here yet.

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.points.auto

: '''Authors:''' based on i.points; additions by Ivan Michelazzi, Luca Miori (MSc theses at ITC-irst); Supervisors: Markus Neteler, Stefano Merler, ITC-irst 2003, 2004. [http://gisws.media.osaka-cu.ac.jp/grass04/viewpaper.php?id=37 PDF article]

==== i.points.reproj ====

: [http://trac.osgeo.org/grass/browser/grass-addons/imagery/i.points.reproj i.points.reproj] is a shell script that will use cs2cs to reproject the target coordinates of a group's POINTS file. By running i.rectify directly to the new target projection, a generation of resampling data loss can be avoided (versus i.rectify + r.proj). On the other hand, i.rectify does not calculate cell resolution well if the map is to be rotated ([http://intevation.de/rt/webrt?serial_num=3296 bug #3296]), in those cases i.rectify+r.proj may be the better option.

: '''Author:''' Hamish Bowman

==== i.plr.py ====

: [[I.plr.py|Probabilistic Label Relaxation]], written in Python

: '''Author:''' Georg Kaspar

==== i.pr ====

: Image classification: implements k-NN (multiclass), classification trees (multiclass), maximum likelihood (multiclass), Support Vector Machines (binary), bagging versions of all the base classifiers, AdaBoost for binary trees and support vector machines. It allows feature manipulation (normalization, principal components,...). It also implements feature selection techniques (RFE, E-RFE,...), statistical tests on variables, tools for resampling (cross-validation and bootstrap) and cost-sensitive techniques for trees and support vector machines.

: '''Author:''' Stefano Merler. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.pr

==== i.spec.sam ====

: Spectral Angle mapping

: '''Author:''' Markus Neteler. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.spec.sam/

==== i.spec.unmix ====

: Spectral unmixing

: '''Author:''' Markus Neteler. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.spec.unmix/

==== i.topo.corr ====
: i.topo.corr is used to topographically correct reflectance from imagery files, e.g. obtained with i.landsat.toar (see above), using a sun illumination terrain model. This illumination model represents the cosine of the incident angle, i.e. the angle between the normal to the ground and the sun rays. It can be obtained with {{cmd|r.sun}} (parameter incidout), and then calculating its cosine with float precision. Correction methods: cosine, minnaert, percent, c-factor.

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.topo.corr

: '''Author:''' E. Jorge Tizado

==== i.warp ====

: [http://trac.osgeo.org/grass/browser/grass-addons/imagery/i.warp i.warp] is a shell script that will use gdalwarp to rectify a raw input image using thin plate splines. The map should be imported into GRASS with r.in.gdal and GCPs set with i.points. Input is the raw image (GeoTIFF, JPEG, etc). Output is a GeoTIFF in the imagery group's target location's map projection. Requires a recent (early 2006) version of GRASS 6.1, or newer.

: '''Author:''' Hamish Bowman

=== Display add-ons ===

See also

svn co https://svn.osgeo.org/grass/grass-addons/display

==== d.barb ====

[http://trac.osgeo.org/grass/browser/grass-addons/display/d.barb d.barb] is a C module that will draw wind barbs, straw plots, and arrow plots from raster array or sparse vector point data. It can use either direction + magnitude, or u + v components as the input, and can produce a legend key. (''work in progress, but it's mostly there'')

: '''Author:''' Hamish Bowman

==== d.edit.rast ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.edit.rast d.edit.rast] edits cells in an existing raster map displayed on the current monitor.

: '''Author:''' Huidae Cho

==== d.frame.quarter ====

: ('''obsolete''') [http://trac.osgeo.org/grass/browser/grass-addons/display/d.frame.split d.frame.quarter] is a shell script that will split the display into four quadrants (or sixths) using ''d.frame''. Individual frames are named ''uno, dos, tres, cuatro'', and ''full_screen''.
: Replaced by {{cmd|d.split.frame}} in main.

: '''Author:''' Hamish Bowman

==== d.frame.split ====

: ''d.frame.split moved into main archive as {{cmd|d.split.frame}}''

==== d.frontline ====

: [http://cloud.github.com/downloads/amuriy/GRASS-scripts/d.frontline d.frontline] is a shell script that draws frontlines on the graphics monitor using ''d.graph'' module and different types of symbols. Also it optionally saves frontline graphics to ''d.graph'' commands file and/or ''ps.map'' file (for later use with the "read" ''ps.map'' instruction)

: '''Author:''' Alexander Muriy

==== d.hyperlink ====

: [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/d.hyperlink.tar.bz2 d.hyperlink] is an interactive shell script that allows the viewing of hyperlinked images from a vector's attribute table in an external image viewer. Queries can be made via SQL statements or interactive mouse-clicking. The attribute table must be pre-populated with a column containing the image to link the vector to; the user also specifies the image folder in the current MAPSET where the images are located. The script currently supports gimp, Eye of Gnome, gthumb, gpdf, and Inkscape image viewers.

: '''Author: '''Eric Patton

==== d.mark ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.shortcuts d.mark] is a shell script that quickly displays a marker on the display at a given coordinate.

: '''Author:''' Hamish Bowman

==== d.region.box ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.region.box d.region.box] is a shell script that quickly displays a box around the current region.

: '''Author:''' Hamish Bowman

==== d.stations ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.shortcuts d.stations] is a shell script that quickly displays vector points (or sites for GRASS 5.4 and below).

: '''Author:''' Hamish Bowman

==== d.varea ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.shortcuts d.varea] is a shell script that quickly displays vector areas.

: '''Author:''' Hamish Bowman

==== pd-GRASS ====

: [http://www.ornl.gov/sci/gist/software/grass/ pd-GRASS]: Parallel Display for GRASS GIS

: '''Author:''' Alex Sorokine

==== [[IconSymbols]] ====

* [[IconSymbols|Symbols]] which can be used with ''d.vect, d.graph'', and ''ps.map''.

=== Postscript add-ons ===

* ''See also [[ps.map scripts|ps.map samples and templates]]''.

==== ps.atlas ====

: [http://les-ejk.cz/programs/grass/ps.atlas ps.atlas] is a shell script that makes more maps on current region according to input *.psmap file. General map can be stored as vector file. The resulting *.eps maps can be automatically converted to *.pdf files.

: '''Author:''' Jachym Cepicky

==== ps.output ====

: [https://trac.osgeo.org/grass/browser/grass-addons/postscript/ps.output ps.output] is much like {{cmd|ps.map}} but with advanced decorations and ability for translucency. Here you can find a [[Ps.output|tutorial]].

: '''Author:''' Jorge Tizado

==== [[AreaFillPatterns]] ====

* Hatches for ps.map's vareas

=== wxGUI add-ons ===

===GRASS and UMN Mapserver===

* [http://www.mail-archive.com/mapserver-users@lists.umn.edu/msg00086.html See interesting posting]
* See wiki [[GRASS and MapServer]] page

==GRASS 5.x (old)==

===Vector add-ons===

* See here: http://grass.osgeo.org/download/addons.php

===Raster add-ons===

* See here: http://grass.osgeo.org/download/addons.php

* [http://www.valledemexico.ambitiouslemon.com/gwmodelling.html r.gmtg] The groundwater modelling tool for grass. A module to use MODFLOW within GRASS. '''Author''': Jaime Carrera

* [http://www.bowdoin.edu/~ltoma/research.html r.terracost] Scalable approach for computing least-cost-path surfaces on massive grid terrains. For GRASS 5.3. '''Lead author''': Laura Toma
:Newer version available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.terracost

==GRASS 4.x (very old)==

===Raster add-ons===

* MAGICAL Software: The MAGICAL software comprises a suite of three programs that provide a multi-agent simulation extension for the GRASS GIS software. http://www.ucl.ac.uk/~tcrnmar/simulation/magical/magical.html

[[Category:Community]]
[[Category:Development]]
[[Category:Documentation]]
[[Category:Installation]]

AddOns

2011-07-01T06:09:46Z

⚠️Cmbarton: /* v.lda.py */

This page contains references to user contributions and add-ons (the original GRASS GIS software can be downloaded [http://grass.osgeo.org/download/ here]).

__TOC__

== AddOns source code repository ==

The AddOns source code is hosted in [http://svn.osgeo.org/grass/grass-addons/ GRASS-AddOns SVN repository].

To checkout:

svn checkout <nowiki>https://svn.osgeo.org/grass/grass-addons/</nowiki> grass-addons

Please read [http://trac.osgeo.org/grass/wiki/HowToContribute#WriteaccesstotheGRASS-Addons-SVNrepository How to get write access to the GRASS-Addons-SVN repository] and contact the [http://lists.osgeo.org/mailman/listinfo/grass-dev grass-dev] mailing list if you would like to host your module there.

== Building and installing Addons ==

See the [[Compile and Install#Addons|compile and install]] wiki page.

In GRASS 6.4 and newer you can use the {{cmd|g.extension}} module, e.g. to install <tt>r.fuzzy.system</tt> run:

g.extension extension=r.fuzzy.system

To remove installed Addons run

g.extension extension=r.fuzzy.system operation=remove

== Adding something new ==

Please announce your add-on to the GRASS users' mailing list so that others may be aware of your work. Also please consider adding your module to one of the [[Applications]] pages.

=== Copyright and licensing information ===

''Please be sure to include copyright and licensing information in the header comments of your code so that others may know how they can use, extend, modify, and redistribute your work.''

e.g. at the top of a shell script:
<pre>
#!/bin/sh
############################################################################
#
# MODULE: v.in.e00
#
# AUTHOR(S): Markus Neteler, Otto Dassau
#
# PURPOSE: Import E00 data into a GRASS vector map
# Imports single and split E00 files (.e00, .e01, .e02 ...)
#
# COPYRIGHT: (c) 2004, 2005 GDF Hannover bR, http://www.gdf-hannover.de
#
# This program is free software under the GNU General Public
# License (>=v2). Read the file COPYING that comes with GRASS
# for details.
#
#############################################################################
#
# REQUIREMENTS:
# - avcimport: http://avce00.maptools.org

[script follows]
</pre>

=== Coding standards ===

Please have a look at our [http://grass.osgeo.org/grass63/source/SUBMITTING_SCRIPTS Shell script coding standards] before submitting here.

There are other coding standards given for modules written in C, Tcl/Tk, and Python''(?)'' located in the GRASS source code.

=== Documenting your code ===

You can have an help page template auto-generated by using the GRASS [[module command line parser | command line parser]] with the <tt>--html-description</tt> command line option. Please, see also the [http://grass.ibiblio.org/grass63/manuals/html63_user/g.parser.html g.parser help page]

== Miscellaneous Add-ons ==

* [http://trac.osgeo.org/grass/browser/grass-addons/misc/utm_which_zone utm_which_zone.sh] is a shell script to determine UTM zone from Lat/Lon input. Requires [http://www.octave.org Octave] or Matlab to be installed. A shell-only version is [http://dcalvelo.free.fr/grass/utm_which_zone_sh.sh available] which only requires awk. '''Authors''': Hamish Bowman (Octave part), Markus Neteler (shell script wrapper), Daniel Calvelo (sh+awk version)

* Perl scripts for converting data forth and back between Excel files and PostgreSQL: [http://dcalvelo.free.fr/grass/pg2xls.pl pg2xls.pl] reads data from PostgreSQL and produces an excel workbook; [http://dcalvelo.free.fr/grass/xls2sql.pl xls2sql.pl] reads excel files and outputs SQL statements to be fed into an RDBMS. Both scripts need modules from [http://www.cpan.org CPAN], especially [http://search.cpan.org/dist/Spreadsheet-ParseExcel/ Spreadsheet::ParseExcel] for xls2sql.pl and [http://search.cpan.org/~tmtm/Spreadsheet-WriteExcel-FromDB Spreadsheet::WriteExcel::FromDB] and its dependencies for pg2sql.pl. Check the source headers for more info. '''Authors:''' Daniel Calvelo (xls2sql.pl), Markus Neteler (pg2xls.pl)

* [http://dream.lrrl.arch.tu-muenchen.de/~wqual/perl/dbf2sql.tgz dbf2sql] is a Perl script for translating dbf-tables into a sql-command. dbf-tables are read using dbfdump-command from dbd-xbase-perl module ([http://search.cpan.org/~janpaz/DBD-XBase-0.241/ dbd::xbase] and [http://search.cpan.org/~jv/Getopt-Long-2.35/lib/Getopt/Long.pm getopt::long] have to be installed from CPAN first). There are problems, if the last column of the table contains characters. Suggestions for improvements welcome! '''Author:'''Wolfgang Qual

* [http://www.igc.usp.br/pessoais/guano/downloads/azimuth2.c azimuth2.c] is a small C program to calculate the azimuth and length of vector lines exported by GRASS-GIS as ASCII files (like this: v.out.ascii input=vector output=ascii format=standard). It is useful for create rose diagrams of lineament maps. Improvements on the original code after suggestions by Örs Téglásy, Hungary. '''Author:''' Carlos Henrique Grohmann

==GRASS 6.x (current)==

=== Vector add-ons ===

See also

svn co https://svn.osgeo.org/grass/grass-addons/vector

==== v.adehabitat.clusthr, v.adehabitat.kernelUD, v.adehabitat.mcp ====

: Tools to calculate home ranges of animals
: '''Author:''' Clement Calenge

Available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/vector/adehabitat

==== v.append ====

: [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.append v.append] is a shell script combining two vector files AND their associated attribute tables. The vector files should be of the same type and, for best results, should have identically formatted attribute tables.

: '''Author:''' Michael Barton

==== v.autokrige ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.autokrige/v.autokrige.py v.autokrige] achieves automatic ordinary kriging from GRASS sites (vector point data), using R with spgrass6 (RGRASS) and automap packages.

: '''Author:''' Mathieu Grelier

==== v.breach ====

: [http://www.sieczka.org/programy_en.html v.breach] creates vector maps of lines and points of continously lowering elevation down the input watercourses, based on the input raster DEM.

: '''Author:''' Maciej Sieczka

==== v.colors ====

: {{cmd|v.colors}} ''moved into main archive''

==== v.count.points.sh ====

: [http://wiki.iosa.it/dokuwiki/spatial_analysis:feature_count v.count.points.sh] counts point features in areas, generates table good as input to d.vect.chart.

: '''Author:''' Stefano Costa

==== v.digatt ====

: [http://phygeo7.geo.uni-augsburg.de/gis2/scripts/v.digatt v.digatt] (shell script) Interactively assign numeric table attributes to series of vector objects. It is meant to be effective by avoiding to type in the attribute value for all single objects again and again. The user is prompted for typing in an attribute value which is assigned to all objects selected by mouseclick afterwards. Next the display is redrawn after updating the table column. Zooming allows to change the region before the old value can be reused or a new one can be typed in (or copied by mouse from another object) in order to assign it to the next series of objects etc. It is tested not very extensively yet. Therefore better work with a copy of your map and consider using v.digit or d.what.vect -e alternatively. [http://phygeo7.geo.uni-augsburg.de/gis2/scripts/v.digatt.png screenshot].

: '''Author:''' Andreas Philipp

==== v.dip ====

: [http://marcin.slodkowski.googlepages.com/v.dip.tgz v.dip] creates points of thickness vectors from the vectors of strike and dip angles. The v.dip is the main ANSI C core program. Program so-called v.dip can run without GRASS environment.

: '''Author:''' Marcin Slodkowski

==== v.flip ====

: [http://www.sieczka.org/programy_en.html v.flip] flips the direction of selected vector lines (redundant since GRASS 6.3 - there is "v.edit tool=flip").

: '''Author:''' Maciej Sieczka

==== v.group ====

: [http://www.shockfamily.net/cedric/grass/v.group v.group] generates a new vector map with the same geometry as an existing map. The new map has categories and a table based on grouping by the values in certain columns of the existing map's table. The values in these columns are preserved in the table for the new map. It's like a v.reclass that preserves data.

: '''Author:''' Cedric Shock

==== v.in.redwg ====

: v.in.redwg imports DWG files into GRASS.

:'''Author:''' Rodrigo Rodrigues da Silva

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.in.redwg

==== v.in.gama ====

: Converts [http://www.gnu.org/software/gama/ GNU GaMa] XML output file to a GRASS vector map layer.

:'''Author:''' Martin Landa

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.in.gama

==== v.in.geodesic ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.in.geodesic v.in.geodesic] is a shell script which will create a new vector map containing a great circle line. The user may either define a beginning and end coordinate, or define a starting coordinate along with initial azimuth and desired line length.

: '''Author:''' Hamish Bowman

==== v.in.geoplot ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.in.geoplot v.in.geoplot] converts a [http://www.geoscan-research.co.uk/page9.html/ Geoplot] ASCII export file to a GRASS vector map layer.

:'''Author:''' Benjamin Ducke

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.in.geoplot

==== v.in.gshhs ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.in.gshhs v.in.gshhs] imports [http://www.soest.hawaii.edu/pwessel/gshhs/index.html GSHHS] shorelines into a GRASS vector map. GSHHS data are automatically reprojected to the current location.

:'''Authors:''' several, updated to GRASS 6 by Markus Metz

==== v.in.marxan ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.in.marxan v.in.marxan] is a python script that imports Marxan output data for display in a vector grid file prepared using v.out.marxan.
: ''see also the [http://www.uq.edu.au/marxan/ Marxan]

: '''Author:''' Trevor Wiens

==== v.in.mbsys_fnv ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.in.mbsys_fnv v.in.mbsys_fnv] imports [[MB-System]] navigation files into a GRASS vector map. You can choose from swath area coverage, track lines (including outer port/starboard edges), all bounds as points, etc. An attribute database is created containing the vital statistics of the specified feature such as track length or swath coverage (geodesic), start stop time and location, pitch, roll, heave, etc. See also the [[#v.in.p190]] addon.

:'''Author:''' Hamish Bowman

==== v.in.ncdc ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.in.ncdc v.in.ncdc] imports an [http://www.ncdc.noaa.gov NCDC] stn file (station data) into a GRASS vector map.

: '''Author:''' Huidae Cho

==== v.in.postgis ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.in.postgis/v.in.postgis.py v.in.postgis] Create a GRASS layer from any sql query on PostGIS data.

: '''Author:''' Mathieu Grelier

==== v.in.osm ====

: [http://kripton.kripserver.net/software/v.in.osm/ v.in.osm]: OpenStreetMap import into GRASS. Yet only supports deprecated API 0.4, will be modified to work with API 0.5 some time soon.

: '''Author:''' Jannis Achstetter

: See also [http://hamish.bowman.googlepages.com/gpsdrivefiles#osm osm2grass.sh] by H Bowman

==== v.in.osm2 ====

: [https://trac.osgeo.org/grass/browser/grass-addons/vector/v.in.osm2 v.in.osm2]: OpenStreetMap import into GRASS. Supports current API 0.6, downloads using the [http://wiki.openstreetmap.org/wiki/Xapi Xapi] interface and imports using GpsBabel 1.3.5 or newer. GpsBabel restricts to either nodes or ways being imported at a time, not both. Use {{cmd|v.patch}} to rejoin them. (''work in progress'')

: '''Author:''' Hamish Bowman

==== v.in.ovl ====

: [http://grasslab.gisix.com/scripts/v.in.ovl/ v.in.ovl] is a shell script that imports an ASCII vector file created with TOP10|25|50 or similar products.

: '''Author:''' Peter Löwe

==== v.in.p190 ====

: [https://trac.osgeo.org/grass/browser/grass-addons/vector/v.in.p190 v.in.p190] is a shell script that imports 'Centre of Source' "S" navigation data from seismic P1/90 (UKOOA) data files and writes it either GRASS vector points or vector lines format. Optionally it will export the navigation data into .csv text files as well. ''Currently in the functional prototype stage, some assembly is required. See inside the shell script for details.'' For working with SEG-Y data, see also the [[#v.in.mbsys_fnv]] addon.

: '''Author:''' Hamish Bowman

==== v.krige ====

: [[V.krige_GSoC_2009 | v.krige]] aims to integrate R functions for kriging (packages automap, gstat, geoR) in a trasparent way. '''Moved into trunk/devbr6 code (r40048)'''

: '''Author:''' Anne Ghisla, as Google Summer of Code 2009 project

: See also [[GRASS_AddOns#v.autokrige]] by Mathieu Grelier

==== v.lda.py ====

: [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.lda.py v.lda.py] is a Python script for calculating Ian Johnson's (U. Sidney) Local Density Analysis values. This can be used in two ways. When only one vector points file is entered, it serves to measure clustering of point data at different neighborhood radii. When two different point files are entered, it measures the the co-occurence of the points from the two files. There is an option to export the data into a cvs format file for easy plotting in a spreadsheet or statistical program like R.

==== v.line.center ====

: [http://www.sieczka.org/programy_en.html v.line.center] creates a points vector map with each point located in the middle of the length of the input vector line.

: '''Author:''' Maciej Sieczka

==== v.lmeasure ====

: [http://ngeo.de/grassstuff/v.lmeasure v.lmeasure] and [http://ngeo.de/grassstuff/v.revlmeasure v.revlmeasure] are two perl scripts that place equidistant vector points along a given arbitrary vector line starting from the beginning or end of the vector line, respectively. Resulting vector points are labeled with the distance from origin.

: '''Author:''' Mats Schuh

==== v.mkhexgrid ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.mkhexgrid v.mkhexgrid] is a python script that creates a hexagonal grid the size of the selected region using user specified side lengths.

: '''Author:''' Trevor Wiens

==== v.out.ascii.db ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.out.ascii.db v.out.ascii.db] is a shell script for exporting vector point data coordinates and selected attribute columns to either a file or to the console.
: ''Superseded in GRASS 6.4 by the new v.out.ascii columns= option.''

: '''Author:''' Hamish Bowman

==== v.out.ascii.mat ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.out.ascii.mat v.out.ascii.mat] is a shell script for exporting vector polygon and polyline data into an ASCII text file suitable for loading into Matlab (or [http://www.gnu.org/software/octave/ Octave]).

: '''Author:''' Hamish Bowman

==== v.out.gmt ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.out.gmt v.out.gmt] is a shell script that exports a polygon vector file into GMT xy file. psbasemap code was copied from Hamish's r.out.gmt.

: '''Author:''' Huidae Cho, Hamish Bowman, Dylan Beaudette

==== v.out.kml ====

: [http://grasslab.gisix.com/scripts/v.out.kml/ v.out.kml] is a shell script that exports a vector file into a KML file for Google Earth or Worldwind. see also [[#r.out.kml|r.out.kml]] and [[#r.out.gmap|r.out.gmap]]

: '''Author:''' Peter Löwe

==== v.out.marxan ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.out.marxan v.out.marxan] is a python script that prepares vector layers and exports GRASS vector attributes and adjacency information as Marxan input files. Output from Marxan simulations can be imported using v.in.marxan.
: ''see also the [http://www.uq.edu.au/marxan/ Marxan]

: '''Author:''' Trevor Wiens

==== v.out.svg ====

: [http://svg.cc/grass/index.html v.out.svg] is a module that exports SVG notation along with optional attribute data directly from GRASS 6.x vector layers. Now part of [http://svn.osgeo.org/grass/grass/trunk/vector/v.out.svg/ grass6-svn].

: '''Author:''' Klaus Förster

==== v.points.cog ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.points.cog v.points.cog] is a shell script which will create a new point at the center of gravity of each cluster of input points or centroids, grouped by attribute. Among other things this is useful for labeling swarms of points.

: '''Author:''' Hamish Bowman

==== v.profile ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.profile v.profile] is vector map profiling tool similar to r.profile. This module will print out distance and attributes to points/lines along profiling line. It's also usefull to determine places where raster profile crosses vector features (i.e. where to place river marker on river walley crossection).

: '''Author:''' Maris Nartiss

==== v.random.cover ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.random.cover v.random.cover] is a shell script for creating random points constrained within an irregularly shaped vector area. (v.random places points only in current region rectangle). Optionally the user can upload raster values at the points. See also '<tt>r.random cover= vector_output=</tt>'

: '''Author:''' Hamish Bowman

==== v.rasterbounds ====

: [http://les-ejk.cz/programs v.rasterbounds] is a shell script for creating polygon-vector file of rasterfile boundaries. The best version of GRASS is 6.1+. If you are using GRASS < 6.1, you have to be in the same mapset as your raster maps are from.

: '''Author:''' Jachym Cepicky

==== v.rast.stats2 ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.rast.stats2 v.rast.stats2] is an adapted version of the GRASS module v.rast.stats. It uses the grass addon [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.univar.zonal r.univar.zonal] to speed up calculation of univariate statistics from a GRASS raster map based on vector polygons.

: '''Authors:''' Markus Neteler, Otto Dassau

==== v.sample.buffer [Currently unavailable. Being re-written in python. Target for inclusion in addons svn is January 2011]====
v.sample.buffer is a shell script that samples rasters in buffers of a specified size around features in a specified vector file. Sampling results are added as attributes to the vector file. This script was designed for sampling vegetation indices and DEM derived attributes for bird point counts. Sampling results can be one or more basic statistics such as mean, range, max, etc.

: '''Author:''' Trevor Wiens

==== v.select.region ====

: [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/v.select.region.tar.bz2 v.select.region] is a shell script that prints out the names of all vectors matching an input search pattern that has geometry (points, line, areas) that fall within a region bounded by an existing vector map, or within the current Grass region.

: '''Author:''' Eric Patton

==== v.selmany ====

: [http://svn.osgeo.org/grass/grass-addons/vector/v.selmany/v.selmany v.selmany] is a shell script that allows to interactively select a set of vector objects on a given layer, then assign them attribute values in a connected database table. The script runs on the command line prompt and within a graphic monitor ; it does not work with DBF driver.

: '''Author:''' Vincent Bain

==== v.surf.icw ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.surf.icw v.surf.icw] is an IDW interpolation method using true distance cost instead of euclidean shortest distance, i.e. ''as the fish swims around an island'' not ''as the bird flies''. This will cleanly travel around hard barriers and a cost surface map may be used to model expensive-cross barriers. Input data points do not need direct line of sight to be considered, but should be kept to less than one hundred as the module becomes very computationally expensive. A number of radial basis function options are available. ([http://grass.osgeo.org/wiki/Image:Inlets_03_SurfSal_icw_big.png screenshot])

: '''Author:''' Hamish Bowman

==== v.surf.idwpow ====

: [http://www.geospatial.it/allegri/grass/v.surf.idwpow.zip v.surf.idwpow] integrates the common v.surf.idw algorithm with the exponential parameter for the distance weights

: '''Author:''' Giovanni Allegri

==== v.surf.krige [deprecated: use v.autokrige instead] ====

: v.surf.krige is a script that do a surface interpolation from vector point data by Kriging method. The interpolated value of a cell is determined by using an omnidirectional variogram model fitted starting from model parameter given by user shown from the experimental semi variogram produced by v.variogram. The script can perform also the Leave-One-out cross validation to test the variogram model "fitted by eye" and an automatic fitted variogram model. The cross validation helps the user to choose the best variogram model to interpolate own data.

: '''Author:''' Pierluigi De Rosa.

==== v.strahler ====

: [http://www.pois.org/florian/downloads/grass/v.strahler.tgz v.strahler] is a module that calculates the Strahler Order for all lines of a given dendritic network.

: '''Author:''' Florian Kindl. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.strahler

==== v.swathwidth ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.swathwidth v.swathwidth] creates a vector map representing the sea bottom coverage of a multibeam (swath) sonar survey.
: ([http://david.p.finlayson.googlepages.com/swathwidth Screenshots])

: '''Authors:''' David Finlayson, Hamish Bowman

==== v.thickness ====

: [http://marcin.slodkowski.googlepages.com/v.thickness.tgz v.thickness] creates points of thickness vectors from the vectors of strike and dip angles.The v.thickness is GUI GRASS script for v.dip.

: '''Author:''' Marcin Slodkowski

==== v.transect.kia ====

: [https://svn.osgeo.org/grass/grass-addons/vector/v.transect.kia v.transect.kia] calculates kilometric abundance indexes (KIA), a common indirect presence index used in wildlife monitoring along line transect surveys.
: Path lenghts can be corrected by draping on a DEM, different type of point objects can be weighted according to their relative importance, and paths can be segmented using a further polygon vector (to calculate, say, abundances per elevation range or per habitat class).
: The module is written in bash and needs a GRASS install compiled with sqlite support.

: '''Author:''' Clara Tattoni and Damiano G. Preatoni

==== v.trees3d ====

: [http://les-ejk.cz/programs/ v.trees3d] is a module for making 3D trees from input vector point file.

: '''Author:''' Jachym Cepicky

==== v.trimesh ====
: [http://www.valledemexico.ambitiouslemon.com/vtrimesh.html v.trimesh] creates a triangular mesh from a vector map using areal constraints for refinement. It uses Jonathan Shewchuk's Triangle library.

: '''Author:''' Jaime Carrera

==== v.what.rast.buffer ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.what.rast.buffer v.what.rast.buffer] is a script that calculates univariate statistics of raster map(s) from buffers around vector points. Results are written to a file. Resolution is taken from each input map.
: ''see also the [http://starspan.casil.ucdavis.edu StarSpan] software

: '''Author:''' Hamish Bowman

==== v.variogram [deprecated: use v.autokrige instead] ====

: v.variogram is a script that create an omnidirectional experimental semi-variogram. This scripts require R-statistics software installed on your machine. Now the script is updated to run on spgrass6 >= 0.3 and sp >= 0.9 [http://grass.osgeo.org/pipermail/statsgrass/2006-October/000455.html reply].

: '''Author:''' Ivan Marchesini, Pierluigi De Rosa.

==== v.vect.stats ====

: [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.vect.stats v.vect.stats] counts the number of points falling into each polygon and optionally calculates statistics from numeric point attributes for each polygon. v.vect.stats is a C module and works with GRASS 6.4 and higher (see enclosed patches for 6.5 and 7.0).

: '''Author:''' Markus Metz

==== AniMove ====

: [http://www.faunalia.it/animov/ AniMove] is software for analysis of animal movement and ranging behaviour using QGIS+GRASS+R.

:'''Authors:''' Support by Faunalia.it

==== Utilities ====

===== Shapemerge =====

: [http://perrygeo.googlecode.com/svn/trunk/gis-bin/shpmerge.sh shpmerge] merges all the shapefiles in the current directory into a single output shapefile

:'''Authors:''' Perrygeo

=== Raster add-ons ===

See also

svn co <nowiki>https://svn.osgeo.org/grass/grass-addons/raster</nowiki>

==== Raplat ====

GRASS-RaPlaT: The Radio Planning Tool for GRASS GIS system developed by support of Slovenian largest mobile operator Mobitel. It is especially designed for radio coverage calculation of GSM/UMTS systems, but can be applied also to other wireless systems in the frequency range 400 MHz – 2.4 GHz (e.g. TETRA, WiFi). Its structure is modular and characterized by high level of flexibility and adaptability.

* Documentation: http://commsys.ijs.si/en/component/content/article/54-software/149-user-manual
* Software: http://commsys.ijs.si/en/software/grass-raplat

: '''Author:''' Department of Communication Systems, Jozef Stefan Institue, Jamova 39, SI-1000 Ljubljana, Slovenia

==== r.area ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.area r.area] Very simple module. Calculate area size (in cells) for every individual category in input raster map and write number of cells as the value of each cell in the area. Optionally write a binary coverage map and set a minimum area threshold. Works well with {{cmd|r.clump}}.

: '''Author:''' Jarek Jasiewicz

==== r.basin ====

: [http://svn.osgeo.org/grass/grass-addons/raster/r.basin/ r.basin] Generates the main morphometric parameters of the basin starting from the digital elevation model and the coordinates of the basin's closing section.

: '''Author:''' Margherita Di Leo, Massimo Di Stefano

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.basin/

==== r.bilateral ====

: [http://les-ejk.cz/files/programs/grass/r.bilateral.tgz r.bilateral] Bilateral filter is an edge-preserving filter, which combines domain and range filtering. It is written in C language.

: '''Author:''' Jachym Cepicky

==== r.broscoe ====

r.broscoe.sh calculates waerden test and t test statistics for some values of threshold area on a single basin, according to A.J.Broscoe theory (1959).
See v.strahler package

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.strahler/

==== r.boxcount ====

: r.boxcount and r.boxcount.sh calculate the fractal dimension for a given map. These are versions for grass6 of [http://www.ucl.ac.uk/~tcrnmar/ Mark Lake's modules] for grass43.

: '''Authors:''' Mark Lake, grass6 port: Florian Kindl.

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.boxcount/
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.boxcount.sh/

==== r.burn.frict ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.burn.frict r.burn.frict] converts vector geometries to raster cells, using a simple anti-aliasing method to close "gaps" between diagonal cells. Useful for "burning" vector geometries into a friction surface, making sure that simulated movement does not "slip" through converted cells that have only diagonal neighbours.

:'''Author:''' Benjamin Ducke

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.burn.frict

==== r.clump2 ====

: [https://trac.osgeo.org/grass/browser/grass-addons/raster/r.clump2 r.clump2] is a C module similar to r.clump. Differences are: diagonally adjacent cells are also clumped but can be excluded, NULL (nodata) cells are always excluded, and selective clumping with start coordinates is supported.

: '''Author:''' Markus Metz

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.clump2

==== r.colors.out_vtk ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.colors.out_vtk r.colors.out_vtk] is a shell script used to export the color table associated with a raster map layer to a {{wikipedia|VTK}} XML file. (see also [[Help with 3D]])

: '''Author:''' Hamish Bowman

==== r.colors.quantiles ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.colors.quantiles/r.colors.quantiles r.colors.quantiles] is a shell script used to create raster colors rules based on nquantiles. It uses R and spgrass6 package (RGRASS).

: '''Authors:''' Mathieu Grelier

==== r.colors.stddev ====

: [http://hamish.bowman.googlepages.com/grass_color_maps r.colors.stddev] ''moved into main archive''

==== r.convergence ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.convergence r.convergence] calculate topographic convergence index, useful to detect lineamets represented by chanell/ridge system

: '''Author:''' Jarek Jasiewicz

==== r.cpt2grass ====

: [http://hamish.bowman.googlepages.com/grass_color_maps r.cpt2grass] is a GRASS script for importing a [http://www.soest.hawaii.edu/gmt/ GMT] .cpt color table into GRASS. It can save to a text file suitable for r.colors or automatically apply the color table to a raster map. For a large collection of GMT .cpt files see http://sview01.wiredworkplace.net/pub/cpt-city/
: Other palette ideas from [http://geography.uoregon.edu/datagraphics/color_scales.htm Univ. Oregon] and [http://oceancolor.gsfc.nasa.gov/PRODUCTS/colorbars.html NASA/Goddard's OceanColor] (latter partially translated for use with GRASS on the [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.colors.tools/palettes grass-addons SVN]).

: '''Author:''' Hamish Bowman

==== r.csr ====

: [https://svn.osgeo.org/grass/grass-addons/raster/r.csr r.csr] integrates several Grass programs to produce colored, shaded-relief rasters in one step. Accepts single or multiple elevation/bathymetry maps as input; optionally will fill data holidays with 3x3 median filter, multiple times, if required; can apply color maps from a) input raster, b) another raster in MAPSET, or c) from a rules file; otherwise, rainbow colorbar is applied. Output colored, shaded-relief rasters can optionally be exported to tiff format if the appropriate flag is given. Shading parameters can be modified, though useful defaults are given.

: '''Author:''' Eric Patton

==== r.cva ====

: [http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html r.cva] is a cumulative viewshed analysis module. It is an advanced version of the {{cmd|r.los}} program.

: '''Author:''' [http://www.ucl.ac.uk/~tcrnmar/ Mark Lake]

==== r.denoise ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.denoise r.denoise] denoises (smooths/despeckles) topographic data, particular DEMs derived from radar data (including SRTM), using Xianfang Sun's [http://www.cs.cf.ac.uk/meshfiltering/index_files/Page342.htm denoising algorithm]. It is designed to preserve sharp edges and to denoise with minimal changes to the original data. See the [http://personalpages.manchester.ac.uk/staff/john.stevenson/mdenoise/r.denoise.html manual pages] for details. Further information on Sun's denoising algorithm, including an example, is available [http://personalpages.manchester.ac.uk/staff/john.stevenson/mdenoise here].

: '''Author:''' John Stevenson

==== r.dominant_dir.m and r.calc_terraflow_dir.m ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.terraflow.tools dominant_dir.m and calc_terraflow_dir.m] are two Matlab scripts for determining the dominant flow direction from a r.terraflow MFD map and converting into a GRASS aspect map for use with d.rast.arrow, etc.

: '''Author:''' Hamish Bowman

==== r.diversity ====
: [http://svn.osgeo.org/grass/grass-addons/raster/r.diversity/ r.diversity] calculates selected diversity indices by calling various r.li commands.This script uses the [http://grass.osgeo.org/grass64/manuals/html64_user/r.li.pielou.html Pielou], [http://grass.osgeo.org/grass64/manuals/html64_user/r.li.renyi.html Renyi], [http://grass.osgeo.org/grass64/manuals/html64_user/r.li.shannon.html Shannon] and [http://grass.osgeo.org/grass64/manuals/html64_user/r.li.simpson.html Simpson] indices. The output is a map for each index.

: '''Author:''' Luca Delucchi, Duccio Rocchini

==== r.eucdist ====

: [http://david.p.finlayson.googlepages.com/r.eucdist r.eucdist] creates a raster map estimating the euclidean distance from known cells.

: '''Author:''' David Finlayson

==== r.fragment ====

: [http://www.chrisgarstin.com/stuff/r.fragment r.fragment] fragments a raster into a user-defined set of smaller tiles according to an input number of rows and columns.
: '''Author:''' Eric Patton

==== r.fuzzy ====
: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.fuzzy r.fuzzy] Calculates membership of every cell in raster according membership function defined by user.
: '''Author:''' Jarek Jasiewicz

==== r.fuzzy.logic ====
: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.fuzzy.logic r.fuzzy.logic] Perform fuzzy operators (AND, OR, NOT, IMP) on membership's map using T-norms and T-conorms for 6 most popular families.
: '''Author:''' Jarek Jasiewicz

==== r.fuzzy.system ====
: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.fuzzy.system r.fuzzy.system] Perform full fuzzy clasificationwith 6 most popular fuzzy logic families and few methods of deffuzification.
: '''Author:''' Jarek Jasiewicz

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.fuzzy.system

==== r.game_of_life ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.game_of_life r.game_of_life] is a shell script which runs Conway's classic Game of Life using GRASS raster modules. It is meant to demonstrate how easy it is to program cellular automata in GRASS as well as various 3D raster volume and time series visualization techniques.

: '''Author:''' Hamish Bowman

==== r.gauss ====

: [http://www.les-ejk.cz/files/programs/grass/r.gauss.tgz r.gauss] is Gaussian and Laplacian of Gaussian filter for GRASS. It is written in C language.

:'''Author:''' Jachym Cepicky

==== r.gradgrid4 ====

: [http://www.uibk.ac.at/geographie/personal/mergili/gradgrid4.zip gradgrid4] is a tool for interpolating values of discrete data points to a raster map, applying a local regression approach with a predictor raster. The model is based on shell and python scripts as well as an R batchfile. It was tested on Fedora Core 6 with GRASS 6.2.1 and R 2.5.1, but should work under most UNIX systems. After unzipping the gradgrid4 folder, store it at any place in your local file system. In the subfolder docs you can find a manual and a publication draft with a detailed description of the concept and the example of an application. The subfolder testloc constitutes a GRASS location with test data.

: '''Author:''' Martin Mergili

==== r.hazard.flood ====

: [http://svn.osgeo.org/grass/grass-addons/raster/r.hazard.flood/ r.hazard.flood] is an implementation of a fast procedure to detect flood prone areas. The exposure to flooding may be delineated by adopting a topographic index (TIm) computed from a DEM. The portion of a basin exposed to flood inundation is generally characterized by a TIm higher than a given threshold, tau. The threshold is automatically determinated from the cellsize. The proposed procedure may help in the delineation of flood prone areas especially in basins with marked topography. The use of the modified topographic index should not be considered as an alternative to standard hydrological-hydraulic simulations for flood mapping, but it may represent a useful and rapid tool for a preliminary delineation of flooding areas in ungauged basins and in areas where expensive and time consuming hydrological-hydraulic simulations are not affordable or economically convenient.

: '''Author:''' Margherita Di Leo

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.hazard.flood/

==== r.in.mb ====

: [http://blogs.tekmap.ns.ca/archives/458 r.in.mb] is a "GRASS/[[MB-System]] program designed to import ''mbio'' compatible multibeam sonar data directly into the GRASS GIS. The program is a modified version of {{cmd|r.in.xyz}}. Instead of reading an ASCII XYZ file, ''r.in.mb'' reads an MB-System compatible list file." It can do automatic reprojection and minor hole filling. The default is to import bathymetry data, but optionally amplitude or sidescan sonar data can be loaded instead.

: '''Author:''' Bob Covill

==== r.in.onearth ====

: [http://www-pool.math.tu-berlin.de/~soeren/grass/modules/ r.in.onearth] for download and import satellite images direct from the NASA onearth WMS server into GRASS.

: '''Author:''' Soeren Gebbert

==== r.in.swisstopo ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.in.swisstopo/ r.in.swisstopo] for importing swisstopo digital elevation model data into GRASS raster maps.

: '''Author:''' Jürgen Hansmann

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.in.swisstopo/

==== r.in.wms (.py) ====

: [http://les-ejk.cz/files/programs/grass/r.in.wms.tgz r.in.wms] for download and import maps direct from WMS servers into GRASS. This script is written in Python Programming language. Note GRASS 6.2+ provides a shell script version of r.in.wms, take care of which one is actually being run.

: '''Author:''' Jachym Cepicky

==== r.inund.fluv ====

: [https://svn.osgeo.org/grass/grass-addons/raster/r.inund.fluv/ r.inund.fluv]This command allows to obtain a fluvial potentially inundation map given a high-resolution DTM of the area surrounding the river and a water surface profile calculated through an 1-D hydrodinamic model.

: '''Authors:''' Roberto Marzocchi, Bianca Federici, Domenico Sguerso

==== r.isoregions ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.isoregions/r.isoregions r.isoregions] allows isoregions creation from a GRASS raster map.

: '''Authors:''' Mathieu Grelier

==== r.interp.mask ====

: [http://david.p.finlayson.googlepages.com/r.interp.mask r.interp.mask] Creates a user-specified buffer around interpolation points that can be used as a MASK to prevent or clip excessive extrapolation artifacts. This works much better than a standard convex hull around the points.

: '''Author:''' David Finlayson

==== r.ipso ====

: [http://svn.osgeo.org/grass/grass-addons/raster/r.ipso/ r.ipso] Produces the ipsometric and ipsographic curve related to a digital elevation model and prints the percentiles

: '''Authors:''' Margherita Di Leo, Massimo Di Stefano, Francesco Di Stefano

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.ipso/

==== r.li ====

: [http://www.faunalia.it/download/r_li/ r.li] is a more flexible and faster replacement of the old r.le. '''''Moved into 6.3-SVN'''''.

: '''Authors:''' Claudio Porta, Davide Spano, Serena Pallecchi, [http://www.faunalia.it Faunalia]

==== r.local_max.pl ====

: [http://les-ejk.cz/files/programs/local_max.pl Local maxima] is a Perl script for <code>r.mapcalc</code>. It detects local maxima of the image.

: '''Author:''' Jachym Cepicky

==== r.mandelbrot ====

: [http://grasslab.gisix.com/scripts/r.mandelbrot r.mandelbrot] is a shell script to calculate the Mandelbrot set.- for GRASS versions 6.X.

: '''Author:''' Peter Löwe

==== mcda====

: mcda suite is a toolset for geographics multi-criteria decision aiding and data analysis based on ELECTRE (r.mcda.electre), REGIME (r.mcda.regime) and FUZZY (r.mcda.fuzzy) algorithm. The module r.roughset is also included for geographics rough set analisys and knowledge discovery based on rough set library. It is written in C language for GRASS versions 6.X.

: '''Author:''' Gianluca Massei (g_massa@libero.it ) - Antonio Boggia

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/mcda/

==== r.mlv ====

: [http://les-ejk.cz/files/programs/grass/r.mlv.tgz r.mlv] is Mean of least variance filter for GRASS. It is an edge-preserving (or even edge-enhacing) filter, which should serve for removing additive noise from images. It is written in C language.

: '''Author:''' Jachym Cepicky

==== r.obstruction, r.planning.static, r.planning.cinematic ====

: [http://www.ing.unitn.it/~grass/software.html r.obstruction, r.planning.static, r.planning.cinematic]: r.obstruction creates a polar obstruction map from a DTM. r.planning.static performs a static planning for GPS and Glonass surveys using the obstruction map created with r.obstruction. r.planning.cinematic performs a cinematic planning for GPS and Glonass surveys. (University of Trento, Faculty of Engineering)

: '''Author:''' Daniele Carli, Dimitri D'Inca', Gianluca Fruet, Domenico Sguerso, Paolo Zatelli

==== r.out.jpeg ====

: [http://www.geospatial.it/allegri/grass/r.out.jpeg_ r.out.jpeg] is a simple GRASS script to export georeferenced JPEG images from rasters, keeping the associated color table. It is a two-step export: first a ppm file is created, then it is converted to jpeg usgin the "convert" command from ImageMagick

: '''Author:''' Giovanni Allegri

==== r.out.gmap ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.out.gmap r.out.gmap] outputs GRASS raster map into set of image tiles
following the tiling scheme of Google Maps and Microsoft Virtual Earth. Read more in the OSGeo Journal [http://www.osgeo.org/journal Volume 5 (2009, to appear)] see also [[#r.out.kml|r.out.kml]] and [[#v.out.kml|v.out.kml]]

: '''Author:''' Tomas Cebecauer

==== r.out.gmt ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.out.gmt r.out.gmt] is a GRASS script for exporting a GRASS raster map into a [http://www.soest.hawaii.edu/gmt/ GMT] grid file. It also creates a GMT color table from the data and can generate some GMT commands for plotting a postscript file. (code is experimental, but functional) see also http://169.237.35.250/~dylan/grass_user_group/#GMT_and_GRASS-overview

: '''Authors:''' Hamish Bowman, Dylan Beaudette

==== r.out.gmt2 ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.out.gmt2 r.out.gmt2] is a modified version of Hamish's r.out.gmt. Added options for title, xlabel, ylabel, comment, and map width. Removed any settings that can be changed by gmtset for more flexibility.

: '''Author:''' Huidae Cho, Hamish Bowman, Dylan Beaudette

==== r.out.kap_template ====

: [https://trac.osgeo.org/grass/browser/grass-addons/raster/r.out.kap_template r.out.kap_template] is a shell script that exports a raster map into a GeoTiff and a metadata text file suitable for use with KAP (BSB) raster nautical chart converter programs such as <tt>tif2bsb</tt> (after verifying that you are legally entitled to use such a tool).
: '''''This is EXPERIMENTAL software. NOT FOR NAVIGATIONAL USE.'''''
: For an easy to use data viewer, see also the [http://www.opencpn.org OpenCPN] free navigational software.

: '''Author:''' Hamish Bowman

==== r.out.kml ====

: [https://trac.osgeo.org/grass/browser/grass-addons/raster/r.out.kml r.out.kml] is a shell script that exports a raster map into a KML file and image for Google Earth or Worldwind. See also [[#v.out.kml|v.out.kml]] and [[#r.out.gmap|r.out.gmap]].

: '''Author:''' Hamish Bowman

==== r.pack ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.pack r.pack] and [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.unpack r.unpack] are two GRASS scripts for transferring raster maps to another computer as a single compressed file including color table etc.
: An earlier version has been renamed as [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.pack/experiment r.pack.mat] and [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.unpack/experiment r.unpack.mat].

: '''Author:''' Hamish Bowman

==== r.pi ====

: [https://svn.osgeo.org/grass/grass-addons/raster/r.pi/ r.pi] (raster patch index) provides various functions to analyse spatial attributes of a landscape. It has a focus on patch-based indices but delivers class-based indices as well. r.le and its successor r.li provide landscape indices.

: '''Authors:''' Programming: Elshad Shirinov, Scientific concept: Dr. Martin Wegmann

==== r.prominence ====

: '''r.prominence''' calculates the average difference between a central cell and its neighbors. It approximated the terrain 'ruggedness' by looking at average differences in elevation within a given neighborhood.

: '''Author:''' Benjamin Ducke

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.prominence/

==== r.refine ====

: [http://www.bowdoin.edu/~ltoma/research.html r.refine]: reduces a DEM to a TIN (takes as input a grid DEM and an error margin and simplifies it to the desired accuracy into a TIN)
Available via the source code repository [https://github.com/jonrtodd/r.refine]
: '''Authors:''' Laura Toma and Jonathan Todd

==== r.rifs ====

: [http://www.ucl.ac.uk/~tcrnmar/ r.rifs]: r.rifs generates a raster map and/or image of a fractal by means of the specified random iterated function system.

: '''Author:''' Mark Lake

==== r.roughness ====

[http://trac.osgeo.org/grass/browser/grass-addons/raster/r.roughness/r.roughness.sh r.roughness.sh] is a shell script to calculate the surface roughness of a DEM, using r.surf.area and v.surf.rst. (for GRASS versions 6.1 and above)

[http://www.igc.usp.br/pessoais/guano/downloads/r.roughness60 r.roughness60] - for GRASS versions 6.0.X

[http://trac.osgeo.org/grass/browser/grass-addons/raster/r.roughness/r.roughness.window.area r.roughness.window.area] - calculate surface roughness as the ratio of real (surface) area and planar area, using a moving-window approach.

[http://trac.osgeo.org/grass/browser/grass-addons/raster/r.roughness/r.roughness.window.vector r.roughness.window.vector] - calculate surface roughness as vector dispersion, using a moving-window approach. Resulting maps are: Vector Strength (R) and Inverted Fisher's k parameter.

[http://trac.osgeo.org/grass/browser/grass-addons/raster/r.roughness/r.roughness.window.vector.html r.roughness.window.vector.html] - provisional help page for r.roughness.window.vector.

: '''Author:''' Carlos Henrique Grohmann

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.roughness/

==== r.roughset ====

: r.roughset is a module for geographics rough set analisys and knowledge discovery based on rough set library. It is written in C language for GRASS versions 6.X.

: '''Author:''' Gianluca Massei (g_massa@libero.it ) - Antonio Boggia

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/mcda/r.roughset/

==== r.seg ====

: '''r.seg''' performs image segmentation and discontinuity detection (based on the Mumford-Shah variational model).
: The module generates a piece-wise smooth approximation of the input raster map and a raster map of the discontinuities of the output approximation. The discontinuities of the output approximation are preserved from being smoothed.
: See [http://www.ing.unitn.it/~vittia/sw here] for details and examples.

Available [http://www.ing.unitn.it/~vittia/sw here] and with improvements via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.seg/

: '''Author''' Alfonso Vitti

==== r.smoothpatch ====

: [http://david.p.finlayson.googlepages.com/r.smoothpatch r.smoothpatch] creates a composite of two rasters using a distance-weighted average across the transition to smooth the edges.

: '''Author:''' David Finlayson

==== r.soils.texture ====

: r.soils.texture is a module to define soils texture from sand and clay raster file with a schema text file (now FAO,USDA and ISSS are available). It is written in C language. - for GRASS versions 6.x - For bugs and suggest: g_massa@libero.it

:'''Author:''' Gianluca Massei

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.soils.texture/

==== r.stack ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stack r.stack] is a shell script used to patch all the raster maps in a time series (or burst 3D raster) together into a vertical stack, to aid mutli-map analyses in modules where group input is not yet available.

: '''Author:''' Hamish Bowman

==== r.stream.angle ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.angle r.stream.angle] Divide stream network into stright line segments according users input. It extends Module uses as input direction and stream netwokr map produced by r.watershed and stream.extract or custom user input. See description for details.

: '''Author:''' Jarek Jasiewicz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.angle

==== r.stream.basins ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.basins r.stream.basins] delineate basins according users input. It extends r.water.outlet funcionality to extracting more than one basin at one step. Module uses as input direction map produced stream network produced by r.stream.extract, r.watershed, r.stream order or custom user input. More in tutorial on grass-wiki pages.

: '''Author:''' Jarek Jasiewicz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.basins

==== r.stream.del ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.del r.stream.del] Calculates downslope length of first order streams and delete them if it length (in pixels) is lower than the treeshold. It also join false segments left by deletion into one with category of upper. It uses r.watershed direction map and r.watershed stream map as input. The module is added only for r.watershed module, r.stream.extract has deleting short streams build-in. During development of r.stream.* it will be probably abandoned due to duplicate functionality

: '''Author:''' Jarek Jasiewicz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.del

==== r.stream.distance ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.distance r.stream.distance] Calculates downslope distance and downslope elevation difference between current cell and stream or outlet cells. It uses r.watershed direction map, r.watershed or r.stream.extract stream map and optionally DEM as input.

: '''Author:''' Jarek Jasiewicz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.distance

==== r.stream.extract ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.extract r.stream.extract] extracts topologically clean stream networks from input elevation and optionally accumulation maps. Output is available as raster and vector and can be used as input for the other r.stream.* modules by Jarek Jasiewicz.

: '''Author:''' Markus Metz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.extract

==== r.stream.order ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.order r.stream.order] orders stream network outputed by r.watershed or r.stream.extract according Sthrahler, Shreve, Horton and Hack ordering systems. It require as input stream and direction map and optionally accumulation map. It handle both SFD nad MFD modes but all data must come from the same procedure.

: '''Author:''' Jarek Jasiewicz, Markus Metz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.order

==== r.stream.pos ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.pos r.stream.pos] Helper module for calculating local stream network properties and linear geostatistics. Mostly To use with R and other grass modules.

: '''Author:''' Jarek Jasiewicz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.pos

==== r.stream.stats ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.stats r.stream.stats] calculate Hortonian statistics for Stahler or Horton stream network created by r.stream.order. It uses r.watershed direction map, DEM and r.stream.order's Stahler or Horton stream network as input. It outputs calculated statistics to standard output.

: '''Author:''' Jarek Jasiewicz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.stream.stats

==== r.surf.nnbathy ====

: [http://www.sieczka.org/programy_en.html r.surf.nnbathy] interpolates a surface from a raster input using Pavel Sakov's [http://code.google.com/p/nn-c/ nn] natural neighbor interpolation library. Provides triangulation, Sibson natural neighbor interpolation and non-Sibsonian interpolation.

: '''Author:''' Maciej Sieczka

==== r.surf.volcano ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.surf.volcano r.surf.volcano] creates an artificial surface resembling a seamount or cone volcano. The user can alter the size and shape of the mountain and optionally roughen its surface. Available decay functions are polynomial, Gaussian, Lorentzian, logarithmic, and exponential.

: '''Author:''' Hamish Bowman

==== r.terracost ====

[http://www.bowdoin.edu/~ltoma/research.html r.terracost] Scalable approach for computing least-cost-path surfaces on massive grid terrains. '''Lead author''': Laura Toma

Available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.terracost

==== r.tileset ====

: ''{{cmd|r.tileset}} moved into main archive''

==== r.traveltime ====

: [http://jesbergwetter.twoday.net/stories/4845555/ r.traveltime] computes the travel time of surface runoff to an outlet. The program starts at the basin outlet and calculates the travel time at each raster cell recursively. A drainage area related threhold considers even surface and also channel runoff. Travel times are derived by assuming kinematic wave approximation. The results can be used to derive a time-area function. This might be usefull for precipitation-runoff calculations (estimation of flood predictions) with a lumped hydrologic model (user-specified unit hydrograph).

: '''Author:''' Kristian Förster

==== r.univar.zonal ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.univar.zonal r.univar.zonal] is similar to r.univar, but calculates statistics separately for each category(zone) present in the separate input map used to define zones (zonal statistics). The output can be like the one of r.univar or in easier to read table format and can be written to a file. This addon is only needed for GRASS 6.4, its functionality has been added to r.univar in 6.5 and 7.

: '''Author:''' Markus Metz

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.univar.zonal

==== r.viewshed ====

: r.viewshed is a module for extremely fast line of sight analysis (replaces the slow r.los). It is written in C language for GRASS versions 6.X/7.x.

: '''Author:''' Laura Toma, USA

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.viewshed

Once {{trac|390}} is solved, it will substitute r.los.

==== r.wavelets ====

: [http://www.ing.unitn.it/~grass/software.html r.wavelets]: This package contains wavelets decomposition and reconstruction modules for the GRASS GIS: r.owave.dec computes the orthogonal wavelet transform of a raster map. r.owave.rec reconstructs a raster map from an orthogonal wavelet transform. r.biowave.dec computes the biorthogonal wavelet transform of a raster map. r.biowave.rec reconstructs a raster map from a biorthogonal wavelet transform.

: '''Authors:''' Members of the University of Trento, Faculty of Engineering

==== r.wf ====

: [http://svn.osgeo.org/grass/grass-addons/raster/r.wf/ r.wf] produces the Width Function of a basin. The Width Function W(x) gives the number of the cells in a basin at a flow distance x from the outlet (it is also referred as distance-area function). The distance is not the euclidean one, but it is measured along the flowpath towards the outlet.

: '''Authors:''' Margherita Di Leo, Massimo Di Stefano, Francesco Di Stefano

Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.wf/

==== r.xtent ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.xtent r.xtent] computes a raster map layer representing the Voronoi diagram, weighted Voronoi diagram or a more complex territorial partitioning of space around points (centers) in a vector input map, based on the XTENT formula.

:'''Author:''' Benjamin Ducke

svn co https://svn.osgeo.org/grass/grass-addons/raster/r.xtent

==== r.zc.pl ====

: [http://les-ejk.cz/files/programs/zc.pl Zero crossing] is a simple Perl script, finds the ,,zero crossings`` from the Laplacian of Gaussian filter (see above). It is really very simple, the edges don't need to be really on that pixel, where they are detected, no interpolation is performed.

: '''Author:''' Jachym Cepicky

==== GIPE ====

: The GRASS Image Processing Environment (GIPE) has USLE, Energy-balance and radiance-reflectance correction models.

: '''Author:''' Yann Chemin (unless specified otherwise).

svn co https://svn.osgeo.org/grass/grass-addons/imagery/gipe

Remark: This is progressively moved to main GRASS SVN (aka GRASS 7)

:* r.hydro.CASC2D, ported from GRASS 5.x version, is temporarily here waiting to return to main GRASS.

:* r.soiltex2prop creates porosity, Saturated Hydraulic conductivity (Ksat) and wetting front pressure head (Hf) from percentage of sand and clay after Rawls et al., 1990. This is a must for r.hydro.CASC2D.

:* i.biomass creates biomass growth map from fPAR, lightuse efficiency, water availability (or evap.fraction), Lat, doy and tsw.

:* i.dn2ref.l7, r.dn2ref.ast create top of atmosphere reflectance for Landsat 7ETM+ and ASTER. These modules also have a flag for radiance output. Updated i.dn2ref.l7 to read .met calibration file.

:* i.dn2full.l[5,7] is an attempt to get all bands of Landsat[5,7] calibrated and corrected to either reflectance or temperature, reads only the .met file.

:* i.dn2potrad.l[5,7] is an attempt to get ET potential from DN of Landsat 7 (Careful! No Atmospheric correction!).

:* i.eb.* are a set of 10+ GRASS modules that together perform the main functions of the SEBAL model (Bastiaanssen, 1995). Those functions include (but are not limited to) Soil heat flux, sensible heat flux, net radiation, evaporative fraction at satellite overpass, diurnal actual evapotranspiration, momentum roughness length, etc. These modules are also part of any Energy-Balance related processing.

:* i.evapo.potrad creates diurnal Potential evapotranspiration assuming all net radiation becomes ET, according to SEBAL model (Bastiaanssen, 1995). This module also has a flag for diurnal net radiation as required by SEBAL in i.eb.eta.

:* i.evapo.SENAY creates actual evapotranspiration following the regional method of Senay (2007).

:* i.lmf creates a Local Maximum Fitting on the temporal dimension of the multi-date input dataset, working, but more precision still to be added.

:* i.vi.mpi is the mpi version of i.vi for cluster GRASS GIS education (no speed up here!) '''Author:''' Shamim Akhter

:* i.modis.stateqa extracts State Quality Assessment information from Modis 500m (MOD09A) products.

:* i.water creates a Water Mask from NDVI and Albedo, or specifically for Modis: NDVI and Band 7.

:* i.wi creates a given Water Index (only one so far).

==== HydroFOSS ====

: HydroFOSS - a GIS embedded approach for Free & Open Source Hydrological modeling.

: '''Author:''' Massimiliano Cannata

svn co https://svn.osgeo.org/grass/grass-addons/HydroFOSS/

==== Hikereport ====

: python script that computes length, cumulative uphill and downhill, average slopes on an interactively drawn path. Based on r.profile's output.

: '''Author:''' Stefano Negri

http://tracce.wordpress.com/?attachment_id=71

=== Misc add-ons===

==== m.eigensystem ====

m.eigensystem - Computes eigen values and eigen vectors for square matrices.

: http://svn.osgeo.org/grass/grass-addons/misc/m.eigensystem/

: '''Author:''' Michael Shapiro

===Database add-ons===
==== db.join ====

: Table joining: join one table into another through common attributes

: '''Author:''' Markus Neteler. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/database/db.join/
or
g.extension db.join

===General add-ons===

==== GRASS create location scripts ====

: [http://trac.osgeo.org/grass/browser/grass-addons/general/grass_create_location grass_create_location.sh] Script to generate a new GRASS location from GIS file (e.g. geoTIFF or SHAPE), wktfile or EPSG code.

: '''Author:''' Markus Neteler

==== g.laptop.sh ====

: [http://www.gbd-consult.de/dassau/grass/g.laptop/g.laptop.sh g.laptop.sh] is an interactive shell script to extract raster and vector data from current Location into a new one. Data can be copied or extracted in current or original resolution and region extend. This script was written to extract smaller parts of a GRASS location to be able to present them on a laptop without the necessity to transfer huge data. Maps do not have to be in the same mapset.

: '''Author:''' Otto Dassau

==== Readline completion ====

: '''''Readline completion''''' for GRASS commands under the bash shell: [http://www.sorokine.info/grass-complete/ grass-complete] won't clutter the environment but needs to be installed; [http://dcalvelo.free.fr/grass/grass_rlcompleter.sh grass_rlcompleter.sh] needs almost no installation but will pollute the environment. Grass-Complete currently requires Bash version 2.05 for proper install.

: '''Author:''' Alexandre Sorokine (grass-complete), Daniel Calvelo (grass_rlcompleter.sh)

==== g.region.point ====

: [http://trac.osgeo.org/grass/browser/grass-addons/general/g.region.point g.region.point] is a shell script which resets the computational region to a square box around a given coordinate. It is intended for use within GRASS scripts to speed up processing by limiting expensive raster calculations to a small area of interest.

: '''Author:''' Hamish Bowman

==== g.linke_by_day ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.sun.tools/ g.linke_by_day] is a python script for [[r.sun]] which interpolates a Linke turbidity value for a given day of the year based on monthly values edited into the script.

: '''Author:''' Hamish Bowman

==== g.xlist ====

: [http://trac.osgeo.org/grass/browser/grass-addons/general/g.xlist g.xlist] is a C implementation of g.mlist. g.xlist searches for data files matching a pattern given by wildcards or POSIX Extended Regular Expressions. POSIX regex(3) functions are required.

: '''Author:''' Huidae Cho

==== g.xremove ====

: [http://trac.osgeo.org/grass/browser/grass-addons/general/g.xremove g.xremove] is a C implementation of g.mremove. g.xremove removes data files matching a pattern given by wildcards or POSIX Extended Regular Expressions. POSIX regex(3) functions are required.

: '''Author:''' Huidae Cho

=== Imagery add-ons ===

See also

svn co https://svn.osgeo.org/grass/grass-addons/imagery

==== GIPE ====

GIPE (see also above in raster section) provides:
i.biomass, i.dn2potrad.l5, i.dn2potrad.l7, i.dn2ref.ast, i.eb.deltat, i.eb.disp, i.eb.eta, i.eb.evapfr, i.eb.g0, i.eb.h0, i.eb.h_SEBAL01, i.eb.h_SEBAL95, i.eb.h_iter, i.eb.molength, i.eb.netrad, i.eb.psi, i.eb.rah, i.eb.rohair, i.eb.ublend, i.eb.ustar, i.eb.wetdrypix, i.eb.z0m, i.eb.z0m0, i.evapo.PT, i.evapo.TSA, i.evapo.potrad, i.evapo.senay, i.evapo.time_integration, i.lmf, i.modis.stateqa, i.sattime, i.vi.grid, i.vi.mpi, i.water, i.wi

svn co https://svn.osgeo.org/grass/grass-addons/gipe/

: '''Author:''' Yann Chemin

==== i.homography ====

Rectifies an image by computing a coordinate transformation for each pixel in the image based on the control points created by i.linespoints. The approach uses homography extended for corresponding lines.

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.homography

: '''Author:''' Daniel Grasso, Bolzano, Italy, based on code written by Stefano Merler, ITC-irst, Italy

==== i.linespoints ====

An imagery command that enables the user to mark coordinate system points as well as lines on an image to be rectified and then input the coordinates of each point for creation of a coordinate transformation matrix. The transformation matrix is needed as input for the GRASS program i.homography.

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.linespoints

: '''Author:''' Daniel Grasso, Bolzano, Italy, based on i.points

==== i.landsat.toar ====

Transform calibrated digital number of Landsat products to top-of-atmosphere radiance or top-of-atmosphere reflectance and temperature (band 6 of the sensors TM and ETM+). Optionally, used to calculate the at-surface radiance or reflectance with atmospheric correction (DOS method).

Available also in GRASS 7.

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.landsat.toar

: '''Author:''' E. Jorge Tizado

==== i.landsat.acca ====

Implements the Automated Cloud-Cover Assessment (ACCA) Algorithm from Irish (2000) with the constant values for pass filter one from Irish et al. (2006). To do this, it needs Landsat band numbers 2, 3, 4, 5, and 6 (or band 61 for Landsat-7 ETM+) which have already been processed from DN into reflectance and band-6 temperature with i.landsat.toar).

Available also in GRASS 7.

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.landsat.acca

: '''Author:''' E. Jorge Tizado

==== i.points.auto ====

This module allows a search of GCP's on two raster-maps with differents levels of automation. The ''manual'' search is the default search, so it's possible to determine the GCP's manually with the mouse (like {{cmd|i.points}}). ''Semiautomated'' search: The user determines with the mouse some correspondent areas (with a discrete precision) in the two maps and the module searches itself the GCP's in these areas. ''Automated'' search: At the start of module the user has to load the maps that the algorithm uses to the search, so it is recommended to use the maps filtered with the filters DIVERSITY or STDDEV (of GRASS) with a window of 3x3 or 5x5 pixels. However, the algorithm sometimes works well with the original maps too.

Note: This code is basically an improved i.points (from 2004). Subsequent changes in i.points haven's been ported here yet.

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.points.auto

: '''Authors:''' based on i.points; additions by Ivan Michelazzi, Luca Miori (MSc theses at ITC-irst); Supervisors: Markus Neteler, Stefano Merler, ITC-irst 2003, 2004. [http://gisws.media.osaka-cu.ac.jp/grass04/viewpaper.php?id=37 PDF article]

==== i.points.reproj ====

: [http://trac.osgeo.org/grass/browser/grass-addons/imagery/i.points.reproj i.points.reproj] is a shell script that will use cs2cs to reproject the target coordinates of a group's POINTS file. By running i.rectify directly to the new target projection, a generation of resampling data loss can be avoided (versus i.rectify + r.proj). On the other hand, i.rectify does not calculate cell resolution well if the map is to be rotated ([http://intevation.de/rt/webrt?serial_num=3296 bug #3296]), in those cases i.rectify+r.proj may be the better option.

: '''Author:''' Hamish Bowman

==== i.plr.py ====

: [[I.plr.py|Probabilistic Label Relaxation]], written in Python

: '''Author:''' Georg Kaspar

==== i.pr ====

: Image classification: implements k-NN (multiclass), classification trees (multiclass), maximum likelihood (multiclass), Support Vector Machines (binary), bagging versions of all the base classifiers, AdaBoost for binary trees and support vector machines. It allows feature manipulation (normalization, principal components,...). It also implements feature selection techniques (RFE, E-RFE,...), statistical tests on variables, tools for resampling (cross-validation and bootstrap) and cost-sensitive techniques for trees and support vector machines.

: '''Author:''' Stefano Merler. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.pr

==== i.spec.sam ====

: Spectral Angle mapping

: '''Author:''' Markus Neteler. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.spec.sam/

==== i.spec.unmix ====

: Spectral unmixing

: '''Author:''' Markus Neteler. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.spec.unmix/

==== i.topo.corr ====
: i.topo.corr is used to topographically correct reflectance from imagery files, e.g. obtained with i.landsat.toar (see above), using a sun illumination terrain model. This illumination model represents the cosine of the incident angle, i.e. the angle between the normal to the ground and the sun rays. It can be obtained with {{cmd|r.sun}} (parameter incidout), and then calculating its cosine with float precision. Correction methods: cosine, minnaert, percent, c-factor.

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.topo.corr

: '''Author:''' E. Jorge Tizado

==== i.warp ====

: [http://trac.osgeo.org/grass/browser/grass-addons/imagery/i.warp i.warp] is a shell script that will use gdalwarp to rectify a raw input image using thin plate splines. The map should be imported into GRASS with r.in.gdal and GCPs set with i.points. Input is the raw image (GeoTIFF, JPEG, etc). Output is a GeoTIFF in the imagery group's target location's map projection. Requires a recent (early 2006) version of GRASS 6.1, or newer.

: '''Author:''' Hamish Bowman

=== Display add-ons ===

See also

svn co https://svn.osgeo.org/grass/grass-addons/display

==== d.barb ====

[http://trac.osgeo.org/grass/browser/grass-addons/display/d.barb d.barb] is a C module that will draw wind barbs, straw plots, and arrow plots from raster array or sparse vector point data. It can use either direction + magnitude, or u + v components as the input, and can produce a legend key. (''work in progress, but it's mostly there'')

: '''Author:''' Hamish Bowman

==== d.edit.rast ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.edit.rast d.edit.rast] edits cells in an existing raster map displayed on the current monitor.

: '''Author:''' Huidae Cho

==== d.frame.quarter ====

: ('''obsolete''') [http://trac.osgeo.org/grass/browser/grass-addons/display/d.frame.split d.frame.quarter] is a shell script that will split the display into four quadrants (or sixths) using ''d.frame''. Individual frames are named ''uno, dos, tres, cuatro'', and ''full_screen''.
: Replaced by {{cmd|d.split.frame}} in main.

: '''Author:''' Hamish Bowman

==== d.frame.split ====

: ''d.frame.split moved into main archive as {{cmd|d.split.frame}}''

==== d.frontline ====

: [http://cloud.github.com/downloads/amuriy/GRASS-scripts/d.frontline d.frontline] is a shell script that draws frontlines on the graphics monitor using ''d.graph'' module and different types of symbols. Also it optionally saves frontline graphics to ''d.graph'' commands file and/or ''ps.map'' file (for later use with the "read" ''ps.map'' instruction)

: '''Author:''' Alexander Muriy

==== d.hyperlink ====

: [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/d.hyperlink.tar.bz2 d.hyperlink] is an interactive shell script that allows the viewing of hyperlinked images from a vector's attribute table in an external image viewer. Queries can be made via SQL statements or interactive mouse-clicking. The attribute table must be pre-populated with a column containing the image to link the vector to; the user also specifies the image folder in the current MAPSET where the images are located. The script currently supports gimp, Eye of Gnome, gthumb, gpdf, and Inkscape image viewers.

: '''Author: '''Eric Patton

==== d.mark ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.shortcuts d.mark] is a shell script that quickly displays a marker on the display at a given coordinate.

: '''Author:''' Hamish Bowman

==== d.region.box ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.region.box d.region.box] is a shell script that quickly displays a box around the current region.

: '''Author:''' Hamish Bowman

==== d.stations ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.shortcuts d.stations] is a shell script that quickly displays vector points (or sites for GRASS 5.4 and below).

: '''Author:''' Hamish Bowman

==== d.varea ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.shortcuts d.varea] is a shell script that quickly displays vector areas.

: '''Author:''' Hamish Bowman

==== pd-GRASS ====

: [http://www.ornl.gov/sci/gist/software/grass/ pd-GRASS]: Parallel Display for GRASS GIS

: '''Author:''' Alex Sorokine

==== [[IconSymbols]] ====

* [[IconSymbols|Symbols]] which can be used with ''d.vect, d.graph'', and ''ps.map''.

=== Postscript add-ons ===

* ''See also [[ps.map scripts|ps.map samples and templates]]''.

==== ps.atlas ====

: [http://les-ejk.cz/programs/grass/ps.atlas ps.atlas] is a shell script that makes more maps on current region according to input *.psmap file. General map can be stored as vector file. The resulting *.eps maps can be automatically converted to *.pdf files.

: '''Author:''' Jachym Cepicky

==== ps.output ====

: [https://trac.osgeo.org/grass/browser/grass-addons/postscript/ps.output ps.output] is much like {{cmd|ps.map}} but with advanced decorations and ability for translucency. Here you can find a [[Ps.output|tutorial]].

: '''Author:''' Jorge Tizado

==== [[AreaFillPatterns]] ====

* Hatches for ps.map's vareas

=== wxGUI add-ons ===

===GRASS and UMN Mapserver===

* [http://www.mail-archive.com/mapserver-users@lists.umn.edu/msg00086.html See interesting posting]
* See wiki [[GRASS and MapServer]] page

==GRASS 5.x (old)==

===Vector add-ons===

* See here: http://grass.osgeo.org/download/addons.php

===Raster add-ons===

* See here: http://grass.osgeo.org/download/addons.php

* [http://www.valledemexico.ambitiouslemon.com/gwmodelling.html r.gmtg] The groundwater modelling tool for grass. A module to use MODFLOW within GRASS. '''Author''': Jaime Carrera

* [http://www.bowdoin.edu/~ltoma/research.html r.terracost] Scalable approach for computing least-cost-path surfaces on massive grid terrains. For GRASS 5.3. '''Lead author''': Laura Toma
:Newer version available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.terracost

==GRASS 4.x (very old)==

===Raster add-ons===

* MAGICAL Software: The MAGICAL software comprises a suite of three programs that provide a multi-agent simulation extension for the GRASS GIS software. http://www.ucl.ac.uk/~tcrnmar/simulation/magical/magical.html

[[Category:Community]]
[[Category:Development]]
[[Category:Documentation]]
[[Category:Installation]]

WxPython-based GUI for GRASS

2010-02-13T20:16:10Z

⚠️Cmbarton: /* What others do */

See also [[GRASS GUI]], [[GRASS and Python]] and [[GRASS SoC Ideas 2009‎]].

For developer-related issues see [http://trac.osgeo.org/grass/wiki/wxGUIDevelopment Trac wxGUI page].

__TOC__

== Overview ==

* [http://grass.osgeo.org/grass64/manuals/html64_user/wxGUI.html Manual page]
* A nice summary of the progress to date, written by Jachym Cepicky:
** [http://www.les-ejk.cz/english/wxgrass-new-grass-gui-1 Part 1]
** [http://www.les-ejk.cz/english/wxgrass-new-grass-gui-2 Part 2]
* [[User:Landa|Martin Landa]]: [http://gama.fsv.cvut.cz/~landa/publications/2008/gis-ostrava-08/paper/landa-grass-gui-wxpython.pdf New GUI for GRASS GIS based on wxPython] ([http://gis2008.com/indexe.html GIS Ostrava 2008], January 27-30, 2008, Ostrava, Czech Republic)
* [[User:Landa|Martin Landa]], Cristina Moretto, Michele Zanolli, Luca Manganelli and Markus Neteler: [http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/paper/grass-gfoss-tn.pdf wxPython-based GUI for GRASS GIS] ([http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/prezentazione/perugia-grass-gui-wxpython.pdf presentation]) ([http://www.grassmeeting2008.unipg.it IX Meeting degli Utenti Italiani di GRASS - GFOSS], February 20-22, Perugia, Italy)

=== Requirements ===

* [http://svn.osgeo.org/grass/grass/trunk/gui/wxpython/README README]

=== Development ===

Do you want to help with the development?

* basic Python programming ability required
* GUI programming experience welcomed (especially wxPython)
* GRASS user (or better developer) experience

How to get [http://trac.osgeo.org/grass/wiki/HowToContribute write access] to the GRASS SVN repository.

== Screenshots ==

* [http://svn.osgeo.org/grass/grass-addons/screenshots/wxpython SVN]
* [http://grass.osgeo.org/screenshots/gui.php Website screenshot page]
* Various screenshots from [[:Category:WxGUI|GRASS-Wiki]]

=== GNU/Linux ===

<center>
{|
|
[[Image:Wxgui-startup-gnulinux.png|300px|thumb|Start-up screen]]
||
[[Image:Wxgui-vdigit1-gnulinux.png|300px|thumb|Vector digitizer]]
|-
|
[[Image:Wxgui-atm0-gnulinux.png|300px|thumb|Attribute Table Manager]]
||
[[Image:Wxgui-vector-querying-gnulinux.png|300px|thumb|Querying vector map layers (attribute data)]]
|}
</center>

=== Mac OS ===

=== MS Windows ===

<center>
{|
|
[[Image:Wxgui-startup-windows1.png|300px|thumb|Start-up screen]]
||
[[Image:Wxgui-d-vect-windows.png|300px|thumb|GUI dialog d.vect]]
|-
|
[[Image:Wxgui-atm-windows.png|300px|thumb|Attribute Table Manager]]
||
[[Image:Wxgui-r-buffer-windows.png|300px|thumb|Running command (r.buffer)]]
|-
|
[[Image:Wxgui-vector-querying-windows.png|300px|thumb|Querying vector map layer (editable mode)]]
||
 
|}
</center>

== Components ==

=== Layer Manager ===

'''Status:''' prototype implemented.

The '''GRASS GIS Layer Manager''' provides an interactive graphical interface to GRASS commands. The Layer Manager includes a set of pull-down menus for all GRASS GIS functions (analysis, file I/O, GIS configuration and management), toolbar that manage display map layers in map display windows, layer tree in which map layers to display are organized, command output window and integrated command line prompt.

<div align="center">
{|
|[[Image:wxgrass-gis-manager-layer.png|350px]] || [[Image:wxgrass-gis-manager-output.png|350px]]
|}
</div>

<div align="center">
[[Image:Wxgrass rgb.png|350px]]
</div>

=== Map display window ===

'''Status:''' prototype implemented.

Each '''Map display window''' has a unique set of layers to display and region setting (zoom). The map display window includes main toolbar with basic tools including zooming, panning, data querying, simple analyse functions (measure, profile, histogram, etc.), overlay management, etc. From main toolbar are accessible additional toolbars, currently only Digitization tool is available. Under development is Georectification tool.

<center>
{|
|-
| [[Image:Wxgrass-mapdisplay-0.png|thumb|350px|center]] ||
[[Image:Wxgui-mapdisplay-1.png|thumb|350px|center]]
|-
|}
</center>

=== Module GUIs ===

'''Status:''' prototype implemented.

Generated from XML using <tt>--interface-description</tt>.

E.g. <tt>d.rgb --help</tt>
<pre>
Description:
Displays three user-specified raster map layers as red, green, and blue overlays in the active graphics frame.

Keywords:
display

Usage:
d.rgb [-ox] red=name green=name blue=name [--verbose] [--quiet]

Flags:
-o Overlay (non-null values only)
-x Don't add to list of commands in monitor
--v Verbose module output
--q Quiet module output

Parameters:
red Name of raster map to be used for <red>
green Name of raster map to be used for <green>
blue Name of raster map to be used for <blue>
</pre>

becomes with <tt>d.rgb --interface-description</tt>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE task SYSTEM "[http://trac.osgeo.org/grass/browser/grass/trunk/gui/xml/grass-interface.dtd grass-interface.dtd]">
<task name="d.rgb">
<description>
Displays three user-specified raster map layers as red, green, and blue overlays in the active graphics frame.
</description>
<keywords>
display
</keywords>
<parameter name="red" type="string" required="yes" multiple="no">
<description>
Name of raster map to be used for <red>
</description>
<keydesc>
<item order="1">name</item>
</keydesc>
<gisprompt age="old" element="cell" prompt="raster" />
</parameter>
<parameter name="green" type="string" required="yes" multiple="no">
<description>
Name of raster map to be used for <green>
</description>
<keydesc>
<item order="1">name</item>
</keydesc>
<gisprompt age="old" element="cell" prompt="raster" />
</parameter>
<parameter name="blue" type="string" required="yes" multiple="no">
<description>
Name of raster map to be used for <blue>
</description>
<keydesc>
<item order="1">name</item>
</keydesc>
<gisprompt age="old" element="cell" prompt="raster" />
</parameter>
<flag name="o">
<description>
Overlay (non-null values only)
</description>
</flag>
<flag name="x">
<description>
Don't add to list of commands in monitor
</description>
</flag>
<flag name="verbose">
<description>
Verbose module output
</description>
</flag>
<flag name="quiet">
<description>
Quiet module output
</description>
</flag>
</task>

which is then used to generate:

[[Image:wxgrass-d-rgb.png|center|600px]]

=== Startup GUI ===

'''Status:''' prototype implemented.

Start new GRASS session with

grass -wxpython

[[Image:Wxgrass-startup.png|center|400px]]

=== Location wizard ===

'''Status:''' prototype implemented.

Wizard for creating new GRASS project location based on:

* Coordinate system
* EPSG code
* Georeferenced file
* PROJ.4 string
* XY

See also [[GRASS Location Wizard]].

[[Image:Wxgui-location-wizard.png|center|thumb|600px|Location wizard]]

=== Cartography tools ===

'''Status:''' development not started yet.

==== GUI for ps.map ====

* [http://grass.osgeo.org/grass63/manuals/html63_user/ps.map.html ps.map] is a cartographic composer, intended to be a stand-alone hardcopy plot generator. It is not meant to be a '''Print''' button for the maps currently displayed in the map canvas, that will need it own controls.

* The GUI will prepare a semi-WYSIWYG + tree menu controls which can write a ps.map control file, and then run ps.map to create PostScript and PDF output directly. Loading a ps.map control file is harder and can happen later.

* For a start at a Tcl/Tk composer see gui/tcltk/d.m/print.tcl
: see also these discussions and pyGTK prototype by Jachym Cepicky
:* http://thread.gmane.org/gmane.comp.gis.grass.devel/12469
:* http://thread.gmane.org/gmane.comp.gis.grass.devel/19368

* Start with most important mapping instructions
** paper
** scale
** maploc
** rast
** vects
** grids
** scalebar
** mapinfo
** text labels

===== Intelligent label placement in ps.map =====

* use PAL/JPAL [http://geosysin.iict.ch/PAL cartographic labelling library] (GPL, C++ language, JNI wrapper)

===== Outputs =====

* ps.map instructions file
* PostScript file [ps.map instructions tmp file]
* lpr [PostScript tmp file]
* PDF File (pstopdf? ps2pdf? GNU Ghostscript?) [PostScript tmp file]

===== Inputs =====

* Ability to load in saved ps.map scripts. I consider this to be a low priority, deal with it after map creation is fully functional. Start with scripts saved using the GUI, after that is working expand to load any ps.map instructions file.

===== Prototype g-ps.map =====
* [http://les-ejk.cz/files/programs/grass/gpsmap-0.1.2.tgz gpsmap-0.1.2.tgz]
* [http://les-ejk.cz/tmp/gpsmap.png g-ps.map Screenshot]
* [http://www.nabble.com/status-of-g-ps.map-tf4465835.html#a12733414 Jachym's posting]

==== Direct printing ====

Implement direct printing of map canvas content using GRASS PS driver or Cairo driver.

* [http://trac.gispython.org/projects/PCL/wiki Python Cartographic Lab]
* [http://wiki.osgeo.org/wiki/OSGeo_Cartographic_Library OSGeo Cartographic Library]
** http://lists.osgeo.org/pipermail/discuss/2008-April/003337.html
** http://www.intevation.de/pipermail/freegis-list/2007-April/003142.html
* [http://wiki.osgeo.org/wiki/OSGeo_map_symbol_set OSGeo Map Symbol Set]
* [http://www.gdal.org/ogr/ogr_feature_style.html OGR - Feature Style Specification]
* [http://trac.osgeo.org/mapguide/wiki/MapGuideRfc14 MapGuide RFC 14 - Cartographic Stylization Engine]

* [http://www.iho.shom.fr/PUBLICATIONS/download.htm#special S-52 standard for nautical chart (ENC) symbology] and cartography from the [http://www.iho.shom.fr/ International Hydrographic Bureau]
** [http://openev.cvs.sourceforge.net/openev/contrib/S52/ GPL library implementing the S-52 standard] (OpenEV)

* [http://www.opengeospatial.org/standards/symbol OpenGIS Symbology Encoding Implementation Specification]

* [http://geosysin.iict.ch/trac/wiki/Index4extJPAL PAL]

=== Georectifier ===

'''Status:''' prototype implemented.

<center>
{|
|-
| [[Image:Wxgui-georectify-0.png|thumb|350px|center]] ||
[[Image:Wxgui-georectify-1.png|thumb|350px|center]]
|-
|}
</center>

=== Profile Analysis Tool ===

'''Status:''' prototype implemented.

<center>
{|
|-
| [[Image:Wxgui-profile-0.png|thumb|350px|center]] ||
[[Image:Wxgui-profile-1.png|thumb|350px|center]]
|-
|}
</center>

=== Vector digitizer ===

'''Status:''' prototype implemented.

[http://grass.osgeo.org/grass64/manuals/html64_user/wxGUI.Vector_Digitizing_Tool.html Manual page].

See also [[GRASS Digitizing tool]].

Replacement of <tt>v.digit</tt> module integrated to Map display window ([http://svn.osgeo.org/grass/grass-addons/screenshots/wxpython/digitization Screenshots]).

<center>

{|
|-
| [[Image:WxDigit200804.png|thumb|300px|center|Vector digitizer (2008/04)]] ||
[[Image:Digit-01.png|thumb|300px|center|Vector digitizer (2007/11)]]
|-
| [[Image:WxGUI-vdigit-fill-area.png|thumb|300px|center|Vector digitizer - fill valid areas (closed boundary + centroid) (2008/07)]] ||
[[Image:WxGUI-vdigit-bg.png|thumb|300px|center|Vector digitizer - background raster maps with different opacity level (2008/07)]]
|-
|}
</center>

=== Raster digitizer ===

'''Status:''' development not started yet.

* r.digit (merge with v.digit?)
: Probably write a front end for [http://grass.osgeo.org/grass63/manuals/html63_user/r.in.poly.html r.in.poly], that's all the old r.digit is.
* d.rast.edit
: Idea: get cell center coords and new values from GUI interaction, then pass those through r.in.xyz, and r.patch the new values over the top of the old map.

* merge with Georectifier? (i.points, i.vpoints)

===== Category Labels =====

* Write with new r.category import tool
** ''Back-end component complete: r.category module is now updated to handle a rules= file and other goodies like dynamic labels''

* Read with one of r.category, r.describe, r.report, r.stats, ???
** probably need to add a new flag to one of those to print flat <tt>"%d %s", cat, label</tt>
: or read the cats/ file directly, it's already flat ascii.

* how to deal with FP maps & cats?

=== Ortho photos ===

'''Status:''' development not started yet.

* To replace i.ortho.photo and friends

=== Attribute table manager ===

[[Image:Wxgui-attribute-table-manager.png|right|thumb|350px|Attribute Table Manager]]

;'''Status:''' prototype implemented.

[http://grass.osgeo.org/grass64/manuals/html64_user/wxGUI.Attribute_Table_Manager.html Manual page].

;Allows:

* To browse attribute data, perform SQL select statements
* Modify attribute data, insert new records to attribute table, delete existing records
* Highlight selected items in Map Display Window
* Extract selected items into new vector map layer
* Modify attribute table - add, drop, rename columns
* Modify vector map layer DB connestion settings - add, remove or modify layers

=== NVIZ replacement ===

'''Status:''' under development.

Detailed information [[wxNVIZ]].

=== Imagery tools ===

'''Status:''' (re)development not started in earnest yet. Some behind-the-scenes code has been prepared, but not much.
: ''Volunteers welcome!''

=== Graphical modeller ===

'''Status:''' development not started yet.

=== GEM integration ===

'''Status:''' development not started yet.

[http://trac.osgeo.org/grass/browser/grass/trunk/gem GEM] is GRASS Extension Manager. Or use the R packages approach.

=== Data Catalog ===

;'''Status:''' Under development.

* [http://trac.osgeo.org/grass/browser/grass-addons/gui/wxpython/data_catalog Data Catalog]

<center>
{|
|-
| [[Image:Catalog.png|350px|thumb|center|Data Catalog ]]
| [[Image:Aspect.png|350px|thumb|center|Data Catalog]]
|-
|}
</center>

;Current Features:

* copy, delete, rename map layers (raster & vector) in current mapset.
* view raster & vector map layers from any location and any mapset.
* Provides a GUI wrapper for r.info & v.info grass commands while viewing map layers in mapwindow.

;To be implemented:

* copy, move map layers in different mapsets.
* View DBF files as tables.
* Copy, delete, rename DBF files.
* Modify attribute tables.
* Viewing other formats.
* ...

=== Help browser ===

'''Status:''' development not started yet.

For browsing manual pages is currently used web browser, the goal is to design integrated help system.
: HB: ''We used to have one of these for viewing the help pages of Tcl/Tk NVIZ. We dropped it because it was a pain to maintain and generally outside our core mission so a distraction.''

== Known issues ==

* See and report in trac: [http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&component=wxGUI&order=priority List of open issues]

* Warning "widget class `GtkPizza' has no property named `row-ending-details'", http://trac.osgeo.org/grass/ticket/204

=== Platform specific ===

For the GUI to know what platform it's on, and therefore apply platform specific commands (e.g. append '.exe' to programs) it has to test what platform it is running on. Here we take the experimental approach to learning what's best to use. Please add or generalize this list as you can.

Platform information - start Python from the command line then issue

<source lang="python">
import sys
sys.platform

import os
os.name
os.environ['OS']

import platform
platform.system()
</source>

* Results:

{| border="1" class="wikitable" style="text-align:center"
! Platform
! sys.platform
! os.name
! os.environ['OS']
! platform.system()
|-
| 32bit GNU/Linux
| linux2
| posix
| ''n/a''
| Linux
|-
| 64bit GNU/Linux
| linux2
| posix
| ''n/a''
| Linux
|-
| 32bit Mac OSX (PowerPC G4)
| darwin
| posix
| ''n/a''
| Darwin
|-
| 64bit Mac OSX (Intel)
| [1] see note
| ?
| ?
| ?
|-
| 32bit MS Windows XP
| win32
| nt
| Windows_NT
| Windows
|-
| 64bit MS Windows Vista
| win32
| nt
| Windows_NT
| Windows
|-
| 32bit MS Windows XP (Cygwin)
| win32
| ?
| ?
| ?
|}

[1] On Fri, May 29, 2009 at 10:49 PM, William Kyngesburye wrote:
: ''Right now the GUI only runs 32bit, even if the rest of GRASS is 64bit, because it's not yet possible for wxPython to be 64bit. It comes out the same as PPC 32bit - no distinction between ppc/intel or 32/64 bit, it's all darwin. (yes, I checked, and I have a custom 64bit python executable to verify)''

== General GUI Design ==

=== Layout ===

For some users, the current approach of separate windows (SDI) leads to a windows flooding. Especially on large monitors or dual screen systems catching the wxGUI windows can be tedious when they appear on separate monitors (depends on windows manager, the much used KDE scatters typically the wxGUI windows all over the screen real estate). Almost each task generates a new wxGUI window which is freely floating around on the screen: [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-03.png example 1] and [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-01.png example 2]. On a dual-screen this may sum up to 50cm of distance!

'''Proposed solutions:'''
* implement ''optional'' layout similar to QGIS (with a legend attached to each display) or [http://sourceforge.net/dbimage.php?id=215336 GSDView] etc) (see figure below)
* implement ''optional'' magnetic docking of the layer manager and display windows to keep the windows closer
* do not allow module windows to stay open. That is, get rid of the apply button and force each window to close when OK is pressed (QGIS/ArcGIS approach). This leaves only the display(s) and single legend/layer manager on desktop.
* If you otherwise wish to continue using your current WM, file a bug report with them asking for better multi-head support and get the problem fixed at the source. (there probably already is a bug filed with tips in it)

<center>
{|
|-
| [[Image:Wxgui_current.png|350px|thumb|center|Current wxGUI layout with detached window components]]
| [[Image:Wxgui_proposal.png|350px|thumb|center|'''Proposal''' for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)]]
|-
|}
</center>

'''New solution: see data catalog above.'''

====What others do====

'''SDI: (each document opened in application occupies a window on the desktop)'''
* GRASS: display window for each document (i.e., set of maps displayed) opened on desktop; one legend/layer manager window for all display windows; ; each module/function opens a separate window on the desktop
* QGIS: display window for each document (i.e., set of maps displayed) opened on the desktop; legend/layer manager window attached to each display window; each module/function opens a separate window on the desktop (e.g. http://grass.osgeo.org/grass61/screenshots/images/qgis08_grass6_toolbox.png)
* ArcGIS: similar to QGIS with combined legend/display for each document (set of maps displayed); each module/function opens a separate window on the desktop (e.g. http://upload.wikimedia.org/wikipedia/en/9/92/ArcMap.jpg)
* MapInfo (pre Pitney Bowes): each document opens a map display window on the desktop; single legend/toolbox opened on the desktop controls all visible documents (i.e., map displays); each module/function opens a separate window on the desktop (similar to current GRASS layout)

'''MDI: (a single frame is opened for the application on the desktop; all documents opened inside the application frame)'''
* SAGA: single application frame opened on the desktop; all documents (display windows) open inside application frame; one legend/layer manager for all display windows; each module/function opens a separate window inside the frame (http://www.saga-gis.uni-goettingen.de/html/images/bild8.gif and http://sourceforge.net/dbimage.php?id=44455)
* Ossim: single application frame opened on the desktop; all documents (display windows) open inside application frame; one legend/layer manager for all display windows; each module/function opens a separate window inside the frame (http://www.ossim.org/OSSIM/Albums/Pages/ImageLinker.html)
* Idrisi: similar to SAGA and Ossim (http://www.clarklabs.org/products/idrisi-taiga.cfm)
* MapInfo (Pitney Bowes): Seems to be like Saga (http://www.pbinsight.com/support/training/video-tutorials/)

'''''See also'''''
* Solution to the problem: [http://www.wxwidgets.org/manuals/stable/wx_wxlayoutalgorithm.html wxLayoutAlgorithm]
* [http://en.wikipedia.org/wiki/Multiple_document_interface Multiple document interface] (MDI, windows reside under a single parent window)
* [http://en.wikipedia.org/wiki/Single_document_interface Single document interface] (SDI, separate windows, currently used for wxGUI)
* and [http://en.wikipedia.org/wiki/Human_interface_guidelines Human interface guidelines] (HIG)

== HowTo ==

* [[Import DXF]]

== Useful links ==

* [http://www.poromenos.org/tutorials/python 10 minutes Python tutorial] for programmers of other languages

== References ==

* [[User:Landa|Martin Landa]]: [http://gama.fsv.cvut.cz/~landa/publications/2008/gis-ostrava-08/paper/landa-grass-gui-wxpython.pdf New GUI for GRASS GIS based on wxPython] ([http://gis2008.com/indexe.html GIS Ostrava 2008], January 27-30, 2008, Ostrava, Czech Republic)
* [[User:Landa|Martin Landa]], Cristina Moretto, Michele Zanolli, Luca Manganelli and Markus Neteler: [http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/paper/grass-gfoss-tn.pdf wxPython-based GUI for GRASS GIS] ([http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/prezentazione/perugia-grass-gui-wxpython.pdf presentation]) ([http://www.grassmeeting2008.unipg.it IX Meeting degli Utenti Italiani di GRASS - GFOSS], February 20-22, Perugia, Italy)

[[Category:Development]]
[[Category:GUI]]
[[Category:Python]]

WxPython-based GUI for GRASS

2010-02-13T20:14:26Z

⚠️Cmbarton: /* Layout */

See also [[GRASS GUI]], [[GRASS and Python]] and [[GRASS SoC Ideas 2009‎]].

For developer-related issues see [http://trac.osgeo.org/grass/wiki/wxGUIDevelopment Trac wxGUI page].

__TOC__

== Overview ==

* [http://grass.osgeo.org/grass64/manuals/html64_user/wxGUI.html Manual page]
* A nice summary of the progress to date, written by Jachym Cepicky:
** [http://www.les-ejk.cz/english/wxgrass-new-grass-gui-1 Part 1]
** [http://www.les-ejk.cz/english/wxgrass-new-grass-gui-2 Part 2]
* [[User:Landa|Martin Landa]]: [http://gama.fsv.cvut.cz/~landa/publications/2008/gis-ostrava-08/paper/landa-grass-gui-wxpython.pdf New GUI for GRASS GIS based on wxPython] ([http://gis2008.com/indexe.html GIS Ostrava 2008], January 27-30, 2008, Ostrava, Czech Republic)
* [[User:Landa|Martin Landa]], Cristina Moretto, Michele Zanolli, Luca Manganelli and Markus Neteler: [http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/paper/grass-gfoss-tn.pdf wxPython-based GUI for GRASS GIS] ([http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/prezentazione/perugia-grass-gui-wxpython.pdf presentation]) ([http://www.grassmeeting2008.unipg.it IX Meeting degli Utenti Italiani di GRASS - GFOSS], February 20-22, Perugia, Italy)

=== Requirements ===

* [http://svn.osgeo.org/grass/grass/trunk/gui/wxpython/README README]

=== Development ===

Do you want to help with the development?

* basic Python programming ability required
* GUI programming experience welcomed (especially wxPython)
* GRASS user (or better developer) experience

How to get [http://trac.osgeo.org/grass/wiki/HowToContribute write access] to the GRASS SVN repository.

== Screenshots ==

* [http://svn.osgeo.org/grass/grass-addons/screenshots/wxpython SVN]
* [http://grass.osgeo.org/screenshots/gui.php Website screenshot page]
* Various screenshots from [[:Category:WxGUI|GRASS-Wiki]]

=== GNU/Linux ===

<center>
{|
|
[[Image:Wxgui-startup-gnulinux.png|300px|thumb|Start-up screen]]
||
[[Image:Wxgui-vdigit1-gnulinux.png|300px|thumb|Vector digitizer]]
|-
|
[[Image:Wxgui-atm0-gnulinux.png|300px|thumb|Attribute Table Manager]]
||
[[Image:Wxgui-vector-querying-gnulinux.png|300px|thumb|Querying vector map layers (attribute data)]]
|}
</center>

=== Mac OS ===

=== MS Windows ===

<center>
{|
|
[[Image:Wxgui-startup-windows1.png|300px|thumb|Start-up screen]]
||
[[Image:Wxgui-d-vect-windows.png|300px|thumb|GUI dialog d.vect]]
|-
|
[[Image:Wxgui-atm-windows.png|300px|thumb|Attribute Table Manager]]
||
[[Image:Wxgui-r-buffer-windows.png|300px|thumb|Running command (r.buffer)]]
|-
|
[[Image:Wxgui-vector-querying-windows.png|300px|thumb|Querying vector map layer (editable mode)]]
||
 
|}
</center>

== Components ==

=== Layer Manager ===

'''Status:''' prototype implemented.

The '''GRASS GIS Layer Manager''' provides an interactive graphical interface to GRASS commands. The Layer Manager includes a set of pull-down menus for all GRASS GIS functions (analysis, file I/O, GIS configuration and management), toolbar that manage display map layers in map display windows, layer tree in which map layers to display are organized, command output window and integrated command line prompt.

<div align="center">
{|
|[[Image:wxgrass-gis-manager-layer.png|350px]] || [[Image:wxgrass-gis-manager-output.png|350px]]
|}
</div>

<div align="center">
[[Image:Wxgrass rgb.png|350px]]
</div>

=== Map display window ===

'''Status:''' prototype implemented.

Each '''Map display window''' has a unique set of layers to display and region setting (zoom). The map display window includes main toolbar with basic tools including zooming, panning, data querying, simple analyse functions (measure, profile, histogram, etc.), overlay management, etc. From main toolbar are accessible additional toolbars, currently only Digitization tool is available. Under development is Georectification tool.

<center>
{|
|-
| [[Image:Wxgrass-mapdisplay-0.png|thumb|350px|center]] ||
[[Image:Wxgui-mapdisplay-1.png|thumb|350px|center]]
|-
|}
</center>

=== Module GUIs ===

'''Status:''' prototype implemented.

Generated from XML using <tt>--interface-description</tt>.

E.g. <tt>d.rgb --help</tt>
<pre>
Description:
Displays three user-specified raster map layers as red, green, and blue overlays in the active graphics frame.

Keywords:
display

Usage:
d.rgb [-ox] red=name green=name blue=name [--verbose] [--quiet]

Flags:
-o Overlay (non-null values only)
-x Don't add to list of commands in monitor
--v Verbose module output
--q Quiet module output

Parameters:
red Name of raster map to be used for <red>
green Name of raster map to be used for <green>
blue Name of raster map to be used for <blue>
</pre>

becomes with <tt>d.rgb --interface-description</tt>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE task SYSTEM "[http://trac.osgeo.org/grass/browser/grass/trunk/gui/xml/grass-interface.dtd grass-interface.dtd]">
<task name="d.rgb">
<description>
Displays three user-specified raster map layers as red, green, and blue overlays in the active graphics frame.
</description>
<keywords>
display
</keywords>
<parameter name="red" type="string" required="yes" multiple="no">
<description>
Name of raster map to be used for <red>
</description>
<keydesc>
<item order="1">name</item>
</keydesc>
<gisprompt age="old" element="cell" prompt="raster" />
</parameter>
<parameter name="green" type="string" required="yes" multiple="no">
<description>
Name of raster map to be used for <green>
</description>
<keydesc>
<item order="1">name</item>
</keydesc>
<gisprompt age="old" element="cell" prompt="raster" />
</parameter>
<parameter name="blue" type="string" required="yes" multiple="no">
<description>
Name of raster map to be used for <blue>
</description>
<keydesc>
<item order="1">name</item>
</keydesc>
<gisprompt age="old" element="cell" prompt="raster" />
</parameter>
<flag name="o">
<description>
Overlay (non-null values only)
</description>
</flag>
<flag name="x">
<description>
Don't add to list of commands in monitor
</description>
</flag>
<flag name="verbose">
<description>
Verbose module output
</description>
</flag>
<flag name="quiet">
<description>
Quiet module output
</description>
</flag>
</task>

which is then used to generate:

[[Image:wxgrass-d-rgb.png|center|600px]]

=== Startup GUI ===

'''Status:''' prototype implemented.

Start new GRASS session with

grass -wxpython

[[Image:Wxgrass-startup.png|center|400px]]

=== Location wizard ===

'''Status:''' prototype implemented.

Wizard for creating new GRASS project location based on:

* Coordinate system
* EPSG code
* Georeferenced file
* PROJ.4 string
* XY

See also [[GRASS Location Wizard]].

[[Image:Wxgui-location-wizard.png|center|thumb|600px|Location wizard]]

=== Cartography tools ===

'''Status:''' development not started yet.

==== GUI for ps.map ====

* [http://grass.osgeo.org/grass63/manuals/html63_user/ps.map.html ps.map] is a cartographic composer, intended to be a stand-alone hardcopy plot generator. It is not meant to be a '''Print''' button for the maps currently displayed in the map canvas, that will need it own controls.

* The GUI will prepare a semi-WYSIWYG + tree menu controls which can write a ps.map control file, and then run ps.map to create PostScript and PDF output directly. Loading a ps.map control file is harder and can happen later.

* For a start at a Tcl/Tk composer see gui/tcltk/d.m/print.tcl
: see also these discussions and pyGTK prototype by Jachym Cepicky
:* http://thread.gmane.org/gmane.comp.gis.grass.devel/12469
:* http://thread.gmane.org/gmane.comp.gis.grass.devel/19368

* Start with most important mapping instructions
** paper
** scale
** maploc
** rast
** vects
** grids
** scalebar
** mapinfo
** text labels

===== Intelligent label placement in ps.map =====

* use PAL/JPAL [http://geosysin.iict.ch/PAL cartographic labelling library] (GPL, C++ language, JNI wrapper)

===== Outputs =====

* ps.map instructions file
* PostScript file [ps.map instructions tmp file]
* lpr [PostScript tmp file]
* PDF File (pstopdf? ps2pdf? GNU Ghostscript?) [PostScript tmp file]

===== Inputs =====

* Ability to load in saved ps.map scripts. I consider this to be a low priority, deal with it after map creation is fully functional. Start with scripts saved using the GUI, after that is working expand to load any ps.map instructions file.

===== Prototype g-ps.map =====
* [http://les-ejk.cz/files/programs/grass/gpsmap-0.1.2.tgz gpsmap-0.1.2.tgz]
* [http://les-ejk.cz/tmp/gpsmap.png g-ps.map Screenshot]
* [http://www.nabble.com/status-of-g-ps.map-tf4465835.html#a12733414 Jachym's posting]

==== Direct printing ====

Implement direct printing of map canvas content using GRASS PS driver or Cairo driver.

* [http://trac.gispython.org/projects/PCL/wiki Python Cartographic Lab]
* [http://wiki.osgeo.org/wiki/OSGeo_Cartographic_Library OSGeo Cartographic Library]
** http://lists.osgeo.org/pipermail/discuss/2008-April/003337.html
** http://www.intevation.de/pipermail/freegis-list/2007-April/003142.html
* [http://wiki.osgeo.org/wiki/OSGeo_map_symbol_set OSGeo Map Symbol Set]
* [http://www.gdal.org/ogr/ogr_feature_style.html OGR - Feature Style Specification]
* [http://trac.osgeo.org/mapguide/wiki/MapGuideRfc14 MapGuide RFC 14 - Cartographic Stylization Engine]

* [http://www.iho.shom.fr/PUBLICATIONS/download.htm#special S-52 standard for nautical chart (ENC) symbology] and cartography from the [http://www.iho.shom.fr/ International Hydrographic Bureau]
** [http://openev.cvs.sourceforge.net/openev/contrib/S52/ GPL library implementing the S-52 standard] (OpenEV)

* [http://www.opengeospatial.org/standards/symbol OpenGIS Symbology Encoding Implementation Specification]

* [http://geosysin.iict.ch/trac/wiki/Index4extJPAL PAL]

=== Georectifier ===

'''Status:''' prototype implemented.

<center>
{|
|-
| [[Image:Wxgui-georectify-0.png|thumb|350px|center]] ||
[[Image:Wxgui-georectify-1.png|thumb|350px|center]]
|-
|}
</center>

=== Profile Analysis Tool ===

'''Status:''' prototype implemented.

<center>
{|
|-
| [[Image:Wxgui-profile-0.png|thumb|350px|center]] ||
[[Image:Wxgui-profile-1.png|thumb|350px|center]]
|-
|}
</center>

=== Vector digitizer ===

'''Status:''' prototype implemented.

[http://grass.osgeo.org/grass64/manuals/html64_user/wxGUI.Vector_Digitizing_Tool.html Manual page].

See also [[GRASS Digitizing tool]].

Replacement of <tt>v.digit</tt> module integrated to Map display window ([http://svn.osgeo.org/grass/grass-addons/screenshots/wxpython/digitization Screenshots]).

<center>

{|
|-
| [[Image:WxDigit200804.png|thumb|300px|center|Vector digitizer (2008/04)]] ||
[[Image:Digit-01.png|thumb|300px|center|Vector digitizer (2007/11)]]
|-
| [[Image:WxGUI-vdigit-fill-area.png|thumb|300px|center|Vector digitizer - fill valid areas (closed boundary + centroid) (2008/07)]] ||
[[Image:WxGUI-vdigit-bg.png|thumb|300px|center|Vector digitizer - background raster maps with different opacity level (2008/07)]]
|-
|}
</center>

=== Raster digitizer ===

'''Status:''' development not started yet.

* r.digit (merge with v.digit?)
: Probably write a front end for [http://grass.osgeo.org/grass63/manuals/html63_user/r.in.poly.html r.in.poly], that's all the old r.digit is.
* d.rast.edit
: Idea: get cell center coords and new values from GUI interaction, then pass those through r.in.xyz, and r.patch the new values over the top of the old map.

* merge with Georectifier? (i.points, i.vpoints)

===== Category Labels =====

* Write with new r.category import tool
** ''Back-end component complete: r.category module is now updated to handle a rules= file and other goodies like dynamic labels''

* Read with one of r.category, r.describe, r.report, r.stats, ???
** probably need to add a new flag to one of those to print flat <tt>"%d %s", cat, label</tt>
: or read the cats/ file directly, it's already flat ascii.

* how to deal with FP maps & cats?

=== Ortho photos ===

'''Status:''' development not started yet.

* To replace i.ortho.photo and friends

=== Attribute table manager ===

[[Image:Wxgui-attribute-table-manager.png|right|thumb|350px|Attribute Table Manager]]

;'''Status:''' prototype implemented.

[http://grass.osgeo.org/grass64/manuals/html64_user/wxGUI.Attribute_Table_Manager.html Manual page].

;Allows:

* To browse attribute data, perform SQL select statements
* Modify attribute data, insert new records to attribute table, delete existing records
* Highlight selected items in Map Display Window
* Extract selected items into new vector map layer
* Modify attribute table - add, drop, rename columns
* Modify vector map layer DB connestion settings - add, remove or modify layers

=== NVIZ replacement ===

'''Status:''' under development.

Detailed information [[wxNVIZ]].

=== Imagery tools ===

'''Status:''' (re)development not started in earnest yet. Some behind-the-scenes code has been prepared, but not much.
: ''Volunteers welcome!''

=== Graphical modeller ===

'''Status:''' development not started yet.

=== GEM integration ===

'''Status:''' development not started yet.

[http://trac.osgeo.org/grass/browser/grass/trunk/gem GEM] is GRASS Extension Manager. Or use the R packages approach.

=== Data Catalog ===

;'''Status:''' Under development.

* [http://trac.osgeo.org/grass/browser/grass-addons/gui/wxpython/data_catalog Data Catalog]

<center>
{|
|-
| [[Image:Catalog.png|350px|thumb|center|Data Catalog ]]
| [[Image:Aspect.png|350px|thumb|center|Data Catalog]]
|-
|}
</center>

;Current Features:

* copy, delete, rename map layers (raster & vector) in current mapset.
* view raster & vector map layers from any location and any mapset.
* Provides a GUI wrapper for r.info & v.info grass commands while viewing map layers in mapwindow.

;To be implemented:

* copy, move map layers in different mapsets.
* View DBF files as tables.
* Copy, delete, rename DBF files.
* Modify attribute tables.
* Viewing other formats.
* ...

=== Help browser ===

'''Status:''' development not started yet.

For browsing manual pages is currently used web browser, the goal is to design integrated help system.
: HB: ''We used to have one of these for viewing the help pages of Tcl/Tk NVIZ. We dropped it because it was a pain to maintain and generally outside our core mission so a distraction.''

== Known issues ==

* See and report in trac: [http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&component=wxGUI&order=priority List of open issues]

* Warning "widget class `GtkPizza' has no property named `row-ending-details'", http://trac.osgeo.org/grass/ticket/204

=== Platform specific ===

For the GUI to know what platform it's on, and therefore apply platform specific commands (e.g. append '.exe' to programs) it has to test what platform it is running on. Here we take the experimental approach to learning what's best to use. Please add or generalize this list as you can.

Platform information - start Python from the command line then issue

<source lang="python">
import sys
sys.platform

import os
os.name
os.environ['OS']

import platform
platform.system()
</source>

* Results:

{| border="1" class="wikitable" style="text-align:center"
! Platform
! sys.platform
! os.name
! os.environ['OS']
! platform.system()
|-
| 32bit GNU/Linux
| linux2
| posix
| ''n/a''
| Linux
|-
| 64bit GNU/Linux
| linux2
| posix
| ''n/a''
| Linux
|-
| 32bit Mac OSX (PowerPC G4)
| darwin
| posix
| ''n/a''
| Darwin
|-
| 64bit Mac OSX (Intel)
| [1] see note
| ?
| ?
| ?
|-
| 32bit MS Windows XP
| win32
| nt
| Windows_NT
| Windows
|-
| 64bit MS Windows Vista
| win32
| nt
| Windows_NT
| Windows
|-
| 32bit MS Windows XP (Cygwin)
| win32
| ?
| ?
| ?
|}

[1] On Fri, May 29, 2009 at 10:49 PM, William Kyngesburye wrote:
: ''Right now the GUI only runs 32bit, even if the rest of GRASS is 64bit, because it's not yet possible for wxPython to be 64bit. It comes out the same as PPC 32bit - no distinction between ppc/intel or 32/64 bit, it's all darwin. (yes, I checked, and I have a custom 64bit python executable to verify)''

== General GUI Design ==

=== Layout ===

For some users, the current approach of separate windows (SDI) leads to a windows flooding. Especially on large monitors or dual screen systems catching the wxGUI windows can be tedious when they appear on separate monitors (depends on windows manager, the much used KDE scatters typically the wxGUI windows all over the screen real estate). Almost each task generates a new wxGUI window which is freely floating around on the screen: [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-03.png example 1] and [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-01.png example 2]. On a dual-screen this may sum up to 50cm of distance!

'''Proposed solutions:'''
* implement ''optional'' layout similar to QGIS (with a legend attached to each display) or [http://sourceforge.net/dbimage.php?id=215336 GSDView] etc) (see figure below)
* implement ''optional'' magnetic docking of the layer manager and display windows to keep the windows closer
* do not allow module windows to stay open. That is, get rid of the apply button and force each window to close when OK is pressed (QGIS/ArcGIS approach). This leaves only the display(s) and single legend/layer manager on desktop.
* If you otherwise wish to continue using your current WM, file a bug report with them asking for better multi-head support and get the problem fixed at the source. (there probably already is a bug filed with tips in it)

<center>
{|
|-
| [[Image:Wxgui_current.png|350px|thumb|center|Current wxGUI layout with detached window components]]
| [[Image:Wxgui_proposal.png|350px|thumb|center|'''Proposal''' for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)]]
|-
|}
</center>

'''New solution: see data catalog above.'''

====What others do====

'''SDI: (each document opened in application occupies a window on the desktop)'''
* GRASS: display window for each document (i.e., set of maps displayed) opened on desktop; one legend/layer manager window for all display windows; ; each module/function opens a separate window on the desktop
* QGIS: display window for each document (i.e., set of maps displayed) opened on the desktop; legend/layer manager window attached to each display window; each module/function opens a separate window on the desktop (e.g. http://grass.osgeo.org/grass61/screenshots/images/qgis08_grass6_toolbox.png)
* ArcGIS: similar to QGIS with combined legend/display for each document (set of maps displayed); each module/function opens a separate window on the desktop (e.g. http://upload.wikimedia.org/wikipedia/en/9/92/ArcMap.jpg)
* MapInfo (pre Pitney Bowes): each document opens a map display window on the desktop; single legend/toolbox opened on the desktop controls all visible documents (i.e., map displays); each module/function opens a separate window on the desktop

'''MDI: (a single frame is opened for the application on the desktop; all documents opened inside the application frame)'''
* SAGA: single application frame opened on the desktop; all documents (display windows) open inside application frame; one legend/layer manager for all display windows; each module/function opens a separate window inside the frame (http://www.saga-gis.uni-goettingen.de/html/images/bild8.gif and http://sourceforge.net/dbimage.php?id=44455)
* Ossim: single application frame opened on the desktop; all documents (display windows) open inside application frame; one legend/layer manager for all display windows; each module/function opens a separate window inside the frame (http://www.ossim.org/OSSIM/Albums/Pages/ImageLinker.html)
* Idrisi: similar to SAGA and Ossim (http://www.clarklabs.org/products/idrisi-taiga.cfm)
MapInfo (Pitney Bowes): Seems to be like Saga (http://www.pbinsight.com/support/training/video-tutorials/)

'''''See also'''''
* Solution to the problem: [http://www.wxwidgets.org/manuals/stable/wx_wxlayoutalgorithm.html wxLayoutAlgorithm]
* [http://en.wikipedia.org/wiki/Multiple_document_interface Multiple document interface] (MDI, windows reside under a single parent window)
* [http://en.wikipedia.org/wiki/Single_document_interface Single document interface] (SDI, separate windows, currently used for wxGUI)
* and [http://en.wikipedia.org/wiki/Human_interface_guidelines Human interface guidelines] (HIG)

== HowTo ==

* [[Import DXF]]

== Useful links ==

* [http://www.poromenos.org/tutorials/python 10 minutes Python tutorial] for programmers of other languages

== References ==

* [[User:Landa|Martin Landa]]: [http://gama.fsv.cvut.cz/~landa/publications/2008/gis-ostrava-08/paper/landa-grass-gui-wxpython.pdf New GUI for GRASS GIS based on wxPython] ([http://gis2008.com/indexe.html GIS Ostrava 2008], January 27-30, 2008, Ostrava, Czech Republic)
* [[User:Landa|Martin Landa]], Cristina Moretto, Michele Zanolli, Luca Manganelli and Markus Neteler: [http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/paper/grass-gfoss-tn.pdf wxPython-based GUI for GRASS GIS] ([http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/prezentazione/perugia-grass-gui-wxpython.pdf presentation]) ([http://www.grassmeeting2008.unipg.it IX Meeting degli Utenti Italiani di GRASS - GFOSS], February 20-22, Perugia, Italy)

[[Category:Development]]
[[Category:GUI]]
[[Category:Python]]

WxPython-based GUI for GRASS

2010-02-13T19:53:05Z

⚠️Cmbarton: /* Layout */

See also [[GRASS GUI]], [[GRASS and Python]] and [[GRASS SoC Ideas 2009‎]].

For developer-related issues see [http://trac.osgeo.org/grass/wiki/wxGUIDevelopment Trac wxGUI page].

__TOC__

== Overview ==

* [http://grass.osgeo.org/grass64/manuals/html64_user/wxGUI.html Manual page]
* A nice summary of the progress to date, written by Jachym Cepicky:
** [http://www.les-ejk.cz/english/wxgrass-new-grass-gui-1 Part 1]
** [http://www.les-ejk.cz/english/wxgrass-new-grass-gui-2 Part 2]
* [[User:Landa|Martin Landa]]: [http://gama.fsv.cvut.cz/~landa/publications/2008/gis-ostrava-08/paper/landa-grass-gui-wxpython.pdf New GUI for GRASS GIS based on wxPython] ([http://gis2008.com/indexe.html GIS Ostrava 2008], January 27-30, 2008, Ostrava, Czech Republic)
* [[User:Landa|Martin Landa]], Cristina Moretto, Michele Zanolli, Luca Manganelli and Markus Neteler: [http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/paper/grass-gfoss-tn.pdf wxPython-based GUI for GRASS GIS] ([http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/prezentazione/perugia-grass-gui-wxpython.pdf presentation]) ([http://www.grassmeeting2008.unipg.it IX Meeting degli Utenti Italiani di GRASS - GFOSS], February 20-22, Perugia, Italy)

=== Requirements ===

* [http://svn.osgeo.org/grass/grass/trunk/gui/wxpython/README README]

=== Development ===

Do you want to help with the development?

* basic Python programming ability required
* GUI programming experience welcomed (especially wxPython)
* GRASS user (or better developer) experience

How to get [http://trac.osgeo.org/grass/wiki/HowToContribute write access] to the GRASS SVN repository.

== Screenshots ==

* [http://svn.osgeo.org/grass/grass-addons/screenshots/wxpython SVN]
* [http://grass.osgeo.org/screenshots/gui.php Website screenshot page]
* Various screenshots from [[:Category:WxGUI|GRASS-Wiki]]

=== GNU/Linux ===

<center>
{|
|
[[Image:Wxgui-startup-gnulinux.png|300px|thumb|Start-up screen]]
||
[[Image:Wxgui-vdigit1-gnulinux.png|300px|thumb|Vector digitizer]]
|-
|
[[Image:Wxgui-atm0-gnulinux.png|300px|thumb|Attribute Table Manager]]
||
[[Image:Wxgui-vector-querying-gnulinux.png|300px|thumb|Querying vector map layers (attribute data)]]
|}
</center>

=== Mac OS ===

=== MS Windows ===

<center>
{|
|
[[Image:Wxgui-startup-windows1.png|300px|thumb|Start-up screen]]
||
[[Image:Wxgui-d-vect-windows.png|300px|thumb|GUI dialog d.vect]]
|-
|
[[Image:Wxgui-atm-windows.png|300px|thumb|Attribute Table Manager]]
||
[[Image:Wxgui-r-buffer-windows.png|300px|thumb|Running command (r.buffer)]]
|-
|
[[Image:Wxgui-vector-querying-windows.png|300px|thumb|Querying vector map layer (editable mode)]]
||
 
|}
</center>

== Components ==

=== Layer Manager ===

'''Status:''' prototype implemented.

The '''GRASS GIS Layer Manager''' provides an interactive graphical interface to GRASS commands. The Layer Manager includes a set of pull-down menus for all GRASS GIS functions (analysis, file I/O, GIS configuration and management), toolbar that manage display map layers in map display windows, layer tree in which map layers to display are organized, command output window and integrated command line prompt.

<div align="center">
{|
|[[Image:wxgrass-gis-manager-layer.png|350px]] || [[Image:wxgrass-gis-manager-output.png|350px]]
|}
</div>

<div align="center">
[[Image:Wxgrass rgb.png|350px]]
</div>

=== Map display window ===

'''Status:''' prototype implemented.

Each '''Map display window''' has a unique set of layers to display and region setting (zoom). The map display window includes main toolbar with basic tools including zooming, panning, data querying, simple analyse functions (measure, profile, histogram, etc.), overlay management, etc. From main toolbar are accessible additional toolbars, currently only Digitization tool is available. Under development is Georectification tool.

<center>
{|
|-
| [[Image:Wxgrass-mapdisplay-0.png|thumb|350px|center]] ||
[[Image:Wxgui-mapdisplay-1.png|thumb|350px|center]]
|-
|}
</center>

=== Module GUIs ===

'''Status:''' prototype implemented.

Generated from XML using <tt>--interface-description</tt>.

E.g. <tt>d.rgb --help</tt>
<pre>
Description:
Displays three user-specified raster map layers as red, green, and blue overlays in the active graphics frame.

Keywords:
display

Usage:
d.rgb [-ox] red=name green=name blue=name [--verbose] [--quiet]

Flags:
-o Overlay (non-null values only)
-x Don't add to list of commands in monitor
--v Verbose module output
--q Quiet module output

Parameters:
red Name of raster map to be used for <red>
green Name of raster map to be used for <green>
blue Name of raster map to be used for <blue>
</pre>

becomes with <tt>d.rgb --interface-description</tt>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE task SYSTEM "[http://trac.osgeo.org/grass/browser/grass/trunk/gui/xml/grass-interface.dtd grass-interface.dtd]">
<task name="d.rgb">
<description>
Displays three user-specified raster map layers as red, green, and blue overlays in the active graphics frame.
</description>
<keywords>
display
</keywords>
<parameter name="red" type="string" required="yes" multiple="no">
<description>
Name of raster map to be used for <red>
</description>
<keydesc>
<item order="1">name</item>
</keydesc>
<gisprompt age="old" element="cell" prompt="raster" />
</parameter>
<parameter name="green" type="string" required="yes" multiple="no">
<description>
Name of raster map to be used for <green>
</description>
<keydesc>
<item order="1">name</item>
</keydesc>
<gisprompt age="old" element="cell" prompt="raster" />
</parameter>
<parameter name="blue" type="string" required="yes" multiple="no">
<description>
Name of raster map to be used for <blue>
</description>
<keydesc>
<item order="1">name</item>
</keydesc>
<gisprompt age="old" element="cell" prompt="raster" />
</parameter>
<flag name="o">
<description>
Overlay (non-null values only)
</description>
</flag>
<flag name="x">
<description>
Don't add to list of commands in monitor
</description>
</flag>
<flag name="verbose">
<description>
Verbose module output
</description>
</flag>
<flag name="quiet">
<description>
Quiet module output
</description>
</flag>
</task>

which is then used to generate:

[[Image:wxgrass-d-rgb.png|center|600px]]

=== Startup GUI ===

'''Status:''' prototype implemented.

Start new GRASS session with

grass -wxpython

[[Image:Wxgrass-startup.png|center|400px]]

=== Location wizard ===

'''Status:''' prototype implemented.

Wizard for creating new GRASS project location based on:

* Coordinate system
* EPSG code
* Georeferenced file
* PROJ.4 string
* XY

See also [[GRASS Location Wizard]].

[[Image:Wxgui-location-wizard.png|center|thumb|600px|Location wizard]]

=== Cartography tools ===

'''Status:''' development not started yet.

==== GUI for ps.map ====

* [http://grass.osgeo.org/grass63/manuals/html63_user/ps.map.html ps.map] is a cartographic composer, intended to be a stand-alone hardcopy plot generator. It is not meant to be a '''Print''' button for the maps currently displayed in the map canvas, that will need it own controls.

* The GUI will prepare a semi-WYSIWYG + tree menu controls which can write a ps.map control file, and then run ps.map to create PostScript and PDF output directly. Loading a ps.map control file is harder and can happen later.

* For a start at a Tcl/Tk composer see gui/tcltk/d.m/print.tcl
: see also these discussions and pyGTK prototype by Jachym Cepicky
:* http://thread.gmane.org/gmane.comp.gis.grass.devel/12469
:* http://thread.gmane.org/gmane.comp.gis.grass.devel/19368

* Start with most important mapping instructions
** paper
** scale
** maploc
** rast
** vects
** grids
** scalebar
** mapinfo
** text labels

===== Intelligent label placement in ps.map =====

* use PAL/JPAL [http://geosysin.iict.ch/PAL cartographic labelling library] (GPL, C++ language, JNI wrapper)

===== Outputs =====

* ps.map instructions file
* PostScript file [ps.map instructions tmp file]
* lpr [PostScript tmp file]
* PDF File (pstopdf? ps2pdf? GNU Ghostscript?) [PostScript tmp file]

===== Inputs =====

* Ability to load in saved ps.map scripts. I consider this to be a low priority, deal with it after map creation is fully functional. Start with scripts saved using the GUI, after that is working expand to load any ps.map instructions file.

===== Prototype g-ps.map =====
* [http://les-ejk.cz/files/programs/grass/gpsmap-0.1.2.tgz gpsmap-0.1.2.tgz]
* [http://les-ejk.cz/tmp/gpsmap.png g-ps.map Screenshot]
* [http://www.nabble.com/status-of-g-ps.map-tf4465835.html#a12733414 Jachym's posting]

==== Direct printing ====

Implement direct printing of map canvas content using GRASS PS driver or Cairo driver.

* [http://trac.gispython.org/projects/PCL/wiki Python Cartographic Lab]
* [http://wiki.osgeo.org/wiki/OSGeo_Cartographic_Library OSGeo Cartographic Library]
** http://lists.osgeo.org/pipermail/discuss/2008-April/003337.html
** http://www.intevation.de/pipermail/freegis-list/2007-April/003142.html
* [http://wiki.osgeo.org/wiki/OSGeo_map_symbol_set OSGeo Map Symbol Set]
* [http://www.gdal.org/ogr/ogr_feature_style.html OGR - Feature Style Specification]
* [http://trac.osgeo.org/mapguide/wiki/MapGuideRfc14 MapGuide RFC 14 - Cartographic Stylization Engine]

* [http://www.iho.shom.fr/PUBLICATIONS/download.htm#special S-52 standard for nautical chart (ENC) symbology] and cartography from the [http://www.iho.shom.fr/ International Hydrographic Bureau]
** [http://openev.cvs.sourceforge.net/openev/contrib/S52/ GPL library implementing the S-52 standard] (OpenEV)

* [http://www.opengeospatial.org/standards/symbol OpenGIS Symbology Encoding Implementation Specification]

* [http://geosysin.iict.ch/trac/wiki/Index4extJPAL PAL]

=== Georectifier ===

'''Status:''' prototype implemented.

<center>
{|
|-
| [[Image:Wxgui-georectify-0.png|thumb|350px|center]] ||
[[Image:Wxgui-georectify-1.png|thumb|350px|center]]
|-
|}
</center>

=== Profile Analysis Tool ===

'''Status:''' prototype implemented.

<center>
{|
|-
| [[Image:Wxgui-profile-0.png|thumb|350px|center]] ||
[[Image:Wxgui-profile-1.png|thumb|350px|center]]
|-
|}
</center>

=== Vector digitizer ===

'''Status:''' prototype implemented.

[http://grass.osgeo.org/grass64/manuals/html64_user/wxGUI.Vector_Digitizing_Tool.html Manual page].

See also [[GRASS Digitizing tool]].

Replacement of <tt>v.digit</tt> module integrated to Map display window ([http://svn.osgeo.org/grass/grass-addons/screenshots/wxpython/digitization Screenshots]).

<center>

{|
|-
| [[Image:WxDigit200804.png|thumb|300px|center|Vector digitizer (2008/04)]] ||
[[Image:Digit-01.png|thumb|300px|center|Vector digitizer (2007/11)]]
|-
| [[Image:WxGUI-vdigit-fill-area.png|thumb|300px|center|Vector digitizer - fill valid areas (closed boundary + centroid) (2008/07)]] ||
[[Image:WxGUI-vdigit-bg.png|thumb|300px|center|Vector digitizer - background raster maps with different opacity level (2008/07)]]
|-
|}
</center>

=== Raster digitizer ===

'''Status:''' development not started yet.

* r.digit (merge with v.digit?)
: Probably write a front end for [http://grass.osgeo.org/grass63/manuals/html63_user/r.in.poly.html r.in.poly], that's all the old r.digit is.
* d.rast.edit
: Idea: get cell center coords and new values from GUI interaction, then pass those through r.in.xyz, and r.patch the new values over the top of the old map.

* merge with Georectifier? (i.points, i.vpoints)

===== Category Labels =====

* Write with new r.category import tool
** ''Back-end component complete: r.category module is now updated to handle a rules= file and other goodies like dynamic labels''

* Read with one of r.category, r.describe, r.report, r.stats, ???
** probably need to add a new flag to one of those to print flat <tt>"%d %s", cat, label</tt>
: or read the cats/ file directly, it's already flat ascii.

* how to deal with FP maps & cats?

=== Ortho photos ===

'''Status:''' development not started yet.

* To replace i.ortho.photo and friends

=== Attribute table manager ===

[[Image:Wxgui-attribute-table-manager.png|right|thumb|350px|Attribute Table Manager]]

;'''Status:''' prototype implemented.

[http://grass.osgeo.org/grass64/manuals/html64_user/wxGUI.Attribute_Table_Manager.html Manual page].

;Allows:

* To browse attribute data, perform SQL select statements
* Modify attribute data, insert new records to attribute table, delete existing records
* Highlight selected items in Map Display Window
* Extract selected items into new vector map layer
* Modify attribute table - add, drop, rename columns
* Modify vector map layer DB connestion settings - add, remove or modify layers

=== NVIZ replacement ===

'''Status:''' under development.

Detailed information [[wxNVIZ]].

=== Imagery tools ===

'''Status:''' (re)development not started in earnest yet. Some behind-the-scenes code has been prepared, but not much.
: ''Volunteers welcome!''

=== Graphical modeller ===

'''Status:''' development not started yet.

=== GEM integration ===

'''Status:''' development not started yet.

[http://trac.osgeo.org/grass/browser/grass/trunk/gem GEM] is GRASS Extension Manager. Or use the R packages approach.

=== Data Catalog ===

;'''Status:''' Under development.

* [http://trac.osgeo.org/grass/browser/grass-addons/gui/wxpython/data_catalog Data Catalog]

<center>
{|
|-
| [[Image:Catalog.png|350px|thumb|center|Data Catalog ]]
| [[Image:Aspect.png|350px|thumb|center|Data Catalog]]
|-
|}
</center>

;Current Features:

* copy, delete, rename map layers (raster & vector) in current mapset.
* view raster & vector map layers from any location and any mapset.
* Provides a GUI wrapper for r.info & v.info grass commands while viewing map layers in mapwindow.

;To be implemented:

* copy, move map layers in different mapsets.
* View DBF files as tables.
* Copy, delete, rename DBF files.
* Modify attribute tables.
* Viewing other formats.
* ...

=== Help browser ===

'''Status:''' development not started yet.

For browsing manual pages is currently used web browser, the goal is to design integrated help system.
: HB: ''We used to have one of these for viewing the help pages of Tcl/Tk NVIZ. We dropped it because it was a pain to maintain and generally outside our core mission so a distraction.''

== Known issues ==

* See and report in trac: [http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&component=wxGUI&order=priority List of open issues]

* Warning "widget class `GtkPizza' has no property named `row-ending-details'", http://trac.osgeo.org/grass/ticket/204

=== Platform specific ===

For the GUI to know what platform it's on, and therefore apply platform specific commands (e.g. append '.exe' to programs) it has to test what platform it is running on. Here we take the experimental approach to learning what's best to use. Please add or generalize this list as you can.

Platform information - start Python from the command line then issue

<source lang="python">
import sys
sys.platform

import os
os.name
os.environ['OS']

import platform
platform.system()
</source>

* Results:

{| border="1" class="wikitable" style="text-align:center"
! Platform
! sys.platform
! os.name
! os.environ['OS']
! platform.system()
|-
| 32bit GNU/Linux
| linux2
| posix
| ''n/a''
| Linux
|-
| 64bit GNU/Linux
| linux2
| posix
| ''n/a''
| Linux
|-
| 32bit Mac OSX (PowerPC G4)
| darwin
| posix
| ''n/a''
| Darwin
|-
| 64bit Mac OSX (Intel)
| [1] see note
| ?
| ?
| ?
|-
| 32bit MS Windows XP
| win32
| nt
| Windows_NT
| Windows
|-
| 64bit MS Windows Vista
| win32
| nt
| Windows_NT
| Windows
|-
| 32bit MS Windows XP (Cygwin)
| win32
| ?
| ?
| ?
|}

[1] On Fri, May 29, 2009 at 10:49 PM, William Kyngesburye wrote:
: ''Right now the GUI only runs 32bit, even if the rest of GRASS is 64bit, because it's not yet possible for wxPython to be 64bit. It comes out the same as PPC 32bit - no distinction between ppc/intel or 32/64 bit, it's all darwin. (yes, I checked, and I have a custom 64bit python executable to verify)''

== General GUI Design ==

=== Layout ===

For some users, the current approach of separate windows (SDI) leads to a windows flooding. Especially on large monitors or dual screen systems catching the wxGUI windows can be tedious when they appear on separate monitors (depends on windows manager, the much used KDE scatters typically the wxGUI windows all over the screen real estate). Almost each task generates a new wxGUI window which is freely floating around on the screen: [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-03.png example 1] and [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-01.png example 2]. On a dual-screen this may sum up to 50cm of distance!

'''Proposed solutions:'''
* implement ''optional'' layout similar to QGIS (with a legend attached to each display) or [http://sourceforge.net/dbimage.php?id=215336 GSDView] etc) (see figure below)
* implement ''optional'' magnetic docking of the layer manager and display windows to keep the windows closer
* If you otherwise wish to continue using your current WM, file a bug report with them asking for better multi-head support and get the problem fixed at the source. (there probably already is a bug filed with tips in it)

<center>
{|
|-
| [[Image:Wxgui_current.png|350px|thumb|center|Current wxGUI layout with detached window components]]
| [[Image:Wxgui_proposal.png|350px|thumb|center|'''Proposal''' for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)]]
|-
|}
</center>

'''New solution: see data catalog above.'''

'''What others do:'''
* QGIS: all basic parts in one frame with legend integrated: e.g. http://grass.osgeo.org/grass61/screenshots/images/qgis08_grass6_toolbox.png
* SAGA: several windows in one frame: http://www.saga-gis.uni-goettingen.de/html/images/bild8.gif and http://sourceforge.net/dbimage.php?id=44455

'''''See also'''''
* Solution to the problem: [http://www.wxwidgets.org/manuals/stable/wx_wxlayoutalgorithm.html wxLayoutAlgorithm]
* [http://en.wikipedia.org/wiki/Multiple_document_interface Multiple document interface] (MDI, windows reside under a single parent window)
* [http://en.wikipedia.org/wiki/Single_document_interface Single document interface] (SDI, separate windows, currently used for wxGUI)
* and [http://en.wikipedia.org/wiki/Human_interface_guidelines Human interface guidelines] (HIG)

== HowTo ==

* [[Import DXF]]

== Useful links ==

* [http://www.poromenos.org/tutorials/python 10 minutes Python tutorial] for programmers of other languages

== References ==

* [[User:Landa|Martin Landa]]: [http://gama.fsv.cvut.cz/~landa/publications/2008/gis-ostrava-08/paper/landa-grass-gui-wxpython.pdf New GUI for GRASS GIS based on wxPython] ([http://gis2008.com/indexe.html GIS Ostrava 2008], January 27-30, 2008, Ostrava, Czech Republic)
* [[User:Landa|Martin Landa]], Cristina Moretto, Michele Zanolli, Luca Manganelli and Markus Neteler: [http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/paper/grass-gfoss-tn.pdf wxPython-based GUI for GRASS GIS] ([http://gama.fsv.cvut.cz/~landa/publications/2008/gfoss-it-08/prezentazione/perugia-grass-gui-wxpython.pdf presentation]) ([http://www.grassmeeting2008.unipg.it IX Meeting degli Utenti Italiani di GRASS - GFOSS], February 20-22, Perugia, Italy)

[[Category:Development]]
[[Category:GUI]]
[[Category:Python]]

GRASS 7 Terminology

2009-04-27T04:42:54Z

⚠️Cmbarton: /* Vector layer */

This page is dedicated to discussion about changes in terminology for GRASS 7.

== Map ==

Currently data entities like rasters or vectors are called in GRASS "maps", i.e. "raster map" or "vector map".

* [[User:Landa|ML]]: GRASS is basically '''"layer-based"''' GIS, calling single raster or vector entities as "maps" is quite confusing. Better would be to use term "layer" or "map layer" for this purpose. "Map" can be used for layer composition, e.g. for cartography outputs.

;Proposal(s)

* map layer
** raster layer
** 3D raster layer
** vector layer

== Vector layer ==

The term "vector layer" is currently used even in more confusing sense, to mark subgroup of vector objects in vector entity. Originally called as "field".

* [[User:Landa|ML]]: Not sure if to go back to the original term "field" (DB-based) or use something like "sub-layer".
* WB: How about calling it "attribute-layer" which connects to an "attribute-table" (DB table)?

;Proposal(s)

* field number
* key
** +1 ([[User:cmbarton|Michael]]). This is the proper term in database terminology. A vector must have at least one set of keys (= 1 or more layers). These are currently called "CAT" for category. The history of this is that it parallels the "category" of a raster cell. Back in GRASS 5 and below, vectors were not regularly linked to external tables (although it was possible to link up a PostgreSQL table) and each vector object had an integer identifier (i.e., a category) and a label, just like a raster. However, since Radim rewrote the vector architecture for GRASS 5.7 (6.0 beta) and above, it is used quite differently, as the key field to link vector objects to lines in an attribute data table. This is pretty standard relational database structure. A linked table is not mandatory, but AFAIK, at least 1 "layer" of "cat" values (i.e., key field values) is required for any vector file. So, I suggest that we don't make up a special GRASS term for a key field but just use the term key (or keyfield). Any set of vector objects in a file can have 1 or more key fields. This identifies each vector object with 1 or more keys, and has the potential to link each object to a line in an attribute data table that has a matching key. In GRASS, keys do not have to be unique; this does not keep them from being keys, but is simply a characteristic of GRASS key fields.
* keyfield
* table link
* category set
** +1 ([[User:Landa|ML]])

== See also ==

* http://lists.osgeo.org/pipermail/grass-dev/2008-August/039277.html
* [http://grass.osgeo.org/gdp/html_grass5/terminology.html GRASS 5 terminology]
* [http://www.nabble.com/terminology-fixes-in-GRASS-td7856076.html#a7856076 GRASS 6 terminology fixes]
* The terminology is related to '''flags and parameters standardization'''. See [http://trac.osgeo.org/grass/browser/grass/trunk/doc/parms_flags.txt proposal(s)].

[[Category: Development]]

GRASS SoC Ideas 2009

2009-03-26T21:10:49Z

⚠️Cmbarton: /* Ideas */

[[Image:2009 summer of code logo final r3-01.png|right|400px]]

== About ==
<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0em 1em 1em 1em; background-color:#FFF5E5;">
'''March 2009: This page is open to contributions - please edit!'''
</div>

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2009. Here we will list project ideas and and other information related to the GRASS GSoC projects.

Promotion:
OSGeo Flyer at http://svn.osgeo.org/osgeo/marketing/flyer/
Videos at http://code.google.com/p/google-summer-of-code/wiki/Videos
More Flyers at http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers

== Timeline ==

([http://code.google.com/opensource/gsoc/2009/faqs.html#0_1_timeline_5354032302481437_ GSoC timeline])

* Community bonding time (getting to know the students)
* Deadline for student's applications (April 3rd)
* Accepted proposals announced (April 20th)
* Work Begins (May 23th)
* Midterm evaluation (July 6th-13th)
* Pencils down! (August 10th-17th)

== Required Steps ==

* List ideas
* Assign Mentors to Ideas
* Notify OSGeo
* Mentors evaluate student applications ('''Deadline April 3rd''')
* April 20st: Accepted students announced
* Students subscribe to the [http://grass.osgeo.org/community/support.php grass-dev mailing list] and introduce themselves
* Create directory structure in the [http://trac.osgeo.org/grass/browser/grass-addons GRASS add-ons SVN] for projects and setup access for students
** Students must read and post agreement to [http://download.osgeo.org/grass/grass6_progman/rfc/ RFC2] to the [http://grass.osgeo.org/community/support.php grass-psc mailing list] to gain SVN access
** Create a Wiki page for each accepted project, to be used as a progress reporting tool
* Coding begins...
* Students and mentors: Complete the Mid-term survey
* Final commit and packaging for Google

== Ideas ==

* '''Also review ideas from [[GRASS SoC Ideas 2008#Ideas|2008]] which are still open'''.
* Project ideas of your own are also most welcome.

=== [[wxGUI]] ===

* While the GUI is becoming very powerful, there is potential for improvement of the layout. It is suggested to reorganize the wxGUI layout to be more similar to QGIS and likeminded with all-in-one-frame interface (see figure below). Essentially follow the [http://en.wikipedia.org/wiki/Human_interface_guidelines Human interface guidelines] and mind your users (and where they come from - think newcomers to the GRASS world - "Don't Limit Your User Base" by being too different from others). If possible, this could be implemented as ''skin'' to give users choices to also get wxGUI as Multiple Document Interface (MDI, i.e, the wxGUI windows reside under a single parent window). More [[WxGUI#Layout|here]].

[[Image:Wxgui_current.png|200px|thumb|center|Current wxGUI layout with detached window components]] [[Image:Wxgui_proposal.png|200px|thumb|center|Proposal for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)]]

* Implement new [[wxGUI#GEM integration|extension manager]] which downloads from GRASS Addons SVN (Unix based systems) or from precompiled Windows binaries ([http://trac.osgeo.org/osgeo4w/ OSGeo4W]?). See the [http://cran.at.r-project.org/web/packages/ R packages manager]

* Continue [[wxNviz]] development for enhanced 3-4D visualization and analysis.

* Implement [[wxGUI#Graphical_modeller|graphical modeller]].

* Develop a [[WxPython-based_GUI_for_GRASS#Cartography_tools|graphical cartographic module]] - something like a GUI front-end or replacement for ps.map

* Create a fully functional command line interface with history within the GUI (see [http://trac.osgeo.org/grass/ticket/528#comment:6 suggestion])

* Develop a GUI module in wxPython for creating animations from multiple maps and saving animation outputs to animated GIF, MOV, or MPEG files.

====Kriging GUI====
Currently GRASS has no native support for Kriging. Kriging is done either with the R package or with the GStat package. Both are command driven and thus a GUI could be created to control the program. R could be maybe called directly or via a script to do the variograms etc.

Your job would be to create a GUI (in wxPython) that can:
# Do Kriging based on R
#* Create and edit R scripts
#* Call R to do variogram analysis. For efficiency the R environment should be done
#* Call R to do the actual Kriging. This includes importing the result back to GRASS.
# Do Kriging based on gstat.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.

: See [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.autokrige v.autokridge] in Addons

'''Willing to Mentor:'''Wolf Bergenheim

* Develop a graphing toolkit that could be used by other modules and by GUI to create analytical graphs like histograms and scatter plots.

=== Raster ===

* implement [[OpenMP]] (multithreading) as much as possible

* Enhance current visibility module to encompass cumulative viewshed analysis and related functions (see [http://www.uni-kiel.de/ufg/ufg_BerDucke.htm B. Ducke's site]). Considerable code already started in AddOns

* Anisotropic spreading simulator. Bring wildfire simulation modules up to date in GRASS 6.4-7 and make them into a more general anisotropic spreading module (useful for other kinds of spreading phenomena).

=== Vector ===

* implement [[OpenMP]] multithreading) as much as possible

* Rewrite {{cmd|v.select}} to implement more spatial operators (currently only "overlap" is available) - see [http://edndoc.esri.com/arcsde/9.0/general_topics/understand_spatial_relations.htm].
: Probably merge {{cmd|v.select}} with {{cmd|v.overlay}}.
: ''--HB: I'm not so sure that a merge is justified; they perform two conceptually different tasks. A full-summer project would probably require more than this one task''

* Implement [http://www.vividsolutions.com/JCS/images/Road%20Network%20Matching.gif vector conflation] to match vector networks from different sources (even rasterized streets from aerial/satellite imagery)

* Further development of network analysis, modules for calculating new indicators such as degree, betweenness, etc, a v.net.distance module (see [http://trac.osgeo.org/grass/ticket/521 ticket 521], integration of time tables (train, public transport) into routing, etc.

* Update and enhance vector querying to give full query capabilities to GRASS vectors. See vector querying section of [http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan GRASS 6.4 Feature Plan].

=== Imagery ===

* GRASS's imagery modules (for satellite, scanned maps, and orthophotos) act as enhanced raster modules. In GRASS 5 and 6 they were mostly implimented using interactive X-monitors which are not available in MS Windows and so are removed in the new cross-platform code of GRASS 7.
** We need someone willing to port the old modules to work with GRASS 7, including writing new wxPython GUI frontends to a number of existing tools and updating the imagery libraries to current raster library standards.
** In addition, there are a number of improved/automated georectification tools which have not been merged into GRASS 5/6 which it would be nice to have updated and merged into the main code.

* implement [[OpenMP]] multithreading) as much as possible

See the [[Image_processing#Ideas_collection_for_improving_GRASS.27_Image_processing_capabilities|Ideas for imagery improvement]] and [[GRASS_7_ideas_collection#Imagery|GRASS 7 ideas]] wiki pages for more details.

=== Other ===

* Continue the development of [[WinGRASS_Current_Status|GRASS for Windows]]. We are especially interested in having GRASS work on Windows Vista.

== Guidelines for Students ==

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing [http://lists.osgeo.org/mailman/listinfo/grass-dev our dev-mailing list], or come and talk to us in [[IRC]] (#grass). You can also reach the mentors directly by emailing:
* Wolf Bergenheim (wolf+grass@bergenheim.net)

=== Getting started with GRASS coding ===

* The source code is maintained in a [http://trac.osgeo.org/grass/browser/grass/trunk SVN server] which is easy to browse
: Please review the SUBMITTING files there for our coding standards.

* There is lots of good info at the [http://trac.osgeo.org/grass/wiki GRASS Developer's wiki]
: See also the [[Development|development section]] of the GRASS user's wiki

== Accepted Ideas ==



[[Category:Development]]
[[Category:Community]]
[[Category:GSoC]]

GRASS SoC Ideas 2009

2009-03-26T20:59:33Z

⚠️Cmbarton: /* wxGUI */

[[Image:2009 summer of code logo final r3-01.png|right|400px]]

== About ==
<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0em 1em 1em 1em; background-color:#FFF5E5;">
'''March 2009: This page is open to contributions - please edit!'''
</div>

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2009. Here we will list project ideas and and other information related to the GRASS GSoC projects.

Promotion:
OSGeo Flyer at http://svn.osgeo.org/osgeo/marketing/flyer/
Videos at http://code.google.com/p/google-summer-of-code/wiki/Videos
More Flyers at http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers

== Timeline ==

([http://code.google.com/opensource/gsoc/2009/faqs.html#0_1_timeline_5354032302481437_ GSoC timeline])

* Community bonding time (getting to know the students)
* Deadline for student's applications (April 3rd)
* Accepted proposals announced (April 20th)
* Work Begins (May 23th)
* Midterm evaluation (July 6th-13th)
* Pencils down! (August 10th-17th)

== Required Steps ==

* List ideas
* Assign Mentors to Ideas
* Notify OSGeo
* Mentors evaluate student applications ('''Deadline April 3rd''')
* April 20st: Accepted students announced
* Students subscribe to the [http://grass.osgeo.org/community/support.php grass-dev mailing list] and introduce themselves
* Create directory structure in the [http://trac.osgeo.org/grass/browser/grass-addons GRASS add-ons SVN] for projects and setup access for students
** Students must read and post agreement to [http://download.osgeo.org/grass/grass6_progman/rfc/ RFC2] to the [http://grass.osgeo.org/community/support.php grass-psc mailing list] to gain SVN access
** Create a Wiki page for each accepted project, to be used as a progress reporting tool
* Coding begins...
* Students and mentors: Complete the Mid-term survey
* Final commit and packaging for Google

== Ideas ==

* '''Also review ideas from [[GRASS SoC Ideas 2008#Ideas|2008]] which are still open'''.
* Project ideas of your own are also most welcome.

=== [[wxGUI]] ===

* While the GUI is becoming very powerful, there is potential for improvement of the layout. It is suggested to reorganize the wxGUI layout to be more similar to QGIS and likeminded with all-in-one-frame interface (see figure below). Essentially follow the [http://en.wikipedia.org/wiki/Human_interface_guidelines Human interface guidelines] and mind your users (and where they come from - think newcomers to the GRASS world - "Don't Limit Your User Base" by being too different from others). If possible, this could be implemented as ''skin'' to give users choices to also get wxGUI as Multiple Document Interface (MDI, i.e, the wxGUI windows reside under a single parent window). More [[WxGUI#Layout|here]].

[[Image:Wxgui_current.png|200px|thumb|center|Current wxGUI layout with detached window components]]
[[Image:Wxgui_proposal.png|200px|thumb|center|Proposal for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)]]

====GUI/Extension Manager Integration====
* Implement new [[wxGUI#GEM integration|extension manager]] which downloads from GRASS Addons SVN (Unix based systems) or from precompiled Windows binaries ([http://trac.osgeo.org/osgeo4w/ OSGeo4W]?). See the [http://cran.at.r-project.org/web/packages/ R packages manager]

====Enhance wxNviz for 3-4D visualization====
* Continue in [[wxNviz]] development.

====Graphical Modeling and Scripter====
* Implement [[wxGUI#Graphical_modeller|graphical modeller]].

====Cartography GUI====
* Develop a [[WxPython-based_GUI_for_GRASS#Cartography_tools|graphical cartographic module]] - something like a GUI front-end or replacement for ps.map

====Command Line Interface====
* Create a fully functional command line interface with history within the GUI (see [http://trac.osgeo.org/grass/ticket/528#comment:6 suggestion])

====Animation GUI====
* Develop a GUI module in wxPython for creating animations from multiple maps and saving animation outputs to animated GIF, MOV, or MPEG files.

====Kriging GUI====
Currently GRASS has no native support for Kriging. Kriging is done either with the R package or with the GStat package. Both are command driven and thus a GUI could be created to control the program. R could be maybe called directly or via a script to do the variograms etc.

Your job would be to create a GUI (in wxPython) that can:
# Do Kriging based on R
#* Create and edit R scripts
#* Call R to do variogram analysis. For efficiency the R environment should be done
#* Call R to do the actual Kriging. This includes importing the result back to GRASS.
# Do Kriging based on gstat.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.

: See [http://trac.osgeo.org/grass/browser/grass-addons/vector/v.autokrige v.autokridge] in Addons

'''Willing to Mentor:'''Wolf Bergenheim
====Enhanced Visibility Analysis Tools====
* Enhance current visibility module to encompass cumulative viewshed analysis and related functions (see [http://www.uni-kiel.de/ufg/ufg_BerDucke.htm B. Ducke's site]). Considerable code already started in AddOns

====Anisotropic spreading simulator====
* Bring wildfire simulation modules up to date in GRASS 6.4-7 and make them into a more general anisotropic spreading module (useful for other kinds of spreading phenomena).

=== Raster ===

* implement [[OpenMP]] (multithreading) as much as possible

=== Vector ===

* implement [[OpenMP]] multithreading) as much as possible

* Rewrite {{cmd|v.select}} to implement more spatial operators (currently only "overlap" is available) - see [http://edndoc.esri.com/arcsde/9.0/general_topics/understand_spatial_relations.htm].
: Probably merge {{cmd|v.select}} with {{cmd|v.overlay}}.
: ''--HB: I'm not so sure that a merge is justified; they perform two conceptually different tasks. A full-summer project would probably require more than this one task''

* Implement [http://www.vividsolutions.com/JCS/images/Road%20Network%20Matching.gif vector conflation] to match vector networks from different sources (even rasterized streets from aerial/satellite imagery)

* Further development of network analysis, modules for calculating new indicators such as degree, betweenness, etc, a v.net.distance module (see [http://trac.osgeo.org/grass/ticket/521 ticket 521], integration of time tables (train, public transport) into routing, etc.

* Update and enhance vector querying to give full query capabilities to GRASS vectors. See vector querying section of [http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan GRASS 6.4 Feature Plan].

=== Imagery ===

* GRASS's imagery modules (for satellite, scanned maps, and orthophotos) act as enhanced raster modules. In GRASS 5 and 6 they were mostly implimented using interactive X-monitors which are not available in MS Windows and so are removed in the new cross-platform code of GRASS 7.
** We need someone willing to port the old modules to work with GRASS 7, including writing new wxPython GUI frontends to a number of existing tools and updating the imagery libraries to current raster library standards.
** In addition, there are a number of improved/automated georectification tools which have not been merged into GRASS 5/6 which it would be nice to have updated and merged into the main code.

* implement [[OpenMP]] multithreading) as much as possible

See the [[Image_processing#Ideas_collection_for_improving_GRASS.27_Image_processing_capabilities|Ideas for imagery improvement]] and [[GRASS_7_ideas_collection#Imagery|GRASS 7 ideas]] wiki pages for more details.

=== Other ===

* Continue the development of [[WinGRASS_Current_Status|GRASS for Windows]]. We are especially interested in having GRASS work on Windows Vista.

== Guidelines for Students ==

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing [http://lists.osgeo.org/mailman/listinfo/grass-dev our dev-mailing list], or come and talk to us in [[IRC]] (#grass). You can also reach the mentors directly by emailing:
* Wolf Bergenheim (wolf+grass@bergenheim.net)

=== Getting started with GRASS coding ===

* The source code is maintained in a [http://trac.osgeo.org/grass/browser/grass/trunk SVN server] which is easy to browse
: Please review the SUBMITTING files there for our coding standards.

* There is lots of good info at the [http://trac.osgeo.org/grass/wiki GRASS Developer's wiki]
: See also the [[Development|development section]] of the GRASS user's wiki

== Accepted Ideas ==



[[Category:Development]]
[[Category:Community]]
[[Category:GSoC]]

GRASS SoC Ideas 2009

2009-03-22T16:37:10Z

⚠️Cmbarton: /* Vector */

[[Image:2009 summer of code logo final r3-01.png|right|400px]]

== About ==
<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0em 1em 1em 1em; background-color:#FFF5E5;">
'''March 2009: This page is open to contributions - please edit!'''
</div>

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2009. Here we will list project ideas and and other information related to the GRASS GSoC projects.

Promotion:
OSGeo Flyer at http://svn.osgeo.org/osgeo/marketing/flyer/
Videos at http://code.google.com/p/google-summer-of-code/wiki/Videos
More Flyers at http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers

== Timeline ==

([http://code.google.com/opensource/gsoc/2009/faqs.html#0_1_timeline_5354032302481437_ GSoC timeline])

* Community bonding time (getting to know the students)
* Deadline for student's applications (April 3rd)
* Accepted proposals announced (April 20th)
* Work Begins (May 23th)
* Midterm evaluation (July 6th-13th)
* Pencils down! (August 10th-17th)

== Required Steps ==

* List ideas
* Assign Mentors to Ideas
* Notify OSGeo
* Mentors evaluate student applications ('''Deadline April 3rd''')
* April 20st: Accepted students announced
* Students subscribe to the [http://grass.osgeo.org/community/support.php grass-dev mailing list] and introduce themselves
* Create directory structure in the [http://trac.osgeo.org/grass/browser/grass-addons GRASS add-ons SVN] for projects and setup access for students
** Students must read and post agreement to [http://download.osgeo.org/grass/grass6_progman/rfc/ RFC2] to the [http://grass.osgeo.org/community/support.php grass-psc mailing list] to gain SVN access
** Create a Wiki page for each accepted project, to be used as a progress reporting tool
* Coding begins...
* Students and mentors: Complete the Mid-term survey
* Final commit and packaging for Google

== Ideas ==

* '''Also review ideas from [[GRASS SoC Ideas 2008#Ideas|2008]] which are still open'''.
* Project ideas of your own are also most welcome.

=== [[wxGUI]] ===

* Reorganize the wxGUI layout to be more similar to QGIS and likeminded with all-in-one-frame interface. Essentially follow the [http://en.wikipedia.org/wiki/Human_interface_guidelines Human interface guidelines] mind your users (and where they come from!) and "Don't Limit Your User Base" by being too different from others. This could also be implemented as ''skin'' to give users choices to also get wxGUI as Multiple document interface (i.e, the wxGUI windows reside under a single parent window) . More [[WxGUI#Layout|here]]

* Implement new [[wxGUI#GEM integration|extension manager]] which downloads from GRASS Addons SVN (Unix based systems) or from precompiled Windows binaries (OSgeo4W?). See the [http://cran.at.r-project.org/web/packages/ R packages manager]

* Continue in [[wxNviz]] development.

* Implement [[wxGUI#Graphical_modeller|graphical modeller]].

* Develop a graphical cartographic module - something like a GUI front-end or replacement for ps.map

* Create a fully functional command line interface with history within the GUI

* Develop a GUI module in wxPython for creating animations from multiple maps and saving animation outputs to animated GIF, MOV, or MPEG files.

=== Raster ===

* implement [[OpenMP]] (multithreading) as much as possible

=== Vector ===

* implement [[OpenMP]] multithreading) as much as possible

* Rewrite {{cmd|v.select}} to implement more spatial operators (currently only "overlap" is available) - see [http://edndoc.esri.com/arcsde/9.0/general_topics/understand_spatial_relations.htm].
: Probably merge {{cmd|v.select}} with {{cmd|v.overlay}}.
: ''--HB: I'm not so sure that a merge is justified; they perform two conceptually different tasks. A full-summer project would probably require more than this one task''

* Implement [http://www.vividsolutions.com/JCS/images/Road%20Network%20Matching.gif vector conflation] to match vector networks from different sources (even rasterized streets from aerial/satellite imagery)

* Further development of network analysis, modules for calculating new indicators such as degree, betweenness, etc, a v.net.distance module (see [http://trac.osgeo.org/grass/ticket/521 ticket 521], integration of time tables (train, public transport) into routing, etc.

* Update and enhance vector querying to give full query capabilities to GRASS vectors. See vector querying section of [http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan GRASS 6.4 Feature Plan].

=== Imagery ===

* GRASS's imagery modules (for satellite, scanned maps, and orthophotos) act as enhanced raster modules. In GRASS 5 and 6 they were mostly implimented using interactive X-monitors which are not available in MS Windows and so are removed in the new cross-platform code of GRASS 7.
** We need someone willing to port the old modules to work with GRASS 7, including writing new wxPython GUI frontends to a number of existing tools and updating the imagery libraries to current raster library standards.
** In addition, there are a number of improved/automated georectification tools which have not been merged into GRASS 5/6 which it would be nice to have updated and merged into the main code.

* implement [[OpenMP]] multithreading) as much as possible

See the [[Image_processing#Ideas_collection_for_improving_GRASS.27_Image_processing_capabilities|Ideas for imagery improvement]] and [[GRASS_7_ideas_collection#Imagery|GRASS 7 ideas]] wiki pages for more details.

== Guidelines for Students ==

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing [http://lists.osgeo.org/mailman/listinfo/grass-dev our dev-mailing list], or come and talk to us in [[IRC]] (#grass). You can also reach the mentors directly by emailing:
* Wolf Bergenheim (wolf+grass@bergenheim.net)

=== Getting started with GRASS coding ===

* The source code is maintained in a [http://trac.osgeo.org/grass/browser/grass/trunk SVN server] which is easy to browse
: Please review the SUBMITTING files there for our coding standards.

* There is lots of good info at the [http://trac.osgeo.org/grass/wiki GRASS Developer's wiki]
: See also the [[Development|development section]] of the GRASS user's wiki

== Accepted Ideas ==



[[Category:Development]]
[[Category:Community]]
[[Category:GSoC]]

GRASS SoC Ideas 2009

2009-03-22T16:31:38Z

⚠️Cmbarton: /* wxGUI */

[[Image:2009 summer of code logo final r3-01.png|right|400px]]

== About ==
<div style="margin:0; margin-top:10px; margin-right:10px; border:1px solid #dfdfdf; padding:0em 1em 1em 1em; background-color:#FFF5E5;">
'''March 2009: This page is open to contributions - please edit!'''
</div>

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2009. Here we will list project ideas and and other information related to the GRASS GSoC projects.

Promotion:
OSGeo Flyer at http://svn.osgeo.org/osgeo/marketing/flyer/
Videos at http://code.google.com/p/google-summer-of-code/wiki/Videos
More Flyers at http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers

== Timeline ==

([http://code.google.com/opensource/gsoc/2009/faqs.html#0_1_timeline_5354032302481437_ GSoC timeline])

* Community bonding time (getting to know the students)
* Deadline for student's applications (April 3rd)
* Accepted proposals announced (April 20th)
* Work Begins (May 23th)
* Midterm evaluation (July 6th-13th)
* Pencils down! (August 10th-17th)

== Required Steps ==

* List ideas
* Assign Mentors to Ideas
* Notify OSGeo
* Mentors evaluate student applications ('''Deadline April 3rd''')
* April 20st: Accepted students announced
* Students subscribe to the [http://grass.osgeo.org/community/support.php grass-dev mailing list] and introduce themselves
* Create directory structure in the [http://trac.osgeo.org/grass/browser/grass-addons GRASS add-ons SVN] for projects and setup access for students
** Students must read and post agreement to [http://download.osgeo.org/grass/grass6_progman/rfc/ RFC2] to the [http://grass.osgeo.org/community/support.php grass-psc mailing list] to gain SVN access
** Create a Wiki page for each accepted project, to be used as a progress reporting tool
* Coding begins...
* Students and mentors: Complete the Mid-term survey
* Final commit and packaging for Google

== Ideas ==

* '''Also review ideas from [[GRASS SoC Ideas 2008#Ideas|2008]] which are still open'''.
* Project ideas of your own are also most welcome.

=== [[wxGUI]] ===

* Reorganize the wxGUI layout to be more similar to QGIS and likeminded with all-in-one-frame interface. Essentially follow the [http://en.wikipedia.org/wiki/Human_interface_guidelines Human interface guidelines] mind your users (and where they come from!) and "Don't Limit Your User Base" by being too different from others. This could also be implemented as ''skin'' to give users choices to also get wxGUI as Multiple document interface (i.e, the wxGUI windows reside under a single parent window) . More [[WxGUI#Layout|here]]

* Implement new [[wxGUI#GEM integration|extension manager]] which downloads from GRASS Addons SVN (Unix based systems) or from precompiled Windows binaries (OSgeo4W?). See the [http://cran.at.r-project.org/web/packages/ R packages manager]

* Continue in [[wxNviz]] development.

* Implement [[wxGUI#Graphical_modeller|graphical modeller]].

* Develop a graphical cartographic module - something like a GUI front-end or replacement for ps.map

* Create a fully functional command line interface with history within the GUI

* Develop a GUI module in wxPython for creating animations from multiple maps and saving animation outputs to animated GIF, MOV, or MPEG files.

=== Raster ===

* implement [[OpenMP]] (multithreading) as much as possible

=== Vector ===

* implement [[OpenMP]] multithreading) as much as possible

* Rewrite {{cmd|v.select}} to implement more spatial operators (currently only "overlap" is available) - see [http://edndoc.esri.com/arcsde/9.0/general_topics/understand_spatial_relations.htm].
: Probably merge {{cmd|v.select}} with {{cmd|v.overlay}}.
: ''--HB: I'm not so sure that a merge is justified; they perform two conceptually different tasks. A full-summer project would probably require more than this one task''

* Implement [http://www.vividsolutions.com/JCS/images/Road%20Network%20Matching.gif vector conflation] to match vector networks from different sources (even rasterized streets from aerial/satellite imagery)

* Further development of network analysis, modules for calculating new indicators such as degree, betweenness, etc, a v.net.distance module (see [http://trac.osgeo.org/grass/ticket/521 ticket 521], integration of time tables (train, public transport) into routing, etc.

=== Imagery ===

* GRASS's imagery modules (for satellite, scanned maps, and orthophotos) act as enhanced raster modules. In GRASS 5 and 6 they were mostly implimented using interactive X-monitors which are not available in MS Windows and so are removed in the new cross-platform code of GRASS 7.
** We need someone willing to port the old modules to work with GRASS 7, including writing new wxPython GUI frontends to a number of existing tools and updating the imagery libraries to current raster library standards.
** In addition, there are a number of improved/automated georectification tools which have not been merged into GRASS 5/6 which it would be nice to have updated and merged into the main code.

* implement [[OpenMP]] multithreading) as much as possible

See the [[Image_processing#Ideas_collection_for_improving_GRASS.27_Image_processing_capabilities|Ideas for imagery improvement]] and [[GRASS_7_ideas_collection#Imagery|GRASS 7 ideas]] wiki pages for more details.

== Guidelines for Students ==

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing [http://lists.osgeo.org/mailman/listinfo/grass-dev our dev-mailing list], or come and talk to us in [[IRC]] (#grass). You can also reach the mentors directly by emailing:
* Wolf Bergenheim (wolf+grass@bergenheim.net)

=== Getting started with GRASS coding ===

* The source code is maintained in a [http://trac.osgeo.org/grass/browser/grass/trunk SVN server] which is easy to browse
: Please review the SUBMITTING files there for our coding standards.

* There is lots of good info at the [http://trac.osgeo.org/grass/wiki GRASS Developer's wiki]
: See also the [[Development|development section]] of the GRASS user's wiki

== Accepted Ideas ==



[[Category:Development]]
[[Category:Community]]
[[Category:GSoC]]

Tips for Arc users

2007-11-21T06:02:48Z

⚠️Cmbarton: /* Raster import/export commands */

== Working with your ArcGIS data ==

'''Importing ArcGIS Data'''

Grass provides convertors for importing ESRI shapefiles, e00 files, and many other GIS formats as well. The key Grass programs for importing vector formats are [http://grass.itc.it/grass61/manuals/html61_user/v.in.ogr.html v.in.ogr] (for ESRI shapefiles, MapInfo files, SDTS, TIGER, etc.) and [http://grass.itc.it/grass61/manuals/html61_user/v.in.e00.html v.in.e00] for e00 format.

=== Vector import/export commands ===

* [http://grass.ibiblio.org/grass61/manuals/html61_user/v.in.ogr.html v.in.ogr] - Convert [http://www.gdal.org/ogr OGR] supported vector formats to GRASS vector format.

* [http://grass.ibiblio.org/grass61/manuals/html61_user/v.out.ogr.html v.out.ogr] - Convert from the GRASS vector format to one of the supported OGR vector formats.

* [http://grass.ibiblio.org/grass61/manuals/html61_user/v.in.e00.html v.in.e00] - Import a E00 coverage into a GRASS vector map.

==== Import of Shapefiles into Grass ====

specify the directory
v.in.ogr dsn=/home/data/navigation_files output=Tracklines layer=Ship_Tracklines

: or just the .shp file name directly
v.in.ogr dsn=Ship_Tracklines.shp output=Tracklines

This is the syntax for v.in.ogr in its most basic form. The ''dsn'' parameter corresponds to the directory path of the vector you are trying to import. You can enter a full or relative path. The ''output'' paramter, aptly enough, is the name of your output Grass vector. The ''layer'' parameter is the name of the input vector, be it shapefile, MapInfo file, or what have you.

==== Export of Shapefiles from GRASS ====

Export lines from GRASS vector map to Shapefile format (generates /tmp/testogr.shp and related files):

v.out.ogr input=multi type=line dsn=/tmp olayer=testogr

Export areas from GRASS vector map to Shapefile format (generates /tmp/testogr.shp and related files):

v.out.ogr input=multi type=area dsn=/tmp olayer=testogr

Export 3D lines from GRASS vector map to Shapefile format:

v.out.ogr input=lines_3d type=line dsn=/tmp olayer=testogr lco="SHPT=ARCZ"

=== Raster import/export commands ===

* [http://grass.ibiblio.org/grass61/manuals/html61_user/r.in.arc.html r.in.arc] - Convert an ESRI ARC/INFO ascii raster file (GRID) into a GRASS (binary) raster map layer.

* [http://grass.ibiblio.org/grass61/manuals/html61_user/r.out.arc.html r.out.arc] - Converts a GRASS raster map layer into an ESRI ARCGRID file.

* [http://grass.ibiblio.org/grass61/manuals/html61_user/r.in.gdal.html r.in.gdal] - Import [http://www.gdal.org GDAL] supported raster file into a binary raster map layer.
** Import a binary ArcInfo raster grid into GRASS:
r.in.gdal input=/path/to/map/hdr.adf output=map

* [http://grass.ibiblio.org/grass61/manuals/html61_user/r.out.gdal.html r.out.gdal] - Exports GRASS raster data into various formats.
** Export a raster as a GeoTIFF for use with ArcView 3.1:
r.out.gdal input=map output=map.tif type=Byte createopt="INTERLEAVE=PIXEL,COMPRESS=PACKBITS"

== See also ==
[[GRASS migration hints]]

[[Category:Documentation]]
[[Category:FAQ]]

Tips for Arc users

2007-11-21T05:59:53Z

⚠️Cmbarton: /* Raster import/export commands */

== Working with your ArcGIS data ==

'''Importing ArcGIS Data'''

Grass provides convertors for importing ESRI shapefiles, e00 files, and many other GIS formats as well. The key Grass programs for importing vector formats are [http://grass.itc.it/grass61/manuals/html61_user/v.in.ogr.html v.in.ogr] (for ESRI shapefiles, MapInfo files, SDTS, TIGER, etc.) and [http://grass.itc.it/grass61/manuals/html61_user/v.in.e00.html v.in.e00] for e00 format.

=== Vector import/export commands ===

* [http://grass.ibiblio.org/grass61/manuals/html61_user/v.in.ogr.html v.in.ogr] - Convert [http://www.gdal.org/ogr OGR] supported vector formats to GRASS vector format.

* [http://grass.ibiblio.org/grass61/manuals/html61_user/v.out.ogr.html v.out.ogr] - Convert from the GRASS vector format to one of the supported OGR vector formats.

* [http://grass.ibiblio.org/grass61/manuals/html61_user/v.in.e00.html v.in.e00] - Import a E00 coverage into a GRASS vector map.

==== Import of Shapefiles into Grass ====

specify the directory
v.in.ogr dsn=/home/data/navigation_files output=Tracklines layer=Ship_Tracklines

: or just the .shp file name directly
v.in.ogr dsn=Ship_Tracklines.shp output=Tracklines

This is the syntax for v.in.ogr in its most basic form. The ''dsn'' parameter corresponds to the directory path of the vector you are trying to import. You can enter a full or relative path. The ''output'' paramter, aptly enough, is the name of your output Grass vector. The ''layer'' parameter is the name of the input vector, be it shapefile, MapInfo file, or what have you.

==== Export of Shapefiles from GRASS ====

Export lines from GRASS vector map to Shapefile format (generates /tmp/testogr.shp and related files):

v.out.ogr input=multi type=line dsn=/tmp olayer=testogr

Export areas from GRASS vector map to Shapefile format (generates /tmp/testogr.shp and related files):

v.out.ogr input=multi type=area dsn=/tmp olayer=testogr

Export 3D lines from GRASS vector map to Shapefile format:

v.out.ogr input=lines_3d type=line dsn=/tmp olayer=testogr lco="SHPT=ARCZ"

=== Raster import/export commands ===

* [http://grass.ibiblio.org/grass61/manuals/html61_user/r.in.arc.html r.in.arc] - Convert an ESRI ARC/INFO ascii raster file (GRID) into a GRASS (binary) raster map layer.

* [http://grass.ibiblio.org/grass61/manuals/html61_user/r.out.arc.html r.out.arc] - Converts a GRASS raster map layer into an ESRI ARCGRID file.

* [http://grass.ibiblio.org/grass61/manuals/html61_user/r.in.gdal.html r.in.gdal] - Import [http://www.gdal.org GDAL] supported raster file into a binary raster map layer.
** Import a binary ArcInfo raster grid into GRASS:
r.in.gdal in=/path/to/map/hdr.adf out=map

* [http://grass.ibiblio.org/grass61/manuals/html61_user/r.out.gdal.html r.out.gdal] - Exports GRASS raster data into various formats.
** Export a raster as a GeoTIFF for use with ArcView 3.1:
r.out.gdal in=map out=map.tif type=Byte createopt="INTERLEAVE=PIXEL,COMPRESS=PACKBITS"

== See also ==
[[GRASS migration hints]]

[[Category:Documentation]]
[[Category:FAQ]]

GRASS 6.3 Feature Plan

2007-10-24T06:41:46Z

⚠️Cmbarton: /* Mostly done? */

== GRASS 6.3.x feature plan ==
=== About feature plan ===

To make GRASS releases more often and more predictable, here is GRASS next releases feature plan. This feature plan has to be filled by developers working on GRASS 6.3.

=== TODO GRASS 6.3.0 ===
There is the release branch for 6.3.x, see details at [http://grass.itc.it/devel/cvstags.php CVS: tags and branches]. A release branch is considered as "frozen", only bugfixes can be done.

==== RC1 ====

''released 24 Oct 2007''

* <strike>annoying winGRASS vector/DBMI freeze bug</strike> (Glynn Clements)
* <strike>replace r.proj with r.proj.seg</strike>
* <strike>d.text with d.text.new</strike>
* <strike>Windows start script's installed on Linux (grass63.bat etc.) [http://wald.intevation.org/tracker/?group_id=21&atid=204&func=detail&aid=323 #323] and [http://wald.intevation.org/tracker/?group_id=21&atid=204&func=detail&aid=471 #471]</strike> (Glynn Clements)
* <strike>Makefile cleanups for parallel builds [http://wald.intevation.org/tracker/?func=detail&aid=359&group_id=21&atid=204 #359]</strike> (Glynn Clements)
* <strike>r.info and Total Cell count overflow [http://wald.intevation.org/tracker/?func=detail&aid=493&group_id=21&atid=204 #493]</strike> (Glynn Clements, Brad Douglas)
* <strike>Makefile cleanups for MS-Windows</strike> (Glynn Clements)

==== RC2 ====

''not released yet''

===== Must do =====
* complete and stabilize the native [[WinGRASS Current Status|winGRASS port]] (seems to be in a good shape now)
* g.region vect=map -a issues [http://wald.intevation.org/tracker/index.php?func=detail&aid=489&group_id=21&atid=204 #489]
* r.out.gdal sets NoData wrong [http://wald.intevation.org/tracker/index.php?func=detail&aid=405&group_id=21&atid=204 #405]
* Update in Web-CVS: http://grass.itc.it/announces/announce_grass630.html

===== Mostly done? =====
* r.in.xyz improvements (see GForge patch)
* v.sample improvements (see GForge patch)
* v.what.vect improvements (see GForge patch)
* use GEM for ''GRASS Addons SVN'' - status unclear
**gis.m menu part of this done (Michael)

===== Wishlist =====

* modify Makefile system to support translated HTML pages. Store translated HTML files in centralized directory with locale specific subdirs, file name is module name.
* Implement [http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/doc/vector/TODO vector improvements] as suggested by Radim
* Integrate [https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/i.points.auto/#_trunk_grassaddons_i.points.auto_ i.points.auto] (merge into i.vpoints) - see also [[Image processing]] - note that A Scianna/Palermo has modernized version
* Make sqlite the default DB? <- needs more testing, for 6.5?
* drop d.m display manager (as now almost unmaintained; there is gis.m and/or a python based GUI)
: Some people still prefer it (see posts to grass-dev) and I will fix bugs in it, but not enhance/add new modules to it without good reason. So I don't see the need to drop it before the WxPython version is ready. It's not hurting us any keeping it. --Hamish
:: We should keep plain d.mon interface but why keep d.m, if gis.m has become really good? Probably we should clearly state, that d.m is UNMAINTAINED and OBSOLETE? [[User:MarisN|MarisN]] 08:24, 16 February 2007 (CET)
* raster maps: implement SQL based [[Time series in GRASS|time series support]] (Markus has working code from Soeren; done some improvements)
* Clean up Makefile system to support extension compilation and installation outside the GRASS installation and without the full GRASS source. Much like what GEM does, but without needing the module source setup and not limited to installing within the GRASS installation dir. This could also simplify GEM on the compilation side. See also general [[Extension development]].

*'''''Updates to vector querying'''''
*v.select (query using a vector map):
**add flags -p and -g for text output instead of creating a new map. It would report which map(s) and feature(s)/cat(s) meet the query criteria.
**allow multiple maps to be selected. This would directly address Eric's question. If the output is a map, it would be the equivalent of v.patch on all queried vector elements.
**add operators "contains" and "adjacent". Contains=all vector features whose nodes are completely inside a polygon (or inside or touching the boundary). Adjacent=all vector features who share a node/point or line/boundary with the selecting feature. Because GRASS is topologically correct, adjacency information is readily available.
**maybe change option names from ainput and binput to selector and selected or queried. This would have to wait until GRASS 7, of course. I find ainput and binput not very clear where used in other vector operations either (maybe I'm just dense).

*v.what (query using coordinates):
**add flags -p and -g for current behavior (-pg could be the default if we wanted to do this before GRASS 7)
**add "output=" option to allow v.what to create a new map from the results of its query, like v.select does
**allow multiple maps for input, as with the suggestion for v.select
**allow coordinates to be read optionally as a line or area boundary (-l or -a?) instead of only as individual points.
**add operators overlap, contains, adjacent.(This also would make possible interactive vector selection with a mouse drawn box or polygon from the GUI)

*In other words, have v.select and v.what work the same except that v.select uses a vector map for querying and v.what uses a set of coordinate points.

*v.overlay (boolean combination of maps):
**drop the ainput and binput. Replace with just input.
**allow multiple maps to be entered into input, not just 2
**deprecate v.patch because v.overlay with the OR operator replaces it. (If we wanted to do this before GRASS 7, we'd have to create a new module, maybe named v.combine or something like that because this changes the default behavior of v.overlay).

=== In progress ===
* native [[WinGRASS Current Status|MS Windows port]]
* Database connection for v.out.vtk: --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
** single column support for numerical data (int, float, double)
** GRASSRGB column support (done for ps.map)
** multiple column support for vector data
* rewrite most of the g3d modules to fulfill the grass function naming convention --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
* adding further (organized) keywords to every grass command and script [http://grass.itc.it/pipermail/grass-dev/2006-August/025164.html] and [http://grass.itc.it/pipermail/grass-dev/2006-August/025190.html]:
** display commands
** database commands
** general commands
** imagery commands
** misc commands
** paint commands
** photo commands
** postscript commands
** raster commands
** raster3D commands
** vector commands
* continue with [[WxPython-based GUI for GRASS]]
* <strike>write (Python based?) GUI wizard to create new locations</strike> (done by Jachym and Michael, see [[WxPython-based GUI for GRASS]])
** This is done. AFAICT it works really well (IIDSSM). It will create locations using EPSG, georeferenced files, custom selection of projection parameters, and xy locations. You can also set default extents (DEFAULT_WIND).
* improve Python-SWIG interface
* less verbose commands (work in progress)
* BLAS/LAPACK updates (Brad)

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS 6.3 Feature Plan

2007-10-24T06:40:47Z

⚠️Cmbarton: /* Wishlist */

== GRASS 6.3.x feature plan ==
=== About feature plan ===

To make GRASS releases more often and more predictable, here is GRASS next releases feature plan. This feature plan has to be filled by developers working on GRASS 6.3.

=== TODO GRASS 6.3.0 ===
There is the release branch for 6.3.x, see details at [http://grass.itc.it/devel/cvstags.php CVS: tags and branches]. A release branch is considered as "frozen", only bugfixes can be done.

==== RC1 ====

''released 24 Oct 2007''

* <strike>annoying winGRASS vector/DBMI freeze bug</strike> (Glynn Clements)
* <strike>replace r.proj with r.proj.seg</strike>
* <strike>d.text with d.text.new</strike>
* <strike>Windows start script's installed on Linux (grass63.bat etc.) [http://wald.intevation.org/tracker/?group_id=21&atid=204&func=detail&aid=323 #323] and [http://wald.intevation.org/tracker/?group_id=21&atid=204&func=detail&aid=471 #471]</strike> (Glynn Clements)
* <strike>Makefile cleanups for parallel builds [http://wald.intevation.org/tracker/?func=detail&aid=359&group_id=21&atid=204 #359]</strike> (Glynn Clements)
* <strike>r.info and Total Cell count overflow [http://wald.intevation.org/tracker/?func=detail&aid=493&group_id=21&atid=204 #493]</strike> (Glynn Clements, Brad Douglas)
* <strike>Makefile cleanups for MS-Windows</strike> (Glynn Clements)

==== RC2 ====

''not released yet''

===== Must do =====
* complete and stabilize the native [[WinGRASS Current Status|winGRASS port]] (seems to be in a good shape now)
* g.region vect=map -a issues [http://wald.intevation.org/tracker/index.php?func=detail&aid=489&group_id=21&atid=204 #489]
* r.out.gdal sets NoData wrong [http://wald.intevation.org/tracker/index.php?func=detail&aid=405&group_id=21&atid=204 #405]
* Update in Web-CVS: http://grass.itc.it/announces/announce_grass630.html

===== Mostly done? =====
* r.in.xyz improvements (see GForge patch)
* v.sample improvements (see GForge patch)
* v.what.vect improvements (see GForge patch)
* use GEM for ''GRASS Addons SVN'' - status unclear

===== Wishlist =====

* modify Makefile system to support translated HTML pages. Store translated HTML files in centralized directory with locale specific subdirs, file name is module name.
* Implement [http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/doc/vector/TODO vector improvements] as suggested by Radim
* Integrate [https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/i.points.auto/#_trunk_grassaddons_i.points.auto_ i.points.auto] (merge into i.vpoints) - see also [[Image processing]] - note that A Scianna/Palermo has modernized version
* Make sqlite the default DB? <- needs more testing, for 6.5?
* drop d.m display manager (as now almost unmaintained; there is gis.m and/or a python based GUI)
: Some people still prefer it (see posts to grass-dev) and I will fix bugs in it, but not enhance/add new modules to it without good reason. So I don't see the need to drop it before the WxPython version is ready. It's not hurting us any keeping it. --Hamish
:: We should keep plain d.mon interface but why keep d.m, if gis.m has become really good? Probably we should clearly state, that d.m is UNMAINTAINED and OBSOLETE? [[User:MarisN|MarisN]] 08:24, 16 February 2007 (CET)
* raster maps: implement SQL based [[Time series in GRASS|time series support]] (Markus has working code from Soeren; done some improvements)
* Clean up Makefile system to support extension compilation and installation outside the GRASS installation and without the full GRASS source. Much like what GEM does, but without needing the module source setup and not limited to installing within the GRASS installation dir. This could also simplify GEM on the compilation side. See also general [[Extension development]].

*'''''Updates to vector querying'''''
*v.select (query using a vector map):
**add flags -p and -g for text output instead of creating a new map. It would report which map(s) and feature(s)/cat(s) meet the query criteria.
**allow multiple maps to be selected. This would directly address Eric's question. If the output is a map, it would be the equivalent of v.patch on all queried vector elements.
**add operators "contains" and "adjacent". Contains=all vector features whose nodes are completely inside a polygon (or inside or touching the boundary). Adjacent=all vector features who share a node/point or line/boundary with the selecting feature. Because GRASS is topologically correct, adjacency information is readily available.
**maybe change option names from ainput and binput to selector and selected or queried. This would have to wait until GRASS 7, of course. I find ainput and binput not very clear where used in other vector operations either (maybe I'm just dense).

*v.what (query using coordinates):
**add flags -p and -g for current behavior (-pg could be the default if we wanted to do this before GRASS 7)
**add "output=" option to allow v.what to create a new map from the results of its query, like v.select does
**allow multiple maps for input, as with the suggestion for v.select
**allow coordinates to be read optionally as a line or area boundary (-l or -a?) instead of only as individual points.
**add operators overlap, contains, adjacent.(This also would make possible interactive vector selection with a mouse drawn box or polygon from the GUI)

*In other words, have v.select and v.what work the same except that v.select uses a vector map for querying and v.what uses a set of coordinate points.

*v.overlay (boolean combination of maps):
**drop the ainput and binput. Replace with just input.
**allow multiple maps to be entered into input, not just 2
**deprecate v.patch because v.overlay with the OR operator replaces it. (If we wanted to do this before GRASS 7, we'd have to create a new module, maybe named v.combine or something like that because this changes the default behavior of v.overlay).

=== In progress ===
* native [[WinGRASS Current Status|MS Windows port]]
* Database connection for v.out.vtk: --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
** single column support for numerical data (int, float, double)
** GRASSRGB column support (done for ps.map)
** multiple column support for vector data
* rewrite most of the g3d modules to fulfill the grass function naming convention --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
* adding further (organized) keywords to every grass command and script [http://grass.itc.it/pipermail/grass-dev/2006-August/025164.html] and [http://grass.itc.it/pipermail/grass-dev/2006-August/025190.html]:
** display commands
** database commands
** general commands
** imagery commands
** misc commands
** paint commands
** photo commands
** postscript commands
** raster commands
** raster3D commands
** vector commands
* continue with [[WxPython-based GUI for GRASS]]
* <strike>write (Python based?) GUI wizard to create new locations</strike> (done by Jachym and Michael, see [[WxPython-based GUI for GRASS]])
** This is done. AFAICT it works really well (IIDSSM). It will create locations using EPSG, georeferenced files, custom selection of projection parameters, and xy locations. You can also set default extents (DEFAULT_WIND).
* improve Python-SWIG interface
* less verbose commands (work in progress)
* BLAS/LAPACK updates (Brad)

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS 6.3 Feature Plan

2007-10-24T05:40:14Z

⚠️Cmbarton: /* In progress */

== GRASS 6.3.x feature plan ==
=== About feature plan ===

To make GRASS releases more often and more predictable, here is GRASS next releases feature plan. This feature plan has to be filled by developers working on GRASS 6.3.

=== TODO GRASS 6.3.0 ===
There is the release branch for 6.3.x, see details at [http://grass.itc.it/devel/cvstags.php CVS: tags and branches]. A release branch is considered as "frozen", only bugfixes can be done.

==== RC1 ====

''released 24 Oct 2007''

* <strike>annoying winGRASS vector/DBMI freeze bug</strike> (Glynn Clements)
* <strike>replace r.proj with r.proj.seg</strike>
* <strike>d.text with d.text.new</strike>
* <strike>Windows start script's installed on Linux (grass63.bat etc.) [http://wald.intevation.org/tracker/?group_id=21&atid=204&func=detail&aid=323 #323] and [http://wald.intevation.org/tracker/?group_id=21&atid=204&func=detail&aid=471 #471]</strike> (Glynn Clements)
* <strike>Makefile cleanups for parallel builds [http://wald.intevation.org/tracker/?func=detail&aid=359&group_id=21&atid=204 #359]</strike> (Glynn Clements)
* <strike>r.info and Total Cell count overflow [http://wald.intevation.org/tracker/?func=detail&aid=493&group_id=21&atid=204 #493]</strike> (Glynn Clements, Brad Douglas)
* <strike>Makefile cleanups for MS-Windows</strike> (Glynn Clements)

==== RC2 ====

''not released yet''

===== Must do =====
* complete and stabilize the native [[WinGRASS Current Status|winGRASS port]] (seems to be in a good shape now)
* g.region vect=map -a issues [http://wald.intevation.org/tracker/index.php?func=detail&aid=489&group_id=21&atid=204 #489]
* r.out.gdal sets NoData wrong [http://wald.intevation.org/tracker/index.php?func=detail&aid=405&group_id=21&atid=204 #405]
* Update in Web-CVS: http://grass.itc.it/announces/announce_grass630.html

===== Mostly done? =====
* r.in.xyz improvements (see GForge patch)
* v.sample improvements (see GForge patch)
* v.what.vect improvements (see GForge patch)
* use GEM for ''GRASS Addons SVN'' - status unclear

===== Wishlist =====

* modify Makefile system to support translated HTML pages. Store translated HTML files in centralized directory with locale specific subdirs, file name is module name.
* Implement [http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/doc/vector/TODO vector improvements] as suggested by Radim
* Integrate [https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/i.points.auto/#_trunk_grassaddons_i.points.auto_ i.points.auto] (merge into i.vpoints) - see also [[Image processing]] - note that A Scianna/Palermo has modernized version
* Make sqlite the default DB? <- needs more testing, for 6.5?
* drop d.m display manager (as now almost unmaintained; there is gis.m and/or a python based GUI)
: Some people still prefer it (see posts to grass-dev) and I will fix bugs in it, but not enhance/add new modules to it without good reason. So I don't see the need to drop it before the WxPython version is ready. It's not hurting us any keeping it. --Hamish
:: We should keep plain d.mon interface but why keep d.m, if gis.m has become really good? Probably we should clearly state, that d.m is UNMAINTAINED and OBSOLETE? [[User:MarisN|MarisN]] 08:24, 16 February 2007 (CET)
* raster maps: implement SQL based [[Time series in GRASS|time series support]] (Markus has working code from Soeren; done some improvements)
* Clean up Makefile system to support extension compilation and installation outside the GRASS installation and without the full GRASS source. Much like what GEM does, but without needing the module source setup and not limited to installing within the GRASS installation dir. This could also simplify GEM on the compilation side. See also general [[Extension development]].

=== In progress ===
* native [[WinGRASS Current Status|MS Windows port]]
* Database connection for v.out.vtk: --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
** single column support for numerical data (int, float, double)
** GRASSRGB column support (done for ps.map)
** multiple column support for vector data
* rewrite most of the g3d modules to fulfill the grass function naming convention --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
* adding further (organized) keywords to every grass command and script [http://grass.itc.it/pipermail/grass-dev/2006-August/025164.html] and [http://grass.itc.it/pipermail/grass-dev/2006-August/025190.html]:
** display commands
** database commands
** general commands
** imagery commands
** misc commands
** paint commands
** photo commands
** postscript commands
** raster commands
** raster3D commands
** vector commands
* continue with [[WxPython-based GUI for GRASS]]
* <strike>write (Python based?) GUI wizard to create new locations</strike> (done by Jachym and Michael, see [[WxPython-based GUI for GRASS]])
** This is done. AFAICT it works really well (IIDSSM). It will create locations using EPSG, georeferenced files, custom selection of projection parameters, and xy locations. You can also set default extents (DEFAULT_WIND).
* improve Python-SWIG interface
* less verbose commands (work in progress)
* BLAS/LAPACK updates (Brad)

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS 6.3 Feature Plan

2007-10-24T05:38:15Z

⚠️Cmbarton: /* In progress */

== GRASS 6.3.x feature plan ==
=== About feature plan ===

To make GRASS releases more often and more predictable, here is GRASS next releases feature plan. This feature plan has to be filled by developers working on GRASS 6.3.

=== TODO GRASS 6.3.0 ===
There is the release branch for 6.3.x, see details at [http://grass.itc.it/devel/cvstags.php CVS: tags and branches]. A release branch is considered as "frozen", only bugfixes can be done.

==== RC1 ====

''released 24 Oct 2007''

* <strike>annoying winGRASS vector/DBMI freeze bug</strike> (Glynn Clements)
* <strike>replace r.proj with r.proj.seg</strike>
* <strike>d.text with d.text.new</strike>
* <strike>Windows start script's installed on Linux (grass63.bat etc.) [http://wald.intevation.org/tracker/?group_id=21&atid=204&func=detail&aid=323 #323] and [http://wald.intevation.org/tracker/?group_id=21&atid=204&func=detail&aid=471 #471]</strike> (Glynn Clements)
* <strike>Makefile cleanups for parallel builds [http://wald.intevation.org/tracker/?func=detail&aid=359&group_id=21&atid=204 #359]</strike> (Glynn Clements)
* <strike>r.info and Total Cell count overflow [http://wald.intevation.org/tracker/?func=detail&aid=493&group_id=21&atid=204 #493]</strike> (Glynn Clements, Brad Douglas)
* <strike>Makefile cleanups for MS-Windows</strike> (Glynn Clements)

==== RC2 ====

''not released yet''

===== Must do =====
* complete and stabilize the native [[WinGRASS Current Status|winGRASS port]] (seems to be in a good shape now)
* g.region vect=map -a issues [http://wald.intevation.org/tracker/index.php?func=detail&aid=489&group_id=21&atid=204 #489]
* r.out.gdal sets NoData wrong [http://wald.intevation.org/tracker/index.php?func=detail&aid=405&group_id=21&atid=204 #405]
* Update in Web-CVS: http://grass.itc.it/announces/announce_grass630.html

===== Mostly done? =====
* r.in.xyz improvements (see GForge patch)
* v.sample improvements (see GForge patch)
* v.what.vect improvements (see GForge patch)
* use GEM for ''GRASS Addons SVN'' - status unclear

===== Wishlist =====

* modify Makefile system to support translated HTML pages. Store translated HTML files in centralized directory with locale specific subdirs, file name is module name.
* Implement [http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass6/doc/vector/TODO vector improvements] as suggested by Radim
* Integrate [https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/i.points.auto/#_trunk_grassaddons_i.points.auto_ i.points.auto] (merge into i.vpoints) - see also [[Image processing]] - note that A Scianna/Palermo has modernized version
* Make sqlite the default DB? <- needs more testing, for 6.5?
* drop d.m display manager (as now almost unmaintained; there is gis.m and/or a python based GUI)
: Some people still prefer it (see posts to grass-dev) and I will fix bugs in it, but not enhance/add new modules to it without good reason. So I don't see the need to drop it before the WxPython version is ready. It's not hurting us any keeping it. --Hamish
:: We should keep plain d.mon interface but why keep d.m, if gis.m has become really good? Probably we should clearly state, that d.m is UNMAINTAINED and OBSOLETE? [[User:MarisN|MarisN]] 08:24, 16 February 2007 (CET)
* raster maps: implement SQL based [[Time series in GRASS|time series support]] (Markus has working code from Soeren; done some improvements)
* Clean up Makefile system to support extension compilation and installation outside the GRASS installation and without the full GRASS source. Much like what GEM does, but without needing the module source setup and not limited to installing within the GRASS installation dir. This could also simplify GEM on the compilation side. See also general [[Extension development]].

=== In progress ===
* native [[WinGRASS Current Status|MS Windows port]]
* Database connection for v.out.vtk: --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
** single column support for numerical data (int, float, double)
** GRASSRGB column support (done for ps.map)
** multiple column support for vector data
* rewrite most of the g3d modules to fulfill the grass function naming convention --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
* adding further (organized) keywords to every grass command and script [http://grass.itc.it/pipermail/grass-dev/2006-August/025164.html] and [http://grass.itc.it/pipermail/grass-dev/2006-August/025190.html]:
** display commands
** database commands
** general commands
** imagery commands
** misc commands
** paint commands
** photo commands
** postscript commands
** raster commands
** raster3D commands
** vector commands
* continue with [[WxPython-based GUI for GRASS]]
* write (Python based?) GUI wizard to create new locations (done by Jachym, see [[WxPython-based GUI for GRASS]])
** This is done. AFAICT it works really well (IIDSSM). It will create locations using EPSG, georeferenced files, custom selection of projection parameters, and xy locations. You can also set default extents (DEFAULT_WIND).
* improve Python-SWIG interface
* less verbose commands (work in progress)
* BLAS/LAPACK updates (Brad)

[[Category:Development]]
[[Category:Release Roadmap]]

GRASS and Python

2007-06-10T20:52:33Z

⚠️Cmbarton: /* Writing python scripts in GRASS */

''(for discussions on the new GRASS GUI, see [[GRASS GUI|here]])''

==Python SIGs==
Python Special Interest Groups are focused collaborative efforts to develop, improve, or maintain specific Python resources. Each SIG has a charter, a coordinator, a mailing list, and a directory on the Python website. SIG membership is informal, defined by subscription to the SIG's mailing list. Anyone can join a SIG, and participate in the development discussions via the SIG's mailing list. Below is the list of currently active Python SIGs, with links to their resources.

See more at http://www.python.org/community/sigs/

==Writing python scripts in GRASS==
Python is between shell and C programs. For C part - it can handle GRASS C functions via SWIG. For shell part, it can be processed with g.parser, so automatic input check and help generation (apart from translation) can be processed.

Example of python script, which is processed by g.parser:
#!/usr/bin/python

import sys
import os

#%Module
#% description: g.parser test script
#% keywords: keyword1, keyword2
#%End
#%flag
#% key: f
#% description: a flag
#%END
#%option
#% key: raster
#% type: string
#% gisprompt: old,cell,raster
#% description: raster input map
#% required : yes
#%end
#%option
#% key: vector
#% type: string
#% gisprompt: old,vector,vector
#% description: vector input map
#% required : yes
#%end
#%option
#% key: option1
#% type: string
#% description: an option
#% required : yes
#%end

def main():

#add your code here
print ""

if ( os.getenv("GIS_FLAG_f") != "0" ):
print "Flag -f set"
else:
print "Flag -f not set"

print "Value of GIS_OPT_option1: %s" % os.getenv("GIS_OPT_option1")
print "Value of GIS_OPT_raster: %s" % os.getenv("GIS_OPT_raster")
print "Value of GIS_OPT_vect: %s" % os.getenv("GIS_OPT_vect")

#end of your code
return

if __name__ == "__main__":
if ( len(sys.argv) <= 1 or sys.argv[1] != "@ARGS_PARSED@" ):
os.execvp("g.parser", [sys.argv[0]] + sys.argv)
else:
main();

=== SUBMITTING_PYTHON proposal ===

<pre>
NOTE: Please improve this list!

Dear (new) GRASS Developer,

When submitting PYTHON SCRIPTS to GRASS SVN repository,
please take care of following rules:

[ see SUBMITTING for C code hints ]
[ see SUBMITTING_SCRIPTS for shell script hints ]
[ see SUBMITTING_TCLTK for TCL/TK script hints ]

1. Indentation

As Python determines nesting based upon indentation, it
isn't just a stylistic issue.

Please use 4-space indentation (GNU Emacs python-mode default).

2. Add a header section to the script you submit and make sure you
include the copyright. The purpose section is meant to contain a
general over view of the code in the file to assist other programmers
that will need to make changes to your code. For this purpose use
Python Docstring.

Example (fictitious header for a script called r.myscript):

"""
MODULE: r.myscript

AUTHOR(S): Me <email AT some domain>

PURPOSE: Calculates univariate statistics from a GRASS raster map

COPYRIGHT: (C) 2007 by the GRASS Development Team

This program is free software under the GNU General Public
License (>=v2). Read the file COPYING that comes with GRASS
for details.
"""

The copyright protects your rights according to GNU General Public
License (www.gnu.org).

...
[please add further hints if required]
</pre>

==Python extensions for GRASS GIS==
=== wxPython GUI development for GRASS ===

* See the [[GRASS GUI]] wiki page

===Python-SWIG-GRASS interface===
There is a prototype GRASS-SWIG interface available (thanks to Sajith VK), find it in GRASS 6-CVS: '''swig/python/'''. Draft documentation is [http://mpa.itc.it/markus/grass63progman/swig/ here]. It now wraps both raster and vector data C functions plus the general GIS (G_*()) functions.

Background: [http://www.swig.org SWIG] (Simplified Wrapper and Interface Generator) is:

* A compiler that turns ANSI C/C++ declarations into scripting language interfaces.
* Completely automated (produces a fully working Python extension module).
* Language neutral. SWIG can also target Tcl, Perl, Guile, MATLAB, etc...
* Attempts to eliminate the tedium of writing extension modules.

Sample script for raster access (use within GRASS, Spearfish session):
#!/usr/bin/python
import python_grass6 as g6lib

input = 'roads'
mapset = 'PERMANENT'

# initialize
g6lib.G_gisinit('')
infd = g6lib.G_open_cell_old(input, mapset)
cell = g6lib.G_allocate_cell_buf()

rown=0
# the API still needs error checking to be added
while 1:
myrow = g6lib.G_get_map_row_nomask(infd, cell, rown)
print rown,myrow[0:10]
rown = rown+1
if rown==476:break

g6lib.G_close_cell(infd)
g6lib.G_free(cell)

Sample script for vector access (use within GRASS, Spearfish session):
#!/usr/bin/python
import python_grass6 as g6lib

input = 'soils'
mapset = 'PERMANENT'

# initialize
g6lib.G_gisinit('')

# define map structure
map = g6lib.Map_info()

# define open level (level 2: topology)
g6lib.Vect_set_open_level (2)

# open existing map
g6lib.Vect_open_old(map, input, mapset)

# query
print 'Vect is 3D: ', g6lib.Vect_is_3d (map)
print 'Vect DB links: ', g6lib.Vect_get_num_dblinks(map)
print 'Map Scale: 1:', g6lib.Vect_get_scale(map)

# close map
g6lib.Vect_close(map)

'''TODO''': Implement modules support in a Python class using --interface-description and a Python-XML parser. This should be a generic class with module's name as parameter, returning back an object which describes the module (description, flags, parameters, status of not/required). See [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/gui/wxpython/ GRASS 6 wxPython interface] for inspiration. Important is to auto-generate the GRASS-Python class at compile time with a Python script.

=== Python-GRASS add-ons ===

Stand-alone addons:

# Jáchym Čepický's G-ps.map, a GUI to typeset printable maps with ps.map (http://193.84.38.2/~jachym/index.py?cat=gpsmap)
# Jáchym Čepický's v.pydigit, a GUI to v.edit (http://les-ejk.cz/?cat=vpydigit)
# Jáchym Čepický's PyWPS, GRASS-Web Processing Service (http://pywps.wald.intevation.org)

=== Using Grass gui.tcl in python ===

Here is some example code to use the grass automatically generated guis in python code. This could (should) all be bundled up and abstracted away so that the implementation can be replaced later.

import Tkinter
import os

# Startup (once):

tk = Tkinter.Tk()
tk.eval ("wm withdraw .")
tk.eval ("source $env(GISBASE)/etc/gui.tcl")
# Here you could do various things to change what the gui does
# See gui.tcl and README.GUI

# Make a gui (per dialog)
# This sets up a window for the command.
# This can be different to integrate with tkinter:
tk.eval ('set path ".dialog$dlg"')
tk.eval ('toplevel .dialog$dlg')
# Load the code for this command:
fd = os.popen ("d.vect --tcltk")
gui = fd.read()
# Run it
tk.eval(gui)
dlg = tk.eval('set dlg') # This is used later to get and set

# Get the current command in the gui we just made:
currentcommand = tk.eval ("dialog_get_command " + dlg)

# Set the command in the dialog we just made:
tk.eval ("dialog_set_command " + dlg + " {d.vect map=roads}")

== Links ==

=== Programming ===

* [http://www.poromenos.org/tutorials/python Quick Python tutorial] for programmers of other languages
: [http://wiki.python.org/moin/BeginnersGuide/Programmers More Python tutorials] for programmers
* [http://www.python.org/dev/peps/pep-0008/ Python programming style guide]
* GRASS-SWIG interface http://mpa.itc.it/markus/grass63progman/swig/
* SWIG http://www.swig.org/
* SIP (C/C++ bindings generator) http://directory.fsf.org/all/Python-SIP.html
* Python and GDAL/OGR:
** [http://mapserver.gis.umn.edu/community/conferences/MUM3/workshop/python Open Source Python GIS Hacks Mum'03]
** http://hobu.biz/software/OSGIS_Hacks - Python OSGIS Hacks '05
** http://zcologia.com/news/categorylist_html?cat_id=8
** http://www.perrygeo.net/wordpress/?p=4
* Python bindings to PROJ:
** http://www.cdc.noaa.gov/people/jeffrey.s.whitaker/python/pyproj.html
* Other external projects
** Scientific Python: http://www.scipy.org/

=== Presentations ===

From FOSS4G2006:
* [http://www.foss4g2006.org/materialDisplay.py?contribId=136&sessionId=48&materialId=slides&confId=1 A Python sweeps in the GRASS] - A. Frigeri 2006
* [http://www.foss4g2006.org/materialDisplay.py?contribId=67&sessionId=48&materialId=slides&confId=1 GRASS goes web: PyWPS] - J. Cepicky 2006

[[Category:Development]]
[[Category:Linking to other languages]]

GRASS and Python

2006-08-14T16:02:42Z

⚠️Cmbarton: /* wxPython GUI development for GRASS */

==Python SIGs==
Python Special Interest Groups are focused collaborative efforts to develop, improve, or maintain specific Python resources. Each SIG has a charter, a coordinator, a mailing list, and a directory on the Python website. SIG membership is informal, defined by subscription to the SIG's mailing list. Anyone can join a SIG, and participate in the development discussions via the SIG's mailing list. Below is the list of currently active Python SIGs, with links to their resources.

See more at http://www.python.org/community/sigs/

==Python extensions for GRASS GIS==
=== wxPython GUI development for GRASS ===
'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 18:02, 14 August 2006 (CEST) '''New version implements double buffered drawing to fix display issues on Debian, including flickering why panning and display being erased by overlaying windows. Output to PNG file added. Better looking zoom rectangles.

'''*****The wxPython code is moving to the GRASS CVS. You should look for the newest versions there. Volunteers to help with the new GUI are welcomed!*****''' [[User:Cmbarton|Cmbarton]]

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

===Python-SWIG-GRASS interface===
There is a prototype GRASS-SWIG interface available (thanks to Sajith VK), find it in GRASS 6-CVS: swig/python/

Background: [http://www.swig.org SWIG] (Simplified Wrapper and Interface Generator) is:

* A compiler that turns ANSI C/C++ declarations into scripting language interfaces.
* Completely automated (produces a fully working Python extension module).
* Language neutral. SWIG can also target Tcl, Perl, Guile, MATLAB, etc...
* Attempts to eliminate the tedium of writing extension modules.

'''TODO''': Implement modules support in a Python class using --interface-description and a Python-XML parser. This should be a generic class with module's name as parameter, returning back an object which describes the module (description, flags, parameters, status of not/required). See [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/gui/wxpython/ GRASS 6 wxPython interface] for inspiration. Important is to auto-generate the GRASS-Python class at compile time with a Python script.

=== Python-GRASS add-ons ===

Stand-alone addons:

# Jáchym Čepický's G-ps.map, a GUI to typeset printable maps with ps.map (http://les-ejk.cz/?cat=gpsmap)
# Jáchym Čepický's v.pydigit, a GUI to v.edit (http://les-ejk.cz/?cat=vpydigit)
# Jáchym Čepický's PyWPS, GRASS-Web Processing Service (http://les-ejk.cz/?cat=pywps)

=== Using Grass gui.tcl in python ===

Here is some example code to use the grass automatically generated guis in python code. This could (should) all be bundled up and abstracted away so that the implementation can be replaced later.

import Tkinter
import os

# Startup (once):

tk = Tkinter.Tk()
tk.eval ("wm withdraw .")
tk.eval ("source $env(GISBASE)/etc/gui.tcl")
# Here you could do various things to change what the gui does
# See gui.tcl and README.GUI

# Make a gui (per dialog)
# This sets up a window for the command.
# This can be different to integrate with tkinter:
tk.eval ('set path ".dialog$dlg"')
tk.eval ('toplevel .dialog$dlg')
# Load the code for this command:
fd = os.popen ("d.vect --tcltk")
gui = fd.read()
# Run it
tk.eval(gui)
dlg = tk.eval('set dlg') # This is used later to get and set

# Get the current command in the gui we just made:
currentcommand = tk.eval ("dialog_get_command " + dlg)

# Set the command in the dialog we just made:
tk.eval ("dialog_set_command " + dlg + " {d.vect map=roads}")

== Links ==

* GRASS-SWIG interface http://mpa.itc.it/markus/grass61progman/swig/
* SWIG http://www.swig.org/
* SIP (C/C++ bindings generator) http://directory.fsf.org/all/Python-SIP.html
* Python and GDAL/OGR:
** [http://mapserver.gis.umn.edu/community/conferences/MUM3/workshop/python Open Source Python GIS Hacks Mum'03]
** http://hobu.biz/software/OSGIS_Hacks - Python OSGIS Hacks '05
** http://zcologia.com/news/categorylist_html?cat_id=8
** http://www.perrygeo.net/wordpress/?p=4
* Python bindings to PROJ:
** http://www.cdc.noaa.gov/people/jeffrey.s.whitaker/python/pyproj.html
* Other external projects
** Scientific Python: http://www.scipy.org/

[[Category:Development]]
[[Category:Linking to other languages]]

GRASS and Python

2006-08-08T22:50:34Z

⚠️Cmbarton: /* wxPython GUI development for GRASS */

==Python extensions for GRASS GIS==

=== wxPython GUI development for GRASS ===
'''[http://www.public.asu.edu/~cmbarton/files/grass_wxpython/ Link to wxPython prototype GUI for GRASS 6]'''

'''Update 00:50, 9 August 2006 (CEST) '''New version will run directly from GRASS prompt with new startup script. Now put gism.py and associated files into $GISBASE/etc/gmwxp and add a new script (gm.wxp) to the $GISBASE/scripts folder. Then simply type gm.wxp& from the GRASS command prompt to get the new prototype wxPython GUI for GRASS. See instructions in today's package update. [[User:Cmbarton|Cmbarton]]

'''Update 23:59, 7 August 2006 (CEST) '''New version with nearly complete raster menu by Yann Chemin. [[User:Cmbarton|Cmbarton]]

'''Update 19:02, 7 August 2006 (CEST)'''I just uploaded a new version of gism.py and related files. I'll keep an archive and so am changing the link to go to the folder rather than the file itself so I won't have to keep changing the link. This update includes the following changes:
*The biggest change in wrapping in grassgui.py. This provides autogenerated wxPython GUI dialogs for all grass commands.
This can now be called from the command console (just type in the command name with no arguments as you do now) or the
prototype menus. I updated grassgui.py to current wxPython syntax (mostly) and added methods to make it callable from
other modules.
*Methods added to gism.py and grassgui.py that automatically restart them with pythonw for the Mac
--[[User:Cmbarton|Cmbarton]] 19:02, 7 August 2006 (CEST)

Initial development has begun on the next generation UI for GRASS. wxPython is the leading contender for a platform in which to continue development of the GRASS GUI. wxPython is a Python implementation of the well known wxWidgets (formerly wxWindows) interface development platform for C++. An initial demonstration was developed by Jachym Cepicky to show the possibility of controling GRASS via wxPython. A second generation prototype has been completed, building on Jachym's work. It is available for testing and further development at link above.
--[[User:Cmbarton|Cmbarton]] 07:15, 4 August 2006 (CEST)

===Python-SWIG-GRASS interface===
There is a prototype GRASS-SWIG interface available (thanks to Sajith VK), find it in GRASS 6-CVS: swig/python/

Background: [http://www.swig.org SWIG] (Simplified Wrapper and Interface Generator) is:

* A compiler that turns ANSI C/C++ declarations into scripting language interfaces.
* Completely automated (produces a fully working Python extension module).
* Language neutral. SWIG can also target Tcl, Perl, Guile, MATLAB, etc...
* Attempts to eliminate the tedium of writing extension modules.

'''TODO''': Implement modules support in a Python class using --interface-description and a Python-XML parser. This should be a generic class with module's name as parameter, returning back an object which describes the module (description, flags, parameters, status of not/required). See [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/gui/wxpython/ GRASS 6 wxPython interface] for inspiration. Important is to auto-generate the GRASS-Python class at compile time with a Python script.

=== Python-GRASS add-ons ===

Stand-alone addons:

# Jáchym Čepický's G-ps.map, a GUI to typeset printable maps with ps.map (http://les-ejk.cz/?cat=gpsmap)
# Jáchym Čepický's v.pydigit, a GUI to v.edit (http://les-ejk.cz/?cat=vpydigit)
# Jáchym Čepický's PyWPS, GRASS-Web Processing Service (http://les-ejk.cz/?cat=pywps)

=== Using Grass gui.tcl in python ===

Here is some example code to use the grass automatically generated guis in python code. This could (should) all be bundled up and abstracted away so that the implementation can be replaced later.

import Tkinter
import os

# Startup (once):

tk = Tkinter.Tk()
tk.eval ("wm withdraw .")
tk.eval ("source $env(GISBASE)/etc/gui.tcl")
# Here you could do various things to change what the gui does
# See gui.tcl and README.GUI

# Make a gui (per dialog)
# This sets up a window for the command.
# This can be different to integrate with tkinter:
tk.eval ('set path ".dialog$dlg"')
tk.eval ('toplevel .dialog$dlg')
# Load the code for this command:
fd = os.popen ("d.vect --tcltk")
gui = fd.read()
# Run it
tk.eval(gui)
dlg = tk.eval('set dlg') # This is used later to get and set

# Get the current command in the gui we just made:
currentcommand = tk.eval ("dialog_get_command " + dlg)

# Set the command in the dialog we just made:
tk.eval ("dialog_set_command " + dlg + " {d.vect map=roads}")

== Links ==

* GRASS-SWIG interface http://mpa.itc.it/markus/grass61progman/swig/
* SWIG http://www.swig.org/
* SIP (C/C++ bindings generator) http://directory.fsf.org/all/Python-SIP.html
* Python and GDAL/OGR:
** [http://mapserver.gis.umn.edu/community/conferences/MUM3/workshop/python Open Source Python GIS Hacks Mum'03]
** http://hobu.biz/software/OSGIS_Hacks - Python OSGIS Hacks '05
** http://zcologia.com/news/categorylist_html?cat_id=8
** http://www.perrygeo.net/wordpress/?p=4
* Python bindings to PROJ:
** http://www.cdc.noaa.gov/people/jeffrey.s.whitaker/python/pyproj.html
* Other external projects
** Scientific Python: http://www.scipy.org/

[[Category:Development]]
[[Category:Linking to other languages]]