GRASS-Wiki - User contributions [en]

Talk:GRASS Community Meeting Prague 2023

2023-06-05T15:19:35Z

⚠️Micha: /* Micha Silver */

__TOC__

== Tasks for participants ==

* Create section for you in the Reports section.
* List all the things you are working on in the section. Update the list each day. Include things you work on with other people.
* Link the [https://github.com/orgs/OSGeo/projects/1/ GRASS Community Meeting Prague 2023] project on GitHub to each PR or issue you are working on or plan to be working on.
* If you are or will be working on an issue or on a PR which is not originally submitted by you, assign yourself to the issue or PR. (You can unassign yourself later if you change your mind.)

== Planning and organizing ==

* Initial planning: Veronica Andreo, Martin Landa, Vaclav Petras, Helmut Kudrnovsky, Anna Petrasova, Huidae Cho, Markus Neteler, Helena Mitasova, Micha Silver, Linda Kladivova
* Funding acquisition: Veronica Andreo, Markus Neteler, Vaclav Petras, Anna Petrasova, Huidae Cho, Luca Delucchi, Venkatesh Raghavan
* Budget: Vaclav Petras, Markus Neteler, Veronica Andreo
* Venue and local organizing: Martin Landa
* T-shirts, hoodies, stickers: Vaclav Petras, Anna Petrasova
* Promotion, invitations, and social media: Caitlin Haedrich, Veronica Andreo, Vaclav Petras
* Wiki page: Martin Landa, Markus Neteler, Vaclav Petras, Veronica Andreo
* Virtual meeting organizing: Veronica Andreo
* Photography: Caitlin Haedrich

== Ideas for the meeting agenda ==

Collect ideas here :-)

=== Markus Neteler ===

* Improve QGIS-GRASS GIS integration; update of provider to GRASS GIS 8
* GRASS GIS addons overview generator for entire GitHub (and more?) based on tag "[https://github.com/topics/grass-gis-addons grass-gis-addons]"
* Discuss about a 4th edition of "Open Source GIS: A GRASS GIS Approach"
* message translation: Easy [https://docs.weblate.org/en/latest/user/translating.html#machine-translation machine translation] of messages in [https://weblate.osgeo.org/translate/grass-gis OSGeo-Weblate] with DeepL API
** my tests with DeepL show that the quality is very good; average translation time of a user message shrinks to 15 seconds {{done}}
** note: one needs to login to Weblate to see the "Automatic suggestion" button (using the OSGeo-ID)
* Fix docs:
** Provide better explanation for radius parameter for r.resamp.filter: https://github.com/OSGeo/grass/issues/2569
** improve v.clean docs

=== Vero ===

* '''All - think about GRASS GIS mission and vision''': Where do we want to be as a project in 5 years time? What do we want to have? What do we want to be?
* Participate in discussions about GRASS interfaces with QGIS and R (rgrass)
* Discuss sponsoring
* Student grant for (python) documentation?
* Discuss about wiki clean-up/update (Anna was working on a list of pages)
* Website enhancements: complete open PR's, meet Daniel Torres, new support item in main menu
* Discuss State of GRASS presentation for FOSS4G 2023
* i.landsat if time permits
* ...

=== You ===

== Reports ==

=== Caitlin Haedrich ===
* Photos, social media and wiki page
* grass.jupyter:
** [https://github.com/OSGeo/grass/pull/2996 add feature for animating series of rasters]

=== Vaclav Petras ===

* Rename location to project
** [https://github.com/OSGeo/grass/pull/2993 wxGUI: Rename location to project #2993]
** Discussion
* Python API
** [https://github.com/OSGeo/grass/pull/2923 grass.experimental: Add object to access modules as functions #2923]
* CI
** [https://github.com/OSGeo/grass/pull/3002 CI: Switch Travis to Ubuntu 22.04 (jammmy) #3002]
* Reviews and merges:
** [https://github.com/OSGeo/grass/pull/2974 t.rast.algebra/testsuite: split file test_raster_algebra.py #2974]
** [https://github.com/OSGeo/grass/pull/2189 Imagery: add libsvm based imagery classification #2189]
** [https://github.com/OSGeo/grass-addons/pull/606 r.random.walk: Add module to create random walks #606]

=== Anna Petrasova ===
* [https://github.com/OSGeo/grass/pull/2992 Fix bug in querying]
* review, merge and backport of [https://github.com/OSGeo/grass/pull/2994 fix in datacatalog]
* review of [https://github.com/OSGeo/grass/pull/2520 wxGUI: fix show MASK statusbar button widget if mask is created]
* merge of [https://github.com/OSGeo/grass/pull/2667 wxGUI: adding a button for undocking an AuiNotebook tab to wx.Frame (Single-Window GUI)]
* edit [https://github.com/OSGeo/grass/pull/2990 check min required wx version when starting wxgui]

=== Maris Nartiss ===

* i.svm.* cleanup and preparation for a review
* A conceptual proposal for a new start up screen
* Initial version of imagery signature management module i.signatures
* Remove obsolete parts of locale README file

=== Micha Silver ===
Working on a new GRASS addon: r.optram
[https://github.com/micha-silver/grass-addons/tree/grass8/src/raster/r.optram the repo on github]

02/06: Initialize main file ''r.optram.py''

includes these functions:
# ''getImgList()'' - get list of IMG_FILEs in a Sentinel 2 SAFE Directory
# ''cropToAOI()'' - Crop the images to the Area of Interest
# ''prepareSTR()'' - Convert SWIR to the SWIR Transformed Reflectance
# ''prepareVI()'' - Prepare the (user chosen) vegetation index

03/06:
# Split to three modules: '''r.optram.preprocess, r.optram, r.optram.soilmoisture'''
# new function: ''prepareTrapezoid()'' - to get wet-dry regression lines and slope, intercept values

04/06
# ''prepareTrapezoid()'' function completed.
# (Joined video conf with Roger Bivand on R-GRASS integration.)

05/06
Initialize third file/function: ''r.optram.soilmoisture.py''
# ''createSoilMoisture()'' - creates new GRASS raster for a single date
# Add documentation to modules
# (joined video conf with Nyall Dawson)

TODO list:
* Read Sentinel cloud mask and mask out cloud pixels in '''r.optram.preprocess'''
* large study areas or very long time series will create a big numpy table of variables (vegetation index and STR). A possible solution:
# Determine some "reasonable" maximum size for the numpy table, depending on computer resources.
# Extract a subset of pixels from each raster in the time series, such that the total table pixel values will not exceed that maximum
# The size of the subset will be set by ("reasonable" max / number of rasters in time series)
# Allow user to determine "reasonable" max.
* Currently this addon consists of three sub-modules. Consider to consolidate to one.
* Improve HTML documentation

=== Luís de Sousa ===

==== Work on GRASS add-on [https://grass.osgeo.org/grass82/manuals/addons/r.mblend.html r.mblend] ====

* Module is still maintained and fully functional in GRASS 8.2 (now included in the [https://github.com/OSGeo/grass-addons GRASS global add-ons repository])
* However was not longer producing correct results due to new behaviour in '''v.what.rast'''
* Solution identified, using inner buffer to interpolation area ([https://github.com/OSGeo/grass-addons/pull/910 PR #910])
* A small unit test suite was developed ([https://github.com/OSGeo/grass-addons/pull/911 PR #911])

==== Documentation ====

* Expanded instructions on Pre-commit ([https://github.com/OSGeo/grass/pull/3006 PR #3006])
* Mini guidelines on unit tests for add-ons ([https://github.com/OSGeo/grass-addons/pull/916 PR #916])

=== Aaron Saw Min Sern ===

* Fix bug to complete r.univar parallelization. [https://github.com/OSGeo/grass/pull/2683 PR]

=== Martin Landa ===

* Check min required wx version when starting wxgui [https://github.com/OSGeo/grass/pull/2990 PR #2990]
* Graphical modeler: avoid overlapping module parameters [https://github.com/OSGeo/grass/issues/2991 PR #2991]
* Show ModelRelation in white on dark mode [https://github.com/OSGeo/grass/pull/2997 PR #2997]
* Add OSGeo4W workflow to compile Addons [https://github.com/OSGeo/grass-addons/pull/912 PR #912]
* Integrate Grapical Modeler into single window layout [https://github.com/OSGeo/grass/pull/3003 PR #3003]
* Graphical Modeler: fix command parsing in "add tool" dialog [https://github.com/OSGeo/grass/pull/3022 PR #3022]

=== Markus Neteler ===

* backport of "HTML header charset changed from ISO-8859-1 to UTF-8" [https://github.com/OSGeo/grass/pull/2547 PR #2547] to GRASS GIS 8.2.1 (fixing r.forcircular manual encoding bug)
* improve "Update alpine Docker tag to v3.18 [https://github.com/OSGeo/grass/pull/2953 PR #2953]
* backport of Alpine Dockerfile improvements
* discussion about "location/mapset" vs "project/..." terminology
* initial QGIS-GRASS update discussion
* Google Photo album feeds
* Use of [https://github.com/OSGeo/grass/blob/main/doc/development/submitting/submitting.md#use-pre-commit pre-commit] (recommended to all devs!)
* Participate in a two-hour meeting with Nyall Dawson (QGIS) and the GRASS Community about interfacing GRASS from QGIS
* GRASS GIS manual pages: re-styling and conversion of all pages to markdown:
** convert to markdown with pandoc (draft script see https://app.gitter.im/#/room/#grassgis_sprint:gitter.im discussion)
** using mkdocs (https://www.mkdocs.org/): it provides menus and a search window
** check: automatic formatting for mkdocs: https://github.com/KyleKing/mdformat-mkdocs

=== Helmut Kudrnovsky ===

* discuss (win)GRASS-R issues [https://github.com/rsbivand/rgrass/issues/57 initGrass Error] and [https://github.com/OSGeo/grass/issues/2998 feature requests]

* Review and initial tests of PR [https://github.com/OSGeo/grass/pull/2684 compilation with cmake] on Windows

* Participated in a two-hour meeting with Roger, Floris, Vaclav, Anna, Micha, ..... about rgrass development

=== Ondřej Pešek ===

* gmodeler: add export to an actinia script: [https://github.com/OSGeo/grass/pull/3005 PR #3005]
* fix GRASS GIS broken for Python 3.12: [https://github.com/OSGeo/grass/pull/3009 PR #3009], [https://github.com/OSGeo/grass/pull/3010 PR #3010], [https://github.com/OSGeo/grass/pull/3011 PR #3011], [https://github.com/OSGeo/grass/pull/3018 PR #3018]
* fix GRASS GIS addons broken for Python 3.12: [https://github.com/OSGeo/grass-addons/pull/917 PR #917], [https://github.com/OSGeo/grass-addons/pull/918 PR #918], [https://github.com/OSGeo/grass-addons/pull/919 PR #919]

=== Floris Vanderhaeghe ===

* Explore reading straight from the GRASS database into R (https://github.com/rsbivand/rgrass/issues/75)
* Help arranging a meeting with Nyall Dawson for the QGIS GRASS interface
* Participate in a two-hour meeting with Roger Bivand, Vero Andreo, Vaclav, Anna, Helmut, Micha, ..... about rgrass development
* Participate in a two-hour meeting with Nyall Dawson (QGIS) and the GRASS Community about interfacing GRASS from QGIS

=== Vero Andreo ===

* Participated in the discussion about renaming locations to projects
* Call with Paulo on diverse topics, r.niche.similarity PR revision and merge
* Participated in a two-hour meeting with Roger, Floris, Vaclav, Anna, Helmut, Micha, ..... about rgrass development
* Worked on GRASS Website:
** Apply fixes and merge the [https://github.com/OSGeo/grass-website/pull/362 DOI] and [https://github.com/OSGeo/grass-website/pull/364 first draft of sponsoring tiers] PRs
** Beautify tables and content of sponsoring page [https://github.com/OSGeo/grass-website/pull/368 #368]
** New menu and submenus (some reordered), please comment [https://github.com/OSGeo/grass-website/pull/369 #369]
** Created a news item about rgrass7 retirement with text snippet contributed by Roger Bivand [https://github.com/OSGeo/grass-website/pull/370 #370]
* Other minor revisions

=== Discussion with Nyall (QGIS) ===

* How to improve the integration
** save some of the existing code
** update "Processing" integration
** ...
* GRASS GIS Addon support in QGIS, see
** https://github.com/qgis/QGIS/pull/53048
** https://github.com/qgis/QGIS/pull/53049

Talk:GRASS Community Meeting Prague 2023

2023-06-05T07:42:39Z

⚠️Micha: /* Micha Silver */

__TOC__

== Tasks for participants ==

* Create section for you in the Reports section.
* List all the things you are working on in the section. Update the list each day. Include things you work on with other people.
* Link the [https://github.com/orgs/OSGeo/projects/1/ GRASS Community Meeting Prague 2023] project on GitHub to each PR or issue you are working on or plan to be working on.
* If you are or will be working on an issue or on a PR which is not originally submitted by you, assign yourself to the issue or PR. (You can unassign yourself later if you change your mind.)

== Planning and organizing ==

* Initial planning: Veronica Andreo, Martin Landa, Vaclav Petras, Helmut Kudrnovsky, Anna Petrasova, Huidae Cho, Markus Neteler, Helena Mitasova, Micha Silver, Linda Kladivova
* Funding acquisition: Veronica Andreo, Markus Neteler, Vaclav Petras, Anna Petrasova, Huidae Cho, Luca Delucchi, Venkatesh Raghavan
* Budget: Vaclav Petras, Markus Neteler, Veronica Andreo
* Venue and local organizing: Martin Landa
* T-shirts, hoodies, stickers: Vaclav Petras, Anna Petrasova
* Promotion, invitations, and social media: Caitlin Haedrich, Veronica Andreo, Vaclav Petras
* Wiki page: Martin Landa, Markus Neteler, Vaclav Petras, Veronica Andreo
* Virtual meeting organizing: Veronica Andreo
* Photography: Caitlin Haedrich

== Ideas for the meeting agenda ==

Collect ideas here :-)

=== Markus Neteler ===

* Improve QGIS-GRASS GIS integration; update of provider to GRASS GIS 8
* GRASS GIS addons overview generator for entire GitHub (and more?) based on tag "[https://github.com/topics/grass-gis-addons grass-gis-addons]"
* Discuss about a 4th edition of "Open Source GIS: A GRASS GIS Approach"
* message translation: Easy [https://docs.weblate.org/en/latest/user/translating.html#machine-translation machine translation] of messages in [https://weblate.osgeo.org/translate/grass-gis OSGeo-Weblate] with DeepL API
** my tests with DeepL show that the quality is very good; average translation time of a user message shrinks to 15 seconds {{done}}
** note: one needs to login to Weblate to see the "Automatic suggestion" button (using the OSGeo-ID)
* Fix docs:
** Provide better explanation for radius parameter for r.resamp.filter: https://github.com/OSGeo/grass/issues/2569
** improve v.clean docs

=== Vero ===

* '''All - think about GRASS GIS mission and vision''': Where do we want to be as a project in 5 years time? What do we want to have? What do we want to be?
* Participate in discussions about GRASS interfaces with QGIS and R (rgrass)
* Discuss sponsoring
* Student grant for (python) documentation?
* Discuss about wiki clean-up/update (Anna was working on a list of pages)
* Website enhancements: complete open PR's, meet Daniel Torres, new support item in main menu
* Discuss State of GRASS presentation for FOSS4G 2023
* i.landsat if time permits
* ...

=== You ===

== Reports ==

=== Caitlin Haedrich ===
* Photos, social media and wiki page
* grass.jupyter:
** [https://github.com/OSGeo/grass/pull/2996 add feature for animating series of rasters]

=== Vaclav Petras ===

* Rename location to project
** [https://github.com/OSGeo/grass/pull/2993 wxGUI: Rename location to project #2993]
** Discussion
* Python API
** [https://github.com/OSGeo/grass/pull/2923 grass.experimental: Add object to access modules as functions #2923]
* CI
** [https://github.com/OSGeo/grass/pull/3002 CI: Switch Travis to Ubuntu 22.04 (jammmy) #3002]
* Reviews and merges:
** [https://github.com/OSGeo/grass/pull/2974 t.rast.algebra/testsuite: split file test_raster_algebra.py #2974]
** [https://github.com/OSGeo/grass/pull/2189 Imagery: add libsvm based imagery classification #2189]
** [https://github.com/OSGeo/grass-addons/pull/606 r.random.walk: Add module to create random walks #606]

=== Anna Petrasova ===
* [https://github.com/OSGeo/grass/pull/2992 Fix bug in querying]
* review, merge and backport of [https://github.com/OSGeo/grass/pull/2994 fix in datacatalog]
* review of [https://github.com/OSGeo/grass/pull/2520 wxGUI: fix show MASK statusbar button widget if mask is created]
* merge of [https://github.com/OSGeo/grass/pull/2667 wxGUI: adding a button for undocking an AuiNotebook tab to wx.Frame (Single-Window GUI)]
* edit [https://github.com/OSGeo/grass/pull/2990 check min required wx version when starting wxgui]

=== Maris Nartiss ===

* i.svm.* cleanup and preparation for a review
* A conceptual proposal for a new start up screen
* Initial version of imagery signature management module i.signatures
* Remove obsolete parts of locale README file

=== Micha Silver ===
Working on a new GRASS addon: r.optram
[https://github.com/micha-silver/grass-addons/tree/grass8/src/raster/r.optram the repo on github]

02/06: Initialize main file ''r.optram.py''

includes these functions:
# ''getImgList()'' - get list of IMG_FILEs in a Sentinel 2 SAFE Directory
# ''cropToAOI()'' - Crop the images to the Area of Interest
# ''prepareSTR()'' - Convert SWIR to the SWIR Transformed Reflectance
# ''prepareVI()'' - Prepare the (user chosen) vegetation index

03/06:
# Split to three modules: '''r.optram.preprocess, r.optram, r.optram.soilmoisture'''
# new function: ''prepareTrapezoid()'' - to get wet-dry regression lines and slope, intercept values

04/06
# ''prepareTrapezoid()'' function completed.
# (Joined video conf with Roger Bivand on R-GRASS integration.)

05/06
Initialize third file/function: ''r.optram.soilmoisture.py''
# ''createSoilMoisture()'' - creates new GRASS raster for a single date
# Add documentation to modules

TODO list:
* Read Sentinel cloud mask and mask out cloud pixels in '''r.optram.preprocess'''
* large study areas or very long time series will create a big numpy table of variables (vegetation index and STR). A possible solution:
# Determine some "reasonable" maximum size for the numpy table, depending on computer resources.
# Extract a subset of pixels from each raster in the time series, such that the total table pixel values will not exceed that maximum
# The size of the subset will be set by ("reasonable" max / number of rasters in time series)
# Allow user to determine "reasonable" max.
* Currently this addon consists of three sub-modules. Consider to consolidate to one.

=== Luís de Sousa ===

==== Work on GRASS add-on [https://grass.osgeo.org/grass82/manuals/addons/r.mblend.html r.mblend] ====

* Module is still maintained and fully functional in GRASS 8.2 (now included in the [https://github.com/OSGeo/grass-addons GRASS global add-ons repository])
* However was not longer producing correct results due to new behaviour in '''v.what.rast'''
* Solution identified, using inner buffer to interpolation area ([https://github.com/OSGeo/grass-addons/pull/910 PR #910])
* A small unit test suite was developed ([https://github.com/OSGeo/grass-addons/pull/911 PR #911])

==== Documentation ====

* Expanded instructions on Pre-commit ([https://github.com/OSGeo/grass/pull/3006 PR #3006])
* Mini guidelines on unit tests for add-ons ([https://github.com/OSGeo/grass-addons/pull/916 PR #916])

=== Aaron Saw Min Sern ===

* Fix bug to complete r.univar parallelization. [https://github.com/OSGeo/grass/pull/2683 PR]

=== Martin Landa ===

* Check min required wx version when starting wxgui [https://github.com/OSGeo/grass/pull/2990 PR #2990]
* Graphical modeler: avoid overlapping module parameters [https://github.com/OSGeo/grass/issues/2991 PR #2991]
* Show ModelRelation in white on dark mode [https://github.com/OSGeo/grass/pull/2997 PR #2997]
* Add OSGeo4W workflow to compile Addons [https://github.com/OSGeo/grass-addons/pull/912 PR #912]
* Integrate Grapical Modeler into single window layout [https://github.com/OSGeo/grass/pull/3003 PR #3003]

=== Markus Neteler ===

* backport of "HTML header charset changed from ISO-8859-1 to UTF-8" [https://github.com/OSGeo/grass/pull/2547 PR #2547] to GRASS GIS 8.2.1 (fixing r.forcircular manual encoding bug)
* improve "Update alpine Docker tag to v3.18 [https://github.com/OSGeo/grass/pull/2953 PR #2953]
* backport of Alpine Dockerfile improvements
* discussion about "location/mapset" vs "project/..." terminology
* initial QGIS-GRASS update discussion
* Google Photo album feeds
* Use of [https://github.com/OSGeo/grass/blob/main/doc/development/submitting/submitting.md#use-pre-commit pre-commit] (recommended to all devs!)
* GRASS GIS manual pages: re-styling and conversion of all pages to markdown:
** convert to markdown with pandoc (draft script see https://app.gitter.im/#/room/#grassgis_sprint:gitter.im discussion)
** using mkdocs (https://www.mkdocs.org/): it provides menus and a search window
** check: automatic formatting for mkdocs: https://github.com/KyleKing/mdformat-mkdocs

=== Helmut Kudrnovsky ===

* discuss (win)GRASS-R issues [https://github.com/rsbivand/rgrass/issues/57 initGrass Error] and [https://github.com/OSGeo/grass/issues/2998 feature requests]

* Review and initial tests of PR [https://github.com/OSGeo/grass/pull/2684 compilation with cmake] on Windows

* Participated in a two-hour meeting with Roger, Floris, Vaclav, Anna, Micha, ..... about rgrass development

=== Ondřej Pešek ===

* gmodeler: add export to an actinia script: [https://github.com/OSGeo/grass/pull/3005 PR #3005]
* fix GRASS GIS broken for Python 3.12: [https://github.com/OSGeo/grass/pull/3009 PR #3009], [https://github.com/OSGeo/grass/pull/3010 PR #3010], [https://github.com/OSGeo/grass/pull/3011 PR #3011]

=== Floris Vanderhaeghe ===

* Explore reading straight from the GRASS database into R (https://github.com/rsbivand/rgrass/issues/75)
* Help arranging a meeting with Nyall Dawson for the QGIS GRASS interface
* Participate in a two-hour meeting with Roger Bivand, Vero Andreo, Vaclav, Anna, Helmut, Micha, ..... about rgrass development

=== Vero Andreo ===

* Participated in the discussion about renaming locations to projects
* Call with Paulo on diverse topics, r.niche.similarity PR revision and merge
* Participated in a two-hour meeting with Roger, Floris, Vaclav, Anna, Helmut, Micha, ..... about rgrass development
* Worked on GRASS Website:
** Apply fixes and merge the [https://github.com/OSGeo/grass-website/pull/362 DOI] and [https://github.com/OSGeo/grass-website/pull/364 first draft of sponsoring tiers] PRs
** Beautify tables and content of sponsoring page [https://github.com/OSGeo/grass-website/pull/368 #368]
** New menu and submenus (some reordered), please comment [https://github.com/OSGeo/grass-website/pull/369 #369]
* Other minor revisions

Talk:GRASS Community Meeting Prague 2023

2023-06-03T13:06:51Z

⚠️Micha: /* Micha Silver */

Talk:GRASS Community Meeting Prague 2023

2023-06-02T16:07:32Z

⚠️Micha: /* Micha Silver */

Talk:GRASS Community Meeting Prague 2023

2023-06-02T16:04:40Z

⚠️Micha: /* Micha Silver */

Talk:GRASS Community Meeting Prague 2023

2023-06-02T15:59:20Z

⚠️Micha: /* Micha Silver */

Talk:GRASS Community Meeting Prague 2023

2023-06-02T15:51:16Z

⚠️Micha:

GRASS Community Meeting Prague 2023

2023-03-16T17:03:53Z

⚠️Micha: /* In person */

{{toc|right}}
The GRASS GIS team is organizing the ''GRASS GIS Community Meeting with contributors, power users and developers'' from '''June 2 to June 6, 2023''' to celebrate GRASS GIS '''40th birthday'''.

<gallery mode="slideshow">
Image:grass-sprint-prague.jpg|Prague 2013
Image:Grass_sprint2018_bonn_fotowall.jpg|Bonn 2018
</gallery>

== Purpose ==

GRASS GIS Community Meeting is a great occasion for folks to support the development by actively contributing to the source code, documentation (manuals, wiki, tutorials), translations, website or likewise. The '''community''' meeting is also a get-together where supporters, contributors, power users and developers make decisions and tackle larger problems related to the project, discuss and collaboratively resolve bugs, plan the direction for the project and work on new features. We welcome people committed to improving the GRASS GIS project and the interfaces to QGIS, GDAL, PostGIS, R statistics, OGC Services and willing to '''celebrate with us the 40th GRASS GIS birthday!!'''

== Sponsors ==

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

:::'''sponsoring the GRASS GIS project''' at '''[https://grass.osgeo.org/contribute/sponsoring/ https://grass.osgeo.org/contribute/sponsoring/]'''

Note that it is also possible to buy a round of beers for the developers with a quick click using the Open Collective "Contribute Money" button https://opencollective.com/osgeo/projects/grass

Any surplus at the end of the event will be turned over to the GRASS GIS project.

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

=== Thanks to our sponsors ===

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

TBD

== Timing ==

'''When''': June 2-6, 2023

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

== Venue ==

[[Image:logo_cvut.jpg|130px|left]]
Department of Geomatics 
[https://www.fsv.cvut.cz/?lang=en Faculty of Civil Engineering] 
[https://www.cvut.cz/en Czech Technical University in Prague], {{wikipedia|Czech Republic}} 
Room B868 
[https://en.mapy.cz/s/debazefuse Map] 

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

== Accommodation and Costs ==

Participants should plan for the following costs:

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

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

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

== Agenda - What we plan to do ==

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

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

=== Timeline ===

Will be specified later.

==== Friday, 2 June ====

==== Saturday, 3 June ====

==== Sunday, 4 June ====

==== Monday, 5 June ====

==== Tuesday, 6 June ====

== Participation ==

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

=== In person ===

{|class="wikitable sortable" border="2" cellspacing="0" cellpadding="4" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse; background-color:#edf9c7; font-size:95%; empty-cells:show;"
!width=50px|'''Number'''
!width=130px|'''Participant '''
!width=100px|'''Country'''
!width=100px|'''Arrival'''
!width=100px|'''Departure'''
!'''Topics'''
!width=75px|'''T-Shirt'''
!'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
|Czech Republic
| June 2
| June 6
|
| XL
|
|-
|x
| Micha Silver
|Israel
|June 2
|June 6
|Addon to derive soil moisture from Sentinel 2
|XXL
|
|-
|}

=== Via chat or hangout ===

Join our [https://app.gitter.im/#/room/#grassgis_community:gitter.im Gitter chatroom]

TBD: Google Meet / Zoom / ???

==== Timing of hangout meetings ====

TBD

=== Collaborative document scratching ===

TBD

== Individual Preparation ==

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

== Broadcast & Video ==

During the event :)

== Photos ==

Also during the event :)

== FAQ ==

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

== Press Release ==

TBD: After the event :-)

[[Category: Workshops]]
[[Category: Code Sprint]]
[[Category: 2023]]

GRASS migration hints

2016-02-01T11:18:04Z

⚠️Micha: /* Support */

== Support ==

There is a lot of help on the web, this wiki and in the user manual. However, a lot of people are available on the mailing lists and at other places.
* See [https://grass.osgeo.org/support/ the official support page] which also includes links to commercially provided support.
* Subscribe to the grass-users [https://lists.osgeo.org/listinfo/grass-user maillist]
* Visit the [http://gis.stackexchange.com/questions/tagged/grass GRASS tag] on gis.stackexchange.com

== Guides and tips for migration ==

* [[GIS Concepts]] in GRASS GIS

=== Migrating from ESRI products ===

* [[GRASS GIS for ArcGIS users]]
* [[Tips for Arc users|Tips for ArcGIS users]]
* [http://www.surfaces.co.il/?p=241 Watershed Analysis with GRASS] (in case you know the ESRI way)
* [[Terminology comparison between ArcGIS and GRASS GIS]]

=== Migrating from older versions of GRASS GIS ===

* [[GRASS Module Porting List|Module updates between GRASS GIS version 5 and 6]]
* [http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures List of new features in GRASS GIS 7] (new modules, new names, options, etc.; check here if you don't find a certain modules or module parameter)

== GIS "The GRASS way" ==

When migrating to GRASS GIS, it is useful to review its design and values. Here are the highlights.

=== Portability ===
* Support for all major platforms including Linux, Mac OS X and MS Windows
* All code POSIX C and generic UNIX compatible
* GRASS GIS works not only on powerful desktops but also on low-end laptops all the way down to devices such as [[Raspberry Pi]].
* GRASS GIS also works on servers, clusters for scientific computing, and on other supper computer or cloud setups
* 64bit and 32bit versions

=== Scalability ===
* [[GRASS GIS Performance]]
* 64bit version offers even better performance and capacity on all platforms including MS Windows

=== All in one ===

* With GRASS GIS you are getting full selection of analysis including but not limited to hydrology, terrain analysis, network analysis and image processing. No installing or purchasing of additional tools or plugins.
* GRASS GIS aims to process all kinds of geospatial data in a unified way including vectors, rasters, images, 3D rasters and their time series.

=== Scriptability ===
* GRASS GIS is made up of modular tools specifically designed for easy scriptability in any number of common scripting languages, see for example [[GRASS and Shell]]
* Interface for direct hooks into higher scripting languages especially Python but also R and Bash/Shell, see [[GRASS and Python]] and [[Category:Linking to other languages]]
* GRASS GIS can run without any GUI when the full path to the mapset is provided in the command line parameters. If "<tt>GRASS_BATCH_JOB=/path/to/script.sh</tt>" environmental variable is set GRASS 6+ will run the script as a batch job and exit when it is complete. Same applies to <tt>--exec</tt> parameter in GRASS 7.1+. See also {{cmd|grass7}} command manual and [[GRASS and Shell#GRASS Batch jobs|GRASS and Shell]].

=== Interoperability ===
Collaboration with external software is highly encouraged.

* [http://www.gdal.org GDAL/OGR] for import/export to many formats
* [http://www.numpy.org/ NumPy] (in Python): {{pyapi|script|script.array|array}}, {{pyapi|script|script.array|array3d}}
* [https://www.r-project.org/ R] statistical software: [http://grass.osgeo.org/statsgrass/ GRASS-R interface]
* DXF: {{cmd|v.in.dxf}}, {{cmd|v.out.dxf}}, {{cmd|v.in.ogr}}, {{cmd|v.out.ogr}}
* Matlab/[http://www.gnu.org/software/octave/Octave Octave]: {{cmd|r.in.mat}}, {{cmd|r.out.mat}}, {{cmd|v.in.mapgen}}, {{cmd|v.in.ascii}}, {{cmd|v.out.ascii}}
* [http://www.povray.org/ POV-Ray] rendering: {{cmd|r.out.pov}}, {{cmd|v.out.pov}} - see also [[POV-Ray]]
* VMRL: {{cmd|r.out.vrml}} (3D virtual reality)
* [http://gmt.soest.hawaii.edu/ GMT] - Generic Mapping Tools for cartography: {{cmd|r.in.bin}}, {{cmd|r.out.bin}}
* Google Earth/KML: {{cmd|v.out.ogr}}
* VTK ([http://www.paraview.org/ Paraview], etc): {{cmd|r3.out.vtk}}, {{cmd|r.out.vtk}}, {{cmd|v.out.vtk}} - see also [[GRASS and Paraview]]
* [http://vis5d.sourceforge.net/ Vis5D]: {{cmd|r3.in.v5d}}, {{cmd|r3.out.v5d}}
* QGIS has GRASS Plugin to work with GRASS GIS data and analytical tools inside QGIS

=== Freedom ===
* All users are free to run the GRASS GIS for any purpose, study how it works, copy it and redistribute it, and even change it.
* Freedoms ensured by GNU General Public License (GPL)
* Rocchini, D., Neteler, M., 2012. Let the four freedoms paradigm apply to ecology. Trends in Ecology & Evolution 27, 310–311., ([http://tinyurl.com/tree-four-freedoms full text])

== External links: Software Comparisons ==

''Some information may be outdated. Note the year of individual resources.''

* Steiniger, S., Hunter, A.J.S., 2013. The 2012 free and open source GIS software map – A guide to facilitate research, development, and adoption. Computers, Environment and Urban Systems 39, 136–150. [http://dx.doi.org/10.1016/j.compenvurbsys.2012.10.003 DOI]
* [http://spreadsheets.google.com/ccc?key=0Albk_XRkhVkzdGxyYk8tNEZvLUp1UTUzTFN5bjlLX2c&hl=en Matrix of open source and proprietary software functionality] (2010)
* [http://contentcat.fhsu.edu/cdm/singleitem/collection/thesis/id/545/rec/44 MSc thesis 2006 (English), Comparison of geographic information system software (ArcGIS 9.0 and GRASS 6.0): implementation and case study] by T.R. Buchanan
* [http://cemml.carleton.ca/osgeo_files/FOSS_geomatics.pdf An Exploration Of Free And Open Source Software For Geomatics] (thesis, 2008)
* [http://gis.stackexchange.com/questions/23637/comparison-of-open-source-desktop-gis-packages Comparison of Open Source Desktop GIS Packages] (collection of links) at GIS StackExchange

[[Category:Community]]
[[Category:ArcGIS]]

GRASS migration hints

2016-02-01T11:16:43Z

⚠️Micha: /* Support */

== Support ==

There is a lot of help on the web, this wiki and in the user manual. However, a lot of people are available on the mailing lists and at other places.
* See [https://grass.osgeo.org/support/ the official support page] which also includes links to commercially provided support.
* Subscribe to the grass-users [https://lists.osgeo.org/listinfo/grass-user maillist]
* The [http://gis.stackexchange.com/questions/tagged/grass GRASS tag] on gis.stackexchange.com

== Guides and tips for migration ==

* [[GIS Concepts]] in GRASS GIS

=== Migrating from ESRI products ===

* [[GRASS GIS for ArcGIS users]]
* [[Tips for Arc users|Tips for ArcGIS users]]
* [http://www.surfaces.co.il/?p=241 Watershed Analysis with GRASS] (in case you know the ESRI way)
* [[Terminology comparison between ArcGIS and GRASS GIS]]

=== Migrating from older versions of GRASS GIS ===

* [[GRASS Module Porting List|Module updates between GRASS GIS version 5 and 6]]
* [http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures List of new features in GRASS GIS 7] (new modules, new names, options, etc.; check here if you don't find a certain modules or module parameter)

== GIS "The GRASS way" ==

When migrating to GRASS GIS, it is useful to review its design and values. Here are the highlights.

=== Portability ===
* Support for all major platforms including Linux, Mac OS X and MS Windows
* All code POSIX C and generic UNIX compatible
* GRASS GIS works not only on powerful desktops but also on low-end laptops all the way down to devices such as [[Raspberry Pi]].
* GRASS GIS also works on servers, clusters for scientific computing, and on other supper computer or cloud setups
* 64bit and 32bit versions

=== Scalability ===
* [[GRASS GIS Performance]]
* 64bit version offers even better performance and capacity on all platforms including MS Windows

=== All in one ===

* With GRASS GIS you are getting full selection of analysis including but not limited to hydrology, terrain analysis, network analysis and image processing. No installing or purchasing of additional tools or plugins.
* GRASS GIS aims to process all kinds of geospatial data in a unified way including vectors, rasters, images, 3D rasters and their time series.

=== Scriptability ===
* GRASS GIS is made up of modular tools specifically designed for easy scriptability in any number of common scripting languages, see for example [[GRASS and Shell]]
* Interface for direct hooks into higher scripting languages especially Python but also R and Bash/Shell, see [[GRASS and Python]] and [[Category:Linking to other languages]]
* GRASS GIS can run without any GUI when the full path to the mapset is provided in the command line parameters. If "<tt>GRASS_BATCH_JOB=/path/to/script.sh</tt>" environmental variable is set GRASS 6+ will run the script as a batch job and exit when it is complete. Same applies to <tt>--exec</tt> parameter in GRASS 7.1+. See also {{cmd|grass7}} command manual and [[GRASS and Shell#GRASS Batch jobs|GRASS and Shell]].

=== Interoperability ===
Collaboration with external software is highly encouraged.

* [http://www.gdal.org GDAL/OGR] for import/export to many formats
* [http://www.numpy.org/ NumPy] (in Python): {{pyapi|script|script.array|array}}, {{pyapi|script|script.array|array3d}}
* [https://www.r-project.org/ R] statistical software: [http://grass.osgeo.org/statsgrass/ GRASS-R interface]
* DXF: {{cmd|v.in.dxf}}, {{cmd|v.out.dxf}}, {{cmd|v.in.ogr}}, {{cmd|v.out.ogr}}
* Matlab/[http://www.gnu.org/software/octave/Octave Octave]: {{cmd|r.in.mat}}, {{cmd|r.out.mat}}, {{cmd|v.in.mapgen}}, {{cmd|v.in.ascii}}, {{cmd|v.out.ascii}}
* [http://www.povray.org/ POV-Ray] rendering: {{cmd|r.out.pov}}, {{cmd|v.out.pov}} - see also [[POV-Ray]]
* VMRL: {{cmd|r.out.vrml}} (3D virtual reality)
* [http://gmt.soest.hawaii.edu/ GMT] - Generic Mapping Tools for cartography: {{cmd|r.in.bin}}, {{cmd|r.out.bin}}
* Google Earth/KML: {{cmd|v.out.ogr}}
* VTK ([http://www.paraview.org/ Paraview], etc): {{cmd|r3.out.vtk}}, {{cmd|r.out.vtk}}, {{cmd|v.out.vtk}} - see also [[GRASS and Paraview]]
* [http://vis5d.sourceforge.net/ Vis5D]: {{cmd|r3.in.v5d}}, {{cmd|r3.out.v5d}}
* QGIS has GRASS Plugin to work with GRASS GIS data and analytical tools inside QGIS

=== Freedom ===
* All users are free to run the GRASS GIS for any purpose, study how it works, copy it and redistribute it, and even change it.
* Freedoms ensured by GNU General Public License (GPL)
* Rocchini, D., Neteler, M., 2012. Let the four freedoms paradigm apply to ecology. Trends in Ecology & Evolution 27, 310–311., ([http://tinyurl.com/tree-four-freedoms full text])

== External links: Software Comparisons ==

''Some information may be outdated. Note the year of individual resources.''

* Steiniger, S., Hunter, A.J.S., 2013. The 2012 free and open source GIS software map – A guide to facilitate research, development, and adoption. Computers, Environment and Urban Systems 39, 136–150. [http://dx.doi.org/10.1016/j.compenvurbsys.2012.10.003 DOI]
* [http://spreadsheets.google.com/ccc?key=0Albk_XRkhVkzdGxyYk8tNEZvLUp1UTUzTFN5bjlLX2c&hl=en Matrix of open source and proprietary software functionality] (2010)
* [http://contentcat.fhsu.edu/cdm/singleitem/collection/thesis/id/545/rec/44 MSc thesis 2006 (English), Comparison of geographic information system software (ArcGIS 9.0 and GRASS 6.0): implementation and case study] by T.R. Buchanan
* [http://cemml.carleton.ca/osgeo_files/FOSS_geomatics.pdf An Exploration Of Free And Open Source Software For Geomatics] (thesis, 2008)
* [http://gis.stackexchange.com/questions/23637/comparison-of-open-source-desktop-gis-packages Comparison of Open Source Desktop GIS Packages] (collection of links) at GIS StackExchange

[[Category:Community]]
[[Category:ArcGIS]]

GRASS migration hints

2016-02-01T11:12:34Z

⚠️Micha:

== Support ==

There is a lot of help on the web, this wiki and in the user manual. However, a lot of people are available on the mailing lists and at other places.
* See [https://grass.osgeo.org/support/ the official support page] which also includes links to commercially provided support.
* Subscribe to the grass-users [https://lists.osgeo.org/listinfo/grass-user maillist]

== Guides and tips for migration ==

* [[GIS Concepts]] in GRASS GIS

=== Migrating from ESRI products ===

* [[GRASS GIS for ArcGIS users]]
* [[Tips for Arc users|Tips for ArcGIS users]]
* [http://www.surfaces.co.il/?p=241 Watershed Analysis with GRASS] (in case you know the ESRI way)
* [[Terminology comparison between ArcGIS and GRASS GIS]]

=== Migrating from older versions of GRASS GIS ===

* [[GRASS Module Porting List|Module updates between GRASS GIS version 5 and 6]]
* [http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures List of new features in GRASS GIS 7] (new modules, new names, options, etc.; check here if you don't find a certain modules or module parameter)

== GIS "The GRASS way" ==

When migrating to GRASS GIS, it is useful to review its design and values. Here are the highlights.

=== Portability ===
* Support for all major platforms including Linux, Mac OS X and MS Windows
* All code POSIX C and generic UNIX compatible
* GRASS GIS works not only on powerful desktops but also on low-end laptops all the way down to devices such as [[Raspberry Pi]].
* GRASS GIS also works on servers, clusters for scientific computing, and on other supper computer or cloud setups
* 64bit and 32bit versions

=== Scalability ===
* [[GRASS GIS Performance]]
* 64bit version offers even better performance and capacity on all platforms including MS Windows

=== All in one ===

* With GRASS GIS you are getting full selection of analysis including but not limited to hydrology, terrain analysis, network analysis and image processing. No installing or purchasing of additional tools or plugins.
* GRASS GIS aims to process all kinds of geospatial data in a unified way including vectors, rasters, images, 3D rasters and their time series.

=== Scriptability ===
* GRASS GIS is made up of modular tools specifically designed for easy scriptability in any number of common scripting languages, see for example [[GRASS and Shell]]
* Interface for direct hooks into higher scripting languages especially Python but also R and Bash/Shell, see [[GRASS and Python]] and [[Category:Linking to other languages]]
* GRASS GIS can run without any GUI when the full path to the mapset is provided in the command line parameters. If "<tt>GRASS_BATCH_JOB=/path/to/script.sh</tt>" environmental variable is set GRASS 6+ will run the script as a batch job and exit when it is complete. Same applies to <tt>--exec</tt> parameter in GRASS 7.1+. See also {{cmd|grass7}} command manual and [[GRASS and Shell#GRASS Batch jobs|GRASS and Shell]].

=== Interoperability ===
Collaboration with external software is highly encouraged.

* [http://www.gdal.org GDAL/OGR] for import/export to many formats
* [http://www.numpy.org/ NumPy] (in Python): {{pyapi|script|script.array|array}}, {{pyapi|script|script.array|array3d}}
* [https://www.r-project.org/ R] statistical software: [http://grass.osgeo.org/statsgrass/ GRASS-R interface]
* DXF: {{cmd|v.in.dxf}}, {{cmd|v.out.dxf}}, {{cmd|v.in.ogr}}, {{cmd|v.out.ogr}}
* Matlab/[http://www.gnu.org/software/octave/Octave Octave]: {{cmd|r.in.mat}}, {{cmd|r.out.mat}}, {{cmd|v.in.mapgen}}, {{cmd|v.in.ascii}}, {{cmd|v.out.ascii}}
* [http://www.povray.org/ POV-Ray] rendering: {{cmd|r.out.pov}}, {{cmd|v.out.pov}} - see also [[POV-Ray]]
* VMRL: {{cmd|r.out.vrml}} (3D virtual reality)
* [http://gmt.soest.hawaii.edu/ GMT] - Generic Mapping Tools for cartography: {{cmd|r.in.bin}}, {{cmd|r.out.bin}}
* Google Earth/KML: {{cmd|v.out.ogr}}
* VTK ([http://www.paraview.org/ Paraview], etc): {{cmd|r3.out.vtk}}, {{cmd|r.out.vtk}}, {{cmd|v.out.vtk}} - see also [[GRASS and Paraview]]
* [http://vis5d.sourceforge.net/ Vis5D]: {{cmd|r3.in.v5d}}, {{cmd|r3.out.v5d}}
* QGIS has GRASS Plugin to work with GRASS GIS data and analytical tools inside QGIS

=== Freedom ===
* All users are free to run the GRASS GIS for any purpose, study how it works, copy it and redistribute it, and even change it.
* Freedoms ensured by GNU General Public License (GPL)
* Rocchini, D., Neteler, M., 2012. Let the four freedoms paradigm apply to ecology. Trends in Ecology & Evolution 27, 310–311., ([http://tinyurl.com/tree-four-freedoms full text])

== External links: Software Comparisons ==

''Some information may be outdated. Note the year of individual resources.''

* Steiniger, S., Hunter, A.J.S., 2013. The 2012 free and open source GIS software map – A guide to facilitate research, development, and adoption. Computers, Environment and Urban Systems 39, 136–150. [http://dx.doi.org/10.1016/j.compenvurbsys.2012.10.003 DOI]
* [http://spreadsheets.google.com/ccc?key=0Albk_XRkhVkzdGxyYk8tNEZvLUp1UTUzTFN5bjlLX2c&hl=en Matrix of open source and proprietary software functionality] (2010)
* [http://contentcat.fhsu.edu/cdm/singleitem/collection/thesis/id/545/rec/44 MSc thesis 2006 (English), Comparison of geographic information system software (ArcGIS 9.0 and GRASS 6.0): implementation and case study] by T.R. Buchanan
* [http://cemml.carleton.ca/osgeo_files/FOSS_geomatics.pdf An Exploration Of Free And Open Source Software For Geomatics] (thesis, 2008)
* [http://gis.stackexchange.com/questions/23637/comparison-of-open-source-desktop-gis-packages Comparison of Open Source Desktop GIS Packages] (collection of links) at GIS StackExchange

[[Category:Community]]
[[Category:ArcGIS]]

GRASS migration hints

2016-02-01T11:10:13Z

⚠️Micha: Bullet items in Support section

== Support ==

There is a lot of help on the web, this wiki and in the user manual. However, a lot of people are available on the mailing lists and at other places.
* See [https://grass.osgeo.org/support/ the official support page] which also includes links to commercially provided support.
* Subscribe to the grass-users [https://lists.osgeo.org/listinfo/grass-user maillist]

== Guides and tips for migration ==

== GRASS GIS Concepts ==

* [[GIS Concepts]] in GRASS GIS

=== Migrating from ESRI products ===

* [[GRASS GIS for ArcGIS users]]
* [[Tips for Arc users|Tips for ArcGIS users]]
* [http://www.surfaces.co.il/?p=241 Watershed Analysis with GRASS] (in case you know the ESRI way)
* [[Terminology comparison between ArcGIS and GRASS GIS]]

=== Migrating from older versions of GRASS GIS ===

* [[GRASS Module Porting List|Module updates between GRASS GIS version 5 and 6]]
* [http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures List of new features in GRASS GIS 7] (new modules, new names, options, etc.; check here if you don't find a certain modules or module parameter)

== GIS "The GRASS way" ==

When migrating to GRASS GIS, it is useful to revise its design and values. Here are the highlights.

=== Portability ===
* Support for all major platforms including Linux, Mac OS X and MS Windows
* All code POSIX C and generic UNIX compatible
* GRASS GIS works not only on powerful desktops but also on low-end laptops all the way down to devices such as [[Raspberry Pi]].
* GRASS GIS also works on servers, clusters for scientific computing, and on other supper computer or cloud setups
* 64bit and 32bit versions

=== Scalability ===
* [[GRASS GIS Performance]]
* 64bit version offers even better performance and capacity on all platforms including MS Windows

=== All in one ===

* With GRASS GIS you are getting full selection of analysis including but not limited to hydrology, terrain analysis, network analysis and image processing. No installing or purchasing of additional tools or plugins.
* GRASS GIS aims to process all kinds of geospatial data in a unified way including vectors, rasters, images, 3D rasters and their time series.

=== Scriptability ===
* GRASS GIS is made up of modular tools specifically designed for easy scriptability in any number of common scripting languages, see for example [[GRASS and Shell]]
* Interface for direct hooks into higher scripting languages especially Python but also R and Bash/Shell, see [[GRASS and Python]] and [[Category:Linking to other languages]]
* GRASS GIS can run without any GUI when the full path to the mapset is provided in the command line parameters. If "<tt>GRASS_BATCH_JOB=/path/to/script.sh</tt>" environmental variable is set GRASS 6+ will run the script as a batch job and exit when it is complete. Same applies to <tt>--exec</tt> parameter in GRASS 7.1+. See also {{cmd|grass7}} command manual and [[GRASS and Shell#GRASS Batch jobs|GRASS and Shell]].

=== Interoperability ===
Collaboration with external software is highly encouraged.

* [http://www.gdal.org GDAL/OGR] for import/export to many formats
* [http://www.numpy.org/ NumPy] (in Python): {{pyapi|script|script.array|array}}, {{pyapi|script|script.array|array3d}}
* [https://www.r-project.org/ R] statistical software: [http://grass.osgeo.org/statsgrass/ GRASS-R interface]
* DXF: {{cmd|v.in.dxf}}, {{cmd|v.out.dxf}}, {{cmd|v.in.ogr}}, {{cmd|v.out.ogr}}
* Matlab/[http://www.gnu.org/software/octave/Octave Octave]: {{cmd|r.in.mat}}, {{cmd|r.out.mat}}, {{cmd|v.in.mapgen}}, {{cmd|v.in.ascii}}, {{cmd|v.out.ascii}}
* [http://www.povray.org/ POV-Ray] rendering: {{cmd|r.out.pov}}, {{cmd|v.out.pov}} - see also [[POV-Ray]]
* VMRL: {{cmd|r.out.vrml}} (3D virtual reality)
* [http://gmt.soest.hawaii.edu/ GMT] - Generic Mapping Tools for cartography: {{cmd|r.in.bin}}, {{cmd|r.out.bin}}
* Google Earth/KML: {{cmd|v.out.ogr}}
* VTK ([http://www.paraview.org/ Paraview], etc): {{cmd|r3.out.vtk}}, {{cmd|r.out.vtk}}, {{cmd|v.out.vtk}} - see also [[GRASS and Paraview]]
* [http://vis5d.sourceforge.net/ Vis5D]: {{cmd|r3.in.v5d}}, {{cmd|r3.out.v5d}}
* QGIS has GRASS Plugin to work with GRASS GIS data and analytical tools inside QGIS

=== Freedom ===
* All users are free to run the GRASS GIS for any purpose, study how it works, copy it and redistribute it, and even change it.
* Freedoms ensured by GNU General Public License (GPL)
* Rocchini, D., Neteler, M., 2012. Let the four freedoms paradigm apply to ecology. Trends in Ecology & Evolution 27, 310–311., ([http://tinyurl.com/tree-four-freedoms full text])

== External links: Software Comparisons ==

''Some information may be outdated. Note the year of individual resources.''

* Steiniger, S., Hunter, A.J.S., 2013. The 2012 free and open source GIS software map – A guide to facilitate research, development, and adoption. Computers, Environment and Urban Systems 39, 136–150. [http://dx.doi.org/10.1016/j.compenvurbsys.2012.10.003 DOI]
* [http://spreadsheets.google.com/ccc?key=0Albk_XRkhVkzdGxyYk8tNEZvLUp1UTUzTFN5bjlLX2c&hl=en Matrix of open source and proprietary software functionality] (2010)
* [http://contentcat.fhsu.edu/cdm/singleitem/collection/thesis/id/545/rec/44 MSc thesis 2006 (English), Comparison of geographic information system software (ArcGIS 9.0 and GRASS 6.0): implementation and case study] by T.R. Buchanan
* [http://cemml.carleton.ca/osgeo_files/FOSS_geomatics.pdf An Exploration Of Free And Open Source Software For Geomatics] (thesis, 2008)
* [http://gis.stackexchange.com/questions/23637/comparison-of-open-source-desktop-gis-packages Comparison of Open Source Desktop GIS Packages] (collection of links) at GIS StackExchange

[[Category:Community]]
[[Category:ArcGIS]]

Creating watersheds

2016-02-01T11:01:52Z

⚠️Micha: /* Calculating total drainage area for each stream reach */

Arcview users, needing to delineate watersheds and stream networks, choose the extension called "Arc Hydro" (requires at least Spatial Analyst). This extension introduces the concepts of "Batch Points" and "Adjoint Catchments". Batch points are locations that the user defines as drainage outlets. An adjoint catchment is the collection of all raster cells that drain into one of the batch points. Here we'll demonstrate how to get similar results with GRASS GIS 6.

== Creating watersheds with specific drainage outlets==
As an example, we'll create a set of catchments with their drainage outlets exactly at the points where the streams cross a road. We'll assume our starting data includes an elevation raster called "dem" and a line vector called "roads". We first create the regular hydrology layers.

=== Preparation ===

<source lang="bash">
#set the region to the dem raster, and run the r.watershed module.
g.region -p rast=dem

# threshold in map cells (try 10000 as a start). Note: DEM Sink-filling not needed:
r.watershed elev=dem drain=fdir basin=catch stream=str thresh=<your-threshold>
</source>

So far, pretty straightforward. There's abundant information on {{cmd|r.watershed}}. I'll just mention that the threshold value is the number of cells that will be the minimum catchment size. So if the resolution of our dem raster is, for example, 10x10 meters (each cell=100 sq. meters), then a threshold of 20,000 (=2,000,000 sq. meters) would create catchments of at least 2 sq. kilometers.

=== Display first results ===
When the process finishes we'll have three new raster maps: the flow direction map, the streams and the catchments. Let's see what we've got so far:

<source lang="bash">
#Convert the steams and catchments to vectors
# r.to.vect in=catch out=catchments feature=area # Grass 6
r.to.vect in=catch out=catchments type=area # Grass 7

# the stream raster usually requires thinning
r.thin in=str out=str_thin
# r.to.vect in=str_thin out=streams feature=line # Grass 6
r.to.vect in=str_thin out=streams type=line # Grass 7
r.colors dem col=elevation

# Make a hillshade raster for displaying "3D"
# r.shaded.relief map=dem shade=dem_shade zmult=1.5 # Grass 6
r.relief input=dem output=dem_shade zscale=1.5 # Grass 7

# Now display layers
# d.mon x0 # Grass 6
d.mon start=wx0 # Grass 7
d.his h=dem i=dem_shade
d.vect map=streams color=blue width=3
d.vect map=catchments type=boundary color=red
d.vect roads color=black width=2
</source>

=== Determine drainage points ===
Now we need to find all the points where streams cross roads. The {{cmd|v.overlay}} module does not deal with point vectors (hint: {{cmd|v.select}} does). Instead we use a trick in v.clean. When cleaning a line vector, all points where lines cross and no node exists are considered topological "errors" and can be saved to a new point vector. So by merging the roads and streams vectors, we create a vector with lines (streams) crossing other lines (roads) without a node. Then we run {{cmd|v.clean}}, and we get all those intersection points in a new vector.

<source lang="bash">
# Patch the streams and roads vectors together
v.patch in=streams,roads out=streams_roads
v.clean in=streams_roads out=streams_roads_clean tool=break error=cross_points

#View cross points on display
d.vect cross_points icon=basic/circle color=green size=12

# Save crossing points to a text file
# v.out.ascii in=cross_points out=cross_points.txt format=point fs=space # Grass 6
v.out.ascii in=cross_points out=cross_points.txt format=point layer=-1 separator=space # Grass 7
</source>

=== Looping thru drainage outlet points ===
Once we have the crossing points in a file, we simply run {{cmd|r.water.outlet}} in a loop to create a watershed for each cross point. However the raster result of r.water.outlet has value '1' in each cell that is upstream of the drainage point, and '0' everywhere else. For our purposes, we want to patch the rasters together after running the loop, so we need to have '''null values''' outside of the watersheds, and each watershed must use a '''different value''' in the upstream cells for its drainage point. To achieve these results, we use the r.null module to set '0' value cells to null. Then, we take advantage of the {{cmd|r.reclass}} function to make a reclassed raster with different values for each watershed. Here's how it works for GRASS 6:

<source lang="bash">
i=0 #an iterator to give consecutive names to the new watersheds
while read X Y; do \
i=$(( ${i} + 1 )) \
r.water.outlet drain=fdir east=$X north=$Y basin=tmp_$i \
r.null tmp_$i setnull=0 \
echo 1=$i | r.reclass in=tmp_$i out=tmp_reclass_$i
done < cross_points.txt
echo "Created $i watersheds"
</source>

And here's how it works for GRASS 7:
<source lang="bash">
i=0 #an iterator to give consecutive names to the new watersheds
while read X Y; do
i=$(( ${i} + 1 ))
r.water.outlet --overwrite input=$drain coordinates=$X,$Y output=tmp_$i
r.null tmp_$i setnull=0
echo 1=$i | r.reclass --overwrite in=tmp_$i out=tmp_reclass_$i rules=-
done < cross_points.txt
echo "Created $i watersheds"
</source>

=== Combining watersheds into one patched vector ===
Next we patch together all the reclassed rasters (watersheds), convert to vector and clean the merged watersheds vector.

<source lang="bash">
# r.patch in=`g.mlist rast pattern=tmp_reclass* separator=,` out=wshed_patch # Grass 6
# r.to.vect in=wshed_patch out=wshed_patch feature=area # Grass 6
r.patch in=`g.list raster pattern=tmp_reclass* separator=,` out=wshed_patch # Grass 7
r.to.vect in=wshed_patch out=wshed_patch type=area
# Use v.clean to remove tiny areas (that were a string of single cells in the raster)
v.clean wshed_patch out=wshed_final tool=rmarea thresh=150
</source>

Choose an appropriate threshold value based on your region resolution. With a region resolution of 10, each individual cell will be 100 sqm, so choosing 150 as the threshold for v.clean allows removing these small areas. Additional manual cleaning may be required.

Clean up tmp rasters:

<source lang="bash">
# g.remove rast=`g.mlist pattern=tmp* sep=,` # Grass 6
g.remove -f type=raster name=`g.list raster pattern=tmp* sep=, ` # Grass 7
</source>

Most likely we'll want to calculate the area for each watershed.

<source lang="bash">
# Add a table with a column for area in sq.km.
# v.db.addcol map=wshed_final col="area_sqkm double" # Grass 6
v.db.addcolumn map=wshed_final col="area_sqkm double" # Grass 7

# Use unit=k(ilometers) to get area in sq. km.
v.to.db map=wshed_final option=area col=area_sqkm unit=k
</source>

And finally, we can view the catchments, and their area values (you may use the [[wxGUI]]):

<source lang="bash">
d.vect wshed_final type=boundary,centroid display=shape,attr attrcol=area_sqkm size=0 width=3 color=orange
</source>

=== Calculating total drainage area for each stream reach ===
Some other software, such as the ArcGIS extension "ArcHydro" can calculate the total upstream drainage area flowing through '''each''' stream reach. The same result is achieved in GRASS with a few hydrology modules and a database join.
Begin by rerunning the r.watershed command as in the first section, but adding a flow accumulation raster as the output:

<source lang="bash">
#set the region to the dem raster, and run the r.watershed module.
g.region -p rast=dem
# Choose threshold in map cells (try 10000 as a start). Note: DEM Sink-filling not needed:
r.watershed elev=dem accumulation=facc thresh=<your-threshold>
</source>

Now create a stream vector layer (or use the vector layer created above) with the r.stream.extract module. Then add to the vector attribute table columns for end point coordinates of each section of the stream, and for the flow accumulation area:
<source lang="bash">
r.stream.extract --o elev=dem accum=facc thresh=<your-threshold> stream_vector=streams
v.db.addcolumn streams col="end_x double, end_y double, accum_area double"
v.to.db streams option=end columns="end_x,end_y"
</source>
We now have a stream vector map with the X-Y coordinates of the end point of each section of the stream, and an empty column ready to accept the upstream drainage area. The next step involves exporting the end point coordinates to a point layer, and using the v.what.rast module to get the values at each point from the flow accumulation grid. Then the end_points vector will have an attribute column containing the total number of upstream pixels flowing thru each point.
<source lang="bash">
v.db.select -c streams column="cat,end_x,end_y" | v.in.ascii --o input=- output=end_points x=2 y=3
v.db.addcolumn end_points column="accum_pixels double, accum_area double"
v.what.rast end_points raster=facc column=accum_pixels
</source>

The following queries the current region setting for the cell resolution. The total number of upstream cells (from the flow accumulation raster) must be multiplied by the cell size in order to get upstream '''area''' in map units. Finally an SQL expression updates the total upstream area to the streams attribute table, using the number of pixels from the end_points multiplied by the area of each pixel.
<source lang="bash">
eval `g.region -g`
SQ_M=$(( ${ewres}*${nsres} ))
v.db.update end_points column=accum_area query_col="accum_pixels*${SQ_M}"
db.execute sql="UPDATE streams SET accum_area=(SELECT accum_area FROM end_points where cat=streams.cat)"
</source>
THis leaves the accum_area column populated with values for total upstream drainage area for each stream reach.

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

Tips for Arc users

2016-02-01T10:57:36Z

⚠️Micha: Added one additional item under hydrology

''If you wish to use both GRASS GIS and ArcGIS together, this page is for you.''

== Working with your ArcGIS data ==

=== Importing ArcGIS Data ===

GRASS GIS provides converters for importing ESRI shapefiles, e00 files, and many other GIS formats as well. The key GRASS modules for importing vector formats are {{cmd|v.in.ogr}} (for ESRI Shapefiles, MapInfo files, SDTS, TIGER, etc.) and {{cmd|v.in.e00}} for e00 format. For raster data, there is {{cmd|r.in.gdal}}.

=== Coordinate Reference Systems ===

The GRASS data structure requires that each data layer have its CRS exactly defined. This is done by maintaining data layers within a "[[Location and Mapsets|Location]]". Each Location has a strictly defined projection, and datum, and all the data layers (raster and vector) within that location should already be either created in or projected to that CRS. GRASS does '''not''' do "on-the-fly" reprojection to avoid often encountered in other GIS software with datum mismatches. Consequently, data layers in one location are not visible from other locations. However, GRASS does supply a collection of [[Common_Tasks#GIS_Tasks|tools]] for projecting vector and raster layers from one location to another. Use of these tools is explained in the {{cmd|projectionintro|manual}}.

=== Vector import/export ===

* {{cmd|v.in.ogr}} - Convert [http://www.gdal.org/ogr OGR] supported vector formats to GRASS vector format.
* {{cmd|v.out.ogr}} - Convert from the GRASS vector format to one of the supported OGR vector formats.
* {{cmd|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 {{cmd|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 ====


Shapefiles can only hold one type of data (point, line, polygon) per shapefile.
You can't export a GRASS vector map with both points and areas to a single
shapefile. You'll have to do it in two passes to two different files with
{{cmd|v.out.ogr}} and different "type=" parameters.

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"

==== Various vector operations ====
* Editing differences
: Tips for [[Digitizing_Area_Features|Digitizing area features with attributes]]

=== Raster import/export ===

* {{cmd|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:
*** See the [http://www.gdal.org/frmt_various.html#AIG GDAL help page for AIC]
*** Often the biggest .adf file is the right one to import -- check your data values after importing even if they visually look correct!
r.in.gdal input=/path/to/map/hdr.adf output=map

* {{cmd|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"

==== Import ArcASCII raster grid and connect to database ====

The trick is to convert the raster coverage to vector
areas to take advantage of GRASS's rich vector attribute/database tie-ins. You can use {{cmd|r.in.gdal}} for the import.

# import ArcASCII grid to UTM55S location
r.in.gdal input=aas_z55.asc output=aas_z55
r.colors aas_z55.gdal color=random
r.info aas_z55

# convert to vector areas, using raster value for category
g.region rast=aas_z55
r.to.vect -v in=aas_z55.gdal out=aas_z55 feature=area

# get rid of empty DBF table created by r.to.vect
v.db.droptable aas_z55

# copy real DBF file into $MAPSET/dbf/ directory
eval `g.gisenv`
cp /tmp/au/aas_z55.DBF "$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/aas_z55.dbf"

# connect full DBF database to vector map, use "VALUE" as the key column
v.db.connect map=aas_z55 driver=dbf table=aas_z55 key=value

Done. The data are in GRASS GIS database.

==== Import E00 raster grids ====

* The {{cmd|v.in.e00}} module only handles vector data. You will have to convert raster E00 data into an Arc ASCII grid before importing into GRASS with {{cmd|r.in.gdal}}.
* [http://lists.osgeo.org/pipermail/grass-user/2009-October/052758.html See instructions in this mailing list post] about the "ArcExplorer Import Utility"

== Linking data to GRASS GIS ==

You can link data instead of importing them, use {{cmd|r.external}}, {{cmd|v.external}}, {{cmd|r.external.out}}, and {{cmd|v.external.out}}. Projection of all data must be consistent.

== Various hydrology and terrain analysis commands ==




* Watershed modeling differences:
** ArcInfo wants a depressionless, filled, hydrologically correct DEM.
** {{cmd|r.watershed}} does not need such a DEM, it is happy with a raw DEM even containing depressions, being not filled, and not hydrologically correct (hence, no extra preparations needed!).
* How to [[Creating_watersheds|Create watersheds for specific drainage points]] like the Arc Hydro extension
* See also [[Hydrological Sciences]] for a list of available hydrological GRASS tools
* [http://www.surfaces.co.il/?p=241 Watershed Analysis with GRASS] (when you know ESRI)
* [https://grasswiki.osgeo.org/wiki/Creating_watersheds#Calculating_total_drainage_area_for_each_stream_reach Calculating total upstream area for each stream]

== See also ==

* [[GRASS GIS for ArcGIS users]]
* [[Terminology comparison between ArcGIS and GRASS GIS]]

== External links ==

* Basic [http://geostat-course.org/Topic_NetelerMetz_2012 GRASS GIS tutorial] at Geostat 2012
* [http://www.appropedia.org/A_transition_from_ArcGIS_to_open_source_GIS_softwares A transition from ArcGIS to open source GIS softwares]
* [http://gis.stackexchange.com/questions/134/can-arcgis-and-osgeo4w-share-the-same-python-install Can ArcGIS and OSGeo4W share the same python install?]

[[Category: Documentation]]
[[Category: FAQ]]
[[Category: Hydrology]]
[[Category: Import]]
[[Category: Vector]]
[[Category:ArcGIS]]

Tips for Arc users

2016-02-01T10:56:18Z

⚠️Micha: /* Various hydrology and terrain analysis commands */

''If you wish to use both GRASS GIS and ArcGIS together, this page is for you.''

== Working with your ArcGIS data ==

=== Importing ArcGIS Data ===

GRASS GIS provides converters for importing ESRI shapefiles, e00 files, and many other GIS formats as well. The key GRASS modules for importing vector formats are {{cmd|v.in.ogr}} (for ESRI Shapefiles, MapInfo files, SDTS, TIGER, etc.) and {{cmd|v.in.e00}} for e00 format. For raster data, there is {{cmd|r.in.gdal}}.

=== Coordinate Reference Systems ===

The GRASS data structure requires that each data layer have its CRS exactly defined. This is done by maintaining data layers within a "[[Location and Mapsets|Location]]". Each Location has a strictly defined projection, and datum, and all the data layers (raster and vector) within that location should already be either created in or projected to that CRS. GRASS does '''not''' do "on-the-fly" reprojection to avoid often encountered in other GIS software with datum mismatches. Consequently, data layers in one location are not visible from other locations. However, GRASS does supply a collection of [[Common_Tasks#GIS_Tasks|tools]] for projecting vector and raster layers from one location to another. Use of these tools is explained in the {{cmd|projectionintro|manual}}.

=== Vector import/export ===

* {{cmd|v.in.ogr}} - Convert [http://www.gdal.org/ogr OGR] supported vector formats to GRASS vector format.
* {{cmd|v.out.ogr}} - Convert from the GRASS vector format to one of the supported OGR vector formats.
* {{cmd|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 {{cmd|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 ====


Shapefiles can only hold one type of data (point, line, polygon) per shapefile.
You can't export a GRASS vector map with both points and areas to a single
shapefile. You'll have to do it in two passes to two different files with
{{cmd|v.out.ogr}} and different "type=" parameters.

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"

==== Various vector operations ====
* Editing differences
: Tips for [[Digitizing_Area_Features|Digitizing area features with attributes]]

=== Raster import/export ===

* {{cmd|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:
*** See the [http://www.gdal.org/frmt_various.html#AIG GDAL help page for AIC]
*** Often the biggest .adf file is the right one to import -- check your data values after importing even if they visually look correct!
r.in.gdal input=/path/to/map/hdr.adf output=map

* {{cmd|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"

==== Import ArcASCII raster grid and connect to database ====

The trick is to convert the raster coverage to vector
areas to take advantage of GRASS's rich vector attribute/database tie-ins. You can use {{cmd|r.in.gdal}} for the import.

# import ArcASCII grid to UTM55S location
r.in.gdal input=aas_z55.asc output=aas_z55
r.colors aas_z55.gdal color=random
r.info aas_z55

# convert to vector areas, using raster value for category
g.region rast=aas_z55
r.to.vect -v in=aas_z55.gdal out=aas_z55 feature=area

# get rid of empty DBF table created by r.to.vect
v.db.droptable aas_z55

# copy real DBF file into $MAPSET/dbf/ directory
eval `g.gisenv`
cp /tmp/au/aas_z55.DBF "$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/aas_z55.dbf"

# connect full DBF database to vector map, use "VALUE" as the key column
v.db.connect map=aas_z55 driver=dbf table=aas_z55 key=value

Done. The data are in GRASS GIS database.

==== Import E00 raster grids ====

* The {{cmd|v.in.e00}} module only handles vector data. You will have to convert raster E00 data into an Arc ASCII grid before importing into GRASS with {{cmd|r.in.gdal}}.
* [http://lists.osgeo.org/pipermail/grass-user/2009-October/052758.html See instructions in this mailing list post] about the "ArcExplorer Import Utility"

== Linking data to GRASS GIS ==

You can link data instead of importing them, use {{cmd|r.external}}, {{cmd|v.external}}, {{cmd|r.external.out}}, and {{cmd|v.external.out}}. Projection of all data must be consistent.

== Various hydrology and terrain analysis commands ==




* Watershed modeling differences:
** ArcInfo wants a depressionless, filled, hydrologically correct DEM.
** {{cmd|r.watershed}} does not need such a DEM, it is happy with a raw DEM even containing depressions, being not filled, and not hydrologically correct (hence, no extra preparations needed!).
* How to [[Creating_watersheds|Create watersheds for specific drainage points]] like the Arc Hydro extension
* See also [[Hydrological Sciences]] for a list of available hydrological GRASS tools
* [http://www.surfaces.co.il/?p=241 Watershed Analysis with GRASS] (when you know ESRI)
* [https://grasswiki.osgeo.org/wiki/Creating_watersheds#Calculating_total_drainage_area_for_each_stream_reach | Calculating total upstream area for each stream]

== See also ==

* [[GRASS GIS for ArcGIS users]]
* [[Terminology comparison between ArcGIS and GRASS GIS]]

== External links ==

* Basic [http://geostat-course.org/Topic_NetelerMetz_2012 GRASS GIS tutorial] at Geostat 2012
* [http://www.appropedia.org/A_transition_from_ArcGIS_to_open_source_GIS_softwares A transition from ArcGIS to open source GIS softwares]
* [http://gis.stackexchange.com/questions/134/can-arcgis-and-osgeo4w-share-the-same-python-install Can ArcGIS and OSGeo4W share the same python install?]

[[Category: Documentation]]
[[Category: FAQ]]
[[Category: Hydrology]]
[[Category: Import]]
[[Category: Vector]]
[[Category:ArcGIS]]

Tips for Arc users

2016-02-01T10:53:19Z

⚠️Micha: One additional internal link in hydrology section

''If you wish to use both GRASS GIS and ArcGIS together, this page is for you.''

== Working with your ArcGIS data ==

=== Importing ArcGIS Data ===

GRASS GIS provides converters for importing ESRI shapefiles, e00 files, and many other GIS formats as well. The key GRASS modules for importing vector formats are {{cmd|v.in.ogr}} (for ESRI Shapefiles, MapInfo files, SDTS, TIGER, etc.) and {{cmd|v.in.e00}} for e00 format. For raster data, there is {{cmd|r.in.gdal}}.

=== Coordinate Reference Systems ===

The GRASS data structure requires that each data layer have its CRS exactly defined. This is done by maintaining data layers within a "[[Location and Mapsets|Location]]". Each Location has a strictly defined projection, and datum, and all the data layers (raster and vector) within that location should already be either created in or projected to that CRS. GRASS does '''not''' do "on-the-fly" reprojection to avoid often encountered in other GIS software with datum mismatches. Consequently, data layers in one location are not visible from other locations. However, GRASS does supply a collection of [[Common_Tasks#GIS_Tasks|tools]] for projecting vector and raster layers from one location to another. Use of these tools is explained in the {{cmd|projectionintro|manual}}.

=== Vector import/export ===

* {{cmd|v.in.ogr}} - Convert [http://www.gdal.org/ogr OGR] supported vector formats to GRASS vector format.
* {{cmd|v.out.ogr}} - Convert from the GRASS vector format to one of the supported OGR vector formats.
* {{cmd|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 {{cmd|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 ====


Shapefiles can only hold one type of data (point, line, polygon) per shapefile.
You can't export a GRASS vector map with both points and areas to a single
shapefile. You'll have to do it in two passes to two different files with
{{cmd|v.out.ogr}} and different "type=" parameters.

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"

==== Various vector operations ====
* Editing differences
: Tips for [[Digitizing_Area_Features|Digitizing area features with attributes]]

=== Raster import/export ===

* {{cmd|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:
*** See the [http://www.gdal.org/frmt_various.html#AIG GDAL help page for AIC]
*** Often the biggest .adf file is the right one to import -- check your data values after importing even if they visually look correct!
r.in.gdal input=/path/to/map/hdr.adf output=map

* {{cmd|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"

==== Import ArcASCII raster grid and connect to database ====

The trick is to convert the raster coverage to vector
areas to take advantage of GRASS's rich vector attribute/database tie-ins. You can use {{cmd|r.in.gdal}} for the import.

# import ArcASCII grid to UTM55S location
r.in.gdal input=aas_z55.asc output=aas_z55
r.colors aas_z55.gdal color=random
r.info aas_z55

# convert to vector areas, using raster value for category
g.region rast=aas_z55
r.to.vect -v in=aas_z55.gdal out=aas_z55 feature=area

# get rid of empty DBF table created by r.to.vect
v.db.droptable aas_z55

# copy real DBF file into $MAPSET/dbf/ directory
eval `g.gisenv`
cp /tmp/au/aas_z55.DBF "$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/aas_z55.dbf"

# connect full DBF database to vector map, use "VALUE" as the key column
v.db.connect map=aas_z55 driver=dbf table=aas_z55 key=value

Done. The data are in GRASS GIS database.

==== Import E00 raster grids ====

* The {{cmd|v.in.e00}} module only handles vector data. You will have to convert raster E00 data into an Arc ASCII grid before importing into GRASS with {{cmd|r.in.gdal}}.
* [http://lists.osgeo.org/pipermail/grass-user/2009-October/052758.html See instructions in this mailing list post] about the "ArcExplorer Import Utility"

== Linking data to GRASS GIS ==

You can link data instead of importing them, use {{cmd|r.external}}, {{cmd|v.external}}, {{cmd|r.external.out}}, and {{cmd|v.external.out}}. Projection of all data must be consistent.

== Various hydrology and terrain analysis commands ==




* Watershed modeling differences:
** ArcInfo wants a depressionless, filled, hydrologically correct DEM.
** {{cmd|r.watershed}} does not need such a DEM, it is happy with a raw DEM even containing depressions, being not filled, and not hydrologically correct (hence, no extra preparations needed!).
* How to [[Creating_watersheds|Create watersheds for specific drainage points]] like the Arc Hydro extension
* See also [[Hydrological Sciences]] for a list of available hydrological GRASS tools
* [http://www.surfaces.co.il/?p=241 Watershed Analysis with GRASS] (when you know ESRI)
* [[Calculating_total_drainage_area_for_each_stream_reach | Calculating total upstream area for each stream]]

== See also ==

* [[GRASS GIS for ArcGIS users]]
* [[Terminology comparison between ArcGIS and GRASS GIS]]

== External links ==

* Basic [http://geostat-course.org/Topic_NetelerMetz_2012 GRASS GIS tutorial] at Geostat 2012
* [http://www.appropedia.org/A_transition_from_ArcGIS_to_open_source_GIS_softwares A transition from ArcGIS to open source GIS softwares]
* [http://gis.stackexchange.com/questions/134/can-arcgis-and-osgeo4w-share-the-same-python-install Can ArcGIS and OSGeo4W share the same python install?]

[[Category: Documentation]]
[[Category: FAQ]]
[[Category: Hydrology]]
[[Category: Import]]
[[Category: Vector]]
[[Category:ArcGIS]]

Creating watersheds

2016-01-29T15:16:39Z

⚠️Micha: completed section on calculating total upstream drainage area

Arcview users, needing to delineate watersheds and stream networks, choose the extension called "Arc Hydro" (requires at least Spatial Analyst). This extension introduces the concepts of "Batch Points" and "Adjoint Catchments". Batch points are locations that the user defines as drainage outlets. An adjoint catchment is the collection of all raster cells that drain into one of the batch points. Here we'll demonstrate how to get similar results with GRASS GIS 6.

== Creating watersheds with specific drainage outlets==
As an example, we'll create a set of catchments with their drainage outlets exactly at the points where the streams cross a road. We'll assume our starting data includes an elevation raster called "dem" and a line vector called "roads". We first create the regular hydrology layers.

=== Preparation ===

<source lang="bash">
#set the region to the dem raster, and run the r.watershed module.
g.region -p rast=dem

# threshold in map cells (try 10000 as a start). Note: DEM Sink-filling not needed:
r.watershed elev=dem drain=fdir basin=catch stream=str thresh=<your-threshold>
</source>

So far, pretty straightforward. There's abundant information on {{cmd|r.watershed}}. I'll just mention that the threshold value is the number of cells that will be the minimum catchment size. So if the resolution of our dem raster is, for example, 10x10 meters (each cell=100 sq. meters), then a threshold of 20,000 (=2,000,000 sq. meters) would create catchments of at least 2 sq. kilometers.

=== Display first results ===
When the process finishes we'll have three new raster maps: the flow direction map, the streams and the catchments. Let's see what we've got so far:

<source lang="bash">
#Convert the steams and catchments to vectors
# r.to.vect in=catch out=catchments feature=area # Grass 6
r.to.vect in=catch out=catchments type=area # Grass 7

# the stream raster usually requires thinning
r.thin in=str out=str_thin
# r.to.vect in=str_thin out=streams feature=line # Grass 6
r.to.vect in=str_thin out=streams type=line # Grass 7
r.colors dem col=elevation

# Make a hillshade raster for displaying "3D"
# r.shaded.relief map=dem shade=dem_shade zmult=1.5 # Grass 6
r.relief input=dem output=dem_shade zscale=1.5 # Grass 7

# Now display layers
# d.mon x0 # Grass 6
d.mon start=wx0 # Grass 7
d.his h=dem i=dem_shade
d.vect map=streams color=blue width=3
d.vect map=catchments type=boundary color=red
d.vect roads color=black width=2
</source>

=== Determine drainage points ===
Now we need to find all the points where streams cross roads. The {{cmd|v.overlay}} module does not deal with point vectors (hint: {{cmd|v.select}} does). Instead we use a trick in v.clean. When cleaning a line vector, all points where lines cross and no node exists are considered topological "errors" and can be saved to a new point vector. So by merging the roads and streams vectors, we create a vector with lines (streams) crossing other lines (roads) without a node. Then we run {{cmd|v.clean}}, and we get all those intersection points in a new vector.

<source lang="bash">
# Patch the streams and roads vectors together
v.patch in=streams,roads out=streams_roads
v.clean in=streams_roads out=streams_roads_clean tool=break error=cross_points

#View cross points on display
d.vect cross_points icon=basic/circle color=green size=12

# Save crossing points to a text file
# v.out.ascii in=cross_points out=cross_points.txt format=point fs=space # Grass 6
v.out.ascii in=cross_points out=cross_points.txt format=point layer=-1 separator=space # Grass 7
</source>

=== Looping thru drainage outlet points ===
Once we have the crossing points in a file, we simply run {{cmd|r.water.outlet}} in a loop to create a watershed for each cross point. However the raster result of r.water.outlet has value '1' in each cell that is upstream of the drainage point, and '0' everywhere else. For our purposes, we want to patch the rasters together after running the loop, so we need to have '''null values''' outside of the watersheds, and each watershed must use a '''different value''' in the upstream cells for its drainage point. To achieve these results, we use the r.null module to set '0' value cells to null. Then, we take advantage of the {{cmd|r.reclass}} function to make a reclassed raster with different values for each watershed. Here's how it works for GRASS 6:

<source lang="bash">
i=0 #an iterator to give consecutive names to the new watersheds
while read X Y; do \
i=$(( ${i} + 1 )) \
r.water.outlet drain=fdir east=$X north=$Y basin=tmp_$i \
r.null tmp_$i setnull=0 \
echo 1=$i | r.reclass in=tmp_$i out=tmp_reclass_$i
done < cross_points.txt
echo "Created $i watersheds"
</source>

And here's how it works for GRASS 7:
<source lang="bash">
i=0 #an iterator to give consecutive names to the new watersheds
while read X Y; do
i=$(( ${i} + 1 ))
r.water.outlet --overwrite input=$drain coordinates=$X,$Y output=tmp_$i
r.null tmp_$i setnull=0
echo 1=$i | r.reclass --overwrite in=tmp_$i out=tmp_reclass_$i rules=-
done < cross_points.txt
echo "Created $i watersheds"
</source>

=== Combining watersheds into one patched vector ===
Next we patch together all the reclassed rasters (watersheds), convert to vector and clean the merged watersheds vector.

<source lang="bash">
# r.patch in=`g.mlist rast pattern=tmp_reclass* separator=,` out=wshed_patch # Grass 6
# r.to.vect in=wshed_patch out=wshed_patch feature=area # Grass 6
r.patch in=`g.list raster pattern=tmp_reclass* separator=,` out=wshed_patch # Grass 7
r.to.vect in=wshed_patch out=wshed_patch type=area
# Use v.clean to remove tiny areas (that were a string of single cells in the raster)
v.clean wshed_patch out=wshed_final tool=rmarea thresh=150
</source>

Choose an appropriate threshold value based on your region resolution. With a region resolution of 10, each individual cell will be 100 sqm, so choosing 150 as the threshold for v.clean allows removing these small areas. Additional manual cleaning may be required.

Clean up tmp rasters:

<source lang="bash">
# g.remove rast=`g.mlist pattern=tmp* sep=,` # Grass 6
g.remove -f type=raster name=`g.list raster pattern=tmp* sep=, ` # Grass 7
</source>

Most likely we'll want to calculate the area for each watershed.

<source lang="bash">
# Add a table with a column for area in sq.km.
# v.db.addcol map=wshed_final col="area_sqkm double" # Grass 6
v.db.addcolumn map=wshed_final col="area_sqkm double" # Grass 7

# Use unit=k(ilometers) to get area in sq. km.
v.to.db map=wshed_final option=area col=area_sqkm unit=k
</source>

And finally, we can view the catchments, and their area values (you may use the [[wxGUI]]):

<source lang="bash">
d.vect wshed_final type=boundary,centroid display=shape,attr attrcol=area_sqkm size=0 width=3 color=orange
</source>

=== Calculating total drainage area for each stream reach ===
Some other software, such as the ArcGIS extension "ArcHydro" can calculate the total upstream drainage area flowing through '''each''' stream reach. The same result is achieved in GRASS with a few hydrology modules and a database join.
Begin by rerunning the r.watershed command as in the first section, but adding a flow accumulation raster as the output:

<source lang="bash">
#set the region to the dem raster, and run the r.watershed module.
g.region -p rast=dem
# Choose threshold in map cells (try 10000 as a start). Note: DEM Sink-filling not needed:
r.watershed elev=dem accumulation=facc thresh=<your-threshold>
</source>

Now create a stream vector layer (or use the vector layer created above) with the r.stream.extract module. Then add to the vector attribute table columns for end point coordinates of each section of the stream, and for the flow accumulation area:
<source lang="bash">
r.stream.extract --o elev=dem accum=facc thresh=<your-threshold> stream_vector=streams
v.db.addcolumn streams col="end_x double, end_y double, accum_area double"
v.to.db streams option=end columns="end_x,end_y"
</source>
We now have a stream vector map with the X-Y coordinates of the end point of each section of the stream, and an empty column ready to accept the upstream drainage area. The next step involves exporting the end point coordinates to a point layer, and using the v.what.rast module to get the values at each point from the flow accumulation grid.
<source lang="bash">
v.db.select -c streams column="cat,end_x,end_y" | v.in.ascii --o input=- output=end_points x=2 y=3
v.db.addcolumn end_points column="accum_pixels double, accum_area double"
v.what.rast end_points raster=facc column=accum_pixels
</source>

The following queries the current region setting for the cell resolution. The total number of upstream cells (from the flow accumulation raster) must be multiplied by the cell size in order to get upstream '''area''' in map units. Finally an SQL expression updates the total upstream area to the streams attribute table.
<source lang="bash">
eval `g.region -g`
SQ_M=$(( ${ewres}*${nsres} ))
v.db.update end_points column=accum_area query_col="accum_pixels*${SQ_M}"
db.execute sql="UPDATE streams SET accum_area=(SELECT accum_area FROM end_points where cat=streams.cat)"
</source>
THis leaves the accum_area column populated with values for total upstream drainage area for each stream reach.

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

Creating watersheds

2016-01-29T14:59:28Z

⚠️Micha: Added section to calulate total upstream drainage area for each stream section

Arcview users, needing to delineate watersheds and stream networks, choose the extension called "Arc Hydro" (requires at least Spatial Analyst). This extension introduces the concepts of "Batch Points" and "Adjoint Catchments". Batch points are locations that the user defines as drainage outlets. An adjoint catchment is the collection of all raster cells that drain into one of the batch points. Here we'll demonstrate how to get similar results with GRASS GIS 6.

== Creating watersheds with specific drainage outlets==
As an example, we'll create a set of catchments with their drainage outlets exactly at the points where the streams cross a road. We'll assume our starting data includes an elevation raster called "dem" and a line vector called "roads". We first create the regular hydrology layers.

=== Preparation ===

<source lang="bash">
#set the region to the dem raster, and run the r.watershed module.
g.region -p rast=dem

# threshold in map cells (try 10000 as a start). Note: DEM Sink-filling not needed:
r.watershed elev=dem drain=fdir basin=catch stream=str thresh=<your-threshold>
</source>

So far, pretty straightforward. There's abundant information on {{cmd|r.watershed}}. I'll just mention that the threshold value is the number of cells that will be the minimum catchment size. So if the resolution of our dem raster is, for example, 10x10 meters (each cell=100 sq. meters), then a threshold of 20,000 (=2,000,000 sq. meters) would create catchments of at least 2 sq. kilometers.

=== Display first results ===
When the process finishes we'll have three new raster maps: the flow direction map, the streams and the catchments. Let's see what we've got so far:

<source lang="bash">
#Convert the steams and catchments to vectors
# r.to.vect in=catch out=catchments feature=area # Grass 6
r.to.vect in=catch out=catchments type=area # Grass 7

# the stream raster usually requires thinning
r.thin in=str out=str_thin
# r.to.vect in=str_thin out=streams feature=line # Grass 6
r.to.vect in=str_thin out=streams type=line # Grass 7
r.colors dem col=elevation

# Make a hillshade raster for displaying "3D"
# r.shaded.relief map=dem shade=dem_shade zmult=1.5 # Grass 6
r.relief input=dem output=dem_shade zscale=1.5 # Grass 7

# Now display layers
# d.mon x0 # Grass 6
d.mon start=wx0 # Grass 7
d.his h=dem i=dem_shade
d.vect map=streams color=blue width=3
d.vect map=catchments type=boundary color=red
d.vect roads color=black width=2
</source>

=== Determine drainage points ===
Now we need to find all the points where streams cross roads. The {{cmd|v.overlay}} module does not deal with point vectors (hint: {{cmd|v.select}} does). Instead we use a trick in v.clean. When cleaning a line vector, all points where lines cross and no node exists are considered topological "errors" and can be saved to a new point vector. So by merging the roads and streams vectors, we create a vector with lines (streams) crossing other lines (roads) without a node. Then we run {{cmd|v.clean}}, and we get all those intersection points in a new vector.

<source lang="bash">
# Patch the streams and roads vectors together
v.patch in=streams,roads out=streams_roads
v.clean in=streams_roads out=streams_roads_clean tool=break error=cross_points

#View cross points on display
d.vect cross_points icon=basic/circle color=green size=12

# Save crossing points to a text file
# v.out.ascii in=cross_points out=cross_points.txt format=point fs=space # Grass 6
v.out.ascii in=cross_points out=cross_points.txt format=point layer=-1 separator=space # Grass 7
</source>

=== Looping thru drainage outlet points ===
Once we have the crossing points in a file, we simply run {{cmd|r.water.outlet}} in a loop to create a watershed for each cross point. However the raster result of r.water.outlet has value '1' in each cell that is upstream of the drainage point, and '0' everywhere else. For our purposes, we want to patch the rasters together after running the loop, so we need to have '''null values''' outside of the watersheds, and each watershed must use a '''different value''' in the upstream cells for its drainage point. To achieve these results, we use the r.null module to set '0' value cells to null. Then, we take advantage of the {{cmd|r.reclass}} function to make a reclassed raster with different values for each watershed. Here's how it works for GRASS 6:

<source lang="bash">
i=0 #an iterator to give consecutive names to the new watersheds
while read X Y; do \
i=$(( ${i} + 1 )) \
r.water.outlet drain=fdir east=$X north=$Y basin=tmp_$i \
r.null tmp_$i setnull=0 \
echo 1=$i | r.reclass in=tmp_$i out=tmp_reclass_$i
done < cross_points.txt
echo "Created $i watersheds"
</source>

And here's how it works for GRASS 7:
<source lang="bash">
i=0 #an iterator to give consecutive names to the new watersheds
while read X Y; do
i=$(( ${i} + 1 ))
r.water.outlet --overwrite input=$drain coordinates=$X,$Y output=tmp_$i
r.null tmp_$i setnull=0
echo 1=$i | r.reclass --overwrite in=tmp_$i out=tmp_reclass_$i rules=-
done < cross_points.txt
echo "Created $i watersheds"
</source>

=== Combining watersheds into one patched vector ===
Next we patch together all the reclassed rasters (watersheds), convert to vector and clean the merged watersheds vector.

<source lang="bash">
# r.patch in=`g.mlist rast pattern=tmp_reclass* separator=,` out=wshed_patch # Grass 6
# r.to.vect in=wshed_patch out=wshed_patch feature=area # Grass 6
r.patch in=`g.list raster pattern=tmp_reclass* separator=,` out=wshed_patch # Grass 7
r.to.vect in=wshed_patch out=wshed_patch type=area
# Use v.clean to remove tiny areas (that were a string of single cells in the raster)
v.clean wshed_patch out=wshed_final tool=rmarea thresh=150
</source>

Choose an appropriate threshold value based on your region resolution. With a region resolution of 10, each individual cell will be 100 sqm, so choosing 150 as the threshold for v.clean allows removing these small areas. Additional manual cleaning may be required.

Clean up tmp rasters:

<source lang="bash">
# g.remove rast=`g.mlist pattern=tmp* sep=,` # Grass 6
g.remove -f type=raster name=`g.list raster pattern=tmp* sep=, ` # Grass 7
</source>

Most likely we'll want to calculate the area for each watershed.

<source lang="bash">
# Add a table with a column for area in sq.km.
# v.db.addcol map=wshed_final col="area_sqkm double" # Grass 6
v.db.addcolumn map=wshed_final col="area_sqkm double" # Grass 7

# Use unit=k(ilometers) to get area in sq. km.
v.to.db map=wshed_final option=area col=area_sqkm unit=k
</source>

And finally, we can view the catchments, and their area values (you may use the [[wxGUI]]):

<source lang="bash">
d.vect wshed_final type=boundary,centroid display=shape,attr attrcol=area_sqkm size=0 width=3 color=orange
</source>

=== Calculating total drainage area for each stream reach ===
Some other software, such as the ArcGIS extension "ArcHydro" can calculate the total updtream drainage area flowing through each stream reach. The same result is achieved in GRASS with a few hydrology modules and a database join.
Begin by rerunning the r.watershed command as in the first section, but adding a flow accumulation raster as the output

<source lang="bash">
#set the region to the dem raster, and run the r.watershed module.
g.region -p rast=dem
# threshold in map cells (try 10000 as a start). Note: DEM Sink-filling not needed:
r.watershed elev=dem accumulation=fdir thresh=<your-threshold>
</source>

Now create a stream vector layer (or use the vector layer created above) with the r.stream.extract module. Then add to the vector attribute table columns for end point coordinates of each section of the stream, and for the flow accumulation area:
<source lang="bash">
r.stream.extract --o elev=dem accum=facc thresh=<your-threshold> stream_vector=streams
v.db.addcolumn streams col="end_x double, end_y double, accum_area double"
v.to.db streams option=end columns="end_x,end_y"
</source

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

GRASS GIS for ArcGIS users

2016-01-29T14:36:55Z

⚠️Micha: Further details in the Flow Direction section

''This is a guide for people who want to migrate from ArcGIS to GRASS GIS or just want to learn GRASS GIS and are already familiar with ArcGIS.''

== Projections ==

ArcGIS supports on-the-fly projection of spatial data while GRASS GIS considers this as a bad practice and requires users to have consistent projection information for all the data entering the analysis. This is one of the ways how GRASS GIS helps user to manage the integrity of their data. The other ways are keeping the geospatial data organized and requiring the data to be in a one format, e.g. to store vector data in the GRASS topological format. However, for raster data there is for example the {{cmd|r.external}} module which allows to link (rather than import) and use data in different formats as long as they are in the same projection.

When data are in different projection they can be imported into GRASS GIS using {{cmd|r.import}} and {{cmd|v.import}} modules. When the data are already in another GRASS Location which has different projection than we want, we can create a new Location with the desired projection and bring the data there using {{cmd|r.proj}} and {{cmd|v.proj}}.

== Data, databases and file formats ==

In ArcGIS, users often have data in different directories on disk. Basically all geospatial data for GRASS GIS are in the GRASS GIS database (a folder on a disk or network drive). This database is divided into ''Locations'' and Locations are further divided into ''Mapsets''. When GRASS GIS is started, it connects to database, Location and Mapset as specified by the user.

By this GRASS GIS is able to apply a specific system to organize the data. The system is designed to accommodate large projects and even multiple users in a Location but it is also useful for individuals who just want to keep their data well organized. First, data must be in one directory called GRASS GIS database directory. You can have one or more of these directories on your disk. This directory contains GRASS Locations. All data in one Location have the same projection (coordinate system, datum). A Location is a directory which contains GRASS Mapsets. A Mapset contains raster and vector maps (layers) and other geospatial data.

To avoid unwanted changes in the existing data, GRASS GIS modules handle the creation, modification, change, copying or deletion of those data stored the current Mapset (i.e., in the actually used session). When needed, the data can be copied from other Mapsets into the current Mapset using {{cmd|g.copy}}, for example when one needs to change attributes of a vector map not belonging to him-/herself.

However, the data from the other Mapsets are available for reading, so you can view and use them in the analysis. By default, you see data only in the current Mapset and in a special Mapset called PERMANENT which must be present in every Location. If desired, you can view the data from other Mapsets (in the current Location) using Settings > GRASS working environment > Mapset access or using module {{cmd|g.mapsets}}. Data in other Locations are accessible only if you start GRASS GIS in the given Location. Accessing data from multiple Location wouldn't be safe because the data in different Locations are (or can be) in different projections (while all Mapsets in one Location contains data in one particular projection).

You can also link data from different sources such as GeoTIFF or PostGIS database.

The system used in GRASS GIS results in a state when it is always defined where the new data will be created (the current Mapset). All data are in one projection and in consistent formats. The result is that once the data are imported, one can focus on analysis, not data formats.

Users can select different strategies how to use the database directory, Locations and Mapsets. Often users have one GRASS GIS database directory called <code>grassdata</code>. Then every Location is a bigger project or a area of interest. Mapsets are then smaller projects or individual tasks. PERMANENT Mapset is used to keep common data in one place.

GRASS GIS Location or Mapset are in certain way similar to File Geodatabase or Personal Geodatabase as they store all data inside them in a given format.

== Cartography ==

ArcGIS has two modes of the display, one is a standard one for viewing and and interacting with the data. The other is a layout mode which is a design tool for creation of hardcopy maps. The ''Map Display'' in GRASS GIS main graphical user interface (GUI) is also meant for interaction but it contains basic cartography features as well. Advanced cartography in GRASS GIS is done in separate application (available from GUI) called ''Cartographic Composer'' or {{cmd|g.gui.psmap}} for starting from command line. This application is a GUI frontend for the {{cmd|ps.map}} module. Some GRASS GIS users prefer the standard display because it is convenient and easily scriptable, some users prefer {{cmd|ps.map}} because some other combine the standard display with professional open source graphics editor [https://inkscape.org/ Inkscape], and some others use [http://qgis.org/ QGIS] for high-quality cartography tasks.


The standard display in GRASS GIS is well suited for standard viewing and exploration of geospatial data. It is also usable for creating basic cartography outputs, e.g. for scientific publications, since basic map elements such as scale bar or raster legend can be displayed directly. This functionality is available in the main GUI in ''Map Display'' and is controlled also in ''Layer Manager''. The functionality is also available through command line interface, so for example:

d.rast elevation

will show elevation raster map in the display. Commands like this one can be used either to control the display in GUI, to control independent graphical display, or to automate creation of hardcopy maps. For the last two options {{cmd|d.mon}} module is used. For example,

d.mon wx0

opens a new window which looks like ''Map Display'' in the main GUI but it is mostly controlled by display modules (<code>d.*</code>) such as aforementioned {{cmd|d.rast}}. Additionally, {{cmd|d.mon}} can be used to create images directly, for example the following series of commands will create a PNG image of elevation raster map with streams vector on top of them:

<source lang="bash">
g.region raster=elevation
d.mon start=cairo output=map.png
d.rast map=elevation
d.vect map=streams
d.mon stop=cairo
</source>

This can be rewritten to Python as follows:

<source lang="python">
import grass.script as script
gscript.run_command('g.region', raster='elevation')
gscript.run_command('d.mon', start='cairo', output='map.png')
gscript.run_command('d.rast', map='elevation')
gscript.run_command('d.vect', map='streams')
gscript.run_command('d.mon', stop='cairo')
</source>

When working in command line or a script, one can also take an advantage of {{cmd|d.frame}} module which makes layout of different maps or map elements easier.

Even when not using Python or command line one can still take an advantage of the command line interface because the commands are shown in the GUI, can be copied and then saved or shared for later use. For example, one can set a style in GUI, copy the command and get something like the following line:

d.vect map=streets color=255:165:0 width_column=SPEED width_scale=0.07

This can be easily stored in a text file, shared through email or included in a study material for a class. Later this command can be used directly in GUI to get the layer in exactly same style.

The standard display has its limitation but they can often overcome. For example, lines can only have one color, so when we want to display borders of line with different color we need to show the line twice, once as a thick line with desired border color and once as a little bit thinner line with desired inner color:

d.vect map=streets color=255:204:109 width=4
d.vect map=streets color=255:165:0 width=8

[[File:Vector_lines_roads.png|200px|thumb|right|Line with border created using two {{cmd|d.vect}} commands]]

Some users also often combine standard display with vector graphics applications such as Inkscape because this gives them all power of an actual graphics program. When automating map creation in Python, multiple created images can be combined and further edited using Python imaging package [https://pypi.python.org/pypi/PIL PIL] (or [https://pypi.python.org/pypi/Pillow/ Pillow]) or [http://www.imagemagick.org ImageMagic], a command line image manipulation suite.

== 3D visualization ==

In GRASS GIS, the 3D view is integrated into the main graphical user interface (GUI) while in ArcGIS suite, there is a separate tool ArcScene. The GRASS GIS library which is behind the 3D view is called NVIZ. The integration of NVIZ into GUI which is called wxGUI is called wxNVIZ. The 3D visualization is also available as a module called {{cmd|m.nviz.image}} (usable from command line or Python).


In GRASS GIS, when you are in 2D and you switch to 3D, all raster map layers are automatically added to the 3D view as surfaces. This means that if you have in 2D a digital elevation model, you will see it as a 3D visualization of terrain in 3D. The colors set will be the same colors as in 2D. This is different from ArcScene where the raster layer is initially flat and you have to specify in properties which raster should be used to create the surface.

== Raster algebra ==

Current ArcGIS raster calculator is implemented in Python. Some parts of the syntax resembles Python while some others differ from it. In GRASS GIS the map algebra is available through {{cmd|r.mapcalc}} module (implemented in C) or its convenient GUI wrapper ''Raster Map Calculator''. The {{cmd|r.mapcalc}} syntax is specifically designed for raster map algebra and is based on C syntax (Python is C-like language as well). Both syntaxes are case sensitive as it is common for C-like languages.

=== Quotes ===

In ArcGIS map algebra layer names must be quoted. In GRASS GIS, the quotes are optional and usually not used. There is few cases where it is necessary to use quotes and that is when raster map name contains dashes (which would be interpreted as minus operator). However, best practice is not to use dashes in map names at all (since map name should be ideally also usable without quoting in SQL). When writing Python script and you want it to be really robust. Then you may want to use quoting.

=== Whitespace ===

In ArcGIS map algebra operators must be surrounded by spaces. In GRASS GIS, the spaces around operators are optional, however it is a best practice to use them (same as in Python or C).

=== Operators ===

{| class="wikitable sortable"
|-
! ArcGIS
! GRASS GIS
! Notes
|-
| &
| &&
| Boolean (logical) AND operator is one ampersand (<tt>&</tt>) in ArcGIS. In GRASS GIS, boolean AND operator is two ampersands (<tt>&&</tt>) which is the same as in C. Note that <tt>&</tt> means bitwise AND operator in GRASS GIS (as well as in Python or C). There is also <tt>&&&</tt> in GRASS GIS which doesn't propagate null values (which is the standard behavior) but instead, treats them as false.
|-
| <nowiki>|</nowiki>
| <nowiki>||</nowiki>
| Difference between ArcGIS and GRASS GIS in boolean (logical) OR operator is the same as in the case of boolean AND operator. In GRASS GIS there is bitwise <tt><nowiki>|</nowiki></tt> and boolean (logical) <tt><nowiki>||</nowiki></tt> and <tt><nowiki>|||</nowiki></tt>. The <tt><nowiki>||</nowiki></tt> operator preserves nulls (as expected by default) and the <tt><nowiki>|||</nowiki></tt> operator evaluates null values as false which is often advantageous.
|-
| ~
| !
| In GRASS GIS the boolean NOT operator is (one) exclamation mark (<tt>!</tt>) which is the same as in C. The ArcGIS equivalent is tilde (<tt>~</tt>) while in GRASS GIS tilde is a bitwise NOT operator (one's complement) which is the same meaning as in C or Python.
|-
| ^
| xor()
| A caret (<tt>^</tt>) in ArcGIS means boolean exclusive OR (XOR) operator while in GRASS GIS it means exponentiation (an arithmetic operation). Boolean exclusive OR is done using a function <tt>xor()</tt> in GRASS GIS.
|}

ArcGIS map algebra expression for the Raster Calculator in GUI for computing NDVI (output name is entered separately):

Float("lsat7_40" - "lsat7_30") / Float("lsat7_40" + "lsat7_30")

The same expression in GRASS GIS also for the Raster Calculator in GUI (output name entered separately as well):

float(lsat7_2002_40 - lsat7_2002_30) / float(lsat7_2002_40 + lsat7_2002_30)

Again the same expression but written as a module call for the command line:

r.mapcalc "ndvi = float(lsat7_2002_40 - lsat7_2002_30) / float(lsat7_2002_40 + lsat7_2002_30)"

See list of all available operators in GRASS GIS in {{cmd|r.mapcalc}} manual.

=== Functions ===

{| class="wikitable sortable"
|-
! ArcGIS
! GRASS GIS
! Notes
|-
| Con(a, b, c), Con(a, b, c, d)
| if(a, b, c)
| The most used conditional statement (if-statement) in both ArcGIS and GRASS GIS has raster algebra is a function with three parameters first is the conditional expression (condition), second is value to be used when the condition is fulfilled ("if-part") and third one is the value to be used when the condition is not fulfilled ("else-part"). ArcGIS also supports a syntax with four parameters where the first one is just the raster and the fourth one is SQL conditional expression. GRASS GIS has also a version with four parameters but it is a convenience for the cases where we need to decide among three values based on the the first parameter (raster or expression) being lesser than zero, zero or greater than zero. 
|-
| Con(a, b)
| if(a, b, null())
| In ArcGIS, the expression <tt>Con(a, b)</tt> will return NoData (NULL) if <tt>a</tt> is true (or non-zero). In GRASS GIS, the expression <tt>if(a, b)</tt> would return 0 (a number zero) in this case. So, we explicitly specify the value <tt>null()</tt> for the case when <tt>a</tt> is false (or zero) using third parameter. The general syntax is <tt>if(a, b, c)</tt> and it is the preferred one because it is explicit and thus one doesn't need to remember the special behavior of the other versions when reading the expression.
|-
| SetNull(a, b), SetNull(a, b, c)
| if(a, null(), b)
| ArcGIS function <tt>SetNull</tt> returns NoData (NULL) when first parameter is true. The optional third parameter is SQL query which can be used instead of the expression (the first parameter). The GRASS GIS function for returning NULL when condition is not fulfilled is standard <tt>if</tt> function used with three parameters where second one is <tt>null()</tt>.
|-
| IsNull()
| isnull()
|
|-
| Int()
| int()
|
|-
| Float()
| float(), double()
| GRASS GIS has two floating point numeric types. First is single precision floating point number (float) with corresponding raster map type is FCELL. Second is double precision floating point number (double) with corresponding raster map type is DCELL.
|}

An expression in ArcGIS to use ''landclass'' value when ''landclass'' is 1 or 2 and null (NoData) value otherwise:

Con( ("landclass" == 1) | ("landclass" == 2), "landclass", null())

The same expression rewritten to GRASS GIS map algebra is:

if(landclass == 1 || landclass == 2, landclass, null())

The expression we used assumes usage in GUI. In command line, used in {{cmd|r.mapcalc}} module call, we would start it with the name of the output and the whole expression would be in quotes (as command line requires).

An expression in ArcGIS to use values from ''landclass'' raster when ''lakes'' contains null (NoData) values and use values from ''lakes'' raster otherwise:

Con(IsNull("lakes"), "landclass", "lakes")

The expression now rewritten to GRASS GIS syntax as it would be used in command line:

r.mapcalc "land = if(isnull(lakes), landclass, lakes)"

In this case without the expression are very similar. The difference is lowercase <code>isnull</code>, name <code>Con</code> versus <code>if</code>. For the command line, we add also <code>r.mapcalc "land = </code> at the beginning and a quote (<code>"</code>) at the end.

See list of all available functions in GRASS GIS in {{cmd|r.mapcalc}} manual.

=== Further notes ===

Note that there are different algebras in GRASS GIS, namely it is 3D raster algebra which the same as the standard 2D one with few differences to accommodate 3D rasters and then it is temporal algebra which contains a lot of additional syntax to work with spatio-temporal data. There is also a module supporting vector map algebra in GRASS GIS Addons repository.

== Python interface ==

=== Importing toolboxes and checking a license ===

Python script in ArcGIS need to check whether the given extension is available, i.e. whether the license to use it is OK. In GRASS GIS, all available modules are included in the standard installation, so there is no need for checking if the extension is present or whether we have a license to use it. Consequently, the following doesn't need any equivalent in GRASS GIS:

<source lang=Python>
# check if we have the Spatial Analyst extension license
arcpy.CheckOutExtension("Spatial")
</source>

In ArcGIS, third party tools can be used in a Python script after calling <code>ImportToolbox()</code> function. In GRASS GIS, the 3rd party tools (modules or sets of modules) are typically installed ahead using {{cmd|g.extension}} module. So, the following is usually not done in Python scripts for GRASS GIS:

<source lang=Python>
arcpy.ImportToolbox("d:/toolsdir/sometools.tbx")
</source>

However, any module in GRASS GIS can be called from Python, so if we would like to install some tools or just ensure that they are installed and updated, we can call {{cmd|g.extension}} from Python:

<source lang=Python>
gscript.run_command('g.extension', extension='v.sometool')
</source>

The {{cmd|g.extension}} module can install modules (extension, addons) from different sources. However, the most common source is the official GRASS GIS Addons repository which contains user wide range of contributed modules. See the {{cmd|g.extension}} manual for your version of GRASS GIS for more details.

== Cost analysis ==
Cost surface is defined differently in GRASS GIS and ArcGIS. Cost in GRASS GIS is cost to ''cross a cell'' while in ArcGIS it is cost to ''cross one map unit''. So for example we define cost as time and we have 30 m cells and speed is 5 m/s. Then the cost value of the cell is 6 s in GRASS GIS and 0.2 s in ArcGIS.

== Flow Directions ==
Like the ArcGIS FLOWDIRECTION function, GRASS can also create a flow direction raster, giving each cell an integer value representing one of the eight directions of flow out of the cell. Flow direction in both programs is determined by finding which of the surrounding cells has the lowest elevation value. However, the values that each software uses are different. In ArcGIS, the flow directions are numbered from east clockwise, and each direction is a power of 2 higher than the previous. Thus, when the flow direction is east out of a cell, that cell is given the value 1. When south-east the value is 2. Then, a cell with flow direction going south gets the value 4, and so on until north-east, which becomes 128. (Details of this procedure are presented in [http://resources.arcgis.com/en/help/main/10.1/index.html#//009z00000052000000 the ArcGIS Resources website])

GRASS numbers the flow directions '''counter-clock wise''' with north-east getting the value 1, north is 2, north-west is assigned 3, west becomes 4 and so on until 8 (east). Furthermore, two additional differences between the GRASS implementation and the Arc implementation should be pointed out.
* What happens when two or more surrounding cells have the same elevation, and flow direction is ambiguous? GRASS uses a Least Cost Path searching algorithm to "look ahead" beyond the adjacent surrounding cells, to find the overall trend. This process gives more realistic results in flat areas. Similarly the GRASS procedure deals well with sinks, without requiring a "Fill Sinks" pre-processing step. ArcGIS on the other hand requires a DEM with no sinks, and cells with ambiguous flow direction are given a value as the sum of the ambiguous directions.
* What happens at the region edge when flow direction goes "off the map"? In this case GRASS chooses a flow direction but sets its value as negative. ArcGIS does not indicate in any special way that the flow goes out of the region. (Although there is a flag in the ArcGIS function to force edge cells to flow off the map)

Suppose you need to convert a GRASS flow direction raster to the ArcGIS numbering scheme. This is achieved simply by defining a table of reclass values, and running the GRASS <nowiki>r.reclass module</nowiki>. Here's the reclass table:
{| class="wikitable"
|-
|-
| 1 -1 || = 128
|-
| 2 -2 || =64
|-
| 3 -3 || =32
|-
| 4 -4 || =16
|-
| 5 -5 || =8
|-
| 6 -6 || =4
|-
| 7 -7 || =2
|-
| 8 -8 || =1
|-
| 0 || =255
|}
(Described more fully in [http://www.surfaces.co.il/flow-direction-from-grass-to-arcgis/ Flow Directions from GRASS to ArcGIS])

== See also ==

* [[Terminology comparison between ArcGIS and GRASS GIS]]
* [[Tips for Arc users]]
* [[GRASS migration hints]]
* [[Performance comparison GRASS vs. ArcGIS]]

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

Case studies

2014-03-14T12:04:55Z

⚠️Micha: Corrected links to QGIS case studies site

== GRASS GIS Case Studies ==

''You are kindly invited to write up a few lines about your experience!''

=== List of Case Studies ===

* [[Case_studies/GlobalChangeBiology | Assessing the invasiveness of exotic species using ecosystem models and GRASS GIS]] by Luigi Ponti
* [[Population_Genetics_and_GIS | Applying population genetics and GIS to create migration corridors for New World screw-worm]]

=== List of external Case Studies ===

* [http://pages.swcp.com/~russo/080103/ Using GRASS GIS to analyze cell phone information from mission 080103] by Dave Sampson
* [http://qgis.org/en/site/about/case_studies/portugal_ribeira.html QGIS and GRASS for modelling ecological corridors for wolves in North Portugal] by Monica Almeida
* [http://qgis.org/en/site/about/case_studies/australia_queens.html QGIS and GRASS in Local Government Bushfire Hazard Mapping] by Nathan Woodrow
* [http://qgis.org/en/site/about/case_studies/portugal_torres.html QGIS and GRASS applied to paleontological survey in Western Portugal] by André Mano
* [http://qgis.org/en/site/about/case_studies/portugal_evora.html Quantum GIS and GRASS in Biogeographical Research in Spain] by Marcia Barbosa

[[Category:Applications]]

Compile and Install

2013-02-13T10:54:07Z

⚠️Micha: /* CentOS */

'''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 [http://grass.osgeo.org/download/ here], otherwise read on...

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

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

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

For detailed information on compilation, please see the [http://grass.osgeo.org/grass64/source/INSTALL INSTALL] file in the source code.

=== Prerequisites ===

GRASS needs at least two extra libraries: PROJ and GDAL/OGR

''Note: if you want to have DBMS support in GDAL (subsequently in GRASS) you have to perform the "Optional" steps below as well.''

* [http://trac.osgeo.org/proj/ PROJ4] for management of projections (with proj-datumgrid-1.3.zip support)
* Optional: [http://trac.osgeo.org/geos/ GEOS]
* Optional: [http://www.postgresql.org PostgreSQL], [http://www.mysql.org mySQL], [http://www.unixodbc.org unixODBC], [http://www.sqlite.org SQLite] (SQLite is needed for [[QGIS]])
* [http://www.gdal.org GDAL/OGR] for reading and writing various GIS data formats (interoperability)

You have to install these two libraries '''first''' (see below how to get them precompiled for your system).

It is easiest to obtain a prepackaged version of these libraries (e.g., .rpm; .deb) for your particular operating system and run the corresponding package installation (e.g., rpm -Uhv packagename.rpm; apt-get) in a terminal window. Take care to also install the development packages of these libraries (...-devel packages). If there is no prepackage version, then you will have to download the source code (see links above, source code packages usually ends in .tar.gz or .zip) and compile it (you must have a C compiler installed as part of your operating system). The Web sites show the steps to compile the libraries.

Other libraries needed to run GRASS are listed on the {{website|grass64/source/REQUIREMENTS.html|requirements page}}.

To compile, you will also need the respective "-devel" packages.

Then [http://grass.osgeo.org/download/index.php#g64x download the GRASS GIS source code] of course.

=== 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 grass6'
su -c 'chown yourlogin:yourgroup grass6'

Otherwise if you have permissions just continue as a normal user:
cd /usr/local/src/
svn checkout ...

* do a code checkout from the SVN source code repository
: checkout the latest GRASS 6.x from SVN (see: {{twiki|DownloadSource}})

* in the grass6 directory, you will find the precious INSTALL file, open it with your favourite pager/editor and read it carefully!

* 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-postgres-libs=/usr/include/pgsql/libpq \
--with-postgres-includes=/usr/include/pgsql \
--with-freetype \
--with-freetype-includes=/usr/include/freetype2 \
--with-motif \
--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: i686-pc-linux-gnu

Source directory: /usr/src/grass6
Build directory: /usr/src/grass6
Installation directory: /usr/local/grass-6.3.svn
Startup script in directory: ${exec_prefix}/bin
C compiler: gcc -g -O2
C++ compiler: c++ -g -O2
FORTRAN compiler:
Building shared libraries: yes
64bit support: no

NVIZ: yes

BLAS support: no
C++ support: yes
DWG support: no
FFMPEG support: no
FFTW support: yes
FreeType support: yes
GDAL support: yes
GLw support: no
LAPACK support: no
Large File Support (LFS): no
Motif support: no
MySQL support: no
NLS support: no
ODBC support: no
OGR support: yes
OpenGL(R) support: yes
PNG support: yes
PostgreSQL support: yes
Readline support: no
SQLite support: no
Tcl/Tk support: yes
TIFF support: yes
X11 support: yes

* Let's compile it (takes a little while...)!
make
* 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: Ne kvě 28 13:18:43 CEST 2006
--
Errors in:
--
Finished compilation: Ne kvě 28 13:43:40 CEST 2006
(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 occuring 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:
grass64

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

===== Debian =====

Read the instructions here:
: http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/debian/README.debian

# first install PROJ, GDAL, etc.
cd grass64/
# follow instructions in debian/README.debian
fakeroot buildpackage

* Official [http://wiki.debian.org/DebianGis DebianGIS] packaging [http://svn.debian.org/viewsvn/pkg-grass/packages/grass/ control files], also accessible via svn:

svn co svn://svn.debian.org/svn/pkg-grass/packages/grass/trunk/

or

svn co svn://svn.debian.org/svn/pkg-grass/packages/grass/branches/<GRASS Version>

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

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

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-1.6.0 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 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:

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

===== Ubuntu =====

''The above Debian notes will probably work with Ubuntu as well.''

A more [[Compile_and_Install_Ubuntu | specific page]] towards Ubuntu is being written on.

====== Ubuntu 6.06, 7.10 ======

* [http://david.p.finlayson.googlepages.com/makegrass.sh makegrass.sh] is script designed to automate most of the download, configuration and compilation of GRASS 6.x-CVS
** it is advised use [https://help.ubuntu.com/community/CheckInstall checkinstall] (''sudo apt-get install checkinstall'') instead of ''make install'' to keep track of installed software
** Think twice before using this script. Some users experienced problems such as disabled XGL etc.
* [[User:Steko/Automated_CVS_compiling|Here]] is another of these scripts, it's homemade so probably you'll find the above more useful for production sites.

====== Ubuntu 7.10 64-bit ======

* Compiling latest GRASS source code on a 64-bit machine (with an ATI graphic card) under Ubuntu 7.10 64-bit with support for: 64-bit, SQLite, OpenGL, PYTHON, FFMPEG
(Based on "Ubuntu 6.06 LTS - GRASS 6.1 Compilation Script" by David Finlayson)
''Assuming it is the first time attempting to compile GRASS' source code & installing SVN, PROJ, GDAL/OGR''

'''Preparation'''
sudo apt-get update && sudo apt-get upgrade

* install dependencies for compiling (in general) and dependencies for GRASS: PROJ, GDAL/OGR
sudo apt-get install grass build-essential flex bison libncurses5-dev zlib1g-dev \
libgdal1-dev libtiff4-dev libgcc1 libpng12-dev tcl8.4-dev tk8.4-dev fftw3-dev \
libfreetype6-dev libavcodec-dev libxmu-dev gdal-bin libreadline5 libreadline5-dev \
make python-dev python-wxversion

* install SQLite
sudo apt-get install sqlite3 libsqlite3-dev

* install SVN
sudo apt-get install subversion

* create a directory as a simple user where source code(s) are going to be stored (in our example we use a directory called '''src''' under '''/usr/local''')

sudo mkdir /usr/local/src

* grant rwx (read-write-execute) permissions for our userid/ groupid on the directory (replace words userid and groupid with real userid):
sudo chown ''userid'':''groupid'' /usr/local/src

sudo chmod ug+rwx /usr/local/src

* download latest source code from GRASS SVN repository in a directory on the system (e.g. /usr/local/src)
svn checkout https://svn.osgeo.org/grass/grass/trunk grass_trunk

* Above command places GRASS' source code in '''/usr/local/src/grass_trunk'''. In case of a subsequent update use the command: '''svn up''' from within the grass_trunk directory

----
'''Before''' attempting to compile GRASS, READ section (C) in the '''INSTALL''' file located in the main directory of GRASS source code entitled:
'''(C) COMPILATION NOTES for 64bit platforms'''
----

* installing FFTW3 if not already on system
sudo apt-get install fftw3 fftw3-dev

'''FFMPEG'''

Note: Back in Ubuntu 7.10, installing ffmpeg through the repositories wouldn't work with grass. The following steps were successfully used.

* install FFMPEG (information taken from: http://stream0.org/2008/01/install-ffmpeg-on-ubuntu-gutsy.html)
* download source code with svn
svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg

* install dependencies
sudo apt-get install liblame-dev libfaad2-dev libfaac-dev libxvidcore4-dev \
liba52-0.7.4 liba52-0.7.4-dev libx264-dev libdts-dev checkinstall \
build-essential subversion

* guide to ffmpeg directory
cd ffmpeg

if necessary: '''make distclean''' before configuration (look at notes below)

* configuration ('''note:''' the configuration parameter "'''--enable-pp'''" does not work anymore)
# configure FFMPEG
./configure --enable-gpl --enable-libvorbis --enable-libtheora \
--enable-liba52 --enable-libdc1394 --enable-libgsm \
--enable-libmp3lame --enable-libfaad --enable-libfaac \
--enable-libxvid --enable-pthreads --enable-libx264 \
--enable-shared

* compilation
make

* installation on /usr/local/bin -- important to remember when configuring GRASS' source code for compilation
sudo checkinstall

'''Go for GRASS!'''
* in our example we used the /usr/local/src directory to store GRASS' source code, so:
cd /usr/local/src/grass_trunk

* configuration
CFLAGS="-g -Wall" ./configure --enable-64bit \
--with-libs=/usr/lib64 --with-cxx --with-freetype=yes \
--with-postgres=no --with-sqlite=yes --enable-largefile=yes \
--with-tcltk-includes=/usr/include/tcl8.4 \
--with-freetype-includes=/usr/include/freetype2 \
--with-opengl-libs=/usr/include/GL --with-readline \
--with-python=yes --with-ffmpeg=yes \
--with-ffmpeg-includes=/usr/local/include/ffmpeg

*if OpenGL fails then maybe it is necessary to link '''glxATI.h''' with '''glx.h''' and re-run the configuration

cd /usr/include/GL

sudo ln glxATI.h glx.h

* compilation
make

* compilation is expected to end with a statement similar to the following:

Started compilation: Wed Feb 27 00:24:36 CET 2008
--
Errors in:
No errors detected.

* installation
sudo checkinstall

* launch 64-bit GRASS.6.4.svn
grass64

'''Notes'''
* in case of errors in future compilation attempts, remember to remove program binaries with
make clean
* and the files created with the "configuration" from previous compilations with
make distclean

====== Ubuntu 8.04 and above ======

* See [[Compile and Install Ubuntu‎]]

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

===== CentOS =====

Note: CentOS 5 comes with Python 2.4 which lacks python-config, hence two extra tweaks are needed.

Preparation:
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

Compile and install [http://proj.osgeo.org PROJ4]:

# get source code and unpack:
wget http://download.osgeo.org/proj/proj-4.7.0.tar.gz
tar xvfz proj-4.7.0.tar.gz
rm -f proj-4.7.0.tar.gz
cd proj-4.7.0/

# get and install datum files into right directory:
cd nad/
wget http://download.osgeo.org/proj/proj-datumgrid-1.5.zip
unzip proj-datumgrid-1.5.zip
rm -f proj-datumgrid-1.5.zip
cd ..

# configure and compile
sh configure
make -j4

# install (may require "root" permissions, use "su"):
make install

Compile and install [http://www.gdal.org GDAL]:
# get source code and unpack:
wget http://download.osgeo.org/gdal/gdal-1.6.3.tar.gz
tar xvfz gdal-1.6.3.tar.gz
rm -f gdal-1.6.3.tar.gz
cd gdal-1.6.3/

# configure and compile
sh configure
make -j4

# install (may require "root" permissions, use "su"):
make install

# add /usr/local/lib/ to LD_LIBRARY_PATH, requires "root" permissions:
su -
echo "/usr/local/lib" > /etc/ld.so.conf.d/gdal.conf
ldconfig
exit

# test installation by running
gdalinfo

GRASS 7 compilation and installation, here 64bit example:

1. Download wxGTP and wxPython:

wget http://packages.sw.be/wxPython/wxPython-2.8.9.1-1.el5.rf.x86_64.rpm
wget http://packages.sw.be/wxPython/wxPython-devel-2.8.9.1-1.el5.rf.x86_64.rpm
wget http://packages.sw.be/wxGTK/wxGTK-2.8.9-1.el5.rf.x86_64.rpm
wget http://packages.sw.be/wxGTK/wxGTK-devel-2.8.9-1.el5.rf.x86_64.rpm

# Install:
rpm -Uhv wxPython-2.8.9.1-1.el5.rf.x86_64.rpm wxPython-devel-2.8.9.1-1.el5.rf.x86_64.rpm \
wxGTK-2.8.9-1.el5.rf.x86_64.rpm wxGTK-devel-2.8.9-1.el5.rf.x86_64.rpm

2. Also required is the python library python-dateutil. As root user run:

yum install python-dateutil

3. [http://grass.osgeo.org/download/ Download] and configure GRASS 7 (suggestion: save this as script). Note that [http://proj.osgeo.org PROJ4] and [http://www.gdal.org GDAL] must be compiled first:

./configure \
--with-libs=/usr/lib64 \
--with-cxx \
--without-ffmpeg \
--with-gdal=/usr/local/bin/gdal-config \
--without-odbc \
--with-sqlite \
--with-postgres \
--without-mysql \
--with-nls \
--with-python \
--with-cairo \
--with-wxwidgets=/usr/bin/wx-config \
--without-fftw \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--enable-largefile \
--with-pthread

4. Add manually the path to the python include directory since python-config isn't there:

# edit include/Make/Platform.make
# and add manually the line

PYTHONINC = -I/usr/include/python2.4

5. Compile
make
or on multicore (number depends of available cores):
make -j4

6. Either install with "make install" (as root user) or run directly from compile directory (substitute ARCH with i586 or x86_64):

bin.$ARCH/grass70 -wx

===== Gentoo =====

See http://gentoo-portage.com/sci-geosciences/grass

===== Fedora =====

'''Preparation''' for the compilation of GRASS GIS source code:

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

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

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

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-wxwidgets=/usr/bin/wx-config \
--with-fftw \
--with-python=/usr/bin/python-config \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--enable-largefile \
--without-odbc

An effective (but not fast) way of getting dependencies is to decide what to enable in the configuration, and then run ./config and see which files are missing. The package providing it can be found via:

yum provides */<name of the file>

and then install them with your favourite package manager frontend or yum itself.

Finally '''compile''' the configured source code:
make
or on multicore (number depends of available cores):
make -j4

If you want also '''FFMPEG''' support:

It requires 'yum install fftw-devel'. Then add to the configuration:

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

===== RPM SPEC files =====
* ... can be found in the source code, rpm/ directory,
* or [https://build.opensuse.org/package/show?package=grass&project=Application%3AGeo OpenSuSe]
* or [https://admin.fedoraproject.org/pkgdb/acls/name/grass Fedora]
* or [http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/grass/ Mandriva] (there are also [http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/proj/ proj4], [http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/geos/ geos], [http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/gdal/ gdal], [http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/gdal-grass/ gdal-grass-plugin], [http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/qgis/ qgis] etc)

===== Zaurus =====

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

==== Mac OSX ====

* see the source/macosx readme
* also see [[Compiling on MacOSX]]
* some notes on [[Packaging on MacOSX]]
* Download [http://www.kyngchaos.com/software/frameworks#build_scripts build scripts]

==== Solaris ====

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

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

* ''see [http://thread.gmane.org/gmane.comp.gis.grass.user/32667 this mailing list thread]''

Mike wrote:
<pre>
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:

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>

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

=== Compiled C modules ===

'''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/

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

Population Genetics and GIS

2012-12-04T09:31:49Z

⚠️Micha: /* Background */

= Applying Population Genetics, Habitat Suitability Modeling and GIS to create predicted migration corridors for New World Screw-worm =

== Background ==
New world Screw-worm ''Cochliomyia hominivorax'' (NWS) is a well known insect pest in South and North America, causing extensive damage to livestock. The females lay eggs into small wounds in warm-blooded vertebrates and the larvae then burrow into the tissue. This injury, known as myasis, weakens the animal, lowers production, and sometimes is severe enough to lead to death of the animal. The "cousin" of NWS, the Old World Screw-worm ''Chrysomya bezziana'' (OWS) causes similar effects throughout the Middle East and South East Asia.

Typically these insect pests are treated by spraying the livestock directly with pesticides. However they are an ideal candidate for treatment by Sterile Insect Technique (SIT) in the context of an Area-Wide pest management program. See [http://www-naweb.iaea.org/nafa/ipc/screwworm-flies.html the Joint FAO/IAEA program]. An SIT based program requires releasing huge numbers of sterilized male flies throughout the grazing lands, so that the female flies do not encounter a wild male, thus leading to a substantial reduction in the population within a few generations. The method is cost effective when the treated area actually is infested or potentially can be infested with screw-worm. So a successful SIT treatment plan depends on a good understanding of the distribution and possible migration of the pest. This research attempts to address that very question. By merging population genetics and a species habitat model through the use of GIS tools, a procedure is suggested which leads to a geographic data layer representing possible migration corridors of the insect. These corridors are created by combining genetic distance data with environmental data using GRASS GIS.

== Genetics ==
In this research, we used the pairwise Fst matrix estimated in [http://pubget.com/paper/21485363 Fresia et al. 2011]. (full text availble on request) as the genetic distance between samples from all pairs of locations. A total of 227 mitochondrial haplotypes were identified in 282 individuals collected from 29 locations throughout S. America and grouped into two "geographic groups". From the matrix, those pairs with Fst=0 (genetically identical samples) were retained for further work. This Fst=0 value was chosen based on the dispersal capability of the NWS and can be adjusted in any particular case.

== Habitat Suitability Model ==
The presence only algorithm employed by MaxEnt ( [http://www.cs.princeton.edu/~schapire/maxent/ software for species habitat modeling] ) was used to create a Habitat Suitability Model (HSM). Environmental predictors were chosen from the BioCLIM data, as well as elevation, landcover (the [http://bioval.jrc.ec.europa.eu/products/glc2000/products.php glc2000 dataset] ) and livestock density from the FAO [http://www.fao.org/AG/againfo/resources/en/glw/home.html Gridded Livestock of the World] data layer. The resulting raster showed the habitat suitability of the NWS based on environmental conditions.

== GIS ==
GRASS-GIS was chosen to perform the spatial analyses due to the variety of available modules, and ease of scripting the procedures. The steps to merge the genetic distance data with the HSM are itemized below. The script used is available online [http://www.surfaces.co.il/dl/grass_hsm_lcp.sh here].

Two text files in CSV format were prepared in advance, to be read by the GRASS script:
* A list of the locations, with location code and Lon/Lat coordinates for each location, as "localities.csv"
* A list of the pairs of location codes for which the Fst value was zero, as "Fst_zero.csv"

The procedure is broken into four steps:

===== Read in the HSM raster =====
The HSM raster is '''inverted''' to create a friction raster. This is done simply with r.in.gdal, and an r.mapcalc expression:

<code>
r.in.gdal in=hsm.tiff out=hsm
g.region -p rast=hsm
r.mapcalc friction="1.0-hsm"
</code>

===== Create cost maps for each of the locations based on the friction raster =====
The GRASS module r.cost was run in a loop, reading each location code, and its coordinates from the localities.csv ASCII text file. The code run in each cycle of the loop consisted of:

<code>
r.cost --verbose --overwrite input=friction out=cost_"$code" coord="$lon,$lat";
</code>

By looping through all the locations, cost rasters were created which represent the difficulty, or cost (from the friction map) to reach each of the locations from any other pixel in the region. This "difficulty" is drawn from the original environmental layers as represented in the habitiat suitability model. In the resulting cost raster, pixels with a low value are those where is would be "easy" for an insect to migrate to the given location. Pixels with a high value represent locations to which it's unlikely that an insect would migrate.

===== Combine the cost rasters =====
Matrix addition was used to combine two cost rasters, while considering only those pairs of locations for which the genetic distance was close (Fst = 0). The script loops through pairs of locations read from the Fst_zero.csv ASCII text file. In addition to adding the rasters, the result was used to create a '''reclassed''' raster as follows:

* The minimum value from the combined raster is given value 3.
* Values up to 2% higher than the minimum are given value 2
* Values from 2% to 5% higher than the minimum are given value 1
* all other values are set to null

This new reclass raster essentially created a least cost path (LCP), or corridor between pairs of locations. This LCP corridor merges the environmental connectivity, and the genetic distance between locations. A LCP raster was created for each pair of points with the following code:

<code>
r.mapcalc corridor_"$loc1"_"$loc2"="round(cost_"$loc1" + cost_"$loc2")"
<nowiki># Save variables for reclass from r.univar</nowiki>
min=`r.univar -g corridor_"$loc1"_"$loc2" | grep min | cut -d= -f2`
two_percent=`echo $min*1.02/1 | bc`
five_percent=`echo $min*1.05/1 | bc`
<nowiki> # Create the reclass rules file for a specific pair of locations </nowiki>
cat << EOF > "$loc1"_"$loc2"_rules.txt
$min = 3 Minimum
$min thru $two_percent = 2 Two percent
$two_percent thru $five_percent = 1 Five percent
<nowiki>* = NULL NULL</nowiki>
end
EOF
<nowiki># Create the reclass raster for a specific pair using the new reclass rules file</nowiki>
r.reclass --overwrite input=corridor_"$loc1"_"$loc2" output=lcp_"$loc1"_"$loc2" rule="$loc1"_"$loc2"_rules.txt title="$loc1 - $loc2 Least Cost Path"
</code>

===== Finally merge all reclass rasters =====
An overall LCP raster for the whole region was then created by summing all the reclass maps, thus showing possible migration corridors.

<code>
lcp_maps=`g.mlist type=rast pattern="lcp*" separator=,`
r.series --overwrite input=$lcp_maps output=lcp_merged method=sum
</code>

===== Samples =====
Below are two sample maps of HSM and resulting LCP predicted migration corridors.

[[File:HSM.jpg|border|450px|left|Map 1]]
[[File:Corridors.jpg|border|450px|right|Map 2]]
 
''Map 1:'' the HSM for New World Screw-worm in S. America

''Map 2:'' the resulting predicted migration corridors

== Discussion ==
The corridor map above, and similar results, show good correlation with the accepted understanding of NSW migration in South America. This match between assumed movement of the insect, and the resulting corridor map increases our confidence in the validity of the procedure. Furthermore, each of the three components of the method outlined above - genetic differentiation, habitat suitability, and least cost path analysis - is flexible. Many adjustments can be applied to adapt the procedure to differing circumstances and other species. We hope therefore that other researchers will adopt the method, and report similar encouraging results.

Regarding NWS and OWS, we believe that this technique could become an integral part of any Area-Wide treatment program, employing SIT to reduce the insect population while avoiding repeated pesticide applications. Infestation can be reduced dramatically, improving livestock production, and allowing expansion of herds into new grazing areas without concern for renewed screw-worm attacks. An analysis of migration corridors will ensure efficient and effective use of SIT, making it a viable as well as safe tool for fighting myasis.

==== Authors ====
:: Pablo Fresia, pfresia at gmail com
:: Micha Silver, micha at arava co il

[[Category: Case Studies]]

Population Genetics and GIS

2012-12-03T19:20:50Z

⚠️Micha: /* Create cost maps for each of the locations based on the friction raster */

= Applying Population Genetics, Habitat Suitability Modeling and GIS to create predicted migration corridors for New World Screw-worm =

== Background ==
New world Screw-worm ''Cochliomyia hominivorax'' (NWS) is a well known insect pest in South and North America, causing extensive damage to livestock. The females lay eggs into small wounds in warm-blooded vertebrate and the larvae then burrow into the tissue. This injury, known as myasis, weakens the animal, lowers production, and sometimes is severe enough to lead to death of the animal. The "cousin" of NWS, the Old World Screw-worm ''Chrysomya bezziana'' (OWS) causes similar effects throughout the Middle East and South East Asia.

Typically these insect pests are treated by spraying the livestock directly with pesticides. However they are an ideal candidate for treatment by Sterile Insect Technique (SIT) in the context of an Area-Wide pest management program. See [http://www-naweb.iaea.org/nafa/ipc/screwworm-flies.html the Joint FAO/IAEA program]. An SIT based program requires releasing huge numbers of sterilized male flies throughout the grazing lands, so that the female flies do not encounter a wild male, thus leading to a substantial reduction in the population within a few generations. The method is cost effective when the treated area actually is infested or potentially can be infested with screw-worm. So a successful SIT treatment plan depends on a good understanding of the distribution and possible migration of the pest. This research attempts to address that very question. By merging population genetics and a species habitat model through the use of GIS tools, a procedure is suggested which leads to a geographic data layer representing possible migration corridors of the insect. These corridors are created by combining genetic distance data with environmental data using GRASS GIS.

== Genetics ==
In this research, we used the pairwise Fst matrix estimated in [http://pubget.com/paper/21485363 Fresia et al. 2011]. (full text availble on request) as the genetic distance between samples from all pairs of locations. A total of 227 mitochondrial haplotypes were identified in 282 individuals collected from 29 locations throughout S. America and grouped into two "geographic groups". From the matrix, those pairs with Fst=0 (genetically identical samples) were retained for further work. This Fst=0 value was chosen based on the dispersal capability of the NWS and can be adjusted in any particular case.

== Habitat Suitability Model ==
The presence only algorithm employed by MaxEnt ( [http://www.cs.princeton.edu/~schapire/maxent/ software for species habitat modeling] ) was used to create a Habitat Suitability Model (HSM). Environmental predictors were chosen from the BioCLIM data, as well as elevation, landcover (the [http://bioval.jrc.ec.europa.eu/products/glc2000/products.php glc2000 dataset] ) and livestock density from the FAO [http://www.fao.org/AG/againfo/resources/en/glw/home.html Gridded Livestock of the World] data layer. The resulting raster showed the habitat suitability of the NWS based on environmental conditions.

== GIS ==
GRASS-GIS was chosen to perform the spatial analyses due to the variety of available modules, and ease of scripting the procedures. The steps to merge the genetic distance data with the HSM are itemized below. The script used is available online [http://www.surfaces.co.il/dl/grass_hsm_lcp.sh here].

Two text files in CSV format were prepared in advance, to be read by the GRASS script:
* A list of the locations, with location code and Lon/Lat coordinates for each location, as "localities.csv"
* A list of the pairs of location codes for which the Fst value was zero, as "Fst_zero.csv"

The procedure is broken into four steps:

===== Read in the HSM raster =====
The HSM raster is '''inverted''' to create a friction raster. This is done simply with r.in.gdal, and an r.mapcalc expression:

<code>
r.in.gdal in=hsm.tiff out=hsm
g.region -p rast=hsm
r.mapcalc friction="1.0-hsm"
</code>

===== Create cost maps for each of the locations based on the friction raster =====
The GRASS module r.cost was run in a loop, reading each location code, and its coordinates from the localities.csv ASCII text file. The code run in each cycle of the loop consisted of:

<code>
r.cost --verbose --overwrite input=friction out=cost_"$code" coord="$lon,$lat";
</code>

By looping through all the locations, cost rasters were created which represent the difficulty, or cost (from the friction map) to reach each of the locations from any other pixel in the region. This "difficulty" is drawn from the original environmental layers as represented in the habitiat suitability model. In the resulting cost raster, pixels with a low value are those where is would be "easy" for an insect to migrate to the given location. Pixels with a high value represent locations to which it's unlikely that an insect would migrate.

===== Combine the cost rasters =====
Matrix addition was used to combine two cost rasters, while considering only those pairs of locations for which the genetic distance was close (Fst = 0). The script loops through pairs of locations read from the Fst_zero.csv ASCII text file. In addition to adding the rasters, the result was used to create a '''reclassed''' raster as follows:

* The minimum value from the combined raster is given value 3.
* Values up to 2% higher than the minimum are given value 2
* Values from 2% to 5% higher than the minimum are given value 1
* all other values are set to null

This new reclass raster essentially created a least cost path (LCP), or corridor between pairs of locations. This LCP corridor merges the environmental connectivity, and the genetic distance between locations. A LCP raster was created for each pair of points with the following code:

<code>
r.mapcalc corridor_"$loc1"_"$loc2"="round(cost_"$loc1" + cost_"$loc2")"
<nowiki># Save variables for reclass from r.univar</nowiki>
min=`r.univar -g corridor_"$loc1"_"$loc2" | grep min | cut -d= -f2`
two_percent=`echo $min*1.02/1 | bc`
five_percent=`echo $min*1.05/1 | bc`
<nowiki> # Create the reclass rules file for a specific pair of locations </nowiki>
cat << EOF > "$loc1"_"$loc2"_rules.txt
$min = 3 Minimum
$min thru $two_percent = 2 Two percent
$two_percent thru $five_percent = 1 Five percent
<nowiki>* = NULL NULL</nowiki>
end
EOF
<nowiki># Create the reclass raster for a specific pair using the new reclass rules file</nowiki>
r.reclass --overwrite input=corridor_"$loc1"_"$loc2" output=lcp_"$loc1"_"$loc2" rule="$loc1"_"$loc2"_rules.txt title="$loc1 - $loc2 Least Cost Path"
</code>

===== Finally merge all reclass rasters =====
An overall LCP raster for the whole region was then created by summing all the reclass maps, thus showing possible migration corridors.

<code>
lcp_maps=`g.mlist type=rast pattern="lcp*" separator=,`
r.series --overwrite input=$lcp_maps output=lcp_merged method=sum
</code>

===== Samples =====
Below are two sample maps of HSM and resulting LCP predicted migration corridors.

[[File:HSM.jpg|border|450px|left|Map 1]]
[[File:Corridors.jpg|border|450px|right|Map 2]]
 
''Map 1:'' the HSM for New World Screw-worm in S. America

''Map 2:'' the resulting predicted migration corridors

== Discussion ==
The corridor map above, and similar results, show good correlation with the accepted understanding of NSW migration in South America. This match between assumed movement of the insect, and the resulting corridor map increases our confidence in the validity of the procedure. Furthermore, each of the three components of the method outlined above - genetic differentiation, habitat suitability, and least cost path analysis - is flexible. Many adjustments can be applied to adapt the procedure to differing circumstances and other species. We hope therefore that other researchers will adopt the method, and report similar encouraging results.

Regarding NWS and OWS, we believe that this technique could become an integral part of any Area-Wide treatment program, employing SIT to reduce the insect population while avoiding repeated pesticide applications. Infestation can be reduced dramatically, improving livestock production, and allowing expansion of herds into new grazing areas without concern for renewed screw-worm attacks. An analysis of migration corridors will ensure efficient and effective use of SIT, making it a viable as well as safe tool for fighting myasis.

==== Authors ====
:: Pablo Fresia, pfresia at gmail com
:: Micha Silver, micha at arava co il

[[Category: Case Studies]]

Population Genetics and GIS

2012-12-03T19:17:01Z

⚠️Micha: /* Samples */

= Applying Population Genetics, Habitat Suitability Modeling and GIS to create predicted migration corridors for New World Screw-worm =

== Background ==
New world Screw-worm ''Cochliomyia hominivorax'' (NWS) is a well known insect pest in South and North America, causing extensive damage to livestock. The females lay eggs into small wounds in warm-blooded vertebrate and the larvae then burrow into the tissue. This injury, known as myasis, weakens the animal, lowers production, and sometimes is severe enough to lead to death of the animal. The "cousin" of NWS, the Old World Screw-worm ''Chrysomya bezziana'' (OWS) causes similar effects throughout the Middle East and South East Asia.

Typically these insect pests are treated by spraying the livestock directly with pesticides. However they are an ideal candidate for treatment by Sterile Insect Technique (SIT) in the context of an Area-Wide pest management program. See [http://www-naweb.iaea.org/nafa/ipc/screwworm-flies.html the Joint FAO/IAEA program]. An SIT based program requires releasing huge numbers of sterilized male flies throughout the grazing lands, so that the female flies do not encounter a wild male, thus leading to a substantial reduction in the population within a few generations. The method is cost effective when the treated area actually is infested or potentially can be infested with screw-worm. So a successful SIT treatment plan depends on a good understanding of the distribution and possible migration of the pest. This research attempts to address that very question. By merging population genetics and a species habitat model through the use of GIS tools, a procedure is suggested which leads to a geographic data layer representing possible migration corridors of the insect. These corridors are created by combining genetic distance data with environmental data using GRASS GIS.

== Genetics ==
In this research, we used the pairwise Fst matrix estimated in [http://pubget.com/paper/21485363 Fresia et al. 2011]. (full text availble on request) as the genetic distance between samples from all pairs of locations. A total of 227 mitochondrial haplotypes were identified in 282 individuals collected from 29 locations throughout S. America and grouped into two "geographic groups". From the matrix, those pairs with Fst=0 (genetically identical samples) were retained for further work. This Fst=0 value was chosen based on the dispersal capability of the NWS and can be adjusted in any particular case.

== Habitat Suitability Model ==
The presence only algorithm employed by MaxEnt ( [http://www.cs.princeton.edu/~schapire/maxent/ software for species habitat modeling] ) was used to create a Habitat Suitability Model (HSM). Environmental predictors were chosen from the BioCLIM data, as well as elevation, landcover (the [http://bioval.jrc.ec.europa.eu/products/glc2000/products.php glc2000 dataset] ) and livestock density from the FAO [http://www.fao.org/AG/againfo/resources/en/glw/home.html Gridded Livestock of the World] data layer. The resulting raster showed the habitat suitability of the NWS based on environmental conditions.

== GIS ==
GRASS-GIS was chosen to perform the spatial analyses due to the variety of available modules, and ease of scripting the procedures. The steps to merge the genetic distance data with the HSM are itemized below. The script used is available online [http://www.surfaces.co.il/dl/grass_hsm_lcp.sh here].

Two text files in CSV format were prepared in advance, to be read by the GRASS script:
* A list of the locations, with location code and Lon/Lat coordinates for each location, as "localities.csv"
* A list of the pairs of location codes for which the Fst value was zero, as "Fst_zero.csv"

The procedure is broken into four steps:

===== Read in the HSM raster =====
The HSM raster is '''inverted''' to create a friction raster. This is done simply with r.in.gdal, and an r.mapcalc expression:

<code>
r.in.gdal in=hsm.tiff out=hsm
g.region -p rast=hsm
r.mapcalc friction="1.0-hsm"
</code>

===== Create cost maps for each of the locations based on the friction raster =====
The GRASS module r.cost was run in a loop, reading each location code, and its coordinates from the localities.csv ASCII text file. The code run in each cycle of the loop consisted of:

<code>
r.cost --verbose --overwrite input=friction out=cost_"$code" coord="$lon,$lat";
</code>

By looping through all the locations, cost rasters were created which represent the difficulty, or cost (from the friction map) to reach each of the locations from any other pixel in the region. This "difficulty" is drawn from the original environmental layers as represented in the habitiat suitability model. In the resulting cost raster, pixels with a low value are those where is would be "easy" for an insect to migrate to, from the given location. Pixels with a high value represent locations to which it's unlikely that an insect would migrate.

===== Combine the cost rasters =====
Matrix addition was used to combine two cost rasters, while considering only those pairs of locations for which the genetic distance was close (Fst = 0). The script loops through pairs of locations read from the Fst_zero.csv ASCII text file. In addition to adding the rasters, the result was used to create a '''reclassed''' raster as follows:

* The minimum value from the combined raster is given value 3.
* Values up to 2% higher than the minimum are given value 2
* Values from 2% to 5% higher than the minimum are given value 1
* all other values are set to null

This new reclass raster essentially created a least cost path (LCP), or corridor between pairs of locations. This LCP corridor merges the environmental connectivity, and the genetic distance between locations. A LCP raster was created for each pair of points with the following code:

<code>
r.mapcalc corridor_"$loc1"_"$loc2"="round(cost_"$loc1" + cost_"$loc2")"
<nowiki># Save variables for reclass from r.univar</nowiki>
min=`r.univar -g corridor_"$loc1"_"$loc2" | grep min | cut -d= -f2`
two_percent=`echo $min*1.02/1 | bc`
five_percent=`echo $min*1.05/1 | bc`
<nowiki> # Create the reclass rules file for a specific pair of locations </nowiki>
cat << EOF > "$loc1"_"$loc2"_rules.txt
$min = 3 Minimum
$min thru $two_percent = 2 Two percent
$two_percent thru $five_percent = 1 Five percent
<nowiki>* = NULL NULL</nowiki>
end
EOF
<nowiki># Create the reclass raster for a specific pair using the new reclass rules file</nowiki>
r.reclass --overwrite input=corridor_"$loc1"_"$loc2" output=lcp_"$loc1"_"$loc2" rule="$loc1"_"$loc2"_rules.txt title="$loc1 - $loc2 Least Cost Path"
</code>

===== Finally merge all reclass rasters =====
An overall LCP raster for the whole region was then created by summing all the reclass maps, thus showing possible migration corridors.

<code>
lcp_maps=`g.mlist type=rast pattern="lcp*" separator=,`
r.series --overwrite input=$lcp_maps output=lcp_merged method=sum
</code>

===== Samples =====
Below are two sample maps of HSM and resulting LCP predicted migration corridors.

[[File:HSM.jpg|border|450px|left|Map 1]]
[[File:Corridors.jpg|border|450px|right|Map 2]]
 
''Map 1:'' the HSM for New World Screw-worm in S. America

''Map 2:'' the resulting predicted migration corridors

== Discussion ==
The corridor map above, and similar results, show good correlation with the accepted understanding of NSW migration in South America. This match between assumed movement of the insect, and the resulting corridor map increases our confidence in the validity of the procedure. Furthermore, each of the three components of the method outlined above - genetic differentiation, habitat suitability, and least cost path analysis - is flexible. Many adjustments can be applied to adapt the procedure to differing circumstances and other species. We hope therefore that other researchers will adopt the method, and report similar encouraging results.

Regarding NWS and OWS, we believe that this technique could become an integral part of any Area-Wide treatment program, employing SIT to reduce the insect population while avoiding repeated pesticide applications. Infestation can be reduced dramatically, improving livestock production, and allowing expansion of herds into new grazing areas without concern for renewed screw-worm attacks. An analysis of migration corridors will ensure efficient and effective use of SIT, making it a viable as well as safe tool for fighting myasis.

==== Authors ====
:: Pablo Fresia, pfresia at gmail com
:: Micha Silver, micha at arava co il

[[Category: Case Studies]]

Population Genetics and GIS

2012-12-03T19:16:07Z

⚠️Micha: /* Finally merge all reclass rasters */

= Applying Population Genetics, Habitat Suitability Modeling and GIS to create predicted migration corridors for New World Screw-worm =

== Background ==
New world Screw-worm ''Cochliomyia hominivorax'' (NWS) is a well known insect pest in South and North America, causing extensive damage to livestock. The females lay eggs into small wounds in warm-blooded vertebrate and the larvae then burrow into the tissue. This injury, known as myasis, weakens the animal, lowers production, and sometimes is severe enough to lead to death of the animal. The "cousin" of NWS, the Old World Screw-worm ''Chrysomya bezziana'' (OWS) causes similar effects throughout the Middle East and South East Asia.

Typically these insect pests are treated by spraying the livestock directly with pesticides. However they are an ideal candidate for treatment by Sterile Insect Technique (SIT) in the context of an Area-Wide pest management program. See [http://www-naweb.iaea.org/nafa/ipc/screwworm-flies.html the Joint FAO/IAEA program]. An SIT based program requires releasing huge numbers of sterilized male flies throughout the grazing lands, so that the female flies do not encounter a wild male, thus leading to a substantial reduction in the population within a few generations. The method is cost effective when the treated area actually is infested or potentially can be infested with screw-worm. So a successful SIT treatment plan depends on a good understanding of the distribution and possible migration of the pest. This research attempts to address that very question. By merging population genetics and a species habitat model through the use of GIS tools, a procedure is suggested which leads to a geographic data layer representing possible migration corridors of the insect. These corridors are created by combining genetic distance data with environmental data using GRASS GIS.

== Genetics ==
In this research, we used the pairwise Fst matrix estimated in [http://pubget.com/paper/21485363 Fresia et al. 2011]. (full text availble on request) as the genetic distance between samples from all pairs of locations. A total of 227 mitochondrial haplotypes were identified in 282 individuals collected from 29 locations throughout S. America and grouped into two "geographic groups". From the matrix, those pairs with Fst=0 (genetically identical samples) were retained for further work. This Fst=0 value was chosen based on the dispersal capability of the NWS and can be adjusted in any particular case.

== Habitat Suitability Model ==
The presence only algorithm employed by MaxEnt ( [http://www.cs.princeton.edu/~schapire/maxent/ software for species habitat modeling] ) was used to create a Habitat Suitability Model (HSM). Environmental predictors were chosen from the BioCLIM data, as well as elevation, landcover (the [http://bioval.jrc.ec.europa.eu/products/glc2000/products.php glc2000 dataset] ) and livestock density from the FAO [http://www.fao.org/AG/againfo/resources/en/glw/home.html Gridded Livestock of the World] data layer. The resulting raster showed the habitat suitability of the NWS based on environmental conditions.

== GIS ==
GRASS-GIS was chosen to perform the spatial analyses due to the variety of available modules, and ease of scripting the procedures. The steps to merge the genetic distance data with the HSM are itemized below. The script used is available online [http://www.surfaces.co.il/dl/grass_hsm_lcp.sh here].

Two text files in CSV format were prepared in advance, to be read by the GRASS script:
* A list of the locations, with location code and Lon/Lat coordinates for each location, as "localities.csv"
* A list of the pairs of location codes for which the Fst value was zero, as "Fst_zero.csv"

The procedure is broken into four steps:

===== Read in the HSM raster =====
The HSM raster is '''inverted''' to create a friction raster. This is done simply with r.in.gdal, and an r.mapcalc expression:

<code>
r.in.gdal in=hsm.tiff out=hsm
g.region -p rast=hsm
r.mapcalc friction="1.0-hsm"
</code>

===== Create cost maps for each of the locations based on the friction raster =====
The GRASS module r.cost was run in a loop, reading each location code, and its coordinates from the localities.csv ASCII text file. The code run in each cycle of the loop consisted of:

<code>
r.cost --verbose --overwrite input=friction out=cost_"$code" coord="$lon,$lat";
</code>

By looping through all the locations, cost rasters were created which represent the difficulty, or cost (from the friction map) to reach each of the locations from any other pixel in the region. This "difficulty" is drawn from the original environmental layers as represented in the habitiat suitability model. In the resulting cost raster, pixels with a low value are those where is would be "easy" for an insect to migrate to, from the given location. Pixels with a high value represent locations to which it's unlikely that an insect would migrate.

===== Combine the cost rasters =====
Matrix addition was used to combine two cost rasters, while considering only those pairs of locations for which the genetic distance was close (Fst = 0). The script loops through pairs of locations read from the Fst_zero.csv ASCII text file. In addition to adding the rasters, the result was used to create a '''reclassed''' raster as follows:

* The minimum value from the combined raster is given value 3.
* Values up to 2% higher than the minimum are given value 2
* Values from 2% to 5% higher than the minimum are given value 1
* all other values are set to null

This new reclass raster essentially created a least cost path (LCP), or corridor between pairs of locations. This LCP corridor merges the environmental connectivity, and the genetic distance between locations. A LCP raster was created for each pair of points with the following code:

<code>
r.mapcalc corridor_"$loc1"_"$loc2"="round(cost_"$loc1" + cost_"$loc2")"
<nowiki># Save variables for reclass from r.univar</nowiki>
min=`r.univar -g corridor_"$loc1"_"$loc2" | grep min | cut -d= -f2`
two_percent=`echo $min*1.02/1 | bc`
five_percent=`echo $min*1.05/1 | bc`
<nowiki> # Create the reclass rules file for a specific pair of locations </nowiki>
cat << EOF > "$loc1"_"$loc2"_rules.txt
$min = 3 Minimum
$min thru $two_percent = 2 Two percent
$two_percent thru $five_percent = 1 Five percent
<nowiki>* = NULL NULL</nowiki>
end
EOF
<nowiki># Create the reclass raster for a specific pair using the new reclass rules file</nowiki>
r.reclass --overwrite input=corridor_"$loc1"_"$loc2" output=lcp_"$loc1"_"$loc2" rule="$loc1"_"$loc2"_rules.txt title="$loc1 - $loc2 Least Cost Path"
</code>

===== Finally merge all reclass rasters =====
An overall LCP raster for the whole region was then created by summing all the reclass maps, thus showing possible migration corridors.

<code>
lcp_maps=`g.mlist type=rast pattern="lcp*" separator=,`
r.series --overwrite input=$lcp_maps output=lcp_merged method=sum
</code>

===== Samples =====
Here are two sample maps of HSM and LCP corridors.resulting predicted migration corridors.

[[File:HSM.jpg|border|450px|left|Map 1]]
[[File:Corridors.jpg|border|450px|right|Map 2]]
 
''Map 1:'' the HSM for New World Screw-worm in S. America

''Map 2:'' the resulting predicted migration corridors

== Discussion ==
The corridor map above, and similar results, show good correlation with the accepted understanding of NSW migration in South America. This match between assumed movement of the insect, and the resulting corridor map increases our confidence in the validity of the procedure. Furthermore, each of the three components of the method outlined above - genetic differentiation, habitat suitability, and least cost path analysis - is flexible. Many adjustments can be applied to adapt the procedure to differing circumstances and other species. We hope therefore that other researchers will adopt the method, and report similar encouraging results.

Regarding NWS and OWS, we believe that this technique could become an integral part of any Area-Wide treatment program, employing SIT to reduce the insect population while avoiding repeated pesticide applications. Infestation can be reduced dramatically, improving livestock production, and allowing expansion of herds into new grazing areas without concern for renewed screw-worm attacks. An analysis of migration corridors will ensure efficient and effective use of SIT, making it a viable as well as safe tool for fighting myasis.

==== Authors ====
:: Pablo Fresia, pfresia at gmail com
:: Micha Silver, micha at arava co il

[[Category: Case Studies]]

Population Genetics and GIS

2012-12-03T19:15:15Z

⚠️Micha: /* Combine the cost rasters */

= Applying Population Genetics, Habitat Suitability Modeling and GIS to create predicted migration corridors for New World Screw-worm =

== Background ==
New world Screw-worm ''Cochliomyia hominivorax'' (NWS) is a well known insect pest in South and North America, causing extensive damage to livestock. The females lay eggs into small wounds in warm-blooded vertebrate and the larvae then burrow into the tissue. This injury, known as myasis, weakens the animal, lowers production, and sometimes is severe enough to lead to death of the animal. The "cousin" of NWS, the Old World Screw-worm ''Chrysomya bezziana'' (OWS) causes similar effects throughout the Middle East and South East Asia.

Typically these insect pests are treated by spraying the livestock directly with pesticides. However they are an ideal candidate for treatment by Sterile Insect Technique (SIT) in the context of an Area-Wide pest management program. See [http://www-naweb.iaea.org/nafa/ipc/screwworm-flies.html the Joint FAO/IAEA program]. An SIT based program requires releasing huge numbers of sterilized male flies throughout the grazing lands, so that the female flies do not encounter a wild male, thus leading to a substantial reduction in the population within a few generations. The method is cost effective when the treated area actually is infested or potentially can be infested with screw-worm. So a successful SIT treatment plan depends on a good understanding of the distribution and possible migration of the pest. This research attempts to address that very question. By merging population genetics and a species habitat model through the use of GIS tools, a procedure is suggested which leads to a geographic data layer representing possible migration corridors of the insect. These corridors are created by combining genetic distance data with environmental data using GRASS GIS.

== Genetics ==
In this research, we used the pairwise Fst matrix estimated in [http://pubget.com/paper/21485363 Fresia et al. 2011]. (full text availble on request) as the genetic distance between samples from all pairs of locations. A total of 227 mitochondrial haplotypes were identified in 282 individuals collected from 29 locations throughout S. America and grouped into two "geographic groups". From the matrix, those pairs with Fst=0 (genetically identical samples) were retained for further work. This Fst=0 value was chosen based on the dispersal capability of the NWS and can be adjusted in any particular case.

== Habitat Suitability Model ==
The presence only algorithm employed by MaxEnt ( [http://www.cs.princeton.edu/~schapire/maxent/ software for species habitat modeling] ) was used to create a Habitat Suitability Model (HSM). Environmental predictors were chosen from the BioCLIM data, as well as elevation, landcover (the [http://bioval.jrc.ec.europa.eu/products/glc2000/products.php glc2000 dataset] ) and livestock density from the FAO [http://www.fao.org/AG/againfo/resources/en/glw/home.html Gridded Livestock of the World] data layer. The resulting raster showed the habitat suitability of the NWS based on environmental conditions.

== GIS ==
GRASS-GIS was chosen to perform the spatial analyses due to the variety of available modules, and ease of scripting the procedures. The steps to merge the genetic distance data with the HSM are itemized below. The script used is available online [http://www.surfaces.co.il/dl/grass_hsm_lcp.sh here].

Two text files in CSV format were prepared in advance, to be read by the GRASS script:
* A list of the locations, with location code and Lon/Lat coordinates for each location, as "localities.csv"
* A list of the pairs of location codes for which the Fst value was zero, as "Fst_zero.csv"

The procedure is broken into four steps:

===== Read in the HSM raster =====
The HSM raster is '''inverted''' to create a friction raster. This is done simply with r.in.gdal, and an r.mapcalc expression:

<code>
r.in.gdal in=hsm.tiff out=hsm
g.region -p rast=hsm
r.mapcalc friction="1.0-hsm"
</code>

===== Create cost maps for each of the locations based on the friction raster =====
The GRASS module r.cost was run in a loop, reading each location code, and its coordinates from the localities.csv ASCII text file. The code run in each cycle of the loop consisted of:

<code>
r.cost --verbose --overwrite input=friction out=cost_"$code" coord="$lon,$lat";
</code>

By looping through all the locations, cost rasters were created which represent the difficulty, or cost (from the friction map) to reach each of the locations from any other pixel in the region. This "difficulty" is drawn from the original environmental layers as represented in the habitiat suitability model. In the resulting cost raster, pixels with a low value are those where is would be "easy" for an insect to migrate to, from the given location. Pixels with a high value represent locations to which it's unlikely that an insect would migrate.

===== Combine the cost rasters =====
Matrix addition was used to combine two cost rasters, while considering only those pairs of locations for which the genetic distance was close (Fst = 0). The script loops through pairs of locations read from the Fst_zero.csv ASCII text file. In addition to adding the rasters, the result was used to create a '''reclassed''' raster as follows:

* The minimum value from the combined raster is given value 3.
* Values up to 2% higher than the minimum are given value 2
* Values from 2% to 5% higher than the minimum are given value 1
* all other values are set to null

This new reclass raster essentially created a least cost path (LCP), or corridor between pairs of locations. This LCP corridor merges the environmental connectivity, and the genetic distance between locations. A LCP raster was created for each pair of points with the following code:

<code>
r.mapcalc corridor_"$loc1"_"$loc2"="round(cost_"$loc1" + cost_"$loc2")"
<nowiki># Save variables for reclass from r.univar</nowiki>
min=`r.univar -g corridor_"$loc1"_"$loc2" | grep min | cut -d= -f2`
two_percent=`echo $min*1.02/1 | bc`
five_percent=`echo $min*1.05/1 | bc`
<nowiki> # Create the reclass rules file for a specific pair of locations </nowiki>
cat << EOF > "$loc1"_"$loc2"_rules.txt
$min = 3 Minimum
$min thru $two_percent = 2 Two percent
$two_percent thru $five_percent = 1 Five percent
<nowiki>* = NULL NULL</nowiki>
end
EOF
<nowiki># Create the reclass raster for a specific pair using the new reclass rules file</nowiki>
r.reclass --overwrite input=corridor_"$loc1"_"$loc2" output=lcp_"$loc1"_"$loc2" rule="$loc1"_"$loc2"_rules.txt title="$loc1 - $loc2 Least Cost Path"
</code>

===== Finally merge all reclass rasters =====
Create an overall LCP raster for the whole region by summing all the reclass maps, showing possible migration corridors.

<code>
lcp_maps=`g.mlist type=rast pattern="lcp*" separator=,`
r.series --overwrite input=$lcp_maps output=lcp_merged method=sum
</code>

===== Samples =====
Here are two sample maps of HSM and LCP corridors.resulting predicted migration corridors.

[[File:HSM.jpg|border|450px|left|Map 1]]
[[File:Corridors.jpg|border|450px|right|Map 2]]
 
''Map 1:'' the HSM for New World Screw-worm in S. America

''Map 2:'' the resulting predicted migration corridors

== Discussion ==
The corridor map above, and similar results, show good correlation with the accepted understanding of NSW migration in South America. This match between assumed movement of the insect, and the resulting corridor map increases our confidence in the validity of the procedure. Furthermore, each of the three components of the method outlined above - genetic differentiation, habitat suitability, and least cost path analysis - is flexible. Many adjustments can be applied to adapt the procedure to differing circumstances and other species. We hope therefore that other researchers will adopt the method, and report similar encouraging results.

Regarding NWS and OWS, we believe that this technique could become an integral part of any Area-Wide treatment program, employing SIT to reduce the insect population while avoiding repeated pesticide applications. Infestation can be reduced dramatically, improving livestock production, and allowing expansion of herds into new grazing areas without concern for renewed screw-worm attacks. An analysis of migration corridors will ensure efficient and effective use of SIT, making it a viable as well as safe tool for fighting myasis.

==== Authors ====
:: Pablo Fresia, pfresia at gmail com
:: Micha Silver, micha at arava co il

[[Category: Case Studies]]

Population Genetics and GIS

2012-12-03T19:13:42Z

⚠️Micha: /* Habitat Suitability Model */

= Applying Population Genetics, Habitat Suitability Modeling and GIS to create predicted migration corridors for New World Screw-worm =

== Background ==
New world Screw-worm ''Cochliomyia hominivorax'' (NWS) is a well known insect pest in South and North America, causing extensive damage to livestock. The females lay eggs into small wounds in warm-blooded vertebrate and the larvae then burrow into the tissue. This injury, known as myasis, weakens the animal, lowers production, and sometimes is severe enough to lead to death of the animal. The "cousin" of NWS, the Old World Screw-worm ''Chrysomya bezziana'' (OWS) causes similar effects throughout the Middle East and South East Asia.

Typically these insect pests are treated by spraying the livestock directly with pesticides. However they are an ideal candidate for treatment by Sterile Insect Technique (SIT) in the context of an Area-Wide pest management program. See [http://www-naweb.iaea.org/nafa/ipc/screwworm-flies.html the Joint FAO/IAEA program]. An SIT based program requires releasing huge numbers of sterilized male flies throughout the grazing lands, so that the female flies do not encounter a wild male, thus leading to a substantial reduction in the population within a few generations. The method is cost effective when the treated area actually is infested or potentially can be infested with screw-worm. So a successful SIT treatment plan depends on a good understanding of the distribution and possible migration of the pest. This research attempts to address that very question. By merging population genetics and a species habitat model through the use of GIS tools, a procedure is suggested which leads to a geographic data layer representing possible migration corridors of the insect. These corridors are created by combining genetic distance data with environmental data using GRASS GIS.

== Genetics ==
In this research, we used the pairwise Fst matrix estimated in [http://pubget.com/paper/21485363 Fresia et al. 2011]. (full text availble on request) as the genetic distance between samples from all pairs of locations. A total of 227 mitochondrial haplotypes were identified in 282 individuals collected from 29 locations throughout S. America and grouped into two "geographic groups". From the matrix, those pairs with Fst=0 (genetically identical samples) were retained for further work. This Fst=0 value was chosen based on the dispersal capability of the NWS and can be adjusted in any particular case.

== Habitat Suitability Model ==
The presence only algorithm employed by MaxEnt ( [http://www.cs.princeton.edu/~schapire/maxent/ software for species habitat modeling] ) was used to create a Habitat Suitability Model (HSM). Environmental predictors were chosen from the BioCLIM data, as well as elevation, landcover (the [http://bioval.jrc.ec.europa.eu/products/glc2000/products.php glc2000 dataset] ) and livestock density from the FAO [http://www.fao.org/AG/againfo/resources/en/glw/home.html Gridded Livestock of the World] data layer. The resulting raster showed the habitat suitability of the NWS based on environmental conditions.

== GIS ==
GRASS-GIS was chosen to perform the spatial analyses due to the variety of available modules, and ease of scripting the procedures. The steps to merge the genetic distance data with the HSM are itemized below. The script used is available online [http://www.surfaces.co.il/dl/grass_hsm_lcp.sh here].

Two text files in CSV format were prepared in advance, to be read by the GRASS script:
* A list of the locations, with location code and Lon/Lat coordinates for each location, as "localities.csv"
* A list of the pairs of location codes for which the Fst value was zero, as "Fst_zero.csv"

The procedure is broken into four steps:

===== Read in the HSM raster =====
The HSM raster is '''inverted''' to create a friction raster. This is done simply with r.in.gdal, and an r.mapcalc expression:

<code>
r.in.gdal in=hsm.tiff out=hsm
g.region -p rast=hsm
r.mapcalc friction="1.0-hsm"
</code>

===== Create cost maps for each of the locations based on the friction raster =====
The GRASS module r.cost was run in a loop, reading each location code, and its coordinates from the localities.csv ASCII text file. The code run in each cycle of the loop consisted of:

<code>
r.cost --verbose --overwrite input=friction out=cost_"$code" coord="$lon,$lat";
</code>

By looping through all the locations, cost rasters were created which represent the difficulty, or cost (from the friction map) to reach each of the locations from any other pixel in the region. This "difficulty" is drawn from the original environmental layers as represented in the habitiat suitability model. In the resulting cost raster, pixels with a low value are those where is would be "easy" for an insect to migrate to, from the given location. Pixels with a high value represent locations to which it's unlikely that an insect would migrate.

===== Combine the cost rasters =====
Use matrix addition to combine two cost rasters, considering only those pairs of locations for which the genetic distance was close (Fst = 0). The script loops through pairs of locations read from the Fst_zero.csv ASCII text file. In addition to adding the rasters, the result is used to create a '''reclassed''' raster as follows:

* The minimum value from the combined raster is given value 3.
* Values up to 2% higher than the minimum are given value 2
* Values from 2% to 5% higher than the minimum are given value 1
* all other values are set to null

This new reclass raster essentially creates a least cost path (LCP), or corridor between pairs of locations. This LCP corridor merges the environmental connectivity, and the genetic distance between locations. A LCP raster is created for each pair of points with the following code:

<code>
r.mapcalc corridor_"$loc1"_"$loc2"="round(cost_"$loc1" + cost_"$loc2")"
<nowiki># Save variables for reclass from r.univar</nowiki>
min=`r.univar -g corridor_"$loc1"_"$loc2" | grep min | cut -d= -f2`
two_percent=`echo $min*1.02/1 | bc`
five_percent=`echo $min*1.05/1 | bc`
<nowiki> # Create the reclass rules file for a specific pair of locations </nowiki>
cat << EOF > "$loc1"_"$loc2"_rules.txt
$min = 3 Minimum
$min thru $two_percent = 2 Two percent
$two_percent thru $five_percent = 1 Five percent
<nowiki>* = NULL NULL</nowiki>
end
EOF
<nowiki># Create the reclass raster for a specific pair using the new reclass rules file</nowiki>
r.reclass --overwrite input=corridor_"$loc1"_"$loc2" output=lcp_"$loc1"_"$loc2" rule="$loc1"_"$loc2"_rules.txt title="$loc1 - $loc2 Least Cost Path"
</code>

===== Finally merge all reclass rasters =====
Create an overall LCP raster for the whole region by summing all the reclass maps, showing possible migration corridors.

<code>
lcp_maps=`g.mlist type=rast pattern="lcp*" separator=,`
r.series --overwrite input=$lcp_maps output=lcp_merged method=sum
</code>

===== Samples =====
Here are two sample maps of HSM and LCP corridors.resulting predicted migration corridors.

[[File:HSM.jpg|border|450px|left|Map 1]]
[[File:Corridors.jpg|border|450px|right|Map 2]]
 
''Map 1:'' the HSM for New World Screw-worm in S. America

''Map 2:'' the resulting predicted migration corridors

== Discussion ==
The corridor map above, and similar results, show good correlation with the accepted understanding of NSW migration in South America. This match between assumed movement of the insect, and the resulting corridor map increases our confidence in the validity of the procedure. Furthermore, each of the three components of the method outlined above - genetic differentiation, habitat suitability, and least cost path analysis - is flexible. Many adjustments can be applied to adapt the procedure to differing circumstances and other species. We hope therefore that other researchers will adopt the method, and report similar encouraging results.

Regarding NWS and OWS, we believe that this technique could become an integral part of any Area-Wide treatment program, employing SIT to reduce the insect population while avoiding repeated pesticide applications. Infestation can be reduced dramatically, improving livestock production, and allowing expansion of herds into new grazing areas without concern for renewed screw-worm attacks. An analysis of migration corridors will ensure efficient and effective use of SIT, making it a viable as well as safe tool for fighting myasis.

==== Authors ====
:: Pablo Fresia, pfresia at gmail com
:: Micha Silver, micha at arava co il

[[Category: Case Studies]]

Population Genetics and GIS

2012-12-03T19:12:54Z

⚠️Micha: /* Genetics */

= Applying Population Genetics, Habitat Suitability Modeling and GIS to create predicted migration corridors for New World Screw-worm =

== Background ==
New world Screw-worm ''Cochliomyia hominivorax'' (NWS) is a well known insect pest in South and North America, causing extensive damage to livestock. The females lay eggs into small wounds in warm-blooded vertebrate and the larvae then burrow into the tissue. This injury, known as myasis, weakens the animal, lowers production, and sometimes is severe enough to lead to death of the animal. The "cousin" of NWS, the Old World Screw-worm ''Chrysomya bezziana'' (OWS) causes similar effects throughout the Middle East and South East Asia.

Typically these insect pests are treated by spraying the livestock directly with pesticides. However they are an ideal candidate for treatment by Sterile Insect Technique (SIT) in the context of an Area-Wide pest management program. See [http://www-naweb.iaea.org/nafa/ipc/screwworm-flies.html the Joint FAO/IAEA program]. An SIT based program requires releasing huge numbers of sterilized male flies throughout the grazing lands, so that the female flies do not encounter a wild male, thus leading to a substantial reduction in the population within a few generations. The method is cost effective when the treated area actually is infested or potentially can be infested with screw-worm. So a successful SIT treatment plan depends on a good understanding of the distribution and possible migration of the pest. This research attempts to address that very question. By merging population genetics and a species habitat model through the use of GIS tools, a procedure is suggested which leads to a geographic data layer representing possible migration corridors of the insect. These corridors are created by combining genetic distance data with environmental data using GRASS GIS.

== Genetics ==
In this research, we used the pairwise Fst matrix estimated in [http://pubget.com/paper/21485363 Fresia et al. 2011]. (full text availble on request) as the genetic distance between samples from all pairs of locations. A total of 227 mitochondrial haplotypes were identified in 282 individuals collected from 29 locations throughout S. America and grouped into two "geographic groups". From the matrix, those pairs with Fst=0 (genetically identical samples) were retained for further work. This Fst=0 value was chosen based on the dispersal capability of the NWS and can be adjusted in any particular case.

== Habitat Suitability Model ==
The presence only algorithm employed by MaxEnt ( [http://www.cs.princeton.edu/~schapire/maxent/ software for species habitat modeling] ) was used to create a Habitat Suitability Model (HSM). Environmental predictors were chosen from the BioCLIM data, as well as elevation, landcover (the [http://bioval.jrc.ec.europa.eu/products/glc2000/products.php glc2000 dataset] ) and livestock density from the FAO [http://www.fao.org/AG/againfo/resources/en/glw/home.html Gridded Livestock of the World] data layer. The resulting raster showed the habitat suitability of the NWS based on environmental conditions.

== GIS ==
GRASS-GIS was chosen to perform the spatial analyses due to the variety of available modules, and ease of scripting the procedures. The steps to merge the genetic distance data with the HSM are itemized below. The script used is available online [http://www.surfaces.co.il/dl/grass_hsm_lcp.sh here].

Two text files in CSV format were prepared in advance, to be read by the GRASS script:
* A list of the locations, with location code and Lon/Lat coordinates for each location, as "localities.csv"
* A list of the pairs of location codes for which the Fst value was zero, as "Fst_zero.csv"

The procedure is broken into four steps:

===== Read in the HSM raster =====
The HSM raster is '''inverted''' to create a friction raster. This is done simply with r.in.gdal, and an r.mapcalc expression:

<code>
r.in.gdal in=hsm.tiff out=hsm
g.region -p rast=hsm
r.mapcalc friction="1.0-hsm"
</code>

===== Create cost maps for each of the locations based on the friction raster =====
The GRASS module r.cost was run in a loop, reading each location code, and its coordinates from the localities.csv ASCII text file. The code run in each cycle of the loop consisted of:

<code>
r.cost --verbose --overwrite input=friction out=cost_"$code" coord="$lon,$lat";
</code>

By looping through all the locations, cost rasters were created which represent the difficulty, or cost (from the friction map) to reach each of the locations from any other pixel in the region. This "difficulty" is drawn from the original environmental layers as represented in the habitiat suitability model. In the resulting cost raster, pixels with a low value are those where is would be "easy" for an insect to migrate to, from the given location. Pixels with a high value represent locations to which it's unlikely that an insect would migrate.

===== Combine the cost rasters =====
Use matrix addition to combine two cost rasters, considering only those pairs of locations for which the genetic distance was close (Fst = 0). The script loops through pairs of locations read from the Fst_zero.csv ASCII text file. In addition to adding the rasters, the result is used to create a '''reclassed''' raster as follows:

* The minimum value from the combined raster is given value 3.
* Values up to 2% higher than the minimum are given value 2
* Values from 2% to 5% higher than the minimum are given value 1
* all other values are set to null

This new reclass raster essentially creates a least cost path (LCP), or corridor between pairs of locations. This LCP corridor merges the environmental connectivity, and the genetic distance between locations. A LCP raster is created for each pair of points with the following code:

<code>
r.mapcalc corridor_"$loc1"_"$loc2"="round(cost_"$loc1" + cost_"$loc2")"
<nowiki># Save variables for reclass from r.univar</nowiki>
min=`r.univar -g corridor_"$loc1"_"$loc2" | grep min | cut -d= -f2`
two_percent=`echo $min*1.02/1 | bc`
five_percent=`echo $min*1.05/1 | bc`
<nowiki> # Create the reclass rules file for a specific pair of locations </nowiki>
cat << EOF > "$loc1"_"$loc2"_rules.txt
$min = 3 Minimum
$min thru $two_percent = 2 Two percent
$two_percent thru $five_percent = 1 Five percent
<nowiki>* = NULL NULL</nowiki>
end
EOF
<nowiki># Create the reclass raster for a specific pair using the new reclass rules file</nowiki>
r.reclass --overwrite input=corridor_"$loc1"_"$loc2" output=lcp_"$loc1"_"$loc2" rule="$loc1"_"$loc2"_rules.txt title="$loc1 - $loc2 Least Cost Path"
</code>

===== Finally merge all reclass rasters =====
Create an overall LCP raster for the whole region by summing all the reclass maps, showing possible migration corridors.

<code>
lcp_maps=`g.mlist type=rast pattern="lcp*" separator=,`
r.series --overwrite input=$lcp_maps output=lcp_merged method=sum
</code>

===== Samples =====
Here are two sample maps of HSM and LCP corridors.resulting predicted migration corridors.

[[File:HSM.jpg|border|450px|left|Map 1]]
[[File:Corridors.jpg|border|450px|right|Map 2]]
 
''Map 1:'' the HSM for New World Screw-worm in S. America

''Map 2:'' the resulting predicted migration corridors

== Discussion ==
The corridor map above, and similar results, show good correlation with the accepted understanding of NSW migration in South America. This match between assumed movement of the insect, and the resulting corridor map increases our confidence in the validity of the procedure. Furthermore, each of the three components of the method outlined above - genetic differentiation, habitat suitability, and least cost path analysis - is flexible. Many adjustments can be applied to adapt the procedure to differing circumstances and other species. We hope therefore that other researchers will adopt the method, and report similar encouraging results.

Regarding NWS and OWS, we believe that this technique could become an integral part of any Area-Wide treatment program, employing SIT to reduce the insect population while avoiding repeated pesticide applications. Infestation can be reduced dramatically, improving livestock production, and allowing expansion of herds into new grazing areas without concern for renewed screw-worm attacks. An analysis of migration corridors will ensure efficient and effective use of SIT, making it a viable as well as safe tool for fighting myasis.

==== Authors ====
:: Pablo Fresia, pfresia at gmail com
:: Micha Silver, micha at arava co il

[[Category: Case Studies]]

Population Genetics and GIS

2012-12-03T19:10:11Z

⚠️Micha:

= Applying Population Genetics, Habitat Suitability Modeling and GIS to create predicted migration corridors for New World Screw-worm =

== Background ==
New world Screw-worm ''Cochliomyia hominivorax'' (NWS) is a well known insect pest in South and North America, causing extensive damage to livestock. The females lay eggs into small wounds in warm-blooded vertebrate and the larvae then burrow into the tissue. This injury, known as myasis, weakens the animal, lowers production, and sometimes is severe enough to lead to death of the animal. The "cousin" of NWS, the Old World Screw-worm ''Chrysomya bezziana'' (OWS) causes similar effects throughout the Middle East and South East Asia.

Typically these insect pests are treated by spraying the livestock directly with pesticides. However they are an ideal candidate for treatment by Sterile Insect Technique (SIT) in the context of an Area-Wide pest management program. See [http://www-naweb.iaea.org/nafa/ipc/screwworm-flies.html the Joint FAO/IAEA program]. An SIT based program requires releasing huge numbers of sterilized male flies throughout the grazing lands, so that the female flies do not encounter a wild male, thus leading to a substantial reduction in the population within a few generations. The method is cost effective when the treated area actually is infested or potentially can be infested with screw-worm. So a successful SIT treatment plan depends on a good understanding of the distribution and possible migration of the pest. This research attempts to address that very question. By merging population genetics and a species habitat model through the use of GIS tools, a procedure is suggested which leads to a geographic data layer representing possible migration corridors of the insect. These corridors are created by combining genetic distance data with environmental data using GRASS GIS.

== Genetics ==
In this research, we used the pairwise Fst matrix estimated in [http://pubget.com/paper/21485363 Fresia et al. 2011]. (full text availble on request) as the genetic distance between samples from all pairs of locations. In this study, a total of 227 mitochondrial haplotypes were identified in 282 individuals collected from 29 locations throughout S. America and grouped into two "geographic groups". From the Fst matrix, those pairs with Fst=0 (genetically identical samples) were retained for further work. This Fst=0 value was chosen based on the dispersal capability of the NWS and can be adjusted in any particular case.

== Habitat Suitability Model ==
The presence only algorithm employed by MaxEnt ( [http://www.cs.princeton.edu/~schapire/maxent/ software for species habitat modeling] ) was used to create a Habitat Suitability Model (HSM). Environmental predictors were chosen from the BioCLIM data, as well as elevation, landcover (the [http://bioval.jrc.ec.europa.eu/products/glc2000/products.php glc2000 dataset] ) and livestock density from the FAO [http://www.fao.org/AG/againfo/resources/en/glw/home.html Gridded Livestock of the World] data layer. The resulting raster showed the habitat suitability of the NWS based on environmental conditions.

== GIS ==
GRASS-GIS was chosen to perform the spatial analyses due to the variety of available modules, and ease of scripting the procedures. The steps to merge the genetic distance data with the HSM are itemized below. The script used is available online [http://www.surfaces.co.il/dl/grass_hsm_lcp.sh here].

Two text files in CSV format were prepared in advance, to be read by the GRASS script:
* A list of the locations, with location code and Lon/Lat coordinates for each location, as "localities.csv"
* A list of the pairs of location codes for which the Fst value was zero, as "Fst_zero.csv"

The procedure is broken into four steps:

===== Read in the HSM raster =====
The HSM raster is '''inverted''' to create a friction raster. This is done simply with r.in.gdal, and an r.mapcalc expression:

<code>
r.in.gdal in=hsm.tiff out=hsm
g.region -p rast=hsm
r.mapcalc friction="1.0-hsm"
</code>

===== Create cost maps for each of the locations based on the friction raster =====
The GRASS module r.cost was run in a loop, reading each location code, and its coordinates from the localities.csv ASCII text file. The code run in each cycle of the loop consisted of:

<code>
r.cost --verbose --overwrite input=friction out=cost_"$code" coord="$lon,$lat";
</code>

By looping through all the locations, cost rasters were created which represent the difficulty, or cost (from the friction map) to reach each of the locations from any other pixel in the region. This "difficulty" is drawn from the original environmental layers as represented in the habitiat suitability model. In the resulting cost raster, pixels with a low value are those where is would be "easy" for an insect to migrate to, from the given location. Pixels with a high value represent locations to which it's unlikely that an insect would migrate.

===== Combine the cost rasters =====
Use matrix addition to combine two cost rasters, considering only those pairs of locations for which the genetic distance was close (Fst = 0). The script loops through pairs of locations read from the Fst_zero.csv ASCII text file. In addition to adding the rasters, the result is used to create a '''reclassed''' raster as follows:

* The minimum value from the combined raster is given value 3.
* Values up to 2% higher than the minimum are given value 2
* Values from 2% to 5% higher than the minimum are given value 1
* all other values are set to null

This new reclass raster essentially creates a least cost path (LCP), or corridor between pairs of locations. This LCP corridor merges the environmental connectivity, and the genetic distance between locations. A LCP raster is created for each pair of points with the following code:

<code>
r.mapcalc corridor_"$loc1"_"$loc2"="round(cost_"$loc1" + cost_"$loc2")"
<nowiki># Save variables for reclass from r.univar</nowiki>
min=`r.univar -g corridor_"$loc1"_"$loc2" | grep min | cut -d= -f2`
two_percent=`echo $min*1.02/1 | bc`
five_percent=`echo $min*1.05/1 | bc`
<nowiki> # Create the reclass rules file for a specific pair of locations </nowiki>
cat << EOF > "$loc1"_"$loc2"_rules.txt
$min = 3 Minimum
$min thru $two_percent = 2 Two percent
$two_percent thru $five_percent = 1 Five percent
<nowiki>* = NULL NULL</nowiki>
end
EOF
<nowiki># Create the reclass raster for a specific pair using the new reclass rules file</nowiki>
r.reclass --overwrite input=corridor_"$loc1"_"$loc2" output=lcp_"$loc1"_"$loc2" rule="$loc1"_"$loc2"_rules.txt title="$loc1 - $loc2 Least Cost Path"
</code>

===== Finally merge all reclass rasters =====
Create an overall LCP raster for the whole region by summing all the reclass maps, showing possible migration corridors.

<code>
lcp_maps=`g.mlist type=rast pattern="lcp*" separator=,`
r.series --overwrite input=$lcp_maps output=lcp_merged method=sum
</code>

===== Samples =====
Here are two sample maps of HSM and LCP corridors.resulting predicted migration corridors.

[[File:HSM.jpg|border|450px|left|Map 1]]
[[File:Corridors.jpg|border|450px|right|Map 2]]
 
''Map 1:'' the HSM for New World Screw-worm in S. America

''Map 2:'' the resulting predicted migration corridors

== Discussion ==
The corridor map above, and similar results, show good correlation with the accepted understanding of NSW migration in South America. This match between assumed movement of the insect, and the resulting corridor map increases our confidence in the validity of the procedure. Furthermore, each of the three components of the method outlined above - genetic differentiation, habitat suitability, and least cost path analysis - is flexible. Many adjustments can be applied to adapt the procedure to differing circumstances and other species. We hope therefore that other researchers will adopt the method, and report similar encouraging results.

Regarding NWS and OWS, we believe that this technique could become an integral part of any Area-Wide treatment program, employing SIT to reduce the insect population while avoiding repeated pesticide applications. Infestation can be reduced dramatically, improving livestock production, and allowing expansion of herds into new grazing areas without concern for renewed screw-worm attacks. An analysis of migration corridors will ensure efficient and effective use of SIT, making it a viable as well as safe tool for fighting myasis.

==== Authors ====
:: Pablo Fresia, pfresia at gmail com
:: Micha Silver, micha at arava co il

[[Category: Case Studies]]

File:HSM.jpg

2012-12-03T19:01:47Z

⚠️Micha: Habitat Suitability Model for NWS in S.America

Habitat Suitability Model for NWS in S.America

File:Corridors.jpg

2012-12-03T19:00:49Z

⚠️Micha: Predicted migration corridors for NWS in S. America

Predicted migration corridors for NWS in S. America

Population Genetics and GIS

2012-12-03T17:41:32Z

⚠️Micha:

= Applying Population Genetics, Habitat Suitability Modeling and GIS to create predicted migration corridors for New World Screw-worm =

== Background ==
New world Screw-worm ''Cochliomyia hominivorax'' (NWS) is a well known insect pest in South and North America, causing extensive damage to livestock. The females lay eggs into small wounds in warm-blooded vertebrate and the larvae then burrow into the tissue. This injury, known as myasis, weakens the animal, lowers production, and sometimes is severe enough to lead to death of the animal. The "cousin" of NWS, the Old World Screw-worm ''Chrysomya bezziana'' (OWS) causes similar effects throughout the Middle East and South East Asia.

Typically these insect pests are treated by spraying the livestock directly with pesticides. However they are an ideal candidate for treatment by Sterile Insect Technique (SIT) in the context of an Area-Wide pest management program. See [http://www-naweb.iaea.org/nafa/ipc/screwworm-flies.html the Joint FAO/IAEA program]. An SIT based program requires releasing huge numbers of sterilized male flies throughout the grazing lands, so that the female flies do not encounter a wild male, thus leading to a substantial reduction in the population within a few generations. The method is cost effective when the treated area actually is infested or potentially can be infested with screw-worm. So a successful SIT treatment plan depends on a good understanding of the distribution and possible migration of the pest. This research attempts to address that very question. By merging population genetics and a species habitat model through the use of GIS tools, a procedure is suggested which leads to a geographic data layer representing possible migration corridors of the insect. These corridors are created by combining genetic distance data with environmental data using GRASS GIS.

== Genetics ==
In this research, we used the pairwise Fst matrix estimated in [http://pubget.com/paper/21485363 Fresia et al. 2011]. (full text availble on request) as the genetic distance between samples from all pairs of locations. In this study, a total of 227 mitochondrial haplotypes were identified in 282 individuals collected from 29 locations throughout S. America and grouped into two "geographic groups". From the Fst matrix, those pairs with Fst=0 (genetically identical samples) were retained for further work. This Fst=0 value was chosen based on the dispersal capability of the NWS and can be adjusted in any particular case.

== Habitat Suitability Model ==
The presence only algorithm employed by MaxEnt ( [http://www.cs.princeton.edu/~schapire/maxent/ software for species habitat modeling] ) was used to create a Habitat Suitability Model (HSM). Environmental predictors were chosen from the BioCLIM data, as well as elevation, landcover (the [http://bioval.jrc.ec.europa.eu/products/glc2000/products.php glc2000 dataset] ) and livestock density from the FAO [http://www.fao.org/AG/againfo/resources/en/glw/home.html Gridded Livestock of the World] data layer. The resulting raster showed the habitat suitability of the NWS based on environmental conditions.

== GIS ==
GRASS-GIS was chosen to perform the spatial analyses due to the variety of available modules, and ease of scripting the procedures. The steps to merge the genetic distance data with the HSM are itemized below. The script used is available online [http://www.surfaces.co.il/dl/grass_hsm_lcp.sh here].

Two text files in CSV format were prepared in advance, to be read by the GRASS script:
* A list of the locations, with location code and Lon/Lat coordinates for each location, as "localities.csv"
* A list of the pairs of location codes for which the Fst value was zero, as "Fst_zero.csv"

The procedure is broken into four steps:

===== Read in the HSM raster =====
The HSM raster is '''inverted''' to create a friction raster. This is done simply with r.in.gdal, and an r.mapcalc expression:

<code>
r.in.gdal in=hsm.tiff out=hsm
g.region -p rast=hsm
r.mapcalc friction="1.0-hsm"
</code>

===== Create cost maps for each of the locations based on the friction raster =====
The GRASS module r.cost was run in a loop, reading each location code, and its coordinates from the localities.csv ASCII text file. The code run in each cycle of the loop consisted of:

<code>
r.cost --verbose --overwrite input=friction out=cost_"$code" coord="$lon,$lat";
</code>

By looping through all the locations, cost rasters were created which represent the difficulty, or cost (from the friction map) to reach each of the locations from any other pixel in the region. This "difficulty" is drawn from the original environmental layers as represented in the habitiat suitability model. In the resulting cost raster, pixels with a low value are those where is would be "easy" for an insect to migrate to, from the given location. Pixels with a high value represent locations to which it's unlikely that an insect would migrate.

===== Combine the cost rasters =====
Use matrix addition to combine two cost rasters, considering only those pairs of locations for which the genetic distance was close (Fst = 0). The script loops through pairs of locations read from the Fst_zero.csv ASCII text file. In addition to adding the rasters, the result is used to create a '''reclassed''' raster as follows:

* The minimum value from the combined raster is given value 3.
* Values up to 2% higher than the minimum are given value 2
* Values from 2% to 5% higher than the minimum are given value 1
* all other values are set to null

This new reclass raster essentially creates a least cost path (LCP), or corridor between pairs of locations. This LCP corridor merges the environmental connectivity, and the genetic distance between locations. A LCP raster is created for each pair of points with the following code:

<code>
r.mapcalc corridor_"$loc1"_"$loc2"="round(cost_"$loc1" + cost_"$loc2")"
<nowiki># Save variables for reclass from r.univar</nowiki>
min=`r.univar -g corridor_"$loc1"_"$loc2" | grep min | cut -d= -f2`
two_percent=`echo $min*1.02/1 | bc`
five_percent=`echo $min*1.05/1 | bc`
<nowiki> # Create the reclass rules file for a specific pair of locations </nowiki>
cat << EOF > "$loc1"_"$loc2"_rules.txt
$min = 3 Minimum
$min thru $two_percent = 2 Two percent
$two_percent thru $five_percent = 1 Five percent
<nowiki>* = NULL NULL</nowiki>
end
EOF
<nowiki># Create the reclass raster for a specific pair using the new reclass rules file</nowiki>
r.reclass --overwrite input=corridor_"$loc1"_"$loc2" output=lcp_"$loc1"_"$loc2" rule="$loc1"_"$loc2"_rules.txt title="$loc1 - $loc2 Least Cost Path"
</code>

===== Finally merge all reclass rasters =====
Create an overall LCP raster for the whole region by summing all the reclass maps, showing possible migration corridors.

<code>
lcp_maps=`g.mlist type=rast pattern="lcp*" separator=,`
r.series --overwrite input=$lcp_maps output=lcp_merged method=sum
</code>

===== Sample =====
Here is a sample map of LCP corridors for the state of São Paulo, Brazil
[[File:Lcp_merged.jpg|border|400px|right]]
'''Map 1''': Predicted migration corridors

== Discussion ==
The corridor map above, and similar results, show good correlation with the accepted understanding of NSW migration in South America. This match between assumed movement of the insect, and the resulting corridor map increases our confidence in the validity of the procedure. Furthermore, each of the three components of the method outlined above - genetic differentiation, habitat suitability, and least cost path analysis - is flexible. Many adjustments can be applied to adapt the procedure to differing circumstances and other species. We hope therefore that other researchers will adopt the method, and report similar encouraging results.

Regarding NWS and OWS, we believe that this technique could become an integral part of any Area-Wide treatment program, employing SIT to reduce the insect population while avoiding repeated pesticide applications. Infestation can be reduced dramatically, improving livestock production, and allowing expansion of herds into new grazing areas without concern for renewed screw-worm attacks. An analysis of migration corridors will ensure efficient and effective use of SIT, making it a viable as well as safe tool for fighting myasis.

==== Authors ====
:: Pablo Fresia, pfresia at gmail com
:: Micha Silver, micha at arava co il

[[Category: Case Studies]]

Population Genetics and GIS

2012-12-01T15:34:30Z

⚠️Micha: /* Sample */

= Applying Population Genetics and GIS to create predicted migration corridors for New World Screw-worm =

== Background ==
New world Screw-worm ''Cochliomyia hominivorax'' (NWS) is a well known agricultural pest in South and North America, causing extensive damage to cattle. The females lay larvae into small wounds in the animal's skin and the larvae then burrow into the tissue and cause myasis, which weakens the animal, lowers production, and sometimes is severe enough to lead to death of the animal. The "cousin" of NWS, the Old World Screw-worm ''Chrysomya bezziana'' (OWS) causes similar effects in cattle and also small ruminants throughout the Middle East and South East Asia.

Typically these pests are treated by spraying the livestock directly with pesticides. However they are an ideal candidate for treatment by Sterile Insect Technique (SIT) in the context of an Area-Wide pest management program. See [http://www-naweb.iaea.org/nafa/ipc/screwworm-flies.html the Joint FAO/IAEA program]. An SIT based program requires releasing huge numbers of sterilized male flies throughout the grazing lands, so that the female flies do not encounter a wild male, thus leading to a substantial reduction in the population within a few generations. The method is cost effective when the treated area actually is infested or potentially can be infested with screw-worm. So a successful SIT treatment plan depends on a good understanding of the distribution and possible migration of the pest. This research attempts to address that very question. By merging population genetics and a species habitat model through the use of GIS tools, a procedure is suggested which leads to a geographic data layer representing possible migration corridors of the insect. These corridors are created by combining genetic distance data with environmental data using GRASS GIS.

== Genetics ==
In this research, individuals were collected from 38 locations throughout S. America, and mtDNA analysis isolated over 200 haplotypes. The haplotypes where grouped into four "geographic groups". A pairwise Fst matrix was created indicating the genetic distance between samples from all pairs of locations. This procedure is fully described in [http://pubget.com/paper/21485363 Fresia et al. 2011]. (Full text availble on request). From the Fst matrix, those pairs with Fst=0 (genetically identical samples) were isolated for further work.

== Habitat Suitability Model ==
The presence only algorithm employed by MaxEnt ( [http://www.cs.princeton.edu/~schapire/maxent/ software for species habitat modeling] ) was used to create a Habitat Suitability Model (HSM). Environmental predictors were chosen from the BioCLIM data, as well as elevation, landcover (the [http://bioval.jrc.ec.europa.eu/products/glc2000/products.php glc2000 dataset] ) and livestock density from the FAO [http://www.fao.org/AG/againfo/resources/en/glw/home.html Gridded Livestock of the World] data layer. The resulting raster showed probabilities for spread of the NWS based on environmental conditions.

== GIS ==
GRASS-GIS was chosen to perform the spatial analyses due to the variety of available modules, and ease of scripting the procedures. The steps to merge the genetic distance data with the HSM are itemized below. The script used is available online [http://www.surfaces.co.il/dl/grass_hsm_lcp.sh here].

Two text files in CSV format were prepared in advance, to be read by the GRASS script:
* A list of the locations, with location code and Lon/Lat coordinates for each location, as "localities.csv"
* A list of the pairs of location codes for which the Fst value was zero, as "Fst_zero.csv"

The procedure is broken into four steps:

===== Read in the HSM raster =====
The HSM raster is '''inverted''' to create a friction raster. This is done simply with r.in.gdal, and an r.mapcalc expression:

<code>
r.in.gdal in=hsm.tiff out=hsm
g.region -p rast=hsm
r.mapcalc friction="1.0-hsm"
</code>

===== Create cost maps for each of the locations based on the friction raster =====
The GRASS module r.cost was run in a loop, reading each location code, and its coordinates from the localities.csv ASCII text file. The code run in each cycle of the loop consisted of:

<code>
r.cost --verbose --overwrite input=friction out=cost_"$code" coord="$lon,$lat";
</code>

By looping through all the locations, cost rasters were created which represent the difficulty, or cost (from the friction map) to reach each of the locations from any other pixel in the region. This "difficulty" is drawn from the original environmental layers as represented in the habitiat suitability model. In the resulting cost raster, pixels with a low value are those where is would be "easy" for an insect to migrate to, from the given location. Pixels with a high value represent locations to which it's unlikely that an insect would migrate.

===== Combine the cost rasters =====
Use matrix addition to combine two cost rasters, considering only those pairs of locations for which the genetic distance was close (Fst = 0). The script loops through pairs of locations read from the Fst_zero.csv ASCII text file. In addition to adding the rasters, the result is used to create a '''reclassed''' raster as follows:

* The minimum value from the combined raster is given value 3.
* Values up to 2% higher than the minimum are given value 2
* Values from 2% to 5% higher than the minimum are given value 1
* all other values are set to null

This new reclass raster essentially creates a least cost path (LCP), or corridor between pairs of locations. This LCP corridor merges the environmental connectivity, and the genetic distance between locations. A LCP raster is created for each pair of points with the following code:

<code>
r.mapcalc corridor_"$loc1"_"$loc2"="round(cost_"$loc1" + cost_"$loc2")"
<nowiki># Save variables for reclass from r.univar</nowiki>
min=`r.univar -g corridor_"$loc1"_"$loc2" | grep min | cut -d= -f2`
two_percent=`echo $min*1.02/1 | bc`
five_percent=`echo $min*1.05/1 | bc`
<nowiki> # Create the reclass rules file for a specific pair of locations </nowiki>
cat << EOF > "$loc1"_"$loc2"_rules.txt
$min = 3 Minimum
$min thru $two_percent = 2 Two percent
$two_percent thru $five_percent = 1 Five percent
<nowiki>* = NULL NULL</nowiki>
end
EOF
<nowiki># Create the reclass raster for a specific pair using the new reclass rules file</nowiki>
r.reclass --overwrite input=corridor_"$loc1"_"$loc2" output=lcp_"$loc1"_"$loc2" rule="$loc1"_"$loc2"_rules.txt title="$loc1 - $loc2 Least Cost Path"
</code>

===== Finally merge all reclass rasters =====
Create an overall LCP raster for the whole region by summing all the reclass maps, showing possible migration corridors.

<code>
lcp_maps=`g.mlist type=rast pattern="lcp*" separator=,`
r.series --overwrite input=$lcp_maps output=lcp_merged method=sum
</code>

===== Sample =====
Here is a sample map of LCP corridors for the state of São Paulo, Brazil
[[File:Lcp_merged.jpg|frame]]
'''Map 1''': Predicted migration corridors

== Discussion ==
The corridor map above, and similar results, show good correlation with the accepted understanding of NSW migration in South America. This match between assumed movement of the insect, and the resulting corridor map increases our confidence in the validity of the procedure. Furthermore, each of the three components of the method outlined above - genetic differentiation, habitat suitability, and least cost path analysis - is flexible. Many adjustments can be applied to adapt the procedure to differing circumstances and other species. We hope therefore that other researchers will adopt the method, and report similar encouraging results.

Regarding NWS and OWS, we believe that this technique could become an integral part of any Area-Wide treatment program, employing SIT to reduce the insect population while avoiding repeated pesticide applications. Infestation can be reduced dramatically, improving livestock production, and allowing expansion of herds into new grazing areas without concern for renewed screw-worm attacks. An analysis of migration corridors will ensure efficient and effective use of SIT, making it a viable as well as safe tool for fighting myasis.

==== Authors ====
:: Pablo Fresia, pfresia at gmail com
:: Micha Silver, micha at arava co il

[[Category: Case Studies]]

Population Genetics and GIS

2012-12-01T14:50:11Z

⚠️Micha: /* Combine the cost rasters */

= Applying Population Genetics and GIS to create predicted migration corridors for New World Screw-worm =

== Background ==
New world Screw-worm ''Cochliomyia hominivorax'' (NWS) is a well known agricultural pest in South and North America, causing extensive damage to cattle. The females lay larvae into small wounds in the animal's skin and the larvae then burrow into the tissue and cause myasis, which weakens the animal, lowers production, and sometimes is severe enough to lead to death of the animal. The "cousin" of NWS, the Old World Screw-worm ''Chrysomya bezziana'' (OWS) causes similar effects in cattle and also small ruminants throughout the Middle East and South East Asia.

Typically these pests are treated by spraying the livestock directly with pesticides. However they are an ideal candidate for treatment by Sterile Insect Technique (SIT) in the context of an Area-Wide pest management program. See [http://www-naweb.iaea.org/nafa/ipc/screwworm-flies.html the Joint FAO/IAEA program]. An SIT based program requires releasing huge numbers of sterilized male flies throughout the grazing lands, so that the female flies do not encounter a wild male, thus leading to a substantial reduction in the population within a few generations. The method is cost effective when the treated area actually is infested or potentially can be infested with screw-worm. So a successful SIT treatment plan depends on a good understanding of the distribution and possible migration of the pest. This research attempts to address that very question. By merging population genetics and a species habitat model through the use of GIS tools, a procedure is suggested which leads to a geographic data layer representing possible migration corridors of the insect. These corridors are created by combining genetic distance data with environmental data using GRASS GIS.

== Genetics ==
In this research, individuals were collected from 38 locations throughout S. America, and mtDNA analysis isolated over 200 haplotypes. The haplotypes where grouped into four "geographic groups". A pairwise Fst matrix was created indicating the genetic distance between samples from all pairs of locations. This procedure is fully described in [http://pubget.com/paper/21485363 Fresia et al. 2011]. (Full text availble on request). From the Fst matrix, those pairs with Fst=0 (genetically identical samples) were isolated for further work.

== Habitat Suitability Model ==
The presence only algorithm employed by MaxEnt ( [http://www.cs.princeton.edu/~schapire/maxent/ software for species habitat modeling] ) was used to create a Habitat Suitability Model (HSM). Environmental predictors were chosen from the BioCLIM data, as well as elevation, landcover (the [http://bioval.jrc.ec.europa.eu/products/glc2000/products.php glc2000 dataset] ) and livestock density from the FAO [http://www.fao.org/AG/againfo/resources/en/glw/home.html Gridded Livestock of the World] data layer. The resulting raster showed probabilities for spread of the NWS based on environmental conditions.

== GIS ==
GRASS-GIS was chosen to perform the spatial analyses due to the variety of available modules, and ease of scripting the procedures. The steps to merge the genetic distance data with the HSM are itemized below. The script used is available online [http://www.surfaces.co.il/dl/grass_hsm_lcp.sh here].

Two text files in CSV format were prepared in advance, to be read by the GRASS script:
* A list of the locations, with location code and Lon/Lat coordinates for each location, as "localities.csv"
* A list of the pairs of location codes for which the Fst value was zero, as "Fst_zero.csv"

The procedure is broken into four steps:

===== Read in the HSM raster =====
The HSM raster is '''inverted''' to create a friction raster. This is done simply with r.in.gdal, and an r.mapcalc expression:

<code>
r.in.gdal in=hsm.tiff out=hsm
g.region -p rast=hsm
r.mapcalc friction="1.0-hsm"
</code>

===== Create cost maps for each of the locations based on the friction raster =====
The GRASS module r.cost was run in a loop, reading each location code, and its coordinates from the localities.csv ASCII text file. The code run in each cycle of the loop consisted of:

<code>
r.cost --verbose --overwrite input=friction out=cost_"$code" coord="$lon,$lat";
</code>

By looping through all the locations, cost rasters were created which represent the difficulty, or cost (from the friction map) to reach each of the locations from any other pixel in the region. This "difficulty" is drawn from the original environmental layers as represented in the habitiat suitability model. In the resulting cost raster, pixels with a low value are those where is would be "easy" for an insect to migrate to, from the given location. Pixels with a high value represent locations to which it's unlikely that an insect would migrate.

===== Combine the cost rasters =====
Use matrix addition to combine two cost rasters, considering only those pairs of locations for which the genetic distance was close (Fst = 0). The script loops through pairs of locations read from the Fst_zero.csv ASCII text file. In addition to adding the rasters, the result is used to create a '''reclassed''' raster as follows:

* The minimum value from the combined raster is given value 3.
* Values up to 2% higher than the minimum are given value 2
* Values from 2% to 5% higher than the minimum are given value 1
* all other values are set to null

This new reclass raster essentially creates a least cost path (LCP), or corridor between pairs of locations. This LCP corridor merges the environmental connectivity, and the genetic distance between locations. A LCP raster is created for each pair of points with the following code:

<code>
r.mapcalc corridor_"$loc1"_"$loc2"="round(cost_"$loc1" + cost_"$loc2")"
<nowiki># Save variables for reclass from r.univar</nowiki>
min=`r.univar -g corridor_"$loc1"_"$loc2" | grep min | cut -d= -f2`
two_percent=`echo $min*1.02/1 | bc`
five_percent=`echo $min*1.05/1 | bc`
<nowiki> # Create the reclass rules file for a specific pair of locations </nowiki>
cat << EOF > "$loc1"_"$loc2"_rules.txt
$min = 3 Minimum
$min thru $two_percent = 2 Two percent
$two_percent thru $five_percent = 1 Five percent
<nowiki>* = NULL NULL</nowiki>
end
EOF
<nowiki># Create the reclass raster for a specific pair using the new reclass rules file</nowiki>
r.reclass --overwrite input=corridor_"$loc1"_"$loc2" output=lcp_"$loc1"_"$loc2" rule="$loc1"_"$loc2"_rules.txt title="$loc1 - $loc2 Least Cost Path"
</code>

===== Finally merge all reclass rasters =====
Create an overall LCP raster for the whole region by summing all the reclass maps, showing possible migration corridors.

<code>
lcp_maps=`g.mlist type=rast pattern="lcp*" separator=,`
r.series --overwrite input=$lcp_maps output=lcp_merged method=sum
</code>

===== Sample =====
Here is a sample map of LCP corridors for the state of São Paulo, Brazil
[[File:Lcp_merged.jpg|frame]]

== Discussion ==
The corridor map above, and similar results, show good correlation with the accepted understanding of NSW migration in South America. This match between assumed movement of the insect, and the resulting corridor map increases our confidence in the validity of the procedure. Furthermore, each of the three components of the method outlined above - genetic differentiation, habitat suitability, and least cost path analysis - is flexible. Many adjustments can be applied to adapt the procedure to differing circumstances and other species. We hope therefore that other researchers will adopt the method, and report similar encouraging results.

Regarding NWS and OWS, we believe that this technique could become an integral part of any Area-Wide treatment program, employing SIT to reduce the insect population while avoiding repeated pesticide applications. Infestation can be reduced dramatically, improving livestock production, and allowing expansion of herds into new grazing areas without concern for renewed screw-worm attacks. An analysis of migration corridors will ensure efficient and effective use of SIT, making it a viable as well as safe tool for fighting myasis.

==== Authors ====
:: Pablo Fresia, pfresia at gmail com
:: Micha Silver, micha at arava co il

[[Category: Case Studies]]

Case studies

2012-12-01T14:44:14Z

⚠️Micha:

== GRASS GIS Case Studies ==

=== List of Case Studies ===

* [http://grasswiki.osgeo.org/wiki/Case_studies/GlobalChangeBiology Assessing the invasiveness of exotic species using ecosystem models and GRASS GIS] by Luigi Ponti
* [http://grasswiki.osgeo.org/wiki/Population_Genetics_and_GIS Applying population genetics and GIS to create migration corridors for New World screw-worm]

=== List of external Case Studies ===

* [http://pages.swcp.com/~russo/080103/ Using GRASS GIS to analyze cell phone information from mission 080103] by Dave Sampson
* [http://www.qgis.org/en/community/qgis-case-studies/ribeira-de-pena-portugal.html QGIS and GRASS for modelling ecological corridors for wolves in North Portugal] by Monica Almeida
* [http://www.qgis.org/en/community/qgis-case-studies/queensland-australia.html QGIS and GRASS in Local Government Bushfire Hazard Mapping] by Nathan Woodrow
* [http://qgis.org/en/community/qgis-case-studies/torres-vedras-portugal.html QGIS and GRASS applied to paleontological survey in Western Portugal] by André Mano
* [http://qgis.org/en/community/qgis-case-studies/evora-portugal.html Quantum GIS and GRASS in Biogeographical Research in Spain] by Marcia Barbosa

[[Category:Applications]]

Population Genetics and GIS

2012-12-01T14:41:27Z

⚠️Micha: Created page with "= Applying Population Genetics and GIS to create predicted migration corridors for New World Screw-worm = == Background == New world Screw-worm ''Cochliomyia hominivorax'' (..."

= Applying Population Genetics and GIS to create predicted migration corridors for New World Screw-worm =

== Background ==
New world Screw-worm ''Cochliomyia hominivorax'' (NWS) is a well known agricultural pest in South and North America, causing extensive damage to cattle. The females lay larvae into small wounds in the animal's skin and the larvae then burrow into the tissue and cause myasis, which weakens the animal, lowers production, and sometimes is severe enough to lead to death of the animal. The "cousin" of NWS, the Old World Screw-worm ''Chrysomya bezziana'' (OWS) causes similar effects in cattle and also small ruminants throughout the Middle East and South East Asia.

Typically these pests are treated by spraying the livestock directly with pesticides. However they are an ideal candidate for treatment by Sterile Insect Technique (SIT) in the context of an Area-Wide pest management program. See [http://www-naweb.iaea.org/nafa/ipc/screwworm-flies.html the Joint FAO/IAEA program]. An SIT based program requires releasing huge numbers of sterilized male flies throughout the grazing lands, so that the female flies do not encounter a wild male, thus leading to a substantial reduction in the population within a few generations. The method is cost effective when the treated area actually is infested or potentially can be infested with screw-worm. So a successful SIT treatment plan depends on a good understanding of the distribution and possible migration of the pest. This research attempts to address that very question. By merging population genetics and a species habitat model through the use of GIS tools, a procedure is suggested which leads to a geographic data layer representing possible migration corridors of the insect. These corridors are created by combining genetic distance data with environmental data using GRASS GIS.

== Genetics ==
In this research, individuals were collected from 38 locations throughout S. America, and mtDNA analysis isolated over 200 haplotypes. The haplotypes where grouped into four "geographic groups". A pairwise Fst matrix was created indicating the genetic distance between samples from all pairs of locations. This procedure is fully described in [http://pubget.com/paper/21485363 Fresia et al. 2011]. (Full text availble on request). From the Fst matrix, those pairs with Fst=0 (genetically identical samples) were isolated for further work.

== Habitat Suitability Model ==
The presence only algorithm employed by MaxEnt ( [http://www.cs.princeton.edu/~schapire/maxent/ software for species habitat modeling] ) was used to create a Habitat Suitability Model (HSM). Environmental predictors were chosen from the BioCLIM data, as well as elevation, landcover (the [http://bioval.jrc.ec.europa.eu/products/glc2000/products.php glc2000 dataset] ) and livestock density from the FAO [http://www.fao.org/AG/againfo/resources/en/glw/home.html Gridded Livestock of the World] data layer. The resulting raster showed probabilities for spread of the NWS based on environmental conditions.

== GIS ==
GRASS-GIS was chosen to perform the spatial analyses due to the variety of available modules, and ease of scripting the procedures. The steps to merge the genetic distance data with the HSM are itemized below. The script used is available online [http://www.surfaces.co.il/dl/grass_hsm_lcp.sh here].

Two text files in CSV format were prepared in advance, to be read by the GRASS script:
* A list of the locations, with location code and Lon/Lat coordinates for each location, as "localities.csv"
* A list of the pairs of location codes for which the Fst value was zero, as "Fst_zero.csv"

The procedure is broken into four steps:

===== Read in the HSM raster =====
The HSM raster is '''inverted''' to create a friction raster. This is done simply with r.in.gdal, and an r.mapcalc expression:

<code>
r.in.gdal in=hsm.tiff out=hsm
g.region -p rast=hsm
r.mapcalc friction="1.0-hsm"
</code>

===== Create cost maps for each of the locations based on the friction raster =====
The GRASS module r.cost was run in a loop, reading each location code, and its coordinates from the localities.csv ASCII text file. The code run in each cycle of the loop consisted of:

<code>
r.cost --verbose --overwrite input=friction out=cost_"$code" coord="$lon,$lat";
</code>

By looping through all the locations, cost rasters were created which represent the difficulty, or cost (from the friction map) to reach each of the locations from any other pixel in the region. This "difficulty" is drawn from the original environmental layers as represented in the habitiat suitability model. In the resulting cost raster, pixels with a low value are those where is would be "easy" for an insect to migrate to, from the given location. Pixels with a high value represent locations to which it's unlikely that an insect would migrate.

===== Combine the cost rasters =====
Use matrix addition to combine two cost rasters, considering only those pairs of locations for which the genetic distance was close (Fst = 0). The script loops through pairs of locations read from the Fst_zero.csv ASCII text file. In addition to adding the rasters, the result is used to create a '''reclassed''' raster as follows:

* The minimum value from the combined raster is given value 3.
* Values up to 2% higher than the minimum are given value 2
* Values from 2% to 5% higher than the minimum are given value 1
* all other values are set to null

This new reclass raster essentially creates a least cost path (LCP), or corridor between pairs of locations. This LCP corridor merges the environtmental connectivity, and the genetic distance between locations. A LCP raster is created for each pair of points with the following code:

<code>
r.mapcalc corridor_"$loc1"_"$loc2"="round(cost_"$loc1" + cost_"$loc2")"
<nowiki># Save variables for reclass from r.univar</nowiki>
min=`r.univar -g corridor_"$loc1"_"$loc2" | grep min | cut -d= -f2`
two_percent=`echo $min*1.02/1 | bc`
five_percent=`echo $min*1.05/1 | bc`
<nowiki> # Create the reclass rules file for a specific pair of locations </nowiki>
cat << EOF > "$loc1"_"$loc2"_rules.txt
$min = 3 Minimum
$min thru $two_percent = 2 Two percent
$two_percent thru $five_percent = 1 Five percent
<nowiki>* = NULL NULL</nowiki>
end
EOF
<nowiki># Create the reclass raster for a specific pair using the new reclass rules file</nowiki>
r.reclass --overwrite input=corridor_"$loc1"_"$loc2" output=lcp_"$loc1"_"$loc2" rule="$loc1"_"$loc2"_rules.txt title="$loc1 - $loc2 Least Cost Path"
</code>

===== Finally merge all reclass rasters =====
Create an overall LCP raster for the whole region by summing all the reclass maps, showing possible migration corridors.

<code>
lcp_maps=`g.mlist type=rast pattern="lcp*" separator=,`
r.series --overwrite input=$lcp_maps output=lcp_merged method=sum
</code>

===== Sample =====
Here is a sample map of LCP corridors for the state of São Paulo, Brazil
[[File:Lcp_merged.jpg|frame]]

== Discussion ==
The corridor map above, and similar results, show good correlation with the accepted understanding of NSW migration in South America. This match between assumed movement of the insect, and the resulting corridor map increases our confidence in the validity of the procedure. Furthermore, each of the three components of the method outlined above - genetic differentiation, habitat suitability, and least cost path analysis - is flexible. Many adjustments can be applied to adapt the procedure to differing circumstances and other species. We hope therefore that other researchers will adopt the method, and report similar encouraging results.

Regarding NWS and OWS, we believe that this technique could become an integral part of any Area-Wide treatment program, employing SIT to reduce the insect population while avoiding repeated pesticide applications. Infestation can be reduced dramatically, improving livestock production, and allowing expansion of herds into new grazing areas without concern for renewed screw-worm attacks. An analysis of migration corridors will ensure efficient and effective use of SIT, making it a viable as well as safe tool for fighting myasis.

==== Authors ====
:: Pablo Fresia, pfresia at gmail com
:: Micha Silver, micha at arava co il

[[Category: Case Studies]]

File:Lcp merged.jpg

2012-12-01T14:16:20Z

⚠️Micha: Least Cost Paths merged

Least Cost Paths merged

R.basin

2012-06-07T13:25:21Z

⚠️Micha: /* Preparation */

== Introduction ==

The module {{AddonCmd|r.basin}} has been designed to perform the delineation and the morphometric characterization of a given basin, on the basis of an elevation raster map and the coordinates of the outlet.
Please note that it is designed to work only in projected coordinates.
Here a tutorial based on NC sample dataset is presented.

== Preparation ==

As a first step, we set the computational region to match the elevation raster map:

<pre>
g.region rast=elevation@PERMANENT -ap
projection: 99 (Lambert Conformal Conic)
zone: 0
datum: nad83
ellipsoid: a=6378137 es=0.006694380022900787
north: 228500
south: 215000
west: 630000
east: 645000
nsres: 10
ewres: 10
rows: 1350
cols: 1500
cells: 2025000
</pre>

For the basin's delineation, a pair of coordinates is required. Usually coordinates belonging to the natural river network don't exactly match with the calculated stream network. What we should do is calculating the stream network first, and then find the coordinates on the calculated stream network closest to the coordinates belonging to the natural stream network.

<pre>
# Calculate flow accumulation map
r.watershed -a elevation=elevation@PERMANENT accumulation=accum

# Extract the stream network
r.stream.extract elevation=elevation@PERMANENT accumulation=accum@testing threshold=20 stream_rast=stream_network stream_vect=streams
</pre>

We no longer need the accumulation map:

<pre>
g.remove rast=accum
</pre>

Now that we have the calculated stream network, we should choose a pair of coordinates for the outlet belonging to it. Let's choose:

<pre>
easting=636654.791181 northing=218824.126649
</pre>

We no longer need the stream network map:

<pre>
g.remove rast=stream_network
</pre>

If there are a lot of basins to be analysed, the coordinate pairs of the intersections between the calculated stream network and basins (outlet points) can be found by:

<pre>
# Convert basins polygon vector boundaries to lines
v.type input=basinspoly output=basinsline type=boundary,line

# Patch basins lines with stream network
v.patch input=basinsline,streams output=basins_streams

# Find cross points at intersections
v.clean input=basins_streams output=basins_streams_clean error=crosspoints_err tool=break

# Add categories to cross points vector
v.category input=crosspoints_err output=crosspoints

# Add table to cross points vector with columns for category, x and y coordinates
v.db.addtable map=crosspoints columns="cat integer,xcoor double precision, ycoor double precision"

# Upload category to cross points attribute table
v.to.db map=crosspoints option=cat columns=cat

# Upload x and y coordinates to cross points attribute table
v.to.db map=crosspoints option=coor columns=xcoor,ycoor
</pre>

== Usage ==

We can run r.basin:

<pre>
r.basin map=elevation@PERMANENT prefix=out easting=636654.791181 northing=218824.126649 threshold=20
</pre>

Prefix parameter is a string given by the user in order to distinguish all the maps produced by every run of the program, i.e. every set of outlet's coordinates. Prefix must start with a letter.

Threshold is the same parameter given in r.watershed and r.stream.extract. Physically, it means the number of cells that determine "where the river begins". (This is an open issue for the hydrological science and a wide literature has been produced on the topic). In order to determine the threshold, see also {{AddonCmd|r.threshold}} and {{AddonCmd|r.stream.preview}}.

The output of r.basin consists of:

* Several morphometric parameters, which are printed in terminal and also stored in a csv file called out_elevation_parameters.csv, in the working directory;
* Maps;
* Plots.

== Morphometric parameters ==

The main parameters are:

* The coordinates of the vertices of the '''rectangle containing the basin'''.
* The '''center of gravity''' of the basin: the coordinates of the pixel nearest to the center of gravity of the geometric figure resulting from the projection of the basin on the horizontal plane.
* The '''area''' of the basin: is the area of a single cell multiplied by the number of cells belonging to the basin.
* The '''perimeter''': is the length of the contour of the figure resulting by the projection of the basin on the horizontal plane.
[As a side note, a paper namely [http://en.wikipedia.org/wiki/How_Long_Is_the_Coast_of_Britain%3F_Statistical_Self-Similarity_and_Fractional_Dimension "How Long Is the Coast of Britain? Statistical Self-Similarity and Fractional Dimension"] points out that perimeter is affected by a fractal problem and the number is mostly meaningless taken by itself. Hence, perimeter should never be mixed with anything from another dataset or even the same data set at a different cell resolution; it is only good as a percentage comparison to its neighbors in the same dataset].
* '''Characteristic values of elevation''': the highest and the lowest altitude, the difference between them and the mean elevation calculated as the sum of the values of the cells divided by the number of the cells.
* The '''mean slope''', calculated averaging the slope map.
* The '''length of the directing vector''': the length of the vector linking the outlet to the center of gravity of the basin.
* The '''prevalent orientation''': in GRASS the aspect categories represent the number degrees of east and they increase counterclockwise: (90deg is North, 180 is West, 270 is South 360 is East). The aspect value 0 is used to indicate undefined aspect in flat areas with slope=0. We instead calculate the orientation as the number of degree from north, increasing counterclockwise.
* The '''length of main channel''': is the length of the longest succession of segments that connect a source to the outlet of the basin.
* The '''mean slope of main channel''': it is calculated as follows:

<center>
[[File:R.basin1.gif]]
</center>

where N is the topological diameter, i.e. the number of links in which the main channel can be divided on the basis of the junctions.
* The '''circularity ratio''': is the ratio between the area of the basin and the area of the circle having the same perimeter of the basin.
* The '''elongation ratio''': is the ratio between the diameter of the circle having the same area of the basin and the length of the main channel.
* The '''compactness coefficient''': is the ratio between the perimeter of the basin and the diameter of the circle having the same area of the basin.
* The '''shape factor''': is the ratio between the area of the basin and the square of the length of the main channel.
* The '''concentration time''' (Giandotti, 1934):

<center>
[[File:R.basin2.gif]]
</center>

Where A is the area, L the length of the main channel and H the difference between the highest and the lowest elevation of the basin.
* The '''mean hillslope length''': is the mean of the distances calculated along the flow direction of each point non belonging to the river network from the point in which flows into the network.
* The '''magnitudo''': is the number of the branches of order 1 following the Strahler hierarchy.
* The '''max order''': is the order of the basin, following the Strahler hierarchy.
* The '''number of streams''': is the number of the branches of the river network.
* The '''total stream length''': is the sum of the length of every branches.
* The '''first order stream frequency''': is the ratio between the magnitudo and the area of the basin.
* The '''drainage density''': is the ratio between the total length of the river network and the area.
* The '''Horton ratios''' (Horton, 1945; Strahler, 1957).

<pre>
##################################
Morphometric parameters of basin :
##################################
Easting Centroid of basin : 635195.00
Northing Centroid of Basin : 220715.00
Rectangle containing basin N-W : 632870 , 222890
Rectangle containing basin S-E : 637000 , 218720
Area of basin [km^2] : 7.8559625
Perimeter of basin [km] : 16.8287990515
Max Elevation [m s.l.m.] : 151.7396
Min Elevation [m s.l.m.]: 94.82206
Elevation Difference [m]: 56.91754
Mean Elevation [m s.l.m.]: 127.6772
Mean Slope : 2.93
Length of Directing Vector [km] : 2.38880562659
Prevalent Orientation [degree from north, counterclockwise] :
0.913351005341
Compactness Coefficient : 5.32106255399
Circularity Ratio : 0.348580442132
Topological Diameter : 127.0
Elongation Ratio : 0.470961456397
Shape Factor : 1.16984953656
Concentration Time (Giandotti, 1934) [hr] : 3.52654267443
Length of Mainchannel [km] : 6.715361467
Mean slope of mainchannel [percent] : 0.957339
Mean hillslope length [m] : 8145.381
Magnitudo : 621.0
Max order (Strahler) : 5
Number of streams : 884
Total Stream Length [km] : 96.3436
First order stream frequency : 79.0482388377
Drainage Density [km/km^2] : 12.2637550778
Bifurcation Ratio (Horton) : 5.7374
Length Ratio (Horton) : 2.6902
Area ratio (Horton) : 5.6815
Slope ratio (Horton): 1.5533
</pre>

The '''hypsographic curve''' provides the distribution of the areas at different altitudes. Each point on the hypsographic curve has on the y-axis the altitude and on the x-axis the percentage of basin surface placed above that altitude. The '''ipsometric curve''' has the same shape but is dimensionless.
Quantiles of the ipsometric curve are displayed:

<pre>
Tot. cells 78560.0
===========================
Ipsometric | quantiles
===========================
145 | 0.025
143 | 0.05
141 | 0.1
137 | 0.25
129 | 0.5
119 | 0.75
121 | 0.7
110 | 0.9
100 | 0.975
</pre>

The '''width function W(x)''' gives the area of the cells in the basin at a certain flow distance x from the outlet (distance-area function). Note that the distance is not intended in the euclidean sense, but it's calculated considering the hydrological path of the water.

<pre>
Tot. cells 78560.0
Tot. area 7856000.0
Max distance 6809.546521
===========================
Whidth Function | quantiles
===========================
784 | 0.05
1477 | 0.15
2137 | 0.3
2543 | 0.4
2933 | 0.5
3606 | 0.6
4169 | 0.7
5144 | 0.85
6105 | 0.95
</pre>

The output of r.stream.stats is also displayed:

<pre>
Summary:
Max order | Tot.N.str. | Tot.str.len. | Tot.area. | Dr.dens. | Str.freq.
(num) | (num) | (km) | (km2) | (km/km2) | (num/km2)
5 | 884 | 96.3436 | 7.8339 | 12.2983 | 112.8429

Stream ratios with standard deviations:
Bif.rt. | Len.rt. | Area.rt. | Slo.rt. | Grd.rt.
5.7374 | 2.6902 | 5.6815 | 1.5533 | 1.7962
3.1961 | 1.9514 | 5.2294 | 0.1250 | 0.7482

Order | Avg.len | Avg.ar | Avg.sl | Avg.grad. | Avg.el.dif
num | (km) | (km2) | (m/m) | (m/m) | (m)
1 | 0.0750 | 0.0069 | 0.0523 | 0.0384 | 3.1062
2 | 0.1428 | 0.0311 | 0.0342 | 0.0277 | 4.1701
3 | 0.4834 | 0.1732 | 0.0243 | 0.0205 | 9.0641
4 | 2.4205 | 2.1885 | 0.0155 | 0.0134 | 24.1708
5 | 1.1247 | 7.8339 | 0.0091 | 0.0046 | 5.1594

Order | Std.len | Std.ar | Std.sl | Std.grad. | Std.el.dif
num | (km) | (km2) | (m/m) | (m/m) | (m)
1 | 0.0600 | 0.0052 | 0.0398 | 0.0287 | 3.2301
2 | 0.1244 | 0.0230 | 0.0250 | 0.0196 | 4.4835
3 | 0.4554 | 0.1353 | 0.0132 | 0.0122 | 7.1065
4 | 2.2874 | 2.3843 | 0.0046 | 0.0061 | 12.9175
5 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 0.0000

Order | N.streams | Tot.len (km) | Tot.area (km2)
1 | 712 | 53.4067 | 4.8998
2 | 137 | 19.5657 | 4.2562
3 | 31 | 14.9849 | 5.3684
4 | 3 | 7.2616 | 6.5655
5 | 1 | 1.1247 | 7.8339

Order | Bif.rt. | Len.rt. | Area.rt. | Slo.rt. | Grd.rt. | d.dens. | str.freq.
1 | 5.1971 | 1.9040 | 0.0000 | 1.5311 | 1.3892 | 10.8998 | 145.3120
2 | 4.4194 | 3.3847 | 4.5144 | 1.4046 | 1.3472 | 4.5970 | 32.1883
3 | 10.3333 | 5.0075 | 5.5742 | 1.5691 | 1.5365 | 2.7913 | 5.7745
4 | 3.0000 | 0.4646 | 12.6376 | 1.7083 | 2.9120 | 1.1060 | 0.4569
5 | 0.0000 | 0.0000 | 3.5796 | 0.0000 | 0.0000 | 0.1436 | 0.1277
</pre>

== Maps ==

Since r.basin performs the delimitation of the river basin, all the maps produced are cropped over the basin. They are:

* Raster maps

<pre>
g.list rast

out_elevation_accumulation out_elevation_hillslope_distance
out_elevation_aspect out_elevation_horton
out_elevation_dist2out out_elevation_shreve
out_elevation_drainage out_elevation_slope
out_elevation_hack out_elevation_strahler

</pre>

<center>
<gallery perrow=3 widths=200>

File:Out_elevation_accumulation.png|Flow accumulation
File:Out_elevation_aspect.png|Aspect
File:Out_elevation_dist2out.png|Distance to outlet (width function)
File:Out_elevation_drainage.png|Flow direction
File:Out_elevation_hack.png|Stream network ordered according to Hack
File:Out_elevation_hillslope_distance.png|Length of hillslopes
File:Out_elevation_horton.png|Stream network ordered according to Horton
File:Out_elevation_shreve.png|Stream network ordered according to Shreve
File:Out_elevation_slope.png|Slope
File:Out_elevation_strahler.png|Stream network ordered according to Strahler

</gallery>
</center>

* Vector maps

<pre>
g.list vect

out_elevation_basin out_elevation_network
out_elevation_mainchannel out_elevation_outlet
</pre>

<center>
<gallery perrow=4 widths=200>

File:Out_elevation_basin.png|Basin
File:Out_elevation_mainchannel.png|Main channel
File:Out_elevation_network.png|Stream network
File:Out_elevation_outlet.png|Outlet

</gallery>
</center>

== Plots ==

Plots are stored in the working directory:

* out_elevation_ipsographic.png
* out_elevation_ipsometric.png
* out_elevation_width_function.png

<center>
<gallery perrow=3 widths=200>

File:Out_elevation_Ipsographic.png|Ipsographic curve
File:Out_elevation_Ipsometric.png|Ipsometric curve (Nondimensional ipsographic curve)
File:Out_elevation_width_function.png|Width function

</gallery>
</center>

== See also ==

[[R.stream.*]]

== References ==

* Di Leo Margherita, Working report: Extraction of morphometric parameters from a digital elevation model - Panama. North Carolina State University, 2010 ([http://dl.dropbox.com/u/1599323/Report_Panama.pdf PDF])
* Rodriguez-Iturbe I., Rinaldo A.; Fractal River Basins, Chance and Self-Organization. Cambridge Press, 2001.
* Di Leo M., Di Stefano M., Claps P., Sole A. Caratterizzazione morfometrica del bacino idrografico in GRASS GIS (Morphometric characterization of the catchment in GRASS GIS environment), Geomatics Workbooks n.9, 2010. ([http://geomatica.como.polimi.it/workbooks/n9/GW9-FOSS4Git_2010.pdf PDF]).

[[Category: Documentation]]
[[Category: Hydrology]]

GPS

2010-12-07T18:49:24Z

⚠️Micha: /* Import */

== GPS applications with GRASS ==

=== Tools ===

==== Import ====
* {{cmd|v.in.gpsbabel}}: allows the user to import waypoint, route, and track data from a locally connected GPS receiver or a text file containing GPS data of many common formats.
: - calls the [http://www.gpsbabel.org/ GPS Babel] software

* {{cmd|v.in.garmin}}: allows the user to import from a Garmin device
: - ''gardump'' from the [http://www.snafu.org/ garmin-utils] package
: - [http://gpstrans.sourceforge.net/ gpstrans] software

* {{cmd|v.in.ascii}}: allows the user to import generic points, lines or polygons from an ASCII file. Using v.in.ascii combined with gpsbabel, it's possible to import attribute columns from GPS units, that might otherwise get "lost" when using v.in.garmin. Here's a oneliner to pull waypoints from a usb connected GPS straight into a GRASS vector points map:
<pre>
gpsbabel -w -i garmin -o unicsv -f USB: -F - | v.in.ascii out=gps_points fs=, column="num integer, y_coord double, x_coord double, elev double, date_str varchar(16), time_str varchar(16)" x=3 y=2 skip=1
</pre>
The gpsbabel output format "unicsv" creates a comma-separated-value table of all attributes from the GPS. The output is piped straight into the v.in.ascii command. The parameter "fs=," sets the field separator for the csv GPS output. Then the "column=..." parameter must be setup in the same format as the GPS output table. If the output isn't known, (or if you just want to save a text file of the gps data) then run gpsbabel saving the output to a file i.e. "-F points.txt" then examine the file to find the attribute columns. Finally, use the v.in.ascii "x=" and "y=" to set the correct column number for X and Y coordinates. Note that the GPS output is often in the "geographic" Lat-Lon order, which means Y first, then X. So be sure to choose the right column numbers for X (longitude) and Y (latitude).

==== Export ====

* {{cmd|v.out.gpsbabel}}
: - calls the [http://www.gpsbabel.org/ GPS Babel] software
* {{cmd|v.out.ogr}} to GPX and KML formats

=== Tasks ===

* [[Import Mio C230 GPS track maps]]

=== Links ===

* [http://www.gpsdrive.de/ GpsDrive] realtime mapping software
* [http://www.gpscenter.com/gps-software/index.html GPS Software] GPS Mapping Software (non-free)
: - see also the {{cmd|d.out.gpsdrive}} module

[[Category: Documentation]]

GRASS-QGIS relevant module list

2010-10-30T15:41:43Z

⚠️Micha: /* General modules */

= GRASS modules available in the QGIS toolbox =
* See [[Development#GRASS_and_QGIS|GRASS and QGIS]]

== List of GRASS modules relevant to QGIS ==

=== Status Templates ===
{| class="wikitable1"
| Present in QGIS:
| {{ModuleAvailable}}
|-
| Present in QGIS but shouldn't be
|
|-
| Not present in QGIS - High Priority:
| {{ModuleNotAvailable}}
|-
| Not present in QGIS - Low Priority:
| {{ModuleNotAvailableLo}}
|-
| Not relevant to QGIS:
| {{ModuleNotRelevant}}
|}

* "Status" is for modules currently present in qgis source code dir src/plugins/grass/modules-*/
* Color coding indicates availability of module in the GRASS Toolbox

=== Database modules ===

{| class="wikitable sortable"
|+ db.* 
! Module
! Status
! Comments
|-
| {{cmd|db.columns}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|db.connect}}
| {{ModuleAvailable}}
| login; generic, schema, which
|-
| {{cmd|db.copy}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.describe}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.drivers}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.dropcol}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.droptable}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.execute}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.in.ogr}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.login}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.out.ogr}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.select}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.tables}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|db.test}}
| {{ModuleNotAvailableLo}}
|
|}

=== General modules ===

{| class="wikitable sortable"
|+ g.* 
! Module
! Status
! Comments
|-
| {{cmd|g.access}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.ask}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.copy}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.dirseps}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.extension}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.filename}}
|{{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.findetc}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.findfile}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.gisenv}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|g.gui}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.list}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.manual}}
| {{ModuleAvailable}}
|
|-
| {{cmd|g.mapset}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.mapsets}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.message}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.mkfontcap}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.mlist}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.mremove}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|g.parser}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.pnmcomp}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.proj}}
| {{ModuleAvailable}}
| generic, ascii, geo, print, proj
|-
| {{cmd|g.region}}
| {{ModuleAvailable}}
| save, zoom, multi-rast multi-vect
|-
| {{cmd|g.remove}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.rename}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.setproj}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|g.tempfile}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.transform}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|g.version}}
| {{ModuleNotRelevant}}
| Not really relevant
|}

=== Imagery modules ===

''Essentially these are raster modules that deal with satellite or aerial photography.''

{| class="wikitable sortable"
|+ i.* 
! Module
! Status
! Comments
|-
| {{cmd|i.atcorr}}
| {{ModuleNotAvailable|lo}}
|
|-
| {{cmd|i.cca}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.class}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|i.cluster}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.fft}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.fusion.brovey}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.gensig}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.gensigset}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.group}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.his.rgb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.ifft}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.image.mosaic}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.in.spotvgt}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|i.landsat.rgb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.maxlik}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.oif}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.ortho.photo}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|i.pca}}
| {{ModuleNotAvailableLo}}
|
|
|-
| {{cmd|i.points}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|i.rectify}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|i.rgb.his}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.smap}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.spectral}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|i.target}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.tasscap}}
| {{ModuleAvailable}}
| common x3
|-
| {{cmd|i.vpoints}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|i.zc}}
|{{ModuleAvailable}}
| common
|}

=== Miscellaneous modules ===

{| class="wikitable sortable"
|+ m.* 
! Module
! Status
! Comments
|-
| {{cmd|m.cogo}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|m.proj}}
| {{ModuleAvailable}}
| common
|}

=== Paint modules ===

''These have been abandoned in GRASS 6.''

{| class="wikitable sortable"
|+ p.* 
! Module
! Status
! Comments
|-
| {{cmd|p.out.vrml}}
| {{ModuleNotRelevant}}
| old & renamed; not for QGIS
|}

=== PostScript modules ===

{| class="wikitable sortable"
|+ ps.* 
! Module
! Status
! Comments
|-
| {{cmd|ps.map}}
| {{ModuleNotRelevant}}
| QGIS has its own map composer, so this probably isn't needed.
|}

=== Raster modules ===

{| class="wikitable sortable"
|+ r.* 
! Module
! Status
! Comments
|-
| {{cmd|r.average}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.basins.fill}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.bilinear}}
| {{ModuleAvailable}}
| modules-6.4 ''Please use "r.resamp.interp" instead.''
|-
| {{cmd|r.bitpattern}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.blend}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.buffer}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.carve}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.category}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.cats}}
| {{ModuleNotRelevant}}
| Wrapper script for backwards compatibility.
|-
| {{cmd|r.circle}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.clump}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.coin}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.colors}}
| {{ModuleAvailable}}
| common x4, generic, rast, rules, table
|-
| {{cmd|r.colors.stddev}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|r.composite}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.compress}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.contour}}
| {{ModuleAvailable}}
| common x2
|-
| {{cmd|r.cost}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.covar}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.cross}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.describe}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.digit}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|r.distance}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.drain}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.external}}
| {{ModuleAvailable}}
| modules-6.4 x3
|-
| {{cmd|r.fill.dir}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.fillnulls}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.flow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.grow}}
| {{ModuleAvailable}}
| 6.4/common
|-
| {{cmd|r.grow.distance}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.gwflow}}
| {{ModuleNotAvailableLo}}
| ground water flow modeling
|-
| {{cmd|r.his}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.horizon}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.in.arc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.ascii}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.aster}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.bin}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.gdal}}
|{{ModuleAvailable}}
| common x4, generic, loc, qgis.loc, qgis
|-
| {{cmd|r.in.gridatb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.mat}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.poly}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.srtm}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.wms}}
| {{ModuleAvailable}}
| common, somewhat brittle
|-
| {{cmd|r.in.xyz}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.info}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|r.kappa}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.lake}}
| {{ModuleAvailable}}
| common x3, generic, seed, xy
|-
| {{cmd|r.le.patch}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.le.pixel}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.le.setup}}
| {{ModuleNotAvailable}}
| Landscape Ecology analyses
|-
| {{cmd|r.le.trace}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.cwed}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.dominance}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.edgedensity}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.mpa}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.mps}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.padcv}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.padrange}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.padsd}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.patchdensity}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.patchnum}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.richness}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.setup}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.shannon}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.shape}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.simpson}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.los}}
| {{ModuleAvailable}}
| common
|
|-
| {{cmd|r.mapcalc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.mapcalculator}}
| {{ModuleAvailable}}
| common, gui wrapper (need both?)
|-
| {{cmd|r.mask}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.median}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.mfilter}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.mfilter.fp}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.mode}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.neighbors}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.null}}
| {{ModuleAvailable}}
| common x4, null, to, val, r.to.null?
|-
| {{cmd|r.out.arc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.ascii}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.bin}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.out.gdal}}
| {{ModuleAvailable}}
| common x2 generic, GeoTiff
|-
| {{cmd|r.out.gdal.sh}}
| {{ModuleNotAvailableLo}}
| old full map extent version
|-
| {{cmd|r.out.gridatb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.mat}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.mpeg}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.png}}
| {{ModuleAvailable}}
| common, important once transparency and Worldfile gets backported from 6.5svn (for OpenLayers/KML tile source)
|-
| {{cmd|r.out.pov}}
| {{ModuleAvailable}}
| common POVray
|-
| {{cmd|r.out.ppm}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.ppm3}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.tiff}}
| {{ModuleAvailable}}
| common, ''visual'' RGB output, not data values (use r.out.gdal for that)
|-
| {{cmd|r.out.vrml}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.vtk}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.xyz}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.param.scale}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.patch}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.plane}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.profile}}
| {{ModuleNotAvailableLo}}
| Python plugin available to find transect profile
|-
| {{cmd|r.proj}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.quant}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.quantile}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.random}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.random.cells}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.random.surface}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.reclass}}
| {{ModuleAvailable}}
| common x2, generic, file
|-
| {{cmd|r.reclass.area}}
| {{ModuleAvailable}}
| common x3, generic, greater, lesser
|-
| {{cmd|r.recode}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.region}}
| {{ModuleAvailable}}
| Oversold?, common x6, generic, rast, vect, region, edge, alignTo
|-
| {{cmd|r.regression.line}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.report}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resamp.interp}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resamp.rst}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resamp.stats}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resample}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.rescale}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.rescale.eq}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.ros}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.series}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.shaded.relief}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.sim.sediment}}
| {{ModuleNotAvailableLo}}
|
|
|-
| {{cmd|r.sim.water}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.slope.aspect}}
| {{ModuleAvailable}}
| common x2, slope, aspect, '''but not others'''
|-
| {{cmd|r.spread}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.spreadpath}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.statistics}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.stats}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.sum}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.sun}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.sunmask}}
| {{ModuleAvailable}}
| common x2, date_time, position
|-
| {{cmd|r.support}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.support.stats}}
| {{ModuleAvailable}}
| common, maybe not needed
|-
| {{cmd|r.surf.area}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.surf.contour}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.surf.fractal}}
| {{ModuleAvailable}}
| 6.3/6.4
|-
| {{cmd|r.surf.gauss}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.surf.idw}}
| {{ModuleAvailable}}
| common, faster
|-
| {{cmd|r.surf.idw2}}
| {{ModuleAvailable}}
| common, supports floating point
|-
| {{cmd|r.surf.random}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.terraflow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.terraflow.short}}
| {{ModuleNotRelevant}}
| Not needed
|-
| {{cmd|r.texture}}
| {{ModuleAvailable}}
| common x2, generic, bis
|-
| {{cmd|r.thin}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.tileset}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|r.timestamp}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|r.to.rast3}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.to.rast3elev}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.to.vect}}
| {{ModuleAvailable}}
| common x3, point, line, area
|-
| {{cmd|r.topidx}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.topmodel}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.transect}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.univar}}
| {{ModuleAvailable}}
| common
|
|-
| {{cmd|r.univar.sh}}
| {{ModuleNotRelevant}}
| Not needed
|-
| {{cmd|r.volume}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.walk}}
| {{ModuleNotAvailable}}
|
|
|-
| {{cmd|r.water.outlet}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.watershed}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.what}}
| {{ModuleNotRelevant}}
| Handled in the QGIS GUI
|-
| {{cmd|r.what.color}}
| {{ModuleNotRelevant}}
|
|-
|}

=== 3D raster modules ===

{| class="wikitable sortable"
|+ r3.* 
! Module
! Status
! Comments
|-
| {{cmd|r3.cross.rast}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.gwflow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.in.ascii}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.in.v5d}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.info}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mapcalc}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mapcalculator}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mask}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mkdspf}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.null}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.out.ascii}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.out.v5d}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.out.vtk}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.stats}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.timestamp}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.to.rast}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.univar}}
| {{ModuleNotAvailableLo}}
|
|}

=== Vector modules ===

{| class="wikitable sortable"
|+ v.* 
! Module
! Status
! Comments
|-
| {{cmd|v.buffer}}
| {{ModuleAvailable}}
| 6.3/6.4, https://trac.osgeo.org/grass/ticket/994
|-
| {{cmd|v.build}}
| {{ModuleAvailable}}
| see specific modules
|-
| {{cmd|v.build.all}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.build.polylines}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.category}}
| {{ModuleAvailable}}
| common x4, add, del, sum, change
|-
| {{cmd|v.centroids}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.class}}
| {{ModuleNotAvailableLo}}
| Fuctionality supplied in QGIS Vector symbology
|-
| {{cmd|v.clean}}
| {{ModuleAvailable}}
| common x13
|-
| {{cmd|v.colors}}
| {{ModuleNotRelevant}}
| Fuctionality supplied in QGIS Vector symbology
|-
| {{cmd|v.convert}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.convert.all}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.db.addcol}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.addtable}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.connect}}
| {{ModuleAvailable}}
| common, v.db.sconnect? v.db.what.connect?
|-
| {{cmd|v.db.dropcol}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|v.db.droptable}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.join}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.reconnect.all}}
| {{ModuleAvailable}}
| common
|
|-
| {{cmd|v.db.renamecol}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.select}}
| {{ModuleAvailable}}
| 6.3/6.4 x2
|-
| {{cmd|v.db.univar}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.update}}
| {{ModuleAvailable}}
| common x4, const, op, op query, query
|-
| {{cmd|v.delaunay}}
| {{ModuleAvailable}}
| common x2, line, area
|-
| {{cmd|v.digit}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|v.dissolve}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.distance}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.drape}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.edit}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|v.external}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.extract}}
| {{ModuleAvailable}}
| common, list, where
|-
| {{cmd|v.extrude}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.generalize}}
| {{ModuleAvailable}}
| common, complicated
|-
| {{cmd|v.hull}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.ascii}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|v.in.db}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.dxf}}
| {{ModuleAvailable}}
| common x2, generic, multi
|-
| {{cmd|v.in.e00}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.garmin}}
| {{ModuleAvailable}}
| common, only for old serial models
|-
| {{cmd|v.in.geonames}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|v.in.gns}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|v.in.gpsbabel}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.lines|version=65}}
| {{ModuleAvailable}}
| Only in 6.5svn, new wrapper script around v.in.mapgen with more obvious name
|-
| {{cmd|v.in.mapgen}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.ogr}}
| {{ModuleAvailable}}
| common x7
|-
| {{cmd|v.in.region}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.sites}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.in.sites.all}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.in.wfs}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|v.info}}
| {{ModuleNotRelevant}}
| Functionality supplied in Toolbox
|-
| {{cmd|v.kcv}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.kernel}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.krige.py}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.label}}
| {{ModuleNotRelevant}}
| Functionality supplied in QGIS GUI
|-
| {{cmd|v.label.sa}}
| {{ModuleNotRelevant}}
| Functionality supplied in QGIS GUI
|-
| {{cmd|v.lidar.correction}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.lidar.edgedetection}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lidar.growing}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lrs.create}}
| {{ModuleNotAvailableLo}}
| Python plugin for Linear Referencing available
|-
| {{cmd|v.lrs.label}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lrs.segment}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lrs.where}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.mkgrid}}
| {{ModuleAvailable}}
| common, by region (by coord is a custom graticule creator)
|-
| {{cmd|v.neighbors}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.nodes}}
| {{ModuleAvailable}}
|
|-
| {{cmd|v.net.alloc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.allpairs}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.bridge}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.centrality}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.components}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.connectivity}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.distance}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.flow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.iso}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.path}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.salesman}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.spanningtree}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.steiner}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.timetable}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.visibility}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.normal}}
| {{ModuleNotAvailableLo}}
| common
|-
| {{cmd|v.out.ascii}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.dxf}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.gpsbabel}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.out.ogr}}
| {{ModuleAvailable}}
| 6.3/6.4/common x4, shapefile, generic, gml, mapinfo; 6.x: PostgreSQL
|-
| {{cmd|v.out.pov}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.svg}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.vtk}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.outlier}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.overlay}}
| {{ModuleAvailable}}
| common x4, and, or, not, xor
|-
| {{cmd|v.parallel}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.patch}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.perturb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.proj}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.qcount}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.random}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.rast.stats}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.reclass}}
| {{ModuleAvailable}}
| common x2, attr, file
|-
| {{cmd|v.report}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.sample}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.segment}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.select}}
| {{ModuleAvailable}}
| common, v.select.overlap
|-
| {{cmd|v.split}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.support}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.surf.bspline}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.surf.idw}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.surf.rst}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.to.3d}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.to.db}}
| {{ModuleAvailable}}
| 6.3/6.4
|-
| {{cmd|v.to.points}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.to.rast}}
| {{ModuleAvailable}}
| common x2, attr, constant
|-
| {{cmd|v.to.rast3}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.transform}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.type}}
| {{ModuleAvailable}}
| common x4, b2l, l2b, c2p, p2c
|-
| {{cmd|v.univar}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.univar.sh}}
| {{ModuleNotRelevant}}
| old, not needed
|-
| {{cmd|v.vol.rst}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.voronoi}}
| {{ModuleAvailable}}
| common x2, line, area; https://trac.osgeo.org/grass/ticket/957
|-
| {{cmd|v.what}}
| {{ModuleNotRelevant}}
| QGIS GUI supplies query at location function
|-
| {{cmd|v.what.rast}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.what.vect}}
| {{ModuleAvailable}}
| common
|}

=== GUI and command modules ===
{| class="wikitable sortable"
|+ GUI modules 
! Module
! Status
! Comments
|-
| {{cmd|gis.m}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|nviz}}
| {{ModuleAvailable}}
| common
|-
| shell
| {{ModuleAvailable}}
| common
|-
| {{cmd|xganim}}
| {{ModuleNotAvailableLo}}
|
|}

=== Display modules ===

{| class="wikitable "
|+ d.* 
|-
| '' None of the display modules will be relevant. Display functionality is handled in the QGIS GUI. ''

<!--
! Module
! Priority
! Status
! Comments
|-
| {{cmd|d.ask}}
|
|
|
|-
| {{cmd|d.barscale}}
|
|
|
|-
| {{cmd|d.colorlist}}
|
|
|
|-
| {{cmd|d.colors}}
|
|
|
|-
| {{cmd|d.colortable}}
|
|
|
|-
| {{cmd|d.correlate}}
|
|
|
|-
| {{cmd|d.erase}}
|
|
|
|-
| {{cmd|d.extend}}
|
|
|
|-
| {{cmd|d.extract}}
|
|
|
|-
| {{cmd|d.font}}
|
|
|
|-
| {{cmd|d.font.freetype}}
|
|
|
|-
| {{cmd|d.frame}}
|
|
|
|-
| {{cmd|d.geodesic}}
|
|
|
|-
| {{cmd|d.graph}}
|
|
|
|-
| {{cmd|d.grid}}
|
|
|
|-
| {{cmd|d.his}}
|
|
|
|-
| {{cmd|d.histogram}}
|
|
|
|-
| {{cmd|d.info}}
|
|
|
|-
| {{cmd|d.labels}}
|
|
|
|-
| {{cmd|d.legend}}
|
|
|
|-
| {{cmd|d.linegraph}}
|
|
|
|-
| {{cmd|d.m}}
|
|
|
|-
| {{cmd|d.mapgraph}}
|
|
|
|-
| {{cmd|d.measure}}
|
|
|
|-
| {{cmd|d.menu}}
|
|
|
|-
| {{cmd|d.mon}}
|
|
|
|-
| {{cmd|d.monsize}}
|
|
|
|-
| {{cmd|d.mvmon}}
|
|
|
|-
| {{cmd|d.nviz}}
|
|
|
|-
| {{cmd|d.out.file}}
|
|
|
|-
| {{cmd|d.out.gpsdrive}}
|
|
|
|-
| {{cmd|d.out.png}}
|
|
|
|-
| {{cmd|d.paint.labels}}
|
|
|
|-
| {{cmd|d.path}}
|
|
|
|-
| {{cmd|d.polar}}
|
|
|
|-
| {{cmd|d.profile}}
|
|
|
|-
| {{cmd|d.rast}}
|
|
|
|-
| {{cmd|d.rast.arrow}}
|
|
|
|-
| {{cmd|d.rast.edit}}
|
|
|
|-
| {{cmd|d.rast.leg}}
|
|
|
|-
| {{cmd|d.rast.num}}
|
|
|
|-
| {{cmd|d.redraw}}
|
|
|
|-
| {{cmd|d.resize}}
|
|
|
|-
| {{cmd|d.rgb}}
|
|
|
|-
| {{cmd|d.rhumbline}}
|
|
|
|-
| {{cmd|d.save}}
|
|
|
|-
| {{cmd|d.shadedmap}}
|
|
|
|-
| {{cmd|d.slide.show}}
|
|
|
|-
| {{cmd|d.split}}
|
|
|
|-
| {{cmd|d.split.frame}}
|
|
|
|-
| {{cmd|d.text}}
|
|
|
|-
| {{cmd|d.text.freetype}}
|
|
|
|-
| {{cmd|d.thematic.area}}
|
|
|
|-
| {{cmd|d.title}}
|
|
|
|-
| {{cmd|d.vect}}
|
|
|
|-
| {{cmd|d.vect.chart}}
|
|sortable"
|+

Template:ModuleNotRelevant

2010-10-30T15:16:27Z

⚠️Micha:

<onlyinclude>
<div style="background-color: #B9B0B0;">
Not Relevant
</div>
</onlyinclude>
Template to color GRASS-QGIS Relevant Modules table

Template:ModuleNotRelevant

2010-10-30T15:15:10Z

⚠️Micha:

<onlyinclude>
<div style="background-color: #B9B0B0;">
Not Relevant
</div>
</onlyinclude>
Template to color GRASS-QGIS Relevant Modules table

Template:ModuleNotAvailalbeLo

2010-10-30T15:12:18Z

⚠️Micha:

{{db-g7}}
<onlyinclude>
<div style="background-color: #F79FA0;">
Missing - Lo
</div>
</onlyinclude>
Template to color GRASS-QGIS Relevant Modules table

GRASS-QGIS relevant module list

2010-10-30T15:09:36Z

⚠️Micha: /* Raster modules */

= GRASS modules available in the QGIS toolbox =
* See [[Development#GRASS_and_QGIS|GRASS and QGIS]]

== List of GRASS modules relevant to QGIS ==

=== Status Templates ===
{| class="wikitable1"
| Present in QGIS:
| {{ModuleAvailable}}
|-
| Present in QGIS but shouldn't be
|
|-
| Not present in QGIS - High Priority:
| {{ModuleNotAvailable}}
|-
| Not present in QGIS - Low Priority:
| {{ModuleNotAvailableLo}}
|-
| Not relevant to QGIS:
| {{ModuleNotRelevant}}
|}

* "Status" is for modules currently present in qgis source code dir src/plugins/grass/modules-*/
* Color coding indicates availability of module in the GRASS Toolbox

=== Database modules ===

{| class="wikitable sortable"
|+ db.* 
! Module
! Status
! Comments
|-
| {{cmd|db.columns}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|db.connect}}
| {{ModuleAvailable}}
| login; generic, schema, which
|-
| {{cmd|db.copy}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.describe}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.drivers}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.dropcol}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.droptable}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.execute}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.in.ogr}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.login}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.out.ogr}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.select}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.tables}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|db.test}}
| {{ModuleNotAvailableLo}}
|
|}

=== General modules ===

{| class="wikitable sortable"
|+ g.* 
! Module
! Status
! Comments
|-
| {{cmd|g.access}}
|
|
|-
| {{cmd|g.ask}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.copy}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.dirseps}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.extension}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.filename}}
|{{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.findetc}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.findfile}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.gisenv}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|g.gui}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.list}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.manual}}
| {{ModuleAvailable}}
|
|-
| {{cmd|g.mapset}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.mapsets}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.message}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.mkfontcap}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.mlist}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.mremove}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|g.parser}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.pnmcomp}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.proj}}
| {{ModuleAvailable}}
| generic, ascii, geo, print, proj
|-
| {{cmd|g.region}}
| {{ModuleAvailable}}
| save, zoom, multi-rast multi-vect
|-
| {{cmd|g.remove}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.rename}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.setproj}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|g.tempfile}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.transform}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|g.version}}
| {{ModuleNotRelevant}}
| Not really relevant
|}

=== Imagery modules ===

''Essentially these are raster modules that deal with satellite or aerial photography.''

{| class="wikitable sortable"
|+ i.* 
! Module
! Status
! Comments
|-
| {{cmd|i.atcorr}}
| {{ModuleNotAvailable|lo}}
|
|-
| {{cmd|i.cca}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.class}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|i.cluster}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.fft}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.fusion.brovey}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.gensig}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.gensigset}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.group}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.his.rgb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.ifft}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.image.mosaic}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.in.spotvgt}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|i.landsat.rgb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.maxlik}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.oif}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.ortho.photo}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|i.pca}}
| {{ModuleNotAvailableLo}}
|
|
|-
| {{cmd|i.points}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|i.rectify}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|i.rgb.his}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.smap}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.spectral}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|i.target}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.tasscap}}
| {{ModuleAvailable}}
| common x3
|-
| {{cmd|i.vpoints}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|i.zc}}
|{{ModuleAvailable}}
| common
|}

=== Miscellaneous modules ===

{| class="wikitable sortable"
|+ m.* 
! Module
! Status
! Comments
|-
| {{cmd|m.cogo}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|m.proj}}
| {{ModuleAvailable}}
| common
|}

=== Paint modules ===

''These have been abandoned in GRASS 6.''

{| class="wikitable sortable"
|+ p.* 
! Module
! Status
! Comments
|-
| {{cmd|p.out.vrml}}
| {{ModuleNotRelevant}}
| old & renamed; not for QGIS
|}

=== PostScript modules ===

{| class="wikitable sortable"
|+ ps.* 
! Module
! Status
! Comments
|-
| {{cmd|ps.map}}
| {{ModuleNotRelevant}}
| QGIS has its own map composer, so this probably isn't needed.
|}

=== Raster modules ===

{| class="wikitable sortable"
|+ r.* 
! Module
! Status
! Comments
|-
| {{cmd|r.average}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.basins.fill}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.bilinear}}
| {{ModuleAvailable}}
| modules-6.4 ''Please use "r.resamp.interp" instead.''
|-
| {{cmd|r.bitpattern}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.blend}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.buffer}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.carve}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.category}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.cats}}
| {{ModuleNotRelevant}}
| Wrapper script for backwards compatibility.
|-
| {{cmd|r.circle}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.clump}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.coin}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.colors}}
| {{ModuleAvailable}}
| common x4, generic, rast, rules, table
|-
| {{cmd|r.colors.stddev}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|r.composite}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.compress}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.contour}}
| {{ModuleAvailable}}
| common x2
|-
| {{cmd|r.cost}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.covar}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.cross}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.describe}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.digit}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|r.distance}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.drain}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.external}}
| {{ModuleAvailable}}
| modules-6.4 x3
|-
| {{cmd|r.fill.dir}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.fillnulls}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.flow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.grow}}
| {{ModuleAvailable}}
| 6.4/common
|-
| {{cmd|r.grow.distance}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.gwflow}}
| {{ModuleNotAvailableLo}}
| ground water flow modeling
|-
| {{cmd|r.his}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.horizon}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.in.arc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.ascii}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.aster}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.bin}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.gdal}}
|{{ModuleAvailable}}
| common x4, generic, loc, qgis.loc, qgis
|-
| {{cmd|r.in.gridatb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.mat}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.poly}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.srtm}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.wms}}
| {{ModuleAvailable}}
| common, somewhat brittle
|-
| {{cmd|r.in.xyz}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.info}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|r.kappa}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.lake}}
| {{ModuleAvailable}}
| common x3, generic, seed, xy
|-
| {{cmd|r.le.patch}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.le.pixel}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.le.setup}}
| {{ModuleNotAvailable}}
| Landscape Ecology analyses
|-
| {{cmd|r.le.trace}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.cwed}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.dominance}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.edgedensity}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.mpa}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.mps}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.padcv}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.padrange}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.padsd}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.patchdensity}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.patchnum}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.richness}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.setup}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.shannon}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.shape}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.simpson}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.los}}
| {{ModuleAvailable}}
| common
|
|-
| {{cmd|r.mapcalc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.mapcalculator}}
| {{ModuleAvailable}}
| common, gui wrapper (need both?)
|-
| {{cmd|r.mask}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.median}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.mfilter}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.mfilter.fp}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.mode}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.neighbors}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.null}}
| {{ModuleAvailable}}
| common x4, null, to, val, r.to.null?
|-
| {{cmd|r.out.arc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.ascii}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.bin}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.out.gdal}}
| {{ModuleAvailable}}
| common x2 generic, GeoTiff
|-
| {{cmd|r.out.gdal.sh}}
| {{ModuleNotAvailableLo}}
| old full map extent version
|-
| {{cmd|r.out.gridatb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.mat}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.mpeg}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.png}}
| {{ModuleAvailable}}
| common, important once transparency and Worldfile gets backported from 6.5svn (for OpenLayers/KML tile source)
|-
| {{cmd|r.out.pov}}
| {{ModuleAvailable}}
| common POVray
|-
| {{cmd|r.out.ppm}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.ppm3}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.tiff}}
| {{ModuleAvailable}}
| common, ''visual'' RGB output, not data values (use r.out.gdal for that)
|-
| {{cmd|r.out.vrml}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.vtk}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.xyz}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.param.scale}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.patch}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.plane}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.profile}}
| {{ModuleNotAvailableLo}}
| Python plugin available to find transect profile
|-
| {{cmd|r.proj}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.quant}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.quantile}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.random}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.random.cells}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.random.surface}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.reclass}}
| {{ModuleAvailable}}
| common x2, generic, file
|-
| {{cmd|r.reclass.area}}
| {{ModuleAvailable}}
| common x3, generic, greater, lesser
|-
| {{cmd|r.recode}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.region}}
| {{ModuleAvailable}}
| Oversold?, common x6, generic, rast, vect, region, edge, alignTo
|-
| {{cmd|r.regression.line}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.report}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resamp.interp}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resamp.rst}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resamp.stats}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resample}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.rescale}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.rescale.eq}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.ros}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.series}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.shaded.relief}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.sim.sediment}}
| {{ModuleNotAvailableLo}}
|
|
|-
| {{cmd|r.sim.water}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.slope.aspect}}
| {{ModuleAvailable}}
| common x2, slope, aspect, '''but not others'''
|-
| {{cmd|r.spread}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.spreadpath}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.statistics}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.stats}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.sum}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.sun}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.sunmask}}
| {{ModuleAvailable}}
| common x2, date_time, position
|-
| {{cmd|r.support}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.support.stats}}
| {{ModuleAvailable}}
| common, maybe not needed
|-
| {{cmd|r.surf.area}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.surf.contour}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.surf.fractal}}
| {{ModuleAvailable}}
| 6.3/6.4
|-
| {{cmd|r.surf.gauss}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.surf.idw}}
| {{ModuleAvailable}}
| common, faster
|-
| {{cmd|r.surf.idw2}}
| {{ModuleAvailable}}
| common, supports floating point
|-
| {{cmd|r.surf.random}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.terraflow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.terraflow.short}}
| {{ModuleNotRelevant}}
| Not needed
|-
| {{cmd|r.texture}}
| {{ModuleAvailable}}
| common x2, generic, bis
|-
| {{cmd|r.thin}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.tileset}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|r.timestamp}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|r.to.rast3}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.to.rast3elev}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.to.vect}}
| {{ModuleAvailable}}
| common x3, point, line, area
|-
| {{cmd|r.topidx}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.topmodel}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.transect}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.univar}}
| {{ModuleAvailable}}
| common
|
|-
| {{cmd|r.univar.sh}}
| {{ModuleNotRelevant}}
| Not needed
|-
| {{cmd|r.volume}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.walk}}
| {{ModuleNotAvailable}}
|
|
|-
| {{cmd|r.water.outlet}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.watershed}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.what}}
| {{ModuleNotRelevant}}
| Handled in the QGIS GUI
|-
| {{cmd|r.what.color}}
| {{ModuleNotRelevant}}
|
|-
|}

=== 3D raster modules ===

{| class="wikitable sortable"
|+ r3.* 
! Module
! Status
! Comments
|-
| {{cmd|r3.cross.rast}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.gwflow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.in.ascii}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.in.v5d}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.info}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mapcalc}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mapcalculator}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mask}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mkdspf}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.null}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.out.ascii}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.out.v5d}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.out.vtk}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.stats}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.timestamp}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.to.rast}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.univar}}
| {{ModuleNotAvailableLo}}
|
|}

=== Vector modules ===

{| class="wikitable sortable"
|+ v.* 
! Module
! Status
! Comments
|-
| {{cmd|v.buffer}}
| {{ModuleAvailable}}
| 6.3/6.4, https://trac.osgeo.org/grass/ticket/994
|-
| {{cmd|v.build}}
| {{ModuleAvailable}}
| see specific modules
|-
| {{cmd|v.build.all}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.build.polylines}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.category}}
| {{ModuleAvailable}}
| common x4, add, del, sum, change
|-
| {{cmd|v.centroids}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.class}}
| {{ModuleNotAvailableLo}}
| Fuctionality supplied in QGIS Vector symbology
|-
| {{cmd|v.clean}}
| {{ModuleAvailable}}
| common x13
|-
| {{cmd|v.colors}}
| {{ModuleNotRelevant}}
| Fuctionality supplied in QGIS Vector symbology
|-
| {{cmd|v.convert}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.convert.all}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.db.addcol}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.addtable}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.connect}}
| {{ModuleAvailable}}
| common, v.db.sconnect? v.db.what.connect?
|-
| {{cmd|v.db.dropcol}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|v.db.droptable}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.join}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.reconnect.all}}
| {{ModuleAvailable}}
| common
|
|-
| {{cmd|v.db.renamecol}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.select}}
| {{ModuleAvailable}}
| 6.3/6.4 x2
|-
| {{cmd|v.db.univar}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.update}}
| {{ModuleAvailable}}
| common x4, const, op, op query, query
|-
| {{cmd|v.delaunay}}
| {{ModuleAvailable}}
| common x2, line, area
|-
| {{cmd|v.digit}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|v.dissolve}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.distance}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.drape}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.edit}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|v.external}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.extract}}
| {{ModuleAvailable}}
| common, list, where
|-
| {{cmd|v.extrude}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.generalize}}
| {{ModuleAvailable}}
| common, complicated
|-
| {{cmd|v.hull}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.ascii}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|v.in.db}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.dxf}}
| {{ModuleAvailable}}
| common x2, generic, multi
|-
| {{cmd|v.in.e00}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.garmin}}
| {{ModuleAvailable}}
| common, only for old serial models
|-
| {{cmd|v.in.geonames}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|v.in.gns}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|v.in.gpsbabel}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.lines|version=65}}
| {{ModuleAvailable}}
| Only in 6.5svn, new wrapper script around v.in.mapgen with more obvious name
|-
| {{cmd|v.in.mapgen}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.ogr}}
| {{ModuleAvailable}}
| common x7
|-
| {{cmd|v.in.region}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.sites}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.in.sites.all}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.in.wfs}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|v.info}}
| {{ModuleNotRelevant}}
| Functionality supplied in Toolbox
|-
| {{cmd|v.kcv}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.kernel}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.krige.py}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.label}}
| {{ModuleNotRelevant}}
| Functionality supplied in QGIS GUI
|-
| {{cmd|v.label.sa}}
| {{ModuleNotRelevant}}
| Functionality supplied in QGIS GUI
|-
| {{cmd|v.lidar.correction}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.lidar.edgedetection}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lidar.growing}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lrs.create}}
| {{ModuleNotAvailableLo}}
| Python plugin for Linear Referencing available
|-
| {{cmd|v.lrs.label}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lrs.segment}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lrs.where}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.mkgrid}}
| {{ModuleAvailable}}
| common, by region (by coord is a custom graticule creator)
|-
| {{cmd|v.neighbors}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.nodes}}
| {{ModuleAvailable}}
|
|-
| {{cmd|v.net.alloc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.allpairs}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.bridge}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.centrality}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.components}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.connectivity}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.distance}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.flow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.iso}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.path}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.salesman}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.spanningtree}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.steiner}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.timetable}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.visibility}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.normal}}
| {{ModuleNotAvailableLo}}
| common
|-
| {{cmd|v.out.ascii}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.dxf}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.gpsbabel}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.out.ogr}}
| {{ModuleAvailable}}
| 6.3/6.4/common x4, shapefile, generic, gml, mapinfo; 6.x: PostgreSQL
|-
| {{cmd|v.out.pov}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.svg}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.vtk}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.outlier}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.overlay}}
| {{ModuleAvailable}}
| common x4, and, or, not, xor
|-
| {{cmd|v.parallel}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.patch}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.perturb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.proj}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.qcount}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.random}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.rast.stats}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.reclass}}
| {{ModuleAvailable}}
| common x2, attr, file
|-
| {{cmd|v.report}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.sample}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.segment}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.select}}
| {{ModuleAvailable}}
| common, v.select.overlap
|-
| {{cmd|v.split}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.support}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.surf.bspline}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.surf.idw}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.surf.rst}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.to.3d}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.to.db}}
| {{ModuleAvailable}}
| 6.3/6.4
|-
| {{cmd|v.to.points}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.to.rast}}
| {{ModuleAvailable}}
| common x2, attr, constant
|-
| {{cmd|v.to.rast3}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.transform}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.type}}
| {{ModuleAvailable}}
| common x4, b2l, l2b, c2p, p2c
|-
| {{cmd|v.univar}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.univar.sh}}
| {{ModuleNotRelevant}}
| old, not needed
|-
| {{cmd|v.vol.rst}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.voronoi}}
| {{ModuleAvailable}}
| common x2, line, area; https://trac.osgeo.org/grass/ticket/957
|-
| {{cmd|v.what}}
| {{ModuleNotRelevant}}
| QGIS GUI supplies query at location function
|-
| {{cmd|v.what.rast}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.what.vect}}
| {{ModuleAvailable}}
| common
|}

=== GUI and command modules ===
{| class="wikitable sortable"
|+ GUI modules 
! Module
! Status
! Comments
|-
| {{cmd|gis.m}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|nviz}}
| {{ModuleAvailable}}
| common
|-
| shell
| {{ModuleAvailable}}
| common
|-
| {{cmd|xganim}}
| {{ModuleNotAvailableLo}}
|
|}

=== Display modules ===

{| class="wikitable "
|+ d.* 
|-
| '' None of the display modules will be relevant. Display functionality is handled in the QGIS GUI. ''

<!--
! Module
! Priority
! Status
! Comments
|-
| {{cmd|d.ask}}
|
|
|
|-
| {{cmd|d.barscale}}
|
|
|
|-
| {{cmd|d.colorlist}}
|
|
|
|-
| {{cmd|d.colors}}
|
|
|
|-
| {{cmd|d.colortable}}
|
|
|
|-
| {{cmd|d.correlate}}
|
|
|
|-
| {{cmd|d.erase}}
|
|
|
|-
| {{cmd|d.extend}}
|
|
|
|-
| {{cmd|d.extract}}
|
|
|
|-
| {{cmd|d.font}}
|
|
|
|-
| {{cmd|d.font.freetype}}
|
|
|
|-
| {{cmd|d.frame}}
|
|
|
|-
| {{cmd|d.geodesic}}
|
|
|
|-
| {{cmd|d.graph}}
|
|
|
|-
| {{cmd|d.grid}}
|
|
|
|-
| {{cmd|d.his}}
|
|
|
|-
| {{cmd|d.histogram}}
|
|
|
|-
| {{cmd|d.info}}
|
|
|
|-
| {{cmd|d.labels}}
|
|
|
|-
| {{cmd|d.legend}}
|
|
|
|-
| {{cmd|d.linegraph}}
|
|
|
|-
| {{cmd|d.m}}
|
|
|
|-
| {{cmd|d.mapgraph}}
|
|
|
|-
| {{cmd|d.measure}}
|
|
|
|-
| {{cmd|d.menu}}
|
|
|
|-
| {{cmd|d.mon}}
|
|
|
|-
| {{cmd|d.monsize}}
|
|
|
|-
| {{cmd|d.mvmon}}
|
|
|
|-
| {{cmd|d.nviz}}
|
|
|
|-
| {{cmd|d.out.file}}
|
|
|
|-
| {{cmd|d.out.gpsdrive}}
|
|
|
|-
| {{cmd|d.out.png}}
|
|
|
|-
| {{cmd|d.paint.labels}}
|
|
|
|-
| {{cmd|d.path}}
|
|
|
|-
| {{cmd|d.polar}}
|
|
|
|-
| {{cmd|d.profile}}
|
|
|
|-
| {{cmd|d.rast}}
|
|
|
|-
| {{cmd|d.rast.arrow}}
|
|
|
|-
| {{cmd|d.rast.edit}}
|
|
|
|-
| {{cmd|d.rast.leg}}
|
|
|
|-
| {{cmd|d.rast.num}}
|
|
|
|-
| {{cmd|d.redraw}}
|
|
|
|-
| {{cmd|d.resize}}
|
|
|
|-
| {{cmd|d.rgb}}
|
|
|
|-
| {{cmd|d.rhumbline}}
|
|
|
|-
| {{cmd|d.save}}
|
|
|
|-
| {{cmd|d.shadedmap}}
|
|
|
|-
| {{cmd|d.slide.show}}
|
|
|
|-
| {{cmd|d.split}}
|
|
|
|-
| {{cmd|d.split.frame}}
|
|
|
|-
| {{cmd|d.text}}
|
|
|
|-
| {{cmd|d.text.freetype}}
|
|
|
|-
| {{cmd|d.thematic.area}}
|
|
|
|-
| {{cmd|d.title}}
|
|
|
|-
| {{cmd|d.vect}}
|
|
|
|-
| {{cmd|d.vect.chart}}
|
|sortable"
|+

GRASS-QGIS relevant module list

2010-10-30T15:08:38Z

⚠️Micha: /* General modules */

= GRASS modules available in the QGIS toolbox =
* See [[Development#GRASS_and_QGIS|GRASS and QGIS]]

== List of GRASS modules relevant to QGIS ==

=== Status Templates ===
{| class="wikitable1"
| Present in QGIS:
| {{ModuleAvailable}}
|-
| Present in QGIS but shouldn't be
|
|-
| Not present in QGIS - High Priority:
| {{ModuleNotAvailable}}
|-
| Not present in QGIS - Low Priority:
| {{ModuleNotAvailableLo}}
|-
| Not relevant to QGIS:
| {{ModuleNotRelevant}}
|}

* "Status" is for modules currently present in qgis source code dir src/plugins/grass/modules-*/
* Color coding indicates availability of module in the GRASS Toolbox

=== Database modules ===

{| class="wikitable sortable"
|+ db.* 
! Module
! Status
! Comments
|-
| {{cmd|db.columns}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|db.connect}}
| {{ModuleAvailable}}
| login; generic, schema, which
|-
| {{cmd|db.copy}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.describe}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.drivers}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.dropcol}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.droptable}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.execute}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.in.ogr}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.login}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.out.ogr}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.select}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.tables}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|db.test}}
| {{ModuleNotAvailableLo}}
|
|}

=== General modules ===

{| class="wikitable sortable"
|+ g.* 
! Module
! Status
! Comments
|-
| {{cmd|g.access}}
|
|
|-
| {{cmd|g.ask}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.copy}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.dirseps}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.extension}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.filename}}
|{{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.findetc}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.findfile}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.gisenv}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|g.gui}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.list}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.manual}}
| {{ModuleAvailable}}
|
|-
| {{cmd|g.mapset}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.mapsets}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.message}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.mkfontcap}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.mlist}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.mremove}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|g.parser}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.pnmcomp}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.proj}}
| {{ModuleAvailable}}
| generic, ascii, geo, print, proj
|-
| {{cmd|g.region}}
| {{ModuleAvailable}}
| save, zoom, multi-rast multi-vect
|-
| {{cmd|g.remove}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.rename}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.setproj}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|g.tempfile}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.transform}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|g.version}}
| {{ModuleNotRelevant}}
| Not really relevant
|}

=== Imagery modules ===

''Essentially these are raster modules that deal with satellite or aerial photography.''

{| class="wikitable sortable"
|+ i.* 
! Module
! Status
! Comments
|-
| {{cmd|i.atcorr}}
| {{ModuleNotAvailable|lo}}
|
|-
| {{cmd|i.cca}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.class}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|i.cluster}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.fft}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.fusion.brovey}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.gensig}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.gensigset}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.group}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.his.rgb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.ifft}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.image.mosaic}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.in.spotvgt}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|i.landsat.rgb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.maxlik}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.oif}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.ortho.photo}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|i.pca}}
| {{ModuleNotAvailableLo}}
|
|
|-
| {{cmd|i.points}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|i.rectify}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|i.rgb.his}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.smap}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.spectral}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|i.target}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.tasscap}}
| {{ModuleAvailable}}
| common x3
|-
| {{cmd|i.vpoints}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|i.zc}}
|{{ModuleAvailable}}
| common
|}

=== Miscellaneous modules ===

{| class="wikitable sortable"
|+ m.* 
! Module
! Status
! Comments
|-
| {{cmd|m.cogo}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|m.proj}}
| {{ModuleAvailable}}
| common
|}

=== Paint modules ===

''These have been abandoned in GRASS 6.''

{| class="wikitable sortable"
|+ p.* 
! Module
! Status
! Comments
|-
| {{cmd|p.out.vrml}}
| {{ModuleNotRelevant}}
| old & renamed; not for QGIS
|}

=== PostScript modules ===

{| class="wikitable sortable"
|+ ps.* 
! Module
! Status
! Comments
|-
| {{cmd|ps.map}}
| {{ModuleNotRelevant}}
| QGIS has its own map composer, so this probably isn't needed.
|}

=== Raster modules ===

{| class="wikitable sortable"
|+ r.* 
! Module
! Status
! Comments
|-
| {{cmd|r.average}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.basins.fill}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.bilinear}}
| {{ModuleAvailable}}
| modules-6.4 ''Please use "r.resamp.interp" instead.''
|-
| {{cmd|r.bitpattern}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.blend}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.buffer}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.carve}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.category}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.cats}}
| {{ModuleNotRelevant}}
| Wrapper script for backwards compatibility.
|-
| {{cmd|r.circle}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.clump}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.coin}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.colors}}
| {{ModuleAvailable}}
| common x4, generic, rast, rules, table
|-
| {{cmd|r.colors.stddev}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|r.composite}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.compress}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.contour}}
| {{ModuleAvailable}}
| common x2
|-
| {{cmd|r.cost}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.covar}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.cross}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.describe}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.digit}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|r.distance}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.drain}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.external}}
| {{ModuleAvailable}}
| modules-6.4 x3
|-
| {{cmd|r.fill.dir}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.fillnulls}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.flow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.grow}}
| {{ModuleAvailable}}
| 6.4/common
|-
| {{cmd|r.grow.distance}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.gwflow}}
| {{ModuleNotAvailableLo}}
| ground water flow modeling
|-
| {{cmd|r.his}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.horizon}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.in.arc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.ascii}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.aster}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.bin}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.gdal}}
|{{ModuleAvailable}}
| common x4, generic, loc, qgis.loc, qgis
|-
| {{cmd|r.in.gridatb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.mat}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.poly}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.srtm}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.wms}}
| {{ModuleAvailable}}
| common, somewhat brittle
|-
| {{cmd|r.in.xyz}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.info}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|r.kappa}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.lake}}
| {{ModuleAvailable}}
| common x3, generic, seed, xy
|-
| {{cmd|r.le.patch}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.le.pixel}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.le.setup}}
| {{ModuleNotAvailable}}
| Landscape Ecology analyses
|-
| {{cmd|r.le.trace}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.cwed}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.dominance}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.edgedensity}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.mpa}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.mps}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.padcv}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.padrange}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.padsd}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.patchdensity}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.patchnum}}
| {{ModuleNotAvailablei}}
|
|-
| {{cmd|r.li.richness}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.setup}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.shannon}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.shape}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.simpson}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.los}}
| {{ModuleAvailable}}
| common
|
|-
| {{cmd|r.mapcalc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.mapcalculator}}
| {{ModuleAvailable}}
| common, gui wrapper (need both?)
|-
| {{cmd|r.mask}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.median}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.mfilter}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.mfilter.fp}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.mode}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.neighbors}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.null}}
| {{ModuleAvailable}}
| common x4, null, to, val, r.to.null?
|-
| {{cmd|r.out.arc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.ascii}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.bin}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.out.gdal}}
| {{ModuleAvailable}}
| common x2 generic, GeoTiff
|-
| {{cmd|r.out.gdal.sh}}
| {{ModuleNotAvailableLo}}
| old full map extent version
|-
| {{cmd|r.out.gridatb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.mat}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.mpeg}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.png}}
| {{ModuleAvailable}}
| common, important once transparency and Worldfile gets backported from 6.5svn (for OpenLayers/KML tile source)
|-
| {{cmd|r.out.pov}}
| {{ModuleAvailable}}
| common POVray
|-
| {{cmd|r.out.ppm}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.ppm3}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.tiff}}
| {{ModuleAvailable}}
| common, ''visual'' RGB output, not data values (use r.out.gdal for that)
|-
| {{cmd|r.out.vrml}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.vtk}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.xyz}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.param.scale}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.patch}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.plane}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.profile}}
| {{ModuleNotAvailableLo}}
| Python plugin available to find transect profile
|-
| {{cmd|r.proj}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.quant}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.quantile}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.random}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.random.cells}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.random.surface}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.reclass}}
| {{ModuleAvailable}}
| common x2, generic, file
|-
| {{cmd|r.reclass.area}}
| {{ModuleAvailable}}
| common x3, generic, greater, lesser
|-
| {{cmd|r.recode}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.region}}
| {{ModuleAvailable}}
| Oversold?, common x6, generic, rast, vect, region, edge, alignTo
|-
| {{cmd|r.regression.line}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.report}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resamp.interp}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resamp.rst}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resamp.stats}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resample}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.rescale}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.rescale.eq}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.ros}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.series}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.shaded.relief}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.sim.sediment}}
| {{ModuleNotAvailableLo}}
|
|
|-
| {{cmd|r.sim.water}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.slope.aspect}}
| {{ModuleAvailable}}
| common x2, slope, aspect, '''but not others'''
|-
| {{cmd|r.spread}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.spreadpath}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.statistics}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.stats}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.sum}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.sun}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.sunmask}}
| {{ModuleAvailable}}
| common x2, date_time, position
|-
| {{cmd|r.support}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.support.stats}}
| {{ModuleAvailable}}
| common, maybe not needed
|-
| {{cmd|r.surf.area}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.surf.contour}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.surf.fractal}}
| {{ModuleAvailable}}
| 6.3/6.4
|-
| {{cmd|r.surf.gauss}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.surf.idw}}
| {{ModuleAvailable}}
| common, faster
|-
| {{cmd|r.surf.idw2}}
| {{ModuleAvailable}}
| common, supports floating point
|-
| {{cmd|r.surf.random}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.terraflow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.terraflow.short}}
| {{ModuleNotRelevant}}
| Not needed
|-
| {{cmd|r.texture}}
| {{ModuleAvailable}}
| common x2, generic, bis
|-
| {{cmd|r.thin}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.tileset}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|r.timestamp}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|r.to.rast3}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.to.rast3elev}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.to.vect}}
| {{ModuleAvailable}}
| common x3, point, line, area
|-
| {{cmd|r.topidx}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.topmodel}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.transect}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.univar}}
| {{ModuleAvailable}}
| common
|
|-
| {{cmd|r.univar.sh}}
| {{ModuleNotRelevant}}
| Not needed
|-
| {{cmd|r.volume}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.walk}}
| {{ModuleNotAvailable}}
|
|
|-
| {{cmd|r.water.outlet}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.watershed}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.what}}
| {{ModuleNotRelevant}}
| Handled in the QGIS GUI
|-
| {{cmd|r.what.color}}
| {{ModuleNotRelevant}}
|
|-
|}

=== 3D raster modules ===

{| class="wikitable sortable"
|+ r3.* 
! Module
! Status
! Comments
|-
| {{cmd|r3.cross.rast}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.gwflow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.in.ascii}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.in.v5d}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.info}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mapcalc}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mapcalculator}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mask}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mkdspf}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.null}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.out.ascii}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.out.v5d}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.out.vtk}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.stats}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.timestamp}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.to.rast}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.univar}}
| {{ModuleNotAvailableLo}}
|
|}

=== Vector modules ===

{| class="wikitable sortable"
|+ v.* 
! Module
! Status
! Comments
|-
| {{cmd|v.buffer}}
| {{ModuleAvailable}}
| 6.3/6.4, https://trac.osgeo.org/grass/ticket/994
|-
| {{cmd|v.build}}
| {{ModuleAvailable}}
| see specific modules
|-
| {{cmd|v.build.all}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.build.polylines}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.category}}
| {{ModuleAvailable}}
| common x4, add, del, sum, change
|-
| {{cmd|v.centroids}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.class}}
| {{ModuleNotAvailableLo}}
| Fuctionality supplied in QGIS Vector symbology
|-
| {{cmd|v.clean}}
| {{ModuleAvailable}}
| common x13
|-
| {{cmd|v.colors}}
| {{ModuleNotRelevant}}
| Fuctionality supplied in QGIS Vector symbology
|-
| {{cmd|v.convert}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.convert.all}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.db.addcol}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.addtable}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.connect}}
| {{ModuleAvailable}}
| common, v.db.sconnect? v.db.what.connect?
|-
| {{cmd|v.db.dropcol}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|v.db.droptable}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.join}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.reconnect.all}}
| {{ModuleAvailable}}
| common
|
|-
| {{cmd|v.db.renamecol}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.select}}
| {{ModuleAvailable}}
| 6.3/6.4 x2
|-
| {{cmd|v.db.univar}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.update}}
| {{ModuleAvailable}}
| common x4, const, op, op query, query
|-
| {{cmd|v.delaunay}}
| {{ModuleAvailable}}
| common x2, line, area
|-
| {{cmd|v.digit}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|v.dissolve}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.distance}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.drape}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.edit}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|v.external}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.extract}}
| {{ModuleAvailable}}
| common, list, where
|-
| {{cmd|v.extrude}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.generalize}}
| {{ModuleAvailable}}
| common, complicated
|-
| {{cmd|v.hull}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.ascii}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|v.in.db}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.dxf}}
| {{ModuleAvailable}}
| common x2, generic, multi
|-
| {{cmd|v.in.e00}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.garmin}}
| {{ModuleAvailable}}
| common, only for old serial models
|-
| {{cmd|v.in.geonames}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|v.in.gns}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|v.in.gpsbabel}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.lines|version=65}}
| {{ModuleAvailable}}
| Only in 6.5svn, new wrapper script around v.in.mapgen with more obvious name
|-
| {{cmd|v.in.mapgen}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.ogr}}
| {{ModuleAvailable}}
| common x7
|-
| {{cmd|v.in.region}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.sites}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.in.sites.all}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.in.wfs}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|v.info}}
| {{ModuleNotRelevant}}
| Functionality supplied in Toolbox
|-
| {{cmd|v.kcv}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.kernel}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.krige.py}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.label}}
| {{ModuleNotRelevant}}
| Functionality supplied in QGIS GUI
|-
| {{cmd|v.label.sa}}
| {{ModuleNotRelevant}}
| Functionality supplied in QGIS GUI
|-
| {{cmd|v.lidar.correction}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.lidar.edgedetection}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lidar.growing}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lrs.create}}
| {{ModuleNotAvailableLo}}
| Python plugin for Linear Referencing available
|-
| {{cmd|v.lrs.label}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lrs.segment}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lrs.where}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.mkgrid}}
| {{ModuleAvailable}}
| common, by region (by coord is a custom graticule creator)
|-
| {{cmd|v.neighbors}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.nodes}}
| {{ModuleAvailable}}
|
|-
| {{cmd|v.net.alloc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.allpairs}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.bridge}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.centrality}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.components}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.connectivity}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.distance}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.flow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.iso}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.path}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.salesman}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.spanningtree}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.steiner}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.timetable}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.visibility}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.normal}}
| {{ModuleNotAvailableLo}}
| common
|-
| {{cmd|v.out.ascii}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.dxf}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.gpsbabel}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.out.ogr}}
| {{ModuleAvailable}}
| 6.3/6.4/common x4, shapefile, generic, gml, mapinfo; 6.x: PostgreSQL
|-
| {{cmd|v.out.pov}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.svg}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.vtk}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.outlier}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.overlay}}
| {{ModuleAvailable}}
| common x4, and, or, not, xor
|-
| {{cmd|v.parallel}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.patch}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.perturb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.proj}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.qcount}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.random}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.rast.stats}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.reclass}}
| {{ModuleAvailable}}
| common x2, attr, file
|-
| {{cmd|v.report}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.sample}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.segment}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.select}}
| {{ModuleAvailable}}
| common, v.select.overlap
|-
| {{cmd|v.split}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.support}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.surf.bspline}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.surf.idw}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.surf.rst}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.to.3d}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.to.db}}
| {{ModuleAvailable}}
| 6.3/6.4
|-
| {{cmd|v.to.points}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.to.rast}}
| {{ModuleAvailable}}
| common x2, attr, constant
|-
| {{cmd|v.to.rast3}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.transform}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.type}}
| {{ModuleAvailable}}
| common x4, b2l, l2b, c2p, p2c
|-
| {{cmd|v.univar}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.univar.sh}}
| {{ModuleNotRelevant}}
| old, not needed
|-
| {{cmd|v.vol.rst}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.voronoi}}
| {{ModuleAvailable}}
| common x2, line, area; https://trac.osgeo.org/grass/ticket/957
|-
| {{cmd|v.what}}
| {{ModuleNotRelevant}}
| QGIS GUI supplies query at location function
|-
| {{cmd|v.what.rast}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.what.vect}}
| {{ModuleAvailable}}
| common
|}

=== GUI and command modules ===
{| class="wikitable sortable"
|+ GUI modules 
! Module
! Status
! Comments
|-
| {{cmd|gis.m}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|nviz}}
| {{ModuleAvailable}}
| common
|-
| shell
| {{ModuleAvailable}}
| common
|-
| {{cmd|xganim}}
| {{ModuleNotAvailableLo}}
|
|}

=== Display modules ===

{| class="wikitable "
|+ d.* 
|-
| '' None of the display modules will be relevant. Display functionality is handled in the QGIS GUI. ''

<!--
! Module
! Priority
! Status
! Comments
|-
| {{cmd|d.ask}}
|
|
|
|-
| {{cmd|d.barscale}}
|
|
|
|-
| {{cmd|d.colorlist}}
|
|
|
|-
| {{cmd|d.colors}}
|
|
|
|-
| {{cmd|d.colortable}}
|
|
|
|-
| {{cmd|d.correlate}}
|
|
|
|-
| {{cmd|d.erase}}
|
|
|
|-
| {{cmd|d.extend}}
|
|
|
|-
| {{cmd|d.extract}}
|
|
|
|-
| {{cmd|d.font}}
|
|
|
|-
| {{cmd|d.font.freetype}}
|
|
|
|-
| {{cmd|d.frame}}
|
|
|
|-
| {{cmd|d.geodesic}}
|
|
|
|-
| {{cmd|d.graph}}
|
|
|
|-
| {{cmd|d.grid}}
|
|
|
|-
| {{cmd|d.his}}
|
|
|
|-
| {{cmd|d.histogram}}
|
|
|
|-
| {{cmd|d.info}}
|
|
|
|-
| {{cmd|d.labels}}
|
|
|
|-
| {{cmd|d.legend}}
|
|
|
|-
| {{cmd|d.linegraph}}
|
|
|
|-
| {{cmd|d.m}}
|
|
|
|-
| {{cmd|d.mapgraph}}
|
|
|
|-
| {{cmd|d.measure}}
|
|
|
|-
| {{cmd|d.menu}}
|
|
|
|-
| {{cmd|d.mon}}
|
|
|
|-
| {{cmd|d.monsize}}
|
|
|
|-
| {{cmd|d.mvmon}}
|
|
|
|-
| {{cmd|d.nviz}}
|
|
|
|-
| {{cmd|d.out.file}}
|
|
|
|-
| {{cmd|d.out.gpsdrive}}
|
|
|
|-
| {{cmd|d.out.png}}
|
|
|
|-
| {{cmd|d.paint.labels}}
|
|
|
|-
| {{cmd|d.path}}
|
|
|
|-
| {{cmd|d.polar}}
|
|
|
|-
| {{cmd|d.profile}}
|
|
|
|-
| {{cmd|d.rast}}
|
|
|
|-
| {{cmd|d.rast.arrow}}
|
|
|
|-
| {{cmd|d.rast.edit}}
|
|
|
|-
| {{cmd|d.rast.leg}}
|
|
|
|-
| {{cmd|d.rast.num}}
|
|
|
|-
| {{cmd|d.redraw}}
|
|
|
|-
| {{cmd|d.resize}}
|
|
|
|-
| {{cmd|d.rgb}}
|
|
|
|-
| {{cmd|d.rhumbline}}
|
|
|
|-
| {{cmd|d.save}}
|
|
|
|-
| {{cmd|d.shadedmap}}
|
|
|
|-
| {{cmd|d.slide.show}}
|
|
|
|-
| {{cmd|d.split}}
|
|
|
|-
| {{cmd|d.split.frame}}
|
|
|
|-
| {{cmd|d.text}}
|
|
|
|-
| {{cmd|d.text.freetype}}
|
|
|
|-
| {{cmd|d.thematic.area}}
|
|
|
|-
| {{cmd|d.title}}
|
|
|
|-
| {{cmd|d.vect}}
|
|
|
|-
| {{cmd|d.vect.chart}}
|
|sortable"
|+

Template:ModuleNotAvailableLo

2010-10-30T15:07:54Z

⚠️Micha: Created page with "<onlyinclude> <div style="background-color: #F79FA0;"> Missing - Lo </div> </onlyinclude> Template to color GRASS-QGIS Relevant Modules table"

<onlyinclude>
<div style="background-color: #F79FA0;">
Missing - Lo
</div>
</onlyinclude>
Template to color GRASS-QGIS Relevant Modules table

GRASS-QGIS relevant module list

2010-10-30T15:06:38Z

⚠️Micha: /* GRASS modules available in the QGIS toolbox */

= GRASS modules available in the QGIS toolbox =
* See [[Development#GRASS_and_QGIS|GRASS and QGIS]]

== List of GRASS modules relevant to QGIS ==

=== Status Templates ===
{| class="wikitable1"
| Present in QGIS:
| {{ModuleAvailable}}
|-
| Present in QGIS but shouldn't be
|
|-
| Not present in QGIS - High Priority:
| {{ModuleNotAvailable}}
|-
| Not present in QGIS - Low Priority:
| {{ModuleNotAvailableLo}}
|-
| Not relevant to QGIS:
| {{ModuleNotRelevant}}
|}

* "Status" is for modules currently present in qgis source code dir src/plugins/grass/modules-*/
* Color coding indicates availability of module in the GRASS Toolbox

=== Database modules ===

{| class="wikitable sortable"
|+ db.* 
! Module
! Status
! Comments
|-
| {{cmd|db.columns}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|db.connect}}
| {{ModuleAvailable}}
| login; generic, schema, which
|-
| {{cmd|db.copy}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.describe}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.drivers}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.dropcol}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.droptable}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|db.execute}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.in.ogr}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.login}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.out.ogr}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.select}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.tables}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|db.test}}
| {{ModuleNotAvailableLo}}
|
|}

=== General modules ===

{| class="wikitable sortable"
|+ g.* 
! Module
! Status
! Comments
|-
| {{cmd|g.access}}
|
|
|-
| {{cmd|g.ask}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.copy}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.dirseps}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.extension}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.filename}}
|{{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.findetc}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.findfile}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.gisenv}}
| {{ModuleNotAvailablelo}}
|
|-
| {{cmd|g.gui}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.list}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.manual}}
| {{ModuleAvailable}}
|
|-
| {{cmd|g.mapset}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.mapsets}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.message}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.mkfontcap}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.mlist}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.mremove}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|g.parser}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.pnmcomp}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.proj}}
| {{ModuleAvailable}}
| generic, ascii, geo, print, proj
|-
| {{cmd|g.region}}
| {{ModuleAvailable}}
| save, zoom, multi-rast multi-vect
|-
| {{cmd|g.remove}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.rename}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.setproj}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|g.tempfile}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.transform}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|g.version}}
| {{ModuleNotRelevant}}
| Not really relevant
|}

=== Imagery modules ===

''Essentially these are raster modules that deal with satellite or aerial photography.''

{| class="wikitable sortable"
|+ i.* 
! Module
! Status
! Comments
|-
| {{cmd|i.atcorr}}
| {{ModuleNotAvailable|lo}}
|
|-
| {{cmd|i.cca}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.class}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|i.cluster}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.fft}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.fusion.brovey}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.gensig}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.gensigset}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.group}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.his.rgb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.ifft}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.image.mosaic}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.in.spotvgt}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|i.landsat.rgb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.maxlik}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.oif}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.ortho.photo}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|i.pca}}
| {{ModuleNotAvailableLo}}
|
|
|-
| {{cmd|i.points}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|i.rectify}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|i.rgb.his}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.smap}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.spectral}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|i.target}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|i.tasscap}}
| {{ModuleAvailable}}
| common x3
|-
| {{cmd|i.vpoints}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|i.zc}}
|{{ModuleAvailable}}
| common
|}

=== Miscellaneous modules ===

{| class="wikitable sortable"
|+ m.* 
! Module
! Status
! Comments
|-
| {{cmd|m.cogo}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|m.proj}}
| {{ModuleAvailable}}
| common
|}

=== Paint modules ===

''These have been abandoned in GRASS 6.''

{| class="wikitable sortable"
|+ p.* 
! Module
! Status
! Comments
|-
| {{cmd|p.out.vrml}}
| {{ModuleNotRelevant}}
| old & renamed; not for QGIS
|}

=== PostScript modules ===

{| class="wikitable sortable"
|+ ps.* 
! Module
! Status
! Comments
|-
| {{cmd|ps.map}}
| {{ModuleNotRelevant}}
| QGIS has its own map composer, so this probably isn't needed.
|}

=== Raster modules ===

{| class="wikitable sortable"
|+ r.* 
! Module
! Status
! Comments
|-
| {{cmd|r.average}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.basins.fill}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.bilinear}}
| {{ModuleAvailable}}
| modules-6.4 ''Please use "r.resamp.interp" instead.''
|-
| {{cmd|r.bitpattern}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.blend}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.buffer}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.carve}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.category}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.cats}}
| {{ModuleNotRelevant}}
| Wrapper script for backwards compatibility.
|-
| {{cmd|r.circle}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.clump}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.coin}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.colors}}
| {{ModuleAvailable}}
| common x4, generic, rast, rules, table
|-
| {{cmd|r.colors.stddev}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|r.composite}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.compress}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.contour}}
| {{ModuleAvailable}}
| common x2
|-
| {{cmd|r.cost}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.covar}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.cross}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.describe}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.digit}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|r.distance}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.drain}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.external}}
| {{ModuleAvailable}}
| modules-6.4 x3
|-
| {{cmd|r.fill.dir}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.fillnulls}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.flow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.grow}}
| {{ModuleAvailable}}
| 6.4/common
|-
| {{cmd|r.grow.distance}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.gwflow}}
| {{ModuleNotAvailableLo}}
| ground water flow modeling
|-
| {{cmd|r.his}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.horizon}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.in.arc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.ascii}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.aster}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.bin}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.gdal}}
|{{ModuleAvailable}}
| common x4, generic, loc, qgis.loc, qgis
|-
| {{cmd|r.in.gridatb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.mat}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.poly}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.srtm}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.wms}}
| {{ModuleAvailable}}
| common, somewhat brittle
|-
| {{cmd|r.in.xyz}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.info}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|r.kappa}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.lake}}
| {{ModuleAvailable}}
| common x3, generic, seed, xy
|-
| {{cmd|r.le.patch}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.le.pixel}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.le.setup}}
| {{ModuleNotAvailable}}
| Landscape Ecology analyses
|-
| {{cmd|r.le.trace}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.cwed}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.dominance}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.edgedensity}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.mpa}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.mps}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.padcv}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.padrange}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.padsd}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.patchdensity}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.patchnum}}
| {{ModuleNotAvailablei}}
|
|-
| {{cmd|r.li.richness}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.setup}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.shannon}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.shape}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.li.simpson}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|r.los}}
| {{ModuleAvailable}}
| common
|
|-
| {{cmd|r.mapcalc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.mapcalculator}}
| {{ModuleAvailable}}
| common, gui wrapper (need both?)
|-
| {{cmd|r.mask}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.median}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.mfilter}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.mfilter.fp}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.mode}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.neighbors}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.null}}
| {{ModuleAvailable}}
| common x4, null, to, val, r.to.null?
|-
| {{cmd|r.out.arc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.ascii}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.bin}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.out.gdal}}
| {{ModuleAvailable}}
| common x2 generic, GeoTiff
|-
| {{cmd|r.out.gdal.sh}}
| {{ModuleNotAvailableLo}}
| old full map extent version
|-
| {{cmd|r.out.gridatb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.mat}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.mpeg}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.png}}
| {{ModuleAvailable}}
| common, important once transparency and Worldfile gets backported from 6.5svn (for OpenLayers/KML tile source)
|-
| {{cmd|r.out.pov}}
| {{ModuleAvailable}}
| common POVray
|-
| {{cmd|r.out.ppm}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.ppm3}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.tiff}}
| {{ModuleAvailable}}
| common, ''visual'' RGB output, not data values (use r.out.gdal for that)
|-
| {{cmd|r.out.vrml}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.vtk}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.xyz}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.param.scale}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.patch}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.plane}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.profile}}
| {{ModuleNotAvailableLo}}
| Python plugin available to find transect profile
|-
| {{cmd|r.proj}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.quant}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.quantile}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.random}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.random.cells}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.random.surface}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.reclass}}
| {{ModuleAvailable}}
| common x2, generic, file
|-
| {{cmd|r.reclass.area}}
| {{ModuleAvailable}}
| common x3, generic, greater, lesser
|-
| {{cmd|r.recode}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.region}}
| {{ModuleAvailable}}
| Oversold?, common x6, generic, rast, vect, region, edge, alignTo
|-
| {{cmd|r.regression.line}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.report}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resamp.interp}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resamp.rst}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resamp.stats}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resample}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.rescale}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.rescale.eq}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.ros}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.series}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.shaded.relief}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.sim.sediment}}
| {{ModuleNotAvailableLo}}
|
|
|-
| {{cmd|r.sim.water}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.slope.aspect}}
| {{ModuleAvailable}}
| common x2, slope, aspect, '''but not others'''
|-
| {{cmd|r.spread}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.spreadpath}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.statistics}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.stats}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.sum}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.sun}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.sunmask}}
| {{ModuleAvailable}}
| common x2, date_time, position
|-
| {{cmd|r.support}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.support.stats}}
| {{ModuleAvailable}}
| common, maybe not needed
|-
| {{cmd|r.surf.area}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.surf.contour}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.surf.fractal}}
| {{ModuleAvailable}}
| 6.3/6.4
|-
| {{cmd|r.surf.gauss}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.surf.idw}}
| {{ModuleAvailable}}
| common, faster
|-
| {{cmd|r.surf.idw2}}
| {{ModuleAvailable}}
| common, supports floating point
|-
| {{cmd|r.surf.random}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.terraflow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.terraflow.short}}
| {{ModuleNotRelevant}}
| Not needed
|-
| {{cmd|r.texture}}
| {{ModuleAvailable}}
| common x2, generic, bis
|-
| {{cmd|r.thin}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.tileset}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|r.timestamp}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|r.to.rast3}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.to.rast3elev}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.to.vect}}
| {{ModuleAvailable}}
| common x3, point, line, area
|-
| {{cmd|r.topidx}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.topmodel}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r.transect}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.univar}}
| {{ModuleAvailable}}
| common
|
|-
| {{cmd|r.univar.sh}}
| {{ModuleNotRelevant}}
| Not needed
|-
| {{cmd|r.volume}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.walk}}
| {{ModuleNotAvailable}}
|
|
|-
| {{cmd|r.water.outlet}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.watershed}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.what}}
| {{ModuleNotRelevant}}
| Handled in the QGIS GUI
|-
| {{cmd|r.what.color}}
| {{ModuleNotRelevant}}
|
|-
|}

=== 3D raster modules ===

{| class="wikitable sortable"
|+ r3.* 
! Module
! Status
! Comments
|-
| {{cmd|r3.cross.rast}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.gwflow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.in.ascii}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.in.v5d}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.info}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mapcalc}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mapcalculator}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mask}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.mkdspf}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.null}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.out.ascii}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.out.v5d}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.out.vtk}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.stats}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.timestamp}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.to.rast}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|r3.univar}}
| {{ModuleNotAvailableLo}}
|
|}

=== Vector modules ===

{| class="wikitable sortable"
|+ v.* 
! Module
! Status
! Comments
|-
| {{cmd|v.buffer}}
| {{ModuleAvailable}}
| 6.3/6.4, https://trac.osgeo.org/grass/ticket/994
|-
| {{cmd|v.build}}
| {{ModuleAvailable}}
| see specific modules
|-
| {{cmd|v.build.all}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.build.polylines}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.category}}
| {{ModuleAvailable}}
| common x4, add, del, sum, change
|-
| {{cmd|v.centroids}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.class}}
| {{ModuleNotAvailableLo}}
| Fuctionality supplied in QGIS Vector symbology
|-
| {{cmd|v.clean}}
| {{ModuleAvailable}}
| common x13
|-
| {{cmd|v.colors}}
| {{ModuleNotRelevant}}
| Fuctionality supplied in QGIS Vector symbology
|-
| {{cmd|v.convert}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.convert.all}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.db.addcol}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.addtable}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.connect}}
| {{ModuleAvailable}}
| common, v.db.sconnect? v.db.what.connect?
|-
| {{cmd|v.db.dropcol}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|v.db.droptable}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.join}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.reconnect.all}}
| {{ModuleAvailable}}
| common
|
|-
| {{cmd|v.db.renamecol}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.select}}
| {{ModuleAvailable}}
| 6.3/6.4 x2
|-
| {{cmd|v.db.univar}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.update}}
| {{ModuleAvailable}}
| common x4, const, op, op query, query
|-
| {{cmd|v.delaunay}}
| {{ModuleAvailable}}
| common x2, line, area
|-
| {{cmd|v.digit}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|v.dissolve}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.distance}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.drape}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.edit}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|v.external}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.extract}}
| {{ModuleAvailable}}
| common, list, where
|-
| {{cmd|v.extrude}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.generalize}}
| {{ModuleAvailable}}
| common, complicated
|-
| {{cmd|v.hull}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.ascii}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|v.in.db}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.dxf}}
| {{ModuleAvailable}}
| common x2, generic, multi
|-
| {{cmd|v.in.e00}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.garmin}}
| {{ModuleAvailable}}
| common, only for old serial models
|-
| {{cmd|v.in.geonames}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|v.in.gns}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|v.in.gpsbabel}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.lines|version=65}}
| {{ModuleAvailable}}
| Only in 6.5svn, new wrapper script around v.in.mapgen with more obvious name
|-
| {{cmd|v.in.mapgen}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.ogr}}
| {{ModuleAvailable}}
| common x7
|-
| {{cmd|v.in.region}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.sites}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.in.sites.all}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.in.wfs}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|v.info}}
| {{ModuleNotRelevant}}
| Functionality supplied in Toolbox
|-
| {{cmd|v.kcv}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.kernel}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.krige.py}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.label}}
| {{ModuleNotRelevant}}
| Functionality supplied in QGIS GUI
|-
| {{cmd|v.label.sa}}
| {{ModuleNotRelevant}}
| Functionality supplied in QGIS GUI
|-
| {{cmd|v.lidar.correction}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.lidar.edgedetection}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lidar.growing}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lrs.create}}
| {{ModuleNotAvailableLo}}
| Python plugin for Linear Referencing available
|-
| {{cmd|v.lrs.label}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lrs.segment}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.lrs.where}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.mkgrid}}
| {{ModuleAvailable}}
| common, by region (by coord is a custom graticule creator)
|-
| {{cmd|v.neighbors}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.nodes}}
| {{ModuleAvailable}}
|
|-
| {{cmd|v.net.alloc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.allpairs}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.bridge}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.centrality}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.components}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.connectivity}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.distance}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.flow}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.iso}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.path}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.salesman}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.spanningtree}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.steiner}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.timetable}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.net.visibility}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.normal}}
| {{ModuleNotAvailableLo}}
| common
|-
| {{cmd|v.out.ascii}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.dxf}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.gpsbabel}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.out.ogr}}
| {{ModuleAvailable}}
| 6.3/6.4/common x4, shapefile, generic, gml, mapinfo; 6.x: PostgreSQL
|-
| {{cmd|v.out.pov}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.svg}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.vtk}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.outlier}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.overlay}}
| {{ModuleAvailable}}
| common x4, and, or, not, xor
|-
| {{cmd|v.parallel}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.patch}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.perturb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.proj}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.qcount}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.random}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.rast.stats}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.reclass}}
| {{ModuleAvailable}}
| common x2, attr, file
|-
| {{cmd|v.report}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.sample}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.segment}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.select}}
| {{ModuleAvailable}}
| common, v.select.overlap
|-
| {{cmd|v.split}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.support}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.surf.bspline}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.surf.idw}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.surf.rst}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.to.3d}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.to.db}}
| {{ModuleAvailable}}
| 6.3/6.4
|-
| {{cmd|v.to.points}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.to.rast}}
| {{ModuleAvailable}}
| common x2, attr, constant
|-
| {{cmd|v.to.rast3}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.transform}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.type}}
| {{ModuleAvailable}}
| common x4, b2l, l2b, c2p, p2c
|-
| {{cmd|v.univar}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.univar.sh}}
| {{ModuleNotRelevant}}
| old, not needed
|-
| {{cmd|v.vol.rst}}
| {{ModuleNotAvailableLo}}
|
|-
| {{cmd|v.voronoi}}
| {{ModuleAvailable}}
| common x2, line, area; https://trac.osgeo.org/grass/ticket/957
|-
| {{cmd|v.what}}
| {{ModuleNotRelevant}}
| QGIS GUI supplies query at location function
|-
| {{cmd|v.what.rast}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.what.vect}}
| {{ModuleAvailable}}
| common
|}

=== GUI and command modules ===
{| class="wikitable sortable"
|+ GUI modules 
! Module
! Status
! Comments
|-
| {{cmd|gis.m}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|nviz}}
| {{ModuleAvailable}}
| common
|-
| shell
| {{ModuleAvailable}}
| common
|-
| {{cmd|xganim}}
| {{ModuleNotAvailableLo}}
|
|}

=== Display modules ===

{| class="wikitable "
|+ d.* 
|-
| '' None of the display modules will be relevant. Display functionality is handled in the QGIS GUI. ''

<!--
! Module
! Priority
! Status
! Comments
|-
| {{cmd|d.ask}}
|
|
|
|-
| {{cmd|d.barscale}}
|
|
|
|-
| {{cmd|d.colorlist}}
|
|
|
|-
| {{cmd|d.colors}}
|
|
|
|-
| {{cmd|d.colortable}}
|
|
|
|-
| {{cmd|d.correlate}}
|
|
|
|-
| {{cmd|d.erase}}
|
|
|
|-
| {{cmd|d.extend}}
|
|
|
|-
| {{cmd|d.extract}}
|
|
|
|-
| {{cmd|d.font}}
|
|
|
|-
| {{cmd|d.font.freetype}}
|
|
|
|-
| {{cmd|d.frame}}
|
|
|
|-
| {{cmd|d.geodesic}}
|
|
|
|-
| {{cmd|d.graph}}
|
|
|
|-
| {{cmd|d.grid}}
|
|
|
|-
| {{cmd|d.his}}
|
|
|
|-
| {{cmd|d.histogram}}
|
|
|
|-
| {{cmd|d.info}}
|
|
|
|-
| {{cmd|d.labels}}
|
|
|
|-
| {{cmd|d.legend}}
|
|
|
|-
| {{cmd|d.linegraph}}
|
|
|
|-
| {{cmd|d.m}}
|
|
|
|-
| {{cmd|d.mapgraph}}
|
|
|
|-
| {{cmd|d.measure}}
|
|
|
|-
| {{cmd|d.menu}}
|
|
|
|-
| {{cmd|d.mon}}
|
|
|
|-
| {{cmd|d.monsize}}
|
|
|
|-
| {{cmd|d.mvmon}}
|
|
|
|-
| {{cmd|d.nviz}}
|
|
|
|-
| {{cmd|d.out.file}}
|
|
|
|-
| {{cmd|d.out.gpsdrive}}
|
|
|
|-
| {{cmd|d.out.png}}
|
|
|
|-
| {{cmd|d.paint.labels}}
|
|
|
|-
| {{cmd|d.path}}
|
|
|
|-
| {{cmd|d.polar}}
|
|
|
|-
| {{cmd|d.profile}}
|
|
|
|-
| {{cmd|d.rast}}
|
|
|
|-
| {{cmd|d.rast.arrow}}
|
|
|
|-
| {{cmd|d.rast.edit}}
|
|
|
|-
| {{cmd|d.rast.leg}}
|
|
|
|-
| {{cmd|d.rast.num}}
|
|
|
|-
| {{cmd|d.redraw}}
|
|
|
|-
| {{cmd|d.resize}}
|
|
|
|-
| {{cmd|d.rgb}}
|
|
|
|-
| {{cmd|d.rhumbline}}
|
|
|
|-
| {{cmd|d.save}}
|
|
|
|-
| {{cmd|d.shadedmap}}
|
|
|
|-
| {{cmd|d.slide.show}}
|
|
|
|-
| {{cmd|d.split}}
|
|
|
|-
| {{cmd|d.split.frame}}
|
|
|
|-
| {{cmd|d.text}}
|
|
|
|-
| {{cmd|d.text.freetype}}
|
|
|
|-
| {{cmd|d.thematic.area}}
|
|
|
|-
| {{cmd|d.title}}
|
|
|
|-
| {{cmd|d.vect}}
|
|
|
|-
| {{cmd|d.vect.chart}}
|
|sortable"
|+

GRASS-QGIS relevant module list

2010-10-30T14:53:08Z

⚠️Micha: /* List of GRASS modules relevant to QGIS */

= GRASS modules available in the QGIS toolbox =
* See [[Development#GRASS_and_QGIS|GRASS and QGIS]]

== List of GRASS modules relevant to QGIS ==

=== Status Templates ===
{| class="wikitable1"
| Present in QGIS:
| {{ModuleAvailable}}
|-
| Present in QGIS but shouldn't be
|
|-
| Not present in QGIS - High Priority:
| {{ModuleNotAvailable}}
|-
| Not present in QGIS - Low Priority:
| {{ModuleNotAvailable|Lo}}
|-
| Not relevant to QGIS:
| {{ModuleNotRelevant}}
|}

* "Status" is for modules currently present in qgis source code dir src/plugins/grass/modules-*/
* Color coding indicates availability of module in the GRASS Toolbox

=== Database modules ===

{| class="wikitable sortable"
|+ db.* 
! Module
! Status
! Comments
|-
| {{cmd|db.columns}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|db.connect}}
| {{ModuleAvailable}}
| login; generic, schema, which
|-
| {{cmd|db.copy}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.describe}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|db.drivers}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|db.dropcol}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|db.droptable}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|db.execute}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.in.ogr}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.login}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.out.ogr}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.select}}
| {{ModuleAvailable}}
|
|-
| {{cmd|db.tables}}
| {{ModuleNotAvailable}}
|
|-
| {{cmd|db.test}}
| {{ModuleNotAvailable|Lo}}
|
|}

=== General modules ===

{| class="wikitable sortable"
|+ g.* 
! Module
! Status
! Comments
|-
| {{cmd|g.access}}
|
|
|-
| {{cmd|g.ask}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.copy}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.dirseps}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.extension}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.filename}}
|{{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.findetc}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.findfile}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.gisenv}}
| {{ModuleNotAvailable|lo}}
|
|-
| {{cmd|g.gui}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.list}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.manual}}
| {{ModuleAvailable}}
|
|-
| {{cmd|g.mapset}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.mapsets}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.message}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.mkfontcap}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.mlist}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.mremove}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|g.parser}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.pnmcomp}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.proj}}
| {{ModuleAvailable}}
| generic, ascii, geo, print, proj
|-
| {{cmd|g.region}}
| {{ModuleAvailable}}
| save, zoom, multi-rast multi-vect
|-
| {{cmd|g.remove}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.rename}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|g.setproj}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|g.tempfile}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|g.transform}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|g.version}}
| {{ModuleNotRelevant}}
| Not really relevant
|}

=== Imagery modules ===

''Essentially these are raster modules that deal with satellite or aerial photography.''

{| class="wikitable sortable"
|+ i.* 
! Module
! Status
! Comments
|-
| {{cmd|i.atcorr}}
| {{ModuleNotAvailable|lo}}
|
|-
| {{cmd|i.cca}}
| {{ModuleNotAvailable|lo}}
|
|-
| {{cmd|i.class}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|i.cluster}}
| {{ModuleNotAvailable|lo}}
|
|-
| {{cmd|i.fft}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.fusion.brovey}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.gensig}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|i.gensigset}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|i.group}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|i.his.rgb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.ifft}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.image.mosaic}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.in.spotvgt}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|i.landsat.rgb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.maxlik}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|i.oif}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.ortho.photo}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|i.pca}}
| {{ModuleNotAvailable|Lo}}
|
|
|-
| {{cmd|i.points}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|i.rectify}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|i.rgb.his}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|i.smap}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|i.spectral}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|i.target}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|i.tasscap}}
| {{ModuleAvailable}}
| common x3
|-
| {{cmd|i.vpoints}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|i.zc}}
|{{ModuleAvailable}}
| common
|}

=== Miscellaneous modules ===

{| class="wikitable sortable"
|+ m.* 
! Module
! Status
! Comments
|-
| {{cmd|m.cogo}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|m.proj}}
| {{ModuleAvailable}}
| common
|}

=== Paint modules ===

''These have been abandoned in GRASS 6.''

{| class="wikitable sortable"
|+ p.* 
! Module
! Status
! Comments
|-
| {{cmd|p.out.vrml}}
| {{ModuleNotRelevant}}
| old & renamed; not for QGIS
|}

=== PostScript modules ===

{| class="wikitable sortable"
|+ ps.* 
! Module
! Status
! Comments
|-
| {{cmd|ps.map}}
| {{ModuleNotRelevant}}
| QGIS has its own map composer, so this probably isn't needed.
|}

=== Raster modules ===

{| class="wikitable sortable"
|+ r.* 
! Module
! Status
! Comments
|-
| {{cmd|r.average}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.basins.fill}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.bilinear}}
| {{ModuleAvailable}}
| modules-6.4 ''Please use "r.resamp.interp" instead.''
|-
| {{cmd|r.bitpattern}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.blend}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.buffer}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.carve}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.category}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.cats}}
| {{ModuleNotRelevant}}
| Wrapper script for backwards compatibility.
|-
| {{cmd|r.circle}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.clump}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.coin}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.colors}}
| {{ModuleAvailable}}
| common x4, generic, rast, rules, table
|-
| {{cmd|r.colors.stddev}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|r.composite}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.compress}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.contour}}
| {{ModuleAvailable}}
| common x2
|-
| {{cmd|r.cost}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.covar}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.cross}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.describe}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.digit}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|r.distance}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.drain}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.external}}
| {{ModuleAvailable}}
| modules-6.4 x3
|-
| {{cmd|r.fill.dir}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.fillnulls}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.flow}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.grow}}
| {{ModuleAvailable}}
| 6.4/common
|-
| {{cmd|r.grow.distance}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.gwflow}}
| {{ModuleNotAvailable|Lo}}
| ground water flow modeling
|-
| {{cmd|r.his}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.horizon}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.in.arc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.ascii}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.aster}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.bin}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.gdal}}
|{{ModuleAvailable}}
| common x4, generic, loc, qgis.loc, qgis
|-
| {{cmd|r.in.gridatb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.mat}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.poly}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.srtm}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.in.wms}}
| {{ModuleAvailable}}
| common, somewhat brittle
|-
| {{cmd|r.in.xyz}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.info}}
| {{ModuleNotRelevant}}
| Handled in the Toolbox
|-
| {{cmd|r.kappa}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.lake}}
| {{ModuleAvailable}}
| common x3, generic, seed, xy
|-
| {{cmd|r.le.patch}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.le.pixel}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.le.setup}}
| {{ModuleNotAvailable|Hi}}
| Landscape Ecology analyses
|-
| {{cmd|r.le.trace}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.li.cwed}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.li.dominance}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.li.edgedensity}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.li.mpa}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.li.mps}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.li.padcv}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.li.padrange}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.li.padsd}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.li.patchdensity}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.li.patchnum}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.li.richness}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.li.setup}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.li.shannon}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.li.shape}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.li.simpson}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|r.los}}
| {{ModuleAvailable}}
| common
|
|-
| {{cmd|r.mapcalc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.mapcalculator}}
| {{ModuleAvailable}}
| common, gui wrapper (need both?)
|-
| {{cmd|r.mask}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.median}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.mfilter}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.mfilter.fp}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.mode}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.neighbors}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.null}}
| {{ModuleAvailable}}
| common x4, null, to, val, r.to.null?
|-
| {{cmd|r.out.arc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.ascii}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.bin}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.out.gdal}}
| {{ModuleAvailable}}
| common x2 generic, GeoTiff
|-
| {{cmd|r.out.gdal.sh}}
| {{ModuleNotAvailable|Lo}}
| old full map extent version
|-
| {{cmd|r.out.gridatb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.mat}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.mpeg}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.png}}
| {{ModuleAvailable}}
| common, important once transparency and Worldfile gets backported from 6.5svn (for OpenLayers/KML tile source)
|-
| {{cmd|r.out.pov}}
| {{ModuleAvailable}}
| common POVray
|-
| {{cmd|r.out.ppm}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.ppm3}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.tiff}}
| {{ModuleAvailable}}
| common, ''visual'' RGB output, not data values (use r.out.gdal for that)
|-
| {{cmd|r.out.vrml}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.vtk}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.out.xyz}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.param.scale}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.patch}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.plane}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.profile}}
| {{ModuleNotAvailable|Lo}}
| Python plugin available to find transect profile
|-
| {{cmd|r.proj}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.quant}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.quantile}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.random}}
| {{ModuleAvailable}}
|
|-
| {{cmd|r.random.cells}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.random.surface}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.reclass}}
| {{ModuleAvailable}}
| common x2, generic, file
|-
| {{cmd|r.reclass.area}}
| {{ModuleAvailable}}
| common x3, generic, greater, lesser
|-
| {{cmd|r.recode}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.region}}
| {{ModuleAvailable}}
| Oversold?, common x6, generic, rast, vect, region, edge, alignTo
|-
| {{cmd|r.regression.line}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.report}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resamp.interp}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resamp.rst}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resamp.stats}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.resample}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.rescale}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.rescale.eq}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.ros}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.series}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.shaded.relief}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.sim.sediment}}
| {{ModuleNotAvailable|Lo}}
|
|
|-
| {{cmd|r.sim.water}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.slope.aspect}}
| {{ModuleAvailable}}
| common x2, slope, aspect, '''but not others'''
|-
| {{cmd|r.spread}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.spreadpath}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.statistics}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.stats}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.sum}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.sun}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.sunmask}}
| {{ModuleAvailable}}
| common x2, date_time, position
|-
| {{cmd|r.support}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.support.stats}}
| {{ModuleAvailable}}
| common, maybe not needed
|-
| {{cmd|r.surf.area}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.surf.contour}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.surf.fractal}}
| {{ModuleAvailable}}
| 6.3/6.4
|-
| {{cmd|r.surf.gauss}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.surf.idw}}
| {{ModuleAvailable}}
| common, faster
|-
| {{cmd|r.surf.idw2}}
| {{ModuleAvailable}}
| common, supports floating point
|-
| {{cmd|r.surf.random}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.terraflow}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.terraflow.short}}
| {{ModuleNotRelevant}}
| Not needed
|-
| {{cmd|r.texture}}
| {{ModuleAvailable}}
| common x2, generic, bis
|-
| {{cmd|r.thin}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.tileset}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|r.timestamp}}
| {{ModuleNotRelevant}}
|
|-
| {{cmd|r.to.rast3}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.to.rast3elev}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.to.vect}}
| {{ModuleAvailable}}
| common x3, point, line, area
|-
| {{cmd|r.topidx}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.topmodel}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r.transect}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.univar}}
| {{ModuleAvailable}}
| common
|
|-
| {{cmd|r.univar.sh}}
| {{ModuleNotRelevant}}
| Not needed
|-
| {{cmd|r.volume}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.walk}}
| {{ModuleNotAvailable|Hi}}
|
|
|-
| {{cmd|r.water.outlet}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.watershed}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|r.what}}
| {{ModuleNotRelevant}}
| Handled in the QGIS GUI
|-
| {{cmd|r.what.color}}
| {{ModuleNotRelevant}}
|
|-
|}

=== 3D raster modules ===

{| class="wikitable sortable"
|+ r3.* 
! Module
! Status
! Comments
|-
| {{cmd|r3.cross.rast}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.gwflow}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.in.ascii}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.in.v5d}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.info}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.mapcalc}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.mapcalculator}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.mask}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.mkdspf}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.null}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.out.ascii}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.out.v5d}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.out.vtk}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.stats}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.timestamp}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.to.rast}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|r3.univar}}
| {{ModuleNotAvailable|Lo}}
|
|}

=== Vector modules ===

{| class="wikitable sortable"
|+ v.* 
! Module
! Status
! Comments
|-
| {{cmd|v.buffer}}
| {{ModuleAvailable}}
| 6.3/6.4, https://trac.osgeo.org/grass/ticket/994
|-
| {{cmd|v.build}}
| {{ModuleAvailable}}
| see specific modules
|-
| {{cmd|v.build.all}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.build.polylines}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.category}}
| {{ModuleAvailable}}
| common x4, add, del, sum, change
|-
| {{cmd|v.centroids}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.class}}
| {{ModuleNotAvailable|Lo}}
| Fuctionality supplied in QGIS Vector symbology
|-
| {{cmd|v.clean}}
| {{ModuleAvailable}}
| common x13
|-
| {{cmd|v.colors}}
| {{ModuleNotRelevant}}
| Fuctionality supplied in QGIS Vector symbology
|-
| {{cmd|v.convert}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.convert.all}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.db.addcol}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.addtable}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.connect}}
| {{ModuleAvailable}}
| common, v.db.sconnect? v.db.what.connect?
|-
| {{cmd|v.db.dropcol}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|v.db.droptable}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.join}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.reconnect.all}}
| {{ModuleAvailable}}
| common
|
|-
| {{cmd|v.db.renamecol}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.select}}
| {{ModuleAvailable}}
| 6.3/6.4 x2
|-
| {{cmd|v.db.univar}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.db.update}}
| {{ModuleAvailable}}
| common x4, const, op, op query, query
|-
| {{cmd|v.delaunay}}
| {{ModuleAvailable}}
| common x2, line, area
|-
| {{cmd|v.digit}}
| {{ModuleNotRelevant}}
| Not possible
|-
| {{cmd|v.dissolve}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.distance}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.drape}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.edit}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|v.external}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.extract}}
| {{ModuleAvailable}}
| common, list, where
|-
| {{cmd|v.extrude}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.generalize}}
| {{ModuleAvailable}}
| common, complicated
|-
| {{cmd|v.hull}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.ascii}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|v.in.db}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.dxf}}
| {{ModuleAvailable}}
| common x2, generic, multi
|-
| {{cmd|v.in.e00}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.garmin}}
| {{ModuleAvailable}}
| common, only for old serial models
|-
| {{cmd|v.in.geonames}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|v.in.gns}}
| {{ModuleAvailable}}
| modules-6.4
|-
| {{cmd|v.in.gpsbabel}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.lines|version=65}}
| {{ModuleAvailable}}
| Only in 6.5svn, new wrapper script around v.in.mapgen with more obvious name
|-
| {{cmd|v.in.mapgen}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.ogr}}
| {{ModuleAvailable}}
| common x7
|-
| {{cmd|v.in.region}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.in.sites}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.in.sites.all}}
| {{ModuleNotRelevant}}
| For loading in old GRASS 4/5 vector data format. Not needed by QGIS.
|-
| {{cmd|v.in.wfs}}
| {{ModuleNotAvailable|Hi}}
|
|-
| {{cmd|v.info}}
| {{ModuleNotRelevant}}
| Functionality supplied in Toolbox
|-
| {{cmd|v.kcv}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.kernel}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.krige.py}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.label}}
| {{ModuleNotRelevant}}
| Functionality supplied in QGIS GUI
|-
| {{cmd|v.label.sa}}
| {{ModuleNotRelevant}}
| Functionality supplied in QGIS GUI
|-
| {{cmd|v.lidar.correction}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.lidar.edgedetection}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.lidar.growing}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.lrs.create}}
| {{ModuleNotAvailable|Lo}}
| Python plugin for Linear Referencing available
|-
| {{cmd|v.lrs.label}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.lrs.segment}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.lrs.where}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.mkgrid}}
| {{ModuleAvailable}}
| common, by region (by coord is a custom graticule creator)
|-
| {{cmd|v.neighbors}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.nodes}}
| {{ModuleAvailable}}
|
|-
| {{cmd|v.net.alloc}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.allpairs}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.net.bridge}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.net.centrality}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.net.components}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.net.connectivity}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.net.distance}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.net.flow}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.net.iso}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.path}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.salesman}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.spanningtree}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.net.steiner}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.net.timetable}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.net.visibility}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.normal}}
| {{ModuleNotAvailable|Lo}}
| common
|-
| {{cmd|v.out.ascii}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.dxf}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.gpsbabel}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.out.ogr}}
| {{ModuleAvailable}}
| 6.3/6.4/common x4, shapefile, generic, gml, mapinfo; 6.x: PostgreSQL
|-
| {{cmd|v.out.pov}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.svg}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.out.vtk}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.outlier}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.overlay}}
| {{ModuleAvailable}}
| common x4, and, or, not, xor
|-
| {{cmd|v.parallel}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.patch}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.perturb}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.proj}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.qcount}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.random}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.rast.stats}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.reclass}}
| {{ModuleAvailable}}
| common x2, attr, file
|-
| {{cmd|v.report}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.sample}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.segment}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.select}}
| {{ModuleAvailable}}
| common, v.select.overlap
|-
| {{cmd|v.split}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.support}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.surf.bspline}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.surf.idw}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.surf.rst}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.to.3d}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.to.db}}
| {{ModuleAvailable}}
| 6.3/6.4
|-
| {{cmd|v.to.points}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.to.rast}}
| {{ModuleAvailable}}
| common x2, attr, constant
|-
| {{cmd|v.to.rast3}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.transform}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.type}}
| {{ModuleAvailable}}
| common x4, b2l, l2b, c2p, p2c
|-
| {{cmd|v.univar}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.univar.sh}}
| {{ModuleNotRelevant}}
| old, not needed
|-
| {{cmd|v.vol.rst}}
| {{ModuleNotAvailable|Lo}}
|
|-
| {{cmd|v.voronoi}}
| {{ModuleAvailable}}
| common x2, line, area; https://trac.osgeo.org/grass/ticket/957
|-
| {{cmd|v.what}}
| {{ModuleNotRelevant}}
| QGIS GUI supplies query at location function
|-
| {{cmd|v.what.rast}}
| {{ModuleAvailable}}
| common
|-
| {{cmd|v.what.vect}}
| {{ModuleAvailable}}
| common
|}

=== GUI and command modules ===
{| class="wikitable sortable"
|+ GUI modules 
! Module
! Status
! Comments
|-
| {{cmd|gis.m}}
| {{ModuleNotRelevant}}
| Not relevant
|-
| {{cmd|nviz}}
| {{ModuleAvailable}}
| common
|-
| shell
| {{ModuleAvailable}}
| common
|-
| {{cmd|xganim}}
| {{ModuleNotAvailable|Lo}}
|
|}

=== Display modules ===

{| class="wikitable "
|+ d.* 
|-
| '' None of the display modules will be relevant. Display functionality is handled in the QGIS GUI. ''

<!--
! Module
! Priority
! Status
! Comments
|-
| {{cmd|d.ask}}
|
|
|
|-
| {{cmd|d.barscale}}
|
|
|
|-
| {{cmd|d.colorlist}}
|
|
|
|-
| {{cmd|d.colors}}
|
|
|
|-
| {{cmd|d.colortable}}
|
|
|
|-
| {{cmd|d.correlate}}
|
|
|
|-
| {{cmd|d.erase}}
|
|
|
|-
| {{cmd|d.extend}}
|
|
|
|-
| {{cmd|d.extract}}
|
|
|
|-
| {{cmd|d.font}}
|
|
|
|-
| {{cmd|d.font.freetype}}
|
|
|
|-
| {{cmd|d.frame}}
|
|
|
|-
| {{cmd|d.geodesic}}
|
|
|
|-
| {{cmd|d.graph}}
|
|
|
|-
| {{cmd|d.grid}}
|
|
|
|-
| {{cmd|d.his}}
|
|
|
|-
| {{cmd|d.histogram}}
|
|
|
|-
| {{cmd|d.info}}
|
|
|
|-
| {{cmd|d.labels}}
|
|
|
|-
| {{cmd|d.legend}}
|
|
|
|-
| {{cmd|d.linegraph}}
|
|
|
|-
| {{cmd|d.m}}
|
|
|
|-
| {{cmd|d.mapgraph}}
|
|
|
|-
| {{cmd|d.measure}}
|
|
|
|-
| {{cmd|d.menu}}
|
|
|
|-
| {{cmd|d.mon}}
|
|
|
|-
| {{cmd|d.monsize}}
|
|
|
|-
| {{cmd|d.mvmon}}
|
|
|
|-
| {{cmd|d.nviz}}
|
|
|
|-
| {{cmd|d.out.file}}
|
|
|
|-
| {{cmd|d.out.gpsdrive}}
|
|
|
|-
| {{cmd|d.out.png}}
|
|
|
|-
| {{cmd|d.paint.labels}}
|
|
|
|-
| {{cmd|d.path}}
|
|
|
|-
| {{cmd|d.polar}}
|
|
|
|-
| {{cmd|d.profile}}
|
|
|
|-
| {{cmd|d.rast}}
|
|
|
|-
| {{cmd|d.rast.arrow}}
|
|
|
|-
| {{cmd|d.rast.edit}}
|
|
|
|-
| {{cmd|d.rast.leg}}
|
|
|
|-
| {{cmd|d.rast.num}}
|
|
|
|-
| {{cmd|d.redraw}}
|
|
|
|-
| {{cmd|d.resize}}
|
|
|
|-
| {{cmd|d.rgb}}
|
|
|
|-
| {{cmd|d.rhumbline}}
|
|
|
|-
| {{cmd|d.save}}
|
|
|
|-
| {{cmd|d.shadedmap}}
|
|
|
|-
| {{cmd|d.slide.show}}
|
|
|
|-
| {{cmd|d.split}}
|
|
|
|-
| {{cmd|d.split.frame}}
|
|
|
|-
| {{cmd|d.text}}
|
|
|
|-
| {{cmd|d.text.freetype}}
|
|
|
|-
| {{cmd|d.thematic.area}}
|
|
|
|-
| {{cmd|d.title}}
|
|
|
|-
| {{cmd|d.vect}}
|
|
|
|-
| {{cmd|d.vect.chart}}
|
|sortable"
|+

Template:ModuleNotAvailalbeLo

2010-10-30T14:51:11Z

⚠️Micha: Created page with "<onlyinclude> <div style="background-color: #F79FA0;"> Missing - Lo </div> </onlyinclude> Template to color GRASS-QGIS Relevant Modules table"

<onlyinclude>
<div style="background-color: #F79FA0;">
Missing - Lo
</div>
</onlyinclude>
Template to color GRASS-QGIS Relevant Modules table

Template:ModuleNotAvailable

2010-10-30T14:48:44Z

⚠️Micha:

<onlyinclude>
<div style="background-color: #f96669;">
Missing - Hi
</div>
</onlyinclude>
Template to color GRASS-QGIS Relevant Modules table