GRASS-Wiki - User contributions [en]

Talk:GRASS GIS Community Sprint Berlin 2019

2019-05-24T06:25:58Z

⚠️Huhabla:

= Sponsors & Supporters =

The GRASS Community sprint was kindly sponsored by FOSSGIS e.V. and coorganized by DIW Berlin, which provided the venue.

= Participants and Reports =

Summarizing '''press release''': TODO

[[File:grassgis 2019 berlin sprint group photo.jpg|400px|center|GRASS GIS community sprinters at DIW Berlin, 2019]]

== Peter Loewe ==

[[File:Community-Sprint 2019 Zenodo high level view.jpg|thumb|right|Community-Sprint 2019 Zenodo high level view]]

* Discussion about Zenodo / GitHub integration
* Set up of Wikipage about the [https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage Zenodo-GitHuB integration] with all known facts and necessary steps tp dp this.
* Investigating [https://grass.osgeo.org/grass7/manuals/addons/v.surf.mass.html v.surf.mass] for social sciences and economic research.
* Preparation of OSGeo as a software commons for upcoming FOSS4G in Bucarest.
* Provision of Sprint infrastructure (coffee machine, vittle, display of holy GRASS relics, etc.)

== Markus Neteler ==

* creation of all new Github repos
** GRASS GIS core: https://github.com/OSGeo/grass (GRASS GIS >= 7.x)
** GRASS GIS legacy: https://github.com/OSGeo/grass-legacy (GRASS GIS 3.x, 4.x, 5.x, 6.x - 1987 - 2016)
** GRASS GIS addons: https://github.com/OSGeo/grass-addons
** GRASS GIS promotional material: https://github.com/OSGeo/grass-promo
** Upcoming new web site: https://github.com/OSGeo/grass-website
* Testing of new Github repo at: https://github.com/OSGeo/grass/
* Github teams created - different roles for read/write/admin access
** grass-committers: GRASS GIS developers team (read/write)
** grass-admin: GRASS GIS GitHub admin team (all)
** grass-docker-homebrew-users: users for automated dockerhub and homebrew builds (read-only)
* New Github users added upon email communication
* Draft version of https://trac.osgeo.org/grass/wiki/HowToGit
* (briefly) discussed image collections in GRASS GIS (needed for H2020 [http://openEO.org openEO.org])
* First PR :-) {{github_pr|8}}
* aftermath cleanup: tracked in https://trac.osgeo.org/grass/wiki/GitMigration#Aftermathcleanup

== Nicolas Bozon ==

* Presentation via video call of a first glance at the [[Website migration plan 2019|upcoming new GRASS GIS web site]] based on Hugo

[[File:grass2019_berlin_sprint_new_website.jpg|thumb|right|Upcoming new GRASS GIS web site]]

== Martin Landa ==

* Working on GitHub migration
** finalize source code migration to GitHub ({{trac|3722}})
*** Targets:
**** https://github.com/OSGeo/grass
**** https://github.com/OSGeo/grass-addons,
**** https://github.com/OSGeo/grass-promo,
**** https://github.com/OSGeo/grass-legacy
*** svn2git migration dump and logs: https://grass.osgeo.org/svn2git_archive/
* Update/Fix WinGRASS build procedure to work with Git
* {{github_pr|9}}
* Discussed GRASS support for image collection with Soeren

== Ondřej Pešek ==

* {{cmd|g.gui.gmodeler}}: Working on PyWPS export (see [https://github.com/ctu-yfsg/2017-d-grass-modeler-pywps/compare/master@%7B17/05/2019%7D...master@%7B21/05/2019%7D github commits] overview)
* Research and discussions about ANN-fueled semantic segmentation modules for GRASS GIS
* Watching Sören's screenings of Mandelbrot's fractals

== Anna Petrasova and Vaclav Petras ==

* video call from sprint to sprint: Minneapolis OSGeo sprint <--> Berlin GRASS GIS community sprint
** discussing GitHub migration and HowToGit document

== Veronica Andreo ==

* video call from Argentina
** learning and testing with HowToGit document
** discussion about progress of the new website

== Anne Ghisla aka aghisla ==

* Discuss with Peter about archiving of source code in Zenodo (one DOI per GRASS release, connection with git)
* Follow closely the svn2git migration and the design of the new commit/push workflow
* Start working on the HTML man pages, so that they refer to git for source code and last edit timestamp ({{github_pr|11}}, work in progress)
* Investigate a clean way of dropping Python 2.x support, to be done before 2020 (official EOL of Python 2.x)
* Check with MarkusM how to update g.extension to use git - maybe the Debian Python Team's way can be of inspiration https://salsa.debian.org/python-team/tools/python-modules

== Markus Metz ==

* Help with git migration and documentation https://trac.osgeo.org/grass/wiki/HowToGit
* Fix basic GIS functionality: r.contour ({{trac|3846}}, {{github_pr|6}})
* Help on polishing github profile
* discussions with the other participants on best practice and future plans (git, python3, proj6)

== Sören Gebbert ==

* Discussion with Martin about the implementation of image collections in GRASS GIS
* Coding module [https://github.com/huhabla/t_rast_udf t.rast.udf] that implements the [https://github.com/Open-EO/openeo-udf openEO UDF Python API] to be used in GRASS GIS with space-time raster datasets

Talk:GRASS GIS Community Sprint Berlin 2019

2019-05-24T06:16:01Z

⚠️Huhabla: /* Sören Gebbert */

= Sponsors & Supporters =

The GRASS Community sprint was kindly sponsored by FOSSGIS e.V. and coorganized by DIW Berlin, which provided the venue.

= Participants and Reports =

Summarizing '''press release''': TODO

[[File:grassgis 2019 berlin sprint group photo.jpg|400px|center|GRASS GIS community sprinters at DIW Berlin, 2019]]

== Peter Loewe ==

[[File:Community-Sprint 2019 Zenodo high level view.jpg|thumb|right|Community-Sprint 2019 Zenodo high level view]]

* Discussion about Zenodo / GitHub integration
* Set up of Wikipage about the [https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage Zenodo-GitHuB integration] with all known facts and necessary steps tp dp this.
* Investigating [https://grass.osgeo.org/grass7/manuals/addons/v.surf.mass.html v.surf.mass] for social sciences and economic research.
* Preparation of OSGeo as a software commons for upcoming FOSS4G in Bucarest.
* Provision of Sprint infrastructure (coffee machine, vittle, display of holy GRASS relics, etc.)

== Markus Neteler ==

* creation of all new Github repos
** GRASS GIS core: https://github.com/OSGeo/grass (GRASS GIS >= 7.x)
** GRASS GIS legacy: https://github.com/OSGeo/grass-legacy (GRASS GIS 3.x, 4.x, 5.x, 6.x - 1987 - 2016)
** GRASS GIS addons: https://github.com/OSGeo/grass-addons
** GRASS GIS promotional material: https://github.com/OSGeo/grass-promo
** Upcoming new web site: https://github.com/OSGeo/grass-website
* Testing of new Github repo at: https://github.com/OSGeo/grass/
* Github teams created - different roles for read/write/admin access
** grass-committers: GRASS GIS developers team (read/write)
** grass-admin: GRASS GIS GitHub admin team (all)
** grass-docker-homebrew-users: users for automated dockerhub and homebrew builds (read-only)
* New Github users added upon email communication
* Draft version of https://trac.osgeo.org/grass/wiki/HowToGit
* (briefly) discussed image collections in GRASS GIS (needed for H2020 [http://openEO.org openEO.org])
* First PR :-) {{github_pr|8}}
* aftermath cleanup: tracked in https://trac.osgeo.org/grass/wiki/GitMigration#Aftermathcleanup

== Nicolas Bozon ==

* Presentation via video call of a first glance at the [[Website migration plan 2019|upcoming new GRASS GIS web site]] based on Hugo

[[File:grass2019_berlin_sprint_new_website.jpg|thumb|right|Upcoming new GRASS GIS web site]]

== Martin Landa ==

* Working on GitHub migration
** finalize source code migration to GitHub ({{trac|3722}})
*** Targets:
**** https://github.com/OSGeo/grass
**** https://github.com/OSGeo/grass-addons,
**** https://github.com/OSGeo/grass-promo,
**** https://github.com/OSGeo/grass-legacy
*** svn2git migration dump and logs: https://grass.osgeo.org/svn2git_archive/
* Update/Fix WinGRASS build procedure to work with Git
* {{github_pr|9}}
* Discussed GRASS support for image collection with Soeren

== Ondřej Pešek ==

* {{cmd|g.gui.gmodeler}}: Working on PyWPS export (see [https://github.com/ctu-yfsg/2017-d-grass-modeler-pywps/compare/master@%7B17/05/2019%7D...master@%7B21/05/2019%7D github commits] overview)
* Research and discussions about ANN-fueled semantic segmentation modules for GRASS GIS
* Watching Sören's screenings of Mandelbrot's fractals

== Anna Petrasova and Vaclav Petras ==

* video call from sprint to sprint: Minneapolis OSGeo sprint <--> Berlin GRASS GIS community sprint
** discussing GitHub migration and HowToGit document

== Veronica Andreo ==

* video call from Argentina
** learning and testing with HowToGit document
** discussion about progress of the new website

== Anne Ghisla aka aghisla ==

* Discuss with Peter about archiving of source code in Zenodo (one DOI per GRASS release, connection with git)
* Follow closely the svn2git migration and the design of the new commit/push workflow
* Start working on the HTML man pages, so that they refer to git for source code and last edit timestamp ({{github_pr|11}}, work in progress)
* Investigate a clean way of dropping Python 2.x support, to be done before 2020 (official EOL of Python 2.x)
* Check with MarkusM how to update g.extension to use git - maybe the Debian Python Team's way can be of inspiration https://salsa.debian.org/python-team/tools/python-modules

== Markus Metz ==

* Help with git migration and documentation https://trac.osgeo.org/grass/wiki/HowToGit
* Fix basic GIS functionality: r.contour ({{trac|3846}}, {{github_pr|6}})
* Help on polishing github profile
* discussions with the other participants on best practice and future plans (git, python3, proj6)

== Sören Gebbert ==

* Discussion with Martin about the implementation of image collections in GRASS GIS
* Coding module [https://github.com/huhabla/t_rast_udf t.rast.udf] that implements the [https://github.com/Open-EO/openeo-udfopenEO UDF Python API] to be used in GRASS GIS with space-time raster datasets

Talk:GRASS GIS Community Sprint Berlin 2019

2019-05-24T06:15:10Z

⚠️Huhabla:

= Sponsors & Supporters =

The GRASS Community sprint was kindly sponsored by FOSSGIS e.V. and coorganized by DIW Berlin, which provided the venue.

= Participants and Reports =

Summarizing '''press release''': TODO

[[File:grassgis 2019 berlin sprint group photo.jpg|400px|center|GRASS GIS community sprinters at DIW Berlin, 2019]]

== Peter Loewe ==

[[File:Community-Sprint 2019 Zenodo high level view.jpg|thumb|right|Community-Sprint 2019 Zenodo high level view]]

* Discussion about Zenodo / GitHub integration
* Set up of Wikipage about the [https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage Zenodo-GitHuB integration] with all known facts and necessary steps tp dp this.
* Investigating [https://grass.osgeo.org/grass7/manuals/addons/v.surf.mass.html v.surf.mass] for social sciences and economic research.
* Preparation of OSGeo as a software commons for upcoming FOSS4G in Bucarest.
* Provision of Sprint infrastructure (coffee machine, vittle, display of holy GRASS relics, etc.)

== Markus Neteler ==

* creation of all new Github repos
** GRASS GIS core: https://github.com/OSGeo/grass (GRASS GIS >= 7.x)
** GRASS GIS legacy: https://github.com/OSGeo/grass-legacy (GRASS GIS 3.x, 4.x, 5.x, 6.x - 1987 - 2016)
** GRASS GIS addons: https://github.com/OSGeo/grass-addons
** GRASS GIS promotional material: https://github.com/OSGeo/grass-promo
** Upcoming new web site: https://github.com/OSGeo/grass-website
* Testing of new Github repo at: https://github.com/OSGeo/grass/
* Github teams created - different roles for read/write/admin access
** grass-committers: GRASS GIS developers team (read/write)
** grass-admin: GRASS GIS GitHub admin team (all)
** grass-docker-homebrew-users: users for automated dockerhub and homebrew builds (read-only)
* New Github users added upon email communication
* Draft version of https://trac.osgeo.org/grass/wiki/HowToGit
* (briefly) discussed image collections in GRASS GIS (needed for H2020 [http://openEO.org openEO.org])
* First PR :-) {{github_pr|8}}
* aftermath cleanup: tracked in https://trac.osgeo.org/grass/wiki/GitMigration#Aftermathcleanup

== Nicolas Bozon ==

* Presentation via video call of a first glance at the [[Website migration plan 2019|upcoming new GRASS GIS web site]] based on Hugo

[[File:grass2019_berlin_sprint_new_website.jpg|thumb|right|Upcoming new GRASS GIS web site]]

== Martin Landa ==

* Working on GitHub migration
** finalize source code migration to GitHub ({{trac|3722}})
*** Targets:
**** https://github.com/OSGeo/grass
**** https://github.com/OSGeo/grass-addons,
**** https://github.com/OSGeo/grass-promo,
**** https://github.com/OSGeo/grass-legacy
*** svn2git migration dump and logs: https://grass.osgeo.org/svn2git_archive/
* Update/Fix WinGRASS build procedure to work with Git
* {{github_pr|9}}
* Discussed GRASS support for image collection with Soeren

== Ondřej Pešek ==

* {{cmd|g.gui.gmodeler}}: Working on PyWPS export (see [https://github.com/ctu-yfsg/2017-d-grass-modeler-pywps/compare/master@%7B17/05/2019%7D...master@%7B21/05/2019%7D github commits] overview)
* Research and discussions about ANN-fueled semantic segmentation modules for GRASS GIS
* Watching Sören's screenings of Mandelbrot's fractals

== Anna Petrasova and Vaclav Petras ==

* video call from sprint to sprint: Minneapolis OSGeo sprint <--> Berlin GRASS GIS community sprint
** discussing GitHub migration and HowToGit document

== Veronica Andreo ==

* video call from Argentina
** learning and testing with HowToGit document
** discussion about progress of the new website

== Anne Ghisla aka aghisla ==

* Discuss with Peter about archiving of source code in Zenodo (one DOI per GRASS release, connection with git)
* Follow closely the svn2git migration and the design of the new commit/push workflow
* Start working on the HTML man pages, so that they refer to git for source code and last edit timestamp ({{github_pr|11}}, work in progress)
* Investigate a clean way of dropping Python 2.x support, to be done before 2020 (official EOL of Python 2.x)
* Check with MarkusM how to update g.extension to use git - maybe the Debian Python Team's way can be of inspiration https://salsa.debian.org/python-team/tools/python-modules

== Markus Metz ==

* Help with git migration and documentation https://trac.osgeo.org/grass/wiki/HowToGit
* Fix basic GIS functionality: r.contour ({{trac|3846}}, {{github_pr|6}})
* Help on polishing github profile
* discussions with the other participants on best practice and future plans (git, python3, proj6)

== Sören Gebbert ==

* Diskussion with Martin about the implementation of image collections in GRASS GIS
* Implementing the module [https://github.com/huhabla/t_rast_udf t.rast.udf] that implements the [https://github.com/Open-EO/openeo-udfopenEO UDF Python API] to be used in GRASS GIS with space-time raster datasets

Talk:GRASS GIS Community Sprint Berlin 2019

2019-05-24T06:11:49Z

⚠️Huhabla:

= Sponsors & Supporters =

The GRASS Community sprint was kindly sponsored by FOSSGIS e.V. and coorganized by DIW Berlin, which provided the venue.

= Participants and Reports =

Summarizing '''press release''': TODO

[[File:grassgis 2019 berlin sprint group photo.jpg|400px|center|GRASS GIS community sprinters at DIW Berlin, 2019]]

== Peter Loewe ==

[[File:Community-Sprint 2019 Zenodo high level view.jpg|thumb|right|Community-Sprint 2019 Zenodo high level view]]

* Discussion about Zenodo / GitHub integration
* Set up of Wikipage about the [https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage Zenodo-GitHuB integration] with all known facts and necessary steps tp dp this.
* Investigating [https://grass.osgeo.org/grass7/manuals/addons/v.surf.mass.html v.surf.mass] for social sciences and economic research.
* Preparation of OSGeo as a software commons for upcoming FOSS4G in Bucarest.
* Provision of Sprint infrastructure (coffee machine, vittle, display of holy GRASS relics, etc.)

== Markus Neteler ==

* creation of all new Github repos
** GRASS GIS core: https://github.com/OSGeo/grass (GRASS GIS >= 7.x)
** GRASS GIS legacy: https://github.com/OSGeo/grass-legacy (GRASS GIS 3.x, 4.x, 5.x, 6.x - 1987 - 2016)
** GRASS GIS addons: https://github.com/OSGeo/grass-addons
** GRASS GIS promotional material: https://github.com/OSGeo/grass-promo
** Upcoming new web site: https://github.com/OSGeo/grass-website
* Testing of new Github repo at: https://github.com/OSGeo/grass/
* Github teams created - different roles for read/write/admin access
** grass-committers: GRASS GIS developers team (read/write)
** grass-admin: GRASS GIS GitHub admin team (all)
** grass-docker-homebrew-users: users for automated dockerhub and homebrew builds (read-only)
* New Github users added upon email communication
* Draft version of https://trac.osgeo.org/grass/wiki/HowToGit
* (briefly) discussed image collections in GRASS GIS (needed for H2020 [http://openEO.org openEO.org])
* First PR :-) {{github_pr|8}}
* aftermath cleanup: tracked in https://trac.osgeo.org/grass/wiki/GitMigration#Aftermathcleanup

== Nicolas Bozon ==

* Presentation via video call of a first glance at the [[Website migration plan 2019|upcoming new GRASS GIS web site]] based on Hugo

[[File:grass2019_berlin_sprint_new_website.jpg|thumb|right|Upcoming new GRASS GIS web site]]

== Martin Landa ==

* Working on GitHub migration
** finalize source code migration to GitHub ({{trac|3722}})
*** Targets:
**** https://github.com/OSGeo/grass
**** https://github.com/OSGeo/grass-addons,
**** https://github.com/OSGeo/grass-promo,
**** https://github.com/OSGeo/grass-legacy
*** svn2git migration dump and logs: https://grass.osgeo.org/svn2git_archive/
* Update/Fix WinGRASS build procedure to work with Git
* {{github_pr|9}}
* Discussed GRASS support for image collection with Soeren

== Ondřej Pešek ==

* {{cmd|g.gui.gmodeler}}: Working on PyWPS export (see [https://github.com/ctu-yfsg/2017-d-grass-modeler-pywps/compare/master@%7B17/05/2019%7D...master@%7B21/05/2019%7D github commits] overview)
* Research and discussions about ANN-fueled semantic segmentation modules for GRASS GIS
* Watching Sören's screenings of Mandelbrot's fractals

== Anna Petrasova and Vaclav Petras ==

* video call from sprint to sprint: Minneapolis OSGeo sprint <--> Berlin GRASS GIS community sprint
** discussing GitHub migration and HowToGit document

== Veronica Andreo ==

* video call from Argentina
** learning and testing with HowToGit document
** discussion about progress of the new website

== Anne Ghisla aka aghisla ==

* Discuss with Peter about archiving of source code in Zenodo (one DOI per GRASS release, connection with git)
* Follow closely the svn2git migration and the design of the new commit/push workflow
* Start working on the HTML man pages, so that they refer to git for source code and last edit timestamp ({{github_pr|11}}, work in progress)
* Investigate a clean way of dropping Python 2.x support, to be done before 2020 (official EOL of Python 2.x)
* Check with MarkusM how to update g.extension to use git - maybe the Debian Python Team's way can be of inspiration https://salsa.debian.org/python-team/tools/python-modules

== Markus Metz ==

* Help with git migration and documentation https://trac.osgeo.org/grass/wiki/HowToGit
* Fix basic GIS functionality: r.contour ({{trac|3846}}, {{github_pr|6}})
* Help on polishing github profile
* discussions with the other participants on best practice and future plans (git, python3, proj6)

== Sören Gebbert ==

* Diskussion with Martin about the implementation of image collections in GRASS GIS
* Implementing the module t.rast.udf that implements the openEO UDF Python API to be used in GRASS GIS with space-time raster datasets

Talk:GRASS GIS Community Sprint Berlin 2019

2019-05-24T06:11:33Z

⚠️Huhabla:

= Sponsors & Supporters =

The GRASS Community sprint was kindly sponsored by FOSSGIS e.V. and coorganized by DIW Berlin, which provided the venue.

= Participants and Reports =

Summarizing '''press release''': TODO

[[File:grassgis 2019 berlin sprint group photo.jpg|400px|center|GRASS GIS community sprinters at DIW Berlin, 2019]]

== Peter Loewe ==

[[File:Community-Sprint 2019 Zenodo high level view.jpg|thumb|right|Community-Sprint 2019 Zenodo high level view]]

* Discussion about Zenodo / GitHub integration
* Set up of Wikipage about the [https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage Zenodo-GitHuB integration] with all known facts and necessary steps tp dp this.
* Investigating [https://grass.osgeo.org/grass7/manuals/addons/v.surf.mass.html v.surf.mass] for social sciences and economic research.
* Preparation of OSGeo as a software commons for upcoming FOSS4G in Bucarest.
* Provision of Sprint infrastructure (coffee machine, vittle, display of holy GRASS relics, etc.)

== Markus Neteler ==

* creation of all new Github repos
** GRASS GIS core: https://github.com/OSGeo/grass (GRASS GIS >= 7.x)
** GRASS GIS legacy: https://github.com/OSGeo/grass-legacy (GRASS GIS 3.x, 4.x, 5.x, 6.x - 1987 - 2016)
** GRASS GIS addons: https://github.com/OSGeo/grass-addons
** GRASS GIS promotional material: https://github.com/OSGeo/grass-promo
** Upcoming new web site: https://github.com/OSGeo/grass-website
* Testing of new Github repo at: https://github.com/OSGeo/grass/
* Github teams created - different roles for read/write/admin access
** grass-committers: GRASS GIS developers team (read/write)
** grass-admin: GRASS GIS GitHub admin team (all)
** grass-docker-homebrew-users: users for automated dockerhub and homebrew builds (read-only)
* New Github users added upon email communication
* Draft version of https://trac.osgeo.org/grass/wiki/HowToGit
* (briefly) discussed image collections in GRASS GIS (needed for H2020 [http://openEO.org openEO.org])
* First PR :-) {{github_pr|8}}
* aftermath cleanup: tracked in https://trac.osgeo.org/grass/wiki/GitMigration#Aftermathcleanup

== Nicolas Bozon ==

* Presentation via video call of a first glance at the [[Website migration plan 2019|upcoming new GRASS GIS web site]] based on Hugo

[[File:grass2019_berlin_sprint_new_website.jpg|thumb|right|Upcoming new GRASS GIS web site]]

== Martin Landa ==

* Working on GitHub migration
** finalize source code migration to GitHub ({{trac|3722}})
*** Targets:
**** https://github.com/OSGeo/grass
**** https://github.com/OSGeo/grass-addons,
**** https://github.com/OSGeo/grass-promo,
**** https://github.com/OSGeo/grass-legacy
*** svn2git migration dump and logs: https://grass.osgeo.org/svn2git_archive/
* Update/Fix WinGRASS build procedure to work with Git
* {{github_pr|9}}
* Discussed GRASS support for image collection with Soeren

== Ondřej Pešek ==

* {{cmd|g.gui.gmodeler}}: Working on PyWPS export (see [https://github.com/ctu-yfsg/2017-d-grass-modeler-pywps/compare/master@%7B17/05/2019%7D...master@%7B21/05/2019%7D github commits] overview)
* Research and discussions about ANN-fueled semantic segmentation modules for GRASS GIS
* Watching Sören's screenings of Mandelbrot's fractals

== Anna Petrasova and Vaclav Petras ==

* video call from sprint to sprint: Minneapolis OSGeo sprint <--> Berlin GRASS GIS community sprint
** discussing GitHub migration and HowToGit document

== Veronica Andreo ==

* video call from Argentina
** learning and testing with HowToGit document
** discussion about progress of the new website

== Anne Ghisla aka aghisla ==

* Discuss with Peter about archiving of source code in Zenodo (one DOI per GRASS release, connection with git)
* Follow closely the svn2git migration and the design of the new commit/push workflow
* Start working on the HTML man pages, so that they refer to git for source code and last edit timestamp ({{github_pr|11}}, work in progress)
* Investigate a clean way of dropping Python 2.x support, to be done before 2020 (official EOL of Python 2.x)
* Check with MarkusM how to update g.extension to use git - maybe the Debian Python Team's way can be of inspiration https://salsa.debian.org/python-team/tools/python-modules

== Markus Metz ==

* Help with git migration and documentation https://trac.osgeo.org/grass/wiki/HowToGit
* Fix basic GIS functionality: r.contour ({{trac|3846}}, {{github_pr|6}})
* Help on polishing github profile
* discussions with the other participants on best practice and future plans (git, python3, proj6)

== Sören Gebbert ==

* Diskussion with Martin about the implementation of image collections in GRASS GIS
* Implementing the module t.rast.udf that implements the openEO UDF Python API to be used in GRASS GIS with space-time raster datasets

GRASS GIS Community Sprint Berlin 2019

2019-04-25T09:43:37Z

⚠️Huhabla: Added Soeren Gebbert

{{toc|right}}

== Timing, Venue ==

'''May 17 (Fri) - May 20 (Mon), 2019 at DIW Berlin, Berlin, Germany'''.

Location: Mohrenstraße 58, 10117 Berlin ([https://www.openstreetmap.org/node/358106189 OSM Map])

== Sponsors ==

DIW Berlin: Free provision of meeting rooms and internet access.

Donation from OSGeo. Please check more info [[GRASS GIS Budget 2019]].

We also welcome direct '''financial contributions''' to help reducing travelling and accommodation expenses for GRASS developers with far arrival If you are interested to sponsor the GRASS Community Sprint, please read about

:::'''sponsoring the GRASS project''' via our [https://www.paypal.com/pools/c/86YKZiIEPV Paypal money pool]

[[Image:Btn_donate_SM.gif|center|link=http://grass.osgeo.org/donations/]]

For any questions, please contact [[User:Landa|Martin Landa]]. Any surplus at the end of the event will be turned over to the GRASS GIS project.

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

== Agenda - What we plan to do ==

* Discuss scientific citation of GRASS code and changes to the metadata of man-pages. (PL)

=== New website ===

== Planned participation ==

For organizational reasons.

=== In person ===

Please add your name here:

{|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|'''No'''
|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
|17/18
|20
|
|L
|
|-
|-
|2
|[[User:Neteler|Markus Neteler]]
|Germany
|?
|?
| completion of git/github migration
|M
|
|-
|3
|[[User:peter.loewe|Peter Loewe]]
|Germany
|17
|20
| Integration of gut/github migration with the Zenodo data repository / strategic planning for extensions of g.citation module
|XL
|
|-
|-
|-
|4
|[[User:mmetz|Markus Metz]]
|Germany
|17
|20
|
|L
|
|-
|-
|5
|[[User:pesekon2|Ondřej Pešek]]
|Czech Republic
|17/18
|20
|
|M
|
|-
|-
|6
|[[User:huhabla|Sören Gebbert]]
|Germany
|17
|19
| Image collections in GRASS GIS
|XL
|
|-
|-
|x
|}

== Accomodation ==

There are several Hotels etc. in walking distance.

=== Backpackers ===
[https://www.cityhostel-berlin.com/ City-Hostel Berlin]
=== Hotels ===
tbd

== Venue ==
==== Address ====
DIW Berlin, Mohrenstrasse 58, 10117 Berlin ([https://www.openstreetmap.org/node/358106189 OSM Map])

==== Public transport ====

See: https://fahrinfo.bvg.de/barrierefrei/bin/query.bin/en

===== Subway / U-Bahn =====
* stations "Mohrenstraße", "Stadtmitte" or "Französische Straße"

===== Light rail / S-Bahn =====
* Friedrichstraße station (10mins walk from there)

==== Rooms ====

* Friday, May 17: 5.2.8 / 5.2.011
* Saturday, May 18 (fifth floor)
* Sunday, May 19 (fifth floor)
* Monday, May 20: 5.2.8 / 5.2.011

=== Pre-event tasks ===

==== Remaining tasks ====

* Provide information about lodging options (hotels, backpackers, etc)

* Provide information about what's up in Berlin
* Provide information about restaurants
* Plan/order catering
* Discuss swag (t-shirts ? mugs ?)
* Discuss BBQ event or similar for saturday night
* @DIW-IT: Prepare WLAN-access tix.
* consider whatsapp(or similar) channel for last minute communication
* consider side events:
** [https://sdtb.de/museum-of-technology/623/ Museum of Technology](they have an ancient Zuse computer on display)
** [http://www.computerspielemuseum.de/1210_Home.htm Video game museum]
** Group picture at the Brandenburg Gate ?
** Fancy dinner (or breakfast!) at the [https://tv-turm.de/en/bar-restaurant/ revolving restaurant] up on the tv tower ? (Sponsors???)

==== Completed tasks ====
* {{done}}: Reserve rooms at DIW for 21 - 22 May
* {{done}}: Rooms at DIW have been reserved for May 18-21 and May 23 (May 18 + 21: office room(s); May 19/20/23: meeting room)
* {{done}}: provide information about the venue and how to get there
* {{done}}: Provide information about public transport

=== Via IRC chat ===

(IRC is a nice archaic chat system, see [[IRC]])

{|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|'''No'''
|width=130px|'''Participant '''
|width=100px|'''Country'''
|'''Note'''
|-
|@#
|...
|
|
|-
|}

== Individual Preparation ==

* Bring your own computer
* Bring [http://en.wikipedia.org/wiki/Mains_electricity_by_country your power connector adapter] if needed (photo: [https://en.wikipedia.org/wiki/File:Schuko_plug_and_socket.png Germany]). See also http://www.power-plugs-sockets.com/
* Install subversion, '''git''', and the compiler tools, and come with a working GRASS development environment if possible.

== Photos ==

== Reports ==

See [[Talk:GRASS_Community_Sprint_Berlin_2019]]

== FAQ ==

* ''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 Martin Landa <tt>landa.martin gmail.com</tt>

[[Category: Workshops]]
[[Category: Code Sprint]]
[[Category: 2019]]

Talk:GRASS Community Sprint Prague 2013

2013-07-16T15:47:40Z

⚠️Huhabla: /* Sören Gebbert aka huhabla */

== Participant comments and plans ==

...

=== Joint efforts ===

(see [[GRASS_Community_Sprint_Prague_2013#In_person|here]] for participants' names)

* Creating 3D vector test data (for 3D interpolation) - ES, SG, MN
* Added [[Image_processing#General_introduction|General introduction]] (based on manual of G7/i.vi by Yann Chemin) - MN, MN, YC
* Discussions on Bundle Block Adjustments - YC, ST
* wxGUI refactoring - AP, VP
* Presentation of state of image processing in GRASS 7 - YC, MN
* Presentation of state of Temporal GIS Algebra in GRASS 7 - SG, TL
* ISIS-GRASS bridge port to GRASS7 - YC, VP, ML, MN
* Discussions on potential integration of Rasdaman software as raster data backend - SG, YC, and Jachym (virtually)
* Presentation on vector conflation - TF with discussion
* ...

=== Individual Reports ===

Here the (very incomplete) list of individual efforts:

==== Martin Landa ====

* Community Sprint organization
* OSGeo4W GRASS 6.4.3RC4 package published
* Fix {{cmd|v.pack|version=70}} on MS Windows, {{rev|57117}}
* Fix {{cmd|v.unpack|version=70}} on MS Windows, {{rev|57121}}

==== Markus Neteler ====

* Community Sprint Budget management (available on request)
* r.wf Addon fixed: {{rev|57075}} and {{rev|57076}}
* r.ipso Addon fixed: {{rev|57077}}
* Draft Doxygen'iation of the CDHC [http://grass.osgeo.org/programming7/cdhclib.html library for testing normality & exponentiality]
* Added [[Image_processing#General_introduction|General introduction]] (based on manual of G7/i.vi by Yann Chemin) - MN, MN, YC

==== Yann Chemin ====

* ISIS-GRASS bridge port to GRASS7 (with Vaclav, Martin and MarkusN)
If ISIS (http://isis.astrogeology.usgs.gov) is installed,
GRASS will load it in the background,
the banner and prompt will change to ISIS-GRASS.
Both ISIS and GRASS commands are available at the ISIS-GRASS prompt.

* g.isis3mt exports a ISIS3 template from current location, ported into GRASS 7

* Tested direct access of ISIS3 data into G7, r.in.gdal and r.external both work (tested Mars MOLA and Dawn test_datasets)

* Discussed with Soeren, Vaclav and Jachym about Rasdaman, Voxel lib and Raster handling in Grass 8, we agreed on investigating handling, interfaces and performances.

* Went through the Bundle Block Adjustment files with Stepan

* Landsat 7 chain processing using pyGRASS goes in testing mode with MarkusN and Soeren

* Worked more on r.crater

==== Margherita Di Leo ====

* r.basin ported to G7 {{rev|57091}}, {{rev|57096}}
* r.basin html fixed {{rev|57110}}

==== Markus Metz ====

* r.stream.* modules: clean up before moving from addons to trunk {{rev|57151}}, {{rev|57152}}
* GRASS wiki image processing update (MM, MN, YC)
* standardizing options for v.db.* and db.* modules, updating respective manuals

==== Anne Ghisla aka aghisla ====

* Google Summer of Code live discussions
* v.krige fixed in G7 {{rev|57146}} and following

==== Sören Gebbert aka huhabla ====

* Google Summer of Code Temporal Algebra presentation and implementation support
* Discussion of RASDAMAN GRASS integration
* Discussion and implementation of the new temporal module t.rast.accumulate and the use of a modified version of r.gdd (implemented by Markus Metz) instead of r.mapcalc
* Writing and updating of many temporal modules manual pages
* Implementing a prototype that uses Python multiprocessing and a new display C-library function derived from g.pnmcomp to speedup the image composition in the wx GUI

==== Stepan Turek ====

* Working on Google Summer of Code project
* Went through the Bundle Block Adjustment files with Yann
* Released source code of scatter plot backend to baclend {{rev|57180}} and turns backend {{rev|57179}}
* Discussed GSoC with Martin and Soren

==== Thomas Leppelt ====

* Working on GSoC Project: Temporal Algebra
* Implementing functions for if-statements in the temporal algebra

==== Milena Nowotarska ====

* GUI translation to Polish

==== Anna Petrasova ====

* attempts to compile wxPython with wxGTK3/Broadway (HTML5) backend, so far not successfull, see [http://wxpython-users.1045709.n5.nabble.com/wxPython-with-wxGTK3-Broadway-HTML5-based-backend-td5718030.html discussion]
* wxGUI refactoring
* wxGUI design
* toolboxes: discussion, adding <addons> tag

==== Vaclav Petras ====

* compiling wxPython with wxGTK3/Broadway with Anna
* discussion of Rasdaman GRASS integration
* wxGUI refactoring
* wxGUI design
* toolboxes: discussion
* ISIS-GRASS bridge port to GRASS7 with Yann

==== Eva Stopková ====
* debug of plotting variogram output in module v.kriging (not published yet)
* discussion about kriging methods in GRASS GIS with Anne
* discussion about optimalization and testing modules (not published yet) v.kriging (2D/3D kriging) and v.nna (2D/3D Nearest Neighbour Analysis) with Marcus N. and Soeren G.
* improving and debugging other functions of module v.kriging
* numerical testing of v.kriging

==== Tereza Fiedlerová ====
* learning something about GRASS GIS vector modules
* discussion about own QGIS plugin and C++ library for vector conflation and its possible implementation to GRASS
* beginning to write C API for vector conflation library (needed for GRASS implementation)

== Video-conferencing options ==

Q: is Google Hangouts smartphones only?
: ''not sure, but I'm pretty sure you can get a web browser plugin for all major desktop OSs''

Q: do you have to be signed up with a Google+ social media account?
: ''in theory no, but in practice they strongly funnel you that way''

Q: is Jitsi on a desktop computer compatible with G+?
: ''at the text chat level, yes. video and voice via Google Talk, reported to work with Voice, not sure about video''

; [http://www.jitsi.org Jitsi]
: ''It is compatible with GoogleTalk instant messaging (and most other instant messaging including the XMPP RFC like Facebook; Skype is the notable one that it doesn't work with), not sure about GoogleTalk's voice calls, I'd give that a 80% chance of working.
: An interesting side-project Jisti offers its own work-alike free multi-person video chat for XMPP(Jabber compatibles) which is not limited to 10 people: [https://jitsi.org/Projects/JitsiVideobridge VideoBridge]. Given enough bandwidth and a modern desktop CPU acting as the bridge server, you can have someone in a G+ hangout share their desktop to pass through the other members of the video hangout.
: Also there's a functional alpha-release Android client.
: For Jitsi <-> Jitsi video you may need a valid XMPP account. Many (federated in a single grid) providers for that, so it doesn't matter much who. Jitsi run a simple registry at http://jit.si
: All quite interesting possiblies and the development is quite active -- but is it there yet? I'm not sure, probably a not far away "almost"; if so, perhaps we could run the bridge on Adhoc for a few days (can run as an unprivilidged user, needs Java 6, chat "host" user needs shell access to set magic pass word and get the assigned port numbers to plug into their client), or perhaps host it at fsv.cvut.cz? (i.e. locate it at the shortest hop to max number of participants using it) --HB''

Talk:GRASS Community Sprint Prague 2013

2013-07-15T15:51:20Z

⚠️Huhabla: /* Individual Reports */

== Participant comments and plans ==

...

=== Joint efforts ===

(see [[GRASS_Community_Sprint_Prague_2013#In_person|here]] for participants' names)

* Creating 3D vector test data (for 3D interpolation) - ES, SG, MN
* Added [[Image_processing#General_introduction|General introduction]] (based on manual of G7/i.vi by Yann Chemin) - MN, MN, YC
* Discussions on Bundle Block Adjustments - YC, ST
* wxGUI refactoring - AP, VP
* Presentation of state of image processing in GRASS 7 - YC, MN
* Presentation of state of Temporal GIS Algebra in GRASS 7 - SG, TL
* ISIS-GRASS bridge port to GRASS7 - YC, VP, ML, MN
* Discussions on potential integration of Rasdaman software as raster data backend - SG, YC, and Jachym (virtually)
* Presentation on vector conflation - TF with discussion
* ...

=== Individual Reports ===

Here the (very incomplete) list of individual efforts:

==== Martin Landa ====

* Community Sprint organization
* OSGeo4W GRASS 6.4.3RC4 package published
* Fix {{cmd|v.pack|version=70}} on MS Windows, {{rev|57117}}
* Fix {{cmd|v.unpack|version=70}} on MS Windows, {{rev|57121}}

==== Markus Neteler ====

* Community Sprint Budget management (available on request)
* r.wf Addon fixed: {{rev|57075}} and {{rev|57076}}
* r.ipso Addon fixed: {{rev|57077}}
* Draft Doxygen'iation of the CDHC [http://grass.osgeo.org/programming7/cdhclib.html library for testing normality & exponentiality]
* Added [[Image_processing#General_introduction|General introduction]] (based on manual of G7/i.vi by Yann Chemin) - MN, MN, YC

==== Yann Chemin ====

* ISIS-GRASS bridge port to GRASS7 (with Vaclav, Martin and MarkusN)
If ISIS (http://isis.astrogeology.usgs.gov) is installed,
GRASS will load it in the background,
the banner and prompt will change to ISIS-GRASS.
Both ISIS and GRASS commands are available at the ISIS-GRASS prompt.

* g.isis3mt exports a ISIS3 template from current location, ported into GRASS 7

* Tested direct access of ISIS3 data into G7, r.in.gdal and r.external both work (tested Mars MOLA and Dawn test_datasets)

* Discussed with Soeren, Vaclav and Jachym about Rasdaman, Voxel lib and Raster handling in Grass 8, we agreed on investigating handling, interfaces and performances.

* Went through the Bundle Block Adjustment files with Stepan

* Worked more on r.crater

==== Margherita Di Leo ====

* r.basin ported to G7 {{rev|57091}}, {{rev|57096}}
* r.basin html fixed {{rev|57110}}

==== Markus Metz ====

* r.stream.* modules: clean up before moving from addons to trunk {{rev|57151}}, {{rev|57152}}
* GRASS wiki image processing update (MM, MN, YC)

==== Anne Ghisla aka aghisla ====

* Google Summer of Code live discussions
* v.krige fixed in G7 {{rev|57146}} and following

==== Sören Gebbert aka huhabla ====

* Google Summer of Code Temporal Algebra presentation and implementation support
* Discussion of RASDAMAN GRASS integration
* Discussion and implementation of the new temporal module t.rast.accumulate and the use of a modified version of r.gdd (implemented by Markus Metz) instead of r.mapcalc
* Writing and updating of many temporal modules manual pages

==== Stepan Turek ====

* Working on Google Summer of Code project
* Went through the Bundle Block Adjustment files with Yann

== Video-conferencing options ==

Q: is Google Hangouts smartphones only?
: ''not sure, but I'm pretty sure you can get a web browser plugin for all major desktop OSs''

Q: do you have to be signed up with a Google+ social media account?
: ''in theory no, but in practice they strongly funnel you that way''

Q: is Jitsi on a desktop computer compatible with G+?
: ''at the text chat level, yes. video and voice via Google Talk, reported to work with Voice, not sure about video''

; [http://www.jitsi.org Jitsi]
: ''It is compatible with GoogleTalk instant messaging (and most other instant messaging including the XMPP RFC like Facebook; Skype is the notable one that it doesn't work with), not sure about GoogleTalk's voice calls, I'd give that a 80% chance of working.
: An interesting side-project Jisti offers its own work-alike free multi-person video chat for XMPP(Jabber compatibles) which is not limited to 10 people: [https://jitsi.org/Projects/JitsiVideobridge VideoBridge]. Given enough bandwidth and a modern desktop CPU acting as the bridge server, you can have someone in a G+ hangout share their desktop to pass through the other members of the video hangout.
: Also there's a functional alpha-release Android client.
: For Jitsi <-> Jitsi video you may need a valid XMPP account. Many (federated in a single grid) providers for that, so it doesn't matter much who. Jitsi run a simple registry at http://jit.si
: All quite interesting possiblies and the development is quite active -- but is it there yet? I'm not sure, probably a not far away "almost"; if so, perhaps we could run the bridge on Adhoc for a few days (can run as an unprivilidged user, needs Java 6, chat "host" user needs shell access to set magic pass word and get the assigned port numbers to plug into their client), or perhaps host it at fsv.cvut.cz? (i.e. locate it at the shortest hop to max number of participants using it) --HB''

GRASS Community Sprint Prague 2013

2013-07-03T09:23:12Z

⚠️Huhabla: /* In person */

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


'''Important dates:'''

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

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

== Purpose ==

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

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

== Sponsors ==

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

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

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

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

=== Thanks to our sponsors ===

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


== Timing ==

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

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

'''Duration''': tbd

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

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

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

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

== Accommodation and Costs ==

Participants should plan for the following costs:

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

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

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

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

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

== Weather and Common Item Prices ==

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

== Agenda - What we plan to do ==

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

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

=== Timeline ===

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


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

* 9:00-evening


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

* 9:00-evening


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

* 9:00-evening


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

* 9:00-evening


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

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

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

* Last meeting
* Farewell and have a good trip home

== Participation ==

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

=== In person ===

{|class="wikitable sortable" border="2" cellspacing="0" cellpadding="4" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse; background-color:#edf9c7; font-size:95%; empty-cells:show;"
!width=50px|'''Number'''
!width=130px|'''Participant '''
!width=100px|'''Country'''
!width=100px|'''Arrival'''
!width=100px|'''Departure'''
!'''Topic'''
!width=75px|'''T-Shirt'''
!'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
|Czech Republic
| July 12
| July 18
| Toolbox concept, vector engine in GRASS 7, wxGUI, PostGIS Topology support, 3D topology
| L
|
|-
|2
| [[User:Neteler|Markus Neteler]]
| Italy
| July 12
| July 19
| Preparation of GRASS 7.0 release, automated unit testing on grass.osgeo.org
| M
|
|-
|3
| [[User:Helena|Helena Mitasova]]
| USA
| July 16 pm
| July 18
| Data exchange, metadata, GRASS7 data sets, temporal data
| M
|
|-
|4
| [[User:benducke|Benjamin Ducke]]
| Germany
| July 15 (+/- 1)
| July 18 (+/- 1)
| 3D interpolation in GRASS 7 (GSoC), misc.
| M
|
|-
|5
| [[User:ychemin|Yann Chemin]]
| France
| July 11 at 15.00
| July 16 at 09.55
| image processing, planetary integration
| XXL
|
|-
|6
| [[User:huhabla|Sören Gebbert]]
| Germany
| July 12
| July 18 (am)
| GRASS GIS Temporal Framework, Temporal GIS Algebra, WPS, visualization and animation of spatio-temporal data
| XL
|
|-
|7
| [[User:annakrat|Anna Petrasova]]
| Czech Republic
| July 11
| July 18
| wxGUI (toolboxes, refactoring, wxNviz, animations)
| M
|
|-
|8
| [[User:wenzeslaus|Vaclav Petras]]
| Czech Republic
| July 11
| July 18
| wxGUI (toolboxes, refactoring), Programmer's manual Doxygen issues
| M
|
|-
|9
| [[User:turek|Štěpán Turek]]
| Czech Republic
| July 11
| July 18
| Scatter Plot, Bundle Adjustment, Turns in vnet.*
| L
|
|-
|10
| [[User:mmetz|Markus Metz]]
| Italy
| July 12
| July 18
| vector engine in GRASS 7, image processing, orthorectification
| L
|
|-
|11
| [[User:mastho|Thomas Leppelt]]
| Germany
| July 12
| July 18 (am)
| Temporal GIS Algebra
| M
|
|-
|12
| [[User:Tereza|Tereza Fiedlerová]]
| Czech Republic
| July 11
| July 18
| vector-to-vector conflation
| S
|
|-
|13
| [[User:Eva|Eva Stopková]]
| Slovak Republic
| July 11
| July 18
| 3D kriging, 3D Nearest Neighbour Analysis
| S
|
|-
|14
| [[User:Madi|Margherita Di Leo]]
| Italy
| July 12
| July 14
| Pest risk analysis, wildfires, hydrology, documentation
| XL
|
|-
|15
|[[User:MilenaN|Milena Nowotarska]]
|Poland
|July 14
|July 18
|translation, wxGUI
|S
|
|-
|16
| ''and you ...''
|
|
|
|
|
|
|-
|}

=== Via IRC chat or hangout===

==== IRC ====
: [irc://freenode/grass #grass] on Freenode

For details, see [[IRC]]

==== Hangout/Videobridge ====

There is the option to use Google+ Hangout, it's limited to 10 people and may require everyone to have G+ social media accounts to participate. (?)

Similarly multi-video conference calls can be done with Skype if the conference call initiator is a paid-up commercial Skype customer.

The FOSS [http://www.jitsi.org Jitsi] VoIP, IM, and video conferencing software produces a trivial to set up [https://jitsi.org/Projects/JitsiVideobridge VideoBridge] server software to the same.

Further discussion on the pros and cons of these can be found on the [[Talk:GRASS_Community_Sprint_Prague_2013|Talk side of this wiki page]].

* [http://www.google.com/+/learnmore/hangouts/ Information on G+ hangout]

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

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

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

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

=== Collaborative document scratching ===

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

Please check http://titanpad.com/grass-sprint-july2013
: (example from last time: http://titanpad.com/I51nq1SrNc)


== Individual Preparation ==

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

== Broadcast & Video ==

During the event :)

== Photos ==

Also during the event :)

== FAQ ==

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

== Press Release ==

''(to be done)''


[[Category: Workshops]]

GRASS Community Sprint Prague 2013

2013-05-30T06:53:54Z

⚠️Huhabla: /* In person */

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


'''Important dates:'''

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

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

== Purpose ==

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

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

== Sponsors ==

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

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

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

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

=== Thanks to our sponsors ===

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


== Timing ==

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

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

'''Duration''': tbd

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

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

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

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

== Accommodation and Costs ==

Participants should plan for the following costs:

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

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

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

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

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

== Weather and Common Item Prices ==

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

== Agenda - What we plan to do ==

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

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

=== Timeline ===

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


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

* 9:00-evening


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

* 9:00-evening


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

* 9:00-evening


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

* 9:00-evening


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

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

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

* Last meeting
* Farewell and have a good trip home

== Participation ==

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

=== In person ===

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

=== Via IRC chat or hangout===

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

For details, see [[IRC]]

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

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

'''Timing of hangout meetings:'''

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

=== Collaborative document scratching ===

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

Please check http://titanpad.com/I51nq1SrNc

== Individual Preparation ==

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

== Broadcast & Video ==

During the event :)

== Photos ==

Also during the event :)

== FAQ ==

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

== Press Release ==

''(to be done)''


[[Category: Workshops]]

Compile and Install Ubuntu

2013-05-10T15:54:41Z

⚠️Huhabla: /* Current stable Ubuntu version */

<div class="boilerplate metadata" id="attention" style="-moz-border-radius:30px; border: 1px double #35824B; margin-bottom: 1.5em; padding: 1em; background-color: #f9f9f9;">
'''Attention''' '''The following instructions describe the compilation and installation of GRASS 6.x (or even 7) and its required dependencies completely from the source on Ubuntu based systems. Please, prefer pre-compiled packages over the manual way described below unless you know ''what'' and ''how'', you want to learn and help testing.'''
</div>

== Very Important notes ==

* Pre-compiled packages and backports are available from [https://wiki.ubuntu.com/UbuntuGIS UbuntuGIS] via their [https://launchpad.net/~ubuntugis/+archive/ppa/ ppa.launchpad] repositories. '''This is by far the simplest and fastest solution. Please prefer it over the manual way described below.'''

* To build an updated version of GRASS or support libraries unmodified, in most cases it will be easier to use an automated build tool such as ''pbuilder'', ''debuild'' or ''cowbuilder''. See the <source lang="bash" enclose="none">debian/</source> directory in the source code for details.

* Some things change fast and therefore it is expected that the instructions might fail. Please inform the grass-user list in case something just does not work (like for example non-available dependecies/packages from the repositories) or update this page respectively.

* GRASS version 6.5 exists for development purposes, testing features to-be backported to version 6.4. As such it may include unstable code and is not intended for production and end-users.

* An alternate method is to use the DebianGIS packaging scripts, which enable a lot of this to happen automatically (see [https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4/debian/README.debian debian/README.debian] in the GRASS Subversion source code repository). Specifically, this command will get you 90% of the way there: <source lang="bash">sudo apt-get build-dep grass</source>
: ''(you'll need to have the deb-src lines active in your /etc/apt/sources.list file)''

== Hints ==

* Usually, the installation of compiled code is done by using the <source lang="bash" enclose="none">make</source> tool. Alternatively, this can be done by using the ''checkinstall'' tool (i.e., <source lang="bash" enclose="none">sudo checkinstall</source> instead of <source lang="bash" enclose="none">sudo make install</source>) which eases off removal of packages. If ''checkinstall'' fails to deliver, please note some related bugs: [https://bugs.launchpad.net/ubuntu/+source/checkinstall/+bug/78455 78455] and [https://bugs.launchpad.net/ubuntu/+source/checkinstall/+bug/599163 599163]. Useful information on using ''checkinstall'': [https://help.ubuntu.com/community/CompilingEasyHowTo Compiling things on Ubuntu the Easy Way].

* In multi-core processors, the compilation performance can be boosted by using ''-j'' switches (e.g. <source lang="bash" enclose="none">make -j2</source> or <source lang="bash" enclose="none">make -j3</source> or even <source lang="bash" enclose="none">make -j4</source>) which specify the number of jobs (commands) to run simultaneously.

== Dependencies ==

=== Current stable Ubuntu version ===

The following dependencies concern [http://releases.ubuntu.com/quantal/ Ubuntu Quantal Quetzal (12.10)]

* First, update the system from the repositories<source lang="bash">
sudo apt-get update && sudo apt-get upgrade
</source>

* then, install ''SQLite'', ''SVN'' and ''dependencies'' for compiling PROJ, GEOS, GDAL/OGR, GRASS, GDAL-GRASS-PLUGIN; the following action will also install various dependencies (listed in the command line as <source lang="bash" enclose="none">The following extra packages will be installed:</source>...): 
<ul>
<source lang="bash">
# this is a single command, please copy-paste it entirely into the terminal:
sudo apt-get install \
build-essential \
flex make bison gcc libgcc1 g++ cmake ccache \
python python-dev python-qt4 python-qt4-dev \
python-opengl \
python-wxversion python-wxtools python-wxgtk2.8 \
python-dateutil libgsl0-dev python-numpy \
wx2.8-headers wx-common libwxgtk2.8-dev libwxgtk2.8-dbg \
libwxbase2.8-dev libwxbase2.8-dbg \
libncurses5-dev \
zlib1g-dev gettext \
libtiff-dev libpnglite-dev \
tcl8.5-dev tk8.5-dev \
libcairo2 libcairo2-dev \
sqlite3 libsqlite3-dev \
libpq-dev \
libreadline6 libreadline6-dev libfreetype6-dev \
txt2tags \
libfftw3-3 libfftw3-dev \
libqt4-core libqt4-dbg libqt4-dev libqt4-gui libqt4-sql libqt4-qt3support \
lsb-qt4 qt4-designer qt4-dev-tools qt4-doc qt4-qtconfig \
libapt-pkg-perl resolvconf \
libjasper-dev \
ruby \
subversion \
ffmpeg ffmpeg2theora \
libffmpegthumbnailer-dev \
libavcodec-dev \
libxmu-dev \
libavformat-dev libswscale-dev \
checkinstall \
libglu1-mesa-dev libxmu-dev</source>
</ul>

* for mysql support, <source lang="bash" enclose="none">libmysqlclient-dev</source> is required <source lang="bash">
sudo apt-get install libmysqlclient-dev
</source>

* for netcdf support, <source lang="bash" enclose="none">netcdf-bin</source> and <source lang="bash" enclose="none">libnetcdf-dev</source> is required <source lang="bash">
sudo apt-get install netcdf-bin libnetcdf-dev
</source>

* create a directory as a simple user where all source code is going to be stored -- in this example, a directory named <source lang="bash" enclose="none">src</source> under <source lang="bash" enclose="none">/usr/local</source> is created <source lang="bash">
sudo mkdir /usr/local/src
</source>

* take over directories ownerships ('''replace''' below the terms ''userid'' and ''groupid'' with a real <source lang="bash" enclose="none">userid</source>): <source lang="bash">
sudo chown userid:groupid /usr/local/src</source>

* similarly, grant <source lang="bash" enclose="none">rwx</source> (read-write-execute) permissions for our ''userid'' and ''groupid'' onto the <source lang="bash" enclose="none">src</source> directory: <source lang="bash">
sudo chmod ug+rwx /usr/local/src</source>

=== Earlier Ubuntu versions ===

For [http://old-releases.ubuntu.com/releases/ earlier Ubuntu versions], '''watch out for dependency differences!''' Modify the dependency list given above as instructed below.

* for [http://releases.ubuntu.com/precise/ Ubuntu Precise Pangolin (12.04)], change the following dependencies:
** <source lang="bash" enclose="none">libpnglite-dev --> libpngwriter-dev</source>
** <source lang="bash" enclose="none">libtiff5-dev --> libtiff4-dev</source>

* for [http://old-releases.ubuntu.com/releases/maverick/ Ubuntu Maverick Meerkat (10.10)] or later, change the following dependencies:
** <source lang="bash" enclose="none">libpngwriter-dev --> libpngwriter0-dev</source>
** <source lang="bash" enclose="none">libcairo-dev --> libcairo2-dev</source>
** <source lang="bash" enclose="none">fftw3 --> libfftw3-3</source>
** <source lang="bash" enclose="none">fftw3-dev --> libfftw3-dev</source>

* for [http://old-releases.ubuntu.com/releases/lucid/ Ubuntu Lucid Lynx (10.04)] or later, also install: <source lang="bash">sudo apt-get install libhdf4-alt-dev libhdf4-0-alt</source>

* for [http://old-releases.ubuntu.com/releases/ earlier Ubuntu versions], also install: <source lang="bash"> sudo apt-get install libhdf4g-dev libhdf4g-run</source>

== Using pre-compiled dev Packages for PROJ.4, GEOS and GDAL ==

=== PROJ.4 ===

Install the <source lang="bash" enclose="none">dev</source> package (possibly without support for datumgrid):

<source lang="bash">
sudo apt-get install libproj-dev
</source>

* In the call to <source lang="bash" enclose="none">./configure</source> for [[#GRASS|GRASS]], replace <source lang="bash" enclose="none">--with-proj-share=/usr/local/share/proj/</source> by <source lang="bash" enclose="none">--with-proj-share=/usr/share/proj/</source>

=== GEOS ===

Install the <source lang="bash" enclose="none">dev</source> package:

<source lang="bash">
sudo apt-get install libgeos-dev
</source>

* In the call to <source lang="bash" enclose="none">./configure</source> for [[#GRASS|GRASS]], replace <source lang="bash" enclose="none">--with-geos=/usr/local/bin/geos-config</source> by <source lang="bash" enclose="none">--with-geos=/usr/bin/geos-config</source>

=== GDAL ===

Install the <source lang="bash" enclose="none">dev</source> package (possibly without support for datumgrid):

<source lang="bash">
sudo apt-get install libgdal-dev
</source>

* Install also the required extra packages (note the message: <source lang="bash" enclose="none">The following extra packages will be installed:</source>)
* Look out for packages to be removed by this operation -- this is most likely caused by incompatible package versions. Fix these problems in advance using commands like the following: <source lang="bash">
sudo apt-get install <package>=<required.version></source>

=== GRASS-GIS ===

[[Compile_and_Install_Ubuntu#GRASS_GIS|Jump to sub-section GRASS-GIS below]]

== Compile from source ==

=== PROJ4 ===

* within the directory <source lang="bash" enclose="none">/usr/local/src</source> (create it if it does not exist) checkout <source lang="bash" enclose="none">proj</source> from its Subversion repository: <source lang="bash">
svn co http://svn.osgeo.org/metacrs/proj/branches/4.8/proj/
</source>

* get [http://download.osgeo.org/proj/proj-datumgrid-1.5.zip '''proj-datumgrid-1.5.zip'''] from [http://trac.osgeo.org/proj proj' trac] and move it under <source lang="bash" enclose="none">proj/nad</source>
<ul><source lang="bash">
wget http://download.osgeo.org/proj/proj-datumgrid-1.5.zip
mv proj-datumgrid-1.5.zip /usr/local/src/proj/nad
cd /usr/local/src/proj/nad
</source>
</ul>

* decompress it <source lang="bash">
unzip proj-datumgrid-1.5.zip
</source>

* go back to the <source lang="bash" enclose="none">proj</source> directory <source lang="bash">
cd /usr/local/src/proj
</source>

* if required, clean previous configuration & compilation <source lang="bash">
make distclean
</source>

* simple configure, compile and install <source lang="bash">
./configure && make && sudo make install
</source>
<ul> or <source lang="bash">
./configure && make -j2 && sudo checkinstall
</source>
</ul>

* ensure that <source lang="bash" enclose="none">/usr/local/lib</source> is added to <source lang="bash" enclose="none">/etc/ld.so.conf</source> and afterwards run <source lang="bash">
sudo ldconfig
</source>

* finally, go back to the parent directory simply by instructing<source lang="bash">
cd ..
</source>

=== GEOS ===

* download '''geos-3.3.5.tar.bz2''' from [http://trac.osgeo.org/geos/ http://trac.osgeo.org/geos] using <source lang="bash" enclose="none">wget</source> <source lang="bash">
wget http://download.osgeo.org/geos/geos-3.3.5.tar.bz2
</source>

* move to the "source-code" directory and decompress
<ul><source lang="bash">
cd /usr/local/src/
bunzip2 geos-3.3.5.tar.bz2
tar xvf geos-3.3.5.tar
</source>
</ul>

* if required, clean previous configuration & compilation <source lang="bash">
make distclean
</source>

* move to geos directory <source lang="bash">
cd geos-3.3.5
</source>

* simple configure, compile and install <source lang="bash">
./configure && make && sudo make install
</source>
<ul> or <source lang="bash">
./configure && make -j2 && sudo checkinstall
</source>
</ul>

* do not forget to execute <source lang="bash">
sudo ldconfig
</source>

=== GDAL ===

'''Note''', GDAL must be compiled '''without''' GRASS support

* download the current stable version <source lang="bash">
svn checkout https://svn.osgeo.org/gdal/branches/1.9/gdal gdal_stable
</source>

* enter in the <source lang="bash" enclose="none">gdal_stable</source> directory <source lang="bash">
cd /usr/local/src/gdal_stable
</source>

* optionally, update the source code <source lang="bash">
svn up
</source>

* if required, clean previous configurations/compilations <source lang="bash">
make distclean
</source>

* a simple configuration without any parameters will detect and support various installed libraries <source lang="bash">
./configure
</source>

* skip to the ''compile and install'' step or check the following customised configuration example
<ul>
<source lang="bash">
CFLAGS="-g -Wall" LDFLAGS="-s" ./configure \
--with-png=internal \
--with-libtiff=internal \
--with-geotiff=internal \
--with-jpeg=internal \
--with-gif=internal \
--with-ecw=yes \
--with-expat=yes \
--with-sqlite3=yes \
--with-geos=yes \
--with-python \
--with-libz=internal \
--with-netcdf \
--with-sqlite \
--with-threads=yes \
--without-grass \
--without-ogdi \
--with-pg=/usr/bin/pg_config \
--with-xerces=yes
</source>
</ul>

* compile, install & ldconfig <source lang="bash">
make -j2 && sudo make install && sudo ldconfig
</source>
<ul> or <source lang="bash">
make -j2 && sudo checkinstall && sudo ldconfig
</source>
</ul>

=== GRASS GIS ===

<div class="boilerplate metadata" id="attention" style="-moz-border-radius:30px; border: 1px double #4da948; margin-bottom: 1em; padding: 0 .25em; background-color: #dcdcdc;">
'''Recommendation''' Before attempting to compile GRASS, read the <code>INSTALL</code> file, which is located in GRASS' source code root directory. Pay attention especially to section <code>(C)</code>, entitled <code>COMPILATION NOTES for 64bit platforms</code>.
</div>

''' Getting GRASS' source code '''

* get current state of the 6.4.x release branch version (stable) <source lang="bash">
svn co https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4 grass64_release
</source>

To download under development versions use

* for GRASS 6.5 (Note: ''GRASS version 6.5 is not intended for end-users! It exists for development purposes which should rather take place for GRASS 7.'') <source lang="bash">
svn checkout https://svn.osgeo.org/grass/grass/branches/develbranch_6 grass6_devel
</source>

* for GRASS 7 <source lang="bash">
svn checkout https://svn.osgeo.org/grass/grass/trunk grass_trunk
</source>

* for subsequent updates execute <source lang="bash">
svn up
</source>

''' Configure, Compile and Install'''

* if required, clean previous configuration & compilation (not needed the first time) <source lang="bash">
make distclean
</source>

* example configuration (which can/should be adjusted according to specific needs):
<ul>
<source lang="bash">
./configure \
--enable-largefile=yes \
--with-nls \
--with-cxx \
--with-proj-share=/usr/local/share/proj/ \
--with-geos=/usr/local/bin/geos-config \
--with-python=yes \
--with-wxwidgets \
--with-cairo \
--with-tcltk-includes="/usr/include/tcl8.5/" \
--with-opengl-libs=/usr/include/GL \
--with-motif \
--with-ffmpeg=yes --with-ffmpeg-includes="/usr/include/libavcodec /usr/include/libavformat /usr/include/libswscale" \
--with-freetype=yes --with-freetype-includes="/usr/include/freetype2/" \
--with-postgres=yes \
--with-postgresql=yes --with-postgres-includes="/usr/include/postgresql" \
--with-sqlite=yes \
--with-mysql=yes --with-mysql-includes="/usr/include/mysql" \
--with-odbc=yes</source>
</ul>

<ul>
'''Note''', the above configuration uses the <code>Proj4</code> and <code>GEOS</code> packages compiled from the source. In the case that pre-compiled versions from the repository are required, remove the above corresponding lines to use the "defaults", i.e. <source lang="bash">
--with-proj-share=/usr/share/proj \
--with-geos=/usr/bin/geos-config \
</source>
</ul>

* compile & install <source lang="bash">
make -j2 && sudo make install && sudo ldconfig
</source>

<ul> or <source lang="bash">
make -j2 && sudo checkinstall && sudo ldconfig
</source>
</ul>

=== GDAL-GRASS-Plugin ===

* get the plugin from [http://download.osgeo.org/gdal OSGeo's Download Server]: [http://download.osgeo.org/gdal/gdal-grass-1.4.3.tar.gz http://download.osgeo.org/gdal/gdal-grass-1.4.3.tar.gz] using <source lang="bash" enclose="none">wget</source> <source lang="bash">
wget http://download.osgeo.org/gdal/gdal-grass-1.4.3.tar.gz</source>

* create <source lang="bash" enclose="none">/etc/ld.so.conf.d/grass6.conf</source> or add in <source lang="bash" enclose="none">/etc/ld.so.conf</source> the GRASS library path, i.e. <source lang="bash" enclose="none">/usr/local/src/grass64_release/lib</source>
* optionally, clean previous configurations/compilations<source lang="bash">
make distclean</source>

* configure -- point to GRASS installation/binaries
<ul>
<source lang="bash"> ./configure \
--prefix=/usr/local \
--with-gdal=/usr/local/bin/gdal-config \
--with-grass=/geo/osgeo/src/grass64_release/dist.x86_64-unknown-linux-gnu/ \
--with-autoload="/usr/local/lib/gdalplugins/" \
--with-ld-shared="g++ -shared"</source>
</ul>
<ul>
* for GRASS 6.5, replace the respective line above, depending on where the source code in question is stored, with something like<source lang="bash" enclose="none"> --with-grass=/usr/local/grass-6.5.svn/</source>
* for GRASS 7, replace with <source lang="bash" enclose="none"> --with-grass=/usr/local/grass_trunk/</source>
</ul>
* compile & install using checkinstall<source lang="bash">
make -j2 && sudo checkinstall</source>

= Post compilation/installation control =

* For a recommended quick-check read the [http://grass.osgeo.org/wiki/Compile_and_install_GRASS_and_QGIS_with_GDAL/OGR_Plugin#Troubleshooting Troubleshooting] section at [http://grass.osgeo.org/wiki/Compile_and_install_GDAL-GRASS_plugin Compile_and_install_GDAL-GRASS_plugin]

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

* another common mistake is compiling a module against some GRASS version and then try to run it through another GRASS version. The solution is to recompile the affected module or, in case there are multiple GRASS installations, set up properly LD_LIBRARY_PATH paths.

= Removal of GRASS =

To get rid of a GRASS binaries installation, delete
* <source lang="bash" enclose="none">/usr/local/grass-6.4.0svn</source> (directory, binaries location)
* <source lang="bash" enclose="none">/usr/local/bin/grass64</source> (file)
* <source lang="bash" enclose="none">/usr/local/bin/gem64</source> (file)
* <source lang="bash" enclose="none">/home/username/.grassrc6</source> (file)

If wanted, delete also the complete source code:
* <source lang="bash" enclose="none">/usr/local/src/grass_64svn</source> (directory, source code location)

To remove <code>grass</code> (or any other package) which was installed by <source lang="bash" enclose="none">checkinstall</source>, use <source lang="bash" enclose="none">dpkg</source>, e.g.<source lang="bash">
sudo dpkg -r grass64 # package name defined at installation is important</source>

= Packaging of GRASS =

* See the {{src|debian/README.debian}} file in the GRASS source code for directions on rolling your own packages.

For details about the auto-nightly-builds and after-market supplied packages from UbuntuGIS, please refer to the [[Ubuntu Packaging]] wiki page.

== See also ==

* [[Ubuntu Packaging]]
* [[GRASS in Debian]]

[[Category: Compilation]]
[[Category: Installation]]
[[Category: Ubuntu]]
[[Category: FAQ]]

Compile and Install Ubuntu

2013-05-10T15:53:10Z

⚠️Huhabla: /* Current stable Ubuntu version */

<div class="boilerplate metadata" id="attention" style="-moz-border-radius:30px; border: 1px double #35824B; margin-bottom: 1.5em; padding: 1em; background-color: #f9f9f9;">
'''Attention''' '''The following instructions describe the compilation and installation of GRASS 6.x (or even 7) and its required dependencies completely from the source on Ubuntu based systems. Please, prefer pre-compiled packages over the manual way described below unless you know ''what'' and ''how'', you want to learn and help testing.'''
</div>

== Very Important notes ==

* Pre-compiled packages and backports are available from [https://wiki.ubuntu.com/UbuntuGIS UbuntuGIS] via their [https://launchpad.net/~ubuntugis/+archive/ppa/ ppa.launchpad] repositories. '''This is by far the simplest and fastest solution. Please prefer it over the manual way described below.'''

* To build an updated version of GRASS or support libraries unmodified, in most cases it will be easier to use an automated build tool such as ''pbuilder'', ''debuild'' or ''cowbuilder''. See the <source lang="bash" enclose="none">debian/</source> directory in the source code for details.

* Some things change fast and therefore it is expected that the instructions might fail. Please inform the grass-user list in case something just does not work (like for example non-available dependecies/packages from the repositories) or update this page respectively.

* GRASS version 6.5 exists for development purposes, testing features to-be backported to version 6.4. As such it may include unstable code and is not intended for production and end-users.

* An alternate method is to use the DebianGIS packaging scripts, which enable a lot of this to happen automatically (see [https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4/debian/README.debian debian/README.debian] in the GRASS Subversion source code repository). Specifically, this command will get you 90% of the way there: <source lang="bash">sudo apt-get build-dep grass</source>
: ''(you'll need to have the deb-src lines active in your /etc/apt/sources.list file)''

== Hints ==

* Usually, the installation of compiled code is done by using the <source lang="bash" enclose="none">make</source> tool. Alternatively, this can be done by using the ''checkinstall'' tool (i.e., <source lang="bash" enclose="none">sudo checkinstall</source> instead of <source lang="bash" enclose="none">sudo make install</source>) which eases off removal of packages. If ''checkinstall'' fails to deliver, please note some related bugs: [https://bugs.launchpad.net/ubuntu/+source/checkinstall/+bug/78455 78455] and [https://bugs.launchpad.net/ubuntu/+source/checkinstall/+bug/599163 599163]. Useful information on using ''checkinstall'': [https://help.ubuntu.com/community/CompilingEasyHowTo Compiling things on Ubuntu the Easy Way].

* In multi-core processors, the compilation performance can be boosted by using ''-j'' switches (e.g. <source lang="bash" enclose="none">make -j2</source> or <source lang="bash" enclose="none">make -j3</source> or even <source lang="bash" enclose="none">make -j4</source>) which specify the number of jobs (commands) to run simultaneously.

== Dependencies ==

=== Current stable Ubuntu version ===

The following dependencies concern [http://releases.ubuntu.com/quantal/ Ubuntu Quantal Quetzal (12.10)]

* First, update the system from the repositories<source lang="bash">
sudo apt-get update && sudo apt-get upgrade
</source>

* then, install ''SQLite'', ''SVN'' and ''dependencies'' for compiling PROJ, GEOS, GDAL/OGR, GRASS, GDAL-GRASS-PLUGIN; the following action will also install various dependencies (listed in the command line as <source lang="bash" enclose="none">The following extra packages will be installed:</source>...): 
<ul>
<source lang="bash">
# this is a single command, please copy-paste it entirely into the terminal:
sudo apt-get install \
build-essential \
flex make bison gcc libgcc1 g++ cmake ccache \
python python-dev python-qt4 python-qt4-dev \
python-opengl \
python-wxversion python-wxtools python-wxgtk2.8 \
python-dateutil libgsl0-dev python-numpy \
wx2.8-headers wx-common libwxgtk2.8-dev libwxgtk2.8-dbg \
libwxbase2.8-dev libwxbase2.8-dbg \
libncurses5-dev \
zlib1g-dev gettext \
libtiff-dev libpnglite-dev \
tcl8.5-dev tk8.5-dev \
libcairo2 libcairo2-dev \
sqlite3 libsqlite3-dev \
libpq-dev \
libreadline6 libreadline6-dev libfreetype6-dev \
txt2tags \
libfftw3-3 libfftw3-dev \
libqt4-core libqt4-dbg libqt4-dev libqt4-gui libqt4-sql libqt4-qt3support \
lsb-qt4 qt4-designer qt4-dev-tools qt4-doc qt4-qtconfig \
libapt-pkg-perl resolvconf \
libjasper-dev \
ruby \
subversion \
ffmpeg ffmpeg2theora \
libffmpegthumbnailer-dev \
libavcodec-dev \
libxmu-dev \
libavformat-dev libswscale-dev \
checkinstall \
libglu1-mesa-dev libxmu-dev</source>
</ul>

* for mysql support, <source lang="bash" enclose="none">libmysqlclient-dev</source> is required <source lang="bash">
sudo apt-get install libmysqlclient-dev
</source>

* for netcdf support, <source lang="bash" enclose="none">netcdf-bin</source> and <source lang="bash" enclose="none">libnetcdf-dev</source> is required <source lang="bash">
sudo apt-get install netcdf-bin libnetcdf-dev
</source>

* In case the compilation of gdal and proj4 is not required, install the following packages <source lang="bash">
sudo apt-get install libproj-dev gdal-bin libgdal-dev
</source>

* create a directory as a simple user where all source code is going to be stored -- in this example, a directory named <source lang="bash" enclose="none">src</source> under <source lang="bash" enclose="none">/usr/local</source> is created <source lang="bash">
sudo mkdir /usr/local/src
</source>

* take over directories ownerships ('''replace''' below the terms ''userid'' and ''groupid'' with a real <source lang="bash" enclose="none">userid</source>): <source lang="bash">
sudo chown userid:groupid /usr/local/src</source>

* similarly, grant <source lang="bash" enclose="none">rwx</source> (read-write-execute) permissions for our ''userid'' and ''groupid'' onto the <source lang="bash" enclose="none">src</source> directory: <source lang="bash">
sudo chmod ug+rwx /usr/local/src</source>

=== Earlier Ubuntu versions ===

For [http://old-releases.ubuntu.com/releases/ earlier Ubuntu versions], '''watch out for dependency differences!''' Modify the dependency list given above as instructed below.

* for [http://releases.ubuntu.com/precise/ Ubuntu Precise Pangolin (12.04)], change the following dependencies:
** <source lang="bash" enclose="none">libpnglite-dev --> libpngwriter-dev</source>
** <source lang="bash" enclose="none">libtiff5-dev --> libtiff4-dev</source>

* for [http://old-releases.ubuntu.com/releases/maverick/ Ubuntu Maverick Meerkat (10.10)] or later, change the following dependencies:
** <source lang="bash" enclose="none">libpngwriter-dev --> libpngwriter0-dev</source>
** <source lang="bash" enclose="none">libcairo-dev --> libcairo2-dev</source>
** <source lang="bash" enclose="none">fftw3 --> libfftw3-3</source>
** <source lang="bash" enclose="none">fftw3-dev --> libfftw3-dev</source>

* for [http://old-releases.ubuntu.com/releases/lucid/ Ubuntu Lucid Lynx (10.04)] or later, also install: <source lang="bash">sudo apt-get install libhdf4-alt-dev libhdf4-0-alt</source>

* for [http://old-releases.ubuntu.com/releases/ earlier Ubuntu versions], also install: <source lang="bash"> sudo apt-get install libhdf4g-dev libhdf4g-run</source>

== Using pre-compiled dev Packages for PROJ.4, GEOS and GDAL ==

=== PROJ.4 ===

Install the <source lang="bash" enclose="none">dev</source> package (possibly without support for datumgrid):

<source lang="bash">
sudo apt-get install libproj-dev
</source>

* In the call to <source lang="bash" enclose="none">./configure</source> for [[#GRASS|GRASS]], replace <source lang="bash" enclose="none">--with-proj-share=/usr/local/share/proj/</source> by <source lang="bash" enclose="none">--with-proj-share=/usr/share/proj/</source>

=== GEOS ===

Install the <source lang="bash" enclose="none">dev</source> package:

<source lang="bash">
sudo apt-get install libgeos-dev
</source>

* In the call to <source lang="bash" enclose="none">./configure</source> for [[#GRASS|GRASS]], replace <source lang="bash" enclose="none">--with-geos=/usr/local/bin/geos-config</source> by <source lang="bash" enclose="none">--with-geos=/usr/bin/geos-config</source>

=== GDAL ===

Install the <source lang="bash" enclose="none">dev</source> package (possibly without support for datumgrid):

<source lang="bash">
sudo apt-get install libgdal-dev
</source>

* Install also the required extra packages (note the message: <source lang="bash" enclose="none">The following extra packages will be installed:</source>)
* Look out for packages to be removed by this operation -- this is most likely caused by incompatible package versions. Fix these problems in advance using commands like the following: <source lang="bash">
sudo apt-get install <package>=<required.version></source>

=== GRASS-GIS ===

[[Compile_and_Install_Ubuntu#GRASS_GIS|Jump to sub-section GRASS-GIS below]]

== Compile from source ==

=== PROJ4 ===

* within the directory <source lang="bash" enclose="none">/usr/local/src</source> (create it if it does not exist) checkout <source lang="bash" enclose="none">proj</source> from its Subversion repository: <source lang="bash">
svn co http://svn.osgeo.org/metacrs/proj/branches/4.8/proj/
</source>

* get [http://download.osgeo.org/proj/proj-datumgrid-1.5.zip '''proj-datumgrid-1.5.zip'''] from [http://trac.osgeo.org/proj proj' trac] and move it under <source lang="bash" enclose="none">proj/nad</source>
<ul><source lang="bash">
wget http://download.osgeo.org/proj/proj-datumgrid-1.5.zip
mv proj-datumgrid-1.5.zip /usr/local/src/proj/nad
cd /usr/local/src/proj/nad
</source>
</ul>

* decompress it <source lang="bash">
unzip proj-datumgrid-1.5.zip
</source>

* go back to the <source lang="bash" enclose="none">proj</source> directory <source lang="bash">
cd /usr/local/src/proj
</source>

* if required, clean previous configuration & compilation <source lang="bash">
make distclean
</source>

* simple configure, compile and install <source lang="bash">
./configure && make && sudo make install
</source>
<ul> or <source lang="bash">
./configure && make -j2 && sudo checkinstall
</source>
</ul>

* ensure that <source lang="bash" enclose="none">/usr/local/lib</source> is added to <source lang="bash" enclose="none">/etc/ld.so.conf</source> and afterwards run <source lang="bash">
sudo ldconfig
</source>

* finally, go back to the parent directory simply by instructing<source lang="bash">
cd ..
</source>

=== GEOS ===

* download '''geos-3.3.5.tar.bz2''' from [http://trac.osgeo.org/geos/ http://trac.osgeo.org/geos] using <source lang="bash" enclose="none">wget</source> <source lang="bash">
wget http://download.osgeo.org/geos/geos-3.3.5.tar.bz2
</source>

* move to the "source-code" directory and decompress
<ul><source lang="bash">
cd /usr/local/src/
bunzip2 geos-3.3.5.tar.bz2
tar xvf geos-3.3.5.tar
</source>
</ul>

* if required, clean previous configuration & compilation <source lang="bash">
make distclean
</source>

* move to geos directory <source lang="bash">
cd geos-3.3.5
</source>

* simple configure, compile and install <source lang="bash">
./configure && make && sudo make install
</source>
<ul> or <source lang="bash">
./configure && make -j2 && sudo checkinstall
</source>
</ul>

* do not forget to execute <source lang="bash">
sudo ldconfig
</source>

=== GDAL ===

'''Note''', GDAL must be compiled '''without''' GRASS support

* download the current stable version <source lang="bash">
svn checkout https://svn.osgeo.org/gdal/branches/1.9/gdal gdal_stable
</source>

* enter in the <source lang="bash" enclose="none">gdal_stable</source> directory <source lang="bash">
cd /usr/local/src/gdal_stable
</source>

* optionally, update the source code <source lang="bash">
svn up
</source>

* if required, clean previous configurations/compilations <source lang="bash">
make distclean
</source>

* a simple configuration without any parameters will detect and support various installed libraries <source lang="bash">
./configure
</source>

* skip to the ''compile and install'' step or check the following customised configuration example
<ul>
<source lang="bash">
CFLAGS="-g -Wall" LDFLAGS="-s" ./configure \
--with-png=internal \
--with-libtiff=internal \
--with-geotiff=internal \
--with-jpeg=internal \
--with-gif=internal \
--with-ecw=yes \
--with-expat=yes \
--with-sqlite3=yes \
--with-geos=yes \
--with-python \
--with-libz=internal \
--with-netcdf \
--with-sqlite \
--with-threads=yes \
--without-grass \
--without-ogdi \
--with-pg=/usr/bin/pg_config \
--with-xerces=yes
</source>
</ul>

* compile, install & ldconfig <source lang="bash">
make -j2 && sudo make install && sudo ldconfig
</source>
<ul> or <source lang="bash">
make -j2 && sudo checkinstall && sudo ldconfig
</source>
</ul>

=== GRASS GIS ===

<div class="boilerplate metadata" id="attention" style="-moz-border-radius:30px; border: 1px double #4da948; margin-bottom: 1em; padding: 0 .25em; background-color: #dcdcdc;">
'''Recommendation''' Before attempting to compile GRASS, read the <code>INSTALL</code> file, which is located in GRASS' source code root directory. Pay attention especially to section <code>(C)</code>, entitled <code>COMPILATION NOTES for 64bit platforms</code>.
</div>

''' Getting GRASS' source code '''

* get current state of the 6.4.x release branch version (stable) <source lang="bash">
svn co https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4 grass64_release
</source>

To download under development versions use

* for GRASS 6.5 (Note: ''GRASS version 6.5 is not intended for end-users! It exists for development purposes which should rather take place for GRASS 7.'') <source lang="bash">
svn checkout https://svn.osgeo.org/grass/grass/branches/develbranch_6 grass6_devel
</source>

* for GRASS 7 <source lang="bash">
svn checkout https://svn.osgeo.org/grass/grass/trunk grass_trunk
</source>

* for subsequent updates execute <source lang="bash">
svn up
</source>

''' Configure, Compile and Install'''

* if required, clean previous configuration & compilation (not needed the first time) <source lang="bash">
make distclean
</source>

* example configuration (which can/should be adjusted according to specific needs):
<ul>
<source lang="bash">
./configure \
--enable-largefile=yes \
--with-nls \
--with-cxx \
--with-proj-share=/usr/local/share/proj/ \
--with-geos=/usr/local/bin/geos-config \
--with-python=yes \
--with-wxwidgets \
--with-cairo \
--with-tcltk-includes="/usr/include/tcl8.5/" \
--with-opengl-libs=/usr/include/GL \
--with-motif \
--with-ffmpeg=yes --with-ffmpeg-includes="/usr/include/libavcodec /usr/include/libavformat /usr/include/libswscale" \
--with-freetype=yes --with-freetype-includes="/usr/include/freetype2/" \
--with-postgres=yes \
--with-postgresql=yes --with-postgres-includes="/usr/include/postgresql" \
--with-sqlite=yes \
--with-mysql=yes --with-mysql-includes="/usr/include/mysql" \
--with-odbc=yes</source>
</ul>

<ul>
'''Note''', the above configuration uses the <code>Proj4</code> and <code>GEOS</code> packages compiled from the source. In the case that pre-compiled versions from the repository are required, remove the above corresponding lines to use the "defaults", i.e. <source lang="bash">
--with-proj-share=/usr/share/proj \
--with-geos=/usr/bin/geos-config \
</source>
</ul>

* compile & install <source lang="bash">
make -j2 && sudo make install && sudo ldconfig
</source>

<ul> or <source lang="bash">
make -j2 && sudo checkinstall && sudo ldconfig
</source>
</ul>

=== GDAL-GRASS-Plugin ===

* get the plugin from [http://download.osgeo.org/gdal OSGeo's Download Server]: [http://download.osgeo.org/gdal/gdal-grass-1.4.3.tar.gz http://download.osgeo.org/gdal/gdal-grass-1.4.3.tar.gz] using <source lang="bash" enclose="none">wget</source> <source lang="bash">
wget http://download.osgeo.org/gdal/gdal-grass-1.4.3.tar.gz</source>

* create <source lang="bash" enclose="none">/etc/ld.so.conf.d/grass6.conf</source> or add in <source lang="bash" enclose="none">/etc/ld.so.conf</source> the GRASS library path, i.e. <source lang="bash" enclose="none">/usr/local/src/grass64_release/lib</source>
* optionally, clean previous configurations/compilations<source lang="bash">
make distclean</source>

* configure -- point to GRASS installation/binaries
<ul>
<source lang="bash"> ./configure \
--prefix=/usr/local \
--with-gdal=/usr/local/bin/gdal-config \
--with-grass=/geo/osgeo/src/grass64_release/dist.x86_64-unknown-linux-gnu/ \
--with-autoload="/usr/local/lib/gdalplugins/" \
--with-ld-shared="g++ -shared"</source>
</ul>
<ul>
* for GRASS 6.5, replace the respective line above, depending on where the source code in question is stored, with something like<source lang="bash" enclose="none"> --with-grass=/usr/local/grass-6.5.svn/</source>
* for GRASS 7, replace with <source lang="bash" enclose="none"> --with-grass=/usr/local/grass_trunk/</source>
</ul>
* compile & install using checkinstall<source lang="bash">
make -j2 && sudo checkinstall</source>

= Post compilation/installation control =

* For a recommended quick-check read the [http://grass.osgeo.org/wiki/Compile_and_install_GRASS_and_QGIS_with_GDAL/OGR_Plugin#Troubleshooting Troubleshooting] section at [http://grass.osgeo.org/wiki/Compile_and_install_GDAL-GRASS_plugin Compile_and_install_GDAL-GRASS_plugin]

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

* another common mistake is compiling a module against some GRASS version and then try to run it through another GRASS version. The solution is to recompile the affected module or, in case there are multiple GRASS installations, set up properly LD_LIBRARY_PATH paths.

= Removal of GRASS =

To get rid of a GRASS binaries installation, delete
* <source lang="bash" enclose="none">/usr/local/grass-6.4.0svn</source> (directory, binaries location)
* <source lang="bash" enclose="none">/usr/local/bin/grass64</source> (file)
* <source lang="bash" enclose="none">/usr/local/bin/gem64</source> (file)
* <source lang="bash" enclose="none">/home/username/.grassrc6</source> (file)

If wanted, delete also the complete source code:
* <source lang="bash" enclose="none">/usr/local/src/grass_64svn</source> (directory, source code location)

To remove <code>grass</code> (or any other package) which was installed by <source lang="bash" enclose="none">checkinstall</source>, use <source lang="bash" enclose="none">dpkg</source>, e.g.<source lang="bash">
sudo dpkg -r grass64 # package name defined at installation is important</source>

= Packaging of GRASS =

* See the {{src|debian/README.debian}} file in the GRASS source code for directions on rolling your own packages.

For details about the auto-nightly-builds and after-market supplied packages from UbuntuGIS, please refer to the [[Ubuntu Packaging]] wiki page.

== See also ==

* [[Ubuntu Packaging]]
* [[GRASS in Debian]]

[[Category: Compilation]]
[[Category: Installation]]
[[Category: Ubuntu]]
[[Category: FAQ]]

Compile and Install Ubuntu

2013-05-10T15:41:17Z

⚠️Huhabla: /* Current stable Ubuntu version */

GRASS SoC Ideas 2013

2013-05-02T11:39:38Z

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

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

__TOC__

== About ==

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

== Ideas ==

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

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

=== General ===

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

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

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

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

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

=== Symbology / Cartography ===

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

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

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

=== Imagery ===

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

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

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

=== Vector ===

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

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

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

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

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

Implementation goals:

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

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

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

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

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

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

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

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

* The GRASS GIS temporal framework will be utilized and extened with the spatio-temporal algebra
* The pygrass module interface will be used to call the raster mapcalc and vector overlay/buffer modules
* PLY will be used for lexical analysis and parser generation
* Spatio-temporal algebra will be equivalent for booth modules with about 60 internal variables and functions

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

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

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

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

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

'''Available mentors:'''

* Benjamin Ducke
* Sören Gebbert

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

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

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

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

See also these GRASS mailing list posts for further information:

'''Further information'''

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

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

GRASS and Paraview

2013-03-26T18:25:47Z

⚠️Huhabla: /* 2D/3D Raster/voxel export */

= 3D visualization of GRASS data with Paraview=

Download Paraview at http://www.paraview.org (available for Linux, MacOSX and MS-Windows) ([http://www.paraview.org/paraview/project/imagegallery.php screenshot gallery])

== 2D/3D Raster/voxel export ==

GRASS GIS is one of the few GIS with volume data support. Here data are stored as a 3D raster with a unit volume called a voxel (volume pixel). [[Voxel]]s are designed to support for example representations of trivariate continuous fields. The latest version of GRASS7 supports space time voxel cubes that have time as the third dimension.

* 2D raster maps: {{cmd|r.out.vtk}}
* 3D raster (voxel) maps: {{cmd|r3.out.vtk}}
* 3D raster (voxel) and space time voxel maps as netCDF: r3.out.netcdf

== 2D/3D Vector export ==

* 2D/3D vector maps: {{cmd|v.out.vtk}}

== Visualization ==

Start Paraview, load VTK data, and choose the correct readers : for example "Legacy VTK file"....it is fairly intuitive to use.
In the Properties section click the Apply button, next in the Display section set "Surface" in Representation menu, and set the name of the file that you had load on the Color menu. Then with Edit menu you can set the color scale.
In Paraview you have many filtes to process the data. A useful filter is "Cell data to point data". In the "Filters" drop-down menu you can find it in the "Alphabetical" list.
''(don't hesitate to expand this part)''

paraview --data=/tmp/threelayer.vtk

[[Image:LausanneDemoDataset3dParaview_4.png|thumb|center|400px|3D groundwater flow]]

[[Image:LausanneDemoDataset3dParaview_10.png|thumb|center|400px|3D groundwater flow]]

== RGB visualization ==

Data export with {{cmd|r.out.vtk}}:
r.out.vtk input=dsm_s_michele elevation=dsm_s_michele \
rgbmaps=ofd_s_michele.red,ofd_s_michele.green,ofd_s_michele.blue \
out=s_michele_color.vtk

Load into Paraview:
paraview --data=s_michele_color.vtk

* In Paraview, click "Apply"
* Select the "Display" tab and choose "Color by" to switch from input scalars to rgb scalars
* Disable the "Map Scalars" check button in the display tab to avoid the use of a lookup table

[[Image:Paraview fondazione mach 3D.png|thumb|center|400px|Fondazione Mach - S. Michele (Italy) area shown in ParaView]]

== Shown as stereo anaglyphs ==

paraview --stereo --data=s_michele_color.vtk

* In Paraview, click "Apply"
* Select the "Display" tab and choose "Color by" to switch from input scalars to rgb scalars
* Disable the "Map Scalars" check button in the display tab to avoid the use of a lookup table

[[Image:Paraview fondazione mach ortho 3D.png|thumb|center|400px|Fondazione Mach - S. Michele (Italy) area shown in ParaView's stereo mode]]

== Creating Stereo anaglyphs ==

* see [[Stereo anaglyphs]]

[[Category: Visualization]]
[[Category: Documentation]]
[[Category: FAQ]]
[[Category: Linking to other languages]]
[[Category: Tutorial]]
[[Category: 3D]]
[[Category: VTK]]

GRASS and Paraview

2013-03-26T18:19:52Z

⚠️Huhabla: /* See also */

= 3D visualization of GRASS data with Paraview=

Download Paraview at http://www.paraview.org (available for Linux, MacOSX and MS-Windows) ([http://www.paraview.org/paraview/project/imagegallery.php screenshot gallery])

== 2D/3D Raster/voxel export ==

GRASS GIS is one of the few GIS with volume data support. Here data are stored as a 3D raster with a unit volume called a voxel (volume pixel). [[Voxel]]s are designed to support for example representations of trivariate continuous fields.

* 2D raster maps: {{cmd|r.out.vtk}}
* 3D raster (voxel) maps: {{cmd|r3.out.vtk}}

== 2D/3D Vector export ==

* 2D/3D vector maps: {{cmd|v.out.vtk}}

== Visualization ==

Start Paraview, load VTK data, and choose the correct readers : for example "Legacy VTK file"....it is fairly intuitive to use.
In the Properties section click the Apply button, next in the Display section set "Surface" in Representation menu, and set the name of the file that you had load on the Color menu. Then with Edit menu you can set the color scale.
In Paraview you have many filtes to process the data. A useful filter is "Cell data to point data". In the "Filters" drop-down menu you can find it in the "Alphabetical" list.
''(don't hesitate to expand this part)''

paraview --data=/tmp/threelayer.vtk

[[Image:LausanneDemoDataset3dParaview_4.png|thumb|center|400px|3D groundwater flow]]

[[Image:LausanneDemoDataset3dParaview_10.png|thumb|center|400px|3D groundwater flow]]

== RGB visualization ==

Data export with {{cmd|r.out.vtk}}:
r.out.vtk input=dsm_s_michele elevation=dsm_s_michele \
rgbmaps=ofd_s_michele.red,ofd_s_michele.green,ofd_s_michele.blue \
out=s_michele_color.vtk

Load into Paraview:
paraview --data=s_michele_color.vtk

* In Paraview, click "Apply"
* Select the "Display" tab and choose "Color by" to switch from input scalars to rgb scalars
* Disable the "Map Scalars" check button in the display tab to avoid the use of a lookup table

[[Image:Paraview fondazione mach 3D.png|thumb|center|400px|Fondazione Mach - S. Michele (Italy) area shown in ParaView]]

== Shown as stereo anaglyphs ==

paraview --stereo --data=s_michele_color.vtk

* In Paraview, click "Apply"
* Select the "Display" tab and choose "Color by" to switch from input scalars to rgb scalars
* Disable the "Map Scalars" check button in the display tab to avoid the use of a lookup table

[[Image:Paraview fondazione mach ortho 3D.png|thumb|center|400px|Fondazione Mach - S. Michele (Italy) area shown in ParaView's stereo mode]]

== Creating Stereo anaglyphs ==

* see [[Stereo anaglyphs]]

[[Category: Visualization]]
[[Category: Documentation]]
[[Category: FAQ]]
[[Category: Linking to other languages]]
[[Category: Tutorial]]
[[Category: 3D]]
[[Category: VTK]]

GRASS SoC Ideas 2013

2013-02-27T10:35:56Z

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

== About ==

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code 2013]. Here we will list project ideas and and other information related to the GRASS GSoC projects.

== Ideas ==

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

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

=== Symbology / Cartography ===

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

* Expand [[IconSymbols|symbology]]
: ''HB: note that SoC only accepts coding projects, not graphics design or documentation projects. Adding svg/eps support to a d.* module and ps.map would be quite helpful. See the {{Cmd|d.graph}} help page and {{Cmd|ps.map}}'s "eps" and "vpoints" instructions.''

* Rework the complete set of thematic cartography tools such as {{Cmd|d.vect.thematic}} and {{Cmd|d.thematic.area}} and the related classification routines

=== Imagery ===

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

* Implement hierarchical classification tools (e.g. being able to create a large class "forest", with subclasses of different types of forests)

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

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

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

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

Implementation goals:

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

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

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

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

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

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

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

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

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

GRASS SoC Ideas 2013

2013-02-27T10:33:34Z

⚠️Huhabla: /* Temporal GIS Algebra */

== About ==

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code 2013]. Here we will list project ideas and and other information related to the GRASS GSoC projects.

== Ideas ==

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

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

=== Symbology / Cartography ===

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

* Expand [[IconSymbols|symbology]]
: ''HB: note that SoC only accepts coding projects, not graphics design or documentation projects. Adding svg/eps support to a d.* module and ps.map would be quite helpful. See the {{Cmd|d.graph}} help page and {{Cmd|ps.map}}'s "eps" and "vpoints" instructions.''

* Rework the complete set of thematic cartography tools such as {{Cmd|d.vect.thematic}} and {{Cmd|d.thematic.area}} and the related classification routines

=== Imagery ===

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

* Implement hierarchical classification tools (e.g. being able to create a large class "forest", with subclasses of different types of forests)

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

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

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

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

Implementation goals:

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

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

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

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

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

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

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

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

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

GRASS SoC Ideas 2013

2013-02-27T10:10:16Z

⚠️Huhabla: /* Temporal GIS Algebra */

== About ==

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code 2013]. Here we will list project ideas and and other information related to the GRASS GSoC projects.

== Ideas ==

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

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

=== Symbology / Cartography ===

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

* Expand [[IconSymbols|symbology]]
: ''HB: note that SoC only accepts coding projects, not graphics design or documentation projects. Adding svg/eps support to a d.* module and ps.map would be quite helpful. See the {{Cmd|d.graph}} help page and {{Cmd|ps.map}}'s "eps" and "vpoints" instructions.''

* Rework the complete set of thematic cartography tools such as {{Cmd|d.vect.thematic}} and {{Cmd|d.thematic.area}} and the related classification routines

=== Imagery ===

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

* Implement hierarchical classification tools (e.g. being able to create a large class "forest", with subclasses of different types of forests)

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

=== Temporal GIS Algebra ===

We (Soeren Gebbert and Thomas Leppelt) would like to implement a spatio-temporal map algebra for raster and vector data in GRASS7.

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

Implementation goals:

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

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

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

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

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

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

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

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

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

GRASS SoC Ideas 2013

2013-02-27T09:59:45Z

⚠️Huhabla: /* Temporal GIS Algebra */

== About ==

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code 2013]. Here we will list project ideas and and other information related to the GRASS GSoC projects.

== Ideas ==

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

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

=== Symbology / Cartography ===

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

* Expand [[IconSymbols|symbology]]
: ''HB: note that SoC only accepts coding projects, not graphics design or documentation projects. Adding svg/eps support to a d.* module and ps.map would be quite helpful. See the {{Cmd|d.graph}} help page and {{Cmd|ps.map}}'s "eps" and "vpoints" instructions.''

* Rework the complete set of thematic cartography tools such as {{Cmd|d.vect.thematic}} and {{Cmd|d.thematic.area}} and the related classification routines

=== Imagery ===

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

* Implement hierarchical classification tools (e.g. being able to create a large class "forest", with subclasses of different types of forests)

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

=== Temporal GIS Algebra ===

We (Soeren Gebbert and Thomas Leppelt) would like to implement a spatio-temporal map algebra for raster and vector data in GRASS7.

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

Implementation goals:

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

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

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

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

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

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

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

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

GRASS SoC Ideas 2013

2013-02-27T09:56:38Z

⚠️Huhabla: /* Temporal GIS Algebra */

== About ==

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code 2013]. Here we will list project ideas and and other information related to the GRASS GSoC projects.

== Ideas ==

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

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

=== Symbology / Cartography ===

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

* Expand [[IconSymbols|symbology]]
: ''HB: note that SoC only accepts coding projects, not graphics design or documentation projects. Adding svg/eps support to a d.* module and ps.map would be quite helpful. See the {{Cmd|d.graph}} help page and {{Cmd|ps.map}}'s "eps" and "vpoints" instructions.''

* Rework the complete set of thematic cartography tools such as {{Cmd|d.vect.thematic}} and {{Cmd|d.thematic.area}} and the related classification routines

=== Imagery ===

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

* Implement hierarchical classification tools (e.g. being able to create a large class "forest", with subclasses of different types of forests)

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

=== Temporal GIS Algebra ===

We (Soeren Gebbert and Thomas Leppelt) would like to implement a spatio-temporal map algebra for raster and vector data in GRASS7.

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

Implementation goals:

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

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

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

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

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

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

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

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

GRASS SoC Ideas 2013

2013-02-27T09:52:43Z

⚠️Huhabla: /* Temporal GIS Algebra */

== About ==

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code 2013]. Here we will list project ideas and and other information related to the GRASS GSoC projects.

== Ideas ==

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

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

=== Symbology / Cartography ===

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

* Expand [[IconSymbols|symbology]]
: ''HB: note that SoC only accepts coding projects, not graphics design or documentation projects. Adding svg/eps support to a d.* module and ps.map would be quite helpful. See the {{Cmd|d.graph}} help page and {{Cmd|ps.map}}'s "eps" and "vpoints" instructions.''

* Rework the complete set of thematic cartography tools such as {{Cmd|d.vect.thematic}} and {{Cmd|d.thematic.area}} and the related classification routines

=== Imagery ===

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

* Implement hierarchical classification tools (e.g. being able to create a large class "forest", with subclasses of different types of forests)

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

=== Temporal GIS Algebra ===

We (Soeren Gebbert and Thomas Leppelt) want to implement a spatio-temporal map algebra for raster and vector data.

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

Implementation goals:

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

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

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

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

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

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

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

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

GRASS SoC Ideas 2013

2013-02-26T21:41:59Z

⚠️Huhabla:

== About ==

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code 2013]. Here we will list project ideas and and other information related to the GRASS GSoC projects.

== Ideas ==

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

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

=== Symbology / Cartography ===

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

* Expand [[IconSymbols|symbology]]
: ''HB: note that SoC only accepts coding projects, not graphics design or documentation projects. Adding svg/eps support to a d.* module and ps.map would be quite helpful. See the {{Cmd|d.graph}} help page and {{Cmd|ps.map}}'s "eps" and "vpoints" instructions.''

* Rework the complete set of thematic cartography tools such as {{Cmd|d.vect.thematic}} and {{Cmd|d.thematic.area}} and the related classification routines

=== Imagery ===

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

* Implement hierarchical classification tools (e.g. being able to create a large class "forest", with subclasses of different types of forests)

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

=== Temporal GIS Algebra ===

We (Soeren Gebbert and Thomas Leppelt) want to implement a spatio-temporal map algebra for raster and vector data

* Spatio-temporal vector algebra module
** The algebra will be based on boolean vector operations from v.overlay (and, or, xor, not), v.buffer (buff_point, buff_line, buff_area), temporal variables (day of year, weekday, datum, time, ...) and temporal topology relations (predecessor, successor, follows, equals, ...)
** We will use PLY for lexical analysis and parser generation
** The resulting module will be able to process space time vector datasets using expressions like:

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

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

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

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

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

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

GRASS Community Sprint Genova 2013

2013-01-30T14:56:14Z

⚠️Huhabla:

The GRASS GIS team will organize a '''GRASS Developer and Power User Meeting, aka 'GRASS Community Sprint'''' from '''2-7 Feb, 2013'''. The sprint is at the same time of the [http://geomorfolab.arch.unige.it/genova2013/index.php?lang=en XIV Meeting degli Utenti Italiani Grass e Gfoss], 6-9 Feb 2013, University of Genova, Dipartimento di Scienze per l'Architettura della Scuola Politecnica, [http://en.wikipedia.org/wiki/Genoa Genova], [http://en.wikipedia.org/wiki/Italy Italy].
[[Image:community_sprint_genova2013.png|center|640px|thumb|Thanks to '''Sonia Bertolone''' for the logo]]

<center>
Our logo — In the left of the GRASS Logo the [http://en.wikipedia.org/wiki/Lighthouse_of_Genoa Lanterna], in the right the [http://en.wikipedia.org/wiki/Mortar_and_pestle ''murtà''] to prepare [http://en.wikipedia.org/wiki/Pesto ''pestu'']

</center>

== Purpose ==

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

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

== Sponsors ==

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

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

For questions, please contact [[User:Lucadelu|Luca Delucchi]] <tt><lucadeluge at gmail.com></tt>. Any surplus at the end of the event will be turned over to the GRASS GIS project.

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

=== Thanks to our sponsors ===

* Anonymous donor - 100 euro
* [http://www.r3-gis.com/ R3 GIS], Merano, Italy - 300 euro
* [http://www.intevation.de Intevation Gmbh], Osnabrück, Germany - 100 euro
* Flavio Rigolon - 30 euro
* Nobusuke Iwasaki - 200 euro

== Timing ==

'''When''': 2-7 Feb, 2013

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

'''Duration''': 6 days

== Venue ==

For the 2nd and 3rd of February we are hosted by the [http://www.alid.it ALID association] at Circolo Zenzero in [http://osm.org/go/xX0m6qo~B-- Via Torti 35, Genova] (in Italy universities are closed during weekends).

From 4th to 7th at University of Genova, Dipartimento di Scienze per l'Architettura della Scuola Politecnica, Genova, Italy.

'''[http://geomorfolab.arch.unige.it/ Geomorfolab]''',
Dipartimento di Scienze per l'Architettura,
Scuola Politecnica - Università degli Studi di Genova,
[http://osm.org/go/xX0ml6cj7-- Stradone S. Agostino 37, 16128 Genova]

Rooms: TBD

== Accommodation and Costs ==

* Bed and breakfast (few rooms) - close to venue (please contact [[User:Lucadelu|Luca Delucchi]] <tt><lucadeluge at gmail.com></tt>)
* New youth hostel, http://www.manenahostel.it/ - close to venue (please contact [[User:Lucadelu|Luca Delucchi]] <tt><lucadeluge at gmail.com></tt>)
* List of [http://geomorfolab.arch.unige.it/genova2013/index.php?option=com_content&view=article&id=42&Itemid=18 Site of XIV Meeting degli utenti italiani GRASS e GFOSS]

== Weather and Common Item Prices ==

== Agenda ==

=== Timeline ===

==== Saturday, 2 Feb ====
* Kick-off in the [http://www.alid.it ALID association] at Circolo Zenzero in [http://osm.org/go/xX0m6qo~B-- Via Torti 35, Genova]
* Participants presentation
* Dinner: at Circolo Zenzero

==== Sunday, 3 Feb ====
* 9:00-evening
* Meeting again in the at Circolo Zenzero

List of topics:
* TBD
* Dinner: at Circolo Zenzero

==== Monday, 4 Feb ====
* 9:00-evening
* Meeting at University of Genova, Dipartimento di Scienze per l'Architettura della Scuola Politecnica, Genova, Italy at the '''[http://geomorfolab.arch.unige.it/ Geomorfolab]''', [http://osm.org/go/xX0ml6cj7-- Stradone S. Agostino 37, 16128 Genova]

List of topics:
* TBD

==== Tuesday, 5 Feb ====
* 9:00-evening
* Meeting again at University of Genova, Geomorfolab

List of topics:
* TBD

==== Wednesday, 6 Feb ====
* 9:00-evening
* Meeting again at University of Genova, Geomorfolab

List of topics:
* TBD
* Group photo!!
* Prepare press release

==== Thursday, 7 Feb ====
* 9:00-evening
* Meeting again at University of Genova, Geomorfolab

List of topics:
* TBD
* Prepare short presentations for Friday at the Italian GFOSS meeting
* Finish and publish press release

Closing of community sprint

==== Friday, 8 Feb ====
* Two hours of time for '''presenting Community Sprint results''' at Italian GFOSS meeting ([http://geomorfolab.arch.unige.it/genova2013/index.php?option=com_content&view=article&id=29&Itemid=21&lang=en venue])

== Participation ==

=== In person ===

{|class="wikitable sortable" border="2" cellspacing="0" cellpadding="4" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse; background-color:#edf9c7; font-size:95%; empty-cells:show;"
!width=50px|'''Number'''
!width=130px|'''Participant '''
!width=100px|'''Country'''
!width=100px|'''Arrival'''
!width=100px|'''Departure'''
!'''Topic'''
!width=75px|'''T-Shirt'''
!'''Notes'''
|-
|1
|[[User:Lucadelu|Luca Delucchi]]
|Italy
| Feb 2
| Feb 10
|
| L
|
|-
|2
|[[User:Neteler|Markus Neteler]]
|Italy
|
|
|
| M + S
|
|-
|3
|[[User:Madi|Margherita Di Leo]]
|Italy
| Feb 1
| Feb 3
|
| L
|
|-
|4
|[[User:pcav|Paolo Cavallini]]
|Italy
| Feb 6
| Feb 9
|
| L
|
|-
|5
|[[User:lcasagrande|Luca Casagrande]]
|Italy
|
|
| GRASS Tutorial with Open Data from Italy
| L
|
|-
|6
|[[User:Annakrat|Anna Kratochvilova]]
|Czech Republic
| Feb 1
| Feb 8
|
| M
|
|-
|7
|Vaclav Petras
|Czech Republic
| Feb 1
| Feb 8
|
| M
|
|-
|8
|[[User:pietro|Pietro Zambelli]]
|Italy
| Feb 2
| Feb 9
| Python and Pygrass workshops
| M
|
|-
|9
|<strike>[[User:Landa|Martin Landa]]</strike>
|Czech Republic
| Feb 2
| Feb 10
| [[wxGUI]], vector architecture, GRASS 7 development
| L
| Probably unable to come :-(
|-
|10
|[[User:Maxi|Massimiliano Cannata]]
|Italy
|
|
|
| XL
|
|-
|11
|[[User:NikosA|Nikos Alexandris]]
|Greece
| Feb 1
| Feb 10
| GRASS-wiki, (re-)working on the idea for a practical & visual guide to GRASS-GIS, testing all landsat related (core + addons) modules
| M
| Will be there with Nikos Ves!
|-
|12
|[[User:AnneGhisla|Anne Ghisla]]
|Italy
| Feb 5
| Feb 8
| fix v.krige, examine i.atcorr problems with RapidEye
| M
|
|-
|13
|[[User:vesnikos|Ves Nikos]]
|Greece
| Feb 1
| Feb 10
|
| L
| Will be there with Nikos Alexandris
|-
|14
|[[User:ychemin|Yann Chemin]]
|Sri Lanka
| Feb 3
| Feb 10
| Remote Sensing, raster/image processing, will help with Landsat and i.atcorr, i.ortho.photo Block/Bundle.
| XXXLL
| 100% confirmed trip
|-
|15
|[[User:mmetz|Markus Metz]]
|Italy
| Feb 2
| Feb 8
| GRASS 7 vector processing, hydrology, orthorectification.
| L
|
|-
|16
|[[User:Annazanchetta|Anna Zanchetta]]
|Italy
| Feb 5?
|
|
| S
| Hopefully will be there on the 5th
|-
|-
|17
|[[User:robertomarzocchi|Roberto Marzocchi]]
|Italy
| Feb 4?
|
| adjust the G-Pastro modules
| M
|
|-
|18
|Stefano 'chiui' Cavallari
|Italy
| Feb 5
| Feb 8
| random Python stuff
| M
|
|-
|}

=== Via IRC chat or hangout===

: [irc://freenode/grass #grass] on Freenode

For details, see [[IRC]]

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

* [[User:Landa|Martin Landa]], [http://www.timeanddate.com/worldclock/city.html?n=204 timezone]
* [[User:huhabla|Soeren Gebbert]], [http://www.timeanddate.com/worldclock/city.html?n=971 timezone]

=== Collaborative document scratching ===

== Individual Preparation ==

* Bring your own computer
* Bring [http://en.wikipedia.org/wiki/Mains_electricity_by_country your power connector adapter] if needed ([http://en.wikipedia.org/wiki/File:L_plug.jpg Italy])
* Install subversion and the compiler tools, and come with a working GRASS development environment if possible.

== Photos ==

Also during the event :)

== FAQ ==

* '''How was it last time?'''
** Very cool, see [[GRASS Community Sprint Prague 2012]]!

* '''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, however, we can do some presentations of current working GRASS implementations and new upcoming features to spread the idea of Open Source GIS software.

* '''Is the GRASS Community Sprint for developers only?'''
** ''Not at all!'' 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:Lucadelu|Luca Delucchi]] <tt><lucadeluge at gmail dot com></tt> or [[User:Neteler|Markus Neteler]]

[[Category: Workshops]]

Toolboxes

2012-06-07T11:35:47Z

⚠️Huhabla: /* New toolbox approach discussed at the GRASS Community Code Sprint in Prag 2012 */

=== New toolbox approach discussed at the GRASS Community Code Sprint 2012 ===

At the community sprint in Prague 2012 the toolbox approach with different repositories as well as the approach using "--with-toolbox/--without-toolbox" configure statements at compile time have been discussed. The major drawback of these solutions is the their complexity and the problem of cross dependencies between modules.

A new approach has been suggested using XML files to describe toolboxes and special directory structure to hide unneeded modules from the user.

The idea is to have a binary directory containing only modules that are listed in a XML file that defines what core modules should be available and what toolboxes should be used. The XML file will be used by the GUI to create menu listings for the selected modules. All modules that are deactivated in the XML file will be held in a directory that is not available in the users binary path, but in the binary search path of modules. Hence unneeded modules are invisible at the command line and in the GUI, but still available for modules that might call other modules.

New toolboxes and core modules can be simply added to the search path and the GUI by editing the XML definition and calling g.extension. The module g.extension will simply links/copy the hidden modules into the binary directory that is visible by the user or move deselected modules in the hidden directory. The GUI will always analyzes the XML toolbox configuration file for menu generation.

The configuration XML file will include a list of core modules for general, raster, image, voxel and vector processing as well as the definition of toolboxes. Toolboxes are defined by their type (raster, vector, ...) a short description and a list of modules. Modules can be defined in several different toolboxes.

The GRASS development team should provide several pre-defined XML toolbox configuration files as for hydrological modeling, vector processing, terrain modeling, image analysis, ..., and WPS server.

Using this approach the repository structure must not be changed. The build system has to be modified to use the XML toolbox file to decide where to copy the binary modules and scripts. g.extension has to be extended to link/copy selected modules in the users binary search path and to remove modules from them. GRASS will be build as usual.

=== Original approach ===

* See [http://lists.osgeo.org/pipermail/grass-dev/2010-April/050210.html original post by Jarosław Jasiewicz]

* Discussion about the suitability of the proposed change on the [[Talk:GRASS_repository_layout_proposal|talk]] side of this wiki page; discussion of the possible method on this side of the page.

<pre>
Hi all!

That rather radical ideas I present here are rather for future, at least for GRASS 8,
but I'd like present it now for long-term reflection.

Probably all notice that for over two years there is big increase in add-on repository
(including me). There are modules of different quality: from fully GRASS toolsets,
to shell or python scripts, from actively developed tools to abandoned,
from all-purpose tools to very specialized etc. I also think that that activity
will be grown due to substitute shell script by python

Similar situation is in main GRASS branch: there are modules for all like conversion tools,
interpolation methods, georeferencing etc, and very specialized modules for very limited
group of users (like wild fire), there are also some modules out of date.

I'm not enthusiastic about moving new modules into main branch. Almost every module has
different coding style and it will lasting in future that GRASS would be difficult to maintain.
On the other hand some people complains that some interesting modules are only available as
add-ons (I assume for some reasons they cannot install it)

So my suggestion is to rearrange future GRASS form two layers (main branch/add-on) into
three layers architecture:

1) GRASS core layer: much limited limited than now, only GIS environment and basic,
all-puropse tools, slow changes, great stability
2) GRASS toolset layer: oficcial GRASS thematic tools and toolsets (like terrain analysis,
hydrological analysis, photo-interpretation, landscape analysis etc,) every toolset with its
maintainer, rapid development, new ready to use tools after quality control may appear here,
also some of current main branch tool shall be moved to that layer
3) GRASS community layer: everything else like experimental, actively development new tools,
that what do not pass quality control, simple scripts, etc....

What benefits:
for developers and contributors: much clear situation and better publication path.
Toolset layer should be much more open for new tools than current GRASS main branch

for users: faster access to new tools.
There is no doubt that new tools are faster developed (less risk) than GRASS core
Binaries with toolsets could be maintained as separate apt/urpmi/pacman/yum/exe etc packages,
so it may appear in linux repository separetly form GRASS core.

There is only loose ideas. Most of them are of course taken from R (core/toolsets/rest of packages;
separate core and package development) but I think it is worth of some discuss ...

regards
Jarek
</pre>
__TOC__
== Repository layout ==
=== Current repository layout ===

<pre>
- grass
|- trunk
|- raster/
|- vector/
|- ...

- grass-addons
|- raster/
|- vector/
|- ...
</pre>

=== Proposed repository layout ===

<pre>
- grass
|- trunk
|- raster/
|- vector/
|- ...

- grass-tools
|- trunk
|- raster/
|- vector/
|- ...

- grass-addons
|- raster/
|- vector/
|- ...
</pre>

== Proposed toolboxes ==

'''Toolbox''' is a topic-based set of modules used for solving common GIS analysis, like hydrology, networking, LRS, etc.

=== Managing toolboxes ===

{{cmd|g.extension|version=70}} is designed to manage locally installed GRASS [[Addons]]. It allows to install single addons modules and also toolboxes (flag <code>-t</code>). Note that toolbox support is '''experimental'''.

* list available toolboxes

g.extension -tl

<pre>
List of available extensions (toolboxes):
Hydrology (HY)
* r.stream.basins
* r.stream.channel
* r.stream.distance
* r.stream.extract
* r.stream.order
* r.stream.segment
* r.stream.slope
* r.stream.snap
* r.stream.stats
...
</pre>

* list available modules from [[Addons]]

g.extension -l

<pre>
List of available extensions (modules):
...
r.stream.slope
...
</pre>

* install new toolbox ("Hydrology")

g.extension -t extension=HY

* install single module from "Hydrology" toolbox

g.extension extension=r.stream.slope

Module {{cmd|g.extension|version=70}} also allows to list installed extensions

* toolboxes

g.extension -ta

<pre>
List of installed extensions (toolboxes):
HY
</pre>

* or modules

g.extension -a

<pre>
List of installed extensions (modules):
r.stream.basins
r.stream.channel
r.stream.distance
r.stream.extract
r.stream.order
r.stream.segment
r.stream.slope
r.stream.snap
r.stream.stats
</pre>

* remove locally installed toolbox

g.extension -ft extension=HY operation=remove

* remove single module

g.extension -f extension=r.stream.slope operation=remove

=== List of toolboxes ===

{| class="wikitable sortable"
|'''Toolbox name''' || '''Toolbox code''' || '''Description'''||'''Correlate toolbox'''
|-
| ''3D Raster''
| R3
| All `r3.*` modules
|
|-
| ''3D Visualization''
| V3
| {{cmd|nviz_cmd|version=70}}
|
|-
| ''Atmospheric tools''
| AT
| Subset of image processing tool
|
|-
| ''Cartography''
| CA
| {{cmd|ps.map|version=70}}, {{AddonCmd|ps.output}}
|
|-
| ''Database''
| DB
| All `db.*` modules
| ''Vector analysis''
|-
| ''Geostatistcal''
| GS
| {{cmd|v.krige|version=70}} maybe other
|
|-
| ''GUI''
| GI
| [[wxGUI]]
|
|-
| ''Hydrology''
| HY
| {{cmd|r.watershed|version=70}}, {{cmd|r.terraflow|version=70}}, `r.stream.*` modules in addons, maybe other, r.flow, r.sim.water, r.sim.sediment
| ''Raster analysis''
|-
| ''Image Processing''
| IM
| All `i.*` modules, selected r.* modules
|
|-
| ''Interoperability tools''
| IO
| All the various import/export modules except for GDAL/OGR
| ''Raster analysis'', ''Vector analysis'', ''Image Processing'', ''Database''
|-
| ''Landscape analysis''
| LA
| All `r.li.*` modules, maybe other
| ''Raster analysis''
|-
| ''Lidar analysis''
| LI
| All `v.lidar.*` modules, {{cmd|v.surf.bspline|version=70}}, r.in.xyz
|
|-
| ''Linear Reference Systems''
| LS
| All `v.lrs.*` modules
| ''Vector analysis''
|-
| ''Network analysis''
| NA
| All `v.net.*` modules, maybe other
| ''Vector analysis''
|-
| ''Raster analysis''
| RA
| A lot of basic `r.*` modules (like {{cmd|r.buffer,|version=70}} {{cmd|r.reclass|version=70}}, {{cmd|r.fillnull|version=70}}...)
|
|-
| ''Terrain analysis''
| TA
| Different kind of analysis: soil ({{cmd|r.sun,|version=70}}), terrain ({{cmd|r.slope.aspect|version=70}}, {{cmd|r.los|version=70}}), geomorphometry ({{cmd|r.param.scale|version=70}})
| ''Raster analysis''
|-
| ''Vector analysis''
| VA
| A lot of basic `v.*` modules (like {{cmd|v.buffer|version=70}}, {{cmd|v.centroid|version=70}}, {{cmd|v.overlay|version=70}}...)
| ''Database''
|}

== List of modules (trunk) ==

=== Display ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|d.barscale|version=70}} || ? ||
|-
| {{cmd|d.colorlist|version=70}} || ? ||
|-
| {{cmd|d.colortable|version=70}} || ? ||
|-
| {{cmd|d.correlate|version=70}} || ? ||
|-
| {{cmd|d.erase|version=70}} || ? ||
|-
| {{cmd|d.font|version=70}} || ? ||
|-
| {{cmd|d.fontlist|version=70}} || ? ||
|-
| {{cmd|d.geodesic|version=70}} || ? ||
|-
| {{cmd|d.graph|version=70}} || ? ||
|-
| {{cmd|d.grid|version=70}} || ? ||
|-
| {{cmd|d.his|version=70}} || ? ||
|-
| {{cmd|d.histogram|version=70}} || ? ||
|-
| {{cmd|d.info|version=70}} || ? ||
|-
| {{cmd|d.labels|version=70}} || ? ||
|-
| {{cmd|d.legend|version=70}} || ? ||
|-
| {{cmd|d.linegraph|version=70}} || ? ||
|-
| {{cmd|d.nviz|version=70}} || ? ||
|-
| {{cmd|d.path|version=70}} || ? ||
|-
| {{cmd|d.polar|version=70}} || ? ||
|-
| {{cmd|d.profile|version=70}} || ? ||
|-
| {{cmd|d.rast|version=70}} || ? ||
|-
| {{cmd|d.rast.arrow|version=70}} || ? ||
|-
| {{cmd|d.rast.edit|version=70}} || ? ||
|-
| {{cmd|d.rast.leg|version=70}} || ? ||
|-
| {{cmd|d.rast.num|version=70}} || ? ||
|-
| {{cmd|d.rgb|version=70}} || ? ||
|-
| {{cmd|d.rhumbline|version=70}} || ? ||
|-
| {{cmd|d.shadedmap|version=70}} || ? ||
|-
| {{cmd|d.text|version=70}} || ? ||
|-
| {{cmd|d.thematic.area|version=70}} || ? ||
|-
| {{cmd|d.title|version=70}} || ? ||
|-
| {{cmd|d.vect|version=70}} || ? ||
|-
| {{cmd|d.vect.chart|version=70}} || ? ||
|-
| {{cmd|d.vect.thematic|version=70}} || ? ||
|-
| {{cmd|d.where|version=70}} || ? ||
|-
|}

=== Database ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|db.columns|version=70}} || ? ||
|-
| {{cmd|db.connect|version=70}} || ? ||
|-
| {{cmd|db.copy|version=70}} || ? ||
|-
| {{cmd|db.createdb|version=70}} || ? ||
|-
| {{cmd|db.databases|version=70}} || ? ||
|-
| {{cmd|db.describe|version=70}} || ? ||
|-
| {{cmd|db.drivers|version=70}} || ? ||
|-
| {{cmd|db.dropcolumn|version=70}} || ? ||
|-
| {{cmd|db.dropdb|version=70}} || ? ||
|-
| {{cmd|db.droptable|version=70}} || ? ||
|-
| {{cmd|db.droptable|version=70}} || ? ||
|-
| {{cmd|db.execute|version=70}} || ? ||
|-
| {{cmd|db.in.ogr|version=70}} || ? ||
|-
| {{cmd|db.login|version=70}} || ? ||
|-
| {{cmd|db.out.ogr|version=70}} || ? ||
|-
| {{cmd|db.select|version=70}} || ? ||
|-
| {{cmd|db.tables|version=70}} || ? ||
|-
| {{cmd|db.test|version=70}} || ? ||
|-
|}

=== General ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|g.access|version=70}} || C ||
|-
| {{cmd|g.cairocomp|version=70}} || C ||
|-
| {{cmd|g.copy|version=70}} || C ||
|-
| {{cmd|g.dirseps|version=70}} || C ||
|-
| {{cmd|g.extension|version=70}} || C ||
|-
| {{cmd|g.filename|version=70}} || C ||
|-
| {{cmd|g.findetc|version=70}} || C ||
|-
| {{cmd|g.findfile|version=70}} || C ||
|-
| {{cmd|g.gisenv|version=70}} || C ||
|-
| {{cmd|g.gui|version=70}} || C ||
|-
| {{cmd|g.list|version=70}} || C ||
|-
| {{cmd|g.manual|version=70}} || C ||
|-
| {{cmd|g.mapset|version=70}} || C ||
|-
| {{cmd|g.mapsets|version=70}} || C ||
|-
| {{cmd|g.message|version=70}} || C ||
|-
| {{cmd|g.mkfontcap|version=70}} || C ||
|-
| {{cmd|g.mlist|version=70}} || C ||
|-
| {{cmd|g.mremove|version=70}} || C ||
|-
| {{cmd|g.parser|version=70}} || C ||
|-
| {{cmd|g.pnmcomp|version=70}} || C ||
|-
| {{cmd|g.ppmtopng|version=70}} || C ||
|-
| {{cmd|g.proj|version=70}} || C ||
|-
| {{cmd|g.region|version=70}} || C ||
|-
| {{cmd|g.remove|version=70}} || C ||
|-
| {{cmd|g.rename|version=70}} || C ||
|-
| {{cmd|g.tempfile|version=70}} || C ||
|-
| {{cmd|g.transform|version=70}} || C ||
|-
| {{cmd|g.version|version=70}} || C ||
|-
|}

=== Imagery ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|i.albedo|version=70}} || T || IM
|-
| {{cmd|i.atcorr|version=70}} || C ||
|-
| {{cmd|i.biomass|version=70}} || T || IM
|-
| {{cmd|i.cca|version=70}} || T || IM
|-
| {{cmd|i.cluster|version=70}} || C ||
|-
| {{cmd|i.eb.eta|version=70}} || T || IM
|-
| {{cmd|i.eb.evapfr|version=70}} || T || IM
|-
| {{cmd|i.eb.h_sebal01|version=70}} || T || IM
|-
| {{cmd|i.eb.soilheatflux|version=70}} || T || IM
|-
| {{cmd|i.emissivity|version=70}} || T || IM
|-
| {{cmd|i.evapo.time|version=70}} || T || IM
|-
| {{cmd|i.fft|version=70}} || C ||
|-
| {{cmd|i.fusion.brovey|version=70}} || C ||
|-
| {{cmd|i.gensig|version=70}} || C ||
|-
| {{cmd|i.gensigset|version=70}} || C ||
|-
| {{cmd|i.group|version=70}} || C ||
|-
| {{cmd|i.his.rgb|version=70}} || C ||
|-
| {{cmd|i.ifft|version=70}} || C ||
|-
| {{cmd|i.image.mosaic|version=70}} || C ||
|-
| {{cmd|i.in.spotvgt|version=70}} || T || IO
|-
| {{cmd|i.landsat.rgb|version=70}} || C ||
|-
| {{cmd|i.latlong|version=70}} || T || IM
|-
| {{cmd|i.maxlik|version=70}} || C ||
|-
| {{cmd|i.modis.qc|version=70}} || T || IM
|-
| {{cmd|i.oif|version=70}} || T || IM
|-
| {{cmd|i.pca|version=70}} || C ||
|-
| {{cmd|i.rectify|version=70}} || C ||
|-
| {{cmd|i.rgb.his|version=70}} || C ||
|-
| {{cmd|i.smap|version=70}} || C ||
|-
| {{cmd|i.spectral|version=70}} || T || IM
|-
| {{cmd|i.sunhours|version=70}} || T || IM
|-
| {{cmd|i.target|version=70}} || C ||
|-
| {{cmd|i.tasscap|version=70}} || T || IM
|-
| {{cmd|i.vi|version=70}} || T || IM
|-
| {{cmd|i.zc|version=70}} || T || IM
|-
|}

=== Misc ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|m.cogo|version=70}} || ? ||
|-
| {{cmd|m.measure|version=70}} || ? ||
|-
| {{cmd|m.proj|version=70}} || ? ||
|-
|}

=== Postscript ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|ps.map|version=70}} || C ||
|-
|}

=== Raster ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|r.basins.fill|version=70}} || T ||TA
|-
| {{cmd|r.bitpattern|version=70}} || T || IM
|-
| {{cmd|r.blend|version=70}} || C ||
|-
| {{cmd|r.buffer|version=70}} || C ||
|-
| {{cmd|r.buffer2|version=70}} || C ||
|-
| {{cmd|r.carve|version=70}} || T || TA
|-
| {{cmd|r.category|version=70}} || C ||
|-
| {{cmd|r.circle|version=70}} || T || RA
|-
| {{cmd|r.clump|version=70}} || C ||
|-
| {{cmd|r.coin|version=70}} || T || RA
|-
| {{cmd|r.colors|version=70}} || C ||
|-
| {{cmd|r.colors.out|version=70}} || T || RA
|-
| {{cmd|r.colors.stddev|version=70}} || T || RA
|-
| {{cmd|r.composite|version=70}} || T || IM
|-
| {{cmd|r.compress|version=70}} || C ||
|-
| {{cmd|r.contour|version=70}} || C ||
|-
| {{cmd|r.cost|version=70}} || T || RA
|-
| {{cmd|r.covar|version=70}} || T || RA
|-
| {{cmd|r.cross|version=70}} || T || RA
|-
| {{cmd|r.describe|version=70}} || C ||
|-
| {{cmd|r.distance|version=70}} || T || RA
|-
| {{cmd|r.drain|version=70}} || T || RA
|-
| {{cmd|r.external|version=70}} || C ||
|-
| {{cmd|r.external.out|version=70}} || C ||
|-
| {{cmd|r.fill.dir|version=70}} || T || HY
|-
| {{cmd|r.fillnulls|version=70}} || T || RA
|-
| {{cmd|r.flow|version=70}} || T || HY
|-
| {{cmd|r.grow|version=70}} || C ||
|-
| {{cmd|r.grow.distance|version=70}} || C ||
|-
| {{cmd|r.gwflow|version=70}} || T || HY
|-
| {{cmd|r.his|version=70}} || T || IM
|-
| {{cmd|r.horizon|version=70}} || T || TA
|-
| {{cmd|r.in.arc|version=70}} || T || IO
|-
| {{cmd|r.in.ascii|version=70}} || T || IO
|-
| {{cmd|r.in.aster|version=70}} || T || IO
|-
| {{cmd|r.in.bin|version=70}} || T || IO
|-
| {{cmd|r.in.gdal|version=70}} || C ||
|-
| {{cmd|r.in.gridatb|version=70}} || T || IO
|-
| {{cmd|r.in.mat|version=70}} || T || IO
|-
| {{cmd|r.in.png|version=70}} || T || IO
|-
| {{cmd|r.in.poly|version=70}} || T || IO
|-
| {{cmd|r.in.srtm|version=70}} || T || IO
|-
| {{cmd|r.in.wms|version=70}} || T || IO
|-
| {{cmd|r.in.xyz|version=70}} || C ||
|-
| {{cmd|r.info|version=70}} || C ||
|-
| {{cmd|r.kappa|version=70}} || T || RA
|-
| {{cmd|r.lake|version=70}} || T ||HY
|-
| {{cmd|r.li.cwed|version=70}} || T || LA
|-
| {{cmd|r.li.dominance|version=70}} || T || LA
|-
| {{cmd|r.li.edgedensity|version=70}} || T || LA
|-
| {{cmd|r.li.mpa|version=70}} || T || LA
|-
| {{cmd|r.li.mps|version=70}} || T || LA
|-
| {{cmd|r.li.padcv|version=70}} || T || LA
|-
| {{cmd|r.li.padrange|version=70}} || T || LA
|-
| {{cmd|r.li.padsd|version=70}} || T || LA
|-
| {{cmd|r.li.patchdensity|version=70}} || T || LA
|-
| {{cmd|r.li.patchnum|version=70}} || T || LA
|-
| {{cmd|r.li.richness|version=70}} || T || LA
|-
| {{cmd|r.li.shannon|version=70}} || T || LA
|-
| {{cmd|r.li.shape|version=70}} || T || LA
|-
| {{cmd|r.li.simpson|version=70}} || T || LA
|-
| {{cmd|r.los|version=70}} || T||TA
|-
| {{cmd|r.mapcalc|version=70}} || C ||
|-
| {{cmd|r.mask|version=70}} || C ||
|-
| {{cmd|r.mfilter|version=70}} || T || RA
|-
| {{cmd|r.mode|version=70}} || T || RA
|-
| {{cmd|r.neighbors|version=70}} || C ||
|-
| {{cmd|r.null|version=70}} || C ||
|-
| {{cmd|r.out.arc|version=70}} || T || IO
|-
| {{cmd|r.out.ascii|version=70}} || T || IO
|-
| {{cmd|r.out.bin|version=70}} || T || IO
|-
| {{cmd|r.out.gdal|version=70}} || C ||
|-
| {{cmd|r.out.gridatb|version=70}} || T || IO
|-
| {{cmd|r.out.mat|version=70}} || T || IO
|-
| {{cmd|r.out.mpeg|version=70}} || T || IO
|-
| {{cmd|r.out.png|version=70}} || T || IO
|-
| {{cmd|r.out.pov|version=70}} || T || IO
|-
| {{cmd|r.out.ppm|version=70}} || T || IO
|-
| {{cmd|r.out.ppm3|version=70}} || T || IO
|-
| {{cmd|r.out.tiff|version=70}} || T || IO
|-
| {{cmd|r.out.vrml|version=70}} || T || IO
|-
| {{cmd|r.out.vtk|version=70}} || T || IO
|-
| {{cmd|r.out.xyz|version=70}} || C ||
|-
| {{cmd|r.param.scale|version=70}} || T ||TA
|-
| {{cmd|r.patch|version=70}} || C ||
|-
| {{cmd|r.plane|version=70}} || T || RA
|-
| {{cmd|r.profile|version=70}} || T || TA
|-
| {{cmd|r.proj|version=70}} || C ||
|-
| {{cmd|r.quant|version=70}} || C ||
|-
| {{cmd|r.quantile|version=70}} || T || RA
|-
| {{cmd|r.random|version=70}} || T || RA
|-
| {{cmd|r.random.cells|version=70}} || T || RA
|-
| {{cmd|r.random.surface|version=70}} || T || RA
|-
| {{cmd|r.reclass|version=70}} || C ||
|-
| {{cmd|r.reclass.area|version=70}} || C ||
|-
| {{cmd|r.recode|version=70}} || C ||
|-
| {{cmd|r.region|version=70}} || C ||
|-
| {{cmd|r.regression.line|version=70}} || T || RA
|-
| {{cmd|r.report|version=70}} || C ||
|-
| {{cmd|r.resamp.bspline|version=70}} || C ||
|-
| {{cmd|r.resamp.filter|version=70}} || C ||
|-
| {{cmd|r.resamp.interp|version=70}} || C ||
|-
| {{cmd|r.resamp.rst|version=70}} || C ||
|-
| {{cmd|r.resamp.stats|version=70}} || C ||
|-
| {{cmd|r.resample|version=70}} || C ||
|-
| {{cmd|r.rescale|version=70}} || C ||
|-
| {{cmd|r.rescale.eq|version=70}} || C ||
|-
| {{cmd|r.ros|version=70}} || T || RA
|-
| {{cmd|r.series|version=70}} || C ||
|-
| {{cmd|r.shaded.relief|version=70}} || C ||
|-
| {{cmd|r.sim.sediment|version=70}} || T || HY
|-
| {{cmd|r.sim.water|version=70}} || T || HY
|-
| {{cmd|r.slope.aspect|version=70}} || T || TA
|-
| {{cmd|r.solute.transport|version=70}} || T || HY
|-
| {{cmd|r.spread|version=70}} || T || RA
|-
| {{cmd|r.spreadpath|version=70}} || T || RA
|-
| {{cmd|r.statistics|version=70}} || C ||
|-
| {{cmd|r.statistics2|version=70}} || C ||
|-
| {{cmd|r.statistics3|version=70}} || C ||
|-
| {{cmd|r.stats|version=70}} || C ||
|-
| {{cmd|r.sun|version=70}} || T ||TA
|-
| {{cmd|r.sunmask|version=70}} || T || TA
|-
| {{cmd|r.support|version=70}} || C ||
|-
| {{cmd|r.support.stats|version=70}} || C ||
|-
| {{cmd|r.surf.area|version=70}} || T || TA
|-
| {{cmd|r.surf.contour|version=70}} || T || TA
|-
| {{cmd|r.surf.fractal|version=70}} || T || TA
|-
| {{cmd|r.surf.gauss|version=70}} || T || RA
|-
| {{cmd|r.surf.idw|version=70}} || T || RA
|-
| {{cmd|r.surf.idw2|version=70}} || T || RA
|-
| {{cmd|r.surf.random|version=70}} || T || RA
|-
| {{cmd|r.terraflow|version=70}} || T ||HY
|-
| {{cmd|r.texture|version=70}} || T || RA
|-
| {{cmd|r.thin|version=70}} || C ||
|-
| {{cmd|r.tileset|version=70}} || ? ||
|-
| {{cmd|r.timestamp|version=70}} || C ||
|-
| {{cmd|r.to.rast3|version=70}} || C ||
|-
| {{cmd|r.to.rast3elev|version=70}} || C ||
|-
| {{cmd|r.to.vect|version=70}} || C ||
|-
| {{cmd|r.topidx|version=70}} || T ||HY
|-
| {{cmd|r.topmodel|version=70}} || T ||HY
|-
| {{cmd|r.transect|version=70}} || T || RA
|-
| {{cmd|r.univar|version=70}} || C ||
|-
| {{cmd|r.uslek|version=70}} || T ||HY
|-
| {{cmd|r.usler|version=70}} || T ||HY
|-
| {{cmd|r.volume|version=70}} || T || RA
|-
| {{cmd|r.walk|version=70}} || T || TA
|-
| {{cmd|r.water.outlet|version=70}} || T|| HY
|-
| {{cmd|r.watershed|version=70}} || T || HY
|-
| {{cmd|r.what|version=70}} || C ||
|-
| {{cmd|r.what.color|version=70}} || C ||
|-
|}

=== 3D raster (voxel) ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|r3.cross.rast|version=70}} || T || 3D Raster
|-
| {{cmd|r3.gwflow|version=70}} || T || 3D Raster
|-
| {{cmd|r3.in.ascii|version=70}} || T || 3D Raster
|-
| {{cmd|r3.in.v5d|version=70}} || T || 3D Raster
|-
| {{cmd|r3.info|version=70}} || T || 3D Raster
|-
| {{cmd|r3.mapcalc|version=70}} || T || 3D Raster
|-
| {{cmd|r3.mask|version=70}} || T || 3D Raster
|-
| {{cmd|r3.mkdspf|version=70}} || T || 3D Raster
|-
| {{cmd|r3.null|version=70}} || T || 3D Raster
|-
| {{cmd|r3.out.ascii|version=70}} || T || 3D Raster
|-
| {{cmd|r3.out.v5d|version=70}} || T || 3D Raster
|-
| {{cmd|r3.out.vtk|version=70}} || T || 3D Raster
|-
| {{cmd|r3.stats|version=70}} || T || 3D Raster
|-
| {{cmd|r3.timestamp|version=70}} || T || 3D Raster
|-
| {{cmd|r3.to.rast|version=70}} || T || 3D Raster
|-
| {{cmd|r3.univar|version=70}} || T || 3D Raster
|-
|}

=== Vector ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|v.autokrige|version=70}} || ? ||
|-
| {{cmd|v.buffer|version=70}} || C ||
|-
| {{cmd|v.build|version=70}} || C ||
|-
| {{cmd|v.build.all|version=70}} || C ||
|-
| {{cmd|v.build.polylines|version=70}} || C ||
|-
| {{cmd|v.category|version=70}} || C ||
|-
| {{cmd|v.centroids|version=70}} || C ||
|-
| {{cmd|v.class|version=70}} || C ||
|-
| {{cmd|v.clean|version=70}} || C ||
|-
| {{cmd|v.colors|version=70}} || C ||
|-
| {{cmd|v.convert|version=70}} || T || IO
|-
| {{cmd|v.convert.all|version=70}} || T || IO
|-
| {{cmd|v.db.addcolumn|version=70}} || ? ||
|-
| {{cmd|v.db.addtable|version=70}} || ? ||
|-
| {{cmd|v.db.connect|version=70}} || ? ||
|-
| {{cmd|v.db.dropcolumn|version=70}} || ? ||
|-
| {{cmd|v.db.droprow|version=70}} || ? ||
|-
| {{cmd|v.db.droptable|version=70}} || ? ||
|-
| {{cmd|v.db.join|version=70}} || ? ||
|-
| {{cmd|v.db.reconnect.all|version=70}} || ? ||
|-
| {{cmd|v.db.renamecolumn|version=70}} || ? ||
|-
| {{cmd|v.db.select|version=70}} || ? ||
|-
| {{cmd|v.db.univar|version=70}} || ? ||
|-
| {{cmd|v.db.update|version=70}} || ? ||
|-
| {{cmd|v.delaunay|version=70}} || ? ||
|-
| {{cmd|v.dissolve|version=70}} || C ||
|-
| {{cmd|v.distance|version=70}} || ? ||
|-
| {{cmd|v.drape|version=70}} || ? ||
|-
| {{cmd|v.edit|version=70}} || C ||
|-
| {{cmd|v.external|version=70}} || C ||
|-
| {{cmd|v.extract|version=70}} || C ||
|-
| {{cmd|v.extrude|version=70}} || ? ||
|-
| {{cmd|v.generalize|version=70}} || ? ||
|-
| {{cmd|v.hull|version=70}} || ? ||
|-
| {{cmd|v.in.ascii|version=70}} || T || IO
|-
| {{cmd|v.in.db|version=70}} || C ||
|-
| {{cmd|v.in.dxf|version=70}} || T || IO
|-
| {{cmd|v.in.e00|version=70}} || T || IO
|-
| {{cmd|v.in.geonames|version=70}} || T || IO
|-
| {{cmd|v.in.gns|version=70}} || T || IO
|-
| {{cmd|v.in.lines|version=70}} || T || IO
|-
| {{cmd|v.in.mapgen|version=70}} || T || IO
|-
| {{cmd|v.in.ogr|version=70}} || C ||
|-
| {{cmd|v.in.postgis|version=70}} || T || IO
|-
| {{cmd|v.in.region|version=70}} || C ||
|-
| {{cmd|v.in.sites|version=70}} || T || IO
|-
| {{cmd|v.in.sites.all|version=70}} || T || IO
|-
| {{cmd|v.in.wfs|version=70}} || T || IO
|-
| {{cmd|v.info|version=70}} || C ||
|-
| {{cmd|v.kcv|version=70}} || ? ||
|-
| {{cmd|v.kernel|version=70}} || ? ||
|-
| {{cmd|v.krige|version=70}} || ? ||
|-
| {{cmd|v.label|version=70}} || ? ||
|-
| {{cmd|v.lidar.correction|version=70}} || ? ||
|-
| {{cmd|v.lidar.edgedetection|version=70}} || ? ||
|-
| {{cmd|v.lidar.growing|version=70}} || ? ||
|-
| {{cmd|v.lrs.create|version=70}} || ? ||
|-
| {{cmd|v.lrs.label|version=70}} || ? ||
|-
| {{cmd|v.lrs.segment|version=70}} || ? ||
|-
| {{cmd|v.lrs.where|version=70}} || ? ||
|-
| {{cmd|v.mkgrid|version=70}} || ? ||
|-
| {{cmd|v.neighbors|version=70}} || ? ||
|-
| {{cmd|v.net|version=70}} || ? ||
|-
| {{cmd|v.net.alloc|version=70}} || ? ||
|-
| {{cmd|v.net.allpairs|version=70}} || ? ||
|-
| {{cmd|v.net.bridge|version=70}} || ? ||
|-
| {{cmd|v.net.centrality|version=70}} || ? ||
|-
| {{cmd|v.net.components|version=70}} || ? ||
|-
| {{cmd|v.net.connectivity|version=70}} || ? ||
|-
| {{cmd|v.net.distance|version=70}} || ? ||
|-
| {{cmd|v.net.flow|version=70}} || ? ||
|-
| {{cmd|v.net.iso|version=70}} || ? ||
|-
| {{cmd|v.net.path|version=70}} || ? ||
|-
| {{cmd|v.net.salesman|version=70}} || ? ||
|-
| {{cmd|v.net.spanningtree|version=70}} || ? ||
|-
| {{cmd|v.net.steiner|version=70}} || ? ||
|-
| {{cmd|v.net.timetable|version=70}} || ? ||
|-
| {{cmd|v.net.visibility|version=70}} || ? ||
|-
| {{cmd|v.normal|version=70}} || ? ||
|-
| {{cmd|v.out.ascii|version=70}} || T || IO
|-
| {{cmd|v.out.dxf|version=70}} || T || IO
|-
| {{cmd|v.out.gps|version=70}} || T || IO
|-
| {{cmd|v.out.ogr|version=70}} || C ||
|-
| {{cmd|v.out.postgis|version=70}} || T || IO
|-
| {{cmd|v.out.pov|version=70}} || T || IO
|-
| {{cmd|v.out.svg|version=70}} || T || IO
|-
| {{cmd|v.out.vtk|version=70}} || T || IO
|-
| {{cmd|v.outlier|version=70}} || ? ||
|-
| {{cmd|v.overlay|version=70}} || ? ||
|-
| {{cmd|v.parallel|version=70}} || ? ||
|-
| {{cmd|v.patch|version=70}} || ? ||
|-
| {{cmd|v.perturb|version=70}} || ? ||
|-
| {{cmd|v.proj|version=70}} || C ||
|-
| {{cmd|v.qcount|version=70}} || ? ||
|-
| {{cmd|v.random|version=70}} || ? ||
|-
| {{cmd|v.rast.stats|version=70}} || ? ||
|-
| {{cmd|v.reclass|version=70}} || ? ||
|-
| {{cmd|v.report|version=70}} || ? ||
|-
| {{cmd|v.sample|version=70}} || ? ||
|-
| {{cmd|v.segment|version=70}} || ? ||
|-
| {{cmd|v.select|version=70}} || ? ||
|-
| {{cmd|v.split|version=70}} || ? ||
|-
| {{cmd|v.support|version=70}} || C ||
|-
| {{cmd|v.surf.bspline|version=70}} || ? ||
|-
| {{cmd|v.surf.idw|version=70}} || ? ||
|-
| {{cmd|v.surf.rst|version=70}} || ? ||
|-
| {{cmd|v.to.3d|version=70}} || ? ||
|-
| {{cmd|v.to.db|version=70}} || ? ||
|-
| {{cmd|v.to.points|version=70}} || ? ||
|-
| {{cmd|v.to.rast|version=70}} || ? ||
|-
| {{cmd|v.to.rast3|version=70}} || ? ||
|-
| {{cmd|v.transform|version=70}} || ? ||
|-
| {{cmd|v.type|version=70}} || ? ||
|-
| {{cmd|v.univar|version=70}} || ? ||
|-
| {{cmd|v.vol.rst|version=70}} || ? ||
|-
| {{cmd|v.voronoi|version=70}} || ? ||
|-
| {{cmd|v.what|version=70}} || ? ||
|-
| {{cmd|v.what.rast|version=70}} || ? ||
|-
| {{cmd|v.what.vect|version=70}} || ? ||
|-
|}

=== Various ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|nviz|version=70}} || ? ||
|-
| {{cmd|nviz_cmd|version=70}} || ? ||
|-
| {{cmd|wximgview|version=70}} || ? ||
|-
| {{cmd|wxpyimgview|version=70}} || ? ||
|-
| {{cmd|xganim|version=70}} || ? ||
|-
| {{cmd|ximgview|version=70}} || ? ||
|-
|}

== List of selected AddOns modules ==

See [[GRASS AddOns]] for full list of available modules. Feel free to extend this list.

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)''' || '''Note'''
|-
| {{AddonCmd|r.stream.channel}} || T || HY || {{done}}
|-
| {{AddonCmd|r.stream.distance}} || T || HY || {{done}}
|-
| {{AddonCmd|r.stream.extract}} || T || HY || {{done}}
|-
| {{AddonCmd|r.stream.order}} || T || HY || {{done}}
|-
| {{AddonCmd|r.stream.segment}} || T || HY || {{done}}
|-
| {{AddonCmd|r.stream.slope}} || T || HY || {{done}}
|-
| {{AddonCmd|r.stream.snap}} || T || HY || {{done}}
|-
| {{AddonCmd|r.stream.stats}} || T || HY || {{done}}
|-
| {{AddonCmd|r.seg}} || T || IM || It could be rename to `i.seg`
|-
| {{AddonCmd|i.topocorr}} || T || IM ||
|-
| {{AddonCmd|r.diversity}} || T || LA ||
|-
| {{AddonCmd|Ps.output}} || ? || ||
|-
| ... || ? || ||
|-
|}

== How to implement ==

=== Proposal 1 ===
* add html tag <param> in the description.html with these options:
<param name = "core"> for core module
<param name = "tool" value="tool_code/codes"> for toolbox
<param name = "addons" [value="tool_code/codes"]> for addons, value is optional

* create a script to generate a xml file for each toolbox
* add toolbox option in g.extension to read the xml and install the modules

=== Proposal 2 ===

* modules (currently only [[Addons]]) are described (name, description, keywords, files) in metadata XML file called [http://grass.osgeo.org/addons/grass7/modules.xml modules.xml] - this file is auto-generated, see [http://trac.osgeo.org/grass/wiki/AddOnsManagement#AddOnsXMLfile trac page] for details
* similarly toolboxes are described (name, code, correlate modules, list of modules) in [http://grass.osgeo.org/addons/grass7/toolboxes.xml toolboxes.xml] - this file is manually manageable via [https://svn.osgeo.org/grass/grass-addons/grass7/toolboxes.xml SVN]

{{cmd|g.extension|version=70}} reads (from remote server http://grass.osgeo.org/addons/grass7) <tt>modules.xml</tt> when listing available modules (<tt>-l</tt>), and <tt>toolboxes.xml</tt> when listing available toolboxes (<tt>-lt</tt>). When installing toolbox using {{cmd|g.extension|version=70}} the module reads <tt>toolboxes.xml</tt> and installs in the loop given list of modules. When all modules are installed it also updates local metadata files - <tt>GRASS_ADDON_BASE/modules.xml</tt> and <tt>GRASS_ADDON_BASE/toolboxes.xml</tt>. These local metadata files are checked when listing locally installed toolboxes or single modules (<tt>-a</tt> or <tt>-ta</tt>).

=== Proposal 3 ===

Use a modified version of [http://pypi.python.org/pypi/pip pip] (a tool for installing and managing Python packages)

With Pip you can add/change repository, compile C/Fortran module, manage dependencies, install from some version control system (use
URLs like hg+http://domain/repo -- or prefix git+, svn+ etc), and using [http://pypi.python.org/pypi/virtualenv virtualenv]

[[Category:Development]]

Talk:GRASS Community Sprint Prague 2012

2012-06-07T11:31:20Z

⚠️Huhabla: /* Reports */

== Reports ==

=== [[User:Landa|Martin Landa]] ===

* OSGeo4W GRASS package configuration: added libLAS support (http://liblas.org/osgeo4w.html) - {{rev|51677}} & {{rev|51679}}
* various wxGUI fixes
* implement saving list of executed commands in wxGUI - {{rev|51798}}
* wxGUI about window issues - {{rev|51830}}
* wxGUI vector/raster importer: updated list of formats (db/protocol): 'PostGIS WKT Raster driver', 'CouchDB', 'WFS','GeoRSS'

=== Markus Metz ===

* R-tree made n-dimensional (from 3D) for temporal GIS support - esp. {{rev|51799}}

=== [[User:Neteler|Markus Neteler]] ===

* Fundraising for this Community Sprint (with great help from Arnulf Christl)
* PSC composition discussion
* fix r.lake segfault for seed map ({{rev|51752}}) together with Markus Metz
* backport of wxGUI language selector (.bat file update yet missing for Windows) - together with Luca Delucchi
* Lidar DEM based example added to {{cmd|r.lake}}
* Testing QGIS-Sextante-GRASS integration:
** Location is generated on the fly, excellent
** v.buffer works
** r.terraflow works but result is not shown
** Parameter [http://sextante.googlecode.com/svn/trunk/soft/bindings/qgis-plugin/src/sextante/grass/grass.txt descriptions] are lacking in the internal control files (params/flags are duplicated), reported as http://hub.qgis.org/issues/5645
** GRASS integration should use private, not user's .grassrc6 file, reported as http://hub.qgis.org/issues/5644

=== [[User:Annakrat|Anna Kratochvilova]] ===
* wxGUI/digitizer: add help button to digitizer toolbar ({{rev|51742}})
* wxGUI: fix histogram tool (the one using the d.histogram) ({{rev|51753}})
* wxNviz: revert changes in zexag and improve its behaviour for latlon projections ({{rev|51695}})
* wxGUI: fixes for d.rast.num and d.rast.arrow

=== [[User:MilenaN|Milena Nowotarska]] ===
* WinGRASS bug hunting
* translation

=== [[User:Wenzeslaus|Vaclav Petras]] ===
* wxGUI: separating d.mon-related code ({{rev|51758}}, {{rev|51804}}), d.mon bugfixing ({{rev|51829}}, {{rev|51836}})
* wxGUI: refactoring to get simplified Map Display for d.mon (nothing to commit yet)
* wiki: [[Using QtCreator for GRASS C development]]
* other: {{trac|1663}}, {{trac|1664}}

=== [[User:NikosA|Nikos Alexandris]] ===
* Testing grass_trunk scripts (+ other modules) look at [http://titanpad.com/I51nq1SrNc GRASS Community Sprint Dashboard]
* Brainstorming about a Visual Guide to GRASS-GIS' modules capabilities [http://grass.osgeo.org/wiki/Talk:GRASS_Community_Sprint_Prague_2012#Wishes_for_the_Community_Sprint under wishes]

=== [[User:lucadelu|Luca Delucchi]] ===
* create v.in.geopaparazzi
* translation status in about gui {{rev|51838}} {{rev|51840}} {{rev|51844}} {{rev|51845}}
* several improvements in About GUI (translation status, used language, improvement font's styles)
* Some improvement into r.li.setup not finish yet

=== [[User:Turek|Stepan Turek]] ===
* r.in.wms2 - improved support of WMS 1.3.0 standard and added more examples into manual ({{rev|51700}})
* worked on feature for interactive inserting of coordinates into parameter field
* worked on improvement of mouse events handlers unregistration from map window
* discussed GSoC project with mentors
* studied WxGui code
* thanks to Václav, Anna and Martin for help

=== [[User:Huhabla|Soeren Gebbert]] ===
* Presentation and demonstration of the new temporal GIS framework
* Implementation of scaled time axis for space time voxel cubes [http://trac.osgeo.org/grass/changeset/51779 r51779]
* Discussion and specification of the new Python GRASS API with Pietro Zambelli and other GRASS developer
* Discussion about a better integration of the temporal GIS framework modules in the GRASS GUI with Martin Landa
* Bug hunting [http://trac.osgeo.org/grass/changeset/51714], [http://trac.osgeo.org/grass/changeset/51793] and tests writing for the 3D raster library
* Discussion and specification of the new GRASS [http://grass.osgeo.org/wiki/Toolboxes toolbox] approach
* Moved the ilist functions and struct from vector lib to gis lib [[http://trac.osgeo.org/grass/changeset/51796]

== Wishes for the Community Sprint ==

* Visual Guide to GRASS GIS modules: scratch a collection of per-module dedicated||or tutorial/task oriented, simple, minimalistic yet attractive, bullet-proof visual examples
**exemplify what GRASS modules do rather than how they do it, thus different than the manuals -- ''rephrase title?''
***make use of existing grass modules list(s), like (this old) [http://grass.itc.it/gdp/grassmanuals/grass63_module_list.pdf GRASS GIS 6.3 Command list (PDF document)]
***: ''HB: A version for GRASS 6.4 [http://grass.osgeo.org/gdp/grassmanuals/grass64_module_list.pdf is here]. How to advertise it better? The script to make it is in SVN, see tools/module_synopsis.sh''
***visuals should clearly refer to both commands (CLI) and (their) respective menu entry (in GUI)
***ignore modules which cannot be visualised?
**check if (and some-how) task-oriented visual examples could be build out of per-modules examples
**setup specific styling rules (?)
***only one descriptive sentence per module or task
***visuals clearly refer to both commands (CLI) and (their) respective menu entry (in GUI)
***limited caption(s) describing visuals
**end-up with some independent and beautiful TeXy PDF
**visually enrich existing manuals and/or grass-wiki
** or consider Sphinx
**Random examples
***Important concepts in GRASS-GIS' raster processing workflow
[[Image:nc_spm_08_the_computational_region_concept_800px_height.png|400px|thumb|center|Understanding the concept of computational region -- (1) North Carolina DEM 500m (elev_state_500m), (2) basins derived from the DEM by r.watershed (threshhold=50K), (3) a selected basin within which grass raster modules will operate]]
***combination of r.slope.aspect, r.buffer2 (grass70) and r.blend
[[Image:Nc_spm_09_r.blend_of_aspect_and_streams_derived_buffered.png|400px|thumb|center|r.blend -- combined streams, buffered streams and aspect]]
* Review of the python + ctypes example scripts.
: The examples given in the code for {{src|doc/python/raster_example_ctypes.py|version=trunk}}, vector_example_ctypes.py and on the [[Python Ctypes Examples|Ctypes wiki page]] have so far for me all been broken in some way or another. Either grass7 API in grass6 example, typos, incomplete, etc. have made almost all of them fail out of the box. As this is teaching code we should make sure it's perfect :-). See also bug in trac about possible memory leak in r.example.

* Extend {{cmd|r.colors}} documentation by an example for a user-generated logarithmic color table.
: + 'r.colors -e' example may be of more interest, even if many people don't know about it.
: + an example of the 'd.legend use=0.001,0.01,0.1,1,10,100' trick with log scale color rules

* I (Hamish) recently added support for Alessandro Frigeri's Planetary ellipsoid list (trunk/lib/gis/ellipse.table.solar.system) to the wx location wizard, but it is still buggy, and I think I broke e.g. "airy" too. any python experts able to help? tx.

* In the wiki, [[Template:AddonCmd]] could use an update for GRASS 7 entries. The page layout is a bit different (different pages for different groups), so either a new Template:AddonCmd7 is needed, or a bunch of fancy logic added to e.g. the way than man pages can have their version added as a "<tt>|version=</tt>" with [[Template:Cmd]].
::: (ML) This template points to [[GRASS AddOns]] page. To implement this wish we would need separate wiki pages, eg. GRASS 6 AddOns and GRASS 7 AddOns. Or the template could also point to the source code - something like [GRASS_Addons#<module>] ([trac/addons/grass<version>/<module> src]).
:::: We also have [[AddOns/GRASS7]], so the structure is totally confused. We need to keep [[AddOns]] as landing pages as it has been highly cited

* Enhance [[Template:wikipedia]] so that alternate names can be given (like with [[Template:Cmd]]), mainly to avoid having to use "_" for spaces in the presented link-text.

== Testing by power users ==

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

Please check http://titanpad.com/I51nq1SrNc

== Non-Technical ==

=== {{done}} Discuss role and current composition of GRASS-PSC ===

Discussion about GRASS [[PSC]]:
* Every year members are requested to confirm to continue their work in the PSC.
* After the Community Sprint 2012, the Chair will request updates to the [[RFC1]] from the PSC members.
* Answer within five business days needed.
* In case of no continuation/no answer, a member is replaced in order to refresh the PSC.
* To be eligible for PSC membership, a person should have a demonstrated and substantial involvement in GRASS GIS (operation of the PSC is defined at [[RFC1]]).

=== Misc ===

* {{done}} Discuss Google Summer of Code (two students are here)
* Discuss GRASS 6.4.3 and 7.0 release schedule
* Define make a manual test procedure for users to simplify testing before new releases, write this up in the wiki ([http://trac.osgeo.org/grass/wiki/HowToTestGrass6 example])

== Semi-Technical ==

=== {{done}} Improve Web site or use CMS ===
* Discussion about [[CMS]]
** Prototype site: http://grass.fem-environment.eu/
** Problem: enormous job
** Involvement of people, see nice example at http://www.mageia.org/en/contribute/

=== Misc ===
* Document tips & tricks for GRASS compilation with the wxGUI
: there is [http://trac.osgeo.org/grass/wiki/CompileOnWindows Compilation on MS-Windows]
* Discuss new GRASS Book 4th edition in conjunction with the GRASS GIS 7.0 release in early 2013

== Technical ==

=== OSGeo4W ===

* [{{done}} (martinl) - {{rev|51677}} & {{rev|51679}}] GRASS package configuration: add liblas support (http://liblas.org/osgeo4w.html) ([http://wingrass.fsv.cvut.cz/grass64/ download])

=== Android ===

* continue the Android compilation (needs especially the elimination of XDR in rast and rast3d)

=== QGIS-Sextante-GRASS interface ===

* work on new integration with [http://plugins.qgis.org/plugins/sextante/ QGIS-Sextante]

=== Update the GDAL-GRASS interface to GRASS 7 ===

* see http://trac.osgeo.org/gdal/ticket/2953
* LGPL grass IO code written from scratch?

=== Rules Based programming and Agent Based Modelling ===

* Tutorial/Documentation on g.infer
* [http://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.agent r.agent] in GRASS 7

=== Time series ===

* {{done}} Seminar on Temporal GIS framework demo and discussion: by Soeren Gebbert
* Add content to http://grass.osgeo.org/grass70/manuals/html70_user/temporalintro.html from Soeren's tutorial
* Discuss temporal GIS wxGUI and WPS integration
* Discuss massive parallel computation of spatio-temporal datasets

=== Automated command use statistics ===

* modify {{Cmd|g.parser}} to write out the list of used commands (without parameters) into a text file for simple, automated command use statistics
: HB: ''I've already written a script to do this. (a while ago, I'll have to dig it out)''

=== Mobile: inventory of mobile and touch implementations ===

* [{{done}} (lucadelu) {{rev|51791}} & {{rev|51792}}] [http://code.google.com/p/geopaparazzi/ Geopaparazzi], v.in.geopaparazzi
* GRASS on Android (patches by MN)

=== Cloud computing ===

* g.cloud
* cluster usage best practices

=== GSoC 2012 ===

* v.net.* front end, WMS
* Python API
* Image Segmentation

=== GRASS 7 ===
* [[PostGIS]] Topology support
* New features for vector engine
* Discuss Toolbox concept
* Discuss how to implement [[GRASS Metadata Management]]
* [{{done}} (lucadelu) - {{rev|51735}}] Fix category in {{Cmd|v.in.mapgen|version=70}}
* [{{done}} ] New addons module [[AddOns/GRASS7|r.massmov]]

=== Model integration ===

* GRASS and [http://www.coulthard.org.uk/CAESAR.html Caesar model]

=== GRASS modules fixes ===

* {{Cmd|i.atcorr}} debugging
** Figure out how to get visibility/aerosol depth at 550nm (perhaps from MODIS atmosphere?)
** Under certain circumstances i.atcorr produces NULL data
* GRASS 6.4.3 - [http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&group=type&order=priority&priority=blocker&priority=critical&milestone=6.4.3&milestone=6.4.2&milestone=6.4.1&milestone=6.4.0 Release critical issues to be fixed]

=== Signal handling ===

* The Python based scripts should catch CTRL-C to avoid that clutter is left behind & that ugly traceback messages are printed to the terminal.

Suggestion by Anne Ghisla (yet not working... ):
<source lang="python">
Index: lib/init/grass.py
===================================================================
--- lib/init/grass.py (revision 51604)
+++ lib/init/grass.py (working copy)
@@ -30,7 +30,12 @@
import subprocess
import re
import platform
+import signal

+# catch user-sent CTRL-C
+signal.signal(signal.SIGINT, lambda a,b:cleanup())
+signal.siginterrupt(signal.SIGINT, False)
+
# Variables substituted during build process
if os.environ.has_key('GISBASE'):
gisbase = os.environ['GISBASE']
</source>

* Currently if vector creation modules fail to create/import they still leave behind the empty skeleton of a map, so you need to use --o for the next time. It would be nice if cleanup could occur. This doesn't happen (visibly) with raster maps as they are composed in $MAPSET/.tmp/ and only moved into the main $MAPSET elements once everything is finished. Vector maps on the otherhand write to the MAPSET in-place.

=== Fix wxGUI problems ===

==== Add a "change language" option in GRASS GUI ====

Implement the diff provided here: http://trac.osgeo.org/grass/ticket/879

==== Fix several issues ====

A. Clerici: please fix:
* ticket https://trac.osgeo.org/grass/ticket/1564
* {{done}} ([[User:annakrat | Anna Kratochvilova]]) - {{rev|51824}}, {{rev|51825}}, {{rev|51827}}. ticket https://trac.osgeo.org/grass/ticket/1570
* wxGUI bugs (GRASS6.4.2RC3 under Fedora 16):
** {{done}} ([[User:annakrat | Anna Kratochvilova]]) - {{rev|51753}}, {{rev|51772}}, {{rev|51773}}. In the 'Create histogram of raster map' function, the style pie and the Color for text and axes options are not working. The options run fine on the tcltk GUI and in command line mode.
** In the 'Add scalebar and north arrow', the scale can be modified only once and the option can't be re-entered nor the scale can't be deleted. Also in this case there are no problems with the tcltk GUI.
** {{done}} ([[User:annakrat | Anna Kratochvilova]]) - {{rev|51824}}, {{rev|51825}}, {{rev|51827}}. The option 'Add raster cell arrows' seems not to work properly. It seems that the arrows in the Map Display cannot zoomed in. It can be checked by the following steps:
*** Load and display the aspect (Spearfish) map; Open the d.rast.arrows panel through the GUI button and choose the same map aspect. Click Apply: the Map Display appears green as expected for the very high resolution; Choose 10 for the 'Draw arrow every Nth grid cell:' option and none as 'Color for drawing grid or “none”' option. The arrows are displayed on the cells of aspect map; To make the arrows visible choose slope as 'Raster map containing values used for arrow length:' and 10.0 as 'Scale factor for arrows'. Zoom in a very small area: the cells of aspect map are enlarged, but the density of arrows remains the same; The direction is correctly the same for all arrows inside the same cell but it seems that instead of having an arrow each 10 aspect cells, there is an arrow each 10 pixel of the screen (with tcltk GUI the procedure works fine)
* Improve the GRASS 7 wx0..6 monitors
** Some improvements done by Vaclav Petras

==== Layout ====

Optionally, have all-in-one GUI window (requested by many new users!):
<center>
{|
|-
| [[Image:Wxgui_current.png|250px|thumb|center|Current wxGUI layout with detached window components]]
| [[Image:Wxgui_proposal.png|200px|thumb|center|'''Proposal''' for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus by simple rearrangement into one frame)]]
|-
|}
</center>

Proposed solution: wxLayoutAlgorithm(), see [[WxGUI#What_others_do]]

Optionally, a minimalistic cointegration of a map display and the command console. See also this post in grass-user [http://lists.osgeo.org/pipermail/grass-user/2011-April/060346.html Re: [GRASS-user<nowiki>]</nowiki> replacement for d.mon in GRASS 7.0?]
<center>
{|
|-
|[[Image:grass-gis_minimalistic_map-display_with_comman-console__layout_mockup.png|200px|thumb|left|alt text]]
|}
</center>

==== r.li.setup ====
work on {{Cmd|r.li.setup}} for GRASS7

==== Saving History ====

* when using the wxGUI, it needs to write back to the shell history
: `cat wxgui_history.log >> $MAPSET/.bash_history`
: Since the wxGUI shell quoting is not perfect, maybe it is better not to write directly to real shell history, but maintain its own in ~/.grass7/history.

==== Digitizing toolbar ====

* missing string "Select vector map" from the drop-down widget on digitizing toolbar
: on winGRASS, nightly build of 24th May
* after editing vector objects and saving, the changes are not applied on the map. Must be some refresh problem.
* Highlighting problem
: objects selected in the attribute table are not highlighted on the map
: objects selected ton the map are not highlighted in the attribute table.
* Bounding box of a layer broken after deletion of some objects with broken geometry, also displaying of the attribute table broken with a message that the map layer is not a vector one,
: closing the layer from the layer tree also not possible
: after closing GRASS6.4.3 and reopening the project, the layer is restored with all the changes applayed.

==== Attribute manager ====

* Editing attribute table broken
: cannot delete a row, permission denied
: different than selected row dissapears after not succesful row deletion but is back after refreshing the table.
* Not able to insert a value into a table, permision to the temp file denied.
* Too small area for displaying the table data after connecting a table to the vector map.
: Add a table to the vector layer in wxGUI GRASS6.4.3 with: Show attribute table > Manage layers tab.
: Go to Browse data tab, the area to thisplay the attributes is extreemly small and cannot be stretched.
: After closing the table manager and reopening, the area is normal wide again.
* SQL simple select "explodes" if selecting a string attribute without quotes

==== Map Display ====

* Clicking with a Query tool on a vector object randomly not able to find an object to display its attributes.
**[{{done}} ([[User:annakrat | Anna Kratochvilova]]) - {{rev|51810}}, {{rev|51811}}]

==== I18N ====

* Solve module description string duplication in both grassmods.po and grasswxpy.po files.
** Before fixing this problem in code, please find a way to automagically copy the translated strings to the proper .po files for all the languages.
** The problem is that the wxGUI menustrings are copied into grasswxpy_XX.po while the strings are already translated in grassmods_XX.py
* {{done}} Add current "language" output into "about" panel
* {{done}} Add new tab about "languages statistics" into "about" panel
* {{done}} Improvment "about" panel style

==== Project file ====
* Find a way to successfully open a project file made in GRASS6.4 in GRASS7.
: Due to changes (e.g. removal of some flags, e.g. -o flag of d.rast), the project file is not opened in a correct way. The user can see the layers in the layer tree, but they cannot be displayed in the map canvas. A warning would help.
* add version into file tags

=== Python coding hints ===

* Consider Spyder, a powerful interactive development environment for the Python: http://code.google.com/p/spyderlib/
* use pylint, the python code static checker: http://pypi.python.org/pypi/pylint

== Not to forget about the next time ==

First day:
* presentation of participants

First or second day:
* group photo

Talk:GRASS Community Sprint Prague 2012

2012-06-07T11:30:31Z

⚠️Huhabla:

GRASS Community Sprint Prague 2012

2012-05-28T23:17:20Z

⚠️Huhabla: /* Saturday, 26 May */

The GRASS GIS team will organize a '''GRASS Developer and Power User Meeting, aka 'GRASS Community Sprint'''' from '''May 23 to May 28, 2012'''. The sprint is following the [http://foss4g-cee.org/ FOSS4G-CEE] & [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2012 Geoinformatics] ''(Free and Open Source Software for Geospatial in Central and East Europe)'', 21-23 May 2012, Czech Technical University in [http://en.wikipedia.org/wiki/Prague Prague], [http://en.wikipedia.org/wiki/Czech_Republic Czech Republic].
[[Image:community_sprint_prague2012.png|center|640px]]
'''Important dates:'''

* 21 (Monday) - 23 (Wednesday) May 2012: [http://foss4g-cee.org/ FOSS4G-CEE & Geoinformatics conference]

* '''23 (Wednesday) - 28 (Monday) May 2012: GRASS GIS Community Sprint''' @ [http://www.fsv.cvut.cz/ FCE CTU]

[[Image:Grass-gis community sprint 2012 collage.jpg|center|500px]]

== Purpose ==

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

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

== Sponsors ==

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

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

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

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

=== Thanks to our sponsors ===

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

* remainder from the 2011 edition of the Community Sprint and small donations (via [http://www.gfoss.it/ GFOSS.it], the Italian OSGeo chapter) - 1400 Euro
* [http://www.osgeo.org/ Open Source Geospatial Foundation] (OSGeo) - 1000 Euro
* [http://www.fossgis.de/ FOSSGIS e.V.] - 1000 Euro
* Stefan Sylla, [http://sylla-consult.de/en/ sylla-consult], Frankfurt, Germany - 500 Euro

== Timing ==

'''When''': Wednesday, May 23, 2012 (day of arrival) - Monday, May 28, 2012 (day of departure)

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

'''Duration''':

* Wednesday is day of arrival
** First meeting in the evening (after the [http://foss4g-cee.org/ FOSS4G-CEE & Geoinfomatics conference]) to define the agenda
* Thursday to Sunday
** Full days
* Monday is day of departure
** Probably hacking for people with a flight later in the evening

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

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

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

== Accommodation and Costs ==

Participants should plan for the following costs:

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

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

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

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

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

== Weather and Common Item Prices ==

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

== Agenda - What we plan to do ==

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

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

=== Timeline ===

TODO: merge below entries from [[Talk:GRASS_Community_Sprint_Prague_2012]]

==== Wednesday, 23 May ====
* 14:30: Kick-off in the Faculty of Civil Engineering, building B, room 367 (3rd floor, [http://geoinformatics.fsv.cvut.cz/gwiki/Where_you_can_find_us map])
* Participants presentation

List of topics:
* various topics from the list: r.modis, add liblas support to OSGeo4W GRASS package ([http://wingrass.fsv.cvut.cz/grass64/ download])
* extension of Rtree to 4D, time series test script portability updates, ...
* see reports [[Talk:GRASS_Community_Sprint_Prague_2012|here]]
* 20:00: Dinner at restaurant [http://www.budvarkadejvice.cz Budvarka] near the university, see the [http://www.openstreetmap.org/?mlat=50.09824&mlon=14.3962&zoom=15&layers=M map]

==== Thursday, 24 May ====

* 9:00-evening
* Discuss role and current composition of GRASS-PSC
* Seminar by Sören Gebbert: "New time series management in GRASS 7" ([http://grass.osgeo.org/gdp/html_grass70/temporal.html manual])
* Starting work on v.in.geopaparazzi
* Discussion: Generate automated command statistics with g.parser (just module name)
* Discussion: adopting CMS for Web site - huge amount of work to change...
* Discussion: GSoC project discussion about the new GRASS Python API [http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2012/High_level_map_interaction#Weekly_reports] and milestones of the project
* 20:00: Dinner at restaurant [http://www.restaurant-uglaubicu.cz/ U Glaubiců] in the city center, see the [http://www.openstreetmap.org/?mlat=50.0876&mlon=14.4035&zoom=16&layers=M map]

==== Friday, 25 May ====

* 9:00-evening
* wxGUI: save session commands into protocol
* test wxGUI digitizer
* visual guide to GRASS GIS usage
* fix v.in.mapgen
* improve italian translation
* Hunting bugs in the 3D raster library and implementing new bug related unit tests [http://trac.osgeo.org/grass/ticket/1662 ticket] and [http://trac.osgeo.org/grass/changeset/51793 r51793]
* ...
* 20:00: Dinner at restaurant [http://www.hlucna-samota.cz/ Hlučná samota], see the [http://www.openstreetmap.org/?mlat=50.071600&mlon=14.436300&zoom=18&layers=M map]

==== Saturday, 26 May ====

* 9:00-evening
* backport of wxGUI language selector (.bat file update yet missing for Windows)
* Lidar DEM based example added to {{cmd|r.lake}}
* Release of new {{AddonCmd|v.in.geopaparazzi}}
* implement saving list of executed commands in wxGUI - {{rev|51798}}
* Moving the ilist functionality from the vector library to the gis library [http://trac.osgeo.org/grass/changeset/51796]
* Implementation of correctly scaled time axes when exporting space time raster datasets as 3D raster maps representing space time voxel cubes [http://trac.osgeo.org/grass/changeset/51779]
* Toolbox concept discussion see [http://grass.osgeo.org/wiki/Toolboxes wiki] update
* Discussion and implementation concepts about a better integration of the temporal GIS framework into the GUI
* 20:00: Dinner at restaurant [http://www.restauraceztratynalezy.estranky.cz/ Ztráty a nálezy], see the [http://www.openstreetmap.org/?mlat=50.07836&mlon=14.43524&zoom=16&layers=M map]

==== Sunday, 27 May ====

* 9:00-evening
* wxGUI about window issues - {{rev|51830}}
* 19:00: Dinner at restaurant [http://www.uveverky.com U Veverky], see the [http://www.openstreetmap.org/?mlat=50.09909&mlon=14.4022&zoom=16&layers=M map]

==== Monday, 28 May ====

* Last meeting
* Farewell and have a good trip home

== Participation ==

We are planning for attendance of 20 people (i.e., hacking places) but of course you are welcome to join us and bring new ideas with you, as more places are 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|'''No'''
!width=130px|'''Participant '''
!width=100px|'''Country'''
!width=100px|'''Arrival'''
!width=100px|'''Departure'''
!'''Topic'''
!width=75px|'''T-Shirt'''
!'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
|Czech Republic
| May 20
| May 28
|Toolbox concept, vector engine in GRASS 7, wxGUI, PostGIS Topology support
| L
|
|-
|2
|[[User:Neteler|Markus Neteler]]
|Italy
| May 20
| May 28
|GRASS on Android, QGIS-Sextante-GRASS interface, high performance computing, g.cloud, singing & beer in pub, Toolbox, ...
| M + S
|
|-
|3
|[[User:Lucadelu|Luca Delucchi]]
|Italy
| May 20
| May 26
| r.modis, r.li.setup gui, v.in.geopaparazzi (only if andrea antonello comes to Prague)
| L
|
|-
|4
|[[User:moovida|Andrea Antonello]]
|Italy
| May 21/22
| May 25/26
| v.in.geopaparazzi, GRASS [[http://www.coulthard.org.uk/CAESAR.html Caesar model]] input module with Silvia, singing at the pub with Luca Delucchi and Peter Loewe
| L
|
|-
|5
|[[User:silli|Silvia Franceschi]]
|Italy
| May 21/22
| May 25/26
| GRASS [[http://www.coulthard.org.uk/CAESAR.html Caesar model]] input module
| S
|
|-
|6
|[[User:peter.loewe|Peter Loewe]]
|Germany
| May 20/21
| May 25/26
| collecting beer-money while Luca and Andrea sing in pubs ; i.atcorr debugging ; g.cloud ? ; r.tsunami ? ; Tutorial/Documentation on g.infer
| S
|
|-
|7
|[[User:Annakrat|Anna Kratochvilova]]
|Czech Republic
| May 20
| May 28
| imagery, wxGUI
| S
|
|-
|8
|[[User:Wenzeslaus|Vaclav Petras]]
|Czech Republic
| May 20
| May 28
| imagery, wxGUI, Toolbox concept ?
| M
|
|-
|9
|[[User:Helena|Helena Mitasova]]
|USA
|May 21
|May 25/26
|toolbox concept, student sandbox, wxnviz z-scale, inventory of mobile and touch implementations, GRASS on-line and cloud
|
|
|-
|10
|[[User:Huhabla|Sören Gebbert]]
|Germany
|May 20
|May 27
|Temporal GIS framework demo and discussion, Temporal GIS wxGUI and WPS integration, massive parallel computation of spatio-temporal datasets, Cloud computing
| L
|
|-
|11
|[[User:Turek|Štěpán Turek]]
|Czech Republic
|May 20
|May 28
|v.net.* front end, WMS
| L
|
|-
|12
|Radim Blažek
|Czech Republic
|May 24/25
|May 24/25
|QGIS interface
| -
|
|-
|13
|[[User:Pietro|Pietro Zambelli]]
|Italy
|May 23/24
|May 28/29
|GSoC2012: High level map interaction
| L
|-
|14
|Markus Metz
|Italy
|May 23
|May 26
|GRASS 7 everything
|
|
|-
|15
|[[User:NikosA|Nikos Alexandris]]
|Greece
|May 24
|May 27/28
|(wannabe) bughunter, assist documentation and tutorials
|
|
|-
|16
|[[User:MilenaN|Milena Nowotarska]]
|Poland
|May 23
|May 27
|translation, wxGUI
|S
|
|-
|17
|[[User:Maxi71|Massimiliano Cannata]]
|Switzerland
|May 20
|May 24
|finalization and commit of a new grass addon module r.massmov, a physically based model to simulate the landslide ruonout velocity and deposit thickness
|
|
|-
|18
|Monia Molinari
|Switzerland
|May 20
|May 24
|finalization and commit of a new grass addon module r.massmov, a physically based model to simulate the landslide ruonout velocity and deposit thickness
|
|
|-
|}

=== Via IRC chat ===

: [irc://freenode/grass #grass] on Freenode

For details, see [[IRC]]

=== Collaborative document scratching ===

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

Please check http://titanpad.com/I51nq1SrNc

== Individual Preparation ==

* Bring your own computer
* Bring [http://en.wikipedia.org/wiki/Mains_electricity_by_country power connector adapter] if needed (Czech Republic: 230V, 50Hz, [http://en.wikipedia.org/wiki/File:Euro-Flachstecker_2.jpg Type C Europlugs] are common and also [http://en.wikipedia.org/wiki/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 year?
** Very nice, see [[GRASS Community Sprint Prague 2011]]!
* ''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>

[[Category: Workshops]]

GRASS Community Sprint Prague 2012

2012-05-28T23:04:16Z

⚠️Huhabla: /* Saturday, 26 May */

The GRASS GIS team will organize a '''GRASS Developer and Power User Meeting, aka 'GRASS Community Sprint'''' from '''May 23 to May 28, 2012'''. The sprint is following the [http://foss4g-cee.org/ FOSS4G-CEE] & [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2012 Geoinformatics] ''(Free and Open Source Software for Geospatial in Central and East Europe)'', 21-23 May 2012, Czech Technical University in [http://en.wikipedia.org/wiki/Prague Prague], [http://en.wikipedia.org/wiki/Czech_Republic Czech Republic].
[[Image:community_sprint_prague2012.png|center|640px]]
'''Important dates:'''

* 21 (Monday) - 23 (Wednesday) May 2012: [http://foss4g-cee.org/ FOSS4G-CEE & Geoinformatics conference]

* '''23 (Wednesday) - 28 (Monday) May 2012: GRASS GIS Community Sprint''' @ [http://www.fsv.cvut.cz/ FCE CTU]

[[Image:Grass-gis community sprint 2012 collage.jpg|center|500px]]

== Purpose ==

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

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

== Sponsors ==

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

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

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

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

=== Thanks to our sponsors ===

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

* remainder from the 2011 edition of the Community Sprint and small donations (via [http://www.gfoss.it/ GFOSS.it], the Italian OSGeo chapter) - 1400 Euro
* [http://www.osgeo.org/ Open Source Geospatial Foundation] (OSGeo) - 1000 Euro
* [http://www.fossgis.de/ FOSSGIS e.V.] - 1000 Euro
* Stefan Sylla, [http://sylla-consult.de/en/ sylla-consult], Frankfurt, Germany - 500 Euro

== Timing ==

'''When''': Wednesday, May 23, 2012 (day of arrival) - Monday, May 28, 2012 (day of departure)

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

'''Duration''':

* Wednesday is day of arrival
** First meeting in the evening (after the [http://foss4g-cee.org/ FOSS4G-CEE & Geoinfomatics conference]) to define the agenda
* Thursday to Sunday
** Full days
* Monday is day of departure
** Probably hacking for people with a flight later in the evening

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

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

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

== Accommodation and Costs ==

Participants should plan for the following costs:

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

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

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

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

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

== Weather and Common Item Prices ==

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

== Agenda - What we plan to do ==

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

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

=== Timeline ===

TODO: merge below entries from [[Talk:GRASS_Community_Sprint_Prague_2012]]

==== Wednesday, 23 May ====
* 14:30: Kick-off in the Faculty of Civil Engineering, building B, room 367 (3rd floor, [http://geoinformatics.fsv.cvut.cz/gwiki/Where_you_can_find_us map])
* Participants presentation

List of topics:
* various topics from the list: r.modis, add liblas support to OSGeo4W GRASS package ([http://wingrass.fsv.cvut.cz/grass64/ download])
* extension of Rtree to 4D, time series test script portability updates, ...
* see reports [[Talk:GRASS_Community_Sprint_Prague_2012|here]]
* 20:00: Dinner at restaurant [http://www.budvarkadejvice.cz Budvarka] near the university, see the [http://www.openstreetmap.org/?mlat=50.09824&mlon=14.3962&zoom=15&layers=M map]

==== Thursday, 24 May ====

* 9:00-evening
* Discuss role and current composition of GRASS-PSC
* Seminar by Sören Gebbert: "New time series management in GRASS 7" ([http://grass.osgeo.org/gdp/html_grass70/temporal.html manual])
* Starting work on v.in.geopaparazzi
* Discussion: Generate automated command statistics with g.parser (just module name)
* Discussion: adopting CMS for Web site - huge amount of work to change...
* Discussion: GSoC project discussion about the new GRASS Python API [http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2012/High_level_map_interaction#Weekly_reports] and milestones of the project
* 20:00: Dinner at restaurant [http://www.restaurant-uglaubicu.cz/ U Glaubiců] in the city center, see the [http://www.openstreetmap.org/?mlat=50.0876&mlon=14.4035&zoom=16&layers=M map]

==== Friday, 25 May ====

* 9:00-evening
* wxGUI: save session commands into protocol
* test wxGUI digitizer
* visual guide to GRASS GIS usage
* fix v.in.mapgen
* improve italian translation
* Hunting bugs in the 3D raster library and implementing new bug related unit tests [http://trac.osgeo.org/grass/ticket/1662 ticket] and [http://trac.osgeo.org/grass/changeset/51793 r51793]
* ...
* 20:00: Dinner at restaurant [http://www.hlucna-samota.cz/ Hlučná samota], see the [http://www.openstreetmap.org/?mlat=50.071600&mlon=14.436300&zoom=18&layers=M map]

==== Saturday, 26 May ====

* 9:00-evening
* backport of wxGUI language selector (.bat file update yet missing for Windows)
* Lidar DEM based example added to {{cmd|r.lake}}
* Release of new {{AddonCmd|v.in.geopaparazzi}}
* implement saving list of executed commands in wxGUI - {{rev|51798}}
* Moving the ilist functionality from the vector library to the gis library [http://trac.osgeo.org/grass/changeset/51796]
* Implementation of correctly scaled time axes when exporting space time raster datasets as 3D raster maps representing space time voxel cubes [http://trac.osgeo.org/grass/changeset/51779]
* Toolbox concept discussion see [http://grass.osgeo.org/wiki/Toolboxes wiki] update
* 20:00: Dinner at restaurant [http://www.restauraceztratynalezy.estranky.cz/ Ztráty a nálezy], see the [http://www.openstreetmap.org/?mlat=50.07836&mlon=14.43524&zoom=16&layers=M map]

==== Sunday, 27 May ====

* 9:00-evening
* wxGUI about window issues - {{rev|51830}}
* 19:00: Dinner at restaurant [http://www.uveverky.com U Veverky], see the [http://www.openstreetmap.org/?mlat=50.09909&mlon=14.4022&zoom=16&layers=M map]

==== Monday, 28 May ====

* Last meeting
* Farewell and have a good trip home

== Participation ==

We are planning for attendance of 20 people (i.e., hacking places) but of course you are welcome to join us and bring new ideas with you, as more places are 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|'''No'''
!width=130px|'''Participant '''
!width=100px|'''Country'''
!width=100px|'''Arrival'''
!width=100px|'''Departure'''
!'''Topic'''
!width=75px|'''T-Shirt'''
!'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
|Czech Republic
| May 20
| May 28
|Toolbox concept, vector engine in GRASS 7, wxGUI, PostGIS Topology support
| L
|
|-
|2
|[[User:Neteler|Markus Neteler]]
|Italy
| May 20
| May 28
|GRASS on Android, QGIS-Sextante-GRASS interface, high performance computing, g.cloud, singing & beer in pub, Toolbox, ...
| M + S
|
|-
|3
|[[User:Lucadelu|Luca Delucchi]]
|Italy
| May 20
| May 26
| r.modis, r.li.setup gui, v.in.geopaparazzi (only if andrea antonello comes to Prague)
| L
|
|-
|4
|[[User:moovida|Andrea Antonello]]
|Italy
| May 21/22
| May 25/26
| v.in.geopaparazzi, GRASS [[http://www.coulthard.org.uk/CAESAR.html Caesar model]] input module with Silvia, singing at the pub with Luca Delucchi and Peter Loewe
| L
|
|-
|5
|[[User:silli|Silvia Franceschi]]
|Italy
| May 21/22
| May 25/26
| GRASS [[http://www.coulthard.org.uk/CAESAR.html Caesar model]] input module
| S
|
|-
|6
|[[User:peter.loewe|Peter Loewe]]
|Germany
| May 20/21
| May 25/26
| collecting beer-money while Luca and Andrea sing in pubs ; i.atcorr debugging ; g.cloud ? ; r.tsunami ? ; Tutorial/Documentation on g.infer
| S
|
|-
|7
|[[User:Annakrat|Anna Kratochvilova]]
|Czech Republic
| May 20
| May 28
| imagery, wxGUI
| S
|
|-
|8
|[[User:Wenzeslaus|Vaclav Petras]]
|Czech Republic
| May 20
| May 28
| imagery, wxGUI, Toolbox concept ?
| M
|
|-
|9
|[[User:Helena|Helena Mitasova]]
|USA
|May 21
|May 25/26
|toolbox concept, student sandbox, wxnviz z-scale, inventory of mobile and touch implementations, GRASS on-line and cloud
|
|
|-
|10
|[[User:Huhabla|Sören Gebbert]]
|Germany
|May 20
|May 27
|Temporal GIS framework demo and discussion, Temporal GIS wxGUI and WPS integration, massive parallel computation of spatio-temporal datasets, Cloud computing
| L
|
|-
|11
|[[User:Turek|Štěpán Turek]]
|Czech Republic
|May 20
|May 28
|v.net.* front end, WMS
| L
|
|-
|12
|Radim Blažek
|Czech Republic
|May 24/25
|May 24/25
|QGIS interface
| -
|
|-
|13
|[[User:Pietro|Pietro Zambelli]]
|Italy
|May 23/24
|May 28/29
|GSoC2012: High level map interaction
| L
|-
|14
|Markus Metz
|Italy
|May 23
|May 26
|GRASS 7 everything
|
|
|-
|15
|[[User:NikosA|Nikos Alexandris]]
|Greece
|May 24
|May 27/28
|(wannabe) bughunter, assist documentation and tutorials
|
|
|-
|16
|[[User:MilenaN|Milena Nowotarska]]
|Poland
|May 23
|May 27
|translation, wxGUI
|S
|
|-
|17
|[[User:Maxi71|Massimiliano Cannata]]
|Switzerland
|May 20
|May 24
|finalization and commit of a new grass addon module r.massmov, a physically based model to simulate the landslide ruonout velocity and deposit thickness
|
|
|-
|18
|Monia Molinari
|Switzerland
|May 20
|May 24
|finalization and commit of a new grass addon module r.massmov, a physically based model to simulate the landslide ruonout velocity and deposit thickness
|
|
|-
|}

=== Via IRC chat ===

: [irc://freenode/grass #grass] on Freenode

For details, see [[IRC]]

=== Collaborative document scratching ===

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

Please check http://titanpad.com/I51nq1SrNc

== Individual Preparation ==

* Bring your own computer
* Bring [http://en.wikipedia.org/wiki/Mains_electricity_by_country power connector adapter] if needed (Czech Republic: 230V, 50Hz, [http://en.wikipedia.org/wiki/File:Euro-Flachstecker_2.jpg Type C Europlugs] are common and also [http://en.wikipedia.org/wiki/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 year?
** Very nice, see [[GRASS Community Sprint Prague 2011]]!
* ''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>

[[Category: Workshops]]

GRASS Community Sprint Prague 2012

2012-05-28T23:02:13Z

⚠️Huhabla: /* Friday, 25 May */

The GRASS GIS team will organize a '''GRASS Developer and Power User Meeting, aka 'GRASS Community Sprint'''' from '''May 23 to May 28, 2012'''. The sprint is following the [http://foss4g-cee.org/ FOSS4G-CEE] & [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2012 Geoinformatics] ''(Free and Open Source Software for Geospatial in Central and East Europe)'', 21-23 May 2012, Czech Technical University in [http://en.wikipedia.org/wiki/Prague Prague], [http://en.wikipedia.org/wiki/Czech_Republic Czech Republic].
[[Image:community_sprint_prague2012.png|center|640px]]
'''Important dates:'''

* 21 (Monday) - 23 (Wednesday) May 2012: [http://foss4g-cee.org/ FOSS4G-CEE & Geoinformatics conference]

* '''23 (Wednesday) - 28 (Monday) May 2012: GRASS GIS Community Sprint''' @ [http://www.fsv.cvut.cz/ FCE CTU]

[[Image:Grass-gis community sprint 2012 collage.jpg|center|500px]]

== Purpose ==

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

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

== Sponsors ==

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

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

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

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

=== Thanks to our sponsors ===

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

* remainder from the 2011 edition of the Community Sprint and small donations (via [http://www.gfoss.it/ GFOSS.it], the Italian OSGeo chapter) - 1400 Euro
* [http://www.osgeo.org/ Open Source Geospatial Foundation] (OSGeo) - 1000 Euro
* [http://www.fossgis.de/ FOSSGIS e.V.] - 1000 Euro
* Stefan Sylla, [http://sylla-consult.de/en/ sylla-consult], Frankfurt, Germany - 500 Euro

== Timing ==

'''When''': Wednesday, May 23, 2012 (day of arrival) - Monday, May 28, 2012 (day of departure)

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

'''Duration''':

* Wednesday is day of arrival
** First meeting in the evening (after the [http://foss4g-cee.org/ FOSS4G-CEE & Geoinfomatics conference]) to define the agenda
* Thursday to Sunday
** Full days
* Monday is day of departure
** Probably hacking for people with a flight later in the evening

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

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

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

== Accommodation and Costs ==

Participants should plan for the following costs:

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

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

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

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

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

== Weather and Common Item Prices ==

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

== Agenda - What we plan to do ==

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

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

=== Timeline ===

TODO: merge below entries from [[Talk:GRASS_Community_Sprint_Prague_2012]]

==== Wednesday, 23 May ====
* 14:30: Kick-off in the Faculty of Civil Engineering, building B, room 367 (3rd floor, [http://geoinformatics.fsv.cvut.cz/gwiki/Where_you_can_find_us map])
* Participants presentation

List of topics:
* various topics from the list: r.modis, add liblas support to OSGeo4W GRASS package ([http://wingrass.fsv.cvut.cz/grass64/ download])
* extension of Rtree to 4D, time series test script portability updates, ...
* see reports [[Talk:GRASS_Community_Sprint_Prague_2012|here]]
* 20:00: Dinner at restaurant [http://www.budvarkadejvice.cz Budvarka] near the university, see the [http://www.openstreetmap.org/?mlat=50.09824&mlon=14.3962&zoom=15&layers=M map]

==== Thursday, 24 May ====

* 9:00-evening
* Discuss role and current composition of GRASS-PSC
* Seminar by Sören Gebbert: "New time series management in GRASS 7" ([http://grass.osgeo.org/gdp/html_grass70/temporal.html manual])
* Starting work on v.in.geopaparazzi
* Discussion: Generate automated command statistics with g.parser (just module name)
* Discussion: adopting CMS for Web site - huge amount of work to change...
* Discussion: GSoC project discussion about the new GRASS Python API [http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2012/High_level_map_interaction#Weekly_reports] and milestones of the project
* 20:00: Dinner at restaurant [http://www.restaurant-uglaubicu.cz/ U Glaubiců] in the city center, see the [http://www.openstreetmap.org/?mlat=50.0876&mlon=14.4035&zoom=16&layers=M map]

==== Friday, 25 May ====

* 9:00-evening
* wxGUI: save session commands into protocol
* test wxGUI digitizer
* visual guide to GRASS GIS usage
* fix v.in.mapgen
* improve italian translation
* Hunting bugs in the 3D raster library and implementing new bug related unit tests [http://trac.osgeo.org/grass/ticket/1662 ticket] and [http://trac.osgeo.org/grass/changeset/51793 r51793]
* ...
* 20:00: Dinner at restaurant [http://www.hlucna-samota.cz/ Hlučná samota], see the [http://www.openstreetmap.org/?mlat=50.071600&mlon=14.436300&zoom=18&layers=M map]

==== Saturday, 26 May ====

* 9:00-evening
* backport of wxGUI language selector (.bat file update yet missing for Windows)
* Lidar DEM based example added to {{cmd|r.lake}}
* Release of new {{AddonCmd|v.in.geopaparazzi}}
* implement saving list of executed commands in wxGUI - {{rev|51798}}
* Moving the ilist functionality from the vector library to the gis library [http://trac.osgeo.org/grass/changeset/51796]
* Implementation of correctly scaled time axes when exporting space time raster datasets as 3D raster maps representing space time voxel cubes [http://trac.osgeo.org/grass/changeset/51779]
* 20:00: Dinner at restaurant [http://www.restauraceztratynalezy.estranky.cz/ Ztráty a nálezy], see the [http://www.openstreetmap.org/?mlat=50.07836&mlon=14.43524&zoom=16&layers=M map]

==== Sunday, 27 May ====

* 9:00-evening
* wxGUI about window issues - {{rev|51830}}
* 19:00: Dinner at restaurant [http://www.uveverky.com U Veverky], see the [http://www.openstreetmap.org/?mlat=50.09909&mlon=14.4022&zoom=16&layers=M map]

==== Monday, 28 May ====

* Last meeting
* Farewell and have a good trip home

== Participation ==

We are planning for attendance of 20 people (i.e., hacking places) but of course you are welcome to join us and bring new ideas with you, as more places are 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|'''No'''
!width=130px|'''Participant '''
!width=100px|'''Country'''
!width=100px|'''Arrival'''
!width=100px|'''Departure'''
!'''Topic'''
!width=75px|'''T-Shirt'''
!'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
|Czech Republic
| May 20
| May 28
|Toolbox concept, vector engine in GRASS 7, wxGUI, PostGIS Topology support
| L
|
|-
|2
|[[User:Neteler|Markus Neteler]]
|Italy
| May 20
| May 28
|GRASS on Android, QGIS-Sextante-GRASS interface, high performance computing, g.cloud, singing & beer in pub, Toolbox, ...
| M + S
|
|-
|3
|[[User:Lucadelu|Luca Delucchi]]
|Italy
| May 20
| May 26
| r.modis, r.li.setup gui, v.in.geopaparazzi (only if andrea antonello comes to Prague)
| L
|
|-
|4
|[[User:moovida|Andrea Antonello]]
|Italy
| May 21/22
| May 25/26
| v.in.geopaparazzi, GRASS [[http://www.coulthard.org.uk/CAESAR.html Caesar model]] input module with Silvia, singing at the pub with Luca Delucchi and Peter Loewe
| L
|
|-
|5
|[[User:silli|Silvia Franceschi]]
|Italy
| May 21/22
| May 25/26
| GRASS [[http://www.coulthard.org.uk/CAESAR.html Caesar model]] input module
| S
|
|-
|6
|[[User:peter.loewe|Peter Loewe]]
|Germany
| May 20/21
| May 25/26
| collecting beer-money while Luca and Andrea sing in pubs ; i.atcorr debugging ; g.cloud ? ; r.tsunami ? ; Tutorial/Documentation on g.infer
| S
|
|-
|7
|[[User:Annakrat|Anna Kratochvilova]]
|Czech Republic
| May 20
| May 28
| imagery, wxGUI
| S
|
|-
|8
|[[User:Wenzeslaus|Vaclav Petras]]
|Czech Republic
| May 20
| May 28
| imagery, wxGUI, Toolbox concept ?
| M
|
|-
|9
|[[User:Helena|Helena Mitasova]]
|USA
|May 21
|May 25/26
|toolbox concept, student sandbox, wxnviz z-scale, inventory of mobile and touch implementations, GRASS on-line and cloud
|
|
|-
|10
|[[User:Huhabla|Sören Gebbert]]
|Germany
|May 20
|May 27
|Temporal GIS framework demo and discussion, Temporal GIS wxGUI and WPS integration, massive parallel computation of spatio-temporal datasets, Cloud computing
| L
|
|-
|11
|[[User:Turek|Štěpán Turek]]
|Czech Republic
|May 20
|May 28
|v.net.* front end, WMS
| L
|
|-
|12
|Radim Blažek
|Czech Republic
|May 24/25
|May 24/25
|QGIS interface
| -
|
|-
|13
|[[User:Pietro|Pietro Zambelli]]
|Italy
|May 23/24
|May 28/29
|GSoC2012: High level map interaction
| L
|-
|14
|Markus Metz
|Italy
|May 23
|May 26
|GRASS 7 everything
|
|
|-
|15
|[[User:NikosA|Nikos Alexandris]]
|Greece
|May 24
|May 27/28
|(wannabe) bughunter, assist documentation and tutorials
|
|
|-
|16
|[[User:MilenaN|Milena Nowotarska]]
|Poland
|May 23
|May 27
|translation, wxGUI
|S
|
|-
|17
|[[User:Maxi71|Massimiliano Cannata]]
|Switzerland
|May 20
|May 24
|finalization and commit of a new grass addon module r.massmov, a physically based model to simulate the landslide ruonout velocity and deposit thickness
|
|
|-
|18
|Monia Molinari
|Switzerland
|May 20
|May 24
|finalization and commit of a new grass addon module r.massmov, a physically based model to simulate the landslide ruonout velocity and deposit thickness
|
|
|-
|}

=== Via IRC chat ===

: [irc://freenode/grass #grass] on Freenode

For details, see [[IRC]]

=== Collaborative document scratching ===

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

Please check http://titanpad.com/I51nq1SrNc

== Individual Preparation ==

* Bring your own computer
* Bring [http://en.wikipedia.org/wiki/Mains_electricity_by_country power connector adapter] if needed (Czech Republic: 230V, 50Hz, [http://en.wikipedia.org/wiki/File:Euro-Flachstecker_2.jpg Type C Europlugs] are common and also [http://en.wikipedia.org/wiki/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 year?
** Very nice, see [[GRASS Community Sprint Prague 2011]]!
* ''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>

[[Category: Workshops]]

GRASS Community Sprint Prague 2012

2012-05-28T23:00:48Z

⚠️Huhabla: /* Friday, 25 May */

The GRASS GIS team will organize a '''GRASS Developer and Power User Meeting, aka 'GRASS Community Sprint'''' from '''May 23 to May 28, 2012'''. The sprint is following the [http://foss4g-cee.org/ FOSS4G-CEE] & [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2012 Geoinformatics] ''(Free and Open Source Software for Geospatial in Central and East Europe)'', 21-23 May 2012, Czech Technical University in [http://en.wikipedia.org/wiki/Prague Prague], [http://en.wikipedia.org/wiki/Czech_Republic Czech Republic].
[[Image:community_sprint_prague2012.png|center|640px]]
'''Important dates:'''

* 21 (Monday) - 23 (Wednesday) May 2012: [http://foss4g-cee.org/ FOSS4G-CEE & Geoinformatics conference]

* '''23 (Wednesday) - 28 (Monday) May 2012: GRASS GIS Community Sprint''' @ [http://www.fsv.cvut.cz/ FCE CTU]

[[Image:Grass-gis community sprint 2012 collage.jpg|center|500px]]

== Purpose ==

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

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

== Sponsors ==

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

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

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

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

=== Thanks to our sponsors ===

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

* remainder from the 2011 edition of the Community Sprint and small donations (via [http://www.gfoss.it/ GFOSS.it], the Italian OSGeo chapter) - 1400 Euro
* [http://www.osgeo.org/ Open Source Geospatial Foundation] (OSGeo) - 1000 Euro
* [http://www.fossgis.de/ FOSSGIS e.V.] - 1000 Euro
* Stefan Sylla, [http://sylla-consult.de/en/ sylla-consult], Frankfurt, Germany - 500 Euro

== Timing ==

'''When''': Wednesday, May 23, 2012 (day of arrival) - Monday, May 28, 2012 (day of departure)

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

'''Duration''':

* Wednesday is day of arrival
** First meeting in the evening (after the [http://foss4g-cee.org/ FOSS4G-CEE & Geoinfomatics conference]) to define the agenda
* Thursday to Sunday
** Full days
* Monday is day of departure
** Probably hacking for people with a flight later in the evening

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

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

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

== Accommodation and Costs ==

Participants should plan for the following costs:

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

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

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

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

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

== Weather and Common Item Prices ==

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

== Agenda - What we plan to do ==

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

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

=== Timeline ===

TODO: merge below entries from [[Talk:GRASS_Community_Sprint_Prague_2012]]

==== Wednesday, 23 May ====
* 14:30: Kick-off in the Faculty of Civil Engineering, building B, room 367 (3rd floor, [http://geoinformatics.fsv.cvut.cz/gwiki/Where_you_can_find_us map])
* Participants presentation

List of topics:
* various topics from the list: r.modis, add liblas support to OSGeo4W GRASS package ([http://wingrass.fsv.cvut.cz/grass64/ download])
* extension of Rtree to 4D, time series test script portability updates, ...
* see reports [[Talk:GRASS_Community_Sprint_Prague_2012|here]]
* 20:00: Dinner at restaurant [http://www.budvarkadejvice.cz Budvarka] near the university, see the [http://www.openstreetmap.org/?mlat=50.09824&mlon=14.3962&zoom=15&layers=M map]

==== Thursday, 24 May ====

* 9:00-evening
* Discuss role and current composition of GRASS-PSC
* Seminar by Sören Gebbert: "New time series management in GRASS 7" ([http://grass.osgeo.org/gdp/html_grass70/temporal.html manual])
* Starting work on v.in.geopaparazzi
* Discussion: Generate automated command statistics with g.parser (just module name)
* Discussion: adopting CMS for Web site - huge amount of work to change...
* Discussion: GSoC project discussion about the new GRASS Python API [http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2012/High_level_map_interaction#Weekly_reports] and milestones of the project
* 20:00: Dinner at restaurant [http://www.restaurant-uglaubicu.cz/ U Glaubiců] in the city center, see the [http://www.openstreetmap.org/?mlat=50.0876&mlon=14.4035&zoom=16&layers=M map]

==== Friday, 25 May ====

* 9:00-evening
* wxGUI: save session commands into protocol
* test wxGUI digitizer
* visual guide to GRASS GIS usage
* fix v.in.mapgen
* improve italian translation
* Hunting bugs in the 3D raster library and implementing new bug related unit tests [http://trac.osgeo.org/grass/ticket/1662] and http://trac.osgeo.org/grass/changeset/51793
* ...
* 20:00: Dinner at restaurant [http://www.hlucna-samota.cz/ Hlučná samota], see the [http://www.openstreetmap.org/?mlat=50.071600&mlon=14.436300&zoom=18&layers=M map]

==== Saturday, 26 May ====

* 9:00-evening
* backport of wxGUI language selector (.bat file update yet missing for Windows)
* Lidar DEM based example added to {{cmd|r.lake}}
* Release of new {{AddonCmd|v.in.geopaparazzi}}
* implement saving list of executed commands in wxGUI - {{rev|51798}}
* Moving the ilist functionality from the vector library to the gis library [http://trac.osgeo.org/grass/changeset/51796]
* Implementation of correctly scaled time axes when exporting space time raster datasets as 3D raster maps representing space time voxel cubes [http://trac.osgeo.org/grass/changeset/51779]
* 20:00: Dinner at restaurant [http://www.restauraceztratynalezy.estranky.cz/ Ztráty a nálezy], see the [http://www.openstreetmap.org/?mlat=50.07836&mlon=14.43524&zoom=16&layers=M map]

==== Sunday, 27 May ====

* 9:00-evening
* wxGUI about window issues - {{rev|51830}}
* 19:00: Dinner at restaurant [http://www.uveverky.com U Veverky], see the [http://www.openstreetmap.org/?mlat=50.09909&mlon=14.4022&zoom=16&layers=M map]

==== Monday, 28 May ====

* Last meeting
* Farewell and have a good trip home

== Participation ==

We are planning for attendance of 20 people (i.e., hacking places) but of course you are welcome to join us and bring new ideas with you, as more places are 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|'''No'''
!width=130px|'''Participant '''
!width=100px|'''Country'''
!width=100px|'''Arrival'''
!width=100px|'''Departure'''
!'''Topic'''
!width=75px|'''T-Shirt'''
!'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
|Czech Republic
| May 20
| May 28
|Toolbox concept, vector engine in GRASS 7, wxGUI, PostGIS Topology support
| L
|
|-
|2
|[[User:Neteler|Markus Neteler]]
|Italy
| May 20
| May 28
|GRASS on Android, QGIS-Sextante-GRASS interface, high performance computing, g.cloud, singing & beer in pub, Toolbox, ...
| M + S
|
|-
|3
|[[User:Lucadelu|Luca Delucchi]]
|Italy
| May 20
| May 26
| r.modis, r.li.setup gui, v.in.geopaparazzi (only if andrea antonello comes to Prague)
| L
|
|-
|4
|[[User:moovida|Andrea Antonello]]
|Italy
| May 21/22
| May 25/26
| v.in.geopaparazzi, GRASS [[http://www.coulthard.org.uk/CAESAR.html Caesar model]] input module with Silvia, singing at the pub with Luca Delucchi and Peter Loewe
| L
|
|-
|5
|[[User:silli|Silvia Franceschi]]
|Italy
| May 21/22
| May 25/26
| GRASS [[http://www.coulthard.org.uk/CAESAR.html Caesar model]] input module
| S
|
|-
|6
|[[User:peter.loewe|Peter Loewe]]
|Germany
| May 20/21
| May 25/26
| collecting beer-money while Luca and Andrea sing in pubs ; i.atcorr debugging ; g.cloud ? ; r.tsunami ? ; Tutorial/Documentation on g.infer
| S
|
|-
|7
|[[User:Annakrat|Anna Kratochvilova]]
|Czech Republic
| May 20
| May 28
| imagery, wxGUI
| S
|
|-
|8
|[[User:Wenzeslaus|Vaclav Petras]]
|Czech Republic
| May 20
| May 28
| imagery, wxGUI, Toolbox concept ?
| M
|
|-
|9
|[[User:Helena|Helena Mitasova]]
|USA
|May 21
|May 25/26
|toolbox concept, student sandbox, wxnviz z-scale, inventory of mobile and touch implementations, GRASS on-line and cloud
|
|
|-
|10
|[[User:Huhabla|Sören Gebbert]]
|Germany
|May 20
|May 27
|Temporal GIS framework demo and discussion, Temporal GIS wxGUI and WPS integration, massive parallel computation of spatio-temporal datasets, Cloud computing
| L
|
|-
|11
|[[User:Turek|Štěpán Turek]]
|Czech Republic
|May 20
|May 28
|v.net.* front end, WMS
| L
|
|-
|12
|Radim Blažek
|Czech Republic
|May 24/25
|May 24/25
|QGIS interface
| -
|
|-
|13
|[[User:Pietro|Pietro Zambelli]]
|Italy
|May 23/24
|May 28/29
|GSoC2012: High level map interaction
| L
|-
|14
|Markus Metz
|Italy
|May 23
|May 26
|GRASS 7 everything
|
|
|-
|15
|[[User:NikosA|Nikos Alexandris]]
|Greece
|May 24
|May 27/28
|(wannabe) bughunter, assist documentation and tutorials
|
|
|-
|16
|[[User:MilenaN|Milena Nowotarska]]
|Poland
|May 23
|May 27
|translation, wxGUI
|S
|
|-
|17
|[[User:Maxi71|Massimiliano Cannata]]
|Switzerland
|May 20
|May 24
|finalization and commit of a new grass addon module r.massmov, a physically based model to simulate the landslide ruonout velocity and deposit thickness
|
|
|-
|18
|Monia Molinari
|Switzerland
|May 20
|May 24
|finalization and commit of a new grass addon module r.massmov, a physically based model to simulate the landslide ruonout velocity and deposit thickness
|
|
|-
|}

=== Via IRC chat ===

: [irc://freenode/grass #grass] on Freenode

For details, see [[IRC]]

=== Collaborative document scratching ===

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

Please check http://titanpad.com/I51nq1SrNc

== Individual Preparation ==

* Bring your own computer
* Bring [http://en.wikipedia.org/wiki/Mains_electricity_by_country power connector adapter] if needed (Czech Republic: 230V, 50Hz, [http://en.wikipedia.org/wiki/File:Euro-Flachstecker_2.jpg Type C Europlugs] are common and also [http://en.wikipedia.org/wiki/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 year?
** Very nice, see [[GRASS Community Sprint Prague 2011]]!
* ''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>

[[Category: Workshops]]

GRASS Community Sprint Prague 2012

2012-05-28T22:59:11Z

⚠️Huhabla: /* Saturday, 26 May */

The GRASS GIS team will organize a '''GRASS Developer and Power User Meeting, aka 'GRASS Community Sprint'''' from '''May 23 to May 28, 2012'''. The sprint is following the [http://foss4g-cee.org/ FOSS4G-CEE] & [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2012 Geoinformatics] ''(Free and Open Source Software for Geospatial in Central and East Europe)'', 21-23 May 2012, Czech Technical University in [http://en.wikipedia.org/wiki/Prague Prague], [http://en.wikipedia.org/wiki/Czech_Republic Czech Republic].
[[Image:community_sprint_prague2012.png|center|640px]]
'''Important dates:'''

* 21 (Monday) - 23 (Wednesday) May 2012: [http://foss4g-cee.org/ FOSS4G-CEE & Geoinformatics conference]

* '''23 (Wednesday) - 28 (Monday) May 2012: GRASS GIS Community Sprint''' @ [http://www.fsv.cvut.cz/ FCE CTU]

[[Image:Grass-gis community sprint 2012 collage.jpg|center|500px]]

== Purpose ==

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

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

== Sponsors ==

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

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

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

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

=== Thanks to our sponsors ===

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

* remainder from the 2011 edition of the Community Sprint and small donations (via [http://www.gfoss.it/ GFOSS.it], the Italian OSGeo chapter) - 1400 Euro
* [http://www.osgeo.org/ Open Source Geospatial Foundation] (OSGeo) - 1000 Euro
* [http://www.fossgis.de/ FOSSGIS e.V.] - 1000 Euro
* Stefan Sylla, [http://sylla-consult.de/en/ sylla-consult], Frankfurt, Germany - 500 Euro

== Timing ==

'''When''': Wednesday, May 23, 2012 (day of arrival) - Monday, May 28, 2012 (day of departure)

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

'''Duration''':

* Wednesday is day of arrival
** First meeting in the evening (after the [http://foss4g-cee.org/ FOSS4G-CEE & Geoinfomatics conference]) to define the agenda
* Thursday to Sunday
** Full days
* Monday is day of departure
** Probably hacking for people with a flight later in the evening

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

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

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

== Accommodation and Costs ==

Participants should plan for the following costs:

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

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

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

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

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

== Weather and Common Item Prices ==

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

== Agenda - What we plan to do ==

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

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

=== Timeline ===

TODO: merge below entries from [[Talk:GRASS_Community_Sprint_Prague_2012]]

==== Wednesday, 23 May ====
* 14:30: Kick-off in the Faculty of Civil Engineering, building B, room 367 (3rd floor, [http://geoinformatics.fsv.cvut.cz/gwiki/Where_you_can_find_us map])
* Participants presentation

List of topics:
* various topics from the list: r.modis, add liblas support to OSGeo4W GRASS package ([http://wingrass.fsv.cvut.cz/grass64/ download])
* extension of Rtree to 4D, time series test script portability updates, ...
* see reports [[Talk:GRASS_Community_Sprint_Prague_2012|here]]
* 20:00: Dinner at restaurant [http://www.budvarkadejvice.cz Budvarka] near the university, see the [http://www.openstreetmap.org/?mlat=50.09824&mlon=14.3962&zoom=15&layers=M map]

==== Thursday, 24 May ====

* 9:00-evening
* Discuss role and current composition of GRASS-PSC
* Seminar by Sören Gebbert: "New time series management in GRASS 7" ([http://grass.osgeo.org/gdp/html_grass70/temporal.html manual])
* Starting work on v.in.geopaparazzi
* Discussion: Generate automated command statistics with g.parser (just module name)
* Discussion: adopting CMS for Web site - huge amount of work to change...
* Discussion: GSoC project discussion about the new GRASS Python API [http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2012/High_level_map_interaction#Weekly_reports] and milestones of the project
* 20:00: Dinner at restaurant [http://www.restaurant-uglaubicu.cz/ U Glaubiců] in the city center, see the [http://www.openstreetmap.org/?mlat=50.0876&mlon=14.4035&zoom=16&layers=M map]

==== Friday, 25 May ====

* 9:00-evening
* wxGUI: save session commands into protocol
* test wxGUI digitizer
* visual guide to GRASS GIS usage
* fix v.in.mapgen
* improve italian translation
* Hunting bugs in the 3D raster library and implementing unit tests
* ...
* 20:00: Dinner at restaurant [http://www.hlucna-samota.cz/ Hlučná samota], see the [http://www.openstreetmap.org/?mlat=50.071600&mlon=14.436300&zoom=18&layers=M map]

==== Saturday, 26 May ====

* 9:00-evening
* backport of wxGUI language selector (.bat file update yet missing for Windows)
* Lidar DEM based example added to {{cmd|r.lake}}
* Release of new {{AddonCmd|v.in.geopaparazzi}}
* implement saving list of executed commands in wxGUI - {{rev|51798}}
* Moving the ilist functionality from the vector library to the gis library [http://trac.osgeo.org/grass/changeset/51796]
* Implementation of correctly scaled time axes when exporting space time raster datasets as 3D raster maps representing space time voxel cubes [http://trac.osgeo.org/grass/changeset/51779]
* 20:00: Dinner at restaurant [http://www.restauraceztratynalezy.estranky.cz/ Ztráty a nálezy], see the [http://www.openstreetmap.org/?mlat=50.07836&mlon=14.43524&zoom=16&layers=M map]

==== Sunday, 27 May ====

* 9:00-evening
* wxGUI about window issues - {{rev|51830}}
* 19:00: Dinner at restaurant [http://www.uveverky.com U Veverky], see the [http://www.openstreetmap.org/?mlat=50.09909&mlon=14.4022&zoom=16&layers=M map]

==== Monday, 28 May ====

* Last meeting
* Farewell and have a good trip home

== Participation ==

We are planning for attendance of 20 people (i.e., hacking places) but of course you are welcome to join us and bring new ideas with you, as more places are 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|'''No'''
!width=130px|'''Participant '''
!width=100px|'''Country'''
!width=100px|'''Arrival'''
!width=100px|'''Departure'''
!'''Topic'''
!width=75px|'''T-Shirt'''
!'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
|Czech Republic
| May 20
| May 28
|Toolbox concept, vector engine in GRASS 7, wxGUI, PostGIS Topology support
| L
|
|-
|2
|[[User:Neteler|Markus Neteler]]
|Italy
| May 20
| May 28
|GRASS on Android, QGIS-Sextante-GRASS interface, high performance computing, g.cloud, singing & beer in pub, Toolbox, ...
| M + S
|
|-
|3
|[[User:Lucadelu|Luca Delucchi]]
|Italy
| May 20
| May 26
| r.modis, r.li.setup gui, v.in.geopaparazzi (only if andrea antonello comes to Prague)
| L
|
|-
|4
|[[User:moovida|Andrea Antonello]]
|Italy
| May 21/22
| May 25/26
| v.in.geopaparazzi, GRASS [[http://www.coulthard.org.uk/CAESAR.html Caesar model]] input module with Silvia, singing at the pub with Luca Delucchi and Peter Loewe
| L
|
|-
|5
|[[User:silli|Silvia Franceschi]]
|Italy
| May 21/22
| May 25/26
| GRASS [[http://www.coulthard.org.uk/CAESAR.html Caesar model]] input module
| S
|
|-
|6
|[[User:peter.loewe|Peter Loewe]]
|Germany
| May 20/21
| May 25/26
| collecting beer-money while Luca and Andrea sing in pubs ; i.atcorr debugging ; g.cloud ? ; r.tsunami ? ; Tutorial/Documentation on g.infer
| S
|
|-
|7
|[[User:Annakrat|Anna Kratochvilova]]
|Czech Republic
| May 20
| May 28
| imagery, wxGUI
| S
|
|-
|8
|[[User:Wenzeslaus|Vaclav Petras]]
|Czech Republic
| May 20
| May 28
| imagery, wxGUI, Toolbox concept ?
| M
|
|-
|9
|[[User:Helena|Helena Mitasova]]
|USA
|May 21
|May 25/26
|toolbox concept, student sandbox, wxnviz z-scale, inventory of mobile and touch implementations, GRASS on-line and cloud
|
|
|-
|10
|[[User:Huhabla|Sören Gebbert]]
|Germany
|May 20
|May 27
|Temporal GIS framework demo and discussion, Temporal GIS wxGUI and WPS integration, massive parallel computation of spatio-temporal datasets, Cloud computing
| L
|
|-
|11
|[[User:Turek|Štěpán Turek]]
|Czech Republic
|May 20
|May 28
|v.net.* front end, WMS
| L
|
|-
|12
|Radim Blažek
|Czech Republic
|May 24/25
|May 24/25
|QGIS interface
| -
|
|-
|13
|[[User:Pietro|Pietro Zambelli]]
|Italy
|May 23/24
|May 28/29
|GSoC2012: High level map interaction
| L
|-
|14
|Markus Metz
|Italy
|May 23
|May 26
|GRASS 7 everything
|
|
|-
|15
|[[User:NikosA|Nikos Alexandris]]
|Greece
|May 24
|May 27/28
|(wannabe) bughunter, assist documentation and tutorials
|
|
|-
|16
|[[User:MilenaN|Milena Nowotarska]]
|Poland
|May 23
|May 27
|translation, wxGUI
|S
|
|-
|17
|[[User:Maxi71|Massimiliano Cannata]]
|Switzerland
|May 20
|May 24
|finalization and commit of a new grass addon module r.massmov, a physically based model to simulate the landslide ruonout velocity and deposit thickness
|
|
|-
|18
|Monia Molinari
|Switzerland
|May 20
|May 24
|finalization and commit of a new grass addon module r.massmov, a physically based model to simulate the landslide ruonout velocity and deposit thickness
|
|
|-
|}

=== Via IRC chat ===

: [irc://freenode/grass #grass] on Freenode

For details, see [[IRC]]

=== Collaborative document scratching ===

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

Please check http://titanpad.com/I51nq1SrNc

== Individual Preparation ==

* Bring your own computer
* Bring [http://en.wikipedia.org/wiki/Mains_electricity_by_country power connector adapter] if needed (Czech Republic: 230V, 50Hz, [http://en.wikipedia.org/wiki/File:Euro-Flachstecker_2.jpg Type C Europlugs] are common and also [http://en.wikipedia.org/wiki/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 year?
** Very nice, see [[GRASS Community Sprint Prague 2011]]!
* ''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>

[[Category: Workshops]]

GRASS Community Sprint Prague 2012

2012-05-28T22:54:09Z

⚠️Huhabla: /* Friday, 25 May */

The GRASS GIS team will organize a '''GRASS Developer and Power User Meeting, aka 'GRASS Community Sprint'''' from '''May 23 to May 28, 2012'''. The sprint is following the [http://foss4g-cee.org/ FOSS4G-CEE] & [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2012 Geoinformatics] ''(Free and Open Source Software for Geospatial in Central and East Europe)'', 21-23 May 2012, Czech Technical University in [http://en.wikipedia.org/wiki/Prague Prague], [http://en.wikipedia.org/wiki/Czech_Republic Czech Republic].
[[Image:community_sprint_prague2012.png|center|640px]]
'''Important dates:'''

* 21 (Monday) - 23 (Wednesday) May 2012: [http://foss4g-cee.org/ FOSS4G-CEE & Geoinformatics conference]

* '''23 (Wednesday) - 28 (Monday) May 2012: GRASS GIS Community Sprint''' @ [http://www.fsv.cvut.cz/ FCE CTU]

[[Image:Grass-gis community sprint 2012 collage.jpg|center|500px]]

== Purpose ==

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

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

== Sponsors ==

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

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

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

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

=== Thanks to our sponsors ===

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

* remainder from the 2011 edition of the Community Sprint and small donations (via [http://www.gfoss.it/ GFOSS.it], the Italian OSGeo chapter) - 1400 Euro
* [http://www.osgeo.org/ Open Source Geospatial Foundation] (OSGeo) - 1000 Euro
* [http://www.fossgis.de/ FOSSGIS e.V.] - 1000 Euro
* Stefan Sylla, [http://sylla-consult.de/en/ sylla-consult], Frankfurt, Germany - 500 Euro

== Timing ==

'''When''': Wednesday, May 23, 2012 (day of arrival) - Monday, May 28, 2012 (day of departure)

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

'''Duration''':

* Wednesday is day of arrival
** First meeting in the evening (after the [http://foss4g-cee.org/ FOSS4G-CEE & Geoinfomatics conference]) to define the agenda
* Thursday to Sunday
** Full days
* Monday is day of departure
** Probably hacking for people with a flight later in the evening

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

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

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

== Accommodation and Costs ==

Participants should plan for the following costs:

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

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

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

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

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

== Weather and Common Item Prices ==

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

== Agenda - What we plan to do ==

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

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

=== Timeline ===

TODO: merge below entries from [[Talk:GRASS_Community_Sprint_Prague_2012]]

==== Wednesday, 23 May ====
* 14:30: Kick-off in the Faculty of Civil Engineering, building B, room 367 (3rd floor, [http://geoinformatics.fsv.cvut.cz/gwiki/Where_you_can_find_us map])
* Participants presentation

List of topics:
* various topics from the list: r.modis, add liblas support to OSGeo4W GRASS package ([http://wingrass.fsv.cvut.cz/grass64/ download])
* extension of Rtree to 4D, time series test script portability updates, ...
* see reports [[Talk:GRASS_Community_Sprint_Prague_2012|here]]
* 20:00: Dinner at restaurant [http://www.budvarkadejvice.cz Budvarka] near the university, see the [http://www.openstreetmap.org/?mlat=50.09824&mlon=14.3962&zoom=15&layers=M map]

==== Thursday, 24 May ====

* 9:00-evening
* Discuss role and current composition of GRASS-PSC
* Seminar by Sören Gebbert: "New time series management in GRASS 7" ([http://grass.osgeo.org/gdp/html_grass70/temporal.html manual])
* Starting work on v.in.geopaparazzi
* Discussion: Generate automated command statistics with g.parser (just module name)
* Discussion: adopting CMS for Web site - huge amount of work to change...
* Discussion: GSoC project discussion about the new GRASS Python API [http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2012/High_level_map_interaction#Weekly_reports] and milestones of the project
* 20:00: Dinner at restaurant [http://www.restaurant-uglaubicu.cz/ U Glaubiců] in the city center, see the [http://www.openstreetmap.org/?mlat=50.0876&mlon=14.4035&zoom=16&layers=M map]

==== Friday, 25 May ====

* 9:00-evening
* wxGUI: save session commands into protocol
* test wxGUI digitizer
* visual guide to GRASS GIS usage
* fix v.in.mapgen
* improve italian translation
* Hunting bugs in the 3D raster library and implementing unit tests
* ...
* 20:00: Dinner at restaurant [http://www.hlucna-samota.cz/ Hlučná samota], see the [http://www.openstreetmap.org/?mlat=50.071600&mlon=14.436300&zoom=18&layers=M map]

==== Saturday, 26 May ====

* 9:00-evening
* backport of wxGUI language selector (.bat file update yet missing for Windows)
* Lidar DEM based example added to {{cmd|r.lake}}
* Release of new {{AddonCmd|v.in.geopaparazzi}}
* implement saving list of executed commands in wxGUI - {{rev|51798}}
* 20:00: Dinner at restaurant [http://www.restauraceztratynalezy.estranky.cz/ Ztráty a nálezy], see the [http://www.openstreetmap.org/?mlat=50.07836&mlon=14.43524&zoom=16&layers=M map]

==== Sunday, 27 May ====

* 9:00-evening
* wxGUI about window issues - {{rev|51830}}
* 19:00: Dinner at restaurant [http://www.uveverky.com U Veverky], see the [http://www.openstreetmap.org/?mlat=50.09909&mlon=14.4022&zoom=16&layers=M map]

==== Monday, 28 May ====

* Last meeting
* Farewell and have a good trip home

== Participation ==

We are planning for attendance of 20 people (i.e., hacking places) but of course you are welcome to join us and bring new ideas with you, as more places are 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|'''No'''
!width=130px|'''Participant '''
!width=100px|'''Country'''
!width=100px|'''Arrival'''
!width=100px|'''Departure'''
!'''Topic'''
!width=75px|'''T-Shirt'''
!'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
|Czech Republic
| May 20
| May 28
|Toolbox concept, vector engine in GRASS 7, wxGUI, PostGIS Topology support
| L
|
|-
|2
|[[User:Neteler|Markus Neteler]]
|Italy
| May 20
| May 28
|GRASS on Android, QGIS-Sextante-GRASS interface, high performance computing, g.cloud, singing & beer in pub, Toolbox, ...
| M + S
|
|-
|3
|[[User:Lucadelu|Luca Delucchi]]
|Italy
| May 20
| May 26
| r.modis, r.li.setup gui, v.in.geopaparazzi (only if andrea antonello comes to Prague)
| L
|
|-
|4
|[[User:moovida|Andrea Antonello]]
|Italy
| May 21/22
| May 25/26
| v.in.geopaparazzi, GRASS [[http://www.coulthard.org.uk/CAESAR.html Caesar model]] input module with Silvia, singing at the pub with Luca Delucchi and Peter Loewe
| L
|
|-
|5
|[[User:silli|Silvia Franceschi]]
|Italy
| May 21/22
| May 25/26
| GRASS [[http://www.coulthard.org.uk/CAESAR.html Caesar model]] input module
| S
|
|-
|6
|[[User:peter.loewe|Peter Loewe]]
|Germany
| May 20/21
| May 25/26
| collecting beer-money while Luca and Andrea sing in pubs ; i.atcorr debugging ; g.cloud ? ; r.tsunami ? ; Tutorial/Documentation on g.infer
| S
|
|-
|7
|[[User:Annakrat|Anna Kratochvilova]]
|Czech Republic
| May 20
| May 28
| imagery, wxGUI
| S
|
|-
|8
|[[User:Wenzeslaus|Vaclav Petras]]
|Czech Republic
| May 20
| May 28
| imagery, wxGUI, Toolbox concept ?
| M
|
|-
|9
|[[User:Helena|Helena Mitasova]]
|USA
|May 21
|May 25/26
|toolbox concept, student sandbox, wxnviz z-scale, inventory of mobile and touch implementations, GRASS on-line and cloud
|
|
|-
|10
|[[User:Huhabla|Sören Gebbert]]
|Germany
|May 20
|May 27
|Temporal GIS framework demo and discussion, Temporal GIS wxGUI and WPS integration, massive parallel computation of spatio-temporal datasets, Cloud computing
| L
|
|-
|11
|[[User:Turek|Štěpán Turek]]
|Czech Republic
|May 20
|May 28
|v.net.* front end, WMS
| L
|
|-
|12
|Radim Blažek
|Czech Republic
|May 24/25
|May 24/25
|QGIS interface
| -
|
|-
|13
|[[User:Pietro|Pietro Zambelli]]
|Italy
|May 23/24
|May 28/29
|GSoC2012: High level map interaction
| L
|-
|14
|Markus Metz
|Italy
|May 23
|May 26
|GRASS 7 everything
|
|
|-
|15
|[[User:NikosA|Nikos Alexandris]]
|Greece
|May 24
|May 27/28
|(wannabe) bughunter, assist documentation and tutorials
|
|
|-
|16
|[[User:MilenaN|Milena Nowotarska]]
|Poland
|May 23
|May 27
|translation, wxGUI
|S
|
|-
|17
|[[User:Maxi71|Massimiliano Cannata]]
|Switzerland
|May 20
|May 24
|finalization and commit of a new grass addon module r.massmov, a physically based model to simulate the landslide ruonout velocity and deposit thickness
|
|
|-
|18
|Monia Molinari
|Switzerland
|May 20
|May 24
|finalization and commit of a new grass addon module r.massmov, a physically based model to simulate the landslide ruonout velocity and deposit thickness
|
|
|-
|}

=== Via IRC chat ===

: [irc://freenode/grass #grass] on Freenode

For details, see [[IRC]]

=== Collaborative document scratching ===

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

Please check http://titanpad.com/I51nq1SrNc

== Individual Preparation ==

* Bring your own computer
* Bring [http://en.wikipedia.org/wiki/Mains_electricity_by_country power connector adapter] if needed (Czech Republic: 230V, 50Hz, [http://en.wikipedia.org/wiki/File:Euro-Flachstecker_2.jpg Type C Europlugs] are common and also [http://en.wikipedia.org/wiki/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 year?
** Very nice, see [[GRASS Community Sprint Prague 2011]]!
* ''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>

[[Category: Workshops]]

GRASS Community Sprint Prague 2012

2012-05-28T22:52:38Z

⚠️Huhabla: /* Thursday, 24 May */

The GRASS GIS team will organize a '''GRASS Developer and Power User Meeting, aka 'GRASS Community Sprint'''' from '''May 23 to May 28, 2012'''. The sprint is following the [http://foss4g-cee.org/ FOSS4G-CEE] & [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2012 Geoinformatics] ''(Free and Open Source Software for Geospatial in Central and East Europe)'', 21-23 May 2012, Czech Technical University in [http://en.wikipedia.org/wiki/Prague Prague], [http://en.wikipedia.org/wiki/Czech_Republic Czech Republic].
[[Image:community_sprint_prague2012.png|center|640px]]
'''Important dates:'''

* 21 (Monday) - 23 (Wednesday) May 2012: [http://foss4g-cee.org/ FOSS4G-CEE & Geoinformatics conference]

* '''23 (Wednesday) - 28 (Monday) May 2012: GRASS GIS Community Sprint''' @ [http://www.fsv.cvut.cz/ FCE CTU]

[[Image:Grass-gis community sprint 2012 collage.jpg|center|500px]]

== Purpose ==

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

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

== Sponsors ==

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

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

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

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

=== Thanks to our sponsors ===

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

* remainder from the 2011 edition of the Community Sprint and small donations (via [http://www.gfoss.it/ GFOSS.it], the Italian OSGeo chapter) - 1400 Euro
* [http://www.osgeo.org/ Open Source Geospatial Foundation] (OSGeo) - 1000 Euro
* [http://www.fossgis.de/ FOSSGIS e.V.] - 1000 Euro
* Stefan Sylla, [http://sylla-consult.de/en/ sylla-consult], Frankfurt, Germany - 500 Euro

== Timing ==

'''When''': Wednesday, May 23, 2012 (day of arrival) - Monday, May 28, 2012 (day of departure)

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

'''Duration''':

* Wednesday is day of arrival
** First meeting in the evening (after the [http://foss4g-cee.org/ FOSS4G-CEE & Geoinfomatics conference]) to define the agenda
* Thursday to Sunday
** Full days
* Monday is day of departure
** Probably hacking for people with a flight later in the evening

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

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

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

== Accommodation and Costs ==

Participants should plan for the following costs:

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

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

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

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

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

== Weather and Common Item Prices ==

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

== Agenda - What we plan to do ==

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

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

=== Timeline ===

TODO: merge below entries from [[Talk:GRASS_Community_Sprint_Prague_2012]]

==== Wednesday, 23 May ====
* 14:30: Kick-off in the Faculty of Civil Engineering, building B, room 367 (3rd floor, [http://geoinformatics.fsv.cvut.cz/gwiki/Where_you_can_find_us map])
* Participants presentation

List of topics:
* various topics from the list: r.modis, add liblas support to OSGeo4W GRASS package ([http://wingrass.fsv.cvut.cz/grass64/ download])
* extension of Rtree to 4D, time series test script portability updates, ...
* see reports [[Talk:GRASS_Community_Sprint_Prague_2012|here]]
* 20:00: Dinner at restaurant [http://www.budvarkadejvice.cz Budvarka] near the university, see the [http://www.openstreetmap.org/?mlat=50.09824&mlon=14.3962&zoom=15&layers=M map]

==== Thursday, 24 May ====

* 9:00-evening
* Discuss role and current composition of GRASS-PSC
* Seminar by Sören Gebbert: "New time series management in GRASS 7" ([http://grass.osgeo.org/gdp/html_grass70/temporal.html manual])
* Starting work on v.in.geopaparazzi
* Discussion: Generate automated command statistics with g.parser (just module name)
* Discussion: adopting CMS for Web site - huge amount of work to change...
* Discussion: GSoC project discussion about the new GRASS Python API [http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2012/High_level_map_interaction#Weekly_reports] and milestones of the project
* 20:00: Dinner at restaurant [http://www.restaurant-uglaubicu.cz/ U Glaubiců] in the city center, see the [http://www.openstreetmap.org/?mlat=50.0876&mlon=14.4035&zoom=16&layers=M map]

==== Friday, 25 May ====

* 9:00-evening
* wxGUI: save session commands into protocol
* test wxGUI digitizer
* visual guide to GRASS GIS usage
* fix v.in.mapgen
* improve italian translation
* ...
* 20:00: Dinner at restaurant [http://www.hlucna-samota.cz/ Hlučná samota], see the [http://www.openstreetmap.org/?mlat=50.071600&mlon=14.436300&zoom=18&layers=M map]

==== Saturday, 26 May ====

* 9:00-evening
* backport of wxGUI language selector (.bat file update yet missing for Windows)
* Lidar DEM based example added to {{cmd|r.lake}}
* Release of new {{AddonCmd|v.in.geopaparazzi}}
* implement saving list of executed commands in wxGUI - {{rev|51798}}
* 20:00: Dinner at restaurant [http://www.restauraceztratynalezy.estranky.cz/ Ztráty a nálezy], see the [http://www.openstreetmap.org/?mlat=50.07836&mlon=14.43524&zoom=16&layers=M map]

==== Sunday, 27 May ====

* 9:00-evening
* wxGUI about window issues - {{rev|51830}}
* 19:00: Dinner at restaurant [http://www.uveverky.com U Veverky], see the [http://www.openstreetmap.org/?mlat=50.09909&mlon=14.4022&zoom=16&layers=M map]

==== Monday, 28 May ====

* Last meeting
* Farewell and have a good trip home

== Participation ==

We are planning for attendance of 20 people (i.e., hacking places) but of course you are welcome to join us and bring new ideas with you, as more places are 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|'''No'''
!width=130px|'''Participant '''
!width=100px|'''Country'''
!width=100px|'''Arrival'''
!width=100px|'''Departure'''
!'''Topic'''
!width=75px|'''T-Shirt'''
!'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
|Czech Republic
| May 20
| May 28
|Toolbox concept, vector engine in GRASS 7, wxGUI, PostGIS Topology support
| L
|
|-
|2
|[[User:Neteler|Markus Neteler]]
|Italy
| May 20
| May 28
|GRASS on Android, QGIS-Sextante-GRASS interface, high performance computing, g.cloud, singing & beer in pub, Toolbox, ...
| M + S
|
|-
|3
|[[User:Lucadelu|Luca Delucchi]]
|Italy
| May 20
| May 26
| r.modis, r.li.setup gui, v.in.geopaparazzi (only if andrea antonello comes to Prague)
| L
|
|-
|4
|[[User:moovida|Andrea Antonello]]
|Italy
| May 21/22
| May 25/26
| v.in.geopaparazzi, GRASS [[http://www.coulthard.org.uk/CAESAR.html Caesar model]] input module with Silvia, singing at the pub with Luca Delucchi and Peter Loewe
| L
|
|-
|5
|[[User:silli|Silvia Franceschi]]
|Italy
| May 21/22
| May 25/26
| GRASS [[http://www.coulthard.org.uk/CAESAR.html Caesar model]] input module
| S
|
|-
|6
|[[User:peter.loewe|Peter Loewe]]
|Germany
| May 20/21
| May 25/26
| collecting beer-money while Luca and Andrea sing in pubs ; i.atcorr debugging ; g.cloud ? ; r.tsunami ? ; Tutorial/Documentation on g.infer
| S
|
|-
|7
|[[User:Annakrat|Anna Kratochvilova]]
|Czech Republic
| May 20
| May 28
| imagery, wxGUI
| S
|
|-
|8
|[[User:Wenzeslaus|Vaclav Petras]]
|Czech Republic
| May 20
| May 28
| imagery, wxGUI, Toolbox concept ?
| M
|
|-
|9
|[[User:Helena|Helena Mitasova]]
|USA
|May 21
|May 25/26
|toolbox concept, student sandbox, wxnviz z-scale, inventory of mobile and touch implementations, GRASS on-line and cloud
|
|
|-
|10
|[[User:Huhabla|Sören Gebbert]]
|Germany
|May 20
|May 27
|Temporal GIS framework demo and discussion, Temporal GIS wxGUI and WPS integration, massive parallel computation of spatio-temporal datasets, Cloud computing
| L
|
|-
|11
|[[User:Turek|Štěpán Turek]]
|Czech Republic
|May 20
|May 28
|v.net.* front end, WMS
| L
|
|-
|12
|Radim Blažek
|Czech Republic
|May 24/25
|May 24/25
|QGIS interface
| -
|
|-
|13
|[[User:Pietro|Pietro Zambelli]]
|Italy
|May 23/24
|May 28/29
|GSoC2012: High level map interaction
| L
|-
|14
|Markus Metz
|Italy
|May 23
|May 26
|GRASS 7 everything
|
|
|-
|15
|[[User:NikosA|Nikos Alexandris]]
|Greece
|May 24
|May 27/28
|(wannabe) bughunter, assist documentation and tutorials
|
|
|-
|16
|[[User:MilenaN|Milena Nowotarska]]
|Poland
|May 23
|May 27
|translation, wxGUI
|S
|
|-
|17
|[[User:Maxi71|Massimiliano Cannata]]
|Switzerland
|May 20
|May 24
|finalization and commit of a new grass addon module r.massmov, a physically based model to simulate the landslide ruonout velocity and deposit thickness
|
|
|-
|18
|Monia Molinari
|Switzerland
|May 20
|May 24
|finalization and commit of a new grass addon module r.massmov, a physically based model to simulate the landslide ruonout velocity and deposit thickness
|
|
|-
|}

=== Via IRC chat ===

: [irc://freenode/grass #grass] on Freenode

For details, see [[IRC]]

=== Collaborative document scratching ===

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

Please check http://titanpad.com/I51nq1SrNc

== Individual Preparation ==

* Bring your own computer
* Bring [http://en.wikipedia.org/wiki/Mains_electricity_by_country power connector adapter] if needed (Czech Republic: 230V, 50Hz, [http://en.wikipedia.org/wiki/File:Euro-Flachstecker_2.jpg Type C Europlugs] are common and also [http://en.wikipedia.org/wiki/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 year?
** Very nice, see [[GRASS Community Sprint Prague 2011]]!
* ''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>

[[Category: Workshops]]

Toolboxes

2012-05-28T22:44:44Z

⚠️Huhabla:

=== New toolbox approach discussed at the GRASS Community Code Sprint in Prag 2012 ===

At the community sprint in Prague 2012 the toolbox approach with different repositories as well as the approach using "--with-toolbox/--without-toolbox" configure statements at compile time have been discussed. The major drawback of these solutions is the their complexity and the problem of cross dependencies between modules.

A new approach has been suggested using XML files to describe toolboxes and special directory structure to hide unneeded modules from the user.

The idea is to have a binary directory containing only modules that are listed in a XML file that defines what core modules should be available and what toolboxes should be used. The XML file will be used by the GUI to create menu listings for the selected modules. All modules that are deactivated in the XML file will be held in a directory that is not available in the users binary path, but in the binary search path of modules. Hence unneeded modules are invisible at the command line and in the GUI, but still available for modules that might call other modules.

New toolboxes and core modules can be simply added to the search path and the GUI by editing the XML definition and calling g.extension. The module g.extension will simply links/copy the hidden modules into the binary directory that is visible by the user or move deselected modules in the hidden directory. The GUI will always analyzes the XML toolbox configuration file for menu generation.

The configuration XML file will include a list of core modules for general, raster, image, voxel and vector processing as well as the definition of toolboxes. Toolboxes are defined by their type (raster, vector, ...) a short description and a list of modules. Modules can be defined in several different toolboxes.

The GRASS development team should provide several pre-defined XML toolbox configuration files as for hydrological modeling, vector processing, terrain modeling, image analysis, ..., and WPS server.

Using this approach the repository structure must not be changed. The build system has to be modified to use the XML toolbox file to decide where to copy the binary modules and scripts. g.extension has to be extended to link/copy selected modules in the users binary search path and to remove modules from them. GRASS will be build as usual.

=== Original approach ===

* See [http://lists.osgeo.org/pipermail/grass-dev/2010-April/050210.html original post by Jarosław Jasiewicz]

* Discussion about the suitability of the proposed change on the [[Talk:GRASS_repository_layout_proposal|talk]] side of this wiki page; discussion of the possible method on this side of the page.

<pre>
Hi all!

That rather radical ideas I present here are rather for future, at least for GRASS 8,
but I'd like present it now for long-term reflection.

Probably all notice that for over two years there is big increase in add-on repository
(including me). There are modules of different quality: from fully GRASS toolsets,
to shell or python scripts, from actively developed tools to abandoned,
from all-purpose tools to very specialized etc. I also think that that activity
will be grown due to substitute shell script by python

Similar situation is in main GRASS branch: there are modules for all like conversion tools,
interpolation methods, georeferencing etc, and very specialized modules for very limited
group of users (like wild fire), there are also some modules out of date.

I'm not enthusiastic about moving new modules into main branch. Almost every module has
different coding style and it will lasting in future that GRASS would be difficult to maintain.
On the other hand some people complains that some interesting modules are only available as
add-ons (I assume for some reasons they cannot install it)

So my suggestion is to rearrange future GRASS form two layers (main branch/add-on) into
three layers architecture:

1) GRASS core layer: much limited limited than now, only GIS environment and basic,
all-puropse tools, slow changes, great stability
2) GRASS toolset layer: oficcial GRASS thematic tools and toolsets (like terrain analysis,
hydrological analysis, photo-interpretation, landscape analysis etc,) every toolset with its
maintainer, rapid development, new ready to use tools after quality control may appear here,
also some of current main branch tool shall be moved to that layer
3) GRASS community layer: everything else like experimental, actively development new tools,
that what do not pass quality control, simple scripts, etc....

What benefits:
for developers and contributors: much clear situation and better publication path.
Toolset layer should be much more open for new tools than current GRASS main branch

for users: faster access to new tools.
There is no doubt that new tools are faster developed (less risk) than GRASS core
Binaries with toolsets could be maintained as separate apt/urpmi/pacman/yum/exe etc packages,
so it may appear in linux repository separetly form GRASS core.

There is only loose ideas. Most of them are of course taken from R (core/toolsets/rest of packages;
separate core and package development) but I think it is worth of some discuss ...

regards
Jarek
</pre>
__TOC__
== Repository layout ==
=== Current repository layout ===

<pre>
- grass
|- trunk
|- raster/
|- vector/
|- ...

- grass-addons
|- raster/
|- vector/
|- ...
</pre>

=== Proposed repository layout ===

<pre>
- grass
|- trunk
|- raster/
|- vector/
|- ...

- grass-tools
|- trunk
|- raster/
|- vector/
|- ...

- grass-addons
|- raster/
|- vector/
|- ...
</pre>

== Proposed toolboxes ==

'''Toolbox''' is a topic-based set of modules used for solving common GIS analysis, like hydrology, networking, LRS, etc.

=== Managing toolboxes ===

{{cmd|g.extension|version=70}} is designed to manage locally installed GRASS [[Addons]]. It allows to install single addons modules and also toolboxes (flag <code>-t</code>). Note that toolbox support is '''experimental'''.

* list available toolboxes

g.extension -tl

<pre>
List of available extensions (toolboxes):
Hydrology (HY)
* r.stream.basins
* r.stream.channel
* r.stream.distance
* r.stream.extract
* r.stream.order
* r.stream.segment
* r.stream.slope
* r.stream.snap
* r.stream.stats
...
</pre>

* list available modules from [[Addons]]

g.extension -l

<pre>
List of available extensions (modules):
...
r.stream.slope
...
</pre>

* install new toolbox ("Hydrology")

g.extension -t extension=HY

* install single module from "Hydrology" toolbox

g.extension extension=r.stream.slope

Module {{cmd|g.extension|version=70}} also allows to list installed extensions

* toolboxes

g.extension -ta

<pre>
List of installed extensions (toolboxes):
HY
</pre>

* or modules

g.extension -a

<pre>
List of installed extensions (modules):
r.stream.basins
r.stream.channel
r.stream.distance
r.stream.extract
r.stream.order
r.stream.segment
r.stream.slope
r.stream.snap
r.stream.stats
</pre>

* remove locally installed toolbox

g.extension -ft extension=HY operation=remove

* remove single module

g.extension -f extension=r.stream.slope operation=remove

=== List of toolboxes ===

{| class="wikitable sortable"
|'''Toolbox name''' || '''Toolbox code''' || '''Description'''||'''Correlate toolbox'''
|-
| ''3D Raster''
| R3
| All `r3.*` modules
|
|-
| ''3D Visualization''
| V3
| {{cmd|nviz_cmd|version=70}}
|
|-
| ''Atmospheric tools''
| AT
| Subset of image processing tool
|
|-
| ''Cartography''
| CA
| {{cmd|ps.map|version=70}}, {{AddonCmd|ps.output}}
|
|-
| ''Database''
| DB
| All `db.*` modules
| ''Vector analysis''
|-
| ''Geostatistcal''
| GS
| {{cmd|v.krige|version=70}} maybe other
|
|-
| ''GUI''
| GI
| [[wxGUI]]
|
|-
| ''Hydrology''
| HY
| {{cmd|r.watershed|version=70}}, {{cmd|r.terraflow|version=70}}, `r.stream.*` modules in addons, maybe other, r.flow, r.sim.water, r.sim.sediment
| ''Raster analysis''
|-
| ''Image Processing''
| IM
| All `i.*` modules, selected r.* modules
|
|-
| ''Interoperability tools''
| IO
| All the various import/export modules except for GDAL/OGR
| ''Raster analysis'', ''Vector analysis'', ''Image Processing'', ''Database''
|-
| ''Landscape analysis''
| LA
| All `r.li.*` modules, maybe other
| ''Raster analysis''
|-
| ''Lidar analysis''
| LI
| All `v.lidar.*` modules, {{cmd|v.surf.bspline|version=70}}, r.in.xyz
|
|-
| ''Linear Reference Systems''
| LS
| All `v.lrs.*` modules
| ''Vector analysis''
|-
| ''Network analysis''
| NA
| All `v.net.*` modules, maybe other
| ''Vector analysis''
|-
| ''Raster analysis''
| RA
| A lot of basic `r.*` modules (like {{cmd|r.buffer,|version=70}} {{cmd|r.reclass|version=70}}, {{cmd|r.fillnull|version=70}}...)
|
|-
| ''Terrain analysis''
| TA
| Different kind of analysis: soil ({{cmd|r.sun,|version=70}}), terrain ({{cmd|r.slope.aspect|version=70}}, {{cmd|r.los|version=70}}), geomorphometry ({{cmd|r.param.scale|version=70}})
| ''Raster analysis''
|-
| ''Vector analysis''
| VA
| A lot of basic `v.*` modules (like {{cmd|v.buffer|version=70}}, {{cmd|v.centroid|version=70}}, {{cmd|v.overlay|version=70}}...)
| ''Database''
|}

== List of modules (trunk) ==

=== Display ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|d.barscale|version=70}} || ? ||
|-
| {{cmd|d.colorlist|version=70}} || ? ||
|-
| {{cmd|d.colortable|version=70}} || ? ||
|-
| {{cmd|d.correlate|version=70}} || ? ||
|-
| {{cmd|d.erase|version=70}} || ? ||
|-
| {{cmd|d.font|version=70}} || ? ||
|-
| {{cmd|d.fontlist|version=70}} || ? ||
|-
| {{cmd|d.geodesic|version=70}} || ? ||
|-
| {{cmd|d.graph|version=70}} || ? ||
|-
| {{cmd|d.grid|version=70}} || ? ||
|-
| {{cmd|d.his|version=70}} || ? ||
|-
| {{cmd|d.histogram|version=70}} || ? ||
|-
| {{cmd|d.info|version=70}} || ? ||
|-
| {{cmd|d.labels|version=70}} || ? ||
|-
| {{cmd|d.legend|version=70}} || ? ||
|-
| {{cmd|d.linegraph|version=70}} || ? ||
|-
| {{cmd|d.nviz|version=70}} || ? ||
|-
| {{cmd|d.path|version=70}} || ? ||
|-
| {{cmd|d.polar|version=70}} || ? ||
|-
| {{cmd|d.profile|version=70}} || ? ||
|-
| {{cmd|d.rast|version=70}} || ? ||
|-
| {{cmd|d.rast.arrow|version=70}} || ? ||
|-
| {{cmd|d.rast.edit|version=70}} || ? ||
|-
| {{cmd|d.rast.leg|version=70}} || ? ||
|-
| {{cmd|d.rast.num|version=70}} || ? ||
|-
| {{cmd|d.rgb|version=70}} || ? ||
|-
| {{cmd|d.rhumbline|version=70}} || ? ||
|-
| {{cmd|d.shadedmap|version=70}} || ? ||
|-
| {{cmd|d.text|version=70}} || ? ||
|-
| {{cmd|d.thematic.area|version=70}} || ? ||
|-
| {{cmd|d.title|version=70}} || ? ||
|-
| {{cmd|d.vect|version=70}} || ? ||
|-
| {{cmd|d.vect.chart|version=70}} || ? ||
|-
| {{cmd|d.vect.thematic|version=70}} || ? ||
|-
| {{cmd|d.where|version=70}} || ? ||
|-
|}

=== Database ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|db.columns|version=70}} || ? ||
|-
| {{cmd|db.connect|version=70}} || ? ||
|-
| {{cmd|db.copy|version=70}} || ? ||
|-
| {{cmd|db.createdb|version=70}} || ? ||
|-
| {{cmd|db.databases|version=70}} || ? ||
|-
| {{cmd|db.describe|version=70}} || ? ||
|-
| {{cmd|db.drivers|version=70}} || ? ||
|-
| {{cmd|db.dropcolumn|version=70}} || ? ||
|-
| {{cmd|db.dropdb|version=70}} || ? ||
|-
| {{cmd|db.droptable|version=70}} || ? ||
|-
| {{cmd|db.droptable|version=70}} || ? ||
|-
| {{cmd|db.execute|version=70}} || ? ||
|-
| {{cmd|db.in.ogr|version=70}} || ? ||
|-
| {{cmd|db.login|version=70}} || ? ||
|-
| {{cmd|db.out.ogr|version=70}} || ? ||
|-
| {{cmd|db.select|version=70}} || ? ||
|-
| {{cmd|db.tables|version=70}} || ? ||
|-
| {{cmd|db.test|version=70}} || ? ||
|-
|}

=== General ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|g.access|version=70}} || C ||
|-
| {{cmd|g.cairocomp|version=70}} || C ||
|-
| {{cmd|g.copy|version=70}} || C ||
|-
| {{cmd|g.dirseps|version=70}} || C ||
|-
| {{cmd|g.extension|version=70}} || C ||
|-
| {{cmd|g.filename|version=70}} || C ||
|-
| {{cmd|g.findetc|version=70}} || C ||
|-
| {{cmd|g.findfile|version=70}} || C ||
|-
| {{cmd|g.gisenv|version=70}} || C ||
|-
| {{cmd|g.gui|version=70}} || C ||
|-
| {{cmd|g.list|version=70}} || C ||
|-
| {{cmd|g.manual|version=70}} || C ||
|-
| {{cmd|g.mapset|version=70}} || C ||
|-
| {{cmd|g.mapsets|version=70}} || C ||
|-
| {{cmd|g.message|version=70}} || C ||
|-
| {{cmd|g.mkfontcap|version=70}} || C ||
|-
| {{cmd|g.mlist|version=70}} || C ||
|-
| {{cmd|g.mremove|version=70}} || C ||
|-
| {{cmd|g.parser|version=70}} || C ||
|-
| {{cmd|g.pnmcomp|version=70}} || C ||
|-
| {{cmd|g.ppmtopng|version=70}} || C ||
|-
| {{cmd|g.proj|version=70}} || C ||
|-
| {{cmd|g.region|version=70}} || C ||
|-
| {{cmd|g.remove|version=70}} || C ||
|-
| {{cmd|g.rename|version=70}} || C ||
|-
| {{cmd|g.tempfile|version=70}} || C ||
|-
| {{cmd|g.transform|version=70}} || C ||
|-
| {{cmd|g.version|version=70}} || C ||
|-
|}

=== Imagery ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|i.albedo|version=70}} || T || IM
|-
| {{cmd|i.atcorr|version=70}} || C ||
|-
| {{cmd|i.biomass|version=70}} || T || IM
|-
| {{cmd|i.cca|version=70}} || T || IM
|-
| {{cmd|i.cluster|version=70}} || C ||
|-
| {{cmd|i.eb.eta|version=70}} || T || IM
|-
| {{cmd|i.eb.evapfr|version=70}} || T || IM
|-
| {{cmd|i.eb.h_sebal01|version=70}} || T || IM
|-
| {{cmd|i.eb.soilheatflux|version=70}} || T || IM
|-
| {{cmd|i.emissivity|version=70}} || T || IM
|-
| {{cmd|i.evapo.time|version=70}} || T || IM
|-
| {{cmd|i.fft|version=70}} || C ||
|-
| {{cmd|i.fusion.brovey|version=70}} || C ||
|-
| {{cmd|i.gensig|version=70}} || C ||
|-
| {{cmd|i.gensigset|version=70}} || C ||
|-
| {{cmd|i.group|version=70}} || C ||
|-
| {{cmd|i.his.rgb|version=70}} || C ||
|-
| {{cmd|i.ifft|version=70}} || C ||
|-
| {{cmd|i.image.mosaic|version=70}} || C ||
|-
| {{cmd|i.in.spotvgt|version=70}} || T || IO
|-
| {{cmd|i.landsat.rgb|version=70}} || C ||
|-
| {{cmd|i.latlong|version=70}} || T || IM
|-
| {{cmd|i.maxlik|version=70}} || C ||
|-
| {{cmd|i.modis.qc|version=70}} || T || IM
|-
| {{cmd|i.oif|version=70}} || T || IM
|-
| {{cmd|i.pca|version=70}} || C ||
|-
| {{cmd|i.rectify|version=70}} || C ||
|-
| {{cmd|i.rgb.his|version=70}} || C ||
|-
| {{cmd|i.smap|version=70}} || C ||
|-
| {{cmd|i.spectral|version=70}} || T || IM
|-
| {{cmd|i.sunhours|version=70}} || T || IM
|-
| {{cmd|i.target|version=70}} || C ||
|-
| {{cmd|i.tasscap|version=70}} || T || IM
|-
| {{cmd|i.vi|version=70}} || T || IM
|-
| {{cmd|i.zc|version=70}} || T || IM
|-
|}

=== Misc ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|m.cogo|version=70}} || ? ||
|-
| {{cmd|m.measure|version=70}} || ? ||
|-
| {{cmd|m.proj|version=70}} || ? ||
|-
|}

=== Postscript ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|ps.map|version=70}} || C ||
|-
|}

=== Raster ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|r.basins.fill|version=70}} || T ||TA
|-
| {{cmd|r.bitpattern|version=70}} || T || IM
|-
| {{cmd|r.blend|version=70}} || C ||
|-
| {{cmd|r.buffer|version=70}} || C ||
|-
| {{cmd|r.buffer2|version=70}} || C ||
|-
| {{cmd|r.carve|version=70}} || T || TA
|-
| {{cmd|r.category|version=70}} || C ||
|-
| {{cmd|r.circle|version=70}} || T || RA
|-
| {{cmd|r.clump|version=70}} || C ||
|-
| {{cmd|r.coin|version=70}} || T || RA
|-
| {{cmd|r.colors|version=70}} || C ||
|-
| {{cmd|r.colors.out|version=70}} || T || RA
|-
| {{cmd|r.colors.stddev|version=70}} || T || RA
|-
| {{cmd|r.composite|version=70}} || T || IM
|-
| {{cmd|r.compress|version=70}} || C ||
|-
| {{cmd|r.contour|version=70}} || C ||
|-
| {{cmd|r.cost|version=70}} || T || RA
|-
| {{cmd|r.covar|version=70}} || T || RA
|-
| {{cmd|r.cross|version=70}} || T || RA
|-
| {{cmd|r.describe|version=70}} || C ||
|-
| {{cmd|r.distance|version=70}} || T || RA
|-
| {{cmd|r.drain|version=70}} || T || RA
|-
| {{cmd|r.external|version=70}} || C ||
|-
| {{cmd|r.external.out|version=70}} || C ||
|-
| {{cmd|r.fill.dir|version=70}} || T || HY
|-
| {{cmd|r.fillnulls|version=70}} || T || RA
|-
| {{cmd|r.flow|version=70}} || T || HY
|-
| {{cmd|r.grow|version=70}} || C ||
|-
| {{cmd|r.grow.distance|version=70}} || C ||
|-
| {{cmd|r.gwflow|version=70}} || T || HY
|-
| {{cmd|r.his|version=70}} || T || IM
|-
| {{cmd|r.horizon|version=70}} || T || TA
|-
| {{cmd|r.in.arc|version=70}} || T || IO
|-
| {{cmd|r.in.ascii|version=70}} || T || IO
|-
| {{cmd|r.in.aster|version=70}} || T || IO
|-
| {{cmd|r.in.bin|version=70}} || T || IO
|-
| {{cmd|r.in.gdal|version=70}} || C ||
|-
| {{cmd|r.in.gridatb|version=70}} || T || IO
|-
| {{cmd|r.in.mat|version=70}} || T || IO
|-
| {{cmd|r.in.png|version=70}} || T || IO
|-
| {{cmd|r.in.poly|version=70}} || T || IO
|-
| {{cmd|r.in.srtm|version=70}} || T || IO
|-
| {{cmd|r.in.wms|version=70}} || T || IO
|-
| {{cmd|r.in.xyz|version=70}} || C ||
|-
| {{cmd|r.info|version=70}} || C ||
|-
| {{cmd|r.kappa|version=70}} || T || RA
|-
| {{cmd|r.lake|version=70}} || T ||HY
|-
| {{cmd|r.li.cwed|version=70}} || T || LA
|-
| {{cmd|r.li.dominance|version=70}} || T || LA
|-
| {{cmd|r.li.edgedensity|version=70}} || T || LA
|-
| {{cmd|r.li.mpa|version=70}} || T || LA
|-
| {{cmd|r.li.mps|version=70}} || T || LA
|-
| {{cmd|r.li.padcv|version=70}} || T || LA
|-
| {{cmd|r.li.padrange|version=70}} || T || LA
|-
| {{cmd|r.li.padsd|version=70}} || T || LA
|-
| {{cmd|r.li.patchdensity|version=70}} || T || LA
|-
| {{cmd|r.li.patchnum|version=70}} || T || LA
|-
| {{cmd|r.li.richness|version=70}} || T || LA
|-
| {{cmd|r.li.shannon|version=70}} || T || LA
|-
| {{cmd|r.li.shape|version=70}} || T || LA
|-
| {{cmd|r.li.simpson|version=70}} || T || LA
|-
| {{cmd|r.los|version=70}} || T||TA
|-
| {{cmd|r.mapcalc|version=70}} || C ||
|-
| {{cmd|r.mask|version=70}} || C ||
|-
| {{cmd|r.mfilter|version=70}} || T || RA
|-
| {{cmd|r.mode|version=70}} || T || RA
|-
| {{cmd|r.neighbors|version=70}} || C ||
|-
| {{cmd|r.null|version=70}} || C ||
|-
| {{cmd|r.out.arc|version=70}} || T || IO
|-
| {{cmd|r.out.ascii|version=70}} || T || IO
|-
| {{cmd|r.out.bin|version=70}} || T || IO
|-
| {{cmd|r.out.gdal|version=70}} || C ||
|-
| {{cmd|r.out.gridatb|version=70}} || T || IO
|-
| {{cmd|r.out.mat|version=70}} || T || IO
|-
| {{cmd|r.out.mpeg|version=70}} || T || IO
|-
| {{cmd|r.out.png|version=70}} || T || IO
|-
| {{cmd|r.out.pov|version=70}} || T || IO
|-
| {{cmd|r.out.ppm|version=70}} || T || IO
|-
| {{cmd|r.out.ppm3|version=70}} || T || IO
|-
| {{cmd|r.out.tiff|version=70}} || T || IO
|-
| {{cmd|r.out.vrml|version=70}} || T || IO
|-
| {{cmd|r.out.vtk|version=70}} || T || IO
|-
| {{cmd|r.out.xyz|version=70}} || C ||
|-
| {{cmd|r.param.scale|version=70}} || T ||TA
|-
| {{cmd|r.patch|version=70}} || C ||
|-
| {{cmd|r.plane|version=70}} || T || RA
|-
| {{cmd|r.profile|version=70}} || T || TA
|-
| {{cmd|r.proj|version=70}} || C ||
|-
| {{cmd|r.quant|version=70}} || C ||
|-
| {{cmd|r.quantile|version=70}} || T || RA
|-
| {{cmd|r.random|version=70}} || T || RA
|-
| {{cmd|r.random.cells|version=70}} || T || RA
|-
| {{cmd|r.random.surface|version=70}} || T || RA
|-
| {{cmd|r.reclass|version=70}} || C ||
|-
| {{cmd|r.reclass.area|version=70}} || C ||
|-
| {{cmd|r.recode|version=70}} || C ||
|-
| {{cmd|r.region|version=70}} || C ||
|-
| {{cmd|r.regression.line|version=70}} || T || RA
|-
| {{cmd|r.report|version=70}} || C ||
|-
| {{cmd|r.resamp.bspline|version=70}} || C ||
|-
| {{cmd|r.resamp.filter|version=70}} || C ||
|-
| {{cmd|r.resamp.interp|version=70}} || C ||
|-
| {{cmd|r.resamp.rst|version=70}} || C ||
|-
| {{cmd|r.resamp.stats|version=70}} || C ||
|-
| {{cmd|r.resample|version=70}} || C ||
|-
| {{cmd|r.rescale|version=70}} || C ||
|-
| {{cmd|r.rescale.eq|version=70}} || C ||
|-
| {{cmd|r.ros|version=70}} || T || RA
|-
| {{cmd|r.series|version=70}} || C ||
|-
| {{cmd|r.shaded.relief|version=70}} || C ||
|-
| {{cmd|r.sim.sediment|version=70}} || T || HY
|-
| {{cmd|r.sim.water|version=70}} || T || HY
|-
| {{cmd|r.slope.aspect|version=70}} || T || TA
|-
| {{cmd|r.solute.transport|version=70}} || T || HY
|-
| {{cmd|r.spread|version=70}} || T || RA
|-
| {{cmd|r.spreadpath|version=70}} || T || RA
|-
| {{cmd|r.statistics|version=70}} || C ||
|-
| {{cmd|r.statistics2|version=70}} || C ||
|-
| {{cmd|r.statistics3|version=70}} || C ||
|-
| {{cmd|r.stats|version=70}} || C ||
|-
| {{cmd|r.sun|version=70}} || T ||TA
|-
| {{cmd|r.sunmask|version=70}} || T || TA
|-
| {{cmd|r.support|version=70}} || C ||
|-
| {{cmd|r.support.stats|version=70}} || C ||
|-
| {{cmd|r.surf.area|version=70}} || T || TA
|-
| {{cmd|r.surf.contour|version=70}} || T || TA
|-
| {{cmd|r.surf.fractal|version=70}} || T || TA
|-
| {{cmd|r.surf.gauss|version=70}} || T || RA
|-
| {{cmd|r.surf.idw|version=70}} || T || RA
|-
| {{cmd|r.surf.idw2|version=70}} || T || RA
|-
| {{cmd|r.surf.random|version=70}} || T || RA
|-
| {{cmd|r.terraflow|version=70}} || T ||HY
|-
| {{cmd|r.texture|version=70}} || T || RA
|-
| {{cmd|r.thin|version=70}} || C ||
|-
| {{cmd|r.tileset|version=70}} || ? ||
|-
| {{cmd|r.timestamp|version=70}} || C ||
|-
| {{cmd|r.to.rast3|version=70}} || C ||
|-
| {{cmd|r.to.rast3elev|version=70}} || C ||
|-
| {{cmd|r.to.vect|version=70}} || C ||
|-
| {{cmd|r.topidx|version=70}} || T ||HY
|-
| {{cmd|r.topmodel|version=70}} || T ||HY
|-
| {{cmd|r.transect|version=70}} || T || RA
|-
| {{cmd|r.univar|version=70}} || C ||
|-
| {{cmd|r.uslek|version=70}} || T ||HY
|-
| {{cmd|r.usler|version=70}} || T ||HY
|-
| {{cmd|r.volume|version=70}} || T || RA
|-
| {{cmd|r.walk|version=70}} || T || TA
|-
| {{cmd|r.water.outlet|version=70}} || T|| HY
|-
| {{cmd|r.watershed|version=70}} || T || HY
|-
| {{cmd|r.what|version=70}} || C ||
|-
| {{cmd|r.what.color|version=70}} || C ||
|-
|}

=== 3D raster (voxel) ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|r3.cross.rast|version=70}} || T || 3D Raster
|-
| {{cmd|r3.gwflow|version=70}} || T || 3D Raster
|-
| {{cmd|r3.in.ascii|version=70}} || T || 3D Raster
|-
| {{cmd|r3.in.v5d|version=70}} || T || 3D Raster
|-
| {{cmd|r3.info|version=70}} || T || 3D Raster
|-
| {{cmd|r3.mapcalc|version=70}} || T || 3D Raster
|-
| {{cmd|r3.mask|version=70}} || T || 3D Raster
|-
| {{cmd|r3.mkdspf|version=70}} || T || 3D Raster
|-
| {{cmd|r3.null|version=70}} || T || 3D Raster
|-
| {{cmd|r3.out.ascii|version=70}} || T || 3D Raster
|-
| {{cmd|r3.out.v5d|version=70}} || T || 3D Raster
|-
| {{cmd|r3.out.vtk|version=70}} || T || 3D Raster
|-
| {{cmd|r3.stats|version=70}} || T || 3D Raster
|-
| {{cmd|r3.timestamp|version=70}} || T || 3D Raster
|-
| {{cmd|r3.to.rast|version=70}} || T || 3D Raster
|-
| {{cmd|r3.univar|version=70}} || T || 3D Raster
|-
|}

=== Vector ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|v.autokrige|version=70}} || ? ||
|-
| {{cmd|v.buffer|version=70}} || C ||
|-
| {{cmd|v.build|version=70}} || C ||
|-
| {{cmd|v.build.all|version=70}} || C ||
|-
| {{cmd|v.build.polylines|version=70}} || C ||
|-
| {{cmd|v.category|version=70}} || C ||
|-
| {{cmd|v.centroids|version=70}} || C ||
|-
| {{cmd|v.class|version=70}} || C ||
|-
| {{cmd|v.clean|version=70}} || C ||
|-
| {{cmd|v.colors|version=70}} || C ||
|-
| {{cmd|v.convert|version=70}} || T || IO
|-
| {{cmd|v.convert.all|version=70}} || T || IO
|-
| {{cmd|v.db.addcolumn|version=70}} || ? ||
|-
| {{cmd|v.db.addtable|version=70}} || ? ||
|-
| {{cmd|v.db.connect|version=70}} || ? ||
|-
| {{cmd|v.db.dropcolumn|version=70}} || ? ||
|-
| {{cmd|v.db.droprow|version=70}} || ? ||
|-
| {{cmd|v.db.droptable|version=70}} || ? ||
|-
| {{cmd|v.db.join|version=70}} || ? ||
|-
| {{cmd|v.db.reconnect.all|version=70}} || ? ||
|-
| {{cmd|v.db.renamecolumn|version=70}} || ? ||
|-
| {{cmd|v.db.select|version=70}} || ? ||
|-
| {{cmd|v.db.univar|version=70}} || ? ||
|-
| {{cmd|v.db.update|version=70}} || ? ||
|-
| {{cmd|v.delaunay|version=70}} || ? ||
|-
| {{cmd|v.dissolve|version=70}} || C ||
|-
| {{cmd|v.distance|version=70}} || ? ||
|-
| {{cmd|v.drape|version=70}} || ? ||
|-
| {{cmd|v.edit|version=70}} || C ||
|-
| {{cmd|v.external|version=70}} || C ||
|-
| {{cmd|v.extract|version=70}} || C ||
|-
| {{cmd|v.extrude|version=70}} || ? ||
|-
| {{cmd|v.generalize|version=70}} || ? ||
|-
| {{cmd|v.hull|version=70}} || ? ||
|-
| {{cmd|v.in.ascii|version=70}} || T || IO
|-
| {{cmd|v.in.db|version=70}} || C ||
|-
| {{cmd|v.in.dxf|version=70}} || T || IO
|-
| {{cmd|v.in.e00|version=70}} || T || IO
|-
| {{cmd|v.in.geonames|version=70}} || T || IO
|-
| {{cmd|v.in.gns|version=70}} || T || IO
|-
| {{cmd|v.in.lines|version=70}} || T || IO
|-
| {{cmd|v.in.mapgen|version=70}} || T || IO
|-
| {{cmd|v.in.ogr|version=70}} || C ||
|-
| {{cmd|v.in.postgis|version=70}} || T || IO
|-
| {{cmd|v.in.region|version=70}} || C ||
|-
| {{cmd|v.in.sites|version=70}} || T || IO
|-
| {{cmd|v.in.sites.all|version=70}} || T || IO
|-
| {{cmd|v.in.wfs|version=70}} || T || IO
|-
| {{cmd|v.info|version=70}} || C ||
|-
| {{cmd|v.kcv|version=70}} || ? ||
|-
| {{cmd|v.kernel|version=70}} || ? ||
|-
| {{cmd|v.krige|version=70}} || ? ||
|-
| {{cmd|v.label|version=70}} || ? ||
|-
| {{cmd|v.lidar.correction|version=70}} || ? ||
|-
| {{cmd|v.lidar.edgedetection|version=70}} || ? ||
|-
| {{cmd|v.lidar.growing|version=70}} || ? ||
|-
| {{cmd|v.lrs.create|version=70}} || ? ||
|-
| {{cmd|v.lrs.label|version=70}} || ? ||
|-
| {{cmd|v.lrs.segment|version=70}} || ? ||
|-
| {{cmd|v.lrs.where|version=70}} || ? ||
|-
| {{cmd|v.mkgrid|version=70}} || ? ||
|-
| {{cmd|v.neighbors|version=70}} || ? ||
|-
| {{cmd|v.net|version=70}} || ? ||
|-
| {{cmd|v.net.alloc|version=70}} || ? ||
|-
| {{cmd|v.net.allpairs|version=70}} || ? ||
|-
| {{cmd|v.net.bridge|version=70}} || ? ||
|-
| {{cmd|v.net.centrality|version=70}} || ? ||
|-
| {{cmd|v.net.components|version=70}} || ? ||
|-
| {{cmd|v.net.connectivity|version=70}} || ? ||
|-
| {{cmd|v.net.distance|version=70}} || ? ||
|-
| {{cmd|v.net.flow|version=70}} || ? ||
|-
| {{cmd|v.net.iso|version=70}} || ? ||
|-
| {{cmd|v.net.path|version=70}} || ? ||
|-
| {{cmd|v.net.salesman|version=70}} || ? ||
|-
| {{cmd|v.net.spanningtree|version=70}} || ? ||
|-
| {{cmd|v.net.steiner|version=70}} || ? ||
|-
| {{cmd|v.net.timetable|version=70}} || ? ||
|-
| {{cmd|v.net.visibility|version=70}} || ? ||
|-
| {{cmd|v.normal|version=70}} || ? ||
|-
| {{cmd|v.out.ascii|version=70}} || T || IO
|-
| {{cmd|v.out.dxf|version=70}} || T || IO
|-
| {{cmd|v.out.gps|version=70}} || T || IO
|-
| {{cmd|v.out.ogr|version=70}} || C ||
|-
| {{cmd|v.out.postgis|version=70}} || T || IO
|-
| {{cmd|v.out.pov|version=70}} || T || IO
|-
| {{cmd|v.out.svg|version=70}} || T || IO
|-
| {{cmd|v.out.vtk|version=70}} || T || IO
|-
| {{cmd|v.outlier|version=70}} || ? ||
|-
| {{cmd|v.overlay|version=70}} || ? ||
|-
| {{cmd|v.parallel|version=70}} || ? ||
|-
| {{cmd|v.patch|version=70}} || ? ||
|-
| {{cmd|v.perturb|version=70}} || ? ||
|-
| {{cmd|v.proj|version=70}} || C ||
|-
| {{cmd|v.qcount|version=70}} || ? ||
|-
| {{cmd|v.random|version=70}} || ? ||
|-
| {{cmd|v.rast.stats|version=70}} || ? ||
|-
| {{cmd|v.reclass|version=70}} || ? ||
|-
| {{cmd|v.report|version=70}} || ? ||
|-
| {{cmd|v.sample|version=70}} || ? ||
|-
| {{cmd|v.segment|version=70}} || ? ||
|-
| {{cmd|v.select|version=70}} || ? ||
|-
| {{cmd|v.split|version=70}} || ? ||
|-
| {{cmd|v.support|version=70}} || C ||
|-
| {{cmd|v.surf.bspline|version=70}} || ? ||
|-
| {{cmd|v.surf.idw|version=70}} || ? ||
|-
| {{cmd|v.surf.rst|version=70}} || ? ||
|-
| {{cmd|v.to.3d|version=70}} || ? ||
|-
| {{cmd|v.to.db|version=70}} || ? ||
|-
| {{cmd|v.to.points|version=70}} || ? ||
|-
| {{cmd|v.to.rast|version=70}} || ? ||
|-
| {{cmd|v.to.rast3|version=70}} || ? ||
|-
| {{cmd|v.transform|version=70}} || ? ||
|-
| {{cmd|v.type|version=70}} || ? ||
|-
| {{cmd|v.univar|version=70}} || ? ||
|-
| {{cmd|v.vol.rst|version=70}} || ? ||
|-
| {{cmd|v.voronoi|version=70}} || ? ||
|-
| {{cmd|v.what|version=70}} || ? ||
|-
| {{cmd|v.what.rast|version=70}} || ? ||
|-
| {{cmd|v.what.vect|version=70}} || ? ||
|-
|}

=== Various ===

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|nviz|version=70}} || ? ||
|-
| {{cmd|nviz_cmd|version=70}} || ? ||
|-
| {{cmd|wximgview|version=70}} || ? ||
|-
| {{cmd|wxpyimgview|version=70}} || ? ||
|-
| {{cmd|xganim|version=70}} || ? ||
|-
| {{cmd|ximgview|version=70}} || ? ||
|-
|}

== List of selected AddOns modules ==

See [[GRASS AddOns]] for full list of available modules. Feel free to extend this list.

{|class="wikitable sortable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)''' || '''Note'''
|-
| {{AddonCmd|r.stream.channel}} || T || HY || {{done}}
|-
| {{AddonCmd|r.stream.distance}} || T || HY || {{done}}
|-
| {{AddonCmd|r.stream.extract}} || T || HY || {{done}}
|-
| {{AddonCmd|r.stream.order}} || T || HY || {{done}}
|-
| {{AddonCmd|r.stream.segment}} || T || HY || {{done}}
|-
| {{AddonCmd|r.stream.slope}} || T || HY || {{done}}
|-
| {{AddonCmd|r.stream.snap}} || T || HY || {{done}}
|-
| {{AddonCmd|r.stream.stats}} || T || HY || {{done}}
|-
| {{AddonCmd|r.seg}} || T || IM || It could be rename to `i.seg`
|-
| {{AddonCmd|i.topocorr}} || T || IM ||
|-
| {{AddonCmd|r.diversity}} || T || LA ||
|-
| {{AddonCmd|Ps.output}} || ? || ||
|-
| ... || ? || ||
|-
|}

== How to implement ==

=== Proposal 1 ===
* add html tag <param> in the description.html with these options:
<param name = "core"> for core module
<param name = "tool" value="tool_code/codes"> for toolbox
<param name = "addons" [value="tool_code/codes"]> for addons, value is optional

* create a script to generate a xml file for each toolbox
* add toolbox option in g.extension to read the xml and install the modules

=== Proposal 2 ===

* modules (currently only [[Addons]]) are described (name, description, keywords, files) in metadata XML file called [http://grass.osgeo.org/addons/grass7/modules.xml modules.xml] - this file is auto-generated, see [http://trac.osgeo.org/grass/wiki/AddOnsManagement#AddOnsXMLfile trac page] for details
* similarly toolboxes are described (name, code, correlate modules, list of modules) in [http://grass.osgeo.org/addons/grass7/toolboxes.xml toolboxes.xml] - this file is manually manageable via [https://svn.osgeo.org/grass/grass-addons/grass7/toolboxes.xml SVN]

{{cmd|g.extension|version=70}} reads (from remote server http://grass.osgeo.org/addons/grass7) <tt>modules.xml</tt> when listing available modules (<tt>-l</tt>), and <tt>toolboxes.xml</tt> when listing available toolboxes (<tt>-lt</tt>). When installing toolbox using {{cmd|g.extension|version=70}} the module reads <tt>toolboxes.xml</tt> and installs in the loop given list of modules. When all modules are installed it also updates local metadata files - <tt>GRASS_ADDON_BASE/modules.xml</tt> and <tt>GRASS_ADDON_BASE/toolboxes.xml</tt>. These local metadata files are checked when listing locally installed toolboxes or single modules (<tt>-a</tt> or <tt>-ta</tt>).

=== Proposal 3 ===

Use a modified version of [http://pypi.python.org/pypi/pip pip] (a tool for installing and managing Python packages)

With Pip you can add/change repository, compile C/Fortran module, manage dependencies, install from some version control system (use
URLs like hg+http://domain/repo -- or prefix git+, svn+ etc), and using [http://pypi.python.org/pypi/virtualenv virtualenv]

[[Category:Development]]

GRASS SoC Ideas 2012

2012-04-13T21:31:12Z

⚠️Huhabla: /* Volume modeling */

<center>

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

* See also previous Google Summer of Code [[GRASS SoC Ideas 2011|ideas from 2011]].

* Visit the [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2012 main OSGeo Google Summer of Code 2012 @ OSGeo wiki page].

__TOC__
== About ==

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code 2012]. Here we will list project ideas and and other information related to the GRASS GSoC projects.

* [http://code.google.com/soc/ Official Google Summer of Code 2012 homepage]
* [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2012 OSGeo SoC 2012 homepage]

Promotion:

* Videos at http://code.google.com/p/google-summer-of-code/wiki/Videos
* More Flyers at http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers

== Timeline ==

* '''[http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs#timeline The official timeline]'''

== Required Steps ==

* '''List ideas'''

* Assign Mentors to Ideas

* Notify OSGeo

* Mentors evaluate student applications

* Accepted students announced

* Students subscribe to the [http://lists.osgeo.org/mailman/listinfo/grass-dev grass-dev mailing list] and introduce themselves

* Mentor will create directory structure in the [http://trac.osgeo.org/grass/browser/grass-addons GRASS add-ons SVN] for projects and setup access for students
** Students must read and post agreement to [http://grass.osgeo.org/programming7/rfc2_psc.html RFC2] to the [http://lists.osgeo.org/mailman/listinfo/grass-psc grass-psc mailing list] to gain SVN access
** Create a Wiki page for each accepted project, to be used as a progress reporting tool

* Coding begins...

* Students and mentors: Complete the Mid-term survey

* Final commit and packaging for Google

== Ideas ==

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

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

=== [[wxGUI]] ===

# Develop GUI support in wxPython for visualy analyzing series of raster map layers. The module should provide users with capabilities to browse and animate raster (and potentially also vector) data series in a 2D display and save outputs to animated GIF, MOV, or MPEG files. A related module that displays the series as small images and support re-ordering, deleting and adding raster maps (frames) to the series would also be helpful. To compare visually two images a slider functionality could be added to the 2D display, for example, to compare before and after images, or two consequent images in series. The series of data layers can be handled as multiple standard raster or vector layers or using the new time series support. See existing modules {{cmd|xganim}}, {{cmd|r.out.mpeg}}, [[NVIZ]]'s animation tools, and the [[Movies]] creation wiki page. There is also a related capability in the TclTk GUI. (co-mentor Helena Mitasova).
# Develop an interactive vector geometry selection and export tool for [[wxGUI]] as described in the trac ticket [http://trac.osgeo.org/grass/ticket/1471 #1471]
# Offer also (optional) "conventional" '''GUI layout''': For some users, the current approach of separate windows (SDI) leads to a '''windows flooding'''. This is a common complaint especially from newbies. Especially on large monitors or dual screen systems catching the [[wxGUI]] windows can be tedious when they appear on separate monitors (depends on windows manager, the much used KDE scatters typically the wxGUI windows all over the screen real estate). Almost each task generates a new wxGUI window which is freely floating around on the screen: [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-03.png example 1] and [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-01.png example 2]. On a dual-screen this may sum up to 50cm of distance! The idea is to capture all those windows in one frame. For details, see [[wxGUI#Layout| wxGUI layout]].
<center>
<gallery widths=400 heights=250>
Image:Wxgui_current.png|Current wxGUI layout with detached window components
Image:Wxgui_proposal.png|Proposal for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)
</gallery>
</center>
# ''Your idea here''

'''Willing to Mentor:''' [[User:Landa|Martin Landa]], [[User:MarisN|Maris Nartiss]], [[User:Mmetz|Markus Metz]], (''your name here'')

=== Raster ===

#Add '''[[OpenMP]] parallelization''' where appropriate, for example {{cmd|r.cost}}, {{cmd|r.surf.contour}}, {{cmd|r.watershed}}. It is important to understand which modules are processor bound, and concentrate on them. i.e. do not needlessly complicate the code of non-long running processor bound modules. A good working knowledge of ANSI C and {{wikipedia|OpenMP}} is required. ({{wikipedia|OpenCL}} and {{wikipedia|pthreads}} are fine too!)
#Create a new GRASS module to find the {{wikipedia|topographic_prominence}} of peaks from a raster elevation map within the region. (probably this would only make up 1/4 to 1/2 of a multi-part GSoC project)
# Expand maximum grid size for {{cmd|r.watershed}}. [[LIDAR]]-based elevation grids are at finer resolution than previous elevation models, often overwhelming the integer variable limit for grid size.
# ''Your suggestion here!''

'''Willing to Mentor:''' Hamish (co-mentor parallelization and prominence projects), Wolf Bergenheim(''your name here'')

=== Vector ===

# Add '''[[OpenMP]] parallelization''' where appropriate, for example, {{cmd|v.surf.rst}} and {{cmd|v.vol.rst}} ''(co-mentor Helena Mitasova)''. (OpenCL and pthreads are fine too!) See above idea in the [[GRASS SoC Ideas 2012#Raster|Raster section]].
# Better '''support for wrap-around at 180 longitude''': Currently the raster engine is pretty good at wrapping data over 180 longitude. The vector data isn't, but it should be. This is a great task if by the end of the summer you'd like to be familiar with the implementation method of an entire vector stack of a fully featured modern GIS.
# Add '''break lines support to interpolation modules''' ({{cmd|v.surf.rst}}, {{cmd|v.surf.idw}}, {{cmd|v.surf.bspline}}). Current implementations provide no support to specify locations of cliffs or faults* thus leading to improper results within non-continous datasets. See [http://www.spatialanalysisonline.com/output/html/Breaklinesandnaturalboundaries.html Geospatial Analysis - a comprehensive guide. 3rd edition] for description. [*] well, some support exists, see {{AddonCmd|v.surf.icw}}.
# Speed up [[wxGUI]] handling and 2D display of large point clouds (several million points). This is likely to include additional "Level-1 Vector" support in the backend modules (for which a working knowledge of ANSI C is req'd).
# ''Your idea here'' ...

'''Willing to Mentor:''' [[User:Landa|Martin Landa]], [[User:Mmetz|Markus Metz]], Hamish (co-mentor for parallelization), Wolf Bergenheim, (''your name here'')

=== Imagery ===

# GRASS's imagery modules (for satellite, scanned maps, and orthophotos) act as enhanced raster modules. In GRASS 5 and 6 they were mostly implemented using interactive X-monitors which are not available in MS Windows and so are removed in the new cross-platform code of GRASS 7.
#* We need someone willing to '''port the old modules to work with GRASS 7''', including writing new '''wxPython GUI frontends''' to a number of existing tools and updating the imagery libraries to current raster library standards.
#* In addition, there are a number of '''improved/automated georectification tools''' which have not been merged into GRASS 5/6 which it would be nice to have updated and merged into the main code.
# Implement '''[[OpenMP]] (multithreading)''' as much as possible (where appropriate; OpenCL and pthreads are fine too)
# In addition to the porting of the georectification tools mentioned above, it would be interesting to implement an orthorectification tool for satellite imagery. Currently, GRASS only has {{cmd|i.ortho.photo}} for aerial photographs.
# Implement image segmentation algorithms and tools
# Implement region-based classification
# Implement hierarchical classification tools (e.g. being able to create a large class "forest", with subclasses of different types of forests)
# ''Your idea here''

See the [[Image_processing#Ideas_collection_for_improving_GRASS.27_Image_processing_capabilities|ideas for imagery improvement]] and [http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib GRASS 7 ideas] wiki pages for more details.

'''Willing to Mentor:''' Hamish (co-mentor for parallelization), Markus Metz (orthorectification), (''your name here'')

=== Cartography and display ===

# Add SVG (and perhaps EPS) support to the display library, for use via {{cmd|d.graph}} and/or {{cmd|d.vect}}, and add SVG support to {{cmd|ps.map}} via a SVG to EPS converter tool (probably by adapting an existing GPL-compatible library). Code to be written in ANSI C. Step 1 is adding a Bézier curve rendering library function.
# Integrate Quantum/GRASS SVG output plugin with Inkscape. Python can serve as a common glue between these tools. The project would facilitate easy cartographic workflow while utilizing the advanced design functionality of Inkscape. This would be a two way bridge:
## QGIS/GRASS plugins to invoke an Inkscape process and send a data set.
## Inkscape plugin to query various OSGeo projects and display various data sets as layers.
# ''Your idea here ...''

'''Willing to Mentor:''' Hamish (as a co-mentor)

=== 3D visualization ===

# Optimize OGSF (and NVIZ/wxNVIZ) to '''display large 3D point clouds with uninterupted tought speed'''. OGSF + (wx)NVIZ should be able to rotate point cloud (i.e. LiDAR dataset) with 4 millions of points on medium hardware (i.e. 2GHz CPU with 2Gb RAM and GPU with hardware transform and lighting support and dedicated video RAM) with response time not greater than 1.0 second.
# Design and implement '''text displaying and styling in OGSF library''' and it's front-ends (NVIZ, [[wxNVIZ]]). Solution should be user configurable (fonts, colors, effects etc.) and multilanguage friendly.
# Design and implement user-provided '''symbol support in OGSF library''' and it's front-ends (NVIZ, [[wxNVIZ]]). Solution should support GRASS symbols, SVG, and/or simple EPS symbols.

# Drape multiple color maps over topography (equivalent to running r.patch or r.composite and draping the result; second raster is currently supported as transparency).
# Improve handling of z-exageration so that z-exag=1 is a realistic representation of landscape in terms of vertical scaling. Other default settings could also be improved to support wider range of data and improve robustness.

'''Willing to Mentor:''' [[User:Landa|Martin Landa]] (for 2), co-mentor for 1 and 5: Helena Mitasova, (''your name here'')

=== Volume modeling ===

# Develop '''r3.flow''' for computing 3D flow lines and 3D flow accumulation from 3D rasters
# Enhance volume interpolation module '''{{cmd|v.vol.rst}}''' for handling of data in space-time cube, including computation of gradients and hypercurvatures

'''Willing to Mentor:''' co-mentor Helena Mitasova, [[User:Huhabla|Sören Gebbert]]

=== Improved Python interface ===

Design '''sophisticated Python scripting interface''' for GRASS based on [http://grass.osgeo.org/programming7/pythonlib.html GRASS Python Scripting Library]. This API should become more intuitive and more integrative

GRASS GIS would gain even more attractiveness!

'''Willing to Mentor:''' [[User:Huhabla|Sören Gebbert]]

=== Other ===

* See also the [https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&type=enhancement GRASS wish list]

# Implement selected modules (in C/C++) for geospatial analysis (kriging, etc.) based on [http://hpgl.aoizora.org/ HPGL] library (see also [http://hub.qgis.org/projects/quantum-gis/wiki/Python_Plugin_Ideas#Add-and-R-Free-geostatistic-toolbox-using-HPGL QGIS plugin wish]).
# Design and implement modern '''metadata management system''' for GRASS to support [http://www.opengeospatial.org/standards/cat OGC CSW] and INSPIRE discovery a view services

# ''Your idea here''

'''Willing to Mentor:''' Wolf Bergenheim (Python API, metadata management), [[User:Landa|Martin Landa]] (for HPGL) (''your name here'')

== Guidelines for Students ==

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing our [http://lists.osgeo.org/mailman/listinfo/grass-dev dev-mailing list], or come and talk to us in [[IRC]] (#grass). You can also reach the mentors directly by emailing:
* [http://lists.osgeo.org/mailman/listinfo/soc The OSGeo SoC mailing list]



* If you are thinking about applying, do make a point of reading the "[http://google-opensource.blogspot.co.nz/2011/02/flip-bits-not-burgers-student-guide.html Flip bits not Burgers: The Student's Guide to the Summer of Code]" eBook

=== Getting started with GRASS coding ===

* The source code is maintained in a [http://trac.osgeo.org/grass/browser/grass/trunk SVN server] which is easy to browse

* Please review the submitting files for our coding standards
** {{src|SUBMITTING|branch=trunk}} for C coding rules
** {{src|SUBMITTING_PYTHON|branch=trunk}} for Python coding rules
** {{src|SUBMITTING_DOCS|branch=trunk}} for Documentantion coding rules

* There is lots of good info at the [http://trac.osgeo.org/grass/wiki GRASS Developer's wiki]
: See also the [[Development|development section]] of the GRASS user's wiki

== Guidelines for Mentors ==

* Un(?)official book: http://www.booki.cc/gsoc-mentoring/
* Some more hints on the [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2012_Administrative#Links OSGeo wiki]

== Accepted Ideas ==

# ''Project name''
#: Student: Your name here
#: Mentor: Your mentor's name here
#: Backup mentor: Your backup mentor's name here
#: Wiki page: wiki page maintained by you (typically in this GRASS wiki, or the trac development wiki)
# ''Project name''
#: Student: Someone else's name here
#: Mentor: Their mentor's name here
#: Backup mentor: Their backup mentor's name here
#: Wiki page: wiki page maintained by them (typically in this GRASS wiki, or the trac development wiki)

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

GRASS SoC Ideas 2012

2012-04-13T21:01:37Z

⚠️Huhabla: /* Improved Python interface */

<center>

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

* See also previous Google Summer of Code [[GRASS SoC Ideas 2011|ideas from 2011]].

* Visit the [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2012 main OSGeo Google Summer of Code 2012 @ OSGeo wiki page].

__TOC__
== About ==

This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code 2012]. Here we will list project ideas and and other information related to the GRASS GSoC projects.

* [http://code.google.com/soc/ Official Google Summer of Code 2012 homepage]
* [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2012 OSGeo SoC 2012 homepage]

Promotion:

* Videos at http://code.google.com/p/google-summer-of-code/wiki/Videos
* More Flyers at http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers

== Timeline ==

* '''[http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs#timeline The official timeline]'''

== Required Steps ==

* '''List ideas'''

* Assign Mentors to Ideas

* Notify OSGeo

* Mentors evaluate student applications

* Accepted students announced

* Students subscribe to the [http://lists.osgeo.org/mailman/listinfo/grass-dev grass-dev mailing list] and introduce themselves

* Mentor will create directory structure in the [http://trac.osgeo.org/grass/browser/grass-addons GRASS add-ons SVN] for projects and setup access for students
** Students must read and post agreement to [http://grass.osgeo.org/programming7/rfc2_psc.html RFC2] to the [http://lists.osgeo.org/mailman/listinfo/grass-psc grass-psc mailing list] to gain SVN access
** Create a Wiki page for each accepted project, to be used as a progress reporting tool

* Coding begins...

* Students and mentors: Complete the Mid-term survey

* Final commit and packaging for Google

== Ideas ==

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

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

=== [[wxGUI]] ===

# Develop GUI support in wxPython for visualy analyzing series of raster map layers. The module should provide users with capabilities to browse and animate raster (and potentially also vector) data series in a 2D display and save outputs to animated GIF, MOV, or MPEG files. A related module that displays the series as small images and support re-ordering, deleting and adding raster maps (frames) to the series would also be helpful. To compare visually two images a slider functionality could be added to the 2D display, for example, to compare before and after images, or two consequent images in series. The series of data layers can be handled as multiple standard raster or vector layers or using the new time series support. See existing modules {{cmd|xganim}}, {{cmd|r.out.mpeg}}, [[NVIZ]]'s animation tools, and the [[Movies]] creation wiki page. There is also a related capability in the TclTk GUI. (co-mentor Helena Mitasova).
# Develop an interactive vector geometry selection and export tool for [[wxGUI]] as described in the trac ticket [http://trac.osgeo.org/grass/ticket/1471 #1471]
# Offer also (optional) "conventional" '''GUI layout''': For some users, the current approach of separate windows (SDI) leads to a '''windows flooding'''. This is a common complaint especially from newbies. Especially on large monitors or dual screen systems catching the [[wxGUI]] windows can be tedious when they appear on separate monitors (depends on windows manager, the much used KDE scatters typically the wxGUI windows all over the screen real estate). Almost each task generates a new wxGUI window which is freely floating around on the screen: [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-03.png example 1] and [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-01.png example 2]. On a dual-screen this may sum up to 50cm of distance! The idea is to capture all those windows in one frame. For details, see [[wxGUI#Layout| wxGUI layout]].
<center>
<gallery widths=400 heights=250>
Image:Wxgui_current.png|Current wxGUI layout with detached window components
Image:Wxgui_proposal.png|Proposal for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)
</gallery>
</center>
# ''Your idea here''

'''Willing to Mentor:''' [[User:Landa|Martin Landa]], [[User:MarisN|Maris Nartiss]], [[User:Mmetz|Markus Metz]], (''your name here'')

=== Raster ===

#Add '''[[OpenMP]] parallelization''' where appropriate, for example {{cmd|r.cost}}, {{cmd|r.surf.contour}}, {{cmd|r.watershed}}. It is important to understand which modules are processor bound, and concentrate on them. i.e. do not needlessly complicate the code of non-long running processor bound modules. A good working knowledge of ANSI C and {{wikipedia|OpenMP}} is required. ({{wikipedia|OpenCL}} and {{wikipedia|pthreads}} are fine too!)
#Create a new GRASS module to find the {{wikipedia|topographic_prominence}} of peaks from a raster elevation map within the region. (probably this would only make up 1/4 to 1/2 of a multi-part GSoC project)
# Expand maximum grid size for {{cmd|r.watershed}}. [[LIDAR]]-based elevation grids are at finer resolution than previous elevation models, often overwhelming the integer variable limit for grid size.
# ''Your suggestion here!''

'''Willing to Mentor:''' Hamish (co-mentor parallelization and prominence projects), Wolf Bergenheim(''your name here'')

=== Vector ===

# Add '''[[OpenMP]] parallelization''' where appropriate, for example, {{cmd|v.surf.rst}} and {{cmd|v.vol.rst}} ''(co-mentor Helena Mitasova)''. (OpenCL and pthreads are fine too!) See above idea in the [[GRASS SoC Ideas 2012#Raster|Raster section]].
# Better '''support for wrap-around at 180 longitude''': Currently the raster engine is pretty good at wrapping data over 180 longitude. The vector data isn't, but it should be. This is a great task if by the end of the summer you'd like to be familiar with the implementation method of an entire vector stack of a fully featured modern GIS.
# Add '''break lines support to interpolation modules''' ({{cmd|v.surf.rst}}, {{cmd|v.surf.idw}}, {{cmd|v.surf.bspline}}). Current implementations provide no support to specify locations of cliffs or faults* thus leading to improper results within non-continous datasets. See [http://www.spatialanalysisonline.com/output/html/Breaklinesandnaturalboundaries.html Geospatial Analysis - a comprehensive guide. 3rd edition] for description. [*] well, some support exists, see {{AddonCmd|v.surf.icw}}.
# Speed up [[wxGUI]] handling and 2D display of large point clouds (several million points). This is likely to include additional "Level-1 Vector" support in the backend modules (for which a working knowledge of ANSI C is req'd).
# ''Your idea here'' ...

'''Willing to Mentor:''' [[User:Landa|Martin Landa]], [[User:Mmetz|Markus Metz]], Hamish (co-mentor for parallelization), Wolf Bergenheim, (''your name here'')

=== Imagery ===

# GRASS's imagery modules (for satellite, scanned maps, and orthophotos) act as enhanced raster modules. In GRASS 5 and 6 they were mostly implemented using interactive X-monitors which are not available in MS Windows and so are removed in the new cross-platform code of GRASS 7.
#* We need someone willing to '''port the old modules to work with GRASS 7''', including writing new '''wxPython GUI frontends''' to a number of existing tools and updating the imagery libraries to current raster library standards.
#* In addition, there are a number of '''improved/automated georectification tools''' which have not been merged into GRASS 5/6 which it would be nice to have updated and merged into the main code.
# Implement '''[[OpenMP]] (multithreading)''' as much as possible (where appropriate; OpenCL and pthreads are fine too)
# In addition to the porting of the georectification tools mentioned above, it would be interesting to implement an orthorectification tool for satellite imagery. Currently, GRASS only has {{cmd|i.ortho.photo}} for aerial photographs.
# Implement image segmentation algorithms and tools
# Implement region-based classification
# Implement hierarchical classification tools (e.g. being able to create a large class "forest", with subclasses of different types of forests)
# ''Your idea here''

See the [[Image_processing#Ideas_collection_for_improving_GRASS.27_Image_processing_capabilities|ideas for imagery improvement]] and [http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib GRASS 7 ideas] wiki pages for more details.

'''Willing to Mentor:''' Hamish (co-mentor for parallelization), Markus Metz (orthorectification), (''your name here'')

=== Cartography and display ===

# Add SVG (and perhaps EPS) support to the display library, for use via {{cmd|d.graph}} and/or {{cmd|d.vect}}, and add SVG support to {{cmd|ps.map}} via a SVG to EPS converter tool (probably by adapting an existing GPL-compatible library). Code to be written in ANSI C. Step 1 is adding a Bézier curve rendering library function.
# Integrate Quantum/GRASS SVG output plugin with Inkscape. Python can serve as a common glue between these tools. The project would facilitate easy cartographic workflow while utilizing the advanced design functionality of Inkscape. This would be a two way bridge:
## QGIS/GRASS plugins to invoke an Inkscape process and send a data set.
## Inkscape plugin to query various OSGeo projects and display various data sets as layers.
# ''Your idea here ...''

'''Willing to Mentor:''' Hamish (as a co-mentor)

=== 3D visualization ===

# Optimize OGSF (and NVIZ/wxNVIZ) to '''display large 3D point clouds with uninterupted tought speed'''. OGSF + (wx)NVIZ should be able to rotate point cloud (i.e. LiDAR dataset) with 4 millions of points on medium hardware (i.e. 2GHz CPU with 2Gb RAM and GPU with hardware transform and lighting support and dedicated video RAM) with response time not greater than 1.0 second.
# Design and implement '''text displaying and styling in OGSF library''' and it's front-ends (NVIZ, [[wxNVIZ]]). Solution should be user configurable (fonts, colors, effects etc.) and multilanguage friendly.
# Design and implement user-provided '''symbol support in OGSF library''' and it's front-ends (NVIZ, [[wxNVIZ]]). Solution should support GRASS symbols, SVG, and/or simple EPS symbols.

# Drape multiple color maps over topography (equivalent to running r.patch or r.composite and draping the result; second raster is currently supported as transparency).
# Improve handling of z-exageration so that z-exag=1 is a realistic representation of landscape in terms of vertical scaling. Other default settings could also be improved to support wider range of data and improve robustness.

'''Willing to Mentor:''' [[User:Landa|Martin Landa]] (for 2), co-mentor for 1 and 5: Helena Mitasova, (''your name here'')

=== Volume modeling ===

# Develop '''r3.flow''' for computing 3D flow lines and 3D flow accumulation from 3D rasters
# Enhance volume interpolation module '''{{cmd|v.vol.rst}}''' for handling of data in space-time cube, including computation of gradients and hypercurvatures

'''Willing to Mentor:''' co-mentor Helena Mitasova, (''your name here'')

=== Improved Python interface ===

Design '''sophisticated Python scripting interface''' for GRASS based on [http://grass.osgeo.org/programming7/pythonlib.html GRASS Python Scripting Library]. This API should become more intuitive and more integrative

GRASS GIS would gain even more attractiveness!

'''Willing to Mentor:''' [[User:Huhabla|Sören Gebbert]]

=== Other ===

* See also the [https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&type=enhancement GRASS wish list]

# Implement selected modules (in C/C++) for geospatial analysis (kriging, etc.) based on [http://hpgl.aoizora.org/ HPGL] library (see also [http://hub.qgis.org/projects/quantum-gis/wiki/Python_Plugin_Ideas#Add-and-R-Free-geostatistic-toolbox-using-HPGL QGIS plugin wish]).
# Design and implement modern '''metadata management system''' for GRASS to support [http://www.opengeospatial.org/standards/cat OGC CSW] and INSPIRE discovery a view services

# ''Your idea here''

'''Willing to Mentor:''' Wolf Bergenheim (Python API, metadata management), [[User:Landa|Martin Landa]] (for HPGL) (''your name here'')

== Guidelines for Students ==

How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing our [http://lists.osgeo.org/mailman/listinfo/grass-dev dev-mailing list], or come and talk to us in [[IRC]] (#grass). You can also reach the mentors directly by emailing:
* [http://lists.osgeo.org/mailman/listinfo/soc The OSGeo SoC mailing list]



* If you are thinking about applying, do make a point of reading the "[http://google-opensource.blogspot.co.nz/2011/02/flip-bits-not-burgers-student-guide.html Flip bits not Burgers: The Student's Guide to the Summer of Code]" eBook

=== Getting started with GRASS coding ===

* The source code is maintained in a [http://trac.osgeo.org/grass/browser/grass/trunk SVN server] which is easy to browse

* Please review the submitting files for our coding standards
** {{src|SUBMITTING|branch=trunk}} for C coding rules
** {{src|SUBMITTING_PYTHON|branch=trunk}} for Python coding rules
** {{src|SUBMITTING_DOCS|branch=trunk}} for Documentantion coding rules

* There is lots of good info at the [http://trac.osgeo.org/grass/wiki GRASS Developer's wiki]
: See also the [[Development|development section]] of the GRASS user's wiki

== Guidelines for Mentors ==

* Un(?)official book: http://www.booki.cc/gsoc-mentoring/
* Some more hints on the [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2012_Administrative#Links OSGeo wiki]

== Accepted Ideas ==

# ''Project name''
#: Student: Your name here
#: Mentor: Your mentor's name here
#: Backup mentor: Your backup mentor's name here
#: Wiki page: wiki page maintained by you (typically in this GRASS wiki, or the trac development wiki)
# ''Project name''
#: Student: Someone else's name here
#: Mentor: Their mentor's name here
#: Backup mentor: Their backup mentor's name here
#: Wiki page: wiki page maintained by them (typically in this GRASS wiki, or the trac development wiki)

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

GRASS Community Sprint Prague 2012

2012-04-13T18:56:16Z

⚠️Huhabla: /* In person */

Python Ctypes Examples

2012-04-07T15:26:24Z

⚠️Huhabla: /* Raster */

See [[GRASS and Python]] for more information. See also [http://trac.osgeo.org/grass/browser/grass/trunk/doc/python/raster_example_ctypes.py raster], [http://trac.osgeo.org/grass/browser/grass/trunk/doc/python/vector_example_ctypes.py vector] sample scripts.
__TOC__
== Raster ==

=== Working with (geographic) coordinates for each raster cell and the computational region ===

The ctypes interfaces are thin wrappers around the corresponding C
functions. Any script which uses them should have essentially the same
structure as a module written in C. Structures can be allocated by
using the structure name as a function, and passed by reference using
[http://docs.python.org/library/ctypes.html ctypes]' byref() function.

The second argument to G_col_to_easting() and G_row_to_northing() is a
"const struct Cell_head *". The information can be obtained from
G_get_window(), e.g.:

<source lang="python">
import sys
import grass.lib.gis as gis
from ctypes import *

gis.G_gisinit(sys.argv[0])

region = gis.Cell_head()
G_get_window(byref(region))
coor_col = gis.G_col_to_easting((thecolumn + 0.5), byref(region))
coor_row = gis.G_row_to_northing((therow + 0.5), byref(region))
</source>

=== Basic raster metadata access methods ===

This is a simple demonstration script to show the ctypes style access to some of the raster metadata.

<source lang="python">
from ctypes import *
import grass.lib.gis as libgis
import grass.lib.raster as libraster

import grass.script as grass
import grass.temporal as tgis

def print_raster_info(name):

grass.run_command("r.mapcalc", expr=name + " = 5.0", overwrite=True)
grass.run_command("r.timestamp", map=name, date="13 Jan 2003 / 15 Jan 2003")

# Create a region struct
region = libgis.Cell_head()

# Read the raster region
libraster.Rast_get_cellhd("test", "", byref(region))
print region.cols
print region.rows
print region.north
print region.south
print region.east
print region.west
print region.ns_res
print region.ew_res
print region.top
print region.bottom
print region.tb_res
print region.depths
print region.proj

# Get Map type
maptype = libraster.Rast_map_type(name, "")

if maptype == libraster.DCELL_TYPE:
print "DCELL"
elif maptype == libraster.FCELL_TYPE:
print "FCELL"
elif maptype == libraster.CELL_TYPE:
print "CELL"
else:
print "Unknown type"

# Read range
if libraster.Rast_map_is_fp(name, ""):
print "Floating point map"
range = libraster.FPRange()
libraster.Rast_read_fp_range(name, "", byref(range))
min = libgis.DCELL()
max = libgis.DCELL()
libraster.Rast_get_fp_range_min_max(byref(range), byref(min), byref(max))
else:
print "Cell map"
range = libraster.Range()
libraster.Rast_read_range(name, "", byref(range))
min = libgis.CELL()
max = libgis.CELL()
libraster.Rast_get_fp_range_min_max(byref(range), byref(min), byref(max))

minimum = min.value
maximum = max.value
print minimum
print maximum

# Read time stamp
tstmp = libgis.TimeStamp()
libgis.G_read_raster_timestamp(name, "", byref(tstmp))

print tstmp.count

dt1 = tstmp.dt[0]
dt2 = tstmp.dt[1]

if tstmp.count >= 1:
print dt1.mode
print dt1.year
print dt1.month
print dt1.day
print dt1.hour
print dt1.minute
print dt1.second
if tstmp.count > 1:
print dt2.mode
print dt2.year
print dt2.month
print dt2.day
print dt2.hour
print dt2.minute
print dt2.second

if __name__ == "__main__":
print_raster_info("test")
</source>

== Vector ==

=== Accessing feature geometry ===

This script switches X, Y coordinates and multiple them by -1.

<source lang="python">
#!/usr/bin/python

import sys

from grass.lib.vector import *

if len(sys.argv) < 2:
sys.exit("Usage: %s: vector" % sys.argv[0])

name = sys.argv[1]

map_info = pointer(Map_info())
points = Vect_new_line_struct()
cats = Vect_new_cats_struct()
c_points = points.contents

level = Vect_open_update(map_info, name, "")
if level < 2:
sys.exit("Topology not available")

nlines = Vect_get_num_lines(map_info)

for line in range(1, nlines + 1):
ltype = Vect_read_line(map_info, points, cats, line)
if line % 100 == 0:
sys.stderr.write("\r%d" % line)

for i in range(c_points.n_points):
x = c_points.x[i]
c_points.x[i] = -1 * c_points.y[i]
c_points.y[i] = -1 * x

Vect_rewrite_line(map_info, line, ltype,
points, cats)
line += 1

sys.stderr.write("\r")

Vect_destroy_line_struct(points)
Vect_destroy_cats_struct(cats)

Vect_build_partial(map_info, GV_BUILD_NONE)
Vect_build(map_info)
Vect_close(map_info)
</source>

== See also ==

* http://docs.python.org/library/ctypes.html

{{Python}}

GRASS Community

2011-10-24T13:45:46Z

⚠️Huhabla: /* GRASS Add-on modules */

__TOC__

== About the project ==

=== Freedom ===

The GRASS GIS project is developed under the terms of the [http://www.gnu.org/copyleft/gpl.html GNU General Public License] (the GPL) [http://grass.ibiblio.org/devel/index.php in the open] by [http://grass.ibiblio.org/community/index.php volunteers] the [http://mapserver.gdf-hannover.de/grassusers/map.phtml world over].

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

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

* [[Gis_Concepts#How_the_Open_Source_software_development_model_works|How the Open Source software development model works]]

* [http://en.wikipedia.org/wiki/Gpl WikiPedia entry discussing the GPL]

=== The GRASS Community and the Development Team ===

* [http://grass.ibiblio.org/community/index.php The Community]
* [http://grass.ibiblio.org/community/team.php The Development Team]
* [[GRASS_Translation_Team|The Translation Team]]
* [[PSC|The GRASS Project Steering Commitee]]

=== User Map ===
* [http://mapserver.gdf-hannover.de/grassusers/map.phtml?winwidth=890&winheight=630&language=1&mapwidth=600&mapheight=400 GRASS User Map]
* Description of new [[GRASS UserMap]]

=== Open Source Geospatial Foundation (OSGeo) ===
* The new [http://www.osgeo.org/ Open Source Geospatial Foundation] (OSGeo.org) was established in Chicago. GRASS was proposed as founding project.
* [[Potential tasks and responsibilities]] (earlier proposal)
* [[GRASS Project Steering Commitee]] for the OSGeo Foundation
* [[GRASS Project Incubation]] at the OSGeo Foundation
* http://grass.osgeo.org/

=== Other Free GIS projects ===

* [http://freegis.org FreeGIS.org]
* [http://pkg-grass.alioth.debian.org/cgi-bin/wiki.pl The DebianGIS Project]

== Getting Help ==

=== Mailing lists ===

* The primary point of contact for GRASS user help and development coordination is on the [http://grass.ibiblio.org/community/support.php mailing lists]. The answers to many questions you may have will probably already have been addressed and will be waiting for you in the [http://grass.ibiblio.org/searchgrass.php mailing list archives].

* Because the mailing lists are so critical to the project's success, and support comes entirely from time-strapped volunteers and colleagues, we request some [[mailing list etiquette]] be followed.

=== IRC communication ===

IRC is live Internet Relay Chat. The GRASS project maintains a "chatroom" and if you are lucky there may be someone logged on who can give you a quick answer.

* [[How to participate in IRC communication]] (#grass, #osgeo, #gdal, #qgis, #mapserver and other channels)

=== Documentation ===

* You've already discovered the wiki. Go forth and explore!

== Community resources ==

=== GRASS education (Free GIS education) ===

The GRASS education (Free GIS education) wiki site offers a start to collect links, text documents and small images. Furthermore it provides a discussion platform to develop and collect approaches, techniques, exercises and course structures for people giving GRASS and/or other Free GIS courses.

* [[GRASS_Education_(Free_GIS_education) | GRASS education (Free GIS education)]]

=== Promoting GRASS GIS ===

* [[GRASS promotion team]]
* [[Promotional material]]
* [[GRASS migration hints]]
* [[GRASS Propaganda]]

=== Conferences ===
* [http://www.foss4g2007.org FOSS4G2007 - Free and Open Source Software for Geospatial 2007] Victoria, Canada September 24-27, 2007
* [http://www.foss4g2006.org/ FOSS4G2006 - Open Source Geospatial Communities Joint Conference] 12-15 September 2006 in Lausanne, Switzerland with GRASS workshops...
* [[GRASS related workshops and presentations]]

=== Seminars and Courses ===
* [[U.S. NOAA/National Weather Service GRASS GIS Workshop - Ohio River Forecast Center, Wilmington, OH, May 16-20, 2011]]

=== GRASS Add-on modules ===

* [[GRASS AddOns]] software contributed by the community

[[Category: Community]]

Test Suite

2011-07-05T09:51:18Z

⚠️Huhabla: /* Main picture */

__TOC__

= GRASS Test Suite =

We aim at creating a comprehensive test suite for GRASS modules and libraries.

== Background ==

See what has been done so far by Sören Gebbert and others here: [[Development#QA]] and the good [[http://www.vtk.org/Wiki/images/b/bc/Testing.cover.txt | VKT test suite]]

Keep an eye on [[GRASS_7_ideas_collection#Complete_GRASS_Test_Suite:_see_activity_on_Test_Suite_development_page | GRASS 7 ideas collection]]

== Main picture ==

We plan to run unittests and integration tests for both libraries and modules. The test suite will be run after compilation, with a command like:

$ make tests [ proj ]

Options:
* proj: run the tests with a [list of] CRS, so that reprojection and map unit handling are tested.
* ...

Tests are executed recursively. If the "make tests" command is executed in the root source folder all libraries and modules are tested. To test only the libraries you need to switch in the '''lib''' directory and execute "make tests". If you want to test only raster modules switch into the '''raster''' directory and run "make tests", same for other modules directories. To test a single module switch into the module directory and run "make tests".

Testing should work in parallel, so that make -j6 tests will execute as maximum 6 tests in parallel. The framework should take care that parallel testing test runs can be performed.

== Tests ==

=== Modules ===
Tests are targeted to cover all modules as well as library test modules.

The modules tests should as independent as possible from other GRASS modules.

Tests are written as simple shell script with annotations. Test script should start with '''test.''' followed by the module name i.e. '''r.mapcalc.''' and further ending with '''.sh'''. Example '''test.r.mapcalc.1.sh'''. All test should be well documented using shell comments.

The framework will execute all test scripts starting with '''test.''' and ending with '''.sh''' located in module or library directories.

Annotations are integrated in the test documentation (simple shell comments) and specify pre-processing steps, the tests and the type of the data to validate. The following annotations should be supported:

* The '''@preprocess''' annotation
** All commands below this annotation are handled as preprocessing steps for the tests.
** If any of the preprocess commands fail, the framework should stop testing an create a detailed error report.
** Preprocessing steps may be data generation, region settings and so on.
** The preprocess annotation is valid till a '''@test''' annotation specifies the begin of a test
** Preprocess annotations can be specified at between tests
* The '''@test''' annotation
** All command below a this annotation are handled as tests by the framework
** The test annotation must be integrated in the comment block which describes the test
** Data validation is performed by the framework for tests if reference data is present
** The test annotation is valid till a '''@preprocess''' annotation specifies the begin of a preprocess block for further test runs
** The data type annotations
*** Data type annotations should be specified in the same comment block as the '''@test''' annotation
*** Data type annotations specify the grass data types which should be validated with reference data
*** The following data type annotations should be specified
**** '''@file''' the framework should compare the reference data with files
**** '''@raster''' the framework should compare the reference data with raster maps using r.out.ascii for export
**** '''@vector''' the framework should compare the reference data with vector maps using v.out.ascii for export
**** '''@raster3d''' the framework should compare the reference data with raster3d maps using r3.out.ascii for export
**** '''@color''' the framework should compare the reference data with color rules using r.color.out for export
**** '''@color3d''' the framework should compare the reference data with 3d color rules using r3.color.out for export
**** '''@table''' the framework should compare the reference data with SQL tables using db.select for export
**** ... please add more
** The '''@precision=[positive integer]''' annotation
*** Should be located in a test comment block
*** Specifies the precision to use to export grass data for validation with reference files
*** In case the precision is not provided the default behavior of the export module is used

Reference data for validation must be located in the module/library reference directory. The reference data names must be identical with the generated data (files, maps, ...) except that reference data always has a '''.ref''' suffix.

Tests are in each module's and in each library's folder. To test library functions special modules must be implemented. Library test modules test the library functions directly and should be written in C. Have a look at the test directories in the g3d, gpde and gmath libraries of grass7.

Framework should be able to generate and compare grass data types: raster, vector, raster3d, general, db, icon, imagery, d.*?

wxGUI testing should be tested separately.

Automated tests on server generates HTML report. Test several platforms.

Here some examples already available in grass7:

=== test.v.random.sh ===

<source lang="bash">
# This is a simple test for v.random
# We create several identical pseudo random points maps :)
# using the seed option for rand and drand48

# In the @preprocess step we set up a suitable region
g.region n=80 s=0 w=0 e=120 res=10 -p

# First @test the rand function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -z output=test_random_vect_1 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -z output=test_random_vect_2 n=20 zmin=0 zmax=100 column=height seed=501

# Second @test the drand48 function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -zd output=test_random_vect_3 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -zd output=test_random_vect_4 n=20 zmin=0 zmax=100 column=height seed=501

# Export the generated data as references
# v.out.ascii --o format=point dp=3 input=test_random_vect_1 output=test_random_vect_1.ref
# db.select "select * from test_random_vect_2" > test_random_vect_2.ref
# v.out.ascii --o format=point dp=3 input=test_random_vect_3 output=test_random_vect_3.ref
# db.select "select * from test_random_vect_4" > test_random_vect_4.ref
</source>

The following reference files are located in the v.random directory:
<pre>
-rw-r--r-- 1 soeren users 460 18. Jun 01:20 test_random_vect_1.ref
-rw-r--r-- 1 soeren users 257 18. Jun 01:20 test_random_vect_2.ref
-rw-r--r-- 1 soeren users 455 18. Jun 01:20 test_random_vect_3.ref
-rw-r--r-- 1 soeren users 256 18. Jun 01:20 test_random_vect_4.ref
</pre>

=== test.r3.out.vtk.sh ===

<source lang="bash">
# This script tests the export of voxel data
# into the VTK format. Almost all options of
# r3.out.vtk are tested. Validation data for each test
# is located in the module source directory

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now generate two elevation maps, we have 8 rows and use
# them for elevation computation. The rows are counted from north
# to south. So in the south the elevation must have a maximum.
r.mapcalc --o expr="elev_bottom = row()"
r.mapcalc --o expr="elev_top = row() + 50"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 2 || row() == 7, null(), volume)"
# Create the rgb maps
r3.mapcalc --o expr="volume_rgb = volume_null * 5"

# The first @test just exports the volume map as cell and point data
# using a low precision and replaces the default null value with 0
# the created @files should be compared with the reference data
r3.out.vtk --o input=volume_null output=test_volume_null_1_cells.vtk dp=3 null=0
r3.out.vtk -p --o input=volume_null output=test_volume_null_1_points.vtk dp=3 null=0

# The second @test adds rgb and vector maps. We re-use the created volume map
# for vector creation. The rgb value must range fom 0 - 255. The generated @files
# should be compared with the reference data.
r3.out.vtk --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_cells_rgb_vect.vtk dp=3 null=-1.0
r3.out.vtk -p --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_points_rgb_vect.vtk dp=3 null=-1.0

# The third @test uses raster maps to create volume data with an elevation surface
# The maximum elevation should be in the south. Reference @files are present for validation.
r3.out.vtk -s --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_cells_elevation.vtk dp=3 null=0
r3.out.vtk -sp --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_points_elevation.vtk dp=3 null=0
</source>

The following reference files are located in the r3.out.vtk directory:
<pre>
-rw-r--r-- 1 soeren users 104556 16. Jun 18:14 test_volume_null_1_cells_elevation.ref
-rw-r--r-- 1 soeren users 3434 16. Jun 18:14 test_volume_null_1_cells.ref
-rw-r--r-- 1 soeren users 22749 16. Jun 18:14 test_volume_null_1_cells_rgb_vect.ref
-rw-r--r-- 1 soeren users 13360 16. Jun 18:14 test_volume_null_1_points_elevation.ref
-rw-r--r-- 1 soeren users 3435 16. Jun 18:14 test_volume_null_1_points.ref
-rw-r--r-- 1 soeren users 22750 16. Jun 18:14 test_volume_null_1_points_rgb_vect.ref
</pre>

=== test.r3.cross.rast.sh ===

<source lang="bash">
# This script tests the r3.cross.rast module to compute
# cross section raster maps based on a raster3d and elevation map

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=100 b=0 t=50 res=10 res3=10 -p3
# We create several elevation maps to create slices of the voxel map
# We start from bottom and raise to the top. Value equal or greater 50
# should generate grass NULL values
r.mapcalc --o expr="elev_0 = 0"
r.mapcalc --o expr="elev_1 = 5"
r.mapcalc --o expr="elev_2 = 15"
r.mapcalc --o expr="elev_3 = 25"
r.mapcalc --o expr="elev_4 = 35"
r.mapcalc --o expr="elev_5 = 45"
r.mapcalc --o expr="elev_NAN = 50"
r.mapcalc --o expr="elev_cross = float(col()* 5)"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 1 || row() == 5, null(), volume)"

# We @test the creation of slices and a cross section of the voxel map. Reference data
# for @raster map validation is located in the r3.cross.rast source directory.
# Slice 0 and 1 should be identical. The last slice should consist only of grass NULL values
r3.cross.rast --o input=volume_null elevation=elev_0 output=test_cross_section_slice_0
r3.cross.rast --o input=volume_null elevation=elev_1 output=test_cross_section_slice_1
r3.cross.rast --o input=volume_null elevation=elev_2 output=test_cross_section_slice_2
r3.cross.rast --o input=volume_null elevation=elev_3 output=test_cross_section_slice_3
r3.cross.rast --o input=volume_null elevation=elev_4 output=test_cross_section_slice_4
r3.cross.rast --o input=volume_null elevation=elev_5 output=test_cross_section_slice_5
r3.cross.rast --o input=volume_null elevation=elev_NAN output=test_cross_section_slice_NAN
r3.cross.rast --o input=volume_null elevation=elev_cross output=test_cross_section_result
</source>

The following reference files are located in the r3.cross.rast directory:

<pre>
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_result.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_0.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_1.ref
-rw-r--r-- 1 soeren users 269 16. Jun 18:14 test_cross_section_slice_2.ref
-rw-r--r-- 1 soeren users 273 16. Jun 18:14 test_cross_section_slice_3.ref
-rw-r--r-- 1 soeren users 276 16. Jun 18:14 test_cross_section_slice_4.ref
-rw-r--r-- 1 soeren users 279 16. Jun 18:14 test_cross_section_slice_5.ref
-rw-r--r-- 1 soeren users 222 16. Jun 18:14 test_cross_section_slice_NAN.ref
</pre>

=== test.r3.out.ascii.sh ===

<source lang="bash">
# Tests for r3.out.ascii and r3.in.ascii
# This script tests the export of voxel data using r3.out.ascii
# as well as the import of the generated data with r3.in.ascii
# using different row and depth ordering options.

# We set up a specific region in the
# @preprocess step of this test. We generate
# voxel data with r3.mapcalc. The region setting
# should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now create several (float, double, null value) voxel map
# with value = col + row + depth.
r3.mapcalc --o expr="volume_float = float(col() + row() + depth())"
r3.mapcalc --o expr="volume_double = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_float_null = if(row() == 1 || row() == 5, null(), volume_float)"
r3.mapcalc --o expr="volume_double_null = if(row() == 1 || row() == 5, null(), volume_double)"

# We export float data in the first @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_float_null output=test_float_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_float_null output=test_float_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_float_null output=test_float_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_float_null output=test_float_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The rsult of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_float_null output=test_float_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_float_null output=test_float_nsbt_null_grass6_comp_3.txt dp=3 null=*

# We export double data in the second @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling. Its hte same
# procedure as with float data
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_double_null output=test_double_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_double_null output=test_double_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_double_null output=test_double_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_double_null output=test_double_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The result of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_double_null output=test_double_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_double_null output=test_double_nsbt_null_grass6_comp_3.txt dp=3 null=*

# In the third @test we import all the generated data using r3.in.ascii
# The created @raster maps should be identical to the map "volume_double_null"
# The export of the created g3d map should use as @precision=0 for data validation
# The same raster name is used for all the imported data and so for the validation reference file
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_snbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nstb_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null.txt nv=*
# Different precision and null values than default
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_prec5.txt nv=-1000
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null_prec8.txt nv=-2000
# Any row or depth order should be ignored in case grass6 compatibility is enabled
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_grass6_comp_1.txt

# In this @preprocess step for the last test we create a large region and
# generate large input data to test the handling of large files
g.region s=0 n=800 w=0 e=1200 b=0 t=50 res=10 res3=1.5 -p3
r3.mapcalc --o expr="volume_double_large = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_double_null_large = if(row() == 1 || row() == 5, null(), volume_double_large)"

# Now @test the export and import of large data without validation
r3.out.ascii --o input=volume_double_null_large output=test_double_nsbt_null_large.txt dp=0 null=*
r3.in.ascii --o output=test_double_nsbt_null_large input=test_double_nsbt_null_large.txt nv=*
# Just for the logs
r3.info test_double_nsbt_null_large
</source>

The following reference files are located in the r3.out.ascii directory:

<pre>
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_double_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_double_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_double_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_sntb_null.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_float_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_float_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_float_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_sntb_null.ref
</pre>

== Test framework: ==

What the test framework should do:

* Creation of a test mapset for each test case in a specific test location located in the grass sources
* Setting the environment variables to the test location and grass installation (grass environment to run modules)
* For each test case a separate temporary directory should be created in which the test is executed. After testing the temporary directory get removed. The temporary directory should be located in the temporary mapset which will be automatically removed after testing.
* Parsing and interpretation and execution of test scripts
* Support of several test scripts in a single module directory
* Run of location specific test scripts (only LL or UTM test scripts)
* Handles module test results codes and stderr messages
* Validation of module output based on reference data and data type annotations in the test description
* Creates a HTML report for single modules and the whole test run
* Deletion of the generated test mapset to clean up the test location

== Implementation ==

* All test cases must be implemented as text files in shell style including annotations in comment blocks
* The test framework should be implemented in Python, parsing and analyzing and executing the test cases line by line
* The Make-System must be modified to start the tests by typing "make tests"

=== Test framework Python approach ===

I suggest the following Python classes:
* TestBase class - implements the test logic
** LatLongTest class - for LatLong test location initialization and test run, derived from TestBase class
** UTMTest class - for UTM test location initialization and test run, derived from TestBase class
* A CommandBase class - implements command line specific methods and attributes and executes a command, logging return value and stderr using the subprocess module
** PreProcess class - derived from CommandBase class for preprocess execution
** TestCase class - derived from CommandBase class for test execution
* ...

The TestBase class implementing the following methods:

<source lang="python">

class TestBase:
def StartGrassSession(self):
"""Abstract method, should be overwritten in a subclass"""
pass
def Run(self):
"""Create the environment variables for the grass session, create a mapset and execute all tests"""
self.StartGrassSession()
self.CreateTestMapset()
self.CheckForReferenceFiles()
self.ExecuteAll()

def CreateTestMapset(self):
"""Creates a temporary mapset for the test using g.mapset"""
pass

def CreateExecutionOrder(self):
"""
* Reads the entire test case into memory and parses the file line by line
* Creates the execution order list as internal structure to store specific execution settings
* For each command in the test case a specific CommandBase object is created and stored in the execution order list
* TestCase objects store the validation type (@file, ...) and the validation precision (@precision=1) ... and maybe more
"""
pass

def ExecuteAll(self):
"""
* Create a temporary test directory in the temporary mapset
* Calls ExecuteTest or ExecutePreProcess for each entry in the execution order list
* Summarize the HTML and text summary content for each entry in the list
* Clean up the temporary directories generate for each command
"""
pass

def ExecuteTest(self):
"""
* Execute a single test command using the TestCase object
* Logs stderr and return value from TestCase object
* Analyses return value and stderr in case of an error
* Checks for new generated maps/files of the command
* Checks if reference files are present
* Export data with data specific commands (r/r3/v.out.ascii, r/r3.colors.out, ...)
* Compares reference files with exported files
* Creates HTML and text logfile entry
"""
pass

def CheckForReferenceFiles(self):
"""Lists all available reference files of a directory in an internal dict,
base name, path and full name are stored"""
pass

def ExecutePreprocess(self):
"""
* Execute a single preprocess command using the PreProcess object
* Logs stderr and return value from PreProcess object
* Analyses return value and stderr in case of an error
* Creates HTML and text logfile entry
"""
pass

def CompareVectorMap(self):
"""
* Exports vector map with v.out.ascii using the default or specific TestCase precision
* Compares exported file with reference file
"""
pass

def CompareRasterMap(self):
"""
* Exports raster map with r.out.ascii using the default or specific TestCase precision
* Compares exported file with reference file
"""
pass

def CompareRaster3dMap(self):
"""
* Exports raster3d map with r3.out.ascii using the default or specific TestCase precision
* Compares exported file with reference file
"""
pass

def CompareColor(self):
"""
* Export raster color with r.colors.out
* Compares exported file with reference file
"""
pass

def CompareColor3d(self):
"""
* Export raster3d color with r3.colors.out
* Compares exported file with reference file
"""
pass

def CreateHTMLTestSummary(self):
pass

def CreateTextTestSummary(self):
pass

def CleanUp(self):
""" Remove the temporary test mapset and all generated test files """
pass

# ... many more
</source>

The LatLongTest implements the following method:

<source lang="python">
class LatLongTest(BaseTest):
def StartGrassSession(self):
"""starts the grass7 session in a LatLong test location"""
pass
</source>

The UTMTest implements the following method:

<source lang="python">
class UTMTest(BaseTest):
def StartGrassSession(self):
"""starts the grass7 session in a UTM test location"""
pass
</source>

The CommandBase class:

* Uses the subprocess module to execute a command
* Is able to identify some shell specific commands in the command line ("&&, |, <, >")
* Acts as a very simple shell interpreter
** In case if "|" connects multiple commands in a command line with subprocess.PIPE
** In case of ">" or "<" uses stdout or stdin io
** No support for complex shell functionality (for, test, ...)

=== Make system ===

New rules should be added to the make system so that:
<source lang="bash">
make test ll
</source>
Will start recursively library and/or module tests from the current directory in the LatLong test location.
The Make system should execute the Python test framework main Python file in each Module or Library directory.
I guess test specific entries must be added to the modules and library Makefiles?

== Timeline and status ==

TBD

== Interested people ==

* [[User:huhabla | Sören Gebbert]]
* [[User:AnneGhisla| Anne Ghisla]]
* [[User:Landa|Martin Landa]]
* Add your name here

[[Category: Development]]
[[Category: Testing]]

Test Suite

2011-07-05T09:26:03Z

⚠️Huhabla:

__TOC__

= GRASS Test Suite =

We aim at creating a comprehensive test suite for GRASS modules and libraries.

== Background ==

See what has been done so far by Sören Gebbert and others here: [[Development#QA]] and the good [[http://www.vtk.org/Wiki/images/b/bc/Testing.cover.txt | VKT test suite]]

Keep an eye on [[GRASS_7_ideas_collection#Complete_GRASS_Test_Suite:_see_activity_on_Test_Suite_development_page | GRASS 7 ideas collection]]

== Main picture ==

We plan to run unittests and integration tests for both libraries and modules. The test suite will be run after compilation, with a command like:

$ make tests [ proj ]

Options:
* proj: run the tests with a [list of] CRS, so that reprojection and map unit handling are tested.
* ...

Tests are executed recursively. If the "make tests" command is executed in the root source folder all libraries and modules are tested. To test only the libraries you need to switch in the '''lib''' directory and execute "make tests". If you want to test only raster modules switch into the '''raster''' directory and run "make tests", same for other modules directories. To test a single module switch into the module directory and run "make tests".

== Tests ==

=== Modules ===
Tests are targeted to cover all modules as well as library test modules.

The modules tests should as independent as possible from other GRASS modules.

Tests are written as simple shell script with annotations. Test script should start with '''test.''' followed by the module name i.e. '''r.mapcalc.''' and further ending with '''.sh'''. Example '''test.r.mapcalc.1.sh'''. All test should be well documented using shell comments.

The framework will execute all test scripts starting with '''test.''' and ending with '''.sh''' located in module or library directories.

Annotations are integrated in the test documentation (simple shell comments) and specify pre-processing steps, the tests and the type of the data to validate. The following annotations should be supported:

* The '''@preprocess''' annotation
** All commands below this annotation are handled as preprocessing steps for the tests.
** If any of the preprocess commands fail, the framework should stop testing an create a detailed error report.
** Preprocessing steps may be data generation, region settings and so on.
** The preprocess annotation is valid till a '''@test''' annotation specifies the begin of a test
** Preprocess annotations can be specified at between tests
* The '''@test''' annotation
** All command below a this annotation are handled as tests by the framework
** The test annotation must be integrated in the comment block which describes the test
** Data validation is performed by the framework for tests if reference data is present
** The test annotation is valid till a '''@preprocess''' annotation specifies the begin of a preprocess block for further test runs
** The data type annotations
*** Data type annotations should be specified in the same comment block as the '''@test''' annotation
*** Data type annotations specify the grass data types which should be validated with reference data
*** The following data type annotations should be specified
**** '''@file''' the framework should compare the reference data with files
**** '''@raster''' the framework should compare the reference data with raster maps using r.out.ascii for export
**** '''@vector''' the framework should compare the reference data with vector maps using v.out.ascii for export
**** '''@raster3d''' the framework should compare the reference data with raster3d maps using r3.out.ascii for export
**** '''@color''' the framework should compare the reference data with color rules using r.color.out for export
**** '''@color3d''' the framework should compare the reference data with 3d color rules using r3.color.out for export
**** '''@table''' the framework should compare the reference data with SQL tables using db.select for export
**** ... please add more
** The '''@precision=[positive integer]''' annotation
*** Should be located in a test comment block
*** Specifies the precision to use to export grass data for validation with reference files
*** In case the precision is not provided the default behavior of the export module is used

Reference data for validation must be located in the module/library reference directory. The reference data names must be identical with the generated data (files, maps, ...) except that reference data always has a '''.ref''' suffix.

Tests are in each module's and in each library's folder. To test library functions special modules must be implemented. Library test modules test the library functions directly and should be written in C. Have a look at the test directories in the g3d, gpde and gmath libraries of grass7.

Framework should be able to generate and compare grass data types: raster, vector, raster3d, general, db, icon, imagery, d.*?

wxGUI testing should be tested separately.

Automated tests on server generates HTML report. Test several platforms.

Here some examples already available in grass7:

=== test.v.random.sh ===

<source lang="bash">
# This is a simple test for v.random
# We create several identical pseudo random points maps :)
# using the seed option for rand and drand48

# In the @preprocess step we set up a suitable region
g.region n=80 s=0 w=0 e=120 res=10 -p

# First @test the rand function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -z output=test_random_vect_1 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -z output=test_random_vect_2 n=20 zmin=0 zmax=100 column=height seed=501

# Second @test the drand48 function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -zd output=test_random_vect_3 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -zd output=test_random_vect_4 n=20 zmin=0 zmax=100 column=height seed=501

# Export the generated data as references
# v.out.ascii --o format=point dp=3 input=test_random_vect_1 output=test_random_vect_1.ref
# db.select "select * from test_random_vect_2" > test_random_vect_2.ref
# v.out.ascii --o format=point dp=3 input=test_random_vect_3 output=test_random_vect_3.ref
# db.select "select * from test_random_vect_4" > test_random_vect_4.ref
</source>

The following reference files are located in the v.random directory:
<pre>
-rw-r--r-- 1 soeren users 460 18. Jun 01:20 test_random_vect_1.ref
-rw-r--r-- 1 soeren users 257 18. Jun 01:20 test_random_vect_2.ref
-rw-r--r-- 1 soeren users 455 18. Jun 01:20 test_random_vect_3.ref
-rw-r--r-- 1 soeren users 256 18. Jun 01:20 test_random_vect_4.ref
</pre>

=== test.r3.out.vtk.sh ===

<source lang="bash">
# This script tests the export of voxel data
# into the VTK format. Almost all options of
# r3.out.vtk are tested. Validation data for each test
# is located in the module source directory

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now generate two elevation maps, we have 8 rows and use
# them for elevation computation. The rows are counted from north
# to south. So in the south the elevation must have a maximum.
r.mapcalc --o expr="elev_bottom = row()"
r.mapcalc --o expr="elev_top = row() + 50"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 2 || row() == 7, null(), volume)"
# Create the rgb maps
r3.mapcalc --o expr="volume_rgb = volume_null * 5"

# The first @test just exports the volume map as cell and point data
# using a low precision and replaces the default null value with 0
# the created @files should be compared with the reference data
r3.out.vtk --o input=volume_null output=test_volume_null_1_cells.vtk dp=3 null=0
r3.out.vtk -p --o input=volume_null output=test_volume_null_1_points.vtk dp=3 null=0

# The second @test adds rgb and vector maps. We re-use the created volume map
# for vector creation. The rgb value must range fom 0 - 255. The generated @files
# should be compared with the reference data.
r3.out.vtk --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_cells_rgb_vect.vtk dp=3 null=-1.0
r3.out.vtk -p --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_points_rgb_vect.vtk dp=3 null=-1.0

# The third @test uses raster maps to create volume data with an elevation surface
# The maximum elevation should be in the south. Reference @files are present for validation.
r3.out.vtk -s --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_cells_elevation.vtk dp=3 null=0
r3.out.vtk -sp --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_points_elevation.vtk dp=3 null=0
</source>

The following reference files are located in the r3.out.vtk directory:
<pre>
-rw-r--r-- 1 soeren users 104556 16. Jun 18:14 test_volume_null_1_cells_elevation.ref
-rw-r--r-- 1 soeren users 3434 16. Jun 18:14 test_volume_null_1_cells.ref
-rw-r--r-- 1 soeren users 22749 16. Jun 18:14 test_volume_null_1_cells_rgb_vect.ref
-rw-r--r-- 1 soeren users 13360 16. Jun 18:14 test_volume_null_1_points_elevation.ref
-rw-r--r-- 1 soeren users 3435 16. Jun 18:14 test_volume_null_1_points.ref
-rw-r--r-- 1 soeren users 22750 16. Jun 18:14 test_volume_null_1_points_rgb_vect.ref
</pre>

=== test.r3.cross.rast.sh ===

<source lang="bash">
# This script tests the r3.cross.rast module to compute
# cross section raster maps based on a raster3d and elevation map

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=100 b=0 t=50 res=10 res3=10 -p3
# We create several elevation maps to create slices of the voxel map
# We start from bottom and raise to the top. Value equal or greater 50
# should generate grass NULL values
r.mapcalc --o expr="elev_0 = 0"
r.mapcalc --o expr="elev_1 = 5"
r.mapcalc --o expr="elev_2 = 15"
r.mapcalc --o expr="elev_3 = 25"
r.mapcalc --o expr="elev_4 = 35"
r.mapcalc --o expr="elev_5 = 45"
r.mapcalc --o expr="elev_NAN = 50"
r.mapcalc --o expr="elev_cross = float(col()* 5)"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 1 || row() == 5, null(), volume)"

# We @test the creation of slices and a cross section of the voxel map. Reference data
# for @raster map validation is located in the r3.cross.rast source directory.
# Slice 0 and 1 should be identical. The last slice should consist only of grass NULL values
r3.cross.rast --o input=volume_null elevation=elev_0 output=test_cross_section_slice_0
r3.cross.rast --o input=volume_null elevation=elev_1 output=test_cross_section_slice_1
r3.cross.rast --o input=volume_null elevation=elev_2 output=test_cross_section_slice_2
r3.cross.rast --o input=volume_null elevation=elev_3 output=test_cross_section_slice_3
r3.cross.rast --o input=volume_null elevation=elev_4 output=test_cross_section_slice_4
r3.cross.rast --o input=volume_null elevation=elev_5 output=test_cross_section_slice_5
r3.cross.rast --o input=volume_null elevation=elev_NAN output=test_cross_section_slice_NAN
r3.cross.rast --o input=volume_null elevation=elev_cross output=test_cross_section_result
</source>

The following reference files are located in the r3.cross.rast directory:

<pre>
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_result.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_0.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_1.ref
-rw-r--r-- 1 soeren users 269 16. Jun 18:14 test_cross_section_slice_2.ref
-rw-r--r-- 1 soeren users 273 16. Jun 18:14 test_cross_section_slice_3.ref
-rw-r--r-- 1 soeren users 276 16. Jun 18:14 test_cross_section_slice_4.ref
-rw-r--r-- 1 soeren users 279 16. Jun 18:14 test_cross_section_slice_5.ref
-rw-r--r-- 1 soeren users 222 16. Jun 18:14 test_cross_section_slice_NAN.ref
</pre>

=== test.r3.out.ascii.sh ===

<source lang="bash">
# Tests for r3.out.ascii and r3.in.ascii
# This script tests the export of voxel data using r3.out.ascii
# as well as the import of the generated data with r3.in.ascii
# using different row and depth ordering options.

# We set up a specific region in the
# @preprocess step of this test. We generate
# voxel data with r3.mapcalc. The region setting
# should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now create several (float, double, null value) voxel map
# with value = col + row + depth.
r3.mapcalc --o expr="volume_float = float(col() + row() + depth())"
r3.mapcalc --o expr="volume_double = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_float_null = if(row() == 1 || row() == 5, null(), volume_float)"
r3.mapcalc --o expr="volume_double_null = if(row() == 1 || row() == 5, null(), volume_double)"

# We export float data in the first @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_float_null output=test_float_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_float_null output=test_float_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_float_null output=test_float_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_float_null output=test_float_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The rsult of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_float_null output=test_float_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_float_null output=test_float_nsbt_null_grass6_comp_3.txt dp=3 null=*

# We export double data in the second @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling. Its hte same
# procedure as with float data
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_double_null output=test_double_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_double_null output=test_double_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_double_null output=test_double_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_double_null output=test_double_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The result of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_double_null output=test_double_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_double_null output=test_double_nsbt_null_grass6_comp_3.txt dp=3 null=*

# In the third @test we import all the generated data using r3.in.ascii
# The created @raster maps should be identical to the map "volume_double_null"
# The export of the created g3d map should use as @precision=0 for data validation
# The same raster name is used for all the imported data and so for the validation reference file
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_snbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nstb_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null.txt nv=*
# Different precision and null values than default
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_prec5.txt nv=-1000
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null_prec8.txt nv=-2000
# Any row or depth order should be ignored in case grass6 compatibility is enabled
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_grass6_comp_1.txt

# In this @preprocess step for the last test we create a large region and
# generate large input data to test the handling of large files
g.region s=0 n=800 w=0 e=1200 b=0 t=50 res=10 res3=1.5 -p3
r3.mapcalc --o expr="volume_double_large = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_double_null_large = if(row() == 1 || row() == 5, null(), volume_double_large)"

# Now @test the export and import of large data without validation
r3.out.ascii --o input=volume_double_null_large output=test_double_nsbt_null_large.txt dp=0 null=*
r3.in.ascii --o output=test_double_nsbt_null_large input=test_double_nsbt_null_large.txt nv=*
# Just for the logs
r3.info test_double_nsbt_null_large
</source>

The following reference files are located in the r3.out.ascii directory:

<pre>
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_double_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_double_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_double_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_sntb_null.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_float_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_float_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_float_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_sntb_null.ref
</pre>

== Test framework: ==

What the test framework should do:

* Creation of a test mapset for each test case in a specific test location located in the grass sources
* Setting the environment variables to the test location and grass installation (grass environment to run modules)
* For each test case a separate temporary directory should be created in which the test is executed. After testing the temporary directory get removed. The temporary directory should be located in the temporary mapset which will be automatically removed after testing.
* Parsing and interpretation and execution of test scripts
* Support of several test scripts in a single module directory
* Run of location specific test scripts (only LL or UTM test scripts)
* Handles module test results codes and stderr messages
* Validation of module output based on reference data and data type annotations in the test description
* Creates a HTML report for single modules and the whole test run
* Deletion of the generated test mapset to clean up the test location

== Implementation ==

* All test cases must be implemented as text files in shell style including annotations in comment blocks
* The test framework should be implemented in Python, parsing and analyzing and executing the test cases line by line
* The Make-System must be modified to start the tests by typing "make tests"

=== Test framework Python approach ===

I suggest the following Python classes:
* TestBase class - implements the test logic
** LatLongTest class - for LatLong test location initialization and test run, derived from TestBase class
** UTMTest class - for UTM test location initialization and test run, derived from TestBase class
* A CommandBase class - implements command line specific methods and attributes and executes a command, logging return value and stderr using the subprocess module
** PreProcess class - derived from CommandBase class for preprocess execution
** TestCase class - derived from CommandBase class for test execution
* ...

The TestBase class implementing the following methods:

<source lang="python">

class TestBase:
def StartGrassSession(self):
"""Abstract method, should be overwritten in a subclass"""
pass
def Run(self):
"""Create the environment variables for the grass session, create a mapset and execute all tests"""
self.StartGrassSession()
self.CreateTestMapset()
self.CheckForReferenceFiles()
self.ExecuteAll()

def CreateTestMapset(self):
"""Creates a temporary mapset for the test using g.mapset"""
pass

def CreateExecutionOrder(self):
"""
* Reads the entire test case into memory and parses the file line by line
* Creates the execution order list as internal structure to store specific execution settings
* For each command in the test case a specific CommandBase object is created and stored in the execution order list
* TestCase objects store the validation type (@file, ...) and the validation precision (@precision=1) ... and maybe more
"""
pass

def ExecuteAll(self):
"""
* Create a temporary test directory in the temporary mapset
* Calls ExecuteTest or ExecutePreProcess for each entry in the execution order list
* Summarize the HTML and text summary content for each entry in the list
* Clean up the temporary directories generate for each command
"""
pass

def ExecuteTest(self):
"""
* Execute a single test command using the TestCase object
* Logs stderr and return value from TestCase object
* Analyses return value and stderr in case of an error
* Checks for new generated maps/files of the command
* Checks if reference files are present
* Export data with data specific commands (r/r3/v.out.ascii, r/r3.colors.out, ...)
* Compares reference files with exported files
* Creates HTML and text logfile entry
"""
pass

def CheckForReferenceFiles(self):
"""Lists all available reference files of a directory in an internal dict,
base name, path and full name are stored"""
pass

def ExecutePreprocess(self):
"""
* Execute a single preprocess command using the PreProcess object
* Logs stderr and return value from PreProcess object
* Analyses return value and stderr in case of an error
* Creates HTML and text logfile entry
"""
pass

def CompareVectorMap(self):
"""
* Exports vector map with v.out.ascii using the default or specific TestCase precision
* Compares exported file with reference file
"""
pass

def CompareRasterMap(self):
"""
* Exports raster map with r.out.ascii using the default or specific TestCase precision
* Compares exported file with reference file
"""
pass

def CompareRaster3dMap(self):
"""
* Exports raster3d map with r3.out.ascii using the default or specific TestCase precision
* Compares exported file with reference file
"""
pass

def CompareColor(self):
"""
* Export raster color with r.colors.out
* Compares exported file with reference file
"""
pass

def CompareColor3d(self):
"""
* Export raster3d color with r3.colors.out
* Compares exported file with reference file
"""
pass

def CreateHTMLTestSummary(self):
pass

def CreateTextTestSummary(self):
pass

def CleanUp(self):
""" Remove the temporary test mapset and all generated test files """
pass

# ... many more
</source>

The LatLongTest implements the following method:

<source lang="python">
class LatLongTest(BaseTest):
def StartGrassSession(self):
"""starts the grass7 session in a LatLong test location"""
pass
</source>

The UTMTest implements the following method:

<source lang="python">
class UTMTest(BaseTest):
def StartGrassSession(self):
"""starts the grass7 session in a UTM test location"""
pass
</source>

The CommandBase class:

* Uses the subprocess module to execute a command
* Is able to identify some shell specific commands in the command line ("&&, |, <, >")
* Acts as a very simple shell interpreter
** In case if "|" connects multiple commands in a command line with subprocess.PIPE
** In case of ">" or "<" uses stdout or stdin io
** No support for complex shell functionality (for, test, ...)

=== Make system ===

New rules should be added to the make system so that:
<source lang="bash">
make test ll
</source>
Will start recursively library and/or module tests from the current directory in the LatLong test location.
The Make system should execute the Python test framework main Python file in each Module or Library directory.
I guess test specific entries must be added to the modules and library Makefiles?

== Timeline and status ==

TBD

== Interested people ==

* [[User:huhabla | Sören Gebbert]]
* [[User:AnneGhisla| Anne Ghisla]]
* [[User:Landa|Martin Landa]]
* Add your name here

[[Category: Development]]
[[Category: Testing]]

Test Suite

2011-07-01T20:03:48Z

⚠️Huhabla: /* Implementation */

__TOC__

= GRASS Test Suite =

We aim at creating a comprehensive test suite for GRASS modules and libraries.

== Background ==

See what has been done so far by Sören Gebbert and others here: [[Development#QA]] and the good [[http://www.vtk.org/Wiki/images/b/bc/Testing.cover.txt | VKT test suite]]

Keep an eye on [[GRASS_7_ideas_collection#Complete_GRASS_Test_Suite:_see_activity_on_Test_Suite_development_page | GRASS 7 ideas collection]]

== Main picture ==

We plan to run unittests and integration tests for both libraries and modules. The test suite will be run after compilation, with a command like:

$ make tests [ proj ]

Options:
* proj: run the tests with a [list of] CRS, so that reprojection and map unit handling are tested.
* ...

Tests are executed recursively. If the "make tests" command is executed in the root source folder all libraries and modules are tested. To test only the libraries you need to switch in the '''lib''' directory and execute "make tests". If you want to test only raster modules switch into the '''raster''' directory and run "make tests", same for other modules directories. To test a single module switch into the module directory and run "make tests".

== Tests ==

=== Modules ===
Tests are targeted to cover all modules as well as library test modules.

The modules tests should as independent as possible from other GRASS modules.

Tests are written as simple shell script with annotations. Test script should start with '''test.''' followed by the module name i.e. '''r.mapcalc.''' and further ending with '''.sh'''. Example '''test.r.mapcalc.1.sh'''. All test should be well documented using shell comments.

The framework will execute all test scripts starting with '''test.''' and ending with '''.sh''' located in module or library directories.

Annotations are integrated in the test documentation (simple shell comments) and specify pre-processing steps, the tests and the type of the data to validate. The following annotations should be supported:

* The '''@preprocess''' annotation
** All commands below this annotation are handled as preprocessing steps for the tests.
** If any of the preprocess commands fail, the framework should stop testing an create a detailed error report.
** Preprocessing steps may be data generation, region settings and so on.
** The preprocess annotation is valid till a '''@test''' annotation specifies the begin of a test
** Preprocess annotations can be specified at between tests
* The '''@test''' annotation
** All command below a this annotation are handled as tests by the framework
** The test annotation must be integrated in the comment block which describes the test
** Data validation is performed by the framework for tests if reference data is present
** The test annotation is valid till a '''@preprocess''' annotation specifies the begin of a preprocess block for further test runs
** The data type annotations
*** Data type annotations should be specified in the same comment block as the '''@test''' annotation
*** Data type annotations specify the grass data types which should be validated with reference data
*** The following data type annotations should be specified
**** '''@file''' the framework should compare the reference data with files
**** '''@raster''' the framework should compare the reference data with raster maps using r.out.ascii for export
**** '''@vector''' the framework should compare the reference data with vector maps using v.out.ascii for export
**** '''@raster3d''' the framework should compare the reference data with raster3d maps using r3.out.ascii for export
**** '''@color''' the framework should compare the reference data with color rules using r.color.out for export
**** '''@color3d''' the framework should compare the reference data with 3d color rules using r3.color.out for export
**** '''@table''' the framework should compare the reference data with SQL tables using db.select for export
**** ... please add more
** The '''@precision=[positive integer]''' annotation
*** Should be located in a test comment block
*** Specifies the precision to use to export grass data for validation with reference files
*** In case the precision is not provided the default behavior of the export module is used

Reference data for validation must be located in the module/library directory. The reference data names must be identical with the generated data (files, maps, ...) except that reference data always has a '''.ref''' suffix.

Tests are in each module's and in each library's folder. To test library functions special modules must be implemented. Library test modules test the library functions directly and should be written in C. Have a look at the test directories in the g3d, gpde and gmath libraries of grass7.

Framework should be able to generate and compare grass data types: raster, vector, raster3d, general, db, icon, imagery, d.*?

wxGUI testing should be tested separately.

Automated tests on server generates HTML report. Test several platforms.

Here some examples already available in grass7:

=== test.v.random.sh ===

<source lang="bash">
# This is a simple test for v.random
# We create several identical pseudo random points maps :)
# using the seed option for rand and drand48

# In the @preprocess step we set up a suitable region
g.region n=80 s=0 w=0 e=120 res=10 -p

# First @test the rand function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -z output=test_random_vect_1 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -z output=test_random_vect_2 n=20 zmin=0 zmax=100 column=height seed=501

# Second @test the drand48 function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -zd output=test_random_vect_3 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -zd output=test_random_vect_4 n=20 zmin=0 zmax=100 column=height seed=501

# Export the generated data as references
# v.out.ascii --o format=point dp=3 input=test_random_vect_1 output=test_random_vect_1.ref
# db.select "select * from test_random_vect_2" > test_random_vect_2.ref
# v.out.ascii --o format=point dp=3 input=test_random_vect_3 output=test_random_vect_3.ref
# db.select "select * from test_random_vect_4" > test_random_vect_4.ref
</source>

The following reference files are located in the v.random directory:
<pre>
-rw-r--r-- 1 soeren users 460 18. Jun 01:20 test_random_vect_1.ref
-rw-r--r-- 1 soeren users 257 18. Jun 01:20 test_random_vect_2.ref
-rw-r--r-- 1 soeren users 455 18. Jun 01:20 test_random_vect_3.ref
-rw-r--r-- 1 soeren users 256 18. Jun 01:20 test_random_vect_4.ref
</pre>

=== test.r3.out.vtk.sh ===

<source lang="bash">
# This script tests the export of voxel data
# into the VTK format. Almost all options of
# r3.out.vtk are tested. Validation data for each test
# is located in the module source directory

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now generate two elevation maps, we have 8 rows and use
# them for elevation computation. The rows are counted from north
# to south. So in the south the elevation must have a maximum.
r.mapcalc --o expr="elev_bottom = row()"
r.mapcalc --o expr="elev_top = row() + 50"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 2 || row() == 7, null(), volume)"
# Create the rgb maps
r3.mapcalc --o expr="volume_rgb = volume_null * 5"

# The first @test just exports the volume map as cell and point data
# using a low precision and replaces the default null value with 0
# the created @files should be compared with the reference data
r3.out.vtk --o input=volume_null output=test_volume_null_1_cells.vtk dp=3 null=0
r3.out.vtk -p --o input=volume_null output=test_volume_null_1_points.vtk dp=3 null=0

# The second @test adds rgb and vector maps. We re-use the created volume map
# for vector creation. The rgb value must range fom 0 - 255. The generated @files
# should be compared with the reference data.
r3.out.vtk --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_cells_rgb_vect.vtk dp=3 null=-1.0
r3.out.vtk -p --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_points_rgb_vect.vtk dp=3 null=-1.0

# The third @test uses raster maps to create volume data with an elevation surface
# The maximum elevation should be in the south. Reference @files are present for validation.
r3.out.vtk -s --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_cells_elevation.vtk dp=3 null=0
r3.out.vtk -sp --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_points_elevation.vtk dp=3 null=0
</source>

The following reference files are located in the r3.out.vtk directory:
<pre>
-rw-r--r-- 1 soeren users 104556 16. Jun 18:14 test_volume_null_1_cells_elevation.ref
-rw-r--r-- 1 soeren users 3434 16. Jun 18:14 test_volume_null_1_cells.ref
-rw-r--r-- 1 soeren users 22749 16. Jun 18:14 test_volume_null_1_cells_rgb_vect.ref
-rw-r--r-- 1 soeren users 13360 16. Jun 18:14 test_volume_null_1_points_elevation.ref
-rw-r--r-- 1 soeren users 3435 16. Jun 18:14 test_volume_null_1_points.ref
-rw-r--r-- 1 soeren users 22750 16. Jun 18:14 test_volume_null_1_points_rgb_vect.ref
</pre>

=== test.r3.cross.rast.sh ===

<source lang="bash">
# This script tests the r3.cross.rast module to compute
# cross section raster maps based on a raster3d and elevation map

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=100 b=0 t=50 res=10 res3=10 -p3
# We create several elevation maps to create slices of the voxel map
# We start from bottom and raise to the top. Value equal or greater 50
# should generate grass NULL values
r.mapcalc --o expr="elev_0 = 0"
r.mapcalc --o expr="elev_1 = 5"
r.mapcalc --o expr="elev_2 = 15"
r.mapcalc --o expr="elev_3 = 25"
r.mapcalc --o expr="elev_4 = 35"
r.mapcalc --o expr="elev_5 = 45"
r.mapcalc --o expr="elev_NAN = 50"
r.mapcalc --o expr="elev_cross = float(col()* 5)"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 1 || row() == 5, null(), volume)"

# We @test the creation of slices and a cross section of the voxel map. Reference data
# for @raster map validation is located in the r3.cross.rast source directory.
# Slice 0 and 1 should be identical. The last slice should consist only of grass NULL values
r3.cross.rast --o input=volume_null elevation=elev_0 output=test_cross_section_slice_0
r3.cross.rast --o input=volume_null elevation=elev_1 output=test_cross_section_slice_1
r3.cross.rast --o input=volume_null elevation=elev_2 output=test_cross_section_slice_2
r3.cross.rast --o input=volume_null elevation=elev_3 output=test_cross_section_slice_3
r3.cross.rast --o input=volume_null elevation=elev_4 output=test_cross_section_slice_4
r3.cross.rast --o input=volume_null elevation=elev_5 output=test_cross_section_slice_5
r3.cross.rast --o input=volume_null elevation=elev_NAN output=test_cross_section_slice_NAN
r3.cross.rast --o input=volume_null elevation=elev_cross output=test_cross_section_result
</source>

The following reference files are located in the r3.cross.rast directory:

<pre>
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_result.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_0.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_1.ref
-rw-r--r-- 1 soeren users 269 16. Jun 18:14 test_cross_section_slice_2.ref
-rw-r--r-- 1 soeren users 273 16. Jun 18:14 test_cross_section_slice_3.ref
-rw-r--r-- 1 soeren users 276 16. Jun 18:14 test_cross_section_slice_4.ref
-rw-r--r-- 1 soeren users 279 16. Jun 18:14 test_cross_section_slice_5.ref
-rw-r--r-- 1 soeren users 222 16. Jun 18:14 test_cross_section_slice_NAN.ref
</pre>

=== test.r3.out.ascii.sh ===

<source lang="bash">
# Tests for r3.out.ascii and r3.in.ascii
# This script tests the export of voxel data using r3.out.ascii
# as well as the import of the generated data with r3.in.ascii
# using different row and depth ordering options.

# We set up a specific region in the
# @preprocess step of this test. We generate
# voxel data with r3.mapcalc. The region setting
# should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now create several (float, double, null value) voxel map
# with value = col + row + depth.
r3.mapcalc --o expr="volume_float = float(col() + row() + depth())"
r3.mapcalc --o expr="volume_double = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_float_null = if(row() == 1 || row() == 5, null(), volume_float)"
r3.mapcalc --o expr="volume_double_null = if(row() == 1 || row() == 5, null(), volume_double)"

# We export float data in the first @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_float_null output=test_float_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_float_null output=test_float_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_float_null output=test_float_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_float_null output=test_float_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The rsult of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_float_null output=test_float_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_float_null output=test_float_nsbt_null_grass6_comp_3.txt dp=3 null=*

# We export double data in the second @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling. Its hte same
# procedure as with float data
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_double_null output=test_double_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_double_null output=test_double_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_double_null output=test_double_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_double_null output=test_double_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The result of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_double_null output=test_double_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_double_null output=test_double_nsbt_null_grass6_comp_3.txt dp=3 null=*

# In the third @test we import all the generated data using r3.in.ascii
# The created @raster maps should be identical to the map "volume_double_null"
# The export of the created g3d map should use as @precision=0 for data validation
# The same raster name is used for all the imported data and so for the validation reference file
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_snbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nstb_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null.txt nv=*
# Different precision and null values than default
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_prec5.txt nv=-1000
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null_prec8.txt nv=-2000
# Any row or depth order should be ignored in case grass6 compatibility is enabled
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_grass6_comp_1.txt

# In this @preprocess step for the last test we create a large region and
# generate large input data to test the handling of large files
g.region s=0 n=800 w=0 e=1200 b=0 t=50 res=10 res3=1.5 -p3
r3.mapcalc --o expr="volume_double_large = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_double_null_large = if(row() == 1 || row() == 5, null(), volume_double_large)"

# Now @test the export and import of large data without validation
r3.out.ascii --o input=volume_double_null_large output=test_double_nsbt_null_large.txt dp=0 null=*
r3.in.ascii --o output=test_double_nsbt_null_large input=test_double_nsbt_null_large.txt nv=*
# Just for the logs
r3.info test_double_nsbt_null_large
</source>

The following reference files are located in the r3.out.ascii directory:

<pre>
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_double_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_double_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_double_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_sntb_null.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_float_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_float_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_float_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_sntb_null.ref
</pre>

== Test framework: ==

What the test framework should do:

* Creation of a test mapset for each test case in a specific test location located in the grass sources
* Setting the environment variables to the test location and grass installation (grass environment to run modules)
* Parsing and interpretation and execution of test scripts
* Support of several test scripts in a single module directory
* Run of location specific test scripts (only LL or UTM test scripts)
* Handles module test results codes and stderr messages
* Validation of module output based on reference data and data type annotations in the test description
* Creates a HTML report for single modules and the whole test run
* Deletion of the generated test mapset to clean up the test location

== Implementation ==

* All test cases must be implemented as text files in shell style including annotations in comment blocks
* The test framework should be implemented in Python, parsing and analyzing and executing the test cases line by line
* The Make-System must be modified to start the tests by typing "make tests"

=== Test framework Python approach ===

I suggest the following Python classes:
* TestBase class - implements the test logic
** LatLongTest class - for LatLong test location initialization and test run, derived from TestBase class
** UTMTest class - for UTM test location initialization and test run, derived from TestBase class
* A CommandBase class - implements command line specific methods and attributes and executes a command, logging return value and stderr using the subprocess module
** PreProcess class - derived from CommandBase class for preprocess execution
** TestCase class - derived from CommandBase class for test execution
* ...

The TestBase class implementing the following methods:

<source lang="python">

class TestBase:
def StartGrassSession(self):
"""Abstract method, should be overwritten in a subclass"""
pass
def Run(self):
"""Create the environment variables for the grass session, create a mapset and execute all tests"""
self.StartGrassSession()
self.CreateTestMapset()
self.CheckForReferenceFiles()
self.ExecuteAll()

def CreateTestMapset(self):
"""Creates a temporary mapset for the test using g.mapset"""
pass

def CreateExecutionOrder(self):
"""
* Reads the entire test case into memory and parses the file line by line
* Creates the execution order list as internal structure to store specific execution settings
* For each command in the test case a specific CommandBase object is created and stored in the execution order list
* TestCase objects store the validation type (@file, ...) and the validation precision (@precision=1) ... and maybe more
"""
pass

def ExecuteAll(self):
"""
* Calls ExecuteTest or ExecutePreProcess for each entry in the execution order list
* Summarize the HTML and text summary content for each entry in the list
"""
pass

def ExecuteTest(self):
"""
* Execute a single test command using the TestCase object
* Logs stderr and return value from TestCase object
* Analyses return value and stderr in case of an error
* Checks for new generated maps/files of the command
* Checks if reference files are present
* Export data with data specific commands (r/r3/v.out.ascii, r/r3.colors.out, ...)
* Compares reference files with exported files
* Creates HTML and text logfile entry
"""
pass

def CheckForReferenceFiles(self):
"""Lists all available reference files of a directory in an internal dict,
base name, path and full name are stored"""
pass

def ExecutePreprocess(self):
"""
* Execute a single preprocess command using the PreProcess object
* Logs stderr and return value from PreProcess object
* Analyses return value and stderr in case of an error
* Creates HTML and text logfile entry
"""
pass

def CompareVectorMap(self):
"""
* Exports vector map with v.out.ascii using the default or specific TestCase precision
* Compares exported file with reference file
"""
pass

def CompareRasterMap(self):
"""
* Exports raster map with r.out.ascii using the default or specific TestCase precision
* Compares exported file with reference file
"""
pass

def CompareRaster3dMap(self):
"""
* Exports raster3d map with r3.out.ascii using the default or specific TestCase precision
* Compares exported file with reference file
"""
pass

def CompareColor(self):
"""
* Export raster color with r.colors.out
* Compares exported file with reference file
"""
pass

def CompareColor3d(self):
"""
* Export raster3d color with r3.colors.out
* Compares exported file with reference file
"""
pass

def CreateHTMLTestSummary(self):
pass

def CreateTextTestSummary(self):
pass

def CleanUp(self):
""" Remove the temporary test mapset and all generated test files """
pass

# ... many more
</source>

The LatLongTest implements the following method:

<source lang="python">
class LatLongTest(BaseTest):
def StartGrassSession(self):
"""starts the grass7 session in a LatLong test location"""
pass
</source>

The UTMTest implements the following method:

<source lang="python">
class UTMTest(BaseTest):
def StartGrassSession(self):
"""starts the grass7 session in a UTM test location"""
pass
</source>

The CommandBase class:

* Uses the subprocess module to execute a command
* Is able to identify some shell specific commands in the command line ("&&, |, <, >")
* Acts as a very simple shell interpreter
** In case if "|" connects multiple commands in a command line with subprocess.PIPE
** In case of ">" or "<" uses stdout or stdin io
** No support for complex shell functionality (for, test, ...)

=== Make system ===

New rules should be added to the make system so that:
<source lang="bash">
make test ll
</source>
Will start recursively library and/or module tests from the current directory in the LatLong test location.
The Make system should execute the Python test framework main Python file in each Module or Library directory.
I guess test specific entries must be added to the modules and library Makefiles?

== Timeline and status ==

TBD

== Interested people ==

* [[User:huhabla | Sören Gebbert]]
* [[User:AnneGhisla| Anne Ghisla]]
* [[User:Landa|Martin Landa]]
* Add your name here

[[Category: Development]]
[[Category: Testing]]

Test Suite

2011-07-01T20:00:13Z

⚠️Huhabla: /* Implementation */

__TOC__

= GRASS Test Suite =

We aim at creating a comprehensive test suite for GRASS modules and libraries.

== Background ==

See what has been done so far by Sören Gebbert and others here: [[Development#QA]] and the good [[http://www.vtk.org/Wiki/images/b/bc/Testing.cover.txt | VKT test suite]]

Keep an eye on [[GRASS_7_ideas_collection#Complete_GRASS_Test_Suite:_see_activity_on_Test_Suite_development_page | GRASS 7 ideas collection]]

== Main picture ==

We plan to run unittests and integration tests for both libraries and modules. The test suite will be run after compilation, with a command like:

$ make tests [ proj ]

Options:
* proj: run the tests with a [list of] CRS, so that reprojection and map unit handling are tested.
* ...

Tests are executed recursively. If the "make tests" command is executed in the root source folder all libraries and modules are tested. To test only the libraries you need to switch in the '''lib''' directory and execute "make tests". If you want to test only raster modules switch into the '''raster''' directory and run "make tests", same for other modules directories. To test a single module switch into the module directory and run "make tests".

== Tests ==

=== Modules ===
Tests are targeted to cover all modules as well as library test modules.

The modules tests should as independent as possible from other GRASS modules.

Tests are written as simple shell script with annotations. Test script should start with '''test.''' followed by the module name i.e. '''r.mapcalc.''' and further ending with '''.sh'''. Example '''test.r.mapcalc.1.sh'''. All test should be well documented using shell comments.

The framework will execute all test scripts starting with '''test.''' and ending with '''.sh''' located in module or library directories.

Annotations are integrated in the test documentation (simple shell comments) and specify pre-processing steps, the tests and the type of the data to validate. The following annotations should be supported:

* The '''@preprocess''' annotation
** All commands below this annotation are handled as preprocessing steps for the tests.
** If any of the preprocess commands fail, the framework should stop testing an create a detailed error report.
** Preprocessing steps may be data generation, region settings and so on.
** The preprocess annotation is valid till a '''@test''' annotation specifies the begin of a test
** Preprocess annotations can be specified at between tests
* The '''@test''' annotation
** All command below a this annotation are handled as tests by the framework
** The test annotation must be integrated in the comment block which describes the test
** Data validation is performed by the framework for tests if reference data is present
** The test annotation is valid till a '''@preprocess''' annotation specifies the begin of a preprocess block for further test runs
** The data type annotations
*** Data type annotations should be specified in the same comment block as the '''@test''' annotation
*** Data type annotations specify the grass data types which should be validated with reference data
*** The following data type annotations should be specified
**** '''@file''' the framework should compare the reference data with files
**** '''@raster''' the framework should compare the reference data with raster maps using r.out.ascii for export
**** '''@vector''' the framework should compare the reference data with vector maps using v.out.ascii for export
**** '''@raster3d''' the framework should compare the reference data with raster3d maps using r3.out.ascii for export
**** '''@color''' the framework should compare the reference data with color rules using r.color.out for export
**** '''@color3d''' the framework should compare the reference data with 3d color rules using r3.color.out for export
**** '''@table''' the framework should compare the reference data with SQL tables using db.select for export
**** ... please add more
** The '''@precision=[positive integer]''' annotation
*** Should be located in a test comment block
*** Specifies the precision to use to export grass data for validation with reference files
*** In case the precision is not provided the default behavior of the export module is used

Reference data for validation must be located in the module/library directory. The reference data names must be identical with the generated data (files, maps, ...) except that reference data always has a '''.ref''' suffix.

Tests are in each module's and in each library's folder. To test library functions special modules must be implemented. Library test modules test the library functions directly and should be written in C. Have a look at the test directories in the g3d, gpde and gmath libraries of grass7.

Framework should be able to generate and compare grass data types: raster, vector, raster3d, general, db, icon, imagery, d.*?

wxGUI testing should be tested separately.

Automated tests on server generates HTML report. Test several platforms.

Here some examples already available in grass7:

=== test.v.random.sh ===

<source lang="bash">
# This is a simple test for v.random
# We create several identical pseudo random points maps :)
# using the seed option for rand and drand48

# In the @preprocess step we set up a suitable region
g.region n=80 s=0 w=0 e=120 res=10 -p

# First @test the rand function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -z output=test_random_vect_1 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -z output=test_random_vect_2 n=20 zmin=0 zmax=100 column=height seed=501

# Second @test the drand48 function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -zd output=test_random_vect_3 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -zd output=test_random_vect_4 n=20 zmin=0 zmax=100 column=height seed=501

# Export the generated data as references
# v.out.ascii --o format=point dp=3 input=test_random_vect_1 output=test_random_vect_1.ref
# db.select "select * from test_random_vect_2" > test_random_vect_2.ref
# v.out.ascii --o format=point dp=3 input=test_random_vect_3 output=test_random_vect_3.ref
# db.select "select * from test_random_vect_4" > test_random_vect_4.ref
</source>

The following reference files are located in the v.random directory:
<pre>
-rw-r--r-- 1 soeren users 460 18. Jun 01:20 test_random_vect_1.ref
-rw-r--r-- 1 soeren users 257 18. Jun 01:20 test_random_vect_2.ref
-rw-r--r-- 1 soeren users 455 18. Jun 01:20 test_random_vect_3.ref
-rw-r--r-- 1 soeren users 256 18. Jun 01:20 test_random_vect_4.ref
</pre>

=== test.r3.out.vtk.sh ===

<source lang="bash">
# This script tests the export of voxel data
# into the VTK format. Almost all options of
# r3.out.vtk are tested. Validation data for each test
# is located in the module source directory

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now generate two elevation maps, we have 8 rows and use
# them for elevation computation. The rows are counted from north
# to south. So in the south the elevation must have a maximum.
r.mapcalc --o expr="elev_bottom = row()"
r.mapcalc --o expr="elev_top = row() + 50"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 2 || row() == 7, null(), volume)"
# Create the rgb maps
r3.mapcalc --o expr="volume_rgb = volume_null * 5"

# The first @test just exports the volume map as cell and point data
# using a low precision and replaces the default null value with 0
# the created @files should be compared with the reference data
r3.out.vtk --o input=volume_null output=test_volume_null_1_cells.vtk dp=3 null=0
r3.out.vtk -p --o input=volume_null output=test_volume_null_1_points.vtk dp=3 null=0

# The second @test adds rgb and vector maps. We re-use the created volume map
# for vector creation. The rgb value must range fom 0 - 255. The generated @files
# should be compared with the reference data.
r3.out.vtk --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_cells_rgb_vect.vtk dp=3 null=-1.0
r3.out.vtk -p --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_points_rgb_vect.vtk dp=3 null=-1.0

# The third @test uses raster maps to create volume data with an elevation surface
# The maximum elevation should be in the south. Reference @files are present for validation.
r3.out.vtk -s --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_cells_elevation.vtk dp=3 null=0
r3.out.vtk -sp --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_points_elevation.vtk dp=3 null=0
</source>

The following reference files are located in the r3.out.vtk directory:
<pre>
-rw-r--r-- 1 soeren users 104556 16. Jun 18:14 test_volume_null_1_cells_elevation.ref
-rw-r--r-- 1 soeren users 3434 16. Jun 18:14 test_volume_null_1_cells.ref
-rw-r--r-- 1 soeren users 22749 16. Jun 18:14 test_volume_null_1_cells_rgb_vect.ref
-rw-r--r-- 1 soeren users 13360 16. Jun 18:14 test_volume_null_1_points_elevation.ref
-rw-r--r-- 1 soeren users 3435 16. Jun 18:14 test_volume_null_1_points.ref
-rw-r--r-- 1 soeren users 22750 16. Jun 18:14 test_volume_null_1_points_rgb_vect.ref
</pre>

=== test.r3.cross.rast.sh ===

<source lang="bash">
# This script tests the r3.cross.rast module to compute
# cross section raster maps based on a raster3d and elevation map

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=100 b=0 t=50 res=10 res3=10 -p3
# We create several elevation maps to create slices of the voxel map
# We start from bottom and raise to the top. Value equal or greater 50
# should generate grass NULL values
r.mapcalc --o expr="elev_0 = 0"
r.mapcalc --o expr="elev_1 = 5"
r.mapcalc --o expr="elev_2 = 15"
r.mapcalc --o expr="elev_3 = 25"
r.mapcalc --o expr="elev_4 = 35"
r.mapcalc --o expr="elev_5 = 45"
r.mapcalc --o expr="elev_NAN = 50"
r.mapcalc --o expr="elev_cross = float(col()* 5)"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 1 || row() == 5, null(), volume)"

# We @test the creation of slices and a cross section of the voxel map. Reference data
# for @raster map validation is located in the r3.cross.rast source directory.
# Slice 0 and 1 should be identical. The last slice should consist only of grass NULL values
r3.cross.rast --o input=volume_null elevation=elev_0 output=test_cross_section_slice_0
r3.cross.rast --o input=volume_null elevation=elev_1 output=test_cross_section_slice_1
r3.cross.rast --o input=volume_null elevation=elev_2 output=test_cross_section_slice_2
r3.cross.rast --o input=volume_null elevation=elev_3 output=test_cross_section_slice_3
r3.cross.rast --o input=volume_null elevation=elev_4 output=test_cross_section_slice_4
r3.cross.rast --o input=volume_null elevation=elev_5 output=test_cross_section_slice_5
r3.cross.rast --o input=volume_null elevation=elev_NAN output=test_cross_section_slice_NAN
r3.cross.rast --o input=volume_null elevation=elev_cross output=test_cross_section_result
</source>

The following reference files are located in the r3.cross.rast directory:

<pre>
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_result.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_0.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_1.ref
-rw-r--r-- 1 soeren users 269 16. Jun 18:14 test_cross_section_slice_2.ref
-rw-r--r-- 1 soeren users 273 16. Jun 18:14 test_cross_section_slice_3.ref
-rw-r--r-- 1 soeren users 276 16. Jun 18:14 test_cross_section_slice_4.ref
-rw-r--r-- 1 soeren users 279 16. Jun 18:14 test_cross_section_slice_5.ref
-rw-r--r-- 1 soeren users 222 16. Jun 18:14 test_cross_section_slice_NAN.ref
</pre>

=== test.r3.out.ascii.sh ===

<source lang="bash">
# Tests for r3.out.ascii and r3.in.ascii
# This script tests the export of voxel data using r3.out.ascii
# as well as the import of the generated data with r3.in.ascii
# using different row and depth ordering options.

# We set up a specific region in the
# @preprocess step of this test. We generate
# voxel data with r3.mapcalc. The region setting
# should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now create several (float, double, null value) voxel map
# with value = col + row + depth.
r3.mapcalc --o expr="volume_float = float(col() + row() + depth())"
r3.mapcalc --o expr="volume_double = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_float_null = if(row() == 1 || row() == 5, null(), volume_float)"
r3.mapcalc --o expr="volume_double_null = if(row() == 1 || row() == 5, null(), volume_double)"

# We export float data in the first @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_float_null output=test_float_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_float_null output=test_float_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_float_null output=test_float_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_float_null output=test_float_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The rsult of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_float_null output=test_float_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_float_null output=test_float_nsbt_null_grass6_comp_3.txt dp=3 null=*

# We export double data in the second @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling. Its hte same
# procedure as with float data
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_double_null output=test_double_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_double_null output=test_double_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_double_null output=test_double_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_double_null output=test_double_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The result of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_double_null output=test_double_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_double_null output=test_double_nsbt_null_grass6_comp_3.txt dp=3 null=*

# In the third @test we import all the generated data using r3.in.ascii
# The created @raster maps should be identical to the map "volume_double_null"
# The export of the created g3d map should use as @precision=0 for data validation
# The same raster name is used for all the imported data and so for the validation reference file
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_snbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nstb_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null.txt nv=*
# Different precision and null values than default
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_prec5.txt nv=-1000
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null_prec8.txt nv=-2000
# Any row or depth order should be ignored in case grass6 compatibility is enabled
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_grass6_comp_1.txt

# In this @preprocess step for the last test we create a large region and
# generate large input data to test the handling of large files
g.region s=0 n=800 w=0 e=1200 b=0 t=50 res=10 res3=1.5 -p3
r3.mapcalc --o expr="volume_double_large = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_double_null_large = if(row() == 1 || row() == 5, null(), volume_double_large)"

# Now @test the export and import of large data without validation
r3.out.ascii --o input=volume_double_null_large output=test_double_nsbt_null_large.txt dp=0 null=*
r3.in.ascii --o output=test_double_nsbt_null_large input=test_double_nsbt_null_large.txt nv=*
# Just for the logs
r3.info test_double_nsbt_null_large
</source>

The following reference files are located in the r3.out.ascii directory:

<pre>
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_double_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_double_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_double_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_sntb_null.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_float_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_float_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_float_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_sntb_null.ref
</pre>

== Test framework: ==

What the test framework should do:

* Creation of a test mapset for each test case in a specific test location located in the grass sources
* Setting the environment variables to the test location and grass installation (grass environment to run modules)
* Parsing and interpretation and execution of test scripts
* Support of several test scripts in a single module directory
* Run of location specific test scripts (only LL or UTM test scripts)
* Handles module test results codes and stderr messages
* Validation of module output based on reference data and data type annotations in the test description
* Creates a HTML report for single modules and the whole test run
* Deletion of the generated test mapset to clean up the test location

== Implementation ==

* All test cases must be implemented as text files in shell style including annotations in comment blocks
* The test framework should be implemented in Python, parsing and analyzing and executing the test cases line by line
* The Make-System must be modified to start the tests by typing "make tests"

=== Test framework Python approach ===

I suggest the following Python classes:
* TestBase class - implements the test logic
** LatLongTest class - for LatLong test location initialization and test run, derived from TestBase class
** UTMTest class - for UTM test location initialization and test run, derived from TestBase class
* A CommandBase class - implements command line specific methods and attributes and executes a command, logging return value and stderr using the subprocess module
** PreProcess class - derived from CommandBase class for preprocess execution
** TestCase class - derived from CommandBase class for test execution
* ...

The TestBase class implementing the following methods:

<source lang="python">

class TestBase:
def StartGrassSession(self):
"""Abstract method, should be overwritten in a subclass"""
pass
def Run(self):
"""Create the environment variables for the grass session, create a mapset and execute all tests"""
self.StartGrassSession()
self.CreateTestMapset()
self.CheckForReferenceFiles()
self.ExecuteAll()

def CreateTestMapset(self):
"""Creates a temporary mapset for the test using g.mapset"""
pass

def CreateExecutionOrder(self):
"""
* Reads the entire test case into memory and parses the file line by line
* Creates the execution order list as internal structure to store specific execution settings
* For each command in the test case a specific CommandBase object is created and stored in the execution order list
* TestCase objects store the validation type (@file, ...) and the validation precision (@precision=1) ... and maybe more
"""
pass

def ExecuteAll(self):
"""
* Calls ExecuteTest or ExecutePreProcess for each entry in the execution order list
* Summarize the HTML and text summary content for each entry in the list
"""
pass

def ExecuteTest(self):
"""
* Execute a single test command using the TestCase object
* Logs stderr and return value from TestCase object
* Analyses return value and stderr in case of an error
* Checks for new generated maps/files of the command
* Checks if reference files are present
* Export data with data specific commands (r/r3/v.out.ascii, r/r3.colors.out, ...)
* Compares reference files with exported files
* Creates HTML and text logfile entry
"""
pass

def CheckForReferenceFiles(self):
"""Lists all available reference files of a directory in an internal dict,
base name, path and full name are stored"""
pass

def ExecutePreprocess(self):
"""
* Execute a single preprocess command using the PreProcess object
* Logs stderr and return value from PreProcess object
* Analyses return value and stderr in case of an error
* Creates HTML and text logfile entry
"""
pass

def CompareVectorMap(self):
"""
* Exports vector map with v.out.ascii using the default or specific TestCase precision
* Compares exported file with reference file
"""
pass

def CompareRasterMap(self):
"""
* Exports raster map with r.out.ascii using the default or specific TestCase precision
* Compares exported file with reference file
"""
pass

def CompareRaster3dMap(self):
"""
* Exports raster3d map with r3.out.ascii using the default or specific TestCase precision
* Compares exported file with reference file
"""
pass

def CompareColor(self):
"""
* Export raster color with r.colors.out
* Compares exported file with reference file
"""
pass

def CompareColor3d(self):
"""
* Export raster3d color with r3.colors.out
* Compares exported file with reference file
"""
pass

def CreateHTMLTestSummary(self):
pass

def CreateTextTestSummary(self):
pass

def CleanUp(self):
""" Remove the temporary test mapset and all generated test files """
pass

# ... many more
</source>

The LatLongTest implements the following method:

* StartGrassSession
** starts the grass7 session in a LatLong test location

The UTMTest implements the following method:

* StartGrassSession
** starts the grass7 session in an UTM test location

The CommandBase class:

* Uses the subprocess module to execute a command
* Is able to identify some shell specific commands in the command line ("&&, |, <, >")
* Acts as a very simple shell interpreter
** In case if "|" connects multiple commands in a command line with subprocess.PIPE
** In case of ">" or "<" uses stdout or stdin io
** No support for complex shell functionality (for, test, ...)

=== Make system ===

New rules should be added to the make system so that:
<source land="bash">
make test ll
</source>
Will start recursively library and/or module tests from the current directory in the LatLong test location.
The Make system should execute the Python test framework main Python file in each Module or Library directory.
I guess test specific entries must be added to the modules and library Makefiles?

== Timeline and status ==

TBD

== Interested people ==

* [[User:huhabla | Sören Gebbert]]
* [[User:AnneGhisla| Anne Ghisla]]
* [[User:Landa|Martin Landa]]
* Add your name here

[[Category: Development]]
[[Category: Testing]]

Test Suite

2011-07-01T19:45:10Z

⚠️Huhabla: /* Implementation */

__TOC__

= GRASS Test Suite =

We aim at creating a comprehensive test suite for GRASS modules and libraries.

== Background ==

See what has been done so far by Sören Gebbert and others here: [[Development#QA]] and the good [[http://www.vtk.org/Wiki/images/b/bc/Testing.cover.txt | VKT test suite]]

Keep an eye on [[GRASS_7_ideas_collection#Complete_GRASS_Test_Suite:_see_activity_on_Test_Suite_development_page | GRASS 7 ideas collection]]

== Main picture ==

We plan to run unittests and integration tests for both libraries and modules. The test suite will be run after compilation, with a command like:

$ make tests [ proj ]

Options:
* proj: run the tests with a [list of] CRS, so that reprojection and map unit handling are tested.
* ...

Tests are executed recursively. If the "make tests" command is executed in the root source folder all libraries and modules are tested. To test only the libraries you need to switch in the '''lib''' directory and execute "make tests". If you want to test only raster modules switch into the '''raster''' directory and run "make tests", same for other modules directories. To test a single module switch into the module directory and run "make tests".

== Tests ==

=== Modules ===
Tests are targeted to cover all modules as well as library test modules.

The modules tests should as independent as possible from other GRASS modules.

Tests are written as simple shell script with annotations. Test script should start with '''test.''' followed by the module name i.e. '''r.mapcalc.''' and further ending with '''.sh'''. Example '''test.r.mapcalc.1.sh'''. All test should be well documented using shell comments.

The framework will execute all test scripts starting with '''test.''' and ending with '''.sh''' located in module or library directories.

Annotations are integrated in the test documentation (simple shell comments) and specify pre-processing steps, the tests and the type of the data to validate. The following annotations should be supported:

* The '''@preprocess''' annotation
** All commands below this annotation are handled as preprocessing steps for the tests.
** If any of the preprocess commands fail, the framework should stop testing an create a detailed error report.
** Preprocessing steps may be data generation, region settings and so on.
** The preprocess annotation is valid till a '''@test''' annotation specifies the begin of a test
** Preprocess annotations can be specified at between tests
* The '''@test''' annotation
** All command below a this annotation are handled as tests by the framework
** The test annotation must be integrated in the comment block which describes the test
** Data validation is performed by the framework for tests if reference data is present
** The test annotation is valid till a '''@preprocess''' annotation specifies the begin of a preprocess block for further test runs
** The data type annotations
*** Data type annotations should be specified in the same comment block as the '''@test''' annotation
*** Data type annotations specify the grass data types which should be validated with reference data
*** The following data type annotations should be specified
**** '''@file''' the framework should compare the reference data with files
**** '''@raster''' the framework should compare the reference data with raster maps using r.out.ascii for export
**** '''@vector''' the framework should compare the reference data with vector maps using v.out.ascii for export
**** '''@raster3d''' the framework should compare the reference data with raster3d maps using r3.out.ascii for export
**** '''@color''' the framework should compare the reference data with color rules using r.color.out for export
**** '''@color3d''' the framework should compare the reference data with 3d color rules using r3.color.out for export
**** '''@table''' the framework should compare the reference data with SQL tables using db.select for export
**** ... please add more
** The '''@precision=[positive integer]''' annotation
*** Should be located in a test comment block
*** Specifies the precision to use to export grass data for validation with reference files
*** In case the precision is not provided the default behavior of the export module is used

Reference data for validation must be located in the module/library directory. The reference data names must be identical with the generated data (files, maps, ...) except that reference data always has a '''.ref''' suffix.

Tests are in each module's and in each library's folder. To test library functions special modules must be implemented. Library test modules test the library functions directly and should be written in C. Have a look at the test directories in the g3d, gpde and gmath libraries of grass7.

Framework should be able to generate and compare grass data types: raster, vector, raster3d, general, db, icon, imagery, d.*?

wxGUI testing should be tested separately.

Automated tests on server generates HTML report. Test several platforms.

Here some examples already available in grass7:

=== test.v.random.sh ===

<source lang="bash">
# This is a simple test for v.random
# We create several identical pseudo random points maps :)
# using the seed option for rand and drand48

# In the @preprocess step we set up a suitable region
g.region n=80 s=0 w=0 e=120 res=10 -p

# First @test the rand function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -z output=test_random_vect_1 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -z output=test_random_vect_2 n=20 zmin=0 zmax=100 column=height seed=501

# Second @test the drand48 function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -zd output=test_random_vect_3 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -zd output=test_random_vect_4 n=20 zmin=0 zmax=100 column=height seed=501

# Export the generated data as references
# v.out.ascii --o format=point dp=3 input=test_random_vect_1 output=test_random_vect_1.ref
# db.select "select * from test_random_vect_2" > test_random_vect_2.ref
# v.out.ascii --o format=point dp=3 input=test_random_vect_3 output=test_random_vect_3.ref
# db.select "select * from test_random_vect_4" > test_random_vect_4.ref
</source>

The following reference files are located in the v.random directory:
<pre>
-rw-r--r-- 1 soeren users 460 18. Jun 01:20 test_random_vect_1.ref
-rw-r--r-- 1 soeren users 257 18. Jun 01:20 test_random_vect_2.ref
-rw-r--r-- 1 soeren users 455 18. Jun 01:20 test_random_vect_3.ref
-rw-r--r-- 1 soeren users 256 18. Jun 01:20 test_random_vect_4.ref
</pre>

=== test.r3.out.vtk.sh ===

<source lang="bash">
# This script tests the export of voxel data
# into the VTK format. Almost all options of
# r3.out.vtk are tested. Validation data for each test
# is located in the module source directory

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now generate two elevation maps, we have 8 rows and use
# them for elevation computation. The rows are counted from north
# to south. So in the south the elevation must have a maximum.
r.mapcalc --o expr="elev_bottom = row()"
r.mapcalc --o expr="elev_top = row() + 50"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 2 || row() == 7, null(), volume)"
# Create the rgb maps
r3.mapcalc --o expr="volume_rgb = volume_null * 5"

# The first @test just exports the volume map as cell and point data
# using a low precision and replaces the default null value with 0
# the created @files should be compared with the reference data
r3.out.vtk --o input=volume_null output=test_volume_null_1_cells.vtk dp=3 null=0
r3.out.vtk -p --o input=volume_null output=test_volume_null_1_points.vtk dp=3 null=0

# The second @test adds rgb and vector maps. We re-use the created volume map
# for vector creation. The rgb value must range fom 0 - 255. The generated @files
# should be compared with the reference data.
r3.out.vtk --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_cells_rgb_vect.vtk dp=3 null=-1.0
r3.out.vtk -p --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_points_rgb_vect.vtk dp=3 null=-1.0

# The third @test uses raster maps to create volume data with an elevation surface
# The maximum elevation should be in the south. Reference @files are present for validation.
r3.out.vtk -s --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_cells_elevation.vtk dp=3 null=0
r3.out.vtk -sp --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_points_elevation.vtk dp=3 null=0
</source>

The following reference files are located in the r3.out.vtk directory:
<pre>
-rw-r--r-- 1 soeren users 104556 16. Jun 18:14 test_volume_null_1_cells_elevation.ref
-rw-r--r-- 1 soeren users 3434 16. Jun 18:14 test_volume_null_1_cells.ref
-rw-r--r-- 1 soeren users 22749 16. Jun 18:14 test_volume_null_1_cells_rgb_vect.ref
-rw-r--r-- 1 soeren users 13360 16. Jun 18:14 test_volume_null_1_points_elevation.ref
-rw-r--r-- 1 soeren users 3435 16. Jun 18:14 test_volume_null_1_points.ref
-rw-r--r-- 1 soeren users 22750 16. Jun 18:14 test_volume_null_1_points_rgb_vect.ref
</pre>

=== test.r3.cross.rast.sh ===

<source lang="bash">
# This script tests the r3.cross.rast module to compute
# cross section raster maps based on a raster3d and elevation map

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=100 b=0 t=50 res=10 res3=10 -p3
# We create several elevation maps to create slices of the voxel map
# We start from bottom and raise to the top. Value equal or greater 50
# should generate grass NULL values
r.mapcalc --o expr="elev_0 = 0"
r.mapcalc --o expr="elev_1 = 5"
r.mapcalc --o expr="elev_2 = 15"
r.mapcalc --o expr="elev_3 = 25"
r.mapcalc --o expr="elev_4 = 35"
r.mapcalc --o expr="elev_5 = 45"
r.mapcalc --o expr="elev_NAN = 50"
r.mapcalc --o expr="elev_cross = float(col()* 5)"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 1 || row() == 5, null(), volume)"

# We @test the creation of slices and a cross section of the voxel map. Reference data
# for @raster map validation is located in the r3.cross.rast source directory.
# Slice 0 and 1 should be identical. The last slice should consist only of grass NULL values
r3.cross.rast --o input=volume_null elevation=elev_0 output=test_cross_section_slice_0
r3.cross.rast --o input=volume_null elevation=elev_1 output=test_cross_section_slice_1
r3.cross.rast --o input=volume_null elevation=elev_2 output=test_cross_section_slice_2
r3.cross.rast --o input=volume_null elevation=elev_3 output=test_cross_section_slice_3
r3.cross.rast --o input=volume_null elevation=elev_4 output=test_cross_section_slice_4
r3.cross.rast --o input=volume_null elevation=elev_5 output=test_cross_section_slice_5
r3.cross.rast --o input=volume_null elevation=elev_NAN output=test_cross_section_slice_NAN
r3.cross.rast --o input=volume_null elevation=elev_cross output=test_cross_section_result
</source>

The following reference files are located in the r3.cross.rast directory:

<pre>
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_result.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_0.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_1.ref
-rw-r--r-- 1 soeren users 269 16. Jun 18:14 test_cross_section_slice_2.ref
-rw-r--r-- 1 soeren users 273 16. Jun 18:14 test_cross_section_slice_3.ref
-rw-r--r-- 1 soeren users 276 16. Jun 18:14 test_cross_section_slice_4.ref
-rw-r--r-- 1 soeren users 279 16. Jun 18:14 test_cross_section_slice_5.ref
-rw-r--r-- 1 soeren users 222 16. Jun 18:14 test_cross_section_slice_NAN.ref
</pre>

=== test.r3.out.ascii.sh ===

<source lang="bash">
# Tests for r3.out.ascii and r3.in.ascii
# This script tests the export of voxel data using r3.out.ascii
# as well as the import of the generated data with r3.in.ascii
# using different row and depth ordering options.

# We set up a specific region in the
# @preprocess step of this test. We generate
# voxel data with r3.mapcalc. The region setting
# should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now create several (float, double, null value) voxel map
# with value = col + row + depth.
r3.mapcalc --o expr="volume_float = float(col() + row() + depth())"
r3.mapcalc --o expr="volume_double = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_float_null = if(row() == 1 || row() == 5, null(), volume_float)"
r3.mapcalc --o expr="volume_double_null = if(row() == 1 || row() == 5, null(), volume_double)"

# We export float data in the first @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_float_null output=test_float_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_float_null output=test_float_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_float_null output=test_float_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_float_null output=test_float_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The rsult of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_float_null output=test_float_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_float_null output=test_float_nsbt_null_grass6_comp_3.txt dp=3 null=*

# We export double data in the second @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling. Its hte same
# procedure as with float data
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_double_null output=test_double_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_double_null output=test_double_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_double_null output=test_double_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_double_null output=test_double_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The result of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_double_null output=test_double_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_double_null output=test_double_nsbt_null_grass6_comp_3.txt dp=3 null=*

# In the third @test we import all the generated data using r3.in.ascii
# The created @raster maps should be identical to the map "volume_double_null"
# The export of the created g3d map should use as @precision=0 for data validation
# The same raster name is used for all the imported data and so for the validation reference file
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_snbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nstb_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null.txt nv=*
# Different precision and null values than default
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_prec5.txt nv=-1000
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null_prec8.txt nv=-2000
# Any row or depth order should be ignored in case grass6 compatibility is enabled
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_grass6_comp_1.txt

# In this @preprocess step for the last test we create a large region and
# generate large input data to test the handling of large files
g.region s=0 n=800 w=0 e=1200 b=0 t=50 res=10 res3=1.5 -p3
r3.mapcalc --o expr="volume_double_large = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_double_null_large = if(row() == 1 || row() == 5, null(), volume_double_large)"

# Now @test the export and import of large data without validation
r3.out.ascii --o input=volume_double_null_large output=test_double_nsbt_null_large.txt dp=0 null=*
r3.in.ascii --o output=test_double_nsbt_null_large input=test_double_nsbt_null_large.txt nv=*
# Just for the logs
r3.info test_double_nsbt_null_large
</source>

The following reference files are located in the r3.out.ascii directory:

<pre>
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_double_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_double_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_double_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_sntb_null.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_float_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_float_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_float_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_sntb_null.ref
</pre>

== Test framework: ==

What the test framework should do:

* Creation of a test mapset for each test case in a specific test location located in the grass sources
* Setting the environment variables to the test location and grass installation (grass environment to run modules)
* Parsing and interpretation and execution of test scripts
* Support of several test scripts in a single module directory
* Run of location specific test scripts (only LL or UTM test scripts)
* Handles module test results codes and stderr messages
* Validation of module output based on reference data and data type annotations in the test description
* Creates a HTML report for single modules and the whole test run
* Deletion of the generated test mapset to clean up the test location

== Implementation ==

* All test cases must be implemented as text files in shell style including annotations in comment blocks
* The test framework should be implemented in Python, parsing and analyzing and executing the test cases line by line
* The Make-System must be modified to start the tests by typing "make tests"

=== Test framework Python approach ===

I suggest the following Python classes:
* TestBase class - implements the test logic
** LatLongTest class - for LatLong test location initialization and test run, derived from TestBase class
** UTMTest class - for UTM test location initialization and test run, derived from TestBase class
* A CommandBase class - implements command line specific methods and attributes and executes a command, logging return value and stderr using the subprocess module
** PreProcess class - derived from CommandBase class for preprocess execution
** TestCase class - derived from CommandBase class for test execution
* ...

The TestBase class implementing the following methods:

<source lang="python">
* StartGrassSession
** Abstract method, should be overwritten in a subclass
* Run
** Calls StartGrassSession
** Calls CreateTestMapset
** Calls ExecuteAll
* CreateTestMapset
** Creates a temporary mapset for the test using g.mapset
* CreateExecutionOrder
** Reads the entire test case into memory and parses the file line by line
** Creates the execution order list as internal structure to store specific execution settings
** For each command in the test case a specific CommandBase object is created and stored in the execution order list
** TestCase objects store the validation type (@file, ...) and the validation precision (@precision=1) ... and maybe more
* ExecuteAll
** Calls ExecuteTest or ExecutePreProcess for each entry in the execution order list
** Summarize the HTML and text summary content for each entry in the list
* ExecuteTest
** Execute a single test command using the TestCase object
** Logs stderr and return value from TestCase object
** Analyses return value and stderr in case of an error
** Checks for new generated maps/files of the command
** Checks if reference files are present
** Export data with data specific commands (r/r3/v.out.ascii, r/r3.colors.out, ...)
** Compares reference files with exported files
** Creates HTML and text logfile entry
* CheckForReferenceFiles
** Lists all available reference files of a directory in an internal dict, base name, path and full name are stored
* ExecutePreprocess
** Execute a single preprocess command using the PreProcess object
** Logs stderr and return value from PreProcess object
** Analyses return value and stderr in case of an error
** Creates HTML and text logfile entry
* CompareVectorMap
** Exports vector map with v.out.ascii using the default or specific TestCase precision
** Compares exported file with reference file
* CompareRasterMap
** Export raster map with r.out.ascii using the default or specific TestCase precision
** Compares exported file with reference file
* CompareRaster3dMaps
** Exports raster3d map with r3.out.ascii using the default or specific TestCase precision
** Compares exported file with reference file
* CompareColor
** Export raster color with r.colors.out
** Compares exported file with reference file
* CompareColor3d
** Export raster3d color with r3.colors.out
** Compares exported file with reference file
* CreateHTMLTestSummary
* CreateTextTestSummary
* CleanUp
** Remove the temporary test mapset and all generated test files
* ... many more
</source>

The LatLongTest implements the following method:

* StartGrassSession
** starts the grass7 session in a LatLong test location

The UTMTest implements the following method:

* StartGrassSession
** starts the grass7 session in an UTM test location

The CommandBase class:

* Uses the subprocess module to execute a command
* Is able to identify some shell specific commands in the command line ("&&, |, <, >")
* Acts as a very simple shell interpreter
** In case if "|" connects multiple commands in a command line with subprocess.PIPE
** In case of ">" or "<" uses stdout or stdin io
** No support for complex shell functionality (for, test, ...)

=== Make system ===

New rules should be added to the make system so that:
{{{
make test ll
}}}
Will start recursively library and/or module tests from the current directory in the LatLong test location.
The Make system should execute the Python test framework main Python file in each Module or Library directory.
I guess test specific entries must be added to the modules and library Makefiles?

== Timeline and status ==

TBD

== Interested people ==

* [[User:huhabla | Sören Gebbert]]
* [[User:AnneGhisla| Anne Ghisla]]
* [[User:Landa|Martin Landa]]
* Add your name here

[[Category: Development]]
[[Category: Testing]]

Test Suite

2011-07-01T19:35:07Z

⚠️Huhabla: /* Test framework Python approach */

__TOC__

= GRASS Test Suite =

We aim at creating a comprehensive test suite for GRASS modules and libraries.

== Background ==

See what has been done so far by Sören Gebbert and others here: [[Development#QA]] and the good [[http://www.vtk.org/Wiki/images/b/bc/Testing.cover.txt | VKT test suite]]

Keep an eye on [[GRASS_7_ideas_collection#Complete_GRASS_Test_Suite:_see_activity_on_Test_Suite_development_page | GRASS 7 ideas collection]]

== Main picture ==

We plan to run unittests and integration tests for both libraries and modules. The test suite will be run after compilation, with a command like:

$ make tests [ proj ]

Options:
* proj: run the tests with a [list of] CRS, so that reprojection and map unit handling are tested.
* ...

Tests are executed recursively. If the "make tests" command is executed in the root source folder all libraries and modules are tested. To test only the libraries you need to switch in the '''lib''' directory and execute "make tests". If you want to test only raster modules switch into the '''raster''' directory and run "make tests", same for other modules directories. To test a single module switch into the module directory and run "make tests".

== Tests ==

=== Modules ===
Tests are targeted to cover all modules as well as library test modules.

The modules tests should as independent as possible from other GRASS modules.

Tests are written as simple shell script with annotations. Test script should start with '''test.''' followed by the module name i.e. '''r.mapcalc.''' and further ending with '''.sh'''. Example '''test.r.mapcalc.1.sh'''. All test should be well documented using shell comments.

The framework will execute all test scripts starting with '''test.''' and ending with '''.sh''' located in module or library directories.

Annotations are integrated in the test documentation (simple shell comments) and specify pre-processing steps, the tests and the type of the data to validate. The following annotations should be supported:

* The '''@preprocess''' annotation
** All commands below this annotation are handled as preprocessing steps for the tests.
** If any of the preprocess commands fail, the framework should stop testing an create a detailed error report.
** Preprocessing steps may be data generation, region settings and so on.
** The preprocess annotation is valid till a '''@test''' annotation specifies the begin of a test
** Preprocess annotations can be specified at between tests
* The '''@test''' annotation
** All command below a this annotation are handled as tests by the framework
** The test annotation must be integrated in the comment block which describes the test
** Data validation is performed by the framework for tests if reference data is present
** The test annotation is valid till a '''@preprocess''' annotation specifies the begin of a preprocess block for further test runs
** The data type annotations
*** Data type annotations should be specified in the same comment block as the '''@test''' annotation
*** Data type annotations specify the grass data types which should be validated with reference data
*** The following data type annotations should be specified
**** '''@file''' the framework should compare the reference data with files
**** '''@raster''' the framework should compare the reference data with raster maps using r.out.ascii for export
**** '''@vector''' the framework should compare the reference data with vector maps using v.out.ascii for export
**** '''@raster3d''' the framework should compare the reference data with raster3d maps using r3.out.ascii for export
**** '''@color''' the framework should compare the reference data with color rules using r.color.out for export
**** '''@color3d''' the framework should compare the reference data with 3d color rules using r3.color.out for export
**** '''@table''' the framework should compare the reference data with SQL tables using db.select for export
**** ... please add more
** The '''@precision=[positive integer]''' annotation
*** Should be located in a test comment block
*** Specifies the precision to use to export grass data for validation with reference files
*** In case the precision is not provided the default behavior of the export module is used

Reference data for validation must be located in the module/library directory. The reference data names must be identical with the generated data (files, maps, ...) except that reference data always has a '''.ref''' suffix.

Tests are in each module's and in each library's folder. To test library functions special modules must be implemented. Library test modules test the library functions directly and should be written in C. Have a look at the test directories in the g3d, gpde and gmath libraries of grass7.

Framework should be able to generate and compare grass data types: raster, vector, raster3d, general, db, icon, imagery, d.*?

wxGUI testing should be tested separately.

Automated tests on server generates HTML report. Test several platforms.

Here some examples already available in grass7:

=== test.v.random.sh ===

<source lang="bash">
# This is a simple test for v.random
# We create several identical pseudo random points maps :)
# using the seed option for rand and drand48

# In the @preprocess step we set up a suitable region
g.region n=80 s=0 w=0 e=120 res=10 -p

# First @test the rand function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -z output=test_random_vect_1 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -z output=test_random_vect_2 n=20 zmin=0 zmax=100 column=height seed=501

# Second @test the drand48 function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -zd output=test_random_vect_3 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -zd output=test_random_vect_4 n=20 zmin=0 zmax=100 column=height seed=501

# Export the generated data as references
# v.out.ascii --o format=point dp=3 input=test_random_vect_1 output=test_random_vect_1.ref
# db.select "select * from test_random_vect_2" > test_random_vect_2.ref
# v.out.ascii --o format=point dp=3 input=test_random_vect_3 output=test_random_vect_3.ref
# db.select "select * from test_random_vect_4" > test_random_vect_4.ref
</source>

The following reference files are located in the v.random directory:
<pre>
-rw-r--r-- 1 soeren users 460 18. Jun 01:20 test_random_vect_1.ref
-rw-r--r-- 1 soeren users 257 18. Jun 01:20 test_random_vect_2.ref
-rw-r--r-- 1 soeren users 455 18. Jun 01:20 test_random_vect_3.ref
-rw-r--r-- 1 soeren users 256 18. Jun 01:20 test_random_vect_4.ref
</pre>

=== test.r3.out.vtk.sh ===

<source lang="bash">
# This script tests the export of voxel data
# into the VTK format. Almost all options of
# r3.out.vtk are tested. Validation data for each test
# is located in the module source directory

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now generate two elevation maps, we have 8 rows and use
# them for elevation computation. The rows are counted from north
# to south. So in the south the elevation must have a maximum.
r.mapcalc --o expr="elev_bottom = row()"
r.mapcalc --o expr="elev_top = row() + 50"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 2 || row() == 7, null(), volume)"
# Create the rgb maps
r3.mapcalc --o expr="volume_rgb = volume_null * 5"

# The first @test just exports the volume map as cell and point data
# using a low precision and replaces the default null value with 0
# the created @files should be compared with the reference data
r3.out.vtk --o input=volume_null output=test_volume_null_1_cells.vtk dp=3 null=0
r3.out.vtk -p --o input=volume_null output=test_volume_null_1_points.vtk dp=3 null=0

# The second @test adds rgb and vector maps. We re-use the created volume map
# for vector creation. The rgb value must range fom 0 - 255. The generated @files
# should be compared with the reference data.
r3.out.vtk --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_cells_rgb_vect.vtk dp=3 null=-1.0
r3.out.vtk -p --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_points_rgb_vect.vtk dp=3 null=-1.0

# The third @test uses raster maps to create volume data with an elevation surface
# The maximum elevation should be in the south. Reference @files are present for validation.
r3.out.vtk -s --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_cells_elevation.vtk dp=3 null=0
r3.out.vtk -sp --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_points_elevation.vtk dp=3 null=0
</source>

The following reference files are located in the r3.out.vtk directory:
<pre>
-rw-r--r-- 1 soeren users 104556 16. Jun 18:14 test_volume_null_1_cells_elevation.ref
-rw-r--r-- 1 soeren users 3434 16. Jun 18:14 test_volume_null_1_cells.ref
-rw-r--r-- 1 soeren users 22749 16. Jun 18:14 test_volume_null_1_cells_rgb_vect.ref
-rw-r--r-- 1 soeren users 13360 16. Jun 18:14 test_volume_null_1_points_elevation.ref
-rw-r--r-- 1 soeren users 3435 16. Jun 18:14 test_volume_null_1_points.ref
-rw-r--r-- 1 soeren users 22750 16. Jun 18:14 test_volume_null_1_points_rgb_vect.ref
</pre>

=== test.r3.cross.rast.sh ===

<source lang="bash">
# This script tests the r3.cross.rast module to compute
# cross section raster maps based on a raster3d and elevation map

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=100 b=0 t=50 res=10 res3=10 -p3
# We create several elevation maps to create slices of the voxel map
# We start from bottom and raise to the top. Value equal or greater 50
# should generate grass NULL values
r.mapcalc --o expr="elev_0 = 0"
r.mapcalc --o expr="elev_1 = 5"
r.mapcalc --o expr="elev_2 = 15"
r.mapcalc --o expr="elev_3 = 25"
r.mapcalc --o expr="elev_4 = 35"
r.mapcalc --o expr="elev_5 = 45"
r.mapcalc --o expr="elev_NAN = 50"
r.mapcalc --o expr="elev_cross = float(col()* 5)"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 1 || row() == 5, null(), volume)"

# We @test the creation of slices and a cross section of the voxel map. Reference data
# for @raster map validation is located in the r3.cross.rast source directory.
# Slice 0 and 1 should be identical. The last slice should consist only of grass NULL values
r3.cross.rast --o input=volume_null elevation=elev_0 output=test_cross_section_slice_0
r3.cross.rast --o input=volume_null elevation=elev_1 output=test_cross_section_slice_1
r3.cross.rast --o input=volume_null elevation=elev_2 output=test_cross_section_slice_2
r3.cross.rast --o input=volume_null elevation=elev_3 output=test_cross_section_slice_3
r3.cross.rast --o input=volume_null elevation=elev_4 output=test_cross_section_slice_4
r3.cross.rast --o input=volume_null elevation=elev_5 output=test_cross_section_slice_5
r3.cross.rast --o input=volume_null elevation=elev_NAN output=test_cross_section_slice_NAN
r3.cross.rast --o input=volume_null elevation=elev_cross output=test_cross_section_result
</source>

The following reference files are located in the r3.cross.rast directory:

<pre>
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_result.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_0.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_1.ref
-rw-r--r-- 1 soeren users 269 16. Jun 18:14 test_cross_section_slice_2.ref
-rw-r--r-- 1 soeren users 273 16. Jun 18:14 test_cross_section_slice_3.ref
-rw-r--r-- 1 soeren users 276 16. Jun 18:14 test_cross_section_slice_4.ref
-rw-r--r-- 1 soeren users 279 16. Jun 18:14 test_cross_section_slice_5.ref
-rw-r--r-- 1 soeren users 222 16. Jun 18:14 test_cross_section_slice_NAN.ref
</pre>

=== test.r3.out.ascii.sh ===

<source lang="bash">
# Tests for r3.out.ascii and r3.in.ascii
# This script tests the export of voxel data using r3.out.ascii
# as well as the import of the generated data with r3.in.ascii
# using different row and depth ordering options.

# We set up a specific region in the
# @preprocess step of this test. We generate
# voxel data with r3.mapcalc. The region setting
# should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now create several (float, double, null value) voxel map
# with value = col + row + depth.
r3.mapcalc --o expr="volume_float = float(col() + row() + depth())"
r3.mapcalc --o expr="volume_double = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_float_null = if(row() == 1 || row() == 5, null(), volume_float)"
r3.mapcalc --o expr="volume_double_null = if(row() == 1 || row() == 5, null(), volume_double)"

# We export float data in the first @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_float_null output=test_float_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_float_null output=test_float_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_float_null output=test_float_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_float_null output=test_float_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The rsult of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_float_null output=test_float_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_float_null output=test_float_nsbt_null_grass6_comp_3.txt dp=3 null=*

# We export double data in the second @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling. Its hte same
# procedure as with float data
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_double_null output=test_double_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_double_null output=test_double_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_double_null output=test_double_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_double_null output=test_double_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The result of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_double_null output=test_double_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_double_null output=test_double_nsbt_null_grass6_comp_3.txt dp=3 null=*

# In the third @test we import all the generated data using r3.in.ascii
# The created @raster maps should be identical to the map "volume_double_null"
# The export of the created g3d map should use as @precision=0 for data validation
# The same raster name is used for all the imported data and so for the validation reference file
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_snbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nstb_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null.txt nv=*
# Different precision and null values than default
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_prec5.txt nv=-1000
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null_prec8.txt nv=-2000
# Any row or depth order should be ignored in case grass6 compatibility is enabled
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_grass6_comp_1.txt

# In this @preprocess step for the last test we create a large region and
# generate large input data to test the handling of large files
g.region s=0 n=800 w=0 e=1200 b=0 t=50 res=10 res3=1.5 -p3
r3.mapcalc --o expr="volume_double_large = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_double_null_large = if(row() == 1 || row() == 5, null(), volume_double_large)"

# Now @test the export and import of large data without validation
r3.out.ascii --o input=volume_double_null_large output=test_double_nsbt_null_large.txt dp=0 null=*
r3.in.ascii --o output=test_double_nsbt_null_large input=test_double_nsbt_null_large.txt nv=*
# Just for the logs
r3.info test_double_nsbt_null_large
</source>

The following reference files are located in the r3.out.ascii directory:

<pre>
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_double_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_double_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_double_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_sntb_null.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_float_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_float_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_float_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_sntb_null.ref
</pre>

== Test framework: ==

What the test framework should do:

* Creation of a test mapset for each test case in a specific test location located in the grass sources
* Setting the environment variables to the test location and grass installation (grass environment to run modules)
* Parsing and interpretation and execution of test scripts
* Support of several test scripts in a single module directory
* Run of location specific test scripts (only LL or UTM test scripts)
* Handles module test results codes and stderr messages
* Validation of module output based on reference data and data type annotations in the test description
* Creates a HTML report for single modules and the whole test run
* Deletion of the generated test mapset to clean up the test location

== Implementation ==

* All test cases must be implemented as text files in shell style including annotations in comment blocks
* The test framework should be implemented in Python, parsing and analyzing and executing the test cases line by line
* The Make-System must be modified to start the tests by typing "make tests"

=== Test framework Python approach ===

I suggest the following Python classes:
* TestBase class - implements the test logic
** LatLongTest class - for LatLong test location initialization and test run, derived from TestBase class
** UTMTest class - for UTM test location initialization and test run, derived from TestBase class
* A CommandBase class - implements command line specific methods and attributes and executes a command, logging return value and stderr using the subprocess module
** PreProcess class - derived from CommandBase class for preprocess execution
** TestCase class - derived from CommandBase class for test execution
* ...

The TestBase class implementing the following methods:

* StartGrassSession
** Abstract method, should be overwritten in a subclass
* Run
** Calls StartGrassSession
** Calls CreateTestMapset
** Calls ExecuteAll
* CreateTestMapset
** Creates a temporary mapset for the test using g.mapset
* CreateExecutionOrder
** Reads the entire test case into memory and parses the file line by line
** Creates the execution order list as internal structure to store specific execution settings
** For each command in the test case a specific CommandBase object is created and stored in the execution order list
** TestCase objects store the validation type (@file, ...) and the validation precision (@precision=1) ... and maybe more
* ExecuteAll
** Calls ExecuteTest or ExecutePreProcess for each entry in the execution order list
** Summarize the HTML and text summary content for each entry in the list
* ExecuteTest
** Execute a single test command using the TestCase object
** Logs stderr and return value from TestCase object
** Analyses return value and stderr in case of an error
** Checks for new generated maps/files of the command
** Checks if reference files are present
** Export data with data specific commands (r/r3/v.out.ascii, r/r3.colors.out, ...)
** Compares reference files with exported files
** Creates HTML and text logfile entry
* CheckForReferenceFiles
** Lists all available reference files of a directory in an internal dict, base name, path and full name are stored
* ExecutePreprocess
** Execute a single preprocess command using the PreProcess object
** Logs stderr and return value from PreProcess object
** Analyses return value and stderr in case of an error
** Creates HTML and text logfile entry
* CompareVectorMap
** Exports vector map with v.out.ascii using the default or specific TestCase precision
** Compares exported file with reference file
* CompareRasterMap
** Export raster map with r.out.ascii using the default or specific TestCase precision
** Compares exported file with reference file
* CompareRaster3dMaps
** Exports raster3d map with r3.out.ascii using the default or specific TestCase precision
** Compares exported file with reference file
* CompareColor
** Export raster color with r.colors.out
** Compares exported file with reference file
* CompareColor3d
** Export raster3d color with r3.colors.out
** Compares exported file with reference file
* CreateHTMLTestSummary
* CreateTextTestSummary
* CleanUp
** Remove the temporary test mapset and all generated test files
* ... many more

The LatLongTest implements the following method:

* StartGrassSession
** starts the grass7 session in a LatLong test location

The UTMTest implements the following method:

* StartGrassSession
** starts the grass7 session in an UTM test location

The CommandBase class:

* Uses the subprocess module to execute a command
* Is able to identify some shell specific commands in the command line ("&&, |, <, >")
* Acts as a very simple shell interpreter
** In case if "|" connects multiple commands in a command line with subprocess.PIPE
** In case of ">" or "<" uses stdout or stdin io
** No support for complex shell functionality (for, test, ...)

== Timeline and status ==

TBD

== Interested people ==

* [[User:huhabla | Sören Gebbert]]
* [[User:AnneGhisla| Anne Ghisla]]
* [[User:Landa|Martin Landa]]
* Add your name here

[[Category: Development]]
[[Category: Testing]]

Test Suite

2011-07-01T19:04:58Z

⚠️Huhabla: /* Test framework Python approach */

__TOC__

= GRASS Test Suite =

We aim at creating a comprehensive test suite for GRASS modules and libraries.

== Background ==

See what has been done so far by Sören Gebbert and others here: [[Development#QA]] and the good [[http://www.vtk.org/Wiki/images/b/bc/Testing.cover.txt | VKT test suite]]

Keep an eye on [[GRASS_7_ideas_collection#Complete_GRASS_Test_Suite:_see_activity_on_Test_Suite_development_page | GRASS 7 ideas collection]]

== Main picture ==

We plan to run unittests and integration tests for both libraries and modules. The test suite will be run after compilation, with a command like:

$ make tests [ proj ]

Options:
* proj: run the tests with a [list of] CRS, so that reprojection and map unit handling are tested.
* ...

Tests are executed recursively. If the "make tests" command is executed in the root source folder all libraries and modules are tested. To test only the libraries you need to switch in the '''lib''' directory and execute "make tests". If you want to test only raster modules switch into the '''raster''' directory and run "make tests", same for other modules directories. To test a single module switch into the module directory and run "make tests".

== Tests ==

=== Modules ===
Tests are targeted to cover all modules as well as library test modules.

The modules tests should as independent as possible from other GRASS modules.

Tests are written as simple shell script with annotations. Test script should start with '''test.''' followed by the module name i.e. '''r.mapcalc.''' and further ending with '''.sh'''. Example '''test.r.mapcalc.1.sh'''. All test should be well documented using shell comments.

The framework will execute all test scripts starting with '''test.''' and ending with '''.sh''' located in module or library directories.

Annotations are integrated in the test documentation (simple shell comments) and specify pre-processing steps, the tests and the type of the data to validate. The following annotations should be supported:

* The '''@preprocess''' annotation
** All commands below this annotation are handled as preprocessing steps for the tests.
** If any of the preprocess commands fail, the framework should stop testing an create a detailed error report.
** Preprocessing steps may be data generation, region settings and so on.
** The preprocess annotation is valid till a '''@test''' annotation specifies the begin of a test
** Preprocess annotations can be specified at between tests
* The '''@test''' annotation
** All command below a this annotation are handled as tests by the framework
** The test annotation must be integrated in the comment block which describes the test
** Data validation is performed by the framework for tests if reference data is present
** The test annotation is valid till a '''@preprocess''' annotation specifies the begin of a preprocess block for further test runs
** The data type annotations
*** Data type annotations should be specified in the same comment block as the '''@test''' annotation
*** Data type annotations specify the grass data types which should be validated with reference data
*** The following data type annotations should be specified
**** '''@file''' the framework should compare the reference data with files
**** '''@raster''' the framework should compare the reference data with raster maps using r.out.ascii for export
**** '''@vector''' the framework should compare the reference data with vector maps using v.out.ascii for export
**** '''@raster3d''' the framework should compare the reference data with raster3d maps using r3.out.ascii for export
**** '''@color''' the framework should compare the reference data with color rules using r.color.out for export
**** '''@color3d''' the framework should compare the reference data with 3d color rules using r3.color.out for export
**** '''@table''' the framework should compare the reference data with SQL tables using db.select for export
**** ... please add more
** The '''@precision=[positive integer]''' annotation
*** Should be located in a test comment block
*** Specifies the precision to use to export grass data for validation with reference files
*** In case the precision is not provided the default behavior of the export module is used

Reference data for validation must be located in the module/library directory. The reference data names must be identical with the generated data (files, maps, ...) except that reference data always has a '''.ref''' suffix.

Tests are in each module's and in each library's folder. To test library functions special modules must be implemented. Library test modules test the library functions directly and should be written in C. Have a look at the test directories in the g3d, gpde and gmath libraries of grass7.

Framework should be able to generate and compare grass data types: raster, vector, raster3d, general, db, icon, imagery, d.*?

wxGUI testing should be tested separately.

Automated tests on server generates HTML report. Test several platforms.

Here some examples already available in grass7:

=== test.v.random.sh ===

<source lang="bash">
# This is a simple test for v.random
# We create several identical pseudo random points maps :)
# using the seed option for rand and drand48

# In the @preprocess step we set up a suitable region
g.region n=80 s=0 w=0 e=120 res=10 -p

# First @test the rand function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -z output=test_random_vect_1 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -z output=test_random_vect_2 n=20 zmin=0 zmax=100 column=height seed=501

# Second @test the drand48 function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -zd output=test_random_vect_3 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -zd output=test_random_vect_4 n=20 zmin=0 zmax=100 column=height seed=501

# Export the generated data as references
# v.out.ascii --o format=point dp=3 input=test_random_vect_1 output=test_random_vect_1.ref
# db.select "select * from test_random_vect_2" > test_random_vect_2.ref
# v.out.ascii --o format=point dp=3 input=test_random_vect_3 output=test_random_vect_3.ref
# db.select "select * from test_random_vect_4" > test_random_vect_4.ref
</source>

The following reference files are located in the v.random directory:
<pre>
-rw-r--r-- 1 soeren users 460 18. Jun 01:20 test_random_vect_1.ref
-rw-r--r-- 1 soeren users 257 18. Jun 01:20 test_random_vect_2.ref
-rw-r--r-- 1 soeren users 455 18. Jun 01:20 test_random_vect_3.ref
-rw-r--r-- 1 soeren users 256 18. Jun 01:20 test_random_vect_4.ref
</pre>

=== test.r3.out.vtk.sh ===

<source lang="bash">
# This script tests the export of voxel data
# into the VTK format. Almost all options of
# r3.out.vtk are tested. Validation data for each test
# is located in the module source directory

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now generate two elevation maps, we have 8 rows and use
# them for elevation computation. The rows are counted from north
# to south. So in the south the elevation must have a maximum.
r.mapcalc --o expr="elev_bottom = row()"
r.mapcalc --o expr="elev_top = row() + 50"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 2 || row() == 7, null(), volume)"
# Create the rgb maps
r3.mapcalc --o expr="volume_rgb = volume_null * 5"

# The first @test just exports the volume map as cell and point data
# using a low precision and replaces the default null value with 0
# the created @files should be compared with the reference data
r3.out.vtk --o input=volume_null output=test_volume_null_1_cells.vtk dp=3 null=0
r3.out.vtk -p --o input=volume_null output=test_volume_null_1_points.vtk dp=3 null=0

# The second @test adds rgb and vector maps. We re-use the created volume map
# for vector creation. The rgb value must range fom 0 - 255. The generated @files
# should be compared with the reference data.
r3.out.vtk --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_cells_rgb_vect.vtk dp=3 null=-1.0
r3.out.vtk -p --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_points_rgb_vect.vtk dp=3 null=-1.0

# The third @test uses raster maps to create volume data with an elevation surface
# The maximum elevation should be in the south. Reference @files are present for validation.
r3.out.vtk -s --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_cells_elevation.vtk dp=3 null=0
r3.out.vtk -sp --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_points_elevation.vtk dp=3 null=0
</source>

The following reference files are located in the r3.out.vtk directory:
<pre>
-rw-r--r-- 1 soeren users 104556 16. Jun 18:14 test_volume_null_1_cells_elevation.ref
-rw-r--r-- 1 soeren users 3434 16. Jun 18:14 test_volume_null_1_cells.ref
-rw-r--r-- 1 soeren users 22749 16. Jun 18:14 test_volume_null_1_cells_rgb_vect.ref
-rw-r--r-- 1 soeren users 13360 16. Jun 18:14 test_volume_null_1_points_elevation.ref
-rw-r--r-- 1 soeren users 3435 16. Jun 18:14 test_volume_null_1_points.ref
-rw-r--r-- 1 soeren users 22750 16. Jun 18:14 test_volume_null_1_points_rgb_vect.ref
</pre>

=== test.r3.cross.rast.sh ===

<source lang="bash">
# This script tests the r3.cross.rast module to compute
# cross section raster maps based on a raster3d and elevation map

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=100 b=0 t=50 res=10 res3=10 -p3
# We create several elevation maps to create slices of the voxel map
# We start from bottom and raise to the top. Value equal or greater 50
# should generate grass NULL values
r.mapcalc --o expr="elev_0 = 0"
r.mapcalc --o expr="elev_1 = 5"
r.mapcalc --o expr="elev_2 = 15"
r.mapcalc --o expr="elev_3 = 25"
r.mapcalc --o expr="elev_4 = 35"
r.mapcalc --o expr="elev_5 = 45"
r.mapcalc --o expr="elev_NAN = 50"
r.mapcalc --o expr="elev_cross = float(col()* 5)"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 1 || row() == 5, null(), volume)"

# We @test the creation of slices and a cross section of the voxel map. Reference data
# for @raster map validation is located in the r3.cross.rast source directory.
# Slice 0 and 1 should be identical. The last slice should consist only of grass NULL values
r3.cross.rast --o input=volume_null elevation=elev_0 output=test_cross_section_slice_0
r3.cross.rast --o input=volume_null elevation=elev_1 output=test_cross_section_slice_1
r3.cross.rast --o input=volume_null elevation=elev_2 output=test_cross_section_slice_2
r3.cross.rast --o input=volume_null elevation=elev_3 output=test_cross_section_slice_3
r3.cross.rast --o input=volume_null elevation=elev_4 output=test_cross_section_slice_4
r3.cross.rast --o input=volume_null elevation=elev_5 output=test_cross_section_slice_5
r3.cross.rast --o input=volume_null elevation=elev_NAN output=test_cross_section_slice_NAN
r3.cross.rast --o input=volume_null elevation=elev_cross output=test_cross_section_result
</source>

The following reference files are located in the r3.cross.rast directory:

<pre>
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_result.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_0.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_1.ref
-rw-r--r-- 1 soeren users 269 16. Jun 18:14 test_cross_section_slice_2.ref
-rw-r--r-- 1 soeren users 273 16. Jun 18:14 test_cross_section_slice_3.ref
-rw-r--r-- 1 soeren users 276 16. Jun 18:14 test_cross_section_slice_4.ref
-rw-r--r-- 1 soeren users 279 16. Jun 18:14 test_cross_section_slice_5.ref
-rw-r--r-- 1 soeren users 222 16. Jun 18:14 test_cross_section_slice_NAN.ref
</pre>

=== test.r3.out.ascii.sh ===

<source lang="bash">
# Tests for r3.out.ascii and r3.in.ascii
# This script tests the export of voxel data using r3.out.ascii
# as well as the import of the generated data with r3.in.ascii
# using different row and depth ordering options.

# We set up a specific region in the
# @preprocess step of this test. We generate
# voxel data with r3.mapcalc. The region setting
# should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now create several (float, double, null value) voxel map
# with value = col + row + depth.
r3.mapcalc --o expr="volume_float = float(col() + row() + depth())"
r3.mapcalc --o expr="volume_double = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_float_null = if(row() == 1 || row() == 5, null(), volume_float)"
r3.mapcalc --o expr="volume_double_null = if(row() == 1 || row() == 5, null(), volume_double)"

# We export float data in the first @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_float_null output=test_float_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_float_null output=test_float_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_float_null output=test_float_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_float_null output=test_float_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The rsult of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_float_null output=test_float_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_float_null output=test_float_nsbt_null_grass6_comp_3.txt dp=3 null=*

# We export double data in the second @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling. Its hte same
# procedure as with float data
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_double_null output=test_double_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_double_null output=test_double_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_double_null output=test_double_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_double_null output=test_double_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The result of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_double_null output=test_double_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_double_null output=test_double_nsbt_null_grass6_comp_3.txt dp=3 null=*

# In the third @test we import all the generated data using r3.in.ascii
# The created @raster maps should be identical to the map "volume_double_null"
# The export of the created g3d map should use as @precision=0 for data validation
# The same raster name is used for all the imported data and so for the validation reference file
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_snbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nstb_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null.txt nv=*
# Different precision and null values than default
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_prec5.txt nv=-1000
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null_prec8.txt nv=-2000
# Any row or depth order should be ignored in case grass6 compatibility is enabled
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_grass6_comp_1.txt

# In this @preprocess step for the last test we create a large region and
# generate large input data to test the handling of large files
g.region s=0 n=800 w=0 e=1200 b=0 t=50 res=10 res3=1.5 -p3
r3.mapcalc --o expr="volume_double_large = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_double_null_large = if(row() == 1 || row() == 5, null(), volume_double_large)"

# Now @test the export and import of large data without validation
r3.out.ascii --o input=volume_double_null_large output=test_double_nsbt_null_large.txt dp=0 null=*
r3.in.ascii --o output=test_double_nsbt_null_large input=test_double_nsbt_null_large.txt nv=*
# Just for the logs
r3.info test_double_nsbt_null_large
</source>

The following reference files are located in the r3.out.ascii directory:

<pre>
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_double_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_double_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_double_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_sntb_null.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_float_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_float_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_float_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_sntb_null.ref
</pre>

== Test framework: ==

What the test framework should do:

* Creation of a test mapset for each test case in a specific test location located in the grass sources
* Setting the environment variables to the test location and grass installation (grass environment to run modules)
* Parsing and interpretation and execution of test scripts
* Support of several test scripts in a single module directory
* Run of location specific test scripts (only LL or UTM test scripts)
* Handles module test results codes and stderr messages
* Validation of module output based on reference data and data type annotations in the test description
* Creates a HTML report for single modules and the whole test run
* Deletion of the generated test mapset to clean up the test location

== Implementation ==

* All test cases must be implemented as text files in shell style including annotations in comment blocks
* The test framework should be implemented in Python, parsing and analyzing and executing the test cases line by line
* The Make-System must be modified to start the tests by typing "make tests"

=== Test framework Python approach ===

I suggest the following Python classes:
* Base test class - implements the test logic
** LatLong test class - for LatLong test location initialization and test run, derived from base test class
** UTM test class - for UTM test location initialization and test run, derived from base test class
* A command class - implements command line specific methods and attributes and executes a command, logging return value and stderr
** PreProcess class - derived from command class for preprocess execution
** TestCase class - derived from command class for test execution
* ...

The base class implementing the following methods:

* CreateTestMapset
** Creates a temporary mapset for the test
* CreateExecutionOrder
** Reads the entire test case into memory and parses the file line by line
** Creates the execution order list as internal structure to store specific execution settings
** For each command in the test case a specific command object is created and stored in the execution order list
** TestCase objects store the validation type (@file, ...) and the validation precision (@precision=1) ... and maybe more
* ExecuteAll
** Calls ExecuteTest or ExecutePreProcess for each entry in the execution order list
* ExecuteTest
** Execute a single test command using the TestCase object
** Logs stderr and return value from TestCase object
** Analyses return value and stderr in case of an error
** Checks for new generated maps/files of the command
** Checks if reference files are present
** Export data with data specific commands (r/r3/v.out.ascii, r/r3.colors.out, ...)
** Compares reference files with exported files
** Creates HTML and text logfile entry
* CheckForReferenceFiles
** Lists all available reference files of a directory in an internal dict, base name, path and full name are stored
* ExecutePreprocess
** Execute a single preprocess command using the PreProcess object
** Logs stderr and return value from PreProcess object
** Analyses return value and stderr in case of an error
** Creates HTML and text logfile entry
* CompareVectorMap
** Exports vector map with v.out.ascii using the default or specific TestCase precision
** Compares exported file with reference file
* CompareRasterMap
** Export raster map with r.out.ascii using the default or specific TestCase precision
** Compares exported file with reference file
* CompareRaster3dMaps
** Exports raster3d map with r3.out.ascii using the default or specific TestCase precision
** Compares exported file with reference file
* CompareColor
** Export raster color with r.colors.out
** Compares exported file with reference file
* CompareColor3d
** Export raster3d color with r3.colors.out
** Compares exported file with reference file
* CreateHTMLTestSummary
* CreateTextTestSummary
* CleanUp
** Remove the temporary test mapset and all generated test files

== Timeline and status ==

TBD

== Interested people ==

* [[User:huhabla | Sören Gebbert]]
* [[User:AnneGhisla| Anne Ghisla]]
* [[User:Landa|Martin Landa]]
* Add your name here

[[Category: Development]]
[[Category: Testing]]

Test Suite

2011-07-01T18:49:40Z

⚠️Huhabla:

__TOC__

= GRASS Test Suite =

We aim at creating a comprehensive test suite for GRASS modules and libraries.

== Background ==

See what has been done so far by Sören Gebbert and others here: [[Development#QA]] and the good [[http://www.vtk.org/Wiki/images/b/bc/Testing.cover.txt | VKT test suite]]

Keep an eye on [[GRASS_7_ideas_collection#Complete_GRASS_Test_Suite:_see_activity_on_Test_Suite_development_page | GRASS 7 ideas collection]]

== Main picture ==

We plan to run unittests and integration tests for both libraries and modules. The test suite will be run after compilation, with a command like:

$ make tests [ proj ]

Options:
* proj: run the tests with a [list of] CRS, so that reprojection and map unit handling are tested.
* ...

Tests are executed recursively. If the "make tests" command is executed in the root source folder all libraries and modules are tested. To test only the libraries you need to switch in the '''lib''' directory and execute "make tests". If you want to test only raster modules switch into the '''raster''' directory and run "make tests", same for other modules directories. To test a single module switch into the module directory and run "make tests".

== Tests ==

=== Modules ===
Tests are targeted to cover all modules as well as library test modules.

The modules tests should as independent as possible from other GRASS modules.

Tests are written as simple shell script with annotations. Test script should start with '''test.''' followed by the module name i.e. '''r.mapcalc.''' and further ending with '''.sh'''. Example '''test.r.mapcalc.1.sh'''. All test should be well documented using shell comments.

The framework will execute all test scripts starting with '''test.''' and ending with '''.sh''' located in module or library directories.

Annotations are integrated in the test documentation (simple shell comments) and specify pre-processing steps, the tests and the type of the data to validate. The following annotations should be supported:

* The '''@preprocess''' annotation
** All commands below this annotation are handled as preprocessing steps for the tests.
** If any of the preprocess commands fail, the framework should stop testing an create a detailed error report.
** Preprocessing steps may be data generation, region settings and so on.
** The preprocess annotation is valid till a '''@test''' annotation specifies the begin of a test
** Preprocess annotations can be specified at between tests
* The '''@test''' annotation
** All command below a this annotation are handled as tests by the framework
** The test annotation must be integrated in the comment block which describes the test
** Data validation is performed by the framework for tests if reference data is present
** The test annotation is valid till a '''@preprocess''' annotation specifies the begin of a preprocess block for further test runs
** The data type annotations
*** Data type annotations should be specified in the same comment block as the '''@test''' annotation
*** Data type annotations specify the grass data types which should be validated with reference data
*** The following data type annotations should be specified
**** '''@file''' the framework should compare the reference data with files
**** '''@raster''' the framework should compare the reference data with raster maps using r.out.ascii for export
**** '''@vector''' the framework should compare the reference data with vector maps using v.out.ascii for export
**** '''@raster3d''' the framework should compare the reference data with raster3d maps using r3.out.ascii for export
**** '''@color''' the framework should compare the reference data with color rules using r.color.out for export
**** '''@color3d''' the framework should compare the reference data with 3d color rules using r3.color.out for export
**** '''@table''' the framework should compare the reference data with SQL tables using db.select for export
**** ... please add more
** The '''@precision=[positive integer]''' annotation
*** Should be located in a test comment block
*** Specifies the precision to use to export grass data for validation with reference files
*** In case the precision is not provided the default behavior of the export module is used

Reference data for validation must be located in the module/library directory. The reference data names must be identical with the generated data (files, maps, ...) except that reference data always has a '''.ref''' suffix.

Tests are in each module's and in each library's folder. To test library functions special modules must be implemented. Library test modules test the library functions directly and should be written in C. Have a look at the test directories in the g3d, gpde and gmath libraries of grass7.

Framework should be able to generate and compare grass data types: raster, vector, raster3d, general, db, icon, imagery, d.*?

wxGUI testing should be tested separately.

Automated tests on server generates HTML report. Test several platforms.

Here some examples already available in grass7:

=== test.v.random.sh ===

<source lang="bash">
# This is a simple test for v.random
# We create several identical pseudo random points maps :)
# using the seed option for rand and drand48

# In the @preprocess step we set up a suitable region
g.region n=80 s=0 w=0 e=120 res=10 -p

# First @test the rand function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -z output=test_random_vect_1 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -z output=test_random_vect_2 n=20 zmin=0 zmax=100 column=height seed=501

# Second @test the drand48 function. Create a 3d vector map with attribute table
# The validation is based on @vector map with a @precision=3
v.random --o -zd output=test_random_vect_3 n=20 zmin=0 zmax=100 seed=501
# Now the attribute @table should be validated. Booth maps are identical
v.random --o -zd output=test_random_vect_4 n=20 zmin=0 zmax=100 column=height seed=501

# Export the generated data as references
# v.out.ascii --o format=point dp=3 input=test_random_vect_1 output=test_random_vect_1.ref
# db.select "select * from test_random_vect_2" > test_random_vect_2.ref
# v.out.ascii --o format=point dp=3 input=test_random_vect_3 output=test_random_vect_3.ref
# db.select "select * from test_random_vect_4" > test_random_vect_4.ref
</source>

The following reference files are located in the v.random directory:
<pre>
-rw-r--r-- 1 soeren users 460 18. Jun 01:20 test_random_vect_1.ref
-rw-r--r-- 1 soeren users 257 18. Jun 01:20 test_random_vect_2.ref
-rw-r--r-- 1 soeren users 455 18. Jun 01:20 test_random_vect_3.ref
-rw-r--r-- 1 soeren users 256 18. Jun 01:20 test_random_vect_4.ref
</pre>

=== test.r3.out.vtk.sh ===

<source lang="bash">
# This script tests the export of voxel data
# into the VTK format. Almost all options of
# r3.out.vtk are tested. Validation data for each test
# is located in the module source directory

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now generate two elevation maps, we have 8 rows and use
# them for elevation computation. The rows are counted from north
# to south. So in the south the elevation must have a maximum.
r.mapcalc --o expr="elev_bottom = row()"
r.mapcalc --o expr="elev_top = row() + 50"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 2 || row() == 7, null(), volume)"
# Create the rgb maps
r3.mapcalc --o expr="volume_rgb = volume_null * 5"

# The first @test just exports the volume map as cell and point data
# using a low precision and replaces the default null value with 0
# the created @files should be compared with the reference data
r3.out.vtk --o input=volume_null output=test_volume_null_1_cells.vtk dp=3 null=0
r3.out.vtk -p --o input=volume_null output=test_volume_null_1_points.vtk dp=3 null=0

# The second @test adds rgb and vector maps. We re-use the created volume map
# for vector creation. The rgb value must range fom 0 - 255. The generated @files
# should be compared with the reference data.
r3.out.vtk --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_cells_rgb_vect.vtk dp=3 null=-1.0
r3.out.vtk -p --o rgbmaps=volume_rgb,volume_rgb,volume_rgb vectormaps=volume_null,volume_null,volume_null input=volume_null output=test_volume_null_1_points_rgb_vect.vtk dp=3 null=-1.0

# The third @test uses raster maps to create volume data with an elevation surface
# The maximum elevation should be in the south. Reference @files are present for validation.
r3.out.vtk -s --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_cells_elevation.vtk dp=3 null=0
r3.out.vtk -sp --o top=elev_top bottom=elev_bottom input=volume_null output=test_volume_null_1_points_elevation.vtk dp=3 null=0
</source>

The following reference files are located in the r3.out.vtk directory:
<pre>
-rw-r--r-- 1 soeren users 104556 16. Jun 18:14 test_volume_null_1_cells_elevation.ref
-rw-r--r-- 1 soeren users 3434 16. Jun 18:14 test_volume_null_1_cells.ref
-rw-r--r-- 1 soeren users 22749 16. Jun 18:14 test_volume_null_1_cells_rgb_vect.ref
-rw-r--r-- 1 soeren users 13360 16. Jun 18:14 test_volume_null_1_points_elevation.ref
-rw-r--r-- 1 soeren users 3435 16. Jun 18:14 test_volume_null_1_points.ref
-rw-r--r-- 1 soeren users 22750 16. Jun 18:14 test_volume_null_1_points_rgb_vect.ref
</pre>

=== test.r3.cross.rast.sh ===

<source lang="bash">
# This script tests the r3.cross.rast module to compute
# cross section raster maps based on a raster3d and elevation map

# We need to set a specific region in the
# @preprocess step of this test. We generate
# raster and voxel data with r.mapcalc and r3.mapcalc
# The region setting should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=100 b=0 t=50 res=10 res3=10 -p3
# We create several elevation maps to create slices of the voxel map
# We start from bottom and raise to the top. Value equal or greater 50
# should generate grass NULL values
r.mapcalc --o expr="elev_0 = 0"
r.mapcalc --o expr="elev_1 = 5"
r.mapcalc --o expr="elev_2 = 15"
r.mapcalc --o expr="elev_3 = 25"
r.mapcalc --o expr="elev_4 = 35"
r.mapcalc --o expr="elev_5 = 45"
r.mapcalc --o expr="elev_NAN = 50"
r.mapcalc --o expr="elev_cross = float(col()* 5)"
# Now create a voxel map with value = col + row + depth.
r3.mapcalc --o expr="volume = col() + row() + depth()"
# Add null value information
r3.mapcalc --o expr="volume_null = if(row() == 1 || row() == 5, null(), volume)"

# We @test the creation of slices and a cross section of the voxel map. Reference data
# for @raster map validation is located in the r3.cross.rast source directory.
# Slice 0 and 1 should be identical. The last slice should consist only of grass NULL values
r3.cross.rast --o input=volume_null elevation=elev_0 output=test_cross_section_slice_0
r3.cross.rast --o input=volume_null elevation=elev_1 output=test_cross_section_slice_1
r3.cross.rast --o input=volume_null elevation=elev_2 output=test_cross_section_slice_2
r3.cross.rast --o input=volume_null elevation=elev_3 output=test_cross_section_slice_3
r3.cross.rast --o input=volume_null elevation=elev_4 output=test_cross_section_slice_4
r3.cross.rast --o input=volume_null elevation=elev_5 output=test_cross_section_slice_5
r3.cross.rast --o input=volume_null elevation=elev_NAN output=test_cross_section_slice_NAN
r3.cross.rast --o input=volume_null elevation=elev_cross output=test_cross_section_result
</source>

The following reference files are located in the r3.cross.rast directory:

<pre>
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_result.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_0.ref
-rw-r--r-- 1 soeren users 264 16. Jun 18:14 test_cross_section_slice_1.ref
-rw-r--r-- 1 soeren users 269 16. Jun 18:14 test_cross_section_slice_2.ref
-rw-r--r-- 1 soeren users 273 16. Jun 18:14 test_cross_section_slice_3.ref
-rw-r--r-- 1 soeren users 276 16. Jun 18:14 test_cross_section_slice_4.ref
-rw-r--r-- 1 soeren users 279 16. Jun 18:14 test_cross_section_slice_5.ref
-rw-r--r-- 1 soeren users 222 16. Jun 18:14 test_cross_section_slice_NAN.ref
</pre>

=== test.r3.out.ascii.sh ===

<source lang="bash">
# Tests for r3.out.ascii and r3.in.ascii
# This script tests the export of voxel data using r3.out.ascii
# as well as the import of the generated data with r3.in.ascii
# using different row and depth ordering options.

# We set up a specific region in the
# @preprocess step of this test. We generate
# voxel data with r3.mapcalc. The region setting
# should work for UTM and LL test locations
g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
# Now create several (float, double, null value) voxel map
# with value = col + row + depth.
r3.mapcalc --o expr="volume_float = float(col() + row() + depth())"
r3.mapcalc --o expr="volume_double = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_float_null = if(row() == 1 || row() == 5, null(), volume_float)"
r3.mapcalc --o expr="volume_double_null = if(row() == 1 || row() == 5, null(), volume_double)"

# We export float data in the first @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_float_null output=test_float_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_float_null output=test_float_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_float_null output=test_float_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_float_null output=test_float_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_float_null output=test_float_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_float_null output=test_float_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The rsult of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_float_null output=test_float_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_float_null output=test_float_nsbt_null_grass6_comp_3.txt dp=3 null=*

# We export double data in the second @test using different order and precision
# as text @files for valdiation of correct ordering and null data handling. Its hte same
# procedure as with float data
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null.txt dp=0 null=*
r3.out.ascii --o -r input=volume_double_null output=test_double_snbt_null.txt dp=0 null=*
r3.out.ascii --o -d input=volume_double_null output=test_double_nstb_null.txt dp=0 null=*
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null.txt dp=0 null=*
# Different precision and null values than default
r3.out.ascii --o input=volume_double_null output=test_double_nsbt_null_prec5.txt dp=5 null=-1000
r3.out.ascii --o -rd input=volume_double_null output=test_double_sntb_null_prec8.txt dp=8 null=-2000
# Test the no header and grass6 compatibility flags
r3.out.ascii --o -h input=volume_double_null output=test_double_nsbt_null_no_header.txt dp=3 null=*
r3.out.ascii --o -c input=volume_double_null output=test_double_nsbt_null_grass6_comp_1.txt dp=3 null=*
# Any row or depth order should be ignored in case grass6 compatibility is enabled
# The result of comp_1, _2 and _3 must be identical
r3.out.ascii --o -cr input=volume_double_null output=test_double_nsbt_null_grass6_comp_2.txt dp=3 null=*
r3.out.ascii --o -crd input=volume_double_null output=test_double_nsbt_null_grass6_comp_3.txt dp=3 null=*

# In the third @test we import all the generated data using r3.in.ascii
# The created @raster maps should be identical to the map "volume_double_null"
# The export of the created g3d map should use as @precision=0 for data validation
# The same raster name is used for all the imported data and so for the validation reference file
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_snbt_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nstb_null.txt nv=*
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null.txt nv=*
# Different precision and null values than default
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_prec5.txt nv=-1000
r3.in.ascii --o output=test_double_nsbt_null input=test_double_sntb_null_prec8.txt nv=-2000
# Any row or depth order should be ignored in case grass6 compatibility is enabled
r3.in.ascii --o output=test_double_nsbt_null input=test_double_nsbt_null_grass6_comp_1.txt

# In this @preprocess step for the last test we create a large region and
# generate large input data to test the handling of large files
g.region s=0 n=800 w=0 e=1200 b=0 t=50 res=10 res3=1.5 -p3
r3.mapcalc --o expr="volume_double_large = double(col() + row() + depth())"
# Add null value information
r3.mapcalc --o expr="volume_double_null_large = if(row() == 1 || row() == 5, null(), volume_double_large)"

# Now @test the export and import of large data without validation
r3.out.ascii --o input=volume_double_null_large output=test_double_nsbt_null_large.txt dp=0 null=*
r3.in.ascii --o output=test_double_nsbt_null_large input=test_double_nsbt_null_large.txt nv=*
# Just for the logs
r3.info test_double_nsbt_null_large
</source>

The following reference files are located in the r3.out.ascii directory:

<pre>
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_double_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_double_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_double_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_double_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_double_sntb_null.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_1.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_2.ref
-rw-r--r-- 1 soeren users 2875 17. Jun 21:36 test_float_nsbt_null_grass6_comp_3.ref
-rw-r--r-- 1 soeren users 2751 17. Jun 21:36 test_float_nsbt_null_no_header.ref
-rw-r--r-- 1 soeren users 4103 17. Jun 21:36 test_float_nsbt_null_prec5.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nsbt_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_nstb_null.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_snbt_null.ref
-rw-r--r-- 1 soeren users 5183 17. Jun 21:36 test_float_sntb_null_prec8.ref
-rw-r--r-- 1 soeren users 1463 17. Jun 21:36 test_float_sntb_null.ref
</pre>

== Test framework: ==

What the test framework should do:

* Creation of a test mapset for each test case in a specific test location located in the grass sources
* Setting the environment variables to the test location and grass installation (grass environment to run modules)
* Parsing and interpretation and execution of test scripts
* Support of several test scripts in a single module directory
* Run of location specific test scripts (only LL or UTM test scripts)
* Handles module test results codes and stderr messages
* Validation of module output based on reference data and data type annotations in the test description
* Creates a HTML report for single modules and the whole test run
* Deletion of the generated test mapset to clean up the test location

== Implementation ==

* All test cases must be implemented as text files in shell style including annotations in comment blocks
* The test framework should be implemented in Python, parsing and analyzing and executing the test cases line by line
* The Make-System must be modified to start the tests by typing "make tests"

=== Test framework Python approach ===

I suggest the following Python classes:
* Base test class - implements the test logic
** LatLong test class - for LatLong test location initialization and test run, derived from base test class
** UTM test class - for UTM test location initialization and test run, derived from base test class
* A command class - implements command line specific methods and attributes and executes a command, logging return value and stderr
** PreProcess class - derived from command class for preprocess execution
** TestCase class - derived from command class for test execution
* ...

The base class implementing the following methods:

* CreateExecutionOrder
** Reads the entire test case into memory and parses the file line by line
** Creates the execution order as internal structure to store specific execution settings
** For each command in the test case a specific command object is created
** TestCase classes store the validation type and the precision ... maybe more
* ExecuteTest
** Exexute a single test command using the TestCase object
** checks for reference files
** Logs stderr and return value from TestCase object
** Analyses return value and stderr in case of an error
** Creates HTML and text logfile entry
* CheckForValidationFiles
* ExecutePreprocess
* CompareVectorMaps
* CompareRasterMaps
* CompareRaster3dMaps
* CompareColor
* CompareColor3d
* CreateHTMLTestSummary
* CreateTextTestSummary

== Timeline and status ==

TBD

== Interested people ==

* [[User:huhabla | Sören Gebbert]]
* [[User:AnneGhisla| Anne Ghisla]]
* [[User:Landa|Martin Landa]]
* Add your name here

[[Category: Development]]
[[Category: Testing]]

Temporal extension for GRASS GIS 7

2011-06-30T05:26:04Z

⚠️Huhabla: /* This page has been moved to New trac based wiki */

= This page has been moved to [http://trac.osgeo.org/grass/wiki/Grass7/TemporalExtension New trac based wiki] =

= Adding the time dimension to GRASS GIS raster, vector and voxel data types for field based applications using a time stamp approach =

== Time stamps in SQL tables ==

Raster, vector and voxel maps in GRASS GIS will have temporal attributes by default:
* Creation time
* Modification time
* An absolute or relative time stamp
** absolute:
*** start date
*** end date
** relative
*** a relative time stamp

To store the time stamps and to enable temporal queries a SQL DBMS, capable of temporal datatypes, will be used. As default a Sqlite3 database will be used to store map specific informations in database files. Additionally Postgresql should be supported too.

In case of SQlite a GRASS SQL database file is created for each mapset in a location. Views are used to access the raster, vector or raster3d map entries of different mapset databases at once.

The time stamps as well as attributes and map specific meta data of all created maps in GRASS GIS will be stored in SQL tables in the GRASS SQL databases. The entries in the SQL tables will be created or updated automatically while creation, modification or removement of maps. For each GRASS datatype (raster, raster3d and vector) four SQL tables will be added to GRASS SQL databases at mapset creation:

* The '''base table''' has an equal layout for raster, vector and raster3d maps. This table stores:
** The '''id''' which is of type string. As '''id''' the raster, raster3d or vector map names should be used, because these must be unique in a mapset and can be used as primary key
** The '''temporal type''' specifies if the time stamp is relative or absolute
** The '''creation date''' is of type datetime
** The '''modification date''' is of type datetime

* The '''absolute time table''' to store the absolute time stamps for each map. The layout is equal for raster, raster3d and vector maps. This table stores:
** The '''id''' as primary key
** The '''start time stamp''' is of type datetime
** The '''end time stamp'''is of type datetime
** The '''time zone'''is of type integer

* The '''relative time table''' to store the relative time stamps for each map. The layout is equal for raster, raster3d and vector maps. This table stores:
** The '''id''' as primary key
** The '''relative time stamp''' is of type datetime

A map can only have an absolute or relative time stamp.

* The '''metadata table''' is specific for each grass data type. It stores the spatial and temporal extent as well as map specific attributes (creator, range, cell type, features, registered spacetime datasets, ...)

In long term these kind of SQL tables may replace the text file based storage of map metadata, database links and time stamps.

== New temporal GRASS datatypes ==

To manage temporal raster, raster3d and vector objects, three new datatypes will be added to GRASS GIS: Spacetime raster, vector and voxel datasets. Additionally thematic spatio-temporal datasets will be added to handle thematic related spacetime datasets of different type.

Maps can be registered and unregistered in spacetime datasets. Maps are registered by id (name). All available spatio-temporal data is availabe in SQL tables. Cross referencing must be implemented (maps storing the spacetime datasets in which they are registered and vis versa)
Spacetime datasets have absolute or relative time type, these types cant be mixed up but converted.

A temporal resolution can be set for each spacetime dataset (1s - decades) defining the granularity of the datasets (like the resolution settings for raster/voxel maps).

The new spacetime datasets are handled like raster or vector maps. They are registered in mapset specific tables with creation and modification date and absolute/relative time stamp.

=== Raster spacetime datasets ===

The raster spacetime datasets store raster map specific attributes and metadata:
* The spatial extent (e, w, n, s)
* The temporal extent (start and end time or duration)
* The data range (min and max)
* The raster datatype (CELL, FCELL, DCELL, MIXED)

All these table entries are computed or updated via trigger from all registered raster maps when maps are added or removed.

Table layout:

The base spacetime tables are equal to the raster/vector and raster3d one.

* '''Spacetime metadata raster table'''
** '''id''' the name of the spacetime raster table
** '''temporal type''' relative or absolute
** '''Raster register table name''' the name of the table storing the ids (names) of all registered raster maps
** '''spatial extent''' (4 columns: e, w, s,n) of all registered raster maps
** '''temporal exten'''t of all registered raster maps
** '''data range''' of all registered raster maps
** ...

=== Raster3d spacetime datasets ===

The raster3d spacetime tables are equal to the raster spacetime tablse, except that the spatial extent is computed based on east, west, south, north, top and bottom.

=== Vector spacetime datasets ===

== New temporal modules ==

New temporal modules must be implemented for registration and un-registration and extraction of raster, voxel and vector maps in süacetime datasets:
* tr.register, tr.unregister, tr.extract
* t3.register, t3.unregister, t3.extract
* tv.register, tv.unregister, tv.extract
* Spacetime modules for resampling, interpolation, time stamp snapping and extraction must be implemented.

== Basic Spatio-temporal algorithms ==

Extraction is based on where SQL statements or specific time stamps. Interpolated maps are created or existing map ids will be returned.
The extraction tool will provide different types of extraction algorithms
Nearest neighbour
Interpolation (only raster and voxel maps) (linear, quadratic, ...) or
first valid time stamp.

tr(3).resample -> will create a new spacetime raster (voxel) datasets with a different spatio-temporal resolution, several methods will be available:
* averaging (mean, median, geometric mean, ...)
* summation, multiplication
* max and min functions

== Implementation details ==

Access to spacetime tables must be implemented as GRASS GIS library:
* Registration and unregistration of maps into spacetime datasets
* Update/creation of base table entries, so the SQL tables can be modified in low level GRASS GIS library functions (creation, deletion of maps)
* Selection of maps from spacetime datasets

Temporal extension for GRASS GIS 7

2011-06-30T05:25:12Z

⚠️Huhabla: /* Adding the time dimension to GRASS GIS raster, vector and voxel data types for field based applications using a time stamp approach */

= This page has been moved to [http://trac.osgeo.org/grass/wiki/Grass7/G3dLib New trac based wiki] =

= Adding the time dimension to GRASS GIS raster, vector and voxel data types for field based applications using a time stamp approach =

== Time stamps in SQL tables ==

Raster, vector and voxel maps in GRASS GIS will have temporal attributes by default:
* Creation time
* Modification time
* An absolute or relative time stamp
** absolute:
*** start date
*** end date
** relative
*** a relative time stamp

To store the time stamps and to enable temporal queries a SQL DBMS, capable of temporal datatypes, will be used. As default a Sqlite3 database will be used to store map specific informations in database files. Additionally Postgresql should be supported too.

In case of SQlite a GRASS SQL database file is created for each mapset in a location. Views are used to access the raster, vector or raster3d map entries of different mapset databases at once.

The time stamps as well as attributes and map specific meta data of all created maps in GRASS GIS will be stored in SQL tables in the GRASS SQL databases. The entries in the SQL tables will be created or updated automatically while creation, modification or removement of maps. For each GRASS datatype (raster, raster3d and vector) four SQL tables will be added to GRASS SQL databases at mapset creation:

* The '''base table''' has an equal layout for raster, vector and raster3d maps. This table stores:
** The '''id''' which is of type string. As '''id''' the raster, raster3d or vector map names should be used, because these must be unique in a mapset and can be used as primary key
** The '''temporal type''' specifies if the time stamp is relative or absolute
** The '''creation date''' is of type datetime
** The '''modification date''' is of type datetime

* The '''absolute time table''' to store the absolute time stamps for each map. The layout is equal for raster, raster3d and vector maps. This table stores:
** The '''id''' as primary key
** The '''start time stamp''' is of type datetime
** The '''end time stamp'''is of type datetime
** The '''time zone'''is of type integer

* The '''relative time table''' to store the relative time stamps for each map. The layout is equal for raster, raster3d and vector maps. This table stores:
** The '''id''' as primary key
** The '''relative time stamp''' is of type datetime

A map can only have an absolute or relative time stamp.

* The '''metadata table''' is specific for each grass data type. It stores the spatial and temporal extent as well as map specific attributes (creator, range, cell type, features, registered spacetime datasets, ...)

In long term these kind of SQL tables may replace the text file based storage of map metadata, database links and time stamps.

== New temporal GRASS datatypes ==

To manage temporal raster, raster3d and vector objects, three new datatypes will be added to GRASS GIS: Spacetime raster, vector and voxel datasets. Additionally thematic spatio-temporal datasets will be added to handle thematic related spacetime datasets of different type.

Maps can be registered and unregistered in spacetime datasets. Maps are registered by id (name). All available spatio-temporal data is availabe in SQL tables. Cross referencing must be implemented (maps storing the spacetime datasets in which they are registered and vis versa)
Spacetime datasets have absolute or relative time type, these types cant be mixed up but converted.

A temporal resolution can be set for each spacetime dataset (1s - decades) defining the granularity of the datasets (like the resolution settings for raster/voxel maps).

The new spacetime datasets are handled like raster or vector maps. They are registered in mapset specific tables with creation and modification date and absolute/relative time stamp.

=== Raster spacetime datasets ===

The raster spacetime datasets store raster map specific attributes and metadata:
* The spatial extent (e, w, n, s)
* The temporal extent (start and end time or duration)
* The data range (min and max)
* The raster datatype (CELL, FCELL, DCELL, MIXED)

All these table entries are computed or updated via trigger from all registered raster maps when maps are added or removed.

Table layout:

The base spacetime tables are equal to the raster/vector and raster3d one.

* '''Spacetime metadata raster table'''
** '''id''' the name of the spacetime raster table
** '''temporal type''' relative or absolute
** '''Raster register table name''' the name of the table storing the ids (names) of all registered raster maps
** '''spatial extent''' (4 columns: e, w, s,n) of all registered raster maps
** '''temporal exten'''t of all registered raster maps
** '''data range''' of all registered raster maps
** ...

=== Raster3d spacetime datasets ===

The raster3d spacetime tables are equal to the raster spacetime tablse, except that the spatial extent is computed based on east, west, south, north, top and bottom.

=== Vector spacetime datasets ===

== New temporal modules ==

New temporal modules must be implemented for registration and un-registration and extraction of raster, voxel and vector maps in süacetime datasets:
* tr.register, tr.unregister, tr.extract
* t3.register, t3.unregister, t3.extract
* tv.register, tv.unregister, tv.extract
* Spacetime modules for resampling, interpolation, time stamp snapping and extraction must be implemented.

== Basic Spatio-temporal algorithms ==

Extraction is based on where SQL statements or specific time stamps. Interpolated maps are created or existing map ids will be returned.
The extraction tool will provide different types of extraction algorithms
Nearest neighbour
Interpolation (only raster and voxel maps) (linear, quadratic, ...) or
first valid time stamp.

tr(3).resample -> will create a new spacetime raster (voxel) datasets with a different spatio-temporal resolution, several methods will be available:
* averaging (mean, median, geometric mean, ...)
* summation, multiplication
* max and min functions

== Implementation details ==

Access to spacetime tables must be implemented as GRASS GIS library:
* Registration and unregistration of maps into spacetime datasets
* Update/creation of base table entries, so the SQL tables can be modified in low level GRASS GIS library functions (creation, deletion of maps)
* Selection of maps from spacetime datasets