GRASS-Wiki - User contributions [en]

Talk:GRASS GIS Community Sprint Berlin 2019

2019-05-20T08:41:33Z

⚠️AnneGhisla: aghisla's activities

= 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
* Working on Wikipage about the [https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage Zenodo-GitHuB integration]
* Investigating [https://grass.osgeo.org/grass7/manuals/addons/v.surf.mass.html v.surf.mass] for social sciences and economic research.

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

GRASS GIS Community Sprint Berlin 2019

2019-05-15T18:05:44Z

⚠️AnneGhisla: /* In person */

{{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
|18 at 2pm
|20 at 2pm
| completion of git/github migration, Image collections in GRASS GIS
|L
|
|-
|-
|2
|[[User:Neteler|Markus Neteler]]
|Germany
|17 at 7pm
|20 at 8am
| completion of git/github migration; discussion of new Hugo based web site
|M
|veggy preferred
|-
|3
|[[User:peter.loewe|Peter Loewe]]
|Germany
|17, at venue from 9sh on
|20, Noonish
| 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 at 9:50 PM
|20, the forenoon
|
|M
|
|-
|-
|6
|[[User:huhabla|Sören Gebbert]]
|Germany
|17
|19
| Image collections in GRASS GIS
|XL
|
|-
|-
|7
|[[User:Anne.ghisla|Anne Ghisla]]
|Germany
|17 from 9am
|20 until evening
|Documentation, beta testing git migration, translation, pair programming
|S
|
|-
|-
|x
|}

== Accomodation ==

There are several Hotels etc. in walking distance.

=== Backpackers ===
[https://www.cityhostel-berlin.com/ City-Hostel Berlin]
=== Hotels ===
* [[https://www.mitte.cph-hotels.com City Partner Hotel]]
* [[https://www.select-hotels.eu Select-Hotel]]
* [[https://www.regenthotels.com Regent]]
* [[https://www.titanic.com.tr Titanic]]
* [https://www.hiltonhotels.de/deutschland/hilton-berlin Hilton]
* [https://www.nh-hotels.de/booking/step1-rates?fini=12/05/2019&fout=13/05/2019&nchilds1=0&nadults1=2&hotelId=DEBE.MITTE&divisa=EUR&roomcode=PREDBL&rateplan=NHR_SD1&regimen=14&utm_medium=metasearch&utm_source=google&utm_campaign=metasearch_google-hpa&utm_term=german-de_generic_customlink&utm_content=115730185&campid=8565112&gclsrc=ha&gclid=AA80OswcAaxezxCuONuFQz09JWuG1FXnUuhA5p5rKxFb7IEwUDd3Uz2T93Rk2JvDIZz-PMYo63aIskNT5UxBABWxEzyq3-oEHiksueI#v=compact NH-Hotel]

== Venue ==

=== Points of contact ===
* Peter Löwe (DIW Head of Research Infrastucture) @: ploewe AT diw DOT de phone: ++49-(0)30-897-89-222
* Olga Zhylenko (DIW Team Assistant): @: ozhylenko AT diw DOT de phone: ++49-(0)30-897-89-470
* DIW Front Desk: +49-(0)-897-89-0

==== 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" (all are located within the central zone "A" of the Berlin public transport system.)

* [https://www.berlin.de/en/public-transportation/1772016-2913840-tickets-fares-and-route-maps.en.html Berlin public transport 101: Fares, zones, day-tickets, etc.]

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

==== Rooms & hours ====

* Friday, May 17: (room 5.2.008, 5th floor): 9:30 - 17:00
* Saturday, May 18 (Conference room 3.3.002C, 3rd floor): 10:00 - 17:00
* Sunday, May 19 (Conference room 3.3.002C, 3rd floor): 10:00 - 17:00
* Monday, May 20(Conference room 3.3.002C, 3rd floor): 9:30 - 17:00

==== Dangers & Annoyances ====
* [http://www.exberliner.com/locations/dussmann-das-kulturkaufhaus/ Dussmann bookshop]: A very dangerous place in walking distance from DIW on Friedrichstrasse: Extremely well-stocked multi-level store for books, comics, music (including rare vinyl), and other geek supplies which stays open till midnight with extremely knowledgeable and friendly staff. Visiting the place WILL result in a massive loss of developer time and POSSIBLY excessive personal overspending on rare books, records or tv-series related t-shirts. You. Have. Been. Warned.

* [http://www.augustiner-braeu-berlin.de/ Augustiner (Bavarian Restaurant)]: Bavarian restaurant in walking distance on Gendarmenmarkt square. Serves authentic beer from Munich (Augustinerbräu). Possible danger/annoynace: The oversized bbq'd pork knuckles (plus a drink or two) can send developers to sleep early, wasting development time.

* [https://www.maximilians-berlin.de/ Maximilians bavarian restaurant]: Another bavarian-themed restaurant, a bit more on the generic touristy side than Augustiner Bräu, but also closer to DIW, featuring lunch time specials during the working week.

== Recreation and cultural events ==
* [http://www.exberliner.com/ ExBerliner: English online-magazine on upcoming events, etc.]

== Tasks ==
=== Pre-event tasks ===

==== Remaining tasks ====

* Plan/order catering
* Discuss swag (t-shirts ? mugs ?)
* Discuss BBQ event or similar for saturday night
* 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
* {{done}}: Provide information about what's up in Berlin
* {{done}}: Provide information about restaurants
* {{done}}: Provide contact details for DIW stakeholders
* {{done}}: Provide information about lodging options (hotels, backpackers, etc)
* {{done}}: @DIW-IT: Prepare WLAN-access tix.

=== 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'''
|-
|@#
|...
|
|
|-
|}

=== Via video-call ===

We can use Hangouts, Zoom, Jitsi or Skype... Plenty of options!

{|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'''
|-
|1
|Vero Andreo
|Argentina
|Available on Sat and Sun
|-
|x
|
|
|
|-
|}

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

GRASS Community Sprint Genova 2013

2013-01-26T18:06:28Z

⚠️AnneGhisla: /* In person */

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

== 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
|
|
|
| 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
|[[User:Landa|Martin Landa]]
|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 ===

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

For details, see [[IRC]]

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

GRASS Community Sprint Genova 2013

2013-01-02T15:52:51Z

⚠️AnneGhisla: /* In person */

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

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

== 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 (in negotiation) - close to venue
* New youth hostel, http://www.manenahostel.it/ - close to venue
* 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]
* more to be added...

== 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
|
|
|
| L
|
|-
|4
|[[User:pcav|Paolo Cavallini]]
|Italy
|
|
|
| L
|
|-
|5
|[[User:lcasagrande|Luca Casagrande]]
|Italy
|
|
| GRASS Tutorial with Open Data from Italy
| L
|
|-
|6
|[[User:Annakrat|Anna Kratochvilova]]
|Czech Republic
|
|
|
| M
|
|-
|7
|Vaclav Petras
|Czech Republic
|
|
|
| M
|
|-
|8
|[[User:pietro|Pietro Zambelli]]
|Italy
|
|
|
| M
|
|-
|9
|[[User:Landa|Martin Landa]]
|Czech Republic
| Feb 2
| Feb 10
| [[wxGUI]], vector architecture, GRASS 7 development
| L
|
|-
|10
|[[User:Maxi|Massimiliano Cannata]]
|Italy
|
|
|
| XL
|
|-
|11
|[[User:NikosA|Nikos Alexandris]]
|Greece
|
|
| GRASS-wiki, (re-)working on the idea for a practical & visual guide to GRASS-GIS
| M
| Will try to be there!
|-
|12
|[[User:AnneGhisla|Anne Ghisla]]
|Italy
|
|
| fix v.krige, examine i.atcorr problems with RapidEye
| M
| Almost sure of participation
|-
|}

=== Via IRC chat ===

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

For details, see [[IRC]]

=== 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 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?''
** 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]]

Earth at night

2011-09-15T12:51:36Z

⚠️AnneGhisla: /* Import */ fixed map name according to link fix

== Import NASA's Night on Earth and Reproject in Polar Stereographic ==

''This micro-tutorial requires GRASS 6.5''

=== Get data ===

Download
http://eoimages.gsfc.nasa.gov/ve/1438/land_ocean_ice_lights_2048.tif
from NASA's
[http://visibleearth.nasa.gov/view_set.php?categoryID=2363 Visible Earth] website.

=== Import ===
* Create a WGS84 Lat/Lon location (EPSG # 4326)

# import into lat/lon, overriding projection check and
# setting dummy region bounds which fit into geographic
# space (the file is missing georeferencing metadata but
# we do know exactly what it should be).

r.in.gdal -o -l in=land_ocean_ice_lights_2048.tif out=land_ocean_ice_lights

for BAND in red green blue ; do
r.region map=land_ocean_ice_lights.$BAND n=90 s=-90 w=-180 e=180
done

g.region n=90 s=45 w=-180 e=180

# create 15° and 30° grid line vectors
v.mkgrid map=grid_15 box=15,15 grid=12,24 pos=coor coor=-180,-90 breaks=30
v.mkgrid map=grid_30 box=30,30 grid=6,12 pos=coor coor=-180,-90 breaks=30

=== Reproject North side ===

* Create new location based on EPSG #3413
# WGS 84 / NSIDC Sea Ice Polar Stereographic North
<3413> +proj=stere +lat_0=90 +lat_ts=70 +lon_0=-45 +k=1 +x_0=0 \
+y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs <>

#### NORTHERN HEMISPHERE #################
# pull in grids
v.proj in=grid_15 location=world_ll
v.proj in=grid_30 location=world_ll

g.region n=10000000 s=-10000000 w=-10000000 e=10000000 res=5000 -p

MAP=land_ocean_ice_lights

for BAND in red green blue ; do
echo "Processing [$BAND] ..."
r.proj -n in=$MAP.$BAND location=world_ll \
method=cubic_f memory=300
r.mapcalc "${MAP}_$BAND = if($MAP.$BAND > 255, 255, if($MAP.$BAND < 0, 0, int($MAP.$BAND)))"
g.remove "$MAP.$BAND"
g.rename "${MAP}_$BAND,$MAP.$BAND"
r.colors $MAP.$BAND color=grey255
echo
done

# draw
d.erase
d.rgb r=$MAP.red g=$MAP.green b=$MAP.blue
d.vect grid_15 type=boundary color=80:40:40
d.vect grid_30 type=boundary color=120:50:50

# output
d.out.file night_on_earth_N -c size=1000,1000 format=png
d.out.file night_on_earth_N_small -c size=250,250 format=png

=== Reproject South side ===

* Create new location based on the inverse of EPSG #3413
+proj : stere
+datum : wgs84
+lat_0 : -90
+lat_ts : -70
+lon_0 : +135
+k : 1

#### SOUTHERN HEMISPHERE #################
# pull in grids
v.proj in=grid_15 location=world_ll
v.proj in=grid_30 location=world_ll

g.region n=10000000 s=-10000000 w=-10000000 e=10000000 res=5000 -p

MAP=land_ocean_ice_lights

for BAND in red green blue ; do
echo "Processing [$BAND] ..."
r.proj -n in=$MAP.$BAND location=world_ll \
method=cubic_f memory=600
r.mapcalc "${MAP}_$BAND = if($MAP.$BAND > 255, 255, if($MAP.$BAND < 0, 0, int($MAP.$BAND)))"
g.remove "$MAP.$BAND"
g.rename "${MAP}_$BAND,$MAP.$BAND"
r.colors $MAP.$BAND color=grey255
echo
done

# remove stray NULLs
for BAND in green blue ; do
echo "Processing [$BAND] ..."
g.rename "$MAP.$BAND,$MAP.$BAND.tmp1"
r.neighbors in="$MAP.$BAND.tmp1" out="$MAP.$BAND.tmp2"
r.patch in="$MAP.$BAND.tmp1,$MAP.$BAND.tmp2" out="$MAP.$BAND"
g.remove "$MAP.$BAND.tmp1,$MAP.$BAND.tmp2"
echo
done

# draw
d.erase
d.rgb r=$MAP.red g=$MAP.green b=$MAP.blue
d.vect grid_15 type=boundary color=80:40:40
d.vect grid_30 type=boundary color=120:50:50

# output
d.out.file night_on_earth_S -c size=1000,1000 format=png
d.out.file night_on_earth_S_small -c size=250,250 format=png

=== Result ===

* {{website|screenshots/images/night_on_earth_N.png|Northern Hemisphere}}
* {{website|screenshots/images/night_on_earth_S.png|Southern Hemisphere}}

[[Category: Documentation]]
[[Category: Tutorial]]

Earth at night

2011-09-15T12:50:06Z

⚠️AnneGhisla: /* Get data */ fixed broken link

== Import NASA's Night on Earth and Reproject in Polar Stereographic ==

''This micro-tutorial requires GRASS 6.5''

=== Get data ===

Download
http://eoimages.gsfc.nasa.gov/ve/1438/land_ocean_ice_lights_2048.tif
from NASA's
[http://visibleearth.nasa.gov/view_set.php?categoryID=2363 Visible Earth] website.

=== Import ===
* Create a WGS84 Lat/Lon location (EPSG # 4326)

# import into lat/lon, overriding projection check and
# setting dummy region bounds which fit into geographic
# space (the file is missing georeferencing metadata but
# we do know exactly what it should be).

r.in.gdal -o -l in=land_ocean_ice_lights_8192.tif out=land_ocean_ice_lights

for BAND in red green blue ; do
r.region map=land_ocean_ice_lights.$BAND n=90 s=-90 w=-180 e=180
done

g.region n=90 s=45 w=-180 e=180

# create 15° and 30° grid line vectors
v.mkgrid map=grid_15 box=15,15 grid=12,24 pos=coor coor=-180,-90 breaks=30
v.mkgrid map=grid_30 box=30,30 grid=6,12 pos=coor coor=-180,-90 breaks=30

=== Reproject North side ===

* Create new location based on EPSG #3413
# WGS 84 / NSIDC Sea Ice Polar Stereographic North
<3413> +proj=stere +lat_0=90 +lat_ts=70 +lon_0=-45 +k=1 +x_0=0 \
+y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs <>

#### NORTHERN HEMISPHERE #################
# pull in grids
v.proj in=grid_15 location=world_ll
v.proj in=grid_30 location=world_ll

g.region n=10000000 s=-10000000 w=-10000000 e=10000000 res=5000 -p

MAP=land_ocean_ice_lights

for BAND in red green blue ; do
echo "Processing [$BAND] ..."
r.proj -n in=$MAP.$BAND location=world_ll \
method=cubic_f memory=300
r.mapcalc "${MAP}_$BAND = if($MAP.$BAND > 255, 255, if($MAP.$BAND < 0, 0, int($MAP.$BAND)))"
g.remove "$MAP.$BAND"
g.rename "${MAP}_$BAND,$MAP.$BAND"
r.colors $MAP.$BAND color=grey255
echo
done

# draw
d.erase
d.rgb r=$MAP.red g=$MAP.green b=$MAP.blue
d.vect grid_15 type=boundary color=80:40:40
d.vect grid_30 type=boundary color=120:50:50

# output
d.out.file night_on_earth_N -c size=1000,1000 format=png
d.out.file night_on_earth_N_small -c size=250,250 format=png

=== Reproject South side ===

* Create new location based on the inverse of EPSG #3413
+proj : stere
+datum : wgs84
+lat_0 : -90
+lat_ts : -70
+lon_0 : +135
+k : 1

#### SOUTHERN HEMISPHERE #################
# pull in grids
v.proj in=grid_15 location=world_ll
v.proj in=grid_30 location=world_ll

g.region n=10000000 s=-10000000 w=-10000000 e=10000000 res=5000 -p

MAP=land_ocean_ice_lights

for BAND in red green blue ; do
echo "Processing [$BAND] ..."
r.proj -n in=$MAP.$BAND location=world_ll \
method=cubic_f memory=600
r.mapcalc "${MAP}_$BAND = if($MAP.$BAND > 255, 255, if($MAP.$BAND < 0, 0, int($MAP.$BAND)))"
g.remove "$MAP.$BAND"
g.rename "${MAP}_$BAND,$MAP.$BAND"
r.colors $MAP.$BAND color=grey255
echo
done

# remove stray NULLs
for BAND in green blue ; do
echo "Processing [$BAND] ..."
g.rename "$MAP.$BAND,$MAP.$BAND.tmp1"
r.neighbors in="$MAP.$BAND.tmp1" out="$MAP.$BAND.tmp2"
r.patch in="$MAP.$BAND.tmp1,$MAP.$BAND.tmp2" out="$MAP.$BAND"
g.remove "$MAP.$BAND.tmp1,$MAP.$BAND.tmp2"
echo
done

# draw
d.erase
d.rgb r=$MAP.red g=$MAP.green b=$MAP.blue
d.vect grid_15 type=boundary color=80:40:40
d.vect grid_30 type=boundary color=120:50:50

# output
d.out.file night_on_earth_S -c size=1000,1000 format=png
d.out.file night_on_earth_S_small -c size=250,250 format=png

=== Result ===

* {{website|screenshots/images/night_on_earth_N.png|Northern Hemisphere}}
* {{website|screenshots/images/night_on_earth_S.png|Southern Hemisphere}}

[[Category: Documentation]]
[[Category: Tutorial]]

Test Suite

2011-07-07T12:44:11Z

⚠️AnneGhisla: /* Timeline and status */ small table with progress so far

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

{|class="wikitable sortable"
|'''Task''' || '''Status''' || '''Developer(s)'''
|-
| Implementation of modules' tests || Progress || Sören
|-
| Implementation of r3.* tests || Progress || Sören
|-
| Implementation of test framework || Starting || Anne
|-
| Make integration || To be done || -
|-
|}

== Interested people ==

* [[User:huhabla | Sören Gebbert]]
* [[User:AnneGhisla| Anne Ghisla]]
* [[User:Landa|Martin Landa]]
* Add your name here

[[Category: Development]]
[[Category: Testing]]

GRASS Community Sprint Prague 2011

2011-05-27T09:15:00Z

⚠️AnneGhisla: /* Testing and benchmarking */ more GUI testing ideas

[[Image:community_sprint_prague_2011.png|center|600px]]
<center>
Let's call the dog [http://books.google.com/books?id=sfQuAAAAIAAJ Dashenka]
</center>
[[Image:grass-logo-url.png|center|100px]]
 
__TOC__

Succeeding the [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2011 Geoinformatics FCE CTU 2011] ''(International Conference on Free Software and Open Source in Geoinformatics)'', 19-20 May 2011, [http://en.wikipedia.org/wiki/Prague Prague], [http://en.wikipedia.org/wiki/Czech_Republic Czech Republic], the GRASS GIS project will hold a '''GRASS Developer and Power User Meeting, aka 'GRASS Community Sprint'''' ''from May 20 to May 25, 2011''.

'''Important dates:'''

* 19 (Thursday) - 20 (Friday) May 2011: Geoinformatics FCE CTU 2011 conference

* '''20 (Friday) - 25 (Wednesday) May 2011: GRASS Community Sprint @ [http://www.fsv.cvut.cz/ FCE CTU]'''

== Purpose ==

Get together GRASS project members to make decisions and tackle larger problems.

For this meeting, we welcome people committed to improving the GRASS GIS project. This includes developers, documenters, bug reporters, translators etc.

== Sponsors ==



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:

* [http://gfoss.it/ GFOSS.it Associazione Italiana per l'Informazione Geografica Libera] - 1400 Euro
* Stefan Sylla, [http://sylla-consult.de/en/ sylla-consult], Frankfurt, Germany - 100 Euro
* [http://www.r3-gis.com/ R3 GIS], Merano, Italy - 500 euro
* [http://www.fossgis.de FOSSGIS e.V.], D-A-CH, - 500 euro

== Timing ==

'''When''': Friday, May 20, 2011 (day of arrival) - Wednesday, May 25, 2011 (day of departure)

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

'''Duration''':

* Friday is day of arrival
** First meeting in the evening (after the [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2011 conference]) to define the agenda
* Saturday to Tuesday
** Full days
* Wednesday 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:

* Travel to Prague, variable depending on where you come from
* Accommodation and meals
'''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]
:* 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 prize 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.

=== Timeline ===

==== Friday, 20 May ====
* Kick-off at 18.30

==== Saturday, 21 May (Room B367, third floor) ====
* 10 a.m. starting time
* 11 a.m. Welcome meeting
* discuss and finetune agenda
* presentation of participants
* Evening
: '''[http://www.youtube.com/watch?v=Jf6NFRGO9ak Valentina Shuklina's] concert in [http://www.cafe-technika.cz Café Technika]'''

==== Sunday, 22 May ====
* '''9 a.m.''' starting time
* All participants discussion rounds:
** Testing new wxGUI features before publishing procedure
** Changing parameter names in GRASS 7 (think about automated differences to GRASS 6 documentation)
** {{done}} r.mask problems: backport this [http://trac.osgeo.org/grass/changeset/46323 change] and floating point support
** [[Toolboxes]]
** ...
* Individual topics...
** {{done}} LiDAR, LAS handling (Sunday: Helena, MarkusM, and MarkusN)
* Evening: '''Social dinner'''

==== Monday, 23 May ====
* Community Sprint 3
** Outline [[Movies#Q:_How_to_create_a_screencast_.28for_video_tutorials_etc.29.3F|screen capture videos]] for "Getting started with GRASS" and for using wxGUI for various specific tasks ''(Monday: Helena and Martin)''

==== Tuesday, 24 May ====
* Community Sprint 4

==== Wednesday, 25 May ====
* Finish press release (including thanks to sponsors with names)
* Wrap up and see you soon

=== Topics ===

==== Non-technical ====

* {{done}} Prettify http://grass.osgeo.org/donation.php (borrow HTML code from http://donate.openstreetmap.org/)
* Discuss new sponsoring concept (discuss during lunch on Sunday)
* Improve promotional material
* {{done}} Introduce this year's selection of Google Summer of Code projects
* Strategy to populate [http://grass.fem-environment.eu/ new GRASS Website] (note: address is temporary) with content from [http://grass.osgeo.org old website] - design new GRASS Web site engine based on [[Web site|CMS]]. Content migration should be tracked in this Wiki ''(Milena, MarkusN, Nicolas)''
* GRASS 7 development strategy:
** Feature freezing GRASS 6; bugfix-only backports for 6.4.2+ libraries and modules
* ...
* run grass64/gource_it.sh and publish video ''(MarkusN)''

==== Semi-technical ====

Open discussion:
* Discuss possible metadata storage improvements for GRASS 7

Individually:
* Discuss changing manual to use Sphinx (see related {{trac|151}})'' (who takes this task?)''
* Support translated manual pages (see related {{trac|846}}) ''(who knows Makefile programming?)''
* Sample Mars dataset - at least empty location with correct setup ''(Alessandro Frigeri)''
: ''ping me later & I'll dig out my MOLA notes (see NVIZ screenshots page). I think there's some info in vol 1 or 3 of the GRASS newsletters. Also I seem to recall that Peter Lowe had a demo Mars mapset already set up for NVIZ + 3D rendering. Note planetary scientists often work in 0-360 degrees not -180 to +180, but GRASS supports that so all is ok.''--Hamish
* LiDAR, LAS handling ''(Sunday: Helena, MarkusM, and MarkusN)''
: ''note wish to add direct liblas support to {{cmd|r.in.xyz}}. To be honest I'm not sure how much of a speed advantage there will really be vs. piping from las2txt, but if someone wants to try & report results I'd be interested to hear about it. Not sure if it should be in another r.in.las cloned module or not. maybe a new option stream={ascii|las|mbio}? See also Bob Covill's r.in.xyz version with direct libmbio.a (MB-Systems [multibeam bathymetry]) support.'' --Hamish
* Improve manual with more examples and screenshots
* Revive command line (ie Bash) tab-completion for map names, option lists.
* ...

==== Technical ====

===== wxGUI: graphical user interface =====
* wxGUI: testing before publishing procedure
* wxGUI: add language selector at startup or in GUI configuration (Important!)
* wxGUI: modeller improvements
* wxGUI: further improve the integration of CLI and GUI
* wxNVIZ: consider to switch to [[OpenSceneGraph]] for 3D visualization
* Restore d.* commands in GRASS7 - some prototypes are already existing (p.mon: Stefano)
* ...

===== Built system, installation =====
* Addons:
** Autocompilation job for GRASS-Addons ''(MarkusN et al.)''
** Improve {{cmd|g.extension}} (enable to use precompiled winGRASS Addon binaries)
* Discuss backporting Makefile system from GRASS 7 to GRASS 6
* {{done}} Discuss and define new [[GRASS repository layout proposal|toolbox concept]]
* Daily generated OSGeo4W packages for 6.5svn, 7.0svn.
* {{done}} GRASS on clusters: shared discussion
** Job queuing with [[Parallel_GRASS_jobs|Grid Engine]] and [http://en.wikipedia.org/wiki/TORQUE_Resource_Manager Torque]
** Multi-core CPU with [[OpenMP]]
** GPU+Multi-core CPU with [[OpenCL]]
** Multi-node with [http://www.mcs.anl.gov/research/projects/mpich2/ mpich2]
* ...

===== Documentation =====
* Develop something like the wxGUI module search tree for the HTML pages
* Finally :) get htDig fixed on the projects VM
* ...

===== Testing and benchmarking =====
* Write tests for different core modules (see the [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_grass-6.4/ former testsuite] from Soeren's): [[Test Suite]]
* Discuss testing procedure for GUI: here is a list of [http://www.testingfaqs.org/t-gui.html| GUI test tools] - see also [http://en.wikipedia.org/wiki/GOMS| GOMS analysis]
* Benchmarking between GRASS, QGIS, Sextante, gvSIG, ... for watershed calculation, import, export, extract, ...
* ...

===== Capabilities =====

* SQLite default DB in grass7: switch default to per-map DB file like DBF, or keep a per-mapset DB file as is currently implemented?
* Discussion and implementation time frame of temporal GIS capabilities in GRASS [[Time series development]]
* Discussion about a new parser interface for better command line, GUI and WPS support. Discussion started here: http://trac.osgeo.org/grass/ticket/1031
* Improve [[WPS]] support
* Discuss improvements in GRASS 7 vector engine (OGR support, lightweight topology structures, better 3D support)
* {{done}} Discuss fundamental changes in raster and vector engine for GRASS 8
* winGRASS: GRASS and R-stats integration improvements (see related {{trac|1149}}, [http://code.google.com/p/batchfiles/ Windows batchfiles for use with R], [http://trac.osgeo.org/grass/ticket/1149#comment:7 ticket/1149#comment:7], [http://trac.osgeo.org/grass/ticket/1149#comment:8 ticket/1149#comment:8])
* Implement [http://www.gaia-gis.it/spatialite/ RasterLite] as GRASS raster database
* Java APIs
* ...

;Discussion on ML
* http://lists.osgeo.org/pipermail/grass-user/2011-March/059830.html

== 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=150px|'''Participant '''
|width=100px|'''Arrival'''
|width=100px|'''Departure'''
|'''Topic'''
|width=75px|'''T-Shirt'''
|'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
| May 20
| May 25
|Toolbox concept, vector engine in GRASS 7, wxGUI
| M
|
|-
|2
|[[User:Neteler|Markus Neteler]]
|May 17
|May 23
| sponsoring, coding, manual, odds and ends
| M
|
|-
|3
|[[User:Lucadelu|Luca Delucchi]]
|May 16
|May 25
|New toolbox concept,translation, g.cloud, r.modis
|L
|
|-
|4
|[[User:RobertSzczepanek|Robert Szczepanek]]
|May 19
|May 23
|wxGUI, hydrological toolbox, translation
|M
|
|-
|5
|[[User:madi|Margherita Di Leo]]
|May 16
|May 25
| [http://grass.osgeo.org/devel/i18n.php Translation] , python api, wxGUI
| L
|
|-
|6
|[[User:annalisapg|Annalisa Minelli]]
|May 16
|May 25
|[http://grass.osgeo.org/devel/i18n.php Translation], python api, r.viewshed, winGRASS debug
|S
|
|-
|7
|[[User:AnneGhisla|Anne Ghisla]]
|May 16
|May 25
|wxGUI development, v.krige
|M
|
|-
|8
|[[User:Afrigeri|Alessandro Frigeri]]
|May 18
|May 25
|Planetary SRS in GRASS GIS - OGC W*S tweakings for IAU GCS
|M
|
|-
|9
|[[User:huhabla|Sören Gebbert]]
| May 20
| May 23
|Time series development, Web Processing Service support, wps-grass-bridge, New parser interface, vtk-grass-bridge
| L
|
|-
|-
|10
|[[User:MilenaN|Milena Nowotarska]]
| May 19
| May 23
|wxGUI, translation
| S
|
|-
|11
|[[User:helena|Helena Mitasova]]
|May 22
|May 25
|wxnviz, v.vol.rst, r3 and time series, toolbox concept
|S
|
|-
|12
|[[User:blazek|Radim Blazek]]
|May 20
|May 21
|QGIS friendliness lobbying
|XL
|
|-
|13
|[[User:peter.loewe|Peter Loewe]]
|May 20
|May 23
|GRASS on computation grids lobbying, povray, paraview/vtk
|XL
|
|-
|14
|[[User:moovida|Andrea Antonello]]
|May 18
|May 23
|GRASS toolbox for uDig, Geopaparazzi import module for GRASS, Hopefully get knowledge about new raster format
|L
|
|-
|15
|[[User:mmetz|Markus Metz]]
|
|
|vector engine in GRASS 7, support for massive datasets
|L
|
|-
|16
|Paweł Netzel
| May 19
| May 22
|
| XL
|
|-
|17
|[[User:annakrat|Anna Kratochvílová]]
|
|
|wxNviz
|S
|
|-
|18
|Vaclav Petras
|
|
|
|
|-
|19
|Stefano Cavallari
|
|
|Python etc
|
|
|-
|}

=== Via IRC chat ===

* join us at irc://irc.freenode.net/grass (#grass in [[IRC]])
* Hamish B, as timezones & work allows

=== Collaborative document scratching ===

* EtherPad: http://etherpad.osuosl.org

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

* Streaming not possible...
* Live session notes via [http://etherpad.osuosl.org/ EtherPad] are useful. (afterwards post the pads to the wiki)


== 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 [[User:Landa|Martin Landa]] <tt><landa.martin at gmail.com></tt>

[[Category: Workshops]]

GRASS Community Sprint Prague 2011

2011-05-27T08:31:08Z

⚠️AnneGhisla: /* Agenda - What we plan to do */

[[Image:community_sprint_prague_2011.png|center|600px]]
<center>
Let's call the dog [http://books.google.com/books?id=sfQuAAAAIAAJ Dashenka]
</center>
[[Image:grass-logo-url.png|center|100px]]
 
__TOC__

Succeeding the [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2011 Geoinformatics FCE CTU 2011] ''(International Conference on Free Software and Open Source in Geoinformatics)'', 19-20 May 2011, [http://en.wikipedia.org/wiki/Prague Prague], [http://en.wikipedia.org/wiki/Czech_Republic Czech Republic], the GRASS GIS project will hold a '''GRASS Developer and Power User Meeting, aka 'GRASS Community Sprint'''' ''from May 20 to May 25, 2011''.

'''Important dates:'''

* 19 (Thursday) - 20 (Friday) May 2011: Geoinformatics FCE CTU 2011 conference

* '''20 (Friday) - 25 (Wednesday) May 2011: GRASS Community Sprint @ [http://www.fsv.cvut.cz/ FCE CTU]'''

== Purpose ==

Get together GRASS project members to make decisions and tackle larger problems.

For this meeting, we welcome people committed to improving the GRASS GIS project. This includes developers, documenters, bug reporters, translators etc.

== Sponsors ==



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:

* [http://gfoss.it/ GFOSS.it Associazione Italiana per l'Informazione Geografica Libera] - 1400 Euro
* Stefan Sylla, [http://sylla-consult.de/en/ sylla-consult], Frankfurt, Germany - 100 Euro
* [http://www.r3-gis.com/ R3 GIS], Merano, Italy - 500 euro
* [http://www.fossgis.de FOSSGIS e.V.], D-A-CH, - 500 euro

== Timing ==

'''When''': Friday, May 20, 2011 (day of arrival) - Wednesday, May 25, 2011 (day of departure)

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

'''Duration''':

* Friday is day of arrival
** First meeting in the evening (after the [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2011 conference]) to define the agenda
* Saturday to Tuesday
** Full days
* Wednesday 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:

* Travel to Prague, variable depending on where you come from
* Accommodation and meals
'''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]
:* 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 prize 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.

=== Timeline ===

==== Friday, 20 May ====
* Kick-off at 18.30

==== Saturday, 21 May (Room B367, third floor) ====
* 10 a.m. starting time
* 11 a.m. Welcome meeting
* discuss and finetune agenda
* presentation of participants
* Evening
: '''[http://www.youtube.com/watch?v=Jf6NFRGO9ak Valentina Shuklina's] concert in [http://www.cafe-technika.cz Café Technika]'''

==== Sunday, 22 May ====
* '''9 a.m.''' starting time
* All participants discussion rounds:
** Testing new wxGUI features before publishing procedure
** Changing parameter names in GRASS 7 (think about automated differences to GRASS 6 documentation)
** {{done}} r.mask problems: backport this [http://trac.osgeo.org/grass/changeset/46323 change] and floating point support
** [[Toolboxes]]
** ...
* Individual topics...
** {{done}} LiDAR, LAS handling (Sunday: Helena, MarkusM, and MarkusN)
* Evening: '''Social dinner'''

==== Monday, 23 May ====
* Community Sprint 3
** Outline [[Movies#Q:_How_to_create_a_screencast_.28for_video_tutorials_etc.29.3F|screen capture videos]] for "Getting started with GRASS" and for using wxGUI for various specific tasks ''(Monday: Helena and Martin)''

==== Tuesday, 24 May ====
* Community Sprint 4

==== Wednesday, 25 May ====
* Finish press release (including thanks to sponsors with names)
* Wrap up and see you soon

=== Topics ===

==== Non-technical ====

* {{done}} Prettify http://grass.osgeo.org/donation.php (borrow HTML code from http://donate.openstreetmap.org/)
* Discuss new sponsoring concept (discuss during lunch on Sunday)
* Improve promotional material
* {{done}} Introduce this year's selection of Google Summer of Code projects
* Strategy to populate [http://grass.fem-environment.eu/ new GRASS Website] (note: address is temporary) with content from [http://grass.osgeo.org old website] - design new GRASS Web site engine based on [[Web site|CMS]]. Content migration should be tracked in this Wiki ''(Milena, MarkusN, Nicolas)''
* GRASS 7 development strategy:
** Feature freezing GRASS 6; bugfix-only backports for 6.4.2+ libraries and modules
* ...
* run grass64/gource_it.sh and publish video ''(MarkusN)''

==== Semi-technical ====

Open discussion:
* Discuss possible metadata storage improvements for GRASS 7

Individually:
* Discuss changing manual to use Sphinx (see related {{trac|151}})'' (who takes this task?)''
* Support translated manual pages (see related {{trac|846}}) ''(who knows Makefile programming?)''
* Sample Mars dataset - at least empty location with correct setup ''(Alessandro Frigeri)''
: ''ping me later & I'll dig out my MOLA notes (see NVIZ screenshots page). I think there's some info in vol 1 or 3 of the GRASS newsletters. Also I seem to recall that Peter Lowe had a demo Mars mapset already set up for NVIZ + 3D rendering. Note planetary scientists often work in 0-360 degrees not -180 to +180, but GRASS supports that so all is ok.''--Hamish
* LiDAR, LAS handling ''(Sunday: Helena, MarkusM, and MarkusN)''
: ''note wish to add direct liblas support to {{cmd|r.in.xyz}}. To be honest I'm not sure how much of a speed advantage there will really be vs. piping from las2txt, but if someone wants to try & report results I'd be interested to hear about it. Not sure if it should be in another r.in.las cloned module or not. maybe a new option stream={ascii|las|mbio}? See also Bob Covill's r.in.xyz version with direct libmbio.a (MB-Systems [multibeam bathymetry]) support.'' --Hamish
* Improve manual with more examples and screenshots
* Revive command line (ie Bash) tab-completion for map names, option lists.
* ...

==== Technical ====

===== wxGUI: graphical user interface =====
* wxGUI: testing before publishing procedure
* wxGUI: add language selector at startup or in GUI configuration (Important!)
* wxGUI: modeller improvements
* wxGUI: further improve the integration of CLI and GUI
* wxNVIZ: consider to switch to [[OpenSceneGraph]] for 3D visualization
* Restore d.* commands in GRASS7 - some prototypes are already existing (p.mon: Stefano)
* ...

===== Built system, installation =====
* Addons:
** Autocompilation job for GRASS-Addons ''(MarkusN et al.)''
** Improve {{cmd|g.extension}} (enable to use precompiled winGRASS Addon binaries)
* Discuss backporting Makefile system from GRASS 7 to GRASS 6
* {{done}} Discuss and define new [[GRASS repository layout proposal|toolbox concept]]
* Daily generated OSGeo4W packages for 6.5svn, 7.0svn.
* {{done}} GRASS on clusters: shared discussion
** Job queuing with [[Parallel_GRASS_jobs|Grid Engine]] and [http://en.wikipedia.org/wiki/TORQUE_Resource_Manager Torque]
** Multi-core CPU with [[OpenMP]]
** GPU+Multi-core CPU with [[OpenCL]]
** Multi-node with [http://www.mcs.anl.gov/research/projects/mpich2/ mpich2]
* ...

===== Documentation =====
* Develop something like the wxGUI module search tree for the HTML pages
* Finally :) get htDig fixed on the projects VM
* ...

===== Testing and benchmarking =====
* Write tests for different core modules (see the [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html_grass-6.4/ former testsuite] from Soeren's): [[Test Suite]]
* Discuss testing procedure for GUI
* Benchmarking between GRASS, QGIS, Sextante, gvSIG, ... for watershed calculation, import, export, extract, ...
* ...

===== Capabilities =====

* SQLite default DB in grass7: switch default to per-map DB file like DBF, or keep a per-mapset DB file as is currently implemented?
* Discussion and implementation time frame of temporal GIS capabilities in GRASS [[Time series development]]
* Discussion about a new parser interface for better command line, GUI and WPS support. Discussion started here: http://trac.osgeo.org/grass/ticket/1031
* Improve [[WPS]] support
* Discuss improvements in GRASS 7 vector engine (OGR support, lightweight topology structures, better 3D support)
* {{done}} Discuss fundamental changes in raster and vector engine for GRASS 8
* winGRASS: GRASS and R-stats integration improvements (see related {{trac|1149}}, [http://code.google.com/p/batchfiles/ Windows batchfiles for use with R], [http://trac.osgeo.org/grass/ticket/1149#comment:7 ticket/1149#comment:7], [http://trac.osgeo.org/grass/ticket/1149#comment:8 ticket/1149#comment:8])
* Implement [http://www.gaia-gis.it/spatialite/ RasterLite] as GRASS raster database
* Java APIs
* ...

;Discussion on ML
* http://lists.osgeo.org/pipermail/grass-user/2011-March/059830.html

== 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=150px|'''Participant '''
|width=100px|'''Arrival'''
|width=100px|'''Departure'''
|'''Topic'''
|width=75px|'''T-Shirt'''
|'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
| May 20
| May 25
|Toolbox concept, vector engine in GRASS 7, wxGUI
| M
|
|-
|2
|[[User:Neteler|Markus Neteler]]
|May 17
|May 23
| sponsoring, coding, manual, odds and ends
| M
|
|-
|3
|[[User:Lucadelu|Luca Delucchi]]
|May 16
|May 25
|New toolbox concept,translation, g.cloud, r.modis
|L
|
|-
|4
|[[User:RobertSzczepanek|Robert Szczepanek]]
|May 19
|May 23
|wxGUI, hydrological toolbox, translation
|M
|
|-
|5
|[[User:madi|Margherita Di Leo]]
|May 16
|May 25
| [http://grass.osgeo.org/devel/i18n.php Translation] , python api, wxGUI
| L
|
|-
|6
|[[User:annalisapg|Annalisa Minelli]]
|May 16
|May 25
|[http://grass.osgeo.org/devel/i18n.php Translation], python api, r.viewshed, winGRASS debug
|S
|
|-
|7
|[[User:AnneGhisla|Anne Ghisla]]
|May 16
|May 25
|wxGUI development, v.krige
|M
|
|-
|8
|[[User:Afrigeri|Alessandro Frigeri]]
|May 18
|May 25
|Planetary SRS in GRASS GIS - OGC W*S tweakings for IAU GCS
|M
|
|-
|9
|[[User:huhabla|Sören Gebbert]]
| May 20
| May 23
|Time series development, Web Processing Service support, wps-grass-bridge, New parser interface, vtk-grass-bridge
| L
|
|-
|-
|10
|[[User:MilenaN|Milena Nowotarska]]
| May 19
| May 23
|wxGUI, translation
| S
|
|-
|11
|[[User:helena|Helena Mitasova]]
|May 22
|May 25
|wxnviz, v.vol.rst, r3 and time series, toolbox concept
|S
|
|-
|12
|[[User:blazek|Radim Blazek]]
|May 20
|May 21
|QGIS friendliness lobbying
|XL
|
|-
|13
|[[User:peter.loewe|Peter Loewe]]
|May 20
|May 23
|GRASS on computation grids lobbying, povray, paraview/vtk
|XL
|
|-
|14
|[[User:moovida|Andrea Antonello]]
|May 18
|May 23
|GRASS toolbox for uDig, Geopaparazzi import module for GRASS, Hopefully get knowledge about new raster format
|L
|
|-
|15
|[[User:mmetz|Markus Metz]]
|
|
|vector engine in GRASS 7, support for massive datasets
|L
|
|-
|16
|Paweł Netzel
| May 19
| May 22
|
| XL
|
|-
|17
|[[User:annakrat|Anna Kratochvílová]]
|
|
|wxNviz
|S
|
|-
|18
|Vaclav Petras
|
|
|
|
|-
|19
|Stefano Cavallari
|
|
|Python etc
|
|
|-
|}

=== Via IRC chat ===

* join us at irc://irc.freenode.net/grass (#grass in [[IRC]])
* Hamish B, as timezones & work allows

=== Collaborative document scratching ===

* EtherPad: http://etherpad.osuosl.org

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

* Streaming not possible...
* Live session notes via [http://etherpad.osuosl.org/ EtherPad] are useful. (afterwards post the pads to the wiki)


== 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 [[User:Landa|Martin Landa]] <tt><landa.martin at gmail.com></tt>

[[Category: Workshops]]

Talk:GRASS Community Sprint Prague 2011

2011-05-26T12:36:08Z

⚠️AnneGhisla: /* Anne Ghisla */

== Reports ==

=== [[User:Lucadelu|Luca Delucchi]] ===
* creation of v.pack and v.unpack modules add upload in GRASS addons (please test it add bug report) {{rev|46388}}
* fix a bug on pyModis with Stefano Cavallari, the library that I'll use for [[R.modis|r.modis]] [https://github.com/lucadelu/pyModis/commit/7369cf63140f611dc9b4a5e78820f6c333ecdcd6]
* implement a new class in pyModis to parse XML files of MODIS products
* create wiki page for my Google summer of code project [[R.modis|r.modis]]

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

* Mediawiki youtube extension - http://lists.osgeo.org/pipermail/grass-user/2011-May/060863.html
* nviz_cmd: remove double parameter & cosmetics in params description - {{rev|46349}}
* wx.psmap moved from addons to the main repo (author: Anna Kratochvilova) - {{rev|46356}}
* various minor changes in wxGUI - {{rev|46392}}

=== Vaclav Petras ===

* wxGUI menu customization - {{rev|46397}}
* wxGUI GSelect height customization - {{rev|46397}}

=== [[User:Neteler|Markus Neteler]] ===
* Sponsor money management
* Nicer [http://grass.osgeo.org/donation.php donations page], together with Stefano Cavallari who implemented the Paypal connector
* r.mask: catch user error - [https://trac.osgeo.org/grass/changeset/46372 r46372]
* grass-addons/grass7/display/d.mon: fix missing Makefile - [https://trac.osgeo.org/grass/changeset/46370 r46370]
* [[Toolboxes]] assignment together with Helena Mitasova
*

=== Robert Szczepanek ===
* continued Polish translation

=== Milena Nowotarska ===
* continued Polish translation
* work on wxGUI menu improvements

=== Markus Metz ===
* r.mask: bug fixed for reclassed maps in 6.x - [https://trac.osgeo.org/grass/changeset/46345/ r46345], [https://trac.osgeo.org/grass/changeset/46346/ r46346]
* LiDAR, LAS handling: creation of import modules [r|v].in.lidar for the [http://www.liblas.org/ ASPRS LiDAR LAS format]
* GRASS 7 development
** time series, together with Helena Mitasova and Sören Gebbert (project leader): design of a true temporal GIS
** scalable vector topology, with Radim Blazek

=== [[User:Madi|Margherita Di Leo]] ===
* Scratch for r.stream GUI (GSoC Project) - [[Wx.stream_gsoc2011]]
* r.threshold: New module useful to find optimal threshold for stream extraction {{rev|46403}}

=== Andrea Antonello ===
* Generic OMS3/Java wrapper for GRASS modules for generic use in the java world.
* Complete description [http://jgrasstechtips.blogspot.com/2011/05/oms3-grass-modules-wrapper-at-prague.html here], since I didn't want to spam with images.

=== Sören Gebbert ===
* Implementing time as new dimension into GRASS GIS to create a true temporal GIS, together with Helena Mitasova and Markus Metz
* Implemented direct access to GRASS GIS 7 libraries (libgis, libraster, libvect, libdb, ...) from the Java programming language in [http://code.google.com/p/vtk-grass-bridge vtk-grass-bridge]
* Discussion about new approaches in grid and cloud computing with GRASS GIS, leaded by Peter Loewe
* Designing a new test suite and test frame work for GRASS GIS, together with Anne Ghisla
* New approaches in web processing services and GRASS GIS, together with Paweł Netzel and Luca Delucchi

=== Paweł Netzel ===
* work on wxGUI menu improvements

=== [[User:AnneGhisla | Anne Ghisla]] ===
* [[Test Suite]] proposal together with Sören Gebbert
* Added datatype check in r.mask Python script (GRASS7) [[https://trac.osgeo.org/grass/changeset/46379 | 46379]], porting GRASS6 shell script [[https://trac.osgeo.org/grass/changeset/46372 | 43672]]
* Google Summer of Code guidance for GRASS students and mentors who attended the sprint

== Press release draft ==

... write it ... mention achievements and sponsors ... at bottom 3 lines what GRASS is, take from [http://grass.osgeo.org/announces/abstract_grass641.txt here]

== Organizer's page ==

* Sponsors
** {{done}} [http://grass.osgeo.org/announces/donate-now.html Find] and coordinate them

* {{done}} ([http://geoinformatics.fsv.cvut.cz/gwiki/Room_B367 B367]) Hackfest Room
** {{done}} Wifi or switch(es)
** {{done}} extension cables
** {{done}} video projector
** {{done}} Opportunity to prepare coffee or likewise (if possible)

* Video broadcasting
** camera for streaming (maybe not needed)

* Accommodation
** {{done}} Reserve sufficient (cheap) rooms in advance
** {{done}} Find some really low budget places

* Social dinner
** {{done}} Sunday evening

* City tour
** {{done}} Consider one city walk event to get distracted :)

* Documentation
** {{done}} [[IRC]] broadcast on #grass
** [http://etherpad.osuosl.org/ Etherpad] for live notes
** Fotos
** '''Press release which includes the relevant sponsor names''' for newspapers and GRASS communication channels

=== Hints for the Preparation ===
* Very useful guide: http://wiki.osgeo.org/wiki/FOSS4G2007_Lessons_Learned

Talk:GRASS Community Sprint Prague 2011

2011-05-26T12:35:38Z

⚠️AnneGhisla: /* Anne Ghisla */

== Reports ==

=== [[User:Lucadelu|Luca Delucchi]] ===
* creation of v.pack and v.unpack modules add upload in GRASS addons (please test it add bug report) {{rev|46388}}
* fix a bug on pyModis with Stefano Cavallari, the library that I'll use for [[R.modis|r.modis]] [https://github.com/lucadelu/pyModis/commit/7369cf63140f611dc9b4a5e78820f6c333ecdcd6]
* implement a new class in pyModis to parse XML files of MODIS products
* create wiki page for my Google summer of code project [[R.modis|r.modis]]

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

* Mediawiki youtube extension - http://lists.osgeo.org/pipermail/grass-user/2011-May/060863.html
* nviz_cmd: remove double parameter & cosmetics in params description - {{rev|46349}}
* wx.psmap moved from addons to the main repo (author: Anna Kratochvilova) - {{rev|46356}}
* various minor changes in wxGUI - {{rev|46392}}

=== Vaclav Petras ===

* wxGUI menu customization - {{rev|46397}}
* wxGUI GSelect height customization - {{rev|46397}}

=== [[User:Neteler|Markus Neteler]] ===
* Sponsor money management
* Nicer [http://grass.osgeo.org/donation.php donations page], together with Stefano Cavallari who implemented the Paypal connector
* r.mask: catch user error - [https://trac.osgeo.org/grass/changeset/46372 r46372]
* grass-addons/grass7/display/d.mon: fix missing Makefile - [https://trac.osgeo.org/grass/changeset/46370 r46370]
* [[Toolboxes]] assignment together with Helena Mitasova
*

=== Robert Szczepanek ===
* continued Polish translation

=== Milena Nowotarska ===
* continued Polish translation
* work on wxGUI menu improvements

=== Markus Metz ===
* r.mask: bug fixed for reclassed maps in 6.x - [https://trac.osgeo.org/grass/changeset/46345/ r46345], [https://trac.osgeo.org/grass/changeset/46346/ r46346]
* LiDAR, LAS handling: creation of import modules [r|v].in.lidar for the [http://www.liblas.org/ ASPRS LiDAR LAS format]
* GRASS 7 development
** time series, together with Helena Mitasova and Sören Gebbert (project leader): design of a true temporal GIS
** scalable vector topology, with Radim Blazek

=== [[User:Madi|Margherita Di Leo]] ===
* Scratch for r.stream GUI (GSoC Project) - [[Wx.stream_gsoc2011]]
* r.threshold: New module useful to find optimal threshold for stream extraction {{rev|46403}}

=== Andrea Antonello ===
* Generic OMS3/Java wrapper for GRASS modules for generic use in the java world.
* Complete description [http://jgrasstechtips.blogspot.com/2011/05/oms3-grass-modules-wrapper-at-prague.html here], since I didn't want to spam with images.

=== Sören Gebbert ===
* Implementing time as new dimension into GRASS GIS to create a true temporal GIS, together with Helena Mitasova and Markus Metz
* Implemented direct access to GRASS GIS 7 libraries (libgis, libraster, libvect, libdb, ...) from the Java programming language in [http://code.google.com/p/vtk-grass-bridge vtk-grass-bridge]
* Discussion about new approaches in grid and cloud computing with GRASS GIS, leaded by Peter Loewe
* Designing a new test suite and test frame work for GRASS GIS, together with Anne Ghisla
* New approaches in web processing services and GRASS GIS, together with Paweł Netzel and Luca Delucchi

=== Paweł Netzel ===
* work on wxGUI menu improvements

=== [[User:Aghisla | Anne Ghisla]] ===
* [[Test Suite]] proposal together with Sören Gebbert
* Added datatype check in r.mask Python script (GRASS7) [[https://trac.osgeo.org/grass/changeset/46379 | 46379]], porting GRASS6 shell script [[https://trac.osgeo.org/grass/changeset/46372 | 43672]]
* Google Summer of Code guidance for GRASS students and mentors who attended the sprint

== Press release draft ==

... write it ... mention achievements and sponsors ... at bottom 3 lines what GRASS is, take from [http://grass.osgeo.org/announces/abstract_grass641.txt here]

== Organizer's page ==

* Sponsors
** {{done}} [http://grass.osgeo.org/announces/donate-now.html Find] and coordinate them

* {{done}} ([http://geoinformatics.fsv.cvut.cz/gwiki/Room_B367 B367]) Hackfest Room
** {{done}} Wifi or switch(es)
** {{done}} extension cables
** {{done}} video projector
** {{done}} Opportunity to prepare coffee or likewise (if possible)

* Video broadcasting
** camera for streaming (maybe not needed)

* Accommodation
** {{done}} Reserve sufficient (cheap) rooms in advance
** {{done}} Find some really low budget places

* Social dinner
** {{done}} Sunday evening

* City tour
** {{done}} Consider one city walk event to get distracted :)

* Documentation
** {{done}} [[IRC]] broadcast on #grass
** [http://etherpad.osuosl.org/ Etherpad] for live notes
** Fotos
** '''Press release which includes the relevant sponsor names''' for newspapers and GRASS communication channels

=== Hints for the Preparation ===
* Very useful guide: http://wiki.osgeo.org/wiki/FOSS4G2007_Lessons_Learned

Test Suite

2011-05-22T10:35:04Z

⚠️AnneGhisla: /* Background */

Test Suite

2011-05-22T10:33:54Z

⚠️AnneGhisla: proposal draft complete

GRASS 7 ideas collection

2011-05-22T09:57:19Z

⚠️AnneGhisla: /* Complete GRASS Test Suite */ added link to new wikipage on test suite

{{MoveToTrac}}

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

== Maintenance of repository ==

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

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

== Terminology ==

See [[GRASS 7 Terminology]].

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

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

== API to access algorithms in modules ==

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

Update 1/2011: Python ctypes interface available

== Raster ==

See also [[Replacement raster format]].

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

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

=== Modules ===

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

==== remove ====
* Remove r.bitpattern since r.mapcalc does it more nicely now
* Remove r.in.arc and r.out.arc, '''if''' a [http://intevation.de/rt/webrt?serial_num=4897 related bug in r.in.gdal] is fixed. The [http://bugzilla.remotesensing.org/show_bug.cgi?id=1071 integer/floating point detection for AAIGrid driver in GDAL] was fixed after 1.3.2 release, so r.in.gdal and r.out.gdal should be enough now.
: see delta comment about r.out.tiff below, sometimes the simple stuff works best! --HB
:: Ditto.

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

* remove r.out.tiff. New C r.out.gdal should cover all it's option now (doublecheck!). See [http://intevation.de/rt/webrt?serial_num=3680 RT #3680] (starting with date Sun, Nov 26 2006 14:54:23).
: It might be worth keeping r.out.tiff! It makes a nice delta when things don't go well (eg [https://svn.qgis.org/trac/ticket/348 QGIS bug#348]) --HB
:: However: code duplication, maintenance overhead, user confussion (more entries in GUI, more manual pages, why are there modules doing the same?).

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

==== Merge ====

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

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

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

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

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

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

==== fix ====
* fix lseek() usage for Large File Support: see [http://grass.itc.it/pipermail/grass-dev/2006-December/028231.html list of affected modules]
* fix the raster map history management (truncating long history, odd storage). It should work like for vector maps in GRASS 6.
* r.volume centroids parameter only makes a level one vector with no attribute table; module should be updated to GRASS 6 vector library)
* r.random should be split into 2 modules: one for generating a raster map with random points (alike v.random), and the other for sampling a raster map (alike v.what.rast). Vector functionality should be droped from r.random - a dupe of existing vector modules. -i and -z flags should be droped.
* v.random -z: read zmin and zmax from region settings, drop zmin and zmax. I.e. treat Z coord same as X,Y.

==== Good coding practice ====

* Input handling:

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

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

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

* In a similar way, metadata/history storage:

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

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

* Or color palettes application is nice:

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

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

* Changes:

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

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

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

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

=== Library ===
* 2d 'vertical' vector data (e.g. [http://sofia.usgs.gov/publications/maps/florida_geology/Txsectionbh.jpg Geologic Cross Sections])
* implement transactions for geometry handling (esp. v.edit, v.digit and to avoid leftover files when a vector command fails)
* Assume '''cat 0''' as the first possible, instead of 1. GRASS has supported cat 0 since around 2005, but it hasn't been widely used. According to Radim, using cat 0 allows for [http://sourceforge.net/mailarchive/message.php?msg_name=340505ef0601170244n1b5fe25bhd0a3eba7342b78d4%40mail.gmail.com exact mapping from OGR FID (which can be 0) to GRASS cat].
* support for elliptical arcs, quadratic and cubic splines. Elliptical arcs or circular arcs are very common in Swiss survey data (Amtliche Vermessung)

=== Modules ===

==== rename ====
* rename v.in.ogr to v.import - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.out.ogr to v.export - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.mkgrid to v.grid - see [http://lists.osgeo.org/pipermail/grass-dev/2008-October/thread.html#40450 discussion]
* rename v.univar.sh to v.db.univar ([http://grass.itc.it/pipermail/grass-dev/2007-May/030883.html comment])

==== remove ====

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

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

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

==== fix ====
* Fix the [http://intevation.de/rt/webrt?serial_num=3623 Column 'cat_' already exists (duplicate name)] in v.in.ogr. Maybe by creating columns ''cat_1'', ''cat_2'' etc. each time a Grass vector is exported to shapefile and imported back to Grass?
* write Vect_map_exists() and implement in g.remove and v.digit -n (why wait for GRASS 7 ??)
* add '-d' dissolve to v.reclass
* add 'where=' to v.to.rast (why wait for GRASS 7 ??)
* <strike>implement Douglas-Peucker generalization ([http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/ C code file])to substitute prune tool of v.clean ([http://grass.itc.it/pipermail/grass-dev/2007-May/thread.html#31446 done]?, see also GSoC)</strike>
** This is done. [http://grass.osgeo.org/grass63/manuals/html63_user/v.generalize.html v.generalize] does D-P and a lot more -WB
* Rewrite vector labeling. Needs more placement control options (may be db field value based), label overlapping prevention would be also good. May be we could borrow some ideas from MapServer? (ongoing: v.label.sa)
* v.what.vect - rename parameters "vector" to "map", "qvector" to "qmap"
* v.type - change type= option to from= and to=.(code's already in there)

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

== General ==
=== Library ===
* Add support for planetary bodies reference systems
* <strike>Add new partial differential equation (PDE) library with OpenMP support</strike> (GRASS 6.3)

=== Modules ===

* g.remove, g.mremove, g.rename, g.copy: don't allow for default datatype (which is currently raster) [http://intevation.de/rt/webrt?serial_num=3009].
: controversial, needs more discussion --HB
* g.region
** [http://grass.itc.it/pipermail/grassuser/2007-February/038337.html Glynn's notes] - cleaning the print flags and new <tt>print=</tt> option
** <strike>Support '''vector's 3rd''' dimension in '''g.region vect= [-a]''', '''[res=]''', like the 2d extents are (or should be)</strike> see [http://trac.osgeo.org/grass/ticket/121 trac #121]

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

* <strike>establish SQLite as default DBMI driver for vector attribute storage (DBF is too limited).</strike> '''done May 2008.'''

=== Modules ===
* allow cross-mapset database access, i.e. parse the '@mapset' notation appended to vector names (requires access via possibly different DBMI drivers)

==== rename ====
* rename db.in.ogr to db.import

== Imagery ==

Page has been moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib

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

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

== Display ==

The page moved to Trac: http://trac.osgeo.org/grass/wiki/Grass7/DisplayLib

== Postscript ==
=== Modules ===
ps.map
* remove scale parameter
: -> from the command line, not the map instruction
* rename sizecol to sizecolumn (remove the given warning)
* use PAL/JPAL [http://geosysin.iict.ch/PAL cartographic labelling library] (GPL, C++ language, JNI wrapper)

See also "New display architecture" comments above.

== Parser ==

* "Add another semantic meaning to the parser system for a type safe enumerated list" (Cedric's words commenting the bug that [http://intevation.de/rt/webrt?serial_num=2969 '''v.type''' doesn't allow for selecting input and output type in '''GUI''']

* Making GRASS modules be less verbose. Use --verbose flag and GRASS_VERBOSE environment variable. All output (G_message, G_percetn, G_warning) should go to GRASS_LOG file which could be grassdata/location/mapset/.grass.log by default.
: less verbose: this is well underway in 6.3
: Note warning and errors are already logged to GIS_ERROR_LOG (see variables.html)

== Init shell and startup ==

* .grassrc6 is not what you expect. It holds the g.gisenv GIS variables, it's not a shell script containing commands like .bashrc is.
: Suggestion: We should change the name for 7.x. It isn't an "rc" file in the conventional sense.
:: Suggestion: make it even a $HOME/.grass7/ directory to store settings etc (e.g., from r.li and others)

* It is asked to run GRASS in its own shell to avoid portability issues [http://grass.itc.it/pipermail/grass-dev/2007-August/032607.html 1].

* Eliminate Init.sh. Glynn explains on [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y GRASS user ML]: "Most of the environment can be set up through an e.g. /etc/env.d/grass script. The database, location and mapset can be set through g.mapset. The only slight subtlety is if you want multiple independent sessions, but that can be done with a fraction of the code in Init.sh."

* Provide a mechanism (g.access option?) to enable r/w access for users in mapsets they don't own. So that it they don't need to hack lib/gis/mapset_msc.c. Glynn explains on [http://www.nabble.com/forum/ViewPost.jtp?post=12914361&framed=y GRASS user ML]: "AFAICT, that restriction has been unnecessary ever since the lockfile was moved from the user's home directory to the mapset directory."
: Actually, I (Glynn) no longer think it's that simple. If other users can create directories within your mapset, they can create directories which you cannot remove, and in which you cannot add, remove or modify files. And this is quite likely to happen: most users will have a umask of 0022 or worse, meaning that other users (i.e. you) cannot modify any files or directories which they create.

== Data management ==

* store vertical units on per-map base, using code from [http://www.gnu.org/software/units/ units] software
: Support for free form unit meta-data added in 6.3. I don't mind it as a guide, but we shouldn't be limited to units found in ''units''. --HB

* store vertical map datum on per-location base (GDAL/OGR needs the same [http://lists.maptools.org/pipermail/gdal-dev/2005-October/006857.html enhancement])
: This requires more discussion. I'm not sure it's a good idea to do this location-wide. --HB
: On a per raster map basis done in 6.3 cvs.

* add versioning for maps (to recover previous map versions)
: see "v.info -h" ?

== Time series ==

* Implement better [[Time series in GRASS]] support (series of satellite data etc)
: for example? [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d r.rast4d]

== Visualization ==

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

== CLI ==

=== Parameters standardization ===

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

=== Flags standardization ===

* Get rid of 'quiet/verbose' flags, preparation in GRASS 6, e.g.:
<pre>
/* please, remove before GRASS 7 released */
if(q->answer) {
putenv("GRASS_VERBOSE=0");
G_warning(_("The '-q' flag is superseded and will be removed "
"in future. Please use '--quiet' instead"));
}
</pre>

== GUI ==

* Multiplatform
* Fast, minimalist, number of windows reduced
* Novice, ...., Expert profiles for the GUI (with reduced features), tailored for use cases, e.g. 3D models of a risk map,
* link from application to the relevant wiki online support, so that non-programmers can contribute to GRASS support
* compile wiki online content and help pages into a offline version of help pages for usage in GRASS without internet access.
* Manageable also from command line via d.* modules
* Facilitating easy development of custom GUI application based on GRASS
* <strike>drop '''d.m'''</strike> {{done}}
* <strike>drop '''gis.m'''</strike> {{done}}

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

== Conceptual changes ==

* File organization in binaries:
** the grass etc dir is a mess... module should maintain arch-deps and arch-indep things in different paths -- <cite> frankie at #grass irc</cite>
** it's basically a FHS violation, i dunno if it is reported by lintian, anyway /usr/lib/grass should be used for arch-deps data, not for mixed stuff -- <cite> frankie at #grass irc</cite>
* Creating $HOME/.grass7 directory for {{done}}
** Custom fonts
** r.li and other modules temp. files
** GEM addons installation {{done}}
** Default path for custom scripts
** Custom symbols and EPS fill patterns
** Custom color maps
** Add here new item...

* [[GRASS repository layout proposal]]

== User Wishes ==

''This section is not really development related...''
* Create 3D animation w nviz showing GRASS 3D coolness. [[User:MarisN|MarisN]] 12:00, 4 August 2006 (CEST)
* here are some examples to get inspired (apparently that's already possible):
** [http://skagit.meas.ncsu.edu/~helena/publwork/grasskey02/grass02talk10.html dynamic surfaces and volumes]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/cenntenial/water01dsmall.gif some water]
**[http://skagit.meas.ncsu.edu/~helena/wrriwork/balsam/fanimwalk.gif particles]
** [http://www.fhpv.unipo.sk/kagerr/pracovnici/hofierka/pv_results.html solar radiation and energy]
* Convince the users to use ParaView [http://www.paraview.org] for sophisticated animations --[[User:Huhabla|huhabla]] 20:47, 14 August 2006 (CEST)
**(Add support for Paraview in GDAL/OGR or add GDAL/OGR support in ParaView to read directly data from GRASS) see discussion
* Or use [http://www.llnl.gov/visit/ VisIt software], it should be able to read GRASS maps directly via GDAL

== Complete GRASS Test Suite: see activity on [[Test_Suite | Test Suite development page]] ==
* base a comprehensive test suite on [http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/?C=M;O=D Soeren's GRASS Test Suite]
* automated error checking on all modules to catch data corruption issues

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

Test Suite

2011-05-22T09:53:29Z

⚠️AnneGhisla: first draft of testing suite development

__TOC__

= GRASS Test Suite =

Unittest and Integration Test for both libraries and modules

$ make tests [ proj [ libs | modules | all ] ]

Tests are on single modules, as independent as possible from other GRASS modules. If independence is impossible, then try to run called modules first and check if they break.

Tests are in each module's folder (Python), and in each library's folder (Python ctypes).

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

Test framework:

[[Category: Development]]
[[Category: Testing]]

Error incompatible library version for module

2011-05-21T13:24:26Z

⚠️AnneGhisla: more than one self-compiled grass version

'''Q''': Running GRASS, I get this error message:

"ERROR: Incompatible library version for module. You need to rebuild GRASS
or untangle multiple installations"

What's that? What should I do?

'''A1''': Likely you have a self-compiled GRASS version (which is fine). So? When doing update from SVN which contains a change in the core GIS library, and a subsequent recompilation without having run "make distclean" before, this error is issued to avoid incompatibility problems.

'''Solution 1'''

Prepare and recompile your source code copy in this way:

make distclean
svn up
./configure ...
make
make install

Note: If you use the GDAL-GRASS plugin then also recompile and reinstall it - "just to be sure".

'''A2''': You have compiled more GRASS versions from SVN, and run make install on more than one. I went into this problem when I compiled and installed both GRASS 6.4 and 6.5.

'''Solution 2'''

You can compile as many GRASS versions as you want; the problems come when you install more than one. The solutions to this error are various:

* First solution can be to choose only one version to be the officially installed. Then remove the grass6.X folder in /usr/local/ (or in the folder you chose for install), and the executable (run which grass65 to find where the executable is). Recompile all involved versions, with the commands shown in Solution 1, ''except make install''. Make install only the version you want to be the official one on your machine.
* Keep all versions installed, and export the correct LD_LIBRARY_PATH just before running the version you want to use.
* Remove all installed GRASS versions, recompile without installing them, and make links to all executables in /usr/local/bin.

=== Notes ===

* the "make install" step requires "sudo" under Ubuntu.
* a reminder that the last step ("sudo make install") can be avoided completely in single-user complilations since GRASS can be launched directly from within the "/path/to/src/grass64_release/bin.x86_64-unknown-linux-gnu/" directory. You can simply create the following link:
/usr/local/bin/grass64 -> /path/to/src/grass64_release/bin.x86_64-unknown-linux-gnu/grass64
* Also, on Ubuntu, in case one wants to install the compiled binaries, the program "checkinstall" is a good option instead of "make install". It creates a .deb package and installs it which can be easily uninstalled of course in case of future updates.

[[Category:FAQ]]

Toolboxes

2011-05-21T10:53:41Z

⚠️AnneGhisla: /* List of toolboxes */ new idea: atmospheric toolbox

* 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. Toolbox should be easily installed by the user using {{cmd|g.extension|version=70}}

* add toolbox

g.extension toolbox=hydrology operation=add

Source code of the selected modules is downloaded from SVN, compiled and afterwards also installed to the user-specified (~/.grass7) or system (/usr/lib/grass7) directory.

Give the possibility with a flag (like -a) to install also modules from addons related that toolbox

g.extension -a toolbox=hydrology operation=add

* remove toolbox

g.extension toolbox=hydrology operation=remove

* list of modules of selected toolbox

g.extension -l toolbox=hydrology

User can also add/remove selected module

g.extension module=r.stream.angle operation=add

=== List of toolboxes ===
{|class="wikitable"
|'''Toolbox name''' || '''Toolbox code''' || '''Description'''||'''Correlate toolbox'''
|-
| ''3D Raster''
| R3
| All `r3.*` modules
|
|-
| ''3D Visualization''
| V3
| {{cmd|nviz_cmd|version=70}}
|
|-
| ''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''
|-
| ''Imagery''
| IM
| All `i.*` modules, selected r.* modules
|
|-
| ''Landascape 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''
|-
| ''Atmospheric tools''
| AT
|
|
|}
HM comment: do we need import/export Toolbox for all of the specialized *.in* and *.out.* commands? gdal/ogr commands should be in core.

== List of modules (trunk) ==

=== Display ===

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

=== Misc ===

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

=== Postscript ===

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

=== Raster ===

{|class="wikitable"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|r.basins.fill|version=70}} || ? ||
|-
| {{cmd|r.bitpattern|version=70}} || ? ||
|-
| {{cmd|r.blend|version=70}} || ? ||
|-
| {{cmd|r.buffer|version=70}} || ? ||
|-
| {{cmd|r.buffer2|version=70}} || ? ||
|-
| {{cmd|r.carve|version=70}} || T ||TA
|-
| {{cmd|r.category|version=70}} || ? ||
|-
| {{cmd|r.circle|version=70}} || ? ||
|-
| {{cmd|r.clump|version=70}} || ? ||
|-
| {{cmd|r.coin|version=70}} || ? ||
|-
| {{cmd|r.colors|version=70}} || C ||
|-
| {{cmd|r.colors.out|version=70}} || ? ||
|-
| {{cmd|r.colors.stddev|version=70}} || ? ||
|-
| {{cmd|r.composite|version=70}} || ? ||
|-
| {{cmd|r.compress|version=70}} || ? ||
|-
| {{cmd|r.contour|version=70}} || C ||
|-
| {{cmd|r.cost|version=70}} || ? ||
|-
| {{cmd|r.covar|version=70}} || ? ||
|-
| {{cmd|r.cross|version=70}} || ? ||
|-
| {{cmd|r.describe|version=70}} || ? ||
|-
| {{cmd|r.distance|version=70}} || ? ||
|-
| {{cmd|r.drain|version=70}} || ? ||
|-
| {{cmd|r.external|version=70}} || ? ||
|-
| {{cmd|r.external.out|version=70}} || ? ||
|-
| {{cmd|r.fill.dir|version=70}} || ? ||
|-
| {{cmd|r.fillnulls|version=70}} || ? ||
|-
| {{cmd|r.flow|version=70}} || T ||HY
|-
| {{cmd|r.grow|version=70}} || ? ||
|-
| {{cmd|r.grow.distance|version=70}} || ? ||
|-
| {{cmd|r.gwflow|version=70}} || T ||HY
|-
| {{cmd|r.his|version=70}} || ? ||
|-
| {{cmd|r.horizon|version=70}} || ? ||
|-
| {{cmd|r.in.arc|version=70}} || ? ||
|-
| {{cmd|r.in.ascii|version=70}} || ? ||
|-
| {{cmd|r.in.aster|version=70}} || ? ||
|-
| {{cmd|r.in.bin|version=70}} || ? ||
|-
| {{cmd|r.in.gdal|version=70}} || ? ||
|-
| {{cmd|r.in.gridatb|version=70}} || ? ||
|-
| {{cmd|r.in.mat|version=70}} || ? ||
|-
| {{cmd|r.in.png|version=70}} || ? ||
|-
| {{cmd|r.in.poly|version=70}} || ? ||
|-
| {{cmd|r.in.srtm|version=70}} || ? ||
|-
| {{cmd|r.in.wms|version=70}} || ? ||
|-
| {{cmd|r.in.xyz|version=70}} || C ||
|-
| {{cmd|r.info|version=70}} || C ||
|-
| {{cmd|r.kappa|version=70}} || ? ||
|-
| {{cmd|r.lake|version=70}} || T ||HY
|-
| {{cmd|r.li.cwed|version=70}} || ? ||
|-
| {{cmd|r.li.dominance|version=70}} || ? ||
|-
| {{cmd|r.li.edgedensity|version=70}} || ? ||
|-
| {{cmd|r.li.mpa|version=70}} || ? ||
|-
| {{cmd|r.li.mps|version=70}} || ? ||
|-
| {{cmd|r.li.padcv|version=70}} || ? ||
|-
| {{cmd|r.li.padrange|version=70}} || ? ||
|-
| {{cmd|r.li.padsd|version=70}} || ? ||
|-
| {{cmd|r.li.patchdensity|version=70}} || ? ||
|-
| {{cmd|r.li.patchnum|version=70}} || ? ||
|-
| {{cmd|r.li.richness|version=70}} || ? ||
|-
| {{cmd|r.li.shannon|version=70}} || ? ||
|-
| {{cmd|r.li.shape|version=70}} || ? ||
|-
| {{cmd|r.li.simpson|version=70}} || ? ||
|-
| {{cmd|r.los|version=70}} || T||TA
|-
| {{cmd|r.mapcalc|version=70}} || C ||
|-
| {{cmd|r.mask|version=70}} || C ||
|-
| {{cmd|r.mfilter|version=70}} || ? ||
|-
| {{cmd|r.mode|version=70}} || ? ||
|-
| {{cmd|r.neighbors|version=70}} || C ||
|-
| {{cmd|r.null|version=70}} || C ||
|-
| {{cmd|r.out.arc|version=70}} || ? ||
|-
| {{cmd|r.out.ascii|version=70}} || ? ||
|-
| {{cmd|r.out.bin|version=70}} || ? ||
|-
| {{cmd|r.out.gdal|version=70}} || ? ||
|-
| {{cmd|r.out.gridatb|version=70}} || ? ||
|-
| {{cmd|r.out.mat|version=70}} || ? ||
|-
| {{cmd|r.out.mpeg|version=70}} || ? ||
|-
| {{cmd|r.out.png|version=70}} || ? ||
|-
| {{cmd|r.out.pov|version=70}} || ? ||
|-
| {{cmd|r.out.ppm|version=70}} || ? ||
|-
| {{cmd|r.out.ppm3|version=70}} || ? ||
|-
| {{cmd|r.out.tiff|version=70}} || ? ||
|-
| {{cmd|r.out.vrml|version=70}} || ? ||
|-
| {{cmd|r.out.vtk|version=70}} || ? ||
|-
| {{cmd|r.out.xyz|version=70}} || ? ||
|-
| {{cmd|r.param.scale|version=70}} || T ||TA
|-
| {{cmd|r.patch|version=70}} || C ||
|-
| {{cmd|r.plane|version=70}} || ? ||
|-
| {{cmd|r.profile|version=70}} || ? ||
|-
| {{cmd|r.proj|version=70}} || C ||
|-
| {{cmd|r.quant|version=70}} || ? ||
|-
| {{cmd|r.quantile|version=70}} || ? ||
|-
| {{cmd|r.random|version=70}} || ? ||
|-
| {{cmd|r.random.cells|version=70}} || ? ||
|-
| {{cmd|r.random.surface|version=70}} || ? ||
|-
| {{cmd|r.reclass|version=70}} || ? ||
|-
| {{cmd|r.reclass.area|version=70}} || ? ||
|-
| {{cmd|r.recode|version=70}} || C ||
|-
| {{cmd|r.region|version=70}} || ? ||
|-
| {{cmd|r.regression.line|version=70}} || C ||
|-
| {{cmd|r.report|version=70}} || C||
|-
| {{cmd|r.resamp.bspline|version=70}} || C ||
|-
| {{cmd|r.resamp.filter|version=70}} || ? ||
|-
| {{cmd|r.resamp.interp|version=70}} || C ||
|-
| {{cmd|r.resamp.rst|version=70}} || ? ||
|-
| {{cmd|r.resamp.stats|version=70}} || ? ||
|-
| {{cmd|r.resample|version=70}} || ? ||
|-
| {{cmd|r.rescale|version=70}} || ? ||
|-
| {{cmd|r.rescale.eq|version=70}} || ? ||
|-
| {{cmd|r.ros|version=70}} || ? ||
|-
| {{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 ||?
|-
| {{cmd|r.spread|version=70}} || ? ||
|-
| {{cmd|r.spreadpath|version=70}} || ? ||
|-
| {{cmd|r.statistics|version=70}} || ? ||
|-
| {{cmd|r.statistics2|version=70}} || ? ||
|-
| {{cmd|r.statistics3|version=70}} || ? ||
|-
| {{cmd|r.stats|version=70}} || ? ||
|-
| {{cmd|r.sun|version=70}} || T ||TA
|-
| {{cmd|r.sunmask|version=70}} || ? ||
|-
| {{cmd|r.support|version=70}} || C||
|-
| {{cmd|r.support.stats|version=70}} || ? ||
|-
| {{cmd|r.surf.area|version=70}} || ? ||
|-
| {{cmd|r.surf.contour|version=70}} || ? ||
|-
| {{cmd|r.surf.fractal|version=70}} || ? ||
|-
| {{cmd|r.surf.gauss|version=70}} || ? ||
|-
| {{cmd|r.surf.idw|version=70}} || ? ||
|-
| {{cmd|r.surf.idw2|version=70}} || ? ||
|-
| {{cmd|r.surf.random|version=70}} || ? ||
|-
| {{cmd|r.terraflow|version=70}} || T ||HY
|-
| {{cmd|r.texture|version=70}} || ? ||
|-
| {{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}} || ? ||
|-
| {{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}} || ? ||
|-
| {{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}} || ? ||
|-
| {{cmd|r.walk|version=70}} || ? ||
|-
| {{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}} || ? ||
|-
|}

=== 3D raster ===

{|class="wikitable"
|'''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"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)'''
|-
| {{cmd|v.autokrige|version=70}} || ? ||
|-
| {{cmd|v.buffer|version=70}} || ? ||
|-
| {{cmd|v.build|version=70}} || ? ||
|-
| {{cmd|v.build.all|version=70}} || ? ||
|-
| {{cmd|v.build.polylines|version=70}} || ? ||
|-
| {{cmd|v.category|version=70}} || ? ||
|-
| {{cmd|v.centroids|version=70}} || ? ||
|-
| {{cmd|v.class|version=70}} || ? ||
|-
| {{cmd|v.clean|version=70}} || ? ||
|-
| {{cmd|v.colors|version=70}} || ? ||
|-
| {{cmd|v.convert|version=70}} || ? ||
|-
| {{cmd|v.convert.all|version=70}} || ? ||
|-
| {{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}} || ? ||
|-
| {{cmd|v.distance|version=70}} || ? ||
|-
| {{cmd|v.drape|version=70}} || ? ||
|-
| {{cmd|v.edit|version=70}} || ? ||
|-
| {{cmd|v.external|version=70}} || ? ||
|-
| {{cmd|v.extract|version=70}} || ? ||
|-
| {{cmd|v.extrude|version=70}} || ? ||
|-
| {{cmd|v.generalize|version=70}} || ? ||
|-
| {{cmd|v.hull|version=70}} || ? ||
|-
| {{cmd|v.in.ascii|version=70}} || ? ||
|-
| {{cmd|v.in.db|version=70}} || ? ||
|-
| {{cmd|v.in.dxf|version=70}} || ? ||
|-
| {{cmd|v.in.e00|version=70}} || ? ||
|-
| {{cmd|v.in.geonames|version=70}} || ? ||
|-
| {{cmd|v.in.gns|version=70}} || ? ||
|-
| {{cmd|v.in.lines|version=70}} || ? ||
|-
| {{cmd|v.in.mapgen|version=70}} || ? ||
|-
| {{cmd|v.in.ogr|version=70}} || ? ||
|-
| {{cmd|v.in.postgis|version=70}} || ? ||
|-
| {{cmd|v.in.region|version=70}} || ? ||
|-
| {{cmd|v.in.sites|version=70}} || ? ||
|-
| {{cmd|v.in.sites.all|version=70}} || ? ||
|-
| {{cmd|v.in.wfs|version=70}} || ? ||
|-
| {{cmd|v.info|version=70}} || ? ||
|-
| {{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}} || ? ||
|-
| {{cmd|v.out.dxf|version=70}} || ? ||
|-
| {{cmd|v.out.gps|version=70}} || ? ||
|-
| {{cmd|v.out.ogr|version=70}} || ? ||
|-
| {{cmd|v.out.postgis|version=70}} || ? ||
|-
| {{cmd|v.out.pov|version=70}} || ? ||
|-
| {{cmd|v.out.svg|version=70}} || ? ||
|-
| {{cmd|v.out.vtk|version=70}} || ? ||
|-
| {{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}} || ? ||
|-
| {{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}} || ? ||
|-
| {{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"
|'''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"
|'''Module''' || '''Core/Tools/Addons''' || '''Toolbox(es)''' || '''Note'''
|-
| {{AddonCmd|r.stream.angle}} || T || HY ||
|-
| {{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 ==

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

[[Category:Development]]

GRASS Community Sprint Prague 2011

2011-05-21T10:51:18Z

⚠️AnneGhisla: /* Topics */ updated after first brainstorming

__TOC__

Succeeding the [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2011 Geoinformatics FCE CTU 2011] ''(International Conference on Free Software and Open Source in Geoinformatics)'', 19-20 May 2011, [http://en.wikipedia.org/wiki/Prague Prague], [http://en.wikipedia.org/wiki/Czech_Republic Czech Republic], the GRASS GIS project will hold a '''GRASS Developer and Power User Meeting, aka 'GRASS Community Sprint'''' ''from May 20 to May 25, 2011''.

'''Important dates:'''

* 19 (Thursday) - 20 (Friday) May 2011: Geoinformatics FCE CTU 2011 conference

* '''20 (Friday) - 25 (Wednesday) May 2011: GRASS Community Sprint @ [http://www.fsv.cvut.cz/ FCE CTU]'''

== Purpose ==

Get together GRASS project members to make decisions and tackle larger problems.

For this meeting, we welcome people committed to improving the GRASS GIS project. This includes developers, documenters, bug reporters, translators etc.

== Sponsors ==



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:

* [http://gfoss.it/ GFOSS.it Associazione Italiana per l'Informazione Geografica Libera] - 1400 Euro
* Stefan Sylla, [http://sylla-consult.de/en/ sylla-consult], Frankfurt, Germany - 100 Euro
* [http://www.r3-gis.com/ R3 GIS], Merano, Italy - 500 euro
* [http://www.fossgis.de FOSSGIS e.V.], D-A-CH, - 500 euro

== Timing ==

'''When''': Friday, May 20, 2011 (day of arrival) - Wednesday, May 25, 2011 (day of departure)

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

'''Duration''':

* Friday is day of arrival
** First meeting in the evening (after the [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2011 conference]) to define the agenda
* Saturday to Tuesday
** Full days
* Wednesday 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:

* Travel to Prague, variable depending on where you come from
* Accommodation and meals
'''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]
:* 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.

'''TO BE DEFINED:''' We will cover costs as much as possible thanks to our sponsors. Apparently also partial travel grants can be offered.

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

=== Timeline ===

==== Friday, 20 May ====
* Kick-off at 18.30

==== Saturday, 21 May (Room B367, third floor) ====
* 10 a.m. starting time
* 11 a.m. Welcome meeting
* discuss and finetune agenda
* presentation of participants
* Evening
: '''[http://www.youtube.com/watch?v=Jf6NFRGO9ak Valentina Shuklina's] concert in [http://www.cafe-technika.cz Café Technika]'''

==== Sunday, 22 May ====
* All participants discussion rounds:
** Testing new GUI features
** Changing parameter names in GRASS 7 (think about automated differences to GRASS 6 documentation)
** r.mask problems: backport this [http://trac.osgeo.org/grass/changeset/46323 change] and floating point support
** Toolboxes?
** ...
* Individual topics...
* Evening: '''Social dinner'''

==== Monday, 23 May ====
* Community Sprint 3

==== Tuesday, 24 May ====
* Community Sprint 4

==== Wednesday, 25 May ====
* Finish press release (including thanks to sponsors with names)
* Wrap up and see you soon

=== Topics ===

==== Non-technical ====

* Discuss new sponsoring concept. Borrow HTML code from http://donate.openstreetmap.org/
* Improve promotional material
* Introduce this year's selection of Google Summer of Code projects
* Strategy to populate new GRASS Website with content from old website
* GRASS 7 development strategy:
** Feature freezing GRASS 6; bugfix-only backports for 6.4.2+ libraries and modules
* ...
* @Markus: run grass64/gource_it.sh and publish video

==== Semi-technical ====

* Improve manual with more examples and screenshots
* Outline screen capture videos for "Getting started with GRASS" and for using wxGUI for various specific tasks
* Discuss changing manual to use Sphinx (see related {{trac|151}})
* Support translated manual pages (see related {{trac|846}})
* Design new project [[Web site]] engine based on CMS
* Discuss possible metadata storage improvements for GRASS 7
* Sample Mars dataset - at least empty location with correct setup
* LiDAR, LAS handling
* ...

==== Technical ====

===== wxGUI: graphical user interface =====
* wxGUI: add language selector at startup or in GUI configuration
* wxGUI modeller improvements
* wxGUI: further improve the integration of CLI and GUI
* wxNVIZ: consider to switch to [[OpenSceneGraph]] for 3D visualization
* Restore d.* commands in GRASS7 - some prototypes are already existing
* ...

===== Built system, installation =====
* Autocompilation job for GRASS-Addons
* Discuss backporting Makefile system from GRASS 7 to GRASS 6
* Improve {{cmd|g.extension}} (enable to use prepared winGRASS Addon binaries)
* Discuss and define new [[GRASS repository layout proposal|toolbox concept]]
* Daily generated OSGeo4W packages for 6.5svn, 7.0svn.
* GRASS on clusters: shared discussion
* ...

===== Documentation =====
* Develop something like the wxGUI module search tree for the HTML pages
* ...

===== Testing and benchmarking =====
* Write tests for different core modules (see Soeren's testsuite)
* Discuss testing procedure for GUI
* Benchmarking between GRASS, QGIS, Sextante, gvSIG, ... for watershed calculation, import, export, extract, ...
* ...

===== Capabilities =====

* SQLite default DB in grass7: switch default to per-map DB file like DBF, or keep a per-mapset DB file as is currently implemented?
* Discussion and implementation time frame of temporal GIS capabilities in GRASS [[Time series development]]
* Discussion about a new parser interface for better command line, GUI and WPS support. Discussion started here: http://trac.osgeo.org/grass/ticket/1031
* Improve [[WPS]] support
* Discuss improvements in GRASS 7 vector engine (OGR support, lightweight topology structures, better 3D support)
* Discuss fundamental changes in raster and vector engine for GRASS 8
* winGRASS: GRASS and R-stats integration improvements (see related {{trac|1149}}, [http://code.google.com/p/batchfiles/ Windows batchfiles for use with R])
* Implement [http://www.gaia-gis.it/spatialite/ RasterLite] as GRASS raster database
* Java APIs
* ...

;Discussion on ML
* http://lists.osgeo.org/pipermail/grass-user/2011-March/059830.html

== 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=150px|'''Participant '''
|width=100px|'''Arrival'''
|width=100px|'''Departure'''
|'''Topic'''
|width=75px|'''T-Shirt'''
|'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
| May 20
| May 25
|Toolbox concept, vector engine in GRASS 7, wxGUI
| M
|
|-
|2
|[[User:Neteler|Markus Neteler]]
|May 17
|May 23
| sponsoring, coding, manual, odds and ends
| M
|
|-
|3
|[[User:Lucadelu|Luca Delucchi]]
|May 16
|May 25
|New toolbox concept,translation, g.cloud, r.modis
|L
|
|-
|4
|[[User:RobertSzczepanek|Robert Szczepanek]]
|May 19
|May 23
|wxGUI, hydrological toolbox, translation
|M
|
|-
|5
|[[User:madi|Margherita Di Leo]]
|May 16
|May 25
| [http://grass.osgeo.org/devel/i18n.php Translation] , python api, wxGUI
| L
|
|-
|6
|[[User:annalisapg|Annalisa Minelli]]
|May 16
|May 25
|[http://grass.osgeo.org/devel/i18n.php Translation], python api, r.viewshed, winGRASS debug
|S
|
|-
|7
|[[User:AnneGhisla|Anne Ghisla]]
|May 16
|May 25
|wxGUI development, v.krige
|M
|
|-
|8
|[[User:Afrigeri|Alessandro Frigeri]]
|May 18
|May 25
|Planetary SRS in GRASS GIS - OGC W*S tweakings for IAU GCS
|M
|
|-
|9
|[[User:huhabla|Sören Gebbert]]
| May 20
| May 23
|Time series development, Web Processing Service support, wps-grass-bridge, New parser interface, vtk-grass-bridge
| L
|
|-
|-
|10
|[[User:MilenaN|Milena Nowotarska]]
| May 19
| May 23
|wxGUI, translation
| S
|
|-
|11
|[[User:helena|Helena Mitasova]]
|May 22
|May 25
|wxnviz, v.vol.rst, r3 and time series, toolbox concept
|S
|
|-
|12
|[[User:blazek|Radim Blazek]]
|May 20
|May 21
|QGIS friendliness lobbying
|XL
|
|-
|13
|[[User:peter.loewe|Peter Loewe]]
|May 20
|May 23
|GRASS on computation grids lobbying, povray, paraview/vtk
|XL
|
|-
|14
|[[User:moovida|Andrea Antonello]]
|May 18
|May 23
|GRASS toolbox for uDig, Geopaparazzi import module for GRASS, Hopefully get knowledge about new raster format
|L
|to be confirmed (but 87% sure)
|-
|15
|[[User:mmetz|Markus Metz]]
|
|
|vector engine in GRASS 7, support for massive datasets
|L
|
|-
|16
|Paweł Netzel
| May 19
| May 22
|
| XL
|
|-
|17
|[[User:annakrat|Anna Kratochvílová]]
|
|
|wxNviz
|S
|
|-
|18
|Vaclav Petras
|
|
|
|
|-
|}

=== Via IRC chat ===

* join us at irc://irc.freenode.net/grass (#grass in [[IRC]])
* Hamish B, as timezones & work allows

=== Collaborative document scratching ===

* EtherPad: http://etherpad.osuosl.org

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

* Live session notes via [http://etherpad.osuosl.org/ EtherPad] are useful. (afterwards post the pads to the wiki)


== 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 [[User:Landa|Martin Landa]] <tt><landa.martin at gmail.com></tt>

[[Category: Workshops]]

GRASS Community Sprint Prague 2011

2011-05-21T10:44:04Z

⚠️AnneGhisla: /* Built system, installation */

__TOC__

Succeeding the [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2011 Geoinformatics FCE CTU 2011] ''(International Conference on Free Software and Open Source in Geoinformatics)'', 19-20 May 2011, [http://en.wikipedia.org/wiki/Prague Prague], [http://en.wikipedia.org/wiki/Czech_Republic Czech Republic], the GRASS GIS project will hold a '''GRASS Developer and Power User Meeting, aka 'GRASS Community Sprint'''' ''from May 20 to May 25, 2011''.

'''Important dates:'''

* 19 (Thursday) - 20 (Friday) May 2011: Geoinformatics FCE CTU 2011 conference

* '''20 (Friday) - 25 (Wednesday) May 2011: GRASS Community Sprint @ [http://www.fsv.cvut.cz/ FCE CTU]'''

== Purpose ==

Get together GRASS project members to make decisions and tackle larger problems.

For this meeting, we welcome people committed to improving the GRASS GIS project. This includes developers, documenters, bug reporters, translators etc.

== Sponsors ==



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:

* [http://gfoss.it/ GFOSS.it Associazione Italiana per l'Informazione Geografica Libera] - 1400 Euro
* Stefan Sylla, [http://sylla-consult.de/en/ sylla-consult], Frankfurt, Germany - 100 Euro
* [http://www.r3-gis.com/ R3 GIS], Merano, Italy - 500 euro
* [http://www.fossgis.de FOSSGIS e.V.], D-A-CH, - 500 euro

== Timing ==

'''When''': Friday, May 20, 2011 (day of arrival) - Wednesday, May 25, 2011 (day of departure)

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

'''Duration''':

* Friday is day of arrival
** First meeting in the evening (after the [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2011 conference]) to define the agenda
* Saturday to Tuesday
** Full days
* Wednesday 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:

* Travel to Prague, variable depending on where you come from
* Accommodation and meals
'''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]
:* 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.

'''TO BE DEFINED:''' We will cover costs as much as possible thanks to our sponsors. Apparently also partial travel grants can be offered.

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

=== Timeline ===

==== Friday, 20 May ====
* Kick-off at 18.30

==== Saturday, 21 May (Room B367, third floor) ====
* 10 a.m. starting time
* 11 a.m. Welcome meeting
* discuss and finetune agenda
* presentation of participants
* Evening
: '''[http://www.youtube.com/watch?v=Jf6NFRGO9ak Valentina Shuklina's] concert in [http://www.cafe-technika.cz Café Technika]'''

==== Sunday, 22 May ====
* All participants discussion rounds:
** Testing new GUI features
** Changing parameter names in GRASS 7 (think about automated differences to GRASS 6 documentation)
** r.mask problems: backport this [http://trac.osgeo.org/grass/changeset/46323 change] and floating point support
** Toolboxes?
** ...
* Individual topics...
* Evening: '''Social dinner'''

==== Monday, 23 May ====
* Community Sprint 3

==== Tuesday, 24 May ====
* Community Sprint 4

==== Wednesday, 25 May ====
* Finish press release (including thanks to sponsors with names)
* Wrap up and see you soon

=== Topics ===

==== Non-technical ====

* Discuss new sponsoring concept. Borrow HTML code from http://donate.openstreetmap.org/
* Introduce this year's selection of Google Summer of Code projects
* Strategy to populate new GRASS Website with content from old website
* GRASS 7 development strategy:
** Feature freezing GRASS 6; bugfix-only backports for 6.4.2+ libraries and modules
* ...
* @Markus: run grass64/gource_it.sh and publish video

==== Semi-technical ====

* Improve manual with more examples and screenshots
* Outline screen capture videos for "Getting started with GRASS" and for using wxGUI for various specific tasks
* Discuss changing manual to use Sphinx (see related {{trac|151}})
* Support translated manual pages (see related {{trac|846}})
* Design new project [[Web site]] engine based on CMS
* Discuss possible metadata storage improvements for GRASS 7
* ...

==== Technical ====

===== wxGUI: graphical user interface =====
* wxGUI: add language selector at startup or in GUI configuration
* wxGUI modeller improvements
* wxGUI: further improve the integration of CLI and GUI
* wxNVIZ: consider to switch to [[OpenSceneGraph]] for 3D visualization
* ...

===== Built system, installation =====
* Autocompilation job for GRASS-Addons
* Discuss backporting Makefile system from GRASS 7 to GRASS 6
* Improve {{cmd|g.extension}} (enable to use prepared winGRASS Addon binaries)
* Discuss and define new [[GRASS repository layout proposal|toolbox concept]]
* Daily generated OSGeo4W packages for 6.5svn, 7.0svn.
* GRASS on clusters: shared discussion
* ...

===== Documentation =====
* Develop something like the wxGUI module search tree for the HTML pages
* ...

===== Testing and benchmarking =====
* Write tests for different core modules (see Soeren's testsuite)
* Discuss testing procedure for GUI
* Benchmarking between GRASS, QGIS, Sextante, gvSIG, ... for watershed calculation, import, export, extract, ...
* ...

===== Capabilities =====

* SQLite default DB in grass7: switch default to per-map DB file like DBF, or keep a per-mapset DB file as is currently implemented?
* Discussion and implementation time frame of temporal GIS capabilities in GRASS [[Time series development]]
* Discussion about a new parser interface for better command line, GUI and WPS support. Discussion started here: http://trac.osgeo.org/grass/ticket/1031
* Improve [[WPS]] support
* Discuss improvements in GRASS 7 vector engine (OGR support, lightweight topology structures, better 3D support)
* Discuss fundamental changes in raster and vector engine for GRASS 8
* winGRASS: GRASS and R-stats integration improvements (see related {{trac|1149}}, [http://code.google.com/p/batchfiles/ Windows batchfiles for use with R])
* Implement [http://www.gaia-gis.it/spatialite/ RasterLite] as GRASS raster database
* ...

;Discussion on ML
* http://lists.osgeo.org/pipermail/grass-user/2011-March/059830.html

== 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=150px|'''Participant '''
|width=100px|'''Arrival'''
|width=100px|'''Departure'''
|'''Topic'''
|width=75px|'''T-Shirt'''
|'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
| May 20
| May 25
|Toolbox concept, vector engine in GRASS 7, wxGUI
| M
|
|-
|2
|[[User:Neteler|Markus Neteler]]
|May 17
|May 23
| sponsoring, coding, manual, odds and ends
| M
|
|-
|3
|[[User:Lucadelu|Luca Delucchi]]
|May 16
|May 25
|New toolbox concept,translation, g.cloud, r.modis
|L
|
|-
|4
|[[User:RobertSzczepanek|Robert Szczepanek]]
|May 19
|May 23
|wxGUI, hydrological toolbox, translation
|M
|
|-
|5
|[[User:madi|Margherita Di Leo]]
|May 16
|May 25
| [http://grass.osgeo.org/devel/i18n.php Translation] , python api, wxGUI
| L
|
|-
|6
|[[User:annalisapg|Annalisa Minelli]]
|May 16
|May 25
|[http://grass.osgeo.org/devel/i18n.php Translation], python api, r.viewshed, winGRASS debug
|S
|
|-
|7
|[[User:AnneGhisla|Anne Ghisla]]
|May 16
|May 25
|wxGUI development, v.krige
|M
|
|-
|8
|[[User:Afrigeri|Alessandro Frigeri]]
|May 18
|May 25
|Planetary SRS in GRASS GIS - OGC W*S tweakings for IAU GCS
|M
|
|-
|9
|[[User:huhabla|Sören Gebbert]]
| May 20
| May 23
|Time series development, Web Processing Service support, wps-grass-bridge, New parser interface, vtk-grass-bridge
| L
|
|-
|-
|10
|[[User:MilenaN|Milena Nowotarska]]
| May 19
| May 23
|wxGUI, translation
| S
|
|-
|11
|[[User:helena|Helena Mitasova]]
|May 22
|May 25
|wxnviz, v.vol.rst, r3 and time series, toolbox concept
|S
|
|-
|12
|[[User:blazek|Radim Blazek]]
|May 20
|May 21
|QGIS friendliness lobbying
|XL
|
|-
|13
|[[User:peter.loewe|Peter Loewe]]
|May 20
|May 23
|GRASS on computation grids lobbying, povray, paraview/vtk
|XL
|
|-
|14
|[[User:moovida|Andrea Antonello]]
|May 18
|May 23
|GRASS toolbox for uDig, Geopaparazzi import module for GRASS, Hopefully get knowledge about new raster format
|L
|to be confirmed (but 87% sure)
|-
|15
|[[User:mmetz|Markus Metz]]
|
|
|vector engine in GRASS 7, support for massive datasets
|L
|
|-
|16
|Paweł Netzel
| May 19
| May 22
|
| XL
|
|-
|17
|[[User:annakrat|Anna Kratochvílová]]
|
|
|wxNviz
|S
|
|-
|18
|Vaclav Petras
|
|
|
|
|-
|}

=== Via IRC chat ===

* join us at irc://irc.freenode.net/grass (#grass in [[IRC]])
* Hamish B, as timezones & work allows

=== Collaborative document scratching ===

* EtherPad: http://etherpad.osuosl.org

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

* Live session notes via [http://etherpad.osuosl.org/ EtherPad] are useful. (afterwards post the pads to the wiki)


== 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 [[User:Landa|Martin Landa]] <tt><landa.martin at gmail.com></tt>

[[Category: Workshops]]

GRASS Community Sprint Prague 2011

2011-05-02T13:28:53Z

⚠️AnneGhisla: /* Participation */ confirmed

__TOC__

Succeeding the [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2011 Geoinformatics FCE CTU 2011] ''(International Conference on Free Software and Open Source in Geoinformatics)'', 19-20 May 2011, [http://en.wikipedia.org/wiki/Prague Prague], [http://en.wikipedia.org/wiki/Czech_Republic Czech Republic], the GRASS GIS project will hold a '''GRASS Developer and Power User Meeting, aka 'GRASS Community Sprint'''' ''from May 20 to May 25, 2011''.

'''Important dates:'''

* 19 (Thursday) - 20 (Friday) May 2011: Geoinformatics FCE CTU 2011 conference

* '''20 (Friday) - 25 (Wednesday) May 2011: GRASS Community Sprint @ [http://www.fsv.cvut.cz/ FCE CTU]'''

== Purpose ==

Get together GRASS project members to make decisions and tackle larger problems.

For this meeting, we welcome people committed to improving the GRASS GIS project. This includes developers, documenters, bug reporters, translators etc.

== Sponsors ==



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

* [http://gfoss.it/ GFOSS.it Associazione Italiana per l'Informazione Geografica Libera]
* Stefan Sylla, [http://sylla-consult.de/en/ sylla-consult], Frankfurt, Germany

== Timing ==

'''When''': Friday, May 20, 2011 (day of arrival) - Wednesday, May 25, 2011 (day of departure)

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

'''Duration''':

* Friday is day of arrival
** First meeting in the evening (after the [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2011 conference]) to define the agenda
* Saturday to Tuesday
** Full days
* Wednesday 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:

* Travel to Prague, variable depending on where you come from
* Accommodation and meals
'''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]
:* 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.

'''TO BE DEFINED:''' We will cover as much as possible 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 prize 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.

=== Timeline ===

* Friday, 20 May:
** Welcome meeting
** Discuss and finetune agenda

* Saturday, 21 May:
** Morning:
** Afternoon:
** Evening: '''[http://www.youtube.com/watch?v=Jf6NFRGO9ak Valentina Shuklina's] concert in [http://www.cafe-technika.cz Café Technika]'''

* Sunday, 22 May:
** Community Sprinting 1
** Evening: '''Social dinner'''

* Monday, 23 May:
** Community Sprinting 2

* Tuesday, 24 May:
** Community Sprinting 3

* Wednesday, 25 May:
** Finish press release (including thanks to sponsors with names)
** Wrap up and see you soon

=== Topics ===

==== Non-technical ====

* Discuss new sponsoring concept
* Populate new GRASS Website with content from old website
* ...

==== Semi-technical ====

* Improve manual with more examples and screenshots
* Outline screen capture videos for "Getting started with GRASS" and for using wxGUI for various specific tasks
* Change manual to use Sphinx (see related {{trac|151}})
* Support translated manual pages (see related {{trac|846}})
* Design new project web site engine based on CMS
* ...

==== Technical ====

wxGUI: graphical user interface
* wxGUI: add language selector at startup or in GUI configuration
* wxGUI modeller improvements
* wxGUI: further improve the integration of CLI and GUI
* wxNVIZ: consider to switch to [[OpenSceneGraph]] for 3D visualization
* ...

Built system, installation:
* autocompilation job for GRASS-Addons
* backport Makefile system from GRASS 7 to GRASS 6
* Improve {{cmd|g.extension}} (enable to use prepared winGRASS Addon binaries)
* Define new [[GRASS repository layout proposal|toolbox concept]]
* Daily generated OSGeo4W packages for 6.5svn, 7.0svn.
* ...

Documentation:
* develop something like the wxGUI module search tree for the HTML pages

Testing and benchmarking:
* write tests for different core modules (see Soeren's testsuite)
* discuss testing procedure for GUI
* benchmarking between GRASS, QGIS, Sextante, gvSIG, ... for watershed calculation, import, export, extract, ...

Capabilities:
* Discussion and implementation time frame of temporal GIS capabilities in GRASS [[Time series development]]
* Discussion about a new parser interface for better command line, GUI and WPS support. Discussion started here: http://trac.osgeo.org/grass/ticket/1031
* Improve [[WPS]] support
* Discuss improvements in GRASS 7 vector engine (OGR support, lightweight topology structures, better 3D support)
* Discuss fundamental changes in raster and vector engine for GRASS 8
* winGRASS: GRASS and R-stats integration improvements (see related {{trac|1149}})
* Implement [http://www.gaia-gis.it/spatialite/ RasterLite] as GRASS raster database
* ...

;Discussion on ML
* http://lists.osgeo.org/pipermail/grass-user/2011-March/059830.html

== Participation ==

We are planning for attendance of 20/30 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>:

{|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=150px|'''Participant '''
|width=100px|'''Arrival'''
|width=100px|'''Departure'''
|'''Topic'''
|width=75px|'''T-Shirt'''
|'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
| May 20
| May 25
|Toolbox concept, vector engine in GRASS 7, wxGUI
| M
|
|-
|2
|[[User:Neteler|Markus Neteler]]
|May 17
|May 23
| sponsoring, coding, manual, odds and ends
| M
|
|-
|3
|[[User:Lucadelu|Luca Delucchi]]
|
|
|New toolbox concept,translation
|
|
|-
|4
|[[User:RobertSzczepanek|Robert Szczepanek]]
|May 19
|May 23
|wxGUI, hydrological toolbox, translation
|M
|
|-
|5
|[[User:madi|Margherita Di Leo]]
|May 16
|May 25
| [http://grass.osgeo.org/devel/i18n.php Translation] , python api, wxGUI
| L
|
|-
|6
|[[User:annalisapg|Annalisa Minelli]]
|May 16
|May 25
|[http://grass.osgeo.org/devel/i18n.php Translation], python api
|S
|
|-
|7
|[[User:AnneGhisla|Anne Ghisla]]
|May 16
|May 25
|wxGUI development, v.krige
|M
|
|-
|8
|[[User:Afrigeri|Alessandro Frigeri]]
|May 18
|May 25
|Planetary SRS in GRASS GIS - OGC W*S tweakings for IAU GCS
|M
|
|-
|9
|[[User:huhabla|Sören Gebbert]]
| May 20
| May 23
|Time series development, Web Processing Service support, wps-grass-bridge, New parser interface, vtk-grass-bridge
| L
|
|-
|-
|10
|[[User:MilenaN|Milena Nowotarska]]
|
|
|wxGUI, translation
|
|
|-
|11
|[[User:helena|Helena Mitasova]]
|May 22
|May 25
|wxnviz, v.vol.rst, r3 and time series, toolbox concept
|S
|
|-
|12
|[[User:blazek|Radim Blazek]]
|?
|?
|QGIS friendliness lobbying
|XL
|
|-
|13
|[[User:peter.loewe|Peter Loewe]]
|May 20
|May 23
|GRASS on computation grids lobbying, povray, paraview/vtk
|XL
|
|-
|14
|[[User:moovida|Andrea Antonello]]
|May 18
|May 23
|GRASS toolbox for uDig, Geopaparazzi import module for GRASS, Hopefully get knowledge about new raster format
|L
|to be confirmed (but 87% sure)
|-
|15
|[[User:mmetz|Markus Metz]]
|
|
|vector engine in GRASS 7, support for massive datasets
|L
|
|-
|
|''add yourself here...''
|
|
|
|
|-
|}

== Individual Preparation ==

* Bring your own computer
* Install subversion and the compiler tools, and come with a working GRASS development environment if possible.


== 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 [[User:Landa|Martin Landa]] <tt><landa.martin at gmail.com></tt>

[[Category: Workshops]]

V.krige GSoC 2009

2011-03-10T16:45:31Z

⚠️AnneGhisla: /* Bulletin Board */ rewrite of v.krige.

=== v.krige: Python porting and [[wxGUI]] addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by [[User:Landa|Martin Landa]] and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

'''V.krige is now into GRASS trunk and devbr_6 code! (r40048 or higher)'''

[[File:Schermata-Kriging Module.png|450px|left]]

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

For GRASS 6.5 <r40048, it is easy to install it via [http://grass.osgeo.org/grass65/manuals/html65_user/g.extension.html g.extension] (for GRASS 6.4 it is an AddOn, from 6.5+/7 onwards included). Simply type in a GRASS shell:

g.extension v.krige

To install v.krige.py from source, please refer to [[Compile_and_Install#Scripts]]. Source is available on SVN:

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

'''The module requires GRASS >= 6.4 RC5''' - it uses the new version of grass-python library. At the moment, no backward compatibility with previous versions is provided.

The module has dependencies:
* R 2.x - no exhaustive tests on compatible versions. An up-to-date R package will do the job in 99% cases.
* R packages spgrass6, gstat and maptools
* Python module rpy2

Be sure that ALL these dependencies are installed and operative. See below for platform-specific details.

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)
install.packages("maptools", dep=T)

either the brand new Debian packages [6], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6 maptools

=== Notes for Windows ===
At this very moment, no backward compatibility with OSGeo4W's packaged GRASS 6.4svn2 is provided, nor with WinGRASS. Testing is planned, as latest WinGRASS includes the most recent python library.

If you really need to run v.krige right now on Windows, I suggest to compile GRASS following [http://trac.osgeo.org/grass/wiki/CompileOnWindows this guide].
You could also use Linux in a virtual machine. Or install Linux in a separate partition of the HD. This is not as painful as it appears, there are lots of guides over the Internet to help you.

== Bulletin Board ==

* '''TODOs'''
** [permanent todo] Cleanup code! Refactoring brings refactoring.
** wxGUI: Split widget creation and layout - makes more readable code
** Solve '''double parsing issue from RunCmd.''' This leads to unnecessary double dependency check.
** Continue integrating '''gstat functions''' - universal kriging first.
** Add '''region resolution parameter in interface''', showing the current value and allowing the user to modify it before kriging. High resolution slows down computation and give better results, but the user should have a clear feedback (I have been surprised by long runs more than once, because I was not aware of resolution).
** wxGUI: GetVector() should check for name validity, if a string is inserted?

* '''IDEAS TO DISCUSS'''
** '''Splash screen at module load''' will be implemented, but activated only if maps are more than a threshold number [Markus Neteler's suggestion]
** Create a '''package''' to delegate dependencies check? (Stefan Krüger's suggestion)

* '''BROKEN WINDOWS (from Martin Fowler's great book [0]) '''
** Imperfect logging - relies on RunCmd...
** The RBookPage::refresh() function has an endless cycle that keeps R graphics window responsive, even when that window has been closed by the user.
** spgrass6::readVECT6() and mapset name - see [http://lists.osgeo.org/pipermail/grass-stats/2009-August/001126.html this thread].

* '''FUTURE PLANS'''
** Rewrite v.krige in order to remove R dependency. It is not nice to add another program as dependency of a core module, a library is acceptable. Possible candidates:
*** '''gstat''' - Pro: it has native GRASS binding. Con: it is not developed as standalone program since 2003, in favour of R package gstat.
*** '''HPGL''' http://hpgl.aoizora.org/ - Python/C++ library with Python API. Pro: Very rich set of functions and parallelisation. Con: Not supported on Mac

== Documentation ==

Notes on v.krige usage, examples and tips are available in the module's help page, available via Help button if the GUI.

Kriging theory is available in Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [1]. Another great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [2] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft and definitive:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [3].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [4] ==

'''Report #1, 29 May'''

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [1], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [5]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

'''Report #2, 5 June'''

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

'''Report #2.5, 11 June'''

First of all, the interface is almost finished..
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

'''Report #3, 12 June'''

this weekly report will be very short, as yesterday I sent this email (Report 2.5, see above) and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK because of projection information handling.

'''Report #4, 19 June'''

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check and data load, and examine how to integrate gstat functions.

'''Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event])'''

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

'''Report #6, 3 July'''

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

'''Report #7, midterm, 10 July'''

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

'''Report #8, 17 July'''

this week I added Command output tab and the option for block kriging, and updated documentation with more precise information on dependencies.
I'll add splashscreen only as dependency check and command output will be fixed: next week I plan to work on these latter issues.

Nothing in particular is blocking progress, just some hardest stone sometimes.

'''Report #9, 24 July'''

this week I didn't work on the project because I attended last university course (botanical survey at Stelvio pass) and came back yesterday night.

Next week I plan to solve g.parser issue about double dependency check and the issue about sill, nugget and value parameters, that are optional
for R. A general cleanup of the code is also welcome...

No blocking issues atm.

'''Report #10, 31 July'''

good news from v.krige:
* fixed optional parameters also in interface - activated by a checkbox, otherwise R's NA value is correctly set
* interactive variogram fit is on its way - stay tuned!

Next week I plan to set up interactive variogram using matplotlib functions and get the stabler code possible for feature freeze.

'''Report #11, 7 August'''

this week I worked on error handling by GUI, adding controls on input data and parameters and hiding Run and Plot buttons unless all options are suitable.
Variogram plotting is on its way - I discarded matplotlib to avoid further dependencies, in favour of wx.lib.plot.

'''Report #12, 14 August'''

this is last SoC report - bringing variogram plotting into v.krige! After a long time searching for the lightest and cleanest implementation, R plotting raised as the best solution. On user demand, a R graphics window plots variogram and refreshes it, without interfering with wxGUI.
Documentation includes a full example using Spearfish dataset and all informations about dependencies.

Many thanks to all who have helped me writing v.krige: GRASS and R developers, OSGeo SoC crew, wise friends, all testers.
I hope this module will attract people towards GRASS and R, and provide a valid alternative to closed-source kriging tools.

== References ==
* [0] Fowler, Beck, Brant, Opdyke, Roberts, 1999. "Refactoring. Improving the design of existing code" (ISBN-10: 0201485672; ISBN-13: 978-0201485677)
* [1] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics" (ISBN 0-19-505013-4)
* [2] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [3] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [4] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [5] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [6] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]
[[Category:R]]

GRASS Community Sprint Prague 2011

2011-03-02T11:01:50Z

⚠️AnneGhisla: /* Participation */ incrermental PK fail

{{ToModify}}
__TOC__

Succeeding the [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2011 Geoinformatics FCE CTU 2011] ''(Conference about Free Software and Open Source in Geoinformatics)'', 19-20 May 2011, [http://en.wikipedia.org/wiki/Prague Prague], [http://en.wikipedia.org/wiki/Czech_Republic Czech Republic], the GRASS GIS project will hold a '''GRASS Developer and Power User Meeting, aka 'GRASS Community Sprint'''' ''from May 20 to May 25, 2011''.

'''Important dates:'''

* 19 (Thursday) - 20 (Friday) May 2011: Geoinformatics FCE CTU 2011 conference

* '''20 (Friday) - 25 (Wednesday) May 2011: GRASS Community Sprint @ [http://www.fsv.cvut.cz/ FCE CTU]'''

== Purpose ==

Get together GRASS project members to make decisions and tackle larger problems.

For this meeting, we welcome people committed to improving the GRASS GIS project. This includes developers, documenters, bug reporters, translators etc.

== Sponsors ==



If you are interested to sponsor the GRASS Community Sprint, 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 (find more information about GRASS sponsorship [http://grass.osgeo.org/donation.php here]).

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.

== Timing ==
'''When''': Friday, May 20, 2011 (day of arrival) - Wednesday, May 25, 2011

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

'''Duration''':

* Friday is day of arrival - first meeting in the evening (after the conference) to define the agenda
* Saturday to Tuesday full day
* Wednesday is the last day

== Venue ==
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] 
Room ''<to be defined>'' 

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

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

== Agenda ==

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

=== Topics ===

==== Non-technical ====

* Discuss new sponsoring concept
* ...

==== Semi-technical ====

* Change manual to use Sphinx (see related {{trac|151}})
* Support translated manual pages (see related {{trac|846}})
* ...

==== Technical ====

* backport Makefile system from GRASS 7 to GRASS 6
* Improve {{cmd|g.extension}} (enable to use prepared winGRASS Addon binaries)
* Define new [[GRASS repository layout proposal|toolbox concept]]
* Improve [[WPS]] support
* Improve vector engine in GRASS 7 (OGR support, lightweight topology structures, better 3D support)
* Discuss fundamental changes in raster and vector engine for GRASS 8
* ...

== Accommodation and Costs ==

Participants should plan for the following costs:

* Travel to Prague, variable depending on where you come from
* Accommodation and meals
'''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]

:: ''(in progress)''
:* [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]
:* 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 only available from 8 p.m. to 8 a.m.), contact [[User:Landa|Martin Landa]] for details

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

TO BE DEFINED: We will cover as much as possible thanks to our sponsors.

== Participation ==

We are planning for attendance of 20/30 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>:

{|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;"
|'''No'''
|'''Participant '''
|'''Arrival'''
|'''Departure'''
|'''Topic'''
|'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
| May 20
| May 25
|Toolbox concept, vector engine in GRASS 7, wxGUI
|
|-
|2
|[[User:Neteler|Markus Neteler]]
|
|
|
|
|-
|3
|[[User:Lucadelu|Luca Delucchi]]
|
|
|New toolbox concept,translation
|
|-
|4
|[[User:RobertSzczepanek|Robert Szczepanek]]
|
|
|wxGUI, toolbox concept, translation
|to be confirmed
|-
|5
|[[User:madi|Margherita Di Leo]]
|
|
|
|
|-
|6
|[[User:annalisapg|Annalisa Minelli]]
|
|
|
|
|-
|7
|[[User:AnneGhisla|Anne Ghisla]]
|
|
|wxGUI development, v.krige
|to be confirmed (but 80% sure)
|-
|X
|''add yourself here...''
|
|
|
|
|-
|}

== Individual Preparation ==

* Bring your own computer
* Install subversion and the compiler tools, and come with a working GRASS development environment if possible.

== Broadcast & Video ==

We plan to be online [http://www.ustream.tv/channel/grass-community-sprint-prague-2011 here].

== 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 [[User:Landa|Martin Landa]] <tt><landa.martin at gmail.com></tt>

[[Category: Workshops]]

GRASS Community Sprint Prague 2011

2011-03-02T10:56:57Z

⚠️AnneGhisla: /* Participation */

{{ToModify}}
__TOC__

Succeeding the [http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2011 Geoinformatics FCE CTU 2011] ''(Conference about Free Software and Open Source in Geoinformatics)'', 19-20 May 2011, [http://en.wikipedia.org/wiki/Prague Prague], [http://en.wikipedia.org/wiki/Czech_Republic Czech Republic], the GRASS GIS project will hold a '''GRASS Developer and Power User Meeting, aka 'GRASS Community Sprint'''' ''from May 20 to May 25, 2011''.

'''Important dates:'''

* 19 (Thursday) - 20 (Friday) May 2011: Geoinformatics FCE CTU 2011 conference

* '''20 (Friday) - 25 (Wednesday) May 2011: GRASS Community Sprint @ [http://www.fsv.cvut.cz/ FCE CTU]'''

== Purpose ==

Get together GRASS project members to make decisions and tackle larger problems.

For this meeting, we welcome people committed to improving the GRASS GIS project. This includes developers, documenters, bug reporters, translators etc.

== Sponsors ==



If you are interested to sponsor the GRASS Community Sprint, 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 (find more information about GRASS sponsorship [http://grass.osgeo.org/donation.php here]).

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.

== Timing ==
'''When''': Friday, May 20, 2011 (day of arrival) - Wednesday, May 25, 2011

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

'''Duration''':

* Friday is day of arrival - first meeting in the evening (after the conference) to define the agenda
* Saturday to Tuesday full day
* Wednesday is the last day

== Venue ==
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] 
Room ''<to be defined>'' 

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

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

== Agenda ==

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

=== Topics ===

==== Non-technical ====

* Discuss new sponsoring concept
* ...

==== Semi-technical ====

* Change manual to use Sphinx (see related {{trac|151}})
* Support translated manual pages (see related {{trac|846}})
* ...

==== Technical ====

* backport Makefile system from GRASS 7 to GRASS 6
* Improve {{cmd|g.extension}} (enable to use prepared winGRASS Addon binaries)
* Define new [[GRASS repository layout proposal|toolbox concept]]
* Improve [[WPS]] support
* Improve vector engine in GRASS 7 (OGR support, lightweight topology structures, better 3D support)
* Discuss fundamental changes in raster and vector engine for GRASS 8
* ...

== Accommodation and Costs ==

Participants should plan for the following costs:

* Travel to Prague, variable depending on where you come from
* Accommodation and meals
'''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]

:: ''(in progress)''
:* [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]
:* 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 only available from 8 p.m. to 8 a.m.), contact [[User:Landa|Martin Landa]] for details

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

TO BE DEFINED: We will cover as much as possible thanks to our sponsors.

== Participation ==

We are planning for attendance of 20/30 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>:

{|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;"
|'''No'''
|'''Participant '''
|'''Arrival'''
|'''Departure'''
|'''Topic'''
|'''Notes'''
|-
|1
|[[User:Landa|Martin Landa]]
| May 20
| May 25
|Toolbox concept, vector engine in GRASS 7, wxGUI
|
|-
|2
|[[User:Neteler|Markus Neteler]]
|
|
|
|
|-
|3
|[[User:Lucadelu|Luca Delucchi]]
|
|
|New toolbox concept,translation
|
|-
|4
|[[User:RobertSzczepanek|Robert Szczepanek]]
|
|
|wxGUI, toolbox concept, translation
|to be confirmed
|-
|5
|[[User:madi|Margherita Di Leo]]
|
|
|
|
|-
|6
|[[User:annalisapg|Annalisa Minelli]]
|
|
|
|
|-
|6
|[[User:AnneGhisla|Anne Ghisla]]
|
|
|wxGUI development, v.krige
|to be confirmed (but 80% sure)
|-
|X
|''add yourself here...''
|
|
|
|
|-
|}

== Individual Preparation ==

* Bring your own computer
* Install subversion and the compiler tools, and come with a working GRASS development environment if possible.

== Broadcast & Video ==

We plan to be online [http://www.ustream.tv/channel/grass-community-sprint-prague-2011 here].

== 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 [[User:Landa|Martin Landa]] <tt><landa.martin at gmail.com></tt>

[[Category: Workshops]]

Man Pages Improvement Sprint

2011-01-19T08:13:58Z

⚠️AnneGhisla: /* Who's interested */ cosmetics

Markus Metz proposed on [ GRASS-dev ml] to have a "man page improvement day", similar to a code sprint, with the whole community dedicating perhaps a day to finding problems in man pages and fixing them.
Benjamin Ducke suggested also to rephrase things that are hard to understand or elaborate on aspects that aren't explained verbosely enough.

=== Ideas ===

* sphinx'ization (http://trac.osgeo.org/grass/ticket/151)
* Add idea here

=== Who's interested ===
* Markus Metz
* Benjamin Ducke
* Dylan Beaudette
* Markus Neteler
* Anne Ghisla

Man Pages Improvement Sprint

2011-01-19T08:13:40Z

⚠️AnneGhisla: /* Ideas */ add MN's suggestion

Man Pages Improvement Sprint

2011-01-19T08:11:16Z

⚠️AnneGhisla: coordination for the man page sprint

Markus Metz proposed on [ GRASS-dev ml] to have a "man page improvement day", similar to a code sprint, with the whole community dedicating perhaps a day to finding problems in man pages and fixing them.
Benjamin Ducke suggested also to rephrase things that are hard to understand or elaborate on aspects that aren't explained verbosely enough.

=== Ideas ===

* TBD

=== Who's interested ===
* Markus Metz
* Benjamin Ducke
* Dylan Beaudette
* Markus Neteler
* Anne Ghisla

Compile and Install

2010-12-10T09:15:49Z

⚠️AnneGhisla: /* Common problems and solutions */

{{MoveToTrac}}
== How to do compilation and installation of GRASS 6? ==

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

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

For detailed information on compilation, please see the [http://grass.itc.it/grass61/source/INSTALL INSTALL] file in the source code.

=== Prerequisites ===

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

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

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

You have to install these two libraries '''first'''.

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

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

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

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

=== Generic Compilation and installation procedure ===

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

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

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

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

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


It may (!) look like this:

./configure \
--with-cxx \
--with-sqlite \
--with-postgres-libs=/usr/include/pgsql/libpq \
--with-postgres-includes=/usr/include/pgsql \
--with-freetype \
--with-freetype-includes=/usr/include/freetype2 \
--with-motif \
--with-proj-share=/usr/share/proj

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

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

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

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

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

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

NVIZ: yes

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

* Let's compile it (takes a little while...)!
make
* At the end, you should get report not much different from this:
----------------------------------------------------------------------
Following modules are missing the 'description.html' file in src code:
----------------------------------------------------------------------
GRASS GIS compilation log
-------------------------
Started compilation: Ne kvě 28 13:18:43 CEST 2006
--
Errors in:
--
Finished compilation: Ne kvě 28 13:43:40 CEST 2006
(In case of errors please change into the directory with error and run 'make')

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

=== What else? ===

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

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

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

=== Platform Specific Notes ===

==== Linux ====

===== Debian =====

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

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

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

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

or

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

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

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

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

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

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

Compile:
make

Install:
sudo make install

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

Install needed packages:
apt-get install flex bison libreadline-dev libncurses5-dev lesstif2-dev debhelper dpatch libtiff4-dev \
tcl-dev tk-dev libfftw3-dev libxmu-dev libfreetype6-dev autoconf2.13 autotools-dev doxygen \
libmysqlclient-dev graphviz libsqlite3-dev python-wxgtk2.8 libcairo2-dev libwxgtk2.8-dev \
python-dev swig libgdal1-dev libgdal1-1.6.0 libproj-dev proj-bin libglw1-mesa-dev \
mysql-client-5.1 mysql-server-5.1 libpq-dev subversion gcc lesstif2-dev \
zlib1g-dev libproj-dev libtiff4-dev mesa-common-dev libglu1-mesa-dev libcairo2-dev \
g++ wx-common python-wxgtk2.8 libwxgtk2.8-dev libxt-dev libxmu-headers gettext python-numpy

Download source code:

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

Configure:

CFLAGS="-g -Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused" \
CXXFLAGS="-g -Wall" \
./configure --prefix=/usr/local \
--with-postgres --with-postgres-includes=/usr/include/postgresql \
--with-mysql --with-mysql-includes=/usr/include/mysql \
--with-gdal --with-proj --with-proj-share=/usr/share \
--with-motif --with-glw --with-nls --with-readline \
--with-cxx --enable-largefile \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--with-sqlite \
--with-odbc --with-cairo --with-python=/usr/bin/python2.6-config --with-wxwidgets \
--with-tcltk-includes=/usr/include/tcl8.5 --with-tcltk-libs=/usr/lib/tcl8.5 \
--with-geos --with-pthread

Compile:
make

Install:
sudo make install

===== Ubuntu =====

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

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

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

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

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

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

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

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

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

* install SVN
sudo apt-get install subversion

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

sudo mkdir /usr/local/src

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

sudo chmod ug+rwx /usr/local/src

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

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

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

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

'''FFMPEG'''

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

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

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

* guide to ffmpeg directory
cd ffmpeg

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

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

* compilation
make

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

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

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

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

cd /usr/include/GL

sudo ln glxATI.h glx.h

* compilation
make

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

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

* installation
sudo checkinstall

* launch 64-bit GRASS.6.4.svn
grass64

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

====== Ubuntu 8.04 and 9.04 ======

* See [[Compile and Install Ubuntu‎]]

===== Mandriva =====

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

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

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

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

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

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

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

===== CentOS =====

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

Preparation:
yum install flex bison zlib-devel tcl-devel tk-devel gcc-c++ swig gettext \
libtiff-devel libpng-devel sqlite-devel libjpeg-devel \
mesa-libGL-devel mesa-libGLU-devel mesa-libGLw-devel \
mesa-libOSMesa-devel libXmu-devel python-devel gtk2-devel\
ncurses-devel postgresql-devel

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

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

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

# configure and compile
sh configure
make -j4

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

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

# configure and compile
sh configure
make -j4

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

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

# test installation by running
gdalinfo

GRASS 7 compilation and installation, here 64bit example:

1. Download wxGTP and wxPython:

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

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

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

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

3. Hack the Makefile of GRASS-SWIG since python-config isn't there (add one line without the '+'):

svn diff swig/
Index: swig/python/Makefile
===================================================================
--- swig/python/Makefile (revision 38916)
+++ swig/python/Makefile (working copy)
@@ -36,6 +36,7 @@
EXTRA_SWIG = ../include/python/my_typemaps.i ../include/python/common.i
SWIGFLAGS = $(INC) -I../include/python -outdir .
EXTRA_CFLAGS = $(PYMOD_CFLAGS)
+EXTRA_LIBS = -lpython2.4
EXTRA_CLEAN_FILES := $(foreach M,$(MODULES),$(M)_wrap.o $(M)_wrap.c $(M).pyc $(M).py _$(M).so)
CLEAN_SUBDIRS = NumPtr

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

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

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

5. Compile
make
or on multicore:
make -j4

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

bin.$ARCH/grass70 -wx

===== Fedora =====

This is an example how to compile GRASS on a 64bit Fedora system:

./configure \
--enable-64bit \
--with-cxx \
--with-libs=/usr/lib64 \
--with-gdal=/usr/bin/gdal-config \
--with-proj-share=/usr/share/proj \
--without-odbc \
--with-sqlite \
--with-nls \
--without-tcltk \
--with-python=/usr/bin/python-config \
--without-cairo \
--without-opengl \
--with-wxwidgets=/usr/bin/wx-config \
--with-fftw \
--with-blas \
--with-lapack \
--without-freetype \
--enable-largefile \
--with-x \
--x-includes=/usr/include/X11/

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

yum provides */<name of the file>

and then installed with your favourite package manager frontend.

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

===== Zaurus =====

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

==== Mac OSX ====

* see the source/macosx readme
* also see [[Compiling on MacOSX]]
* some notes on [[Packaging on MacOSX]]

==== Solaris ====

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

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

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

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

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

The pre-built packages don't work.

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

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

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

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

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

* Next configure, e. g.:

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

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

then:

make
su
make install

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

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

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

==== AIX ====

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

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

The environment variables and configure command that worked were:

export PATH=/usr/local/bin:/opt/freeware/bin:$PATH
export OBJECT_MODE=64
export LIBICONV=/opt/freeware
export CC="xlc_r -q64"
export CFLAGS="-O -qstrict"
export CXX="xlC_r -q64"
export CXXFLAGS="-O -qstrict"
export AR="ar -X64"
export F77="xlf_r -q64"
export CPPFLAGS="-I/afs/isis/pkg/libpng/include -I/usr/local/include -I$LIBICONV/include -I/usr/lpp/X11/include/X11"
export LDFLAGS="-L/usr/local/lib -L$LIBICONV/lib -L/usr/lib -L/usr/X11R6/lib -lc"

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

==== MS-Windows ====

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

... see [http://grass.itc.it/platforms/wingrass.html here] (should be moved to the Wiki)

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

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

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

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

=== Common problems and solutions ===

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

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

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

=== Optimization ===

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

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

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

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

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

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

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

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

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

=== Configure options and their meanings ===

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

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

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

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

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



== Addons ==

=== GRASS-GDAL plugin ===

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

=== Compiled C modules ===

'''Requirements:'''

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

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

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

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

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

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

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

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

=== Scripts ===

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

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

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

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

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

Compile and Install

2010-12-10T09:10:16Z

⚠️AnneGhisla: /* Fedora */

{{MoveToTrac}}
== How to do compilation and installation of GRASS 6? ==

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

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

For detailed information on compilation, please see the [http://grass.itc.it/grass61/source/INSTALL INSTALL] file in the source code.

=== Prerequisites ===

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

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

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

You have to install these two libraries '''first'''.

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

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

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

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

=== Generic Compilation and installation procedure ===

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

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

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

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

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


It may (!) look like this:

./configure \
--with-cxx \
--with-sqlite \
--with-postgres-libs=/usr/include/pgsql/libpq \
--with-postgres-includes=/usr/include/pgsql \
--with-freetype \
--with-freetype-includes=/usr/include/freetype2 \
--with-motif \
--with-proj-share=/usr/share/proj

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

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

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

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

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

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

NVIZ: yes

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

* Let's compile it (takes a little while...)!
make
* At the end, you should get report not much different from this:
----------------------------------------------------------------------
Following modules are missing the 'description.html' file in src code:
----------------------------------------------------------------------
GRASS GIS compilation log
-------------------------
Started compilation: Ne kvě 28 13:18:43 CEST 2006
--
Errors in:
--
Finished compilation: Ne kvě 28 13:43:40 CEST 2006
(In case of errors please change into the directory with error and run 'make')

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

=== What else? ===

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

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

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

=== Platform Specific Notes ===

==== Linux ====

===== Debian =====

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

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

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

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

or

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

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

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

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

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

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

Compile:
make

Install:
sudo make install

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

Install needed packages:
apt-get install flex bison libreadline-dev libncurses5-dev lesstif2-dev debhelper dpatch libtiff4-dev \
tcl-dev tk-dev libfftw3-dev libxmu-dev libfreetype6-dev autoconf2.13 autotools-dev doxygen \
libmysqlclient-dev graphviz libsqlite3-dev python-wxgtk2.8 libcairo2-dev libwxgtk2.8-dev \
python-dev swig libgdal1-dev libgdal1-1.6.0 libproj-dev proj-bin libglw1-mesa-dev \
mysql-client-5.1 mysql-server-5.1 libpq-dev subversion gcc lesstif2-dev \
zlib1g-dev libproj-dev libtiff4-dev mesa-common-dev libglu1-mesa-dev libcairo2-dev \
g++ wx-common python-wxgtk2.8 libwxgtk2.8-dev libxt-dev libxmu-headers gettext python-numpy

Download source code:

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

Configure:

CFLAGS="-g -Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused" \
CXXFLAGS="-g -Wall" \
./configure --prefix=/usr/local \
--with-postgres --with-postgres-includes=/usr/include/postgresql \
--with-mysql --with-mysql-includes=/usr/include/mysql \
--with-gdal --with-proj --with-proj-share=/usr/share \
--with-motif --with-glw --with-nls --with-readline \
--with-cxx --enable-largefile \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--with-sqlite \
--with-odbc --with-cairo --with-python=/usr/bin/python2.6-config --with-wxwidgets \
--with-tcltk-includes=/usr/include/tcl8.5 --with-tcltk-libs=/usr/lib/tcl8.5 \
--with-geos --with-pthread

Compile:
make

Install:
sudo make install

===== Ubuntu =====

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

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

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

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

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

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

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

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

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

* install SVN
sudo apt-get install subversion

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

sudo mkdir /usr/local/src

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

sudo chmod ug+rwx /usr/local/src

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

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

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

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

'''FFMPEG'''

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

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

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

* guide to ffmpeg directory
cd ffmpeg

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

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

* compilation
make

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

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

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

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

cd /usr/include/GL

sudo ln glxATI.h glx.h

* compilation
make

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

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

* installation
sudo checkinstall

* launch 64-bit GRASS.6.4.svn
grass64

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

====== Ubuntu 8.04 and 9.04 ======

* See [[Compile and Install Ubuntu‎]]

===== Mandriva =====

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

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

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

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

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

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

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

===== CentOS =====

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

Preparation:
yum install flex bison zlib-devel tcl-devel tk-devel gcc-c++ swig gettext \
libtiff-devel libpng-devel sqlite-devel libjpeg-devel \
mesa-libGL-devel mesa-libGLU-devel mesa-libGLw-devel \
mesa-libOSMesa-devel libXmu-devel python-devel gtk2-devel\
ncurses-devel postgresql-devel

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

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

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

# configure and compile
sh configure
make -j4

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

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

# configure and compile
sh configure
make -j4

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

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

# test installation by running
gdalinfo

GRASS 7 compilation and installation, here 64bit example:

1. Download wxGTP and wxPython:

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

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

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

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

3. Hack the Makefile of GRASS-SWIG since python-config isn't there (add one line without the '+'):

svn diff swig/
Index: swig/python/Makefile
===================================================================
--- swig/python/Makefile (revision 38916)
+++ swig/python/Makefile (working copy)
@@ -36,6 +36,7 @@
EXTRA_SWIG = ../include/python/my_typemaps.i ../include/python/common.i
SWIGFLAGS = $(INC) -I../include/python -outdir .
EXTRA_CFLAGS = $(PYMOD_CFLAGS)
+EXTRA_LIBS = -lpython2.4
EXTRA_CLEAN_FILES := $(foreach M,$(MODULES),$(M)_wrap.o $(M)_wrap.c $(M).pyc $(M).py _$(M).so)
CLEAN_SUBDIRS = NumPtr

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

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

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

5. Compile
make
or on multicore:
make -j4

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

bin.$ARCH/grass70 -wx

===== Fedora =====

This is an example how to compile GRASS on a 64bit Fedora system:

./configure \
--enable-64bit \
--with-cxx \
--with-libs=/usr/lib64 \
--with-gdal=/usr/bin/gdal-config \
--with-proj-share=/usr/share/proj \
--without-odbc \
--with-sqlite \
--with-nls \
--without-tcltk \
--with-python=/usr/bin/python-config \
--without-cairo \
--without-opengl \
--with-wxwidgets=/usr/bin/wx-config \
--with-fftw \
--with-blas \
--with-lapack \
--without-freetype \
--enable-largefile \
--with-x \
--x-includes=/usr/include/X11/

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

yum provides */<name of the file>

and then installed with your favourite package manager frontend.

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

===== Zaurus =====

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

==== Mac OSX ====

* see the source/macosx readme
* also see [[Compiling on MacOSX]]
* some notes on [[Packaging on MacOSX]]

==== Solaris ====

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

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

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

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

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

The pre-built packages don't work.

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

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

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

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

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

* Next configure, e. g.:

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

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

then:

make
su
make install

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

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

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

==== AIX ====

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

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

The environment variables and configure command that worked were:

export PATH=/usr/local/bin:/opt/freeware/bin:$PATH
export OBJECT_MODE=64
export LIBICONV=/opt/freeware
export CC="xlc_r -q64"
export CFLAGS="-O -qstrict"
export CXX="xlC_r -q64"
export CXXFLAGS="-O -qstrict"
export AR="ar -X64"
export F77="xlf_r -q64"
export CPPFLAGS="-I/afs/isis/pkg/libpng/include -I/usr/local/include -I$LIBICONV/include -I/usr/lpp/X11/include/X11"
export LDFLAGS="-L/usr/local/lib -L$LIBICONV/lib -L/usr/lib -L/usr/X11R6/lib -lc"

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

==== MS-Windows ====

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

... see [http://grass.itc.it/platforms/wingrass.html here] (should be moved to the Wiki)

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

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

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

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

=== Common problems and solutions ===

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

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

=== Optimization ===

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

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

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

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

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

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

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

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

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

=== Configure options and their meanings ===

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

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

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

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

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



== Addons ==

=== GRASS-GDAL plugin ===

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

=== Compiled C modules ===

'''Requirements:'''

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

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

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

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

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

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

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

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

=== Scripts ===

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

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

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

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

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

V.krige GSoC 2009

2009-12-28T14:09:15Z

⚠️AnneGhisla: removed x/y column hack and added maptools dependency

=== v.krige: Python porting and [[wxGUI]] addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by [[User:Landa|Martin Landa]] and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

'''V.krige is now into GRASS trunk and devbr_6 code! (r40048 or higher)'''

[[File:Schermata-Kriging Module.png|450px|left]]

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

For GRASS 6.5 <r40048, it is easy to install it via [http://grass.osgeo.org/grass65/manuals/html65_user/g.extension.html g.extension] (for GRASS 6.4 it is an AddOn, from 6.5+/7 onwards included). Simply type in a GRASS shell:

g.extension v.krige

To install v.krige.py from source, please refer to [[Compile_and_Install#Scripts]]. Source is available on SVN:

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

'''The module requires GRASS >= 6.4 RC5''' - it uses the new version of grass-python library. At the moment, no backward compatibility with previous versions is provided.

The module has dependencies:
* R 2.x - no exhaustive tests on compatible versions. An up-to-date R package will do the job in 99% cases.
* R packages spgrass6, gstat and maptools
* Python module rpy2

Be sure that ALL these dependencies are installed and operative. See below for platform-specific details.

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)
install.packages("maptools", dep=T)

either the brand new Debian packages [6], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6 maptools

=== Notes for Windows ===
At this very moment, no backward compatibility with OSGeo4W's packaged GRASS 6.4svn2 is provided, nor with WinGRASS. Testing is planned, as latest WinGRASS includes the most recent python library.

If you really need to run v.krige right now on Windows, I suggest to compile GRASS following [http://trac.osgeo.org/grass/wiki/CompileOnWindows this guide].
You could also use Linux in a virtual machine. Or install Linux in a separate partition of the HD. This is not as painful as it appears, there are lots of guides over the Internet to help you.

== Bulletin Board ==

* '''TODOs'''
** [permanent todo] Cleanup code! Refactoring brings refactoring.
** wxGUI: Split widget creation and layout - makes more readable code
** Solve '''double parsing issue from RunCmd.''' This leads to unnecessary double dependency check.
** Continue integrating '''gstat functions''' - universal kriging first.
** Add '''region resolution parameter in interface''', showing the current value and allowing the user to modify it before kriging. High resolution slows down computation and give better results, but the user should have a clear feedback (I have been surprised by long runs more than once, because I was not aware of resolution).
** wxGUI: GetVector() should check for name validity, if a string is inserted?

* '''IDEAS TO DISCUSS'''
** '''Splash screen at module load''' will be implemented, but activated only if maps are more than a threshold number [Markus Neteler's suggestion]
** Create a '''package''' to delegate dependencies check? (Stefan Krüger's suggestion)

* '''BROKEN WINDOWS (from Martin Fowler's great book [0]) '''
** Imperfect logging - relies on RunCmd...
** The RBookPage::refresh() function has an endless cycle that keeps R graphics window responsive, even when that window has been closed by the user.
** spgrass6::readVECT6() and mapset name - see [http://lists.osgeo.org/pipermail/grass-stats/2009-August/001126.html this thread].

* '''FUTURE PLANS'''
** Keep on working on v.krige and solve above problems
** Backward compatibility of CLI at least

== Documentation ==

Notes on v.krige usage, examples and tips are available in the module's help page, available via Help button if the GUI.

Kriging theory is available in Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [1]. Another great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [2] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft and definitive:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [3].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [4] ==

'''Report #1, 29 May'''

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [1], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [5]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

'''Report #2, 5 June'''

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

'''Report #2.5, 11 June'''

First of all, the interface is almost finished..
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

'''Report #3, 12 June'''

this weekly report will be very short, as yesterday I sent this email (Report 2.5, see above) and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK because of projection information handling.

'''Report #4, 19 June'''

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check and data load, and examine how to integrate gstat functions.

'''Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event])'''

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

'''Report #6, 3 July'''

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

'''Report #7, midterm, 10 July'''

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

'''Report #8, 17 July'''

this week I added Command output tab and the option for block kriging, and updated documentation with more precise information on dependencies.
I'll add splashscreen only as dependency check and command output will be fixed: next week I plan to work on these latter issues.

Nothing in particular is blocking progress, just some hardest stone sometimes.

'''Report #9, 24 July'''

this week I didn't work on the project because I attended last university course (botanical survey at Stelvio pass) and came back yesterday night.

Next week I plan to solve g.parser issue about double dependency check and the issue about sill, nugget and value parameters, that are optional
for R. A general cleanup of the code is also welcome...

No blocking issues atm.

'''Report #10, 31 July'''

good news from v.krige:
* fixed optional parameters also in interface - activated by a checkbox, otherwise R's NA value is correctly set
* interactive variogram fit is on its way - stay tuned!

Next week I plan to set up interactive variogram using matplotlib functions and get the stabler code possible for feature freeze.

'''Report #11, 7 August'''

this week I worked on error handling by GUI, adding controls on input data and parameters and hiding Run and Plot buttons unless all options are suitable.
Variogram plotting is on its way - I discarded matplotlib to avoid further dependencies, in favour of wx.lib.plot.

'''Report #12, 14 August'''

this is last SoC report - bringing variogram plotting into v.krige! After a long time searching for the lightest and cleanest implementation, R plotting raised as the best solution. On user demand, a R graphics window plots variogram and refreshes it, without interfering with wxGUI.
Documentation includes a full example using Spearfish dataset and all informations about dependencies.

Many thanks to all who have helped me writing v.krige: GRASS and R developers, OSGeo SoC crew, wise friends, all testers.
I hope this module will attract people towards GRASS and R, and provide a valid alternative to closed-source kriging tools.

== References ==
* [0] Fowler, Beck, Brant, Opdyke, Roberts, 1999. "Refactoring. Improving the design of existing code" (ISBN-10: 0201485672; ISBN-13: 978-0201485677)
* [1] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics" (ISBN 0-19-505013-4)
* [2] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [3] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [4] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [5] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [6] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]
[[Category:R]]

AddOns

2009-12-18T16:42:00Z

⚠️AnneGhisla: /* v.krige */ moved into trunk

This page contains references to user contributions and add-ons (the original GRASS GIS software can be downloaded [http://grass.osgeo.org/download/index.php here]).

__TOC__

== AddOns source code repository ==

The AddOns source code is hosted in [http://svn.osgeo.org/grass/grass-addons/ GRASS-AddOns SVN repository].

To checkout:

svn checkout <nowiki>https://svn.osgeo.org/grass/grass-addons/</nowiki> grass-addons

Please read [http://trac.osgeo.org/grass/wiki/HowToContribute#WriteaccesstotheGRASS-Addons-SVNrepository How to get write access to the GRASS-Addons-SVN repository] and contact the [http://lists.osgeo.org/mailman/listinfo/grass-dev grass-dev] mailing list if you would like to host your module there.

== Building and installing Addons ==

* see the [[Compile and Install#Addons]] wiki page

== Adding something new ==

Please announce your add-on to the GRASS users' mailing list so that others may be aware of your work. Also please consider adding your module to one of the [[Applications]] pages.

=== Copyright and licensing information ===

''Please be sure to include copyright and licensing information in the header comments of your code so that others may know how they can use, extend, modify, and redistribute your work.''

e.g. at the top of a shell script:
<pre>
#!/bin/sh
############################################################################
#
# MODULE: v.in.e00
#
# AUTHOR(S): Markus Neteler, Otto Dassau
#
# PURPOSE: Import E00 data into a GRASS vector map
# Imports single and split E00 files (.e00, .e01, .e02 ...)
#
# COPYRIGHT: (c) 2004, 2005 GDF Hannover bR, http://www.gdf-hannover.de
#
# This program is free software under the GNU General Public
# License (>=v2). Read the file COPYING that comes with GRASS
# for details.
#
#############################################################################
#
# REQUIREMENTS:
# - avcimport: http://avce00.maptools.org

[script follows]
</pre>

=== Coding standards ===

Please have a look at our [http://grass.osgeo.org/grass63/source/SUBMITTING_SCRIPTS Shell script coding standards] before submitting here.

There are other coding standards given for modules written in C, Tcl/Tk, and Python''(?)'' located in the GRASS source code.

=== Documenting your code ===

You can have an help page template auto-generated by using the GRASS [[module command line parser | command line parser]] with the <tt>--html-description</tt> command line option. Please, see also the [http://grass.ibiblio.org/grass63/manuals/html63_user/g.parser.html g.parser help page]

== Miscellaneous Add-ons ==

* [http://trac.osgeo.org/grass/browser/grass-addons/misc/utm_which_zone utm_which_zone.sh] is a shell script to determine UTM zone from Lat/Lon input. Requires [http://www.octave.org Octave] or Matlab to be installed. A shell-only version is [http://dcalvelo.free.fr/grass/utm_which_zone_sh.sh available] which only requires awk. '''Authors''': Hamish Bowman (Octave part), Markus Neteler (shell script wrapper), Daniel Calvelo (sh+awk version)

* Perl scripts for converting data forth and back between Excel files and PostgreSQL: [http://dcalvelo.free.fr/grass/pg2xls.pl pg2xls.pl] reads data from PostgreSQL and produces an excel workbook; [http://dcalvelo.free.fr/grass/xls2sql.pl xls2sql.pl] reads excel files and outputs SQL statements to be fed into an RDBMS. Both scripts need modules from [http://www.cpan.org CPAN], especially [http://search.cpan.org/dist/Spreadsheet-ParseExcel/ Spreadsheet::ParseExcel] for xls2sql.pl and [http://search.cpan.org/~tmtm/Spreadsheet-WriteExcel-FromDB Spreadsheet::WriteExcel::FromDB] and its dependencies for pg2sql.pl. Check the source headers for more info. '''Authors:''' Daniel Calvelo (xls2sql.pl), Markus Neteler (pg2xls.pl)

* [http://dream.lrrl.arch.tu-muenchen.de/~wqual/perl/dbf2sql.tgz dbf2sql] is a Perl script for translating dbf-tables into a sql-command. dbf-tables are read using dbfdump-command from dbd-xbase-perl module ([http://search.cpan.org/~janpaz/DBD-XBase-0.241/ dbd::xbase] and [http://search.cpan.org/~jv/Getopt-Long-2.35/lib/Getopt/Long.pm getopt::long] have to be installed from CPAN first). There are problems, if the last column of the table contains characters. Suggestions for improvements welcome! '''Author:'''Wolfgang Qual

* [http://www.igc.usp.br/pessoais/guano/downloads/azimuth2.c azimuth2.c] is a small C program to calculate the azimuth and length of vector lines exported by GRASS-GIS as ASCII files (like this: v.out.ascii input=vector output=ascii format=standard). It is useful for create rose diagrams of lineament maps. Improvements on the original code after suggestions by Örs Téglásy, Hungary. '''Author:''' Carlos Henrique Grohmann

==GRASS 4.x==

===Raster add-ons for GRASS 4===

* MAGICAL Software: The MAGICAL software comprises a suite of three programs that provide a multi-agent simulation extension for the GRASS GIS software. http://www.ucl.ac.uk/~tcrnmar/simulation/magical/magical.html

==GRASS 5.x==

===Vector add-ons for GRASS 5===

* See here: http://grass.osgeo.org/download/addons.php

===Raster add-ons for GRASS 5===

* See here: http://grass.osgeo.org/download/addons.php

* [http://www.valledemexico.ambitiouslemon.com/gwmodelling.html r.gmtg] The groundwater modelling tool for grass. A module to use MODFLOW within GRASS. '''Author''': Jaime Carrera

* [http://www.bowdoin.edu/~ltoma/research.html r.terracost] Scalable approach for computing least-cost-path surfaces on massive grid terrains. For GRASS 5.3. '''Lead author''': Laura Toma
:Newer version available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.terracost

==GRASS 6.x==

=== Vector add-ons ===

See also

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

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

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

Available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/vector/adehabitat

==== v.append ====

: [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.append v.append] is a shell script combining two vector files AND their associated attribute tables. The vector files should be of the same type and, for best results, should have identically formatted attribute tables.

: '''Author:''' Michael Barton

==== v.autokrige ====

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

: '''Author:''' Mathieu Grelier

==== v.breach ====

: [http://www.sieczka.org/programy_en.html v.breach] creates vector maps of lines and points of continously lowering elevation down the input watercourses, based on the input raster DEM.

: '''Author:''' Maciej Sieczka

==== v.colors ====

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

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

: [http://wiki.iosa.it/dokuwiki/spatial_analysis:feature_count v.count.points.sh] counts point features in areas, generates table good as input to d.vect.chart.

: '''Author:''' Stefano Costa

==== v.digatt ====

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

: '''Author:''' Andreas Philipp

==== v.dip ====

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

: '''Author:''' Marcin Slodkowski

==== v.flip ====

: [http://www.sieczka.org/programy_en.html v.flip] flips the direction of selected vector lines (redundant since GRASS 6.3 - there is "v.edit tool=flip").

: '''Author:''' Maciej Sieczka

==== v.group ====

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

: '''Author:''' Cedric Shock

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

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

:'''Author:''' Martin Landa

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

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

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

:'''Author:''' Benjamin Ducke

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

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

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

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

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

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

: '''Author:''' Huidae Cho

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

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

: '''Author:''' Mathieu Grelier

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

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

: '''Author:''' Jannis Achstetter

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

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

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

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

==== v.krige ====

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

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

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

==== v.lda ====

: [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.lda v.lda] is a shell script for calculating Ian Johnson's (U. Sidney) Local Density Analysis values to measure clustering of point data at different neighborhood radii. There is an option to create a simple line graph of the results. There have been reports of problems creating the line graph on Cygwin installations of GRASS.

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

: [http://www.sieczka.org/programy_en.html v.line.center] creates a points vector map with each point located in the middle of the length of the input vector line.

: '''Author:''' Maciej Sieczka

==== v.lmeasure ====

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

: '''Author:''' Mats Schuh

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Hamish Bowman

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

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

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

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

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

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

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

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

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

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

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

: '''Author:''' Hamish Bowman

==== v.rasterbounds ====

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

: '''Author:''' Jachym Cepicky

==== v.sample.buffer [broken link, please update or delete]====

: [http://www.clubwebcanada.ca/twiens/v.sample.buffer.tgz v.sample.buffer] is a shell script that samples rasters in buffers of a specified size around features in a specified vector file. Sampling results are added as attributes to the vector file. This script was designed for sampling vegetation indices and DEM derived attributes for bird point counts. Sampling results can be one or more basic statistics such as mean, range, max, etc.

: '''Author:''' Trevor Wiens

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

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

: '''Author:''' Eric Patton

==== v.selmany ====

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

: '''Author:''' Vincent Bain

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Giovanni Allegri

==== v.surf.krige [deprecated: use v.autokrige instead] ====

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

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

==== v.strahler ====

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

: '''Author:''' Florian Kindl. Available via SVN:

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

==== v.swathwidth ====

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

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

==== v.thickness ====

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

: '''Author:''' Marcin Slodkowski

==== v.trees3d ====

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

: '''Author:''' Jachym Cepicky

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

: '''Author:''' Jaime Carrera

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

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

: '''Author:''' Hamish Bowman

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

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

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

==== AniMove ====

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

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

==== Utilities ====

===== Shapemerge =====

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

:'''Authors:''' Perrygeo

=== Raster add-ons ===

See also

svn co <nowiki>https://svn.osgeo.org/grass/grass-addons/raster</nowiki>

==== r.bilateral ====

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

: '''Author:''' Jachym Cepicky

==== r.boxcount ====

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

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

Available via SVN:

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

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

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

:'''Author:''' Benjamin Ducke

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

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

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

: '''Authors:''' Mathieu Grelier

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

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

==== r.cpt2grass ====

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

: '''Author:''' Hamish Bowman

==== r.csr ====

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

: '''Author:''' Eric Patton

==== r.cva ====

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

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

==== r.denoise ====

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

: '''Author:''' John Stevenson

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

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

: '''Author:''' Hamish Bowman

==== r.eucdist ====

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

: '''Author:''' David Finlayson

==== r.fragment ====

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

==== r.game_of_life ====

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

: '''Author:''' Hamish Bowman

==== r.gauss ====

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

:'''Author:''' Jachym Cepicky

==== r.gradgrid4 ====

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

: '''Author:''' Martin Mergili

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

: [http://www-pool.math.tu-berlin.de/~soeren/grass/modules/ r.in.onearth] for download and import satellite images direct from the NASA onearth WMS server into GRASS.

: '''Author:''' Soeren Gebbert

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

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

: '''Author:''' Jachym Cepicky

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

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

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

==== r.isoregions ====

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

: '''Authors:''' Mathieu Grelier

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

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

: '''Author:''' David Finlayson

==== r.li ====

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

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

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

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

: '''Author:''' Jachym Cepicky

==== r.mandelbrot ====

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

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

==== mcda====

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

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

Available via SVN:

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

==== r.mlv ====

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

: '''Author:''' Jachym Cepicky

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

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

: '''Author:''' Giovanni Allegri

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

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

: '''Author:''' Tomas Cebecauer

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

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

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

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

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

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

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

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

: '''Author:''' Hamish Bowman

==== r.pack ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.pack r.pack and r.unpack] are two GRASS scripts for transfering raster maps to another computer as a single file.

: '''Author:''' Hamish Bowman

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

Available via SVN:

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

==== r.roughness ====

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

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

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

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

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

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

Available via SVN:

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

==== r.roughset ====

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

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

Available via SVN:

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

==== r.smoothpatch ====

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

: '''Author:''' David Finlayson

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

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

:'''Author:''' Gianluca Massei

Available via SVN:

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

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

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

: '''Author:''' Markus Metz

Available via SVN:

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

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

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.stream.order r.stream.order] orders stream network outputed by r.watershed or r.stream.extract according Sthrahler, Shreve, Horton and Hack ordering systems. It require as input stream and direction map and optionally accumulation map. It handle both SFD nad MFD modes but all data must come from the same procedure.

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

Available via SVN:

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

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

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

: '''Author:''' Jarek Jasiewicz

Available via SVN:

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

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

: [http://www.sieczka.org/programy_en.html r.surf.nnbathy] interpolates a surface from a raster input using Pavel Sakov's [http://code.google.com/p/nn-c/ nn] natural neighbor interpolation library. Provides triangulation, Sibson natural neighbor interpolation and non-Sibsonian interpolation.

: '''Author:''' Maciej Sieczka

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

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

: '''Author:''' Hamish Bowman

==== r.terracost ====

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

Available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.terracost

==== r.tileset ====

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

==== r.traveltime ====

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

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

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

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

: '''Author:''' Markus Metz

Available via SVN:

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

==== r.viewshed ====

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

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

Available via SVN:

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

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

==== r.xtent ====

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

:'''Author:''' Benjamin Ducke

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

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

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

: '''Author:''' Jachym Cepicky

==== GIPE ====

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==== HydroFOSS ====

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

: '''Author:''' Massimiliano Cannata

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

==== Hikereport ====

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

: '''Author:''' Stefano Negri

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

=== Misc add-ons===

==== m.eigensystem ====

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

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

: '''Author:''' Michael Shapiro

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

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

: '''Author:''' Markus Neteler. Available via SVN:

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

===General add-ons===

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

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

: '''Author:''' Otto Dassau

==== Readline completion ====

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

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

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

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

: '''Author:''' Hamish Bowman

==== g.linke_by_day ====

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

: '''Author:''' Hamish Bowman

==== g.xlist ====

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

: '''Author:''' Huidae Cho

==== g.xremove ====

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

: '''Author:''' Huidae Cho

=== Imagery add-ons ===

See also

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

==== GIPE ====

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

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

: '''Author:''' Yann Chemin

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

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

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

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

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Georg Kaspar

==== i.pr ====

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

: '''Author:''' Stefano Merler. Available via SVN:

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

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

: Spectral Angle mapping

: '''Author:''' Markus Neteler. Available via SVN:

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

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

: Spectral unmixing

: '''Author:''' Markus Neteler. Available via SVN:

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

==== i.warp ====

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

: '''Author:''' Hamish Bowman

=== Display add-ons ===

See also

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

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

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

: '''Author:''' Huidae Cho

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

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

: '''Author:''' Hamish Bowman

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

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

==== d.hyperlink ====

: [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/d.hyperlink.tar.bz2 d.hyperlink] is an interactive shell script that allows the viewing of hyperlinked images from a vector's attribute table in an external image viewer. Queries can be made via SQL statements or interactive mouse-clicking. The attribute table must be pre-populated with a column containing the image to link the vector to; the user also specifies the image folder in the current MAPSET where the images are located. The script currently supports gimp, Eye of Gnome, gthumb, gpdf, and Inkscape image viewers.

: '''Author: '''Eric Patton

==== d.mark ====

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Hamish Bowman

==== d.stations ====

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

: '''Author:''' Hamish Bowman

==== d.varea ====

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

: '''Author:''' Hamish Bowman

==== pd-GRASS ====

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

: '''Author:''' Alex Sorokine

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

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

=== Postscript add-ons ===

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

==== ps.atlas ====

: [http://les-ejk.cz/programs/grass/ps.atlas ps.atlas] is a shell script that makes more maps on current region according to input *.psmap file. General map can be stored as vector file. The resulting *.eps maps can be automatically converted to *.pdf files.

: '''Author:''' Jachym Cepicky

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

* Hatches for ps.map's vareas

===GRASS and UMN Mapserver===

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

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

V.krige GSoC 2009

2009-12-18T16:39:16Z

⚠️AnneGhisla: v.krige into trunk!

=== v.krige: Python porting and [[wxGUI]] addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by [[User:Landa|Martin Landa]] and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

'''V.krige is now into GRASS trunk and devbr_6 code! (r40048 or higher)'''

[[File:Schermata-Kriging Module.png|450px|left]]

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

For GRASS 6.5 <r40048, it is easy to install it via [http://grass.osgeo.org/grass65/manuals/html65_user/g.extension.html g.extension] (for GRASS 6.4 it is an AddOn, from 6.5+/7 onwards included). Simply type in a GRASS shell:

g.extension v.krige

To install v.krige.py from source, please refer to [[Compile_and_Install#Scripts]]. Source is available on SVN:

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

'''The module requires GRASS >= 6.4 RC5''' - it uses the new version of grass-python library. At the moment, no backward compatibility with previous versions is provided.

The module has dependencies:
* R 2.x - no exhaustive tests on compatible versions. An up-to-date R package will do the job in 99% cases.
* R packages spgrass6 and gstat
* Python module rpy2

Be sure that ALL these dependencies are installed and operative. See below for platform-specific details.

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)

either the brand new Debian packages [6], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6

=== Notes for Windows ===
At this very moment, no backward compatibility with OSGeo4W's packaged GRASS 6.4svn2 is provided, nor with WinGRASS.

If you really need to run v.krige right now on Windows, I suggest to compile GRASS following [http://trac.osgeo.org/grass/wiki/CompileOnWindows this guide].
You could also use Linux in a virtual machine. Or install Linux in a separate partition of the HD. This is not as painful as it appears, there are lots of guides over the Internet to help you.

== Bulletin Board ==

* '''TODOs'''
** [permanent todo] Cleanup code! Refactoring brings refactoring.
** wxGUI: Split widget creation and layout - makes more readable code
** Solve '''double parsing issue from RunCmd.''' This leads to unnecessary double dependency check.
** Continue integrating '''gstat functions''' - universal kriging first.
** Add '''region resolution parameter in interface''', showing the current value and allowing the user to modify it before kriging. High resolution slows down computation and give better results, but the user should have a clear feedback (I have been surprised by long runs more than once, because I was not aware of resolution).
** wxGUI: GetVector() should check for name validity, if a string is inserted?

* '''IDEAS TO DISCUSS'''
** '''Splash screen at module load''' will be implemented, but activated only if maps are more than a threshold number [Markus Neteler's suggestion]
** Create a '''package''' to delegate dependencies check? (Stefan Krüger's suggestion)
** As kriging function from gstat requires x,y columns into attribute table, the actual implementation is a hack. Problems can arise if the map comes from another mapset, and it is unfair to modify input data.

* '''BROKEN WINDOWS (from Martin Fowler's great book [0]) '''
** Imperfect logging - relies on RunCmd...
** The RBookPage::refresh() function has an endless cycle that keeps R graphics window responsive, even when that window has been closed by the user.
** spgrass6::readVECT6() and mapset name - see [http://lists.osgeo.org/pipermail/grass-stats/2009-August/001126.html this thread].

* '''FUTURE PLANS'''
** Keep on working on v.krige and solve above problems
** Backward compatibility of CLI at least

== Documentation ==

Notes on v.krige usage, examples and tips are available in the module's help page, available via Help button if the GUI.

Kriging theory is available in Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [1]. Another great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [2] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft and definitive:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [3].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [4] ==

'''Report #1, 29 May'''

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [1], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [5]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

'''Report #2, 5 June'''

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

'''Report #2.5, 11 June'''

First of all, the interface is almost finished..
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

'''Report #3, 12 June'''

this weekly report will be very short, as yesterday I sent this email (Report 2.5, see above) and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK because of projection information handling.

'''Report #4, 19 June'''

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check and data load, and examine how to integrate gstat functions.

'''Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event])'''

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

'''Report #6, 3 July'''

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

'''Report #7, midterm, 10 July'''

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

'''Report #8, 17 July'''

this week I added Command output tab and the option for block kriging, and updated documentation with more precise information on dependencies.
I'll add splashscreen only as dependency check and command output will be fixed: next week I plan to work on these latter issues.

Nothing in particular is blocking progress, just some hardest stone sometimes.

'''Report #9, 24 July'''

this week I didn't work on the project because I attended last university course (botanical survey at Stelvio pass) and came back yesterday night.

Next week I plan to solve g.parser issue about double dependency check and the issue about sill, nugget and value parameters, that are optional
for R. A general cleanup of the code is also welcome...

No blocking issues atm.

'''Report #10, 31 July'''

good news from v.krige:
* fixed optional parameters also in interface - activated by a checkbox, otherwise R's NA value is correctly set
* interactive variogram fit is on its way - stay tuned!

Next week I plan to set up interactive variogram using matplotlib functions and get the stabler code possible for feature freeze.

'''Report #11, 7 August'''

this week I worked on error handling by GUI, adding controls on input data and parameters and hiding Run and Plot buttons unless all options are suitable.
Variogram plotting is on its way - I discarded matplotlib to avoid further dependencies, in favour of wx.lib.plot.

'''Report #12, 14 August'''

this is last SoC report - bringing variogram plotting into v.krige! After a long time searching for the lightest and cleanest implementation, R plotting raised as the best solution. On user demand, a R graphics window plots variogram and refreshes it, without interfering with wxGUI.
Documentation includes a full example using Spearfish dataset and all informations about dependencies.

Many thanks to all who have helped me writing v.krige: GRASS and R developers, OSGeo SoC crew, wise friends, all testers.
I hope this module will attract people towards GRASS and R, and provide a valid alternative to closed-source kriging tools.

== References ==
* [0] Fowler, Beck, Brant, Opdyke, Roberts, 1999. "Refactoring. Improving the design of existing code" (ISBN-10: 0201485672; ISBN-13: 978-0201485677)
* [1] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics" (ISBN 0-19-505013-4)
* [2] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [3] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [4] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [5] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [6] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]
[[Category:R]]

V.krige GSoC 2009

2009-10-20T09:25:29Z

⚠️AnneGhisla: /* Bulletin Board */ update

=== v.krige: Python porting and [[wxGUI]] addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by [[User:Landa|Martin Landa]] and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

'''Interactive variogram fit is available! (r38714 or higher)''' In gstat tab, the button labeled "Plot/refresh variogram" calls up a R graphics window with the data variogram and the fitted curve. Play with options to obtain the best fit, refresh plot, and when the model fits the data, run kriging!

[[File:Schermata-Kriging Module.png|450px|left]]

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

It is easy to install it via [http://grass.osgeo.org/grass65/manuals/html65_user/g.extension.html g.extension] (for GRASS 6.4 it is an AddOn, from 6.5+/7 onwards included). Simply type in a GRASS shell:

g.extension v.krige

To install v.krige.py from source, please refer to [[Compile_and_Install#Scripts]]. Source is available on SVN:

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

'''The module requires GRASS >= 6.4 RC5''' - it uses the new version of grass-python library. At the moment, no backward compatibility with previous versions is provided.

The module has dependencies:
* R 2.x - no exhaustive tests on compatible versions. An up-to-date R package will do the job in 99% cases.
* R packages spgrass6 and gstat
* Python module rpy2

Be sure that ALL these dependencies are installed and operative. See below for platform-specific details.

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)

either the brand new Debian packages [6], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6

=== Notes for Windows ===
At this very moment, no backward compatibility with OSGeo4W's packaged GRASS 6.4svn2 is provided, nor with WinGRASS.

If you really need to run v.krige right now on Windows, I suggest to compile GRASS following [http://trac.osgeo.org/grass/wiki/CompileOnWindows this guide].
You could also use Linux in a virtual machine. Or install Linux in a separate partition of the HD. This is not as painful as it appears, there are lots of guides over the Internet to help you.

== Bulletin Board ==

* '''TODOs'''
** [permanent todo] Cleanup code! Refactoring brings refactoring.
** wxGUI: Split widget creation and layout - makes more readable code
** Solve '''double parsing issue from RunCmd.''' This leads to unnecessary double dependency check.
** Continue integrating '''gstat functions''' - universal kriging first.
** Add '''region resolution parameter in interface''', showing the current value and allowing the user to modify it before kriging. High resolution slows down computation and give better results, but the user should have a clear feedback (I have been surprised by long runs more than once, because I was not aware of resolution).
** wxGUI: GetVector() should check for name validity, if a string is inserted?

* '''IDEAS TO DISCUSS'''
** '''Splash screen at module load''' will be implemented, but activated only if maps are more than a threshold number [Markus Neteler's suggestion]
** Create a '''package''' to delegate dependencies check? (Stefan Krüger's suggestion)
** As kriging function from gstat requires x,y columns into attribute table, the actual implementation is a hack. Problems can arise if the map comes from another mapset, and it is unfair to modify input data.

* '''BROKEN WINDOWS (from Martin Fowler's great book [0]) '''
** Imperfect logging - relies on RunCmd...
** The RBookPage::refresh() function has an endless cycle that keeps R graphics window responsive, even when that window has been closed by the user.
** spgrass6::readVECT6() and mapset name - see [http://lists.osgeo.org/pipermail/grass-stats/2009-August/001126.html this thread].

* '''FUTURE PLANS'''
** Keep on working on v.krige after SoC, in particular integrate it into GRASS trunk - not before November nor before some more reliability improvements.
** Backward compatibility of CLI at least

== Documentation ==

Notes on v.krige usage, examples and tips are available in the module's help page, available via Help button if the GUI.

Kriging theory is available in Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [1]. Another great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [2] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft and definitive:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [3].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [4] ==

'''Report #1, 29 May'''

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [1], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [5]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

'''Report #2, 5 June'''

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

'''Report #2.5, 11 June'''

First of all, the interface is almost finished..
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

'''Report #3, 12 June'''

this weekly report will be very short, as yesterday I sent this email (Report 2.5, see above) and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK because of projection information handling.

'''Report #4, 19 June'''

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check and data load, and examine how to integrate gstat functions.

'''Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event])'''

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

'''Report #6, 3 July'''

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

'''Report #7, midterm, 10 July'''

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

'''Report #8, 17 July'''

this week I added Command output tab and the option for block kriging, and updated documentation with more precise information on dependencies.
I'll add splashscreen only as dependency check and command output will be fixed: next week I plan to work on these latter issues.

Nothing in particular is blocking progress, just some hardest stone sometimes.

'''Report #9, 24 July'''

this week I didn't work on the project because I attended last university course (botanical survey at Stelvio pass) and came back yesterday night.

Next week I plan to solve g.parser issue about double dependency check and the issue about sill, nugget and value parameters, that are optional
for R. A general cleanup of the code is also welcome...

No blocking issues atm.

'''Report #10, 31 July'''

good news from v.krige:
* fixed optional parameters also in interface - activated by a checkbox, otherwise R's NA value is correctly set
* interactive variogram fit is on its way - stay tuned!

Next week I plan to set up interactive variogram using matplotlib functions and get the stabler code possible for feature freeze.

'''Report #11, 7 August'''

this week I worked on error handling by GUI, adding controls on input data and parameters and hiding Run and Plot buttons unless all options are suitable.
Variogram plotting is on its way - I discarded matplotlib to avoid further dependencies, in favour of wx.lib.plot.

'''Report #12, 14 August'''

this is last SoC report - bringing variogram plotting into v.krige! After a long time searching for the lightest and cleanest implementation, R plotting raised as the best solution. On user demand, a R graphics window plots variogram and refreshes it, without interfering with wxGUI.
Documentation includes a full example using Spearfish dataset and all informations about dependencies.

Many thanks to all who have helped me writing v.krige: GRASS and R developers, OSGeo SoC crew, wise friends, all testers.
I hope this module will attract people towards GRASS and R, and provide a valid alternative to closed-source kriging tools.

== References ==
* [0] Fowler, Beck, Brant, Opdyke, Roberts, 1999. "Refactoring. Improving the design of existing code" (ISBN-10: 0201485672; ISBN-13: 978-0201485677)
* [1] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics" (ISBN 0-19-505013-4)
* [2] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [3] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [4] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [5] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [6] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]
[[Category:R]]

V.krige GSoC 2009

2009-08-28T12:54:45Z

⚠️AnneGhisla: /* Installation */ restored svn link

=== v.krige: Python porting and [[wxGUI]] addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by [[User:Landa|Martin Landa]] and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

'''Interactive variogram fit is available! (r38714 or higher)''' In gstat tab, the button labeled "Plot/refresh variogram" calls up a R graphics window with the data variogram and the fitted curve. Play with options to obtain the best fit, refresh plot, and when the model fits the data, run kriging!

[[File:Schermata-Kriging Module.png|450px|left]]

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

It is easy to install it via [http://grass.osgeo.org/grass65/manuals/html65_user/g.extension.html g.extension] (for GRASS 6.4 it is an AddOn, from 6.5+/7 onwards included). Simply type in a GRASS shell:

g.extension v.krige

To install v.krige.py from source, please refer to [[Compile_and_Install#Scripts]]. Source is available on SVN:

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

'''The module requires GRASS >= 6.4 RC5''' - it uses the new version of grass-python library. At the moment, no backward compatibility with previous versions is provided.

The module has dependencies:
* R 2.x - no exhaustive tests on compatible versions. An up-to-date R package will do the job in 99% cases.
* R packages spgrass6 and gstat
* Python module rpy2

Be sure that ALL these dependencies are installed and operative. See below for platform-specific details.

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)

either the brand new Debian packages [6], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6

=== Notes for Windows ===
At this very moment, no backward compatibility with OSGeo4W's packaged GRASS 6.4svn2 is provided, nor with WinGRASS.

If you really need to run v.krige right now on Windows, I suggest to compile GRASS following [http://trac.osgeo.org/grass/wiki/CompileOnWindows this guide].
You could also use Linux in a virtual machine. Or install Linux in a separate partition of the HD. This is not as painful as it appears, there are lots of guides over the Internet to help you.

== Bulletin Board ==

* '''TODOs'''
** [permanent todo] Cleanup code! Refactoring brings refactoring.
** wxGUI: Split widget creation and layout - makes more readable code
** Solve '''double parsing issue from RunCmd.''' This leads to unnecessary double dependency check.
** Continue integrating '''gstat functions''' - universal kriging first.
** Add '''region resolution parameter in interface''', showing the current value and allowing the user to modify it before kriging. High resolution slows down computation and give better results, but the user should have a clear feedback (I have been surprised by long runs more than once, because I was not aware of resolution).

* '''IDEAS TO DISCUSS'''
** '''Splash screen at module load''' will be implemented, but activated only if maps are more than a threshold number [Markus Neteler's suggestion]
** Create a '''package''' to delegate dependencies check? (Stefan Krüger's suggestion)

* '''BLOCKING ISSUE(S)'''
** No more!!

* '''BROKEN WINDOWS (from Martin Fowler's great book [0]) '''
** Imperfect logging - relies on RunCmd...
** The RBookPage::refresh() function has an endless cycle that keeps R graphics window responsive, even when that window has been closed by the user.
** spgrass6::readVECT6() and mapset name - see [http://lists.osgeo.org/pipermail/grass-stats/2009-August/001126.html this thread].

* '''FUTURE PLANS'''
** Keep on working on v.krige after SoC, in particular integrate it into GRASS trunk - not before November nor before some more reliability improvements.

== Documentation ==

Notes on v.krige usage, examples and tips are available in the module's help page, available via Help button if the GUI.

Kriging theory is available in Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [1]. Another great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [2] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft and definitive:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [3].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [4] ==

'''Report #1, 29 May'''

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [1], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [5]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

'''Report #2, 5 June'''

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

'''Report #2.5, 11 June'''

First of all, the interface is almost finished..
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

'''Report #3, 12 June'''

this weekly report will be very short, as yesterday I sent this email (Report 2.5, see above) and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK because of projection information handling.

'''Report #4, 19 June'''

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check and data load, and examine how to integrate gstat functions.

'''Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event])'''

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

'''Report #6, 3 July'''

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

'''Report #7, midterm, 10 July'''

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

'''Report #8, 17 July'''

this week I added Command output tab and the option for block kriging, and updated documentation with more precise information on dependencies.
I'll add splashscreen only as dependency check and command output will be fixed: next week I plan to work on these latter issues.

Nothing in particular is blocking progress, just some hardest stone sometimes.

'''Report #9, 24 July'''

this week I didn't work on the project because I attended last university course (botanical survey at Stelvio pass) and came back yesterday night.

Next week I plan to solve g.parser issue about double dependency check and the issue about sill, nugget and value parameters, that are optional
for R. A general cleanup of the code is also welcome...

No blocking issues atm.

'''Report #10, 31 July'''

good news from v.krige:
* fixed optional parameters also in interface - activated by a checkbox, otherwise R's NA value is correctly set
* interactive variogram fit is on its way - stay tuned!

Next week I plan to set up interactive variogram using matplotlib functions and get the stabler code possible for feature freeze.

'''Report #11, 7 August'''

this week I worked on error handling by GUI, adding controls on input data and parameters and hiding Run and Plot buttons unless all options are suitable.
Variogram plotting is on its way - I discarded matplotlib to avoid further dependencies, in favour of wx.lib.plot.

'''Report #12, 14 August'''

this is last SoC report - bringing variogram plotting into v.krige! After a long time searching for the lightest and cleanest implementation, R plotting raised as the best solution. On user demand, a R graphics window plots variogram and refreshes it, without interfering with wxGUI.
Documentation includes a full example using Spearfish dataset and all informations about dependencies.

Many thanks to all who have helped me writing v.krige: GRASS and R developers, OSGeo SoC crew, wise friends, all testers.
I hope this module will attract people towards GRASS and R, and provide a valid alternative to closed-source kriging tools.

== References ==
* [0] Fowler, Beck, Brant, Opdyke, Roberts, 1999. "Refactoring. Improving the design of existing code" (ISBN-10: 0201485672; ISBN-13: 978-0201485677)
* [1] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics" (ISBN 0-19-505013-4)
* [2] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [3] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [4] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [5] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [6] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]
[[Category:R]]

AddOns

2009-08-25T18:20:39Z

⚠️AnneGhisla: /* v.krige */ updated link

This page contains references to user contributions and add-ons (the original GRASS GIS software can be downloaded [http://grass.osgeo.org/download/index.php here]).

__TOC__

== AddOns source code repository ==

The AddOns source code is hosted in [http://svn.osgeo.org/grass/grass-addons/ GRASS-AddOns SVN repository].

To checkout:

svn checkout <nowiki>https://svn.osgeo.org/grass/grass-addons/</nowiki> grass-addons

Please read [http://trac.osgeo.org/grass/wiki/HowToContribute#WriteaccesstotheGRASS-Addons-SVNrepository How to get write access to the GRASS-Addons-SVN repository] and contact the [http://lists.osgeo.org/mailman/listinfo/grass-dev grass-dev] mailing list if you would like to host your module there.

== Building and installing Addons ==

* see the [[Compile and Install#Addons]] wiki page

== Adding something new ==

Please announce your add-on to the GRASS users' mailing list so that others may be aware of your work. Also please consider adding your module to one of the [[Applications]] pages.

=== Copyright and licensing information ===

''Please be sure to include copyright and licensing information in the header comments of your code so that others may know how they can use, extend, modify, and redistribute your work.''

e.g. at the top of a shell script:
<pre>
#!/bin/sh
############################################################################
#
# MODULE: v.in.e00
#
# AUTHOR(S): Markus Neteler, Otto Dassau
#
# PURPOSE: Import E00 data into a GRASS vector map
# Imports single and split E00 files (.e00, .e01, .e02 ...)
#
# COPYRIGHT: (c) 2004, 2005 GDF Hannover bR, http://www.gdf-hannover.de
#
# This program is free software under the GNU General Public
# License (>=v2). Read the file COPYING that comes with GRASS
# for details.
#
#############################################################################
#
# REQUIREMENTS:
# - avcimport: http://avce00.maptools.org

[script follows]
</pre>

=== Coding standards ===

Please have a look at our [http://grass.osgeo.org/grass63/source/SUBMITTING_SCRIPTS Shell script coding standards] before submitting here.

There are other coding standards given for modules written in C, Tcl/Tk, and Python''(?)'' located in the GRASS source code.

=== Documenting your code ===

You can have an help page template auto-generated by using the GRASS [[module command line parser | command line parser]] with the <tt>--html-description</tt> command line option. Please, see also the [http://grass.ibiblio.org/grass63/manuals/html63_user/g.parser.html g.parser help page]

== Miscellaneous Add-ons ==

* [http://trac.osgeo.org/grass/browser/grass-addons/misc/utm_which_zone utm_which_zone.sh] is a shell script to determine UTM zone from Lat/Lon input. Requires [http://www.octave.org Octave] or Matlab to be installed. A shell-only version is [http://dcalvelo.free.fr/grass/utm_which_zone_sh.sh available] which only requires awk. '''Authors''': Hamish Bowman (Octave part), Markus Neteler (shell script wrapper), Daniel Calvelo (sh+awk version)

* Perl scripts for converting data forth and back between Excel files and PostgreSQL: [http://dcalvelo.free.fr/grass/pg2xls.pl pg2xls.pl] reads data from PostgreSQL and produces an excel workbook; [http://dcalvelo.free.fr/grass/xls2sql.pl xls2sql.pl] reads excel files and outputs SQL statements to be fed into an RDBMS. Both scripts need modules from [http://www.cpan.org CPAN], especially [http://search.cpan.org/dist/Spreadsheet-ParseExcel/ Spreadsheet::ParseExcel] for xls2sql.pl and [http://search.cpan.org/~tmtm/Spreadsheet-WriteExcel-FromDB Spreadsheet::WriteExcel::FromDB] and its dependencies for pg2sql.pl. Check the source headers for more info. '''Authors:''' Daniel Calvelo (xls2sql.pl), Markus Neteler (pg2xls.pl)

* [http://dream.lrrl.arch.tu-muenchen.de/~wqual/perl/dbf2sql.tgz dbf2sql] is a Perl script for translating dbf-tables into a sql-command. dbf-tables are read using dbfdump-command from dbd-xbase-perl module ([http://search.cpan.org/~janpaz/DBD-XBase-0.241/ dbd::xbase] and [http://search.cpan.org/~jv/Getopt-Long-2.35/lib/Getopt/Long.pm getopt::long] have to be installed from CPAN first). There are problems, if the last column of the table contains characters. Suggestions for improvements welcome! '''Author:'''Wolfgang Qual

* [http://www.igc.usp.br/pessoais/guano/downloads/azimuth2.c azimuth2.c] is a small C program to calculate the azimuth and length of vector lines exported by GRASS-GIS as ASCII files (like this: v.out.ascii input=vector output=ascii format=standard). It is useful for create rose diagrams of lineament maps. Improvements on the original code after suggestions by Örs Téglásy, Hungary. '''Author:''' Carlos Henrique Grohmann

==GRASS 4.x==

===Raster add-ons for GRASS 4===

* MAGICAL Software: The MAGICAL software comprises a suite of three programs that provide a multi-agent simulation extension for the GRASS GIS software. http://www.ucl.ac.uk/~tcrnmar/simulation/magical/magical.html

==GRASS 5.x==

===Vector add-ons for GRASS 5===

* See here: http://grass.osgeo.org/download/addons.php

===Raster add-ons for GRASS 5===

* See here: http://grass.osgeo.org/download/addons.php

* [http://www.valledemexico.ambitiouslemon.com/gwmodelling.html r.gmtg] The groundwater modelling tool for grass. A module to use MODFLOW within GRASS. '''Author''': Jaime Carrera

* [http://www.bowdoin.edu/~ltoma/research.html r.terracost] Scalable approach for computing least-cost-path surfaces on massive grid terrains. For GRASS 5.3. '''Lead author''': Laura Toma
:Newer version available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.terracost

==GRASS 6.x==

=== Vector add-ons ===

See also

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

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

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

Available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/vector/adehabitat

==== v.append ====

: [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.append v.append] is a shell script combining two vector files AND their associated attribute tables. The vector files should be of the same type and, for best results, should have identically formatted attribute tables.

: '''Author:''' Michael Barton

==== v.autokrige ====

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

: '''Author:''' Mathieu Grelier

==== v.breach ====

: [http://www.sieczka.org/programy_en.html v.breach] creates vector maps of lines and points of continously lowering elevation down the input watercourses, based on the input raster DEM.

: '''Author:''' Maciej Sieczka

==== v.colors ====

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

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

: [http://wiki.iosa.it/dokuwiki/spatial_analysis:feature_count v.count.points.sh] counts point features in areas, generates table good as input to d.vect.chart.

: '''Author:''' Stefano Costa

==== v.digatt ====

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

: '''Author:''' Andreas Philipp

==== v.dip ====

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

: '''Author:''' Marcin Slodkowski

==== v.flip ====

: [http://www.sieczka.org/programy_en.html v.flip] flips the direction of selected vector lines (redundant since GRASS 6.3 - there is "v.edit tool=flip").

: '''Author:''' Maciej Sieczka

==== v.group ====

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

: '''Author:''' Cedric Shock

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

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

:'''Author:''' Martin Landa

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

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

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

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

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

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

: '''Author:''' Huidae Cho

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

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

: '''Author:''' Mathieu Grelier

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

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

: '''Author:''' Jannis Achstetter

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

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

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

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

==== v.krige ====

: [[V.krige_GSoC_2009 | v.krige]] aims to integrate R functions for kriging (packages automap, gstat, geoR) in a trasparent way. '''Still beta''': testing welcome.

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

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

==== v.lda ====

: [http://www.public.asu.edu/~cmbarton/files/grass_scripts/v.lda v.lda] is a shell script for calculating Ian Johnson's (U. Sidney) Local Density Analysis values to measure clustering of point data at different neighborhood radii. There is an option to create a simple line graph of the results. There have been reports of problems creating the line graph on Cygwin installations of GRASS.

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

: [http://www.sieczka.org/programy_en.html v.line.center] creates a points vector map with each point located in the middle of the length of the input vector line.

: '''Author:''' Maciej Sieczka

==== v.lmeasure ====

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

: '''Author:''' Mats Schuh

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Hamish Bowman

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

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

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

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

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

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

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

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

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

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

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

: '''Author:''' Hamish Bowman

==== v.rasterbounds ====

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

: '''Author:''' Jachym Cepicky

==== v.sample.buffer [broken link, please update or delete]====

: [http://www.clubwebcanada.ca/twiens/v.sample.buffer.tgz v.sample.buffer] is a shell script that samples rasters in buffers of a specified size around features in a specified vector file. Sampling results are added as attributes to the vector file. This script was designed for sampling vegetation indices and DEM derived attributes for bird point counts. Sampling results can be one or more basic statistics such as mean, range, max, etc.

: '''Author:''' Trevor Wiens

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

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

: '''Author:''' Eric Patton

==== v.selmany ====

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

: '''Author:''' Vincent Bain

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

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

: '''Author:''' Hamish Bowman

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

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

: '''Author:''' Giovanni Allegri

==== v.surf.krige [deprecated: use v.autokrige instead] ====

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

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

==== v.strahler ====

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

: '''Author:''' Florian Kindl. Available via SVN:

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

==== v.swathwidth ====

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

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

==== v.thickness ====

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

: '''Author:''' Marcin Slodkowski

==== v.trees3d ====

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

: '''Author:''' Jachym Cepicky

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

: '''Author:''' Jaime Carrera

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

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

: '''Author:''' Hamish Bowman

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

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

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

==== AniMove ====

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

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

==== Utilities ====

===== Shapemerge =====

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

:'''Authors:''' Perrygeo

=== Raster add-ons ===

See also

svn co <nowiki>https://svn.osgeo.org/grass/grass-addons/raster</nowiki>

==== r.bilateral ====

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

: '''Author:''' Jachym Cepicky

==== r.boxcount ====

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

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

Available via SVN:

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

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

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

: '''Authors:''' Mathieu Grelier

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

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

==== r.cpt2grass ====

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

: '''Author:''' Hamish Bowman

==== r.csr ====

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

: '''Author:''' Eric Patton

==== r.cva ====

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

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

==== r.denoise ====

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

: '''Author:''' John Stevenson

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

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

: '''Author:''' Hamish Bowman

==== r.eucdist ====

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

: '''Author:''' David Finlayson

==== r.fragment ====

: [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/r.fragment.tar.bz2 r.fragment] fragments a raster into a user-defined set of smaller tiles according to an input number of rows and columns.
: '''Author:''' Eric Patton

==== r.game_of_life ====

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

: '''Author:''' Hamish Bowman

==== r.gauss ====

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

:'''Author:''' Jachym Cepicky

==== r.gradgrid4 ====

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

: '''Author:''' Martin Mergili

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

: [http://www-pool.math.tu-berlin.de/~soeren/grass/modules/ r.in.onearth] for download and import satellite images direct from the NASA onearth WMS server into GRASS.

: '''Author:''' Soeren Gebbert

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

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

: '''Author:''' Jachym Cepicky

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

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

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

==== r.isoregions ====

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

: '''Authors:''' Mathieu Grelier

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

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

: '''Author:''' David Finlayson

==== r.li ====

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

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

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

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

: '''Author:''' Jachym Cepicky

==== r.mandelbrot ====

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

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

==== mcda====

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

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

Available via SVN:

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

==== r.mlv ====

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

: '''Author:''' Jachym Cepicky

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

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

: '''Author:''' Giovanni Allegri

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

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

: '''Author:''' Tomas Cebecauer

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

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

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

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

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

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

==== r.pack ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.pack r.pack and r.unpack] are two GRASS scripts for transfering raster maps to another computer as a single file.

: '''Author:''' Hamish Bowman

==== r.roughness ====

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

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

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

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

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

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

Available via SVN:

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

==== r.roughset ====

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

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

Available via SVN:

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

==== r.smoothpatch ====

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

: '''Author:''' David Finlayson

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

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

:'''Author:''' Gianluca Massei

Available via SVN:

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

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

: [http://www.sieczka.org/programy_en.html r.surf.nnbathy] interpolates a surface from a raster input using Pavel Sakov's [http://www.sieczka.org/prog/grass/nn-v.1.80.tar.gz nn] natural neighbor interpolation library. Provides triangulation, Sibson natural neighbor interpolation and non-Sibsonian interpolation.
: See the [http://code.google.com/p/nn-c/ NN project page] at Google Code.


: '''Author:''' Maciej Sieczka

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

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

: '''Author:''' Hamish Bowman

==== r.terracost ====

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

Available via SVN:
svn co https://svn.osgeo.org/grass/grass-addons/raster/r.terracost

==== r.tileset ====

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

==== r.traveltime ====

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

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

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

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

: '''Author:''' Markus Metz

Available via SVN:

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

==== r.viewshed ====

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

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

Available via SVN:

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

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

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

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

: '''Author:''' Jachym Cepicky

==== GIPE ====

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==== HydroFOSS ====

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

: '''Author:''' Massimiliano Cannata

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

==== Hikereport ====

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

: '''Author:''' Stefano Negri

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

=== Misc add-ons===

==== m.eigensystem ====

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

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

: '''Author:''' Michael Shapiro

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

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

: '''Author:''' Markus Neteler. Available via SVN:

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

===General add-ons===

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

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

: '''Author:''' Otto Dassau

==== Readline completion ====

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

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

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

: [http://trac.osgeo.org/grass/browser/grass-addons/general/g.region.point g.region.point] is a shell script which resets the computational region to a square box around a given coordinate. It is intended for use within GRASS scripts to speed up processing by limiting expensive raster calculations to a small area of interest.

: '''Author:''' Hamish Bowman

==== g.linke_by_day ====

: [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.sun.tools/ g.linke_by_day] is a python script for [[r.sun]] which interpolates a Linke turbidity value for a given day of the year based on monthly values edited into the script.

: '''Author:''' Hamish Bowman

==== g.xlist ====

: [http://trac.osgeo.org/grass/browser/grass-addons/general/g.xlist g.xlist] is a C implementation of g.mlist. g.xlist searches for data files matching a pattern given by wildcards or POSIX Extended Regular Expressions. POSIX regex(3) functions are required.

: '''Author:''' Huidae Cho

==== g.xremove ====

: [http://trac.osgeo.org/grass/browser/grass-addons/general/g.xremove g.xremove] is a C implementation of g.mremove. g.xremove removes data files matching a pattern given by wildcards or POSIX Extended Regular Expressions. POSIX regex(3) functions are required.

: '''Author:''' Huidae Cho

=== Imagery add-ons ===

See also

svn co https://svn.osgeo.org/grass/grass-addons/imagery

==== GIPE ====

GIPE (see also above in raster section) provides:
i.biomass, i.dn2potrad.l5, i.dn2potrad.l7, i.dn2ref.ast, i.eb.deltat, i.eb.disp, i.eb.eta, i.eb.evapfr, i.eb.g0, i.eb.h0, i.eb.h_SEBAL01, i.eb.h_SEBAL95, i.eb.h_iter, i.eb.molength, i.eb.netrad, i.eb.psi, i.eb.rah, i.eb.rohair, i.eb.ublend, i.eb.ustar, i.eb.wetdrypix, i.eb.z0m, i.eb.z0m0, i.evapo.PT, i.evapo.TSA, i.evapo.potrad, i.evapo.senay, i.evapo.time_integration, i.lmf, i.modis.stateqa, i.sattime, i.vi.grid, i.vi.mpi, i.water, i.wi

svn co https://svn.osgeo.org/grass/grass-addons/gipe/

: '''Author:''' Yann Chemin

==== i.landsat.toar ====

Transform calibrated digital number of Landsat products to top-of-atmosphere radiance or top-of-atmosphere reflectance and temperature (band 6 of the sensors TM and ETM+). Optionally, used to calculate the at-surface radiance or reflectance with atmospheric correction (DOS method).

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.landsat.toar

: '''Author:''' E. Jorge Tizado

==== i.points.reproj ====

: [http://trac.osgeo.org/grass/browser/grass-addons/imagery/i.points.reproj i.points.reproj] is a shell script that will use cs2cs to reproject the target coordinates of a group's POINTS file. By running i.rectify directly to the new target projection, a generation of resampling data loss can be avoided (versus i.rectify + r.proj). On the other hand, i.rectify does not calculate cell resolution well if the map is to be rotated ([http://intevation.de/rt/webrt?serial_num=3296 bug #3296]), in those cases i.rectify+r.proj may be the better option.

: '''Author:''' Hamish Bowman

==== i.pr ====

: Image classification: implements k-NN (multiclass), classification trees (multiclass), maximum likelihood (multiclass), Support Vector Machines (binary), bagging versions of all the base classifiers, AdaBoost for binary trees and support vector machines. It allows feature manipulation (normalization, principal components,...). It also implements feature selection techniques (RFE, E-RFE,...), statistical tests on variables, tools for resampling (cross-validation and bootstrap) and cost-sensitive techniques for trees and support vector machines.

: '''Author:''' Stefano Merler. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.pr

==== i.spec.sam ====

: Spectral Angle mapping

: '''Author:''' Markus Neteler. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.spec.sam/

==== i.spec.unmix ====

: Spectral unmixing

: '''Author:''' Markus Neteler. Available via SVN:

svn co https://svn.osgeo.org/grass/grass-addons/imagery/i.spec.unmix/

==== i.warp ====

: [http://trac.osgeo.org/grass/browser/grass-addons/imagery/i.warp i.warp] is a shell script that will use gdalwarp to rectify a raw input image using thin plate splines. The map should be imported into GRASS with r.in.gdal and GCPs set with i.points. Input is the raw image (GeoTIFF, JPEG, etc). Output is a GeoTIFF in the imagery group's target location's map projection. Requires a recent (early 2006) version of GRASS 6.1, or newer.

: '''Author:''' Hamish Bowman

=== Display add-ons ===

See also

svn co https://svn.osgeo.org/grass/grass-addons/display

==== d.edit.rast ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.edit.rast d.edit.rast] edits cells in an existing raster map displayed on the current monitor.

: '''Author:''' Huidae Cho

==== d.frame.quarter ====

: ('''obsolete''') [http://trac.osgeo.org/grass/browser/grass-addons/display/d.frame.split d.frame.quarter] is a shell script that will split the display into four quadrants (or sixths) using ''d.frame''. Individual frames are named ''uno, dos, tres, cuatro'', and ''full_screen''.
: Replaced by {{cmd|d.split.frame}} in main.

: '''Author:''' Hamish Bowman

==== d.frame.split ====

: ''d.frame.split moved into main archive as {{cmd|d.split.frame}}''

==== d.hyperlink ====

: [ftp://gsca.nrcan.gc.ca/outgoing/Patton/Grass/Scripts/d.hyperlink.tar.bz2 d.hyperlink] is an interactive shell script that allows the viewing of hyperlinked images from a vector's attribute table in an external image viewer. Queries can be made via SQL statements or interactive mouse-clicking. The attribute table must be pre-populated with a column containing the image to link the vector to; the user also specifies the image folder in the current MAPSET where the images are located. The script currently supports gimp, Eye of Gnome, gthumb, gpdf, and Inkscape image viewers.

: '''Author: '''Eric Patton

==== d.mark ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.shortcuts d.mark] is a shell script that quickly displays a marker on the display at a given coordinate.

: '''Author:''' Hamish Bowman

==== d.region.box ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.region.box d.region.box] is a shell script that quickly displays a box around the current region.

: '''Author:''' Hamish Bowman

==== d.stations ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.shortcuts d.stations] is a shell script that quickly displays vector points (or sites for GRASS 5.4 and below).

: '''Author:''' Hamish Bowman

==== d.varea ====

: [http://trac.osgeo.org/grass/browser/grass-addons/display/d.shortcuts d.varea] is a shell script that quickly displays vector areas.

: '''Author:''' Hamish Bowman

==== pd-GRASS ====

: [http://www.ornl.gov/sci/gist/software/grass/ pd-GRASS]: Parallel Display for GRASS GIS

: '''Author:''' Alex Sorokine

==== [[IconSymbols]] ====

* [[IconSymbols|Symbols]] which can be used with ''d.vect, d.graph'', and ''ps.map''.

=== Postscript add-ons ===

''See also [[ps.map scripts|ps.map samples and templates]]''.

==== ps.atlas ====

: [http://les-ejk.cz/programs/grass/ps.atlas ps.atlas] is a shell script that makes more maps on current region according to input *.psmap file. General map can be stored as vector file. The resulting *.eps maps can be automatically converted to *.pdf files.

: '''Author:''' Jachym Cepicky

==== [[AreaFillPatterns]] ====

* Hatches for ps.map's vareas

===GRASS and UMN Mapserver===

* [http://www.mail-archive.com/mapserver-users@lists.umn.edu/msg00086.html See interesting posting]

[[Category:Community]]
[[Category:Development]]
[[Category:Documentation]]
[[Category:Installation]]

How to interpolate point value using kriging method with R and GRASS 6

2009-08-25T18:19:50Z

⚠️AnneGhisla: typo, will upgrade the section below asap

=== ORDINARY KRIGING IN R WITH GRASS6 DATA ===

-- New development mid-2009:
* GRASS's [[Kriging]] wiki page
* [[v.krige_GSoC_2009]] wxGUI Kriging project by Anne Ghisla
** Anne's {{addonCmd|v.krige}} module
* {{addonCmd|v.autokrige}} module by Mathieu Grelier
--

('''WARNING!!''' Most of the code quoted here is very out of date, and simply does not work for current R/sp/gstat/spgrass6. Untried suggestions have been edited in, but without a test location, there is no guarantee that they will work! Roger Bivand, 5 April 2007)

Of all the methods we tried this is the most easy and (I suppose) exact too:

You have to have in your library the packages "gstat" and "spgrass6", you can download this last one directly from R using the command "install.packages".
In GRASS we have a vector file named "giaciture_cat_clean3" and we want to do a prediction on this data...
these are the commmands:

enter R from the GRASS prompt, and type:

<pre>
library(spgrass6)

#get vector points as SpatialPointsDataFrame
#giaciture <- getSites6sp("giaciture_cat_clean3") RSB 070405

giaciture <- readVECT6("giaciture_cat_clean3") # RSB 070405

class(giaciture) #shows the class of "giaciture" (SpatialPointsDataFrame)

# G <- gmeta6() #get region from GRASS to R RSB 070405
</pre>

now if you want you can continue to work in R from GRASS or not...

<pre>
#create a grid from the region settings of GRASS, it is very important
# to have square cells, so you can set the region settings of GRASS or
# you can give directly square dimensions using the values:
# e.g."cells.dim=c(50,50)"
#grd <- GridTopology(cellcentre.offset=c(G$west+(G$ewres/2)
# ,G$south+(G$nsres/2))
# ,cellsize=c(G$ewres, G$nsres)
# ,cells.dim=c(G$cols, G$rows)) RSB 070405

grd <- gmeta2grd() # RSB 070405

#create a SpatialGridDataFrame
mask_SG <- SpatialGridDataFrame(grd,
# ,data=list(k=rep(1, G$cols*G$rows)) RSB 070405
data=data.frame(k=rep(1, prod(slot(grd, "cells.dim")))), # RSB 070405
proj4string=CRS(proj4string(giaciture))) # RSB 070405
# proj4string(giaciture) and proj4string(mask_SG) must agree
class(mask_SG)

library(gstat)

cvgm <- variogram(IMMERSIONE~1, data=giaciture, width=400, cutoff=4000) # RSB 070405
#create variogram, and "IMMERSIONE"
#here is the our variable, the variable on wich we have to do the prediction,
# ~ 1 select the type of kriging, this is the ordinary one

efitted <- fit.variogram(cvgm, vgm(psill=5000, model="Exp", range=1500, nugget=8000))
# choose the model to fit variogram (here is exponential) and give the
# estimated parameters of the variogram (partial sill, range and nugget)

OK_pred <- krige(IMMERSIONE~1, data=giaciture, newdata=mask_SG, model=efitted) # RSB 070405
# make the kriging prediction

names(OK_pred) #show the name of variable kriged

writeRAST6(OK_pred, "OK_pred", zcol="var1.pred") # RSB 070405
#write a raster file and save it in GRASS, now you can open it from there.
</pre>

that's all!

special thanks to Roger Bivand, ever ready to lend a hand!

=== More Help ===

* A [http://casoilresource.lawr.ucdavis.edu/drupal/node/438 nice working example] for recent versions of R/sp/gstat/spgrass6.
* [[Kriging]]

[[Category:Documentation]]

File:Schermata-Kriging Module.png

2009-08-25T07:18:44Z

⚠️AnneGhisla: uploaded a new version of "File:Schermata-Kriging Module.png": with variogram plot - wOOt!

draft interface for v.autokrige2.py addon

Kriging

2009-08-15T19:24:35Z

⚠️AnneGhisla: /* Kriging collection */ updated link, even if redirection pointed to the right page.

GRASS and kriging

== Kriging collection ==

* [[How to interpolate point value using kriging method with R and GRASS 6]]
* [[V.krige GSoC 2009]]
* [http://www.gstat.org gstat] - gstat is a powerful tool for geostatistical analysis including various kriging techniques (and offers direct support for GRASS vector points)
* [http://cran.at.r-project.org/web/views/Spatial.html Analysis of Spatial Data in R] - The R Project for Statistical Computing is a rich statistical framework with numerous geospatial extentions including kriging and a gstat extention (and offers direct support for GRASS data via the "[http://grass.osgeo.org/statsgrass/grass6_r_install.html spgrass6]" class)

== See also ==

* Bezzi M. & Vitti A., 2005: A comparison of some kriging interpolation methods for the production of solar radiation maps. [http://geomatica.como.polimi.it/workbooks/n5/list.php Geomatics workbooks 5] ([http://geomatica.como.polimi.it/workbooks/n5/full.php PDF], requires free registration)
* Bivand, R. 2007. Using the R-GRASS interface. OSGeo Journal 1, 36-38 ([http://www.osgeo.org/files/journal/final_pdfs/OSGeo_vol1_GRASS-R.pdf PDF])

[[Category:Documentation]]

V.krige GSoC 2009

2009-08-15T19:22:24Z

⚠️AnneGhisla: removed reports from TOC - added a todo

=== v.krige: Python porting and wxPython GUI addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by Martin Landa and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

'''Interactive variogram fit is available! (r38714 or higher)''' In gstat tab, the button labeled "Plot/refresh variogram" calls up a R graphics window with the data variogram and the fitted curve. Play with options to obtain the best fit, refresh plot, and when the model fits the data, run kriging!

[[File:Schermata-Kriging Module.png|450px|left]]

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

To install v.krige.py, please refer to [[Compile_and_Install#Scripts]]. It is easier to install it via [http://grass.osgeo.org/grass65/manuals/html65_user/g.extension.html g.extension] (for GRASS 6.4 it is an AddOn, from 6.5+/7 onwards included). Simply type in a GRASS shell:

g.extension v.krige

'''The module requires GRASS >= 6.4 RC5''' - it uses the new version of grass-python library. At the moment, no backward compatibility with previous versions is provided.

The module has dependencies:
* R 2.x - no exhaustive tests on compatible versions. An up-to-date R package will do the job in 99% cases.
* R packages spgrass6 and gstat
* Python module rpy2

Be sure that ALL these dependencies are installed and operative. See below for platform-specific details.

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)

either the brand new Debian packages [6], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6

=== Notes for Windows ===
At this very moment, no backward compatibility with OSGeo4W's packaged GRASS 6.4svn2 is provided, nor with WinGRASS.

If you really need to run v.krige right now on Windows, I suggest to compile GRASS following [http://trac.osgeo.org/grass/wiki/CompileOnWindows this guide].
You could also use Linux in a virtual machine. Or install Linux in a separate partition of the HD. This is not as painful as it appears, there are lots of guides over the Internet to help you.

== Bulletin Board ==

* '''TODOs'''
** [permanent todo] Cleanup code! Refactoring brings refactoring.
** wxGUI: Split widget creation and layout - makes more readable code
** Solve '''double parsing issue from RunCmd.''' This leads to unnecessary double dependency check.
** Continue integrating '''gstat functions''' - universal kriging first.
** Add '''region resolution parameter in interface''', showing the current value and allowing the user to modify it before kriging. High resolution slows down computation and give better results, but the user should have a clear feedback (I have been surprised by long runs more than once, because I was not aware of resolution).

* '''IDEAS TO DISCUSS'''
** '''Splash screen at module load''' will be implemented, but activated only if maps are more than a threshold number [Markus Neteler's suggestion]
** Create a '''package''' to delegate dependencies check? (Stefan Krüger's suggestion)

* '''BLOCKING ISSUE(S)'''
** No more!!

* '''BROKEN WINDOWS (from Martin Fowler's great book [0]) '''
** Imperfect logging - relies on RunCmd...
** The RBookPage::refresh() function has an endless cycle that keeps R graphics window responsive, even when that window has been closed by the user.
** spgrass6::readVECT6() and mapset name - see [http://lists.osgeo.org/pipermail/grass-stats/2009-August/001126.html this thread].

* '''FUTURE PLANS'''
** Keep on working on v.krige after SoC, in particular integrate it into GRASS trunk - not before November nor before some more reliability improvements.

== Documentation ==

Notes on v.krige usage, examples and tips are available in the module's help page, available via Help button if the GUI.

Kriging theory is available in Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [1]. Another great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [2] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft and definitive:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [3].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [4] ==

'''Report #1, 29 May'''

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [1], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [5]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

'''Report #2, 5 June'''

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

'''Report #2.5, 11 June'''

First of all, the interface is almost finished..
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

'''Report #3, 12 June'''

this weekly report will be very short, as yesterday I sent this email (Report 2.5, see above) and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK because of projection information handling.

'''Report #4, 19 June'''

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check and data load, and examine how to integrate gstat functions.

'''Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event])'''

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

'''Report #6, 3 July'''

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

'''Report #7, midterm, 10 July'''

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

'''Report #8, 17 July'''

this week I added Command output tab and the option for block kriging, and updated documentation with more precise information on dependencies.
I'll add splashscreen only as dependency check and command output will be fixed: next week I plan to work on these latter issues.

Nothing in particular is blocking progress, just some hardest stone sometimes.

'''Report #9, 24 July'''

this week I didn't work on the project because I attended last university course (botanical survey at Stelvio pass) and came back yesterday night.

Next week I plan to solve g.parser issue about double dependency check and the issue about sill, nugget and value parameters, that are optional
for R. A general cleanup of the code is also welcome...

No blocking issues atm.

'''Report #10, 31 July'''

good news from v.krige:
* fixed optional parameters also in interface - activated by a checkbox, otherwise R's NA value is correctly set
* interactive variogram fit is on its way - stay tuned!

Next week I plan to set up interactive variogram using matplotlib functions and get the stabler code possible for feature freeze.

'''Report #11, 7 August'''

this week I worked on error handling by GUI, adding controls on input data and parameters and hiding Run and Plot buttons unless all options are suitable.
Variogram plotting is on its way - I discarded matplotlib to avoid further dependencies, in favour of wx.lib.plot.

'''Report #12, 14 August'''

this is last SoC report - bringing variogram plotting into v.krige! After a long time searching for the lightest and cleanest implementation, R plotting raised as the best solution. On user demand, a R graphics window plots variogram and refreshes it, without interfering with wxGUI.
Documentation includes a full example using Spearfish dataset and all informations about dependencies.

Many thanks to all who have helped me writing v.krige: GRASS and R developers, OSGeo SoC crew, wise friends, all testers.
I hope this module will attract people towards GRASS and R, and provide a valid alternative to closed-source kriging tools.

== References ==
* [0] Fowler, Beck, Brant, Opdyke, Roberts, 1999. "Refactoring. Improving the design of existing code" (ISBN-10: 0201485672; ISBN-13: 978-0201485677)
* [1] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics" (ISBN 0-19-505013-4)
* [2] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [3] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [4] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [5] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [6] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]

V.krige GSoC 2009

2009-08-15T10:13:22Z

⚠️AnneGhisla: final update - plans for future develpment

=== v.krige: Python porting and wxPython GUI addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by Martin Landa and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

'''Interactive variogram fit is available! (r38714 or higher)''' In gstat tab, the button labeled "Plot/refresh variogram" calls up a R graphics window with the data variogram and the fitted curve. Play with options to obtain the best fit, refresh plot, and when the model fits the data, run kriging!

[[File:Schermata-Kriging Module.png|450px|left]]

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

To install v.krige.py, please refer to [[Compile_and_Install#Scripts]]. It is easier to install it via [http://grass.osgeo.org/grass65/manuals/html65_user/g.extension.html g.extension] (for GRASS 6.4 it is an AddOn, from 6.5+/7 onwards included). Simply type in a GRASS shell:

g.extension v.krige

'''The module requires GRASS >= 6.4 RC5''' - it uses the new version of grass-python library. At the moment, no backward compatibility with previous versions is provided.

The module has dependencies:
* R 2.x - no exhaustive tests on compatible versions. An up-to-date R package will do the job in 99% cases.
* R packages spgrass6 and gstat
* Python module rpy2

Be sure that ALL these dependencies are installed and operative. See below for platform-specific details.

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)

either the brand new Debian packages [6], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6

=== Notes for Windows ===
At this very moment, no backward compatibility with OSGeo4W's packaged GRASS 6.4svn2 is provided, nor with WinGRASS.

If you really need to run v.krige right now on Windows, I suggest to compile GRASS following [http://trac.osgeo.org/grass/wiki/CompileOnWindows this guide].
You could also use Linux in a virtual machine. Or install Linux in a separate partition of the HD. This is not as painful as it appears, there are lots of guides over the Internet to help you.

== Bulletin Board ==

* '''TODOs'''
** [permanent todo] Cleanup code! Refactoring brings refactoring.
** Split widget creation and layout - makes more readable code
** Check '''dependencies''' all before interface load. If something is missing, a popup window will give a clear message.
** Solve '''double parsing issue!!''' This leads to unnecessary double dependency check.
** Continue integrating '''gstat functions''' - universal kriging first.

* '''IDEAS TO DISCUSS'''
** '''Splash screen at module load''' will be implemented, but activated only if maps are more than a threshold number [Markus Neteler's suggestion]
** Create a '''package''' to delegate dependencies check? (Stefan Krüger's suggestion)

* '''BLOCKING ISSUE(S)'''
** No more!!

* '''BROKEN WINDOWS (from Martin Fowler's great book [0]) '''
** Imperfect logging - relies on RunCmd...
** The RBookPage::refresh() function has an endless cycle that keeps R graphics window responsive, even when that window has been closed by the user.
** spgrass6::readVECT6() and mapset name - see [http://lists.osgeo.org/pipermail/grass-stats/2009-August/001126.html this thread].

* '''FUTURE PLANS'''
** Keep on working on v.krige after SoC, in particular integrate it into trunk - not before November nor before some more reliability improvements.

== Documentation ==

Kriging theory from Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [1]. Another great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [2] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft and definitive:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [3].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [4] ==

=== Report #1, 29 May ===

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [1], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [5]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

=== Report #2, 5 June ===

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

=== Report #2.5, 11 June ===

First of all, the interface is almost finished..
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

=== Report #3, 12 June ===

this weekly report will be very short, as yesterday I sent this email and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK because of projection information handling.

=== Report #4, 19 June ===

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check
and data load, and examine how to integrate gstat functions.

=== Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event]) ===

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

=== Report #6, 3 July ===

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

=== Report #7, midterm, 10 July ===

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

=== Report #8, 17 July ===

this week I added Command output tab and the option for block kriging, and updated documentation with more precise information on dependencies.
I'll add splashscreen only as dependency check and command output will be fixed: next week I plan to work on these latter issues.

Nothing in particular is blocking progress, just some hardest stone sometimes.

=== Report #9, 24 July ===

this week I didn't work on the project because I attended last university course (botanical survey at Stelvio pass) and came back yesterday night.

Next week I plan to solve g.parser issue about double dependency check and the issue about sill, nugget and value parameters, that are optional
for R. A general cleanup of the code is also welcome...

No blocking issues atm.

=== Report #10, 31 July ===

good news from v.krige:
* fixed optional parameters also in interface - activated by a checkbox, otherwise R's NA value is correctly set
* interactive variogram fit is on its way - stay tuned!

Next week I plan to set up interactive variogram using matplotlib functions and get the stabler code possible for feature freeze.

=== Report #11, 7 August ===

this week I worked on error handling by GUI, adding controls on input data and parameters and hiding Run and Plot buttons unless all options are suitable.
Variogram plotting is on its way - I discarded matplotlib to avoid further dependencies, in favour of wx.lib.plot.

=== Report #12, 14 August ===

this is last SoC report - bringing variogram plotting into v.krige! After a long time searching for the lightest and cleanest implementation, R plotting raised as the best solution. On user demand, a R graphics window plots variogram and refreshes it, without interfering with wxGUI.
Documentation includes a full example using Spearfish dataset and all informations about dependencies.

Many thanks to all who have helped me writing v.krige: GRASS and R developers, OSGeo SoC crew, wise friends, all testers.
I hope this module will attract people towards GRASS and R, and provide a valid alternative to closed-source kriging tools.

== References ==
* [0] Fowler, Beck, Brant, Opdyke, Roberts, 1999. "Refactoring. Improving the design of existing code" (ISBN-10: 0201485672; ISBN-13: 978-0201485677)
* [1] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics" (ISBN 0-19-505013-4)
* [2] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [3] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [4] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [5] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [6] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]

V.krige GSoC 2009

2009-08-14T13:32:22Z

⚠️AnneGhisla: endo of summer of code!

=== v.krige: Python porting and wxPython GUI addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by Martin Landa and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

'''Interactive variogram fit is available! (r38714 or higher)''' In gstat tab, a button labeled "Plot/refresh variogram" calls up a R graphics window with the data variogram and the fitted curve. Play with options to obtain the best fit, and then run kriging!

Pick v.krige with g.extension, just writing in a grass shell:

g.extension v.krige

[[File:Schermata-Kriging Module.png|450px|left]]

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

To install v.krige.py, please refer to [[Compile_and_Install#Scripts]]. It is easier to install it via g.extension, available too as an AddOn.

'''The module requires GRASS >= 6.4 RC5''' - it uses the new version of grass-python library. At the moment, no backward compatibility with previous versions is provided.

The module has dependencies:
* R 2.x - no exhaustive tests on compatible versions. An up-to-date R package will do the job in 99% cases.
* R packages spgrass6 and gstat
* Python module rpy2

Be sure that ALL these dependencies are installed and operative. See below for platform-specific details.

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)

either the brand new Debian packages [6], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6

=== Notes for Windows ===
At this very moment, no backward compatibility with OSGeo4W's packaged GRASS 6.4svn2 is provided, nor with WinGRASS.

If you really need to run v.krige right now on Windows, I suggest to compile GRASS following [http://trac.osgeo.org/grass/wiki/CompileOnWindows this guide].
You could also use Linux in a virtual machine. Or install Linux in a separate partition of the HD. This is not as painful as it appears, there are lots of guides over the Internet to help you.

== Bulletin Board ==

* '''TODOs'''
** [permanent todo] Cleanup code! Refactoring brings refactoring.
** Check '''dependencies''' all before interface load. If something is missing, a popup window will give a clear message.
** Solve '''double parsing issue!!''' This leads to unnecessary double dependency check.
** Continue integrating '''gstat functions'''

* '''IDEAS TO DISCUSS'''
** '''Splash screen at module load''' will be implemented, but activated only if maps are more than a threshold number [Markus Neteler's suggestion]
** Create a '''package''' to delegate dependencies check? (Stefan Krüger's suggestion)

* '''BLOCKING ISSUE(S)'''
** No more!!

* '''BROKEN WINDOWS (from Martin Fowler's great book [0]) '''
** Imperfect logging - relies on RunCmd...

== Documentation ==

Kriging theory from Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [1]. Another great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [2] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft and definitive:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [3].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [4] ==

=== Report #1, 29 May ===

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [1], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [5]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

=== Report #2, 5 June ===

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

=== Report #2.5, 11 June ===

First of all, the interface is almost finished..
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

=== Report #3, 12 June ===

this weekly report will be very short, as yesterday I sent this email and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK because of projection information handling.

=== Report #4, 19 June ===

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check
and data load, and examine how to integrate gstat functions.

=== Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event]) ===

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

=== Report #6, 3 July ===

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

=== Report #7, midterm, 10 July ===

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

=== Report #8, 17 July ===

this week I added Command output tab and the option for block kriging, and updated documentation with more precise information on dependencies.
I'll add splashscreen only as dependency check and command output will be fixed: next week I plan to work on these latter issues.

Nothing in particular is blocking progress, just some hardest stone sometimes.

=== Report #9, 24 July ===

this week I didn't work on the project because I attended last university course (botanical survey at Stelvio pass) and came back yesterday night.

Next week I plan to solve g.parser issue about double dependency check and the issue about sill, nugget and value parameters, that are optional
for R. A general cleanup of the code is also welcome...

No blocking issues atm.

=== Report #10, 31 July ===

good news from v.krige:
* fixed optional parameters also in interface - activated by a checkbox, otherwise R's NA value is correctly set
* interactive variogram fit is on its way - stay tuned!

Next week I plan to set up interactive variogram using matplotlib functions and get the stabler code possible for feature freeze.

=== Report #11, 7 August ===

this week I worked on error handling by GUI, adding controls on input data and parameters and hiding Run and Plot buttons unless all options are suitable.
Variogram plotting is on its way - I discarded matplotlib to avoid further dependencies, in favour of wx.lib.plot.

=== Report #12, 14 August ===

this is last SoC report - bringing variogram plotting into v.krige! After a long time searching for the lightest and cleanest implementation, R plotting raised as the best solution. On user demand, a R graphics window plots variogram and refreshes it, without interfering with wxGUI.
Documentation includes a full example using Spearfish dataset and all informations about dependencies.

Many thanks to all who have helped me writing v.krige: GRASS and R developers, OSGeo SoC crew, wise friends, all testers.
I hope this module will attract people towards GRASS and R, and provide a valid alternative to closed-source kriging tools.

== References ==
* [0] Fowler, Beck, Brant, Opdyke, Roberts, 1999. "Refactoring. Improving the design of existing code" (ISBN-10: 0201485672; ISBN-13: 978-0201485677)
* [1] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics" (ISBN 0-19-505013-4)
* [2] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [3] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [4] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [5] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [6] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]

File:Schermata-Kriging Module.png

2009-08-11T13:36:35Z

⚠️AnneGhisla: uploaded a new version of "File:Schermata-Kriging Module.png": added help button, variance raster output, handling of gui

draft interface for v.autokrige2.py addon

V.krige GSoC 2009

2009-08-11T13:25:49Z

⚠️AnneGhisla: updates - see svn log!

=== v.krige: Python porting and wxPython GUI addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by Martin Landa and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

'''Ordinary and block kriging are available both from GUI and CLI!'''

Part of the options are available for gstat, anyway is it a great goal to see that the whole process ends in writing a GRASS raster map with the result. Note also that the module suggests a filename based on the input data map name. One step further towards the One-Click Interface.

Have a look at it from svn:

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.krige v.krige

[[File:Schermata-Kriging Module.png|450px|left]]

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

To install v.krige.py, please refer to [[Compile_and_Install#Scripts]]. It is easier to install it via g.extension, available too as an AddOn.

'''The module requires GRASS >= 6.4 RC5''' - it uses the new version of grass-python library. At the moment, no backward compatibility with previous versions is provided.

The module has dependencies:
* R 2.x - no exhaustive tests on compatible versions. An up-to-date R package will do the job in 99% cases.
* R packages spgrass6 and gstat
* Python module rpy2

Be sure that ALL these dependencies are installed and operative. See below for platform-specific details.

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)

either the brand new Debian packages [6], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6

=== Notes for Windows ===
At this very moment, no backward compatibility with OSGeo4W's packaged GRASS 6.4svn2 is provided, nor with WinGRASS.

If you really need to run v.krige right now on Windows, I suggest to compile GRASS following [http://trac.osgeo.org/grass/wiki/CompileOnWindows this guide].
You could also use Linux in a virtual machine. Or install Linux in a separate partition of the HD. This is not as painful as it appears, there are lots of guides over the Internet to help you.

== Bulletin Board ==

* '''TODOs'''
** [permanent todo] Cleanup code! Refactoring brings refactoring.
** Check '''dependencies''' all before interface load. If something is missing, a popup window will give a clear message.
** Solve '''double parsing issue!!''' This leads to unnecessary double dependency check.
** Continue integrating '''gstat functions'''
** '''Variogram fit''': in a separated window, with allowed interactive model fit, using Python plot libraries zB mapplotlib.

* '''IDEAS TO DISCUSS'''
** '''Splash screen at module load''' will be implemented, but activated only if maps are more than a threshold number [Markus Neteler's suggestion]
** Create a '''package''' to delegate dependencies check? (Stefan Krüger's suggestion)

* '''BLOCKING ISSUE(S)'''
** Plotting is taking more time than I imagined.

* '''BROKEN WINDOWS (from Martin Fowler's great book [0]) '''
** Imperfect logging - relies on RunCmd...

== Documentation ==

Kriging theory from Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [1]. Another great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [2] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [3].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [4] ==

=== Report #1, 29 May ===

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [1], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [5]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

=== Report #2, 5 June ===

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

=== Report #2.5, 11 June ===

First of all, the interface is almost finished..
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

=== Report #3, 12 June ===

this weekly report will be very short, as yesterday I sent this email and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK because of projection information handling.

=== Report #4, 19 June ===

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check
and data load, and examine how to integrate gstat functions.

=== Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event]) ===

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

=== Report #6, 3 July ===

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

=== Report #7, midterm, 10 July ===

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

=== Report #8, 17 July ===

this week I added Command output tab and the option for block kriging, and updated documentation with more precise information on dependencies.
I'll add splashscreen only as dependency check and command output will be fixed: next week I plan to work on these latter issues.

Nothing in particular is blocking progress, just some hardest stone sometimes.

=== Report #9, 24 July ===

this week I didn't work on the project because I attended last university course (botanical survey at Stelvio pass) and came back yesterday night.

Next week I plan to solve g.parser issue about double dependency check and the issue about sill, nugget and value parameters, that are optional
for R. A general cleanup of the code is also welcome...

No blocking issues atm.

=== Report #10, 31 July ===

good news from v.krige:
* fixed optional parameters also in interface - activated by a checkbox, otherwise R's NA value is correctly set
* interactive variogram fit is on its way - stay tuned!

Next week I plan to set up interactive variogram using matplotlib functions and get the stabler code possible for feature freeze.

== References ==
* [0] Fowler, Beck, Brant, Opdyke, Roberts, 1999. "Refactoring. Improving the design of existing code" (ISBN-10: 0201485672; ISBN-13: 978-0201485677)
* [1] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics" (ISBN 0-19-505013-4)
* [2] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [3] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [4] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [5] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [6] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]

V.krige GSoC 2009

2009-07-31T15:43:54Z

⚠️AnneGhisla: added report #10

=== v.krige: Python porting and wxPython GUI addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by Martin Landa and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

''' Breaking news: Ordinary and block kriging are available both from GUI and CLI!'''

Part of the options are available for gstat, anyway is it a great goal to see that the whole process ends in writing a GRASS raster map with the result. Note also that the module suggests a filename based on the input data map name. One step further towards the One-Click Interface.

Have a look at it from svn:

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.krige v.krige

[[File:Schermata-Kriging Module.png|450px|left]]

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

To install v.krige.py, please refer to [[Compile_and_Install#Scripts]].

'''The module requires GRASS >= 6.4 RC5''' - it uses the new version of grass-python library. At the moment, no backward compatibility with previous versions is provided.

The module has dependencies:
* R 2.x - no exhaustive tests on compatible versions. An up-to-date R package will do the job in 99% cases.
* R packages spgrass6 and gstat
* Python module rpy2

Be sure that ALL these dependencies are installed and operative. See below for platform-specific details.

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)

either the brand new Debian packages [6], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6

=== Notes for Windows ===
At this very moment, no backward compatibility with OSGeo4W's packaged GRASS 6.4svn2 is provided, nor with WinGRASS.

If you really need to run v.krige right now on Windows, I suggest to compile GRASS following [http://trac.osgeo.org/grass/wiki/CompileOnWindows this guide].
You could also use Linux in a virtual machine. Or install Linux in a separate partition of the HD. This is not as painful as it appears, there are lots of guides over the Internet to help you.

== Bulletin Board ==

* '''TODOs'''
** [permanent todo] Cleanup code! Refactoring brings refactoring.
** Check '''dependencies''' all before interface load. If something is missing, a popup window will give a clear message.
** Solve '''double parsing issue!!''' This leads to unnecessary double dependency check.
** Continue integrating '''gstat functions'''
** '''Variogram fit''': in a separated window, with allowed interactive model fit, using Python plot libraries zB mapplotlib.

* '''IDEAS TO DISCUSS'''
** '''Splash screen at module load''' - does not seem necessary. Time to load is not huge.
** Create a '''package''' to delegate dependencies check? (Stefan Krüger's suggestion)

* '''BLOCKING ISSUE(S)'''
** None ATM.

* '''BROKEN WINDOWS (from Martin Fowler's great book [0]) '''
** Imperfect logging - relies on RunCmd...

== Documentation ==

Kriging theory from Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [1]. Another great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [2] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [3].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [4] ==

=== Report #1, 29 May ===

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [1], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [5]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

=== Report #2, 5 June ===

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

=== Report #2.5, 11 June ===

First of all, the interface is almost finished..
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

=== Report #3, 12 June ===

this weekly report will be very short, as yesterday I sent this email and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK because of projection information handling.

=== Report #4, 19 June ===

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check
and data load, and examine how to integrate gstat functions.

=== Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event]) ===

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

=== Report #6, 3 July ===

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

=== Report #7, midterm, 10 July ===

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

=== Report #8, 17 July ===

this week I added Command output tab and the option for block kriging, and updated documentation with more precise information on dependencies.
I'll add splashscreen only as dependency check and command output will be fixed: next week I plan to work on these latter issues.

Nothing in particular is blocking progress, just some hardest stone sometimes.

=== Report #9, 24 July ===

this week I didn't work on the project because I attended last university course (botanical survey at Stelvio pass) and came back yesterday night.

Next week I plan to solve g.parser issue about double dependency check and the issue about sill, nugget and value parameters, that are optional
for R. A general cleanup of the code is also welcome...

No blocking issues atm.

=== Report #10, 31 July ===

good news from v.krige:
* fixed optional parameters also in interface - activated by a checkbox, otherwise R's NA value is correctly set
* interactive variogram fit is on its way - stay tuned!

Next week I plan to set up interactive variogram using matplotlib functions and get the stabler code possible for feature freeze.

== References ==
* [0] Fowler, Beck, Brant, Opdyke, Roberts, 1999. "Refactoring. Improving the design of existing code" (ISBN-10: 0201485672; ISBN-13: 978-0201485677)
* [1] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics" (ISBN 0-19-505013-4)
* [2] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [3] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [4] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [5] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [6] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]

V.krige GSoC 2009

2009-07-31T09:42:10Z

⚠️AnneGhisla:

=== v.krige: Python porting and wxPython GUI addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by Martin Landa and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

''' Breaking news: Ordinary and block kriging are available both from GUI and CLI!'''

Part of the options are available for gstat, anyway is it a great goal to see that the whole process ends in writing a GRASS raster map with the result. Note also that the module suggests a filename based on the input data map name. One step further towards the One-Click Interface.

Have a look at it from svn:

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.krige v.krige

[[File:Schermata-Kriging Module.png|450px|left]]

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

To install v.krige.py, please refer to [[Compile_and_Install#Scripts]].

'''The module requires GRASS >= 6.4 RC5''' - it uses the new version of grass-python library. At the moment, no backward compatibility with previous versions is provided.

The module has dependencies:
* R 2.x - no exhaustive tests on compatible versions. An up-to-date R package will do the job in 99% cases.
* R packages spgrass6 and gstat
* Python module rpy2

Be sure that ALL these dependencies are installed and operative. See below for platform-specific details.

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)

either the brand new Debian packages [6], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6

=== Notes for Windows ===
At this very moment, no backward compatibility with OSGeo4W's packaged GRASS 6.4svn2 is provided, nor with WinGRASS.

If you really need to run v.krige right now on Windows, I suggest to compile GRASS following [http://trac.osgeo.org/grass/wiki/CompileOnWindows this guide].
You could also use Linux in a virtual machine. Or install Linux in a separate partition of the HD. This is not as painful as it appears, there are lots of guides over the Internet to help you.

== Bulletin Board ==

* '''TODOs'''
** [permanent todo] Cleanup code! Refactoring brings refactoring.
** Check '''dependencies''' all before interface load. If something is missing, a popup window will give a clear message.
** Solve '''double parsing issue!!''' This leads to unnecessary double dependency check.
** Continue integrating '''gstat functions'''
** '''Variogram fit''': in a separated window, with allowed interactive model fit, using Python plot libraries zB mapplotlib.

* '''IDEAS TO DISCUSS'''
** '''Splash screen at module load''' - does not seem necessary. Time to load is not huge.
** Create a '''package''' to delegate dependencies check? (Stefan Krüger's suggestion)

* '''BLOCKING ISSUE(S)'''
** None ATM.

* '''BROKEN WINDOWS (from Martin Fowler's great book [0]) '''
** Imperfect logging - relies on RunCmd...

== Documentation ==

Kriging theory from Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [1]. Another great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [2] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [3].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [4] ==

=== Report #1, 29 May ===

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [1], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [5]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

=== Report #2, 5 June ===

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

=== Report #2.5, 11 June ===

First of all, the interface is almost finished..
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

=== Report #3, 12 June ===

this weekly report will be very short, as yesterday I sent this email and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK because of projection information handling.

=== Report #4, 19 June ===

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check
and data load, and examine how to integrate gstat functions.

=== Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event]) ===

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

=== Report #6, 3 July ===

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

=== Report #7, midterm, 10 July ===

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

=== Report #8, 17 July ===

this week I added Command output tab and the option for block kriging, and updated documentation with more precise information on dependencies.
I'll add splashscreen only as dependency check and command output will be fixed: next week I plan to work on these latter issues.

Nothing in particular is blocking progress, just some hardest stone sometimes.

=== Report #9, 24 July ===

this week I didn't work on the project because I attended last university course (botanical survey at Stelvio pass) and came back yesterday night.

Next week I plan to solve g.parser issue about double dependency check and the issue about sill, nugget and value parameters, that are optional
for R. A general cleanup of the code is also welcome...

No blocking issues atm.

== References ==
* [0] Fowler, Beck, Brant, Opdyke, Roberts, 1999. "Refactoring. Improving the design of existing code" (ISBN-10: 0201485672; ISBN-13: 978-0201485677)
* [1] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics" (ISBN 0-19-505013-4)
* [2] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [3] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [4] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [5] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [6] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]

V.krige GSoC 2009

2009-07-28T16:56:05Z

⚠️AnneGhisla: /* Bulletin Board */ update

=== v.krige: Python porting and wxPython GUI addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by Martin Landa and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

''' Breaking news: Ordinary and block kriging are available both from GUI and CLI!'''

Part of the options are available for gstat, anyway is it a great goal to see that the whole process ends in writing a GRASS raster map with the result. Note also that the module suggests a filename based on the input data map name. One step further towards the One-Click Interface.

Have a look at it from svn:

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.krige v.krige

[[File:Schermata-Kriging Module.png|450px|left]]

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

To install v.krige.py, please refer to [[Compile_and_Install#Scripts]].

The module has dependencies:
* R 2.x - no exhaustive tests on compatible versions. An up-to-date R package will do the job in 99% cases.
* R packages spgrass6 and gstat
* Python module rpy2

Be sure that ALL these dependencies are installed and operative. See below for platform-specific details.

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)

either the brand new Debian packages [5], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6

=== Notes for Windows ===
At this very moment, v.krige is developed against grass 6.5 (6_develbranch) and no backward compatibility with OSGeo4W's packaged GRASS 6.4svn2 is provided, nor with WinGRASS.

If you really need to run v.krige right now on Windows, I suggest to compile GRASS following [http://trac.osgeo.org/grass/wiki/CompileOnWindows this guide].
You could also use Linux in a virtual machine. Or install Linux in a separate partition of the HD. This is not as painful as it appears, there are lots of guides over the Internet to help you.

== Bulletin Board ==

* '''TODOs'''
** Cleanup code! Refactoring brings refactoring.
** Check '''dependencies''' all before interface load. If something is missing, a popup window will give a clear message.
** Solve '''double parsing issue!!''' This leads to unnecessary double dependency check.
** Continue integrating '''gstat functions'''
** '''Variogram fit''': in a separated window, with allowed interactive model fit, using Python plot libraries zB mapplotlib.

* '''IDEAS TO DISCUSS'''
** '''Splash screen at module load''' - does not seem necessary. Time to load is not huge.
** Create a '''package''' to delegate dependencies check? (Stefan Krüger's suggestion)

* '''BLOCKING ISSUE(S)'''
** None

== Documentation ==

Kriging theory from Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [0]. Great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [1] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [2].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [3] ==

=== Report #1, 29 May ===

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [0], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [4]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

=== Report #2, 5 June ===

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

=== Report #2.5, 11 June ===

First of all, the interface is almost finished. See a screenshot on the wiki page [0].
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample [1] works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

=== Report #3, 12 June ===

this weekly report will be very short, as yesterday I sent this email
[0] and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK
because of projection information handling.

=== Report #4, 19 June ===

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check
and data load, and examine how to integrate gstat functions.

=== Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event]) ===

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data, see this tutorial [0]. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

=== Report #6, 3 July ===

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

=== Report #7, midterm, 10 July ===

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

== References ==
* [0] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics", (ISBN 0-19-505013-4)
* [1] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [2] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [3] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [4] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [5] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]

File:Schermata-Kriging Module.png

2009-07-17T13:20:33Z

⚠️AnneGhisla: uploaded a new version of "File:Schermata-Kriging Module.png": block kriging widgets functional

draft interface for v.autokrige2.py addon

V.krige GSoC 2009

2009-07-17T13:19:05Z

⚠️AnneGhisla: block kriging available

=== v.krige: Python porting and wxPython GUI addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by Martin Landa and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

''' Breaking news: Ordinary and block kriging are available both from GUI and CLI!'''

Part of the options are available for gstat, anyway is it a great goal to see that the whole process ends in writing a GRASS raster map with the result. Note also that the module suggests a filename based on the input data map name. One step further towards the One-Click Interface.

Have a look at it from svn:

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.krige v.krige

[[File:Schermata-Kriging Module.png|450px|left]]

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

To install v.krige.py, please refer to [[Compile_and_Install#Scripts]].

The module has dependencies:
* R 2.x - no exhaustive tests on compatible versions. An up-to-date R package will do the job in 99% cases.
* R packages spgrass6 and gstat
* Python module rpy2

Be sure that ALL these dependencies are installed and operative. See below for platform-specific details.

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)

either the brand new Debian packages [5], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6

=== Notes for Windows ===
At this very moment, v.krige is developed against grass 6.5 (6_develbranch) and no backward compatibility with OSGeo4W's packaged GRASS 6.4svn2 is provided, nor with WinGRASS.

If you really need to run v.krige right now on Windows, I suggest to compile GRASS following [http://trac.osgeo.org/grass/wiki/CompileOnWindows this guide].
You could also use Linux in a virtual machine. Or install Linux in a separate partition of the HD. This is not as painful as it appears, there are lots of guides over the Internet to help you.

== Bulletin Board ==

* '''TODOs'''
** '''Document dependencies''' - continue fill up html template page
** Cleanup code! Refactoring brings refactoring.
** '''Splash screen at module load'''.
*** Check '''dependencies''' all before interface load. If something is missing, a popup window will give a clear message.
** Continue integrating '''gstat functions'''

* '''IDEAS TO DISCUSS'''
** Create a '''package''' to delegate dependencies check? (Stefan Krüger's suggestion)
** '''Variogram fit''': in a separated window, with allowed interactive model fit, using Python plot libraries.

* '''BLOCKING ISSUE(S)'''
** NULL

== Documentation ==

Kriging theory from Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [0]. Great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [1] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [2].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [3] ==

=== Report #1, 29 May ===

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [0], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [4]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

=== Report #2, 5 June ===

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

=== Report #2.5, 11 June ===

First of all, the interface is almost finished. See a screenshot on the wiki page [0].
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample [1] works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

=== Report #3, 12 June ===

this weekly report will be very short, as yesterday I sent this email
[0] and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK
because of projection information handling.

=== Report #4, 19 June ===

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check
and data load, and examine how to integrate gstat functions.

=== Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event]) ===

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data, see this tutorial [0]. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

=== Report #6, 3 July ===

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

=== Report #7, midterm, 10 July ===

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

== References ==
* [0] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics", (ISBN 0-19-505013-4)
* [1] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [2] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [3] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [4] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [5] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]

V.krige GSoC 2009

2009-07-16T13:02:27Z

⚠️AnneGhisla: /* Installation */ explicit dependency list

=== v.krige: Python porting and wxPython GUI addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by Martin Landa and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

''' Breaking news: Ordinary kriging is up and running both from GUI and CLI!''' not all the options are available for gstat, anyway is it a great goal to see that the whole process ends in writing a GRASS raster map with the result. Note also that the module suggests a filename based on the input data map name. One step further towards the One-Click Interface.

[[File:Schermata-Kriging Module.png|450px|left]]

Have a look at it from svn:

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.krige v.krige

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

To install v.krige.py, please refer to [[Compile_and_Install#Scripts]].

The module has dependencies:
* R 2.x - no exhaustive tests on compatible versions. An up-to-date R package will do the job in 99% cases.
* R packages spgrass6 and gstat
* Python module rpy2

Be sure that ALL these dependencies are installed and operative. See below for platform-specific details.

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)

either the brand new Debian packages [5], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6

=== Notes for Windows ===
At this very moment, v.krige is developed against grass 6.5 (6_develbranch) and no backward compatibility with OSGeo4W's packaged GRASS 6.4svn2 is provided, nor with WinGRASS.

If you really need to run v.krige right now on Windows, I suggest to compile GRASS following [http://trac.osgeo.org/grass/wiki/CompileOnWindows this guide].
You could also use Linux in a virtual machine. Or install Linux in a separate partition of the HD. This is not as painful as it appears, there are lots of guides over the Internet to help you.

== Bulletin Board ==

* '''TODOs'''
** '''Document dependencies''' - continue fill up html template page
** Cleanup code! Refactoring brings refactoring.
** '''Splash screen at module load'''.
*** Check '''dependencies''' all before interface load. If something is missing, a popup window will give a clear message.
** Continue integrating '''gstat functions'''

* '''IDEAS TO DISCUSS'''
** Create a '''package''' to delegate dependencies check!
** '''Variogram fit''': in a separated window, with allowed interactive model fit, using Python plot libraries.

* '''BLOCKING ISSUE(S)'''
** NULL

== Documentation ==

Kriging theory from Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [0]. Great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [1] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [2].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [3] ==

=== Report #1, 29 May ===

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [0], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [4]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

=== Report #2, 5 June ===

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

=== Report #2.5, 11 June ===

First of all, the interface is almost finished. See a screenshot on the wiki page [0].
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample [1] works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

=== Report #3, 12 June ===

this weekly report will be very short, as yesterday I sent this email
[0] and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK
because of projection information handling.

=== Report #4, 19 June ===

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check
and data load, and examine how to integrate gstat functions.

=== Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event]) ===

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data, see this tutorial [0]. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

=== Report #6, 3 July ===

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

=== Report #7, midterm, 10 July ===

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

== References ==
* [0] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics", (ISBN 0-19-505013-4)
* [1] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [2] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [3] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [4] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [5] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]

V.krige GSoC 2009

2009-07-15T09:16:51Z

⚠️AnneGhisla: /* Notes for Windows */ no compatibility with packages GRASS in OSGeo4W nor WinGRASS - suggestions

=== v.krige: Python porting and wxPython GUI addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by Martin Landa and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

''' Breaking news: Ordinary kriging is up and running both from GUI and CLI!''' not all the options are available for gstat, anyway is it a great goal to see that the whole process ends in writing a GRASS raster map with the result. Note also that the module suggests a filename based on the input data map name. One step further towards the One-Click Interface.

[[File:Schermata-Kriging Module.png|450px|left]]

Have a look at it from svn:

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.krige v.krige

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

Please refer to [[Compile_and_Install#Scripts]].

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)

either the brand new Debian packages [5], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6

=== Notes for Windows ===
At this very moment, v.krige is developed against grass 6.5 (6_develbranch) and no backward compatibility with OSGeo4W's packaged GRASS 6.4svn2 is provided, nor with WinGRASS.

If you really need to run v.krige right now on Windows, I suggest to compile GRASS following [http://trac.osgeo.org/grass/wiki/CompileOnWindows this guide].
You could also use Linux in a virtual machine. Or install Linux in a separate partition of the HD. This is not as painful as it appears, there are lots of guides over the Internet to help you.

== Bulletin Board ==

* '''TODOs'''
** '''Document dependencies''' - continue fill up html template page
** Cleanup code! Refactoring brings refactoring.
** '''Splash screen at module load'''.
*** Check '''dependencies''' all before interface load. If something is missing, a popup window will give a clear message.
** Continue integrating '''gstat functions'''

* '''IDEAS TO DISCUSS'''
** Create a '''package''' to delegate dependencies check!
** '''Variogram fit''': in a separated window, with allowed interactive model fit, using Python plot libraries.

* '''BLOCKING ISSUE(S)'''
** NULL

== Documentation ==

Kriging theory from Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [0]. Great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [1] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [2].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [3] ==

=== Report #1, 29 May ===

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [0], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [4]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

=== Report #2, 5 June ===

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

=== Report #2.5, 11 June ===

First of all, the interface is almost finished. See a screenshot on the wiki page [0].
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample [1] works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

=== Report #3, 12 June ===

this weekly report will be very short, as yesterday I sent this email
[0] and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK
because of projection information handling.

=== Report #4, 19 June ===

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check
and data load, and examine how to integrate gstat functions.

=== Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event]) ===

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data, see this tutorial [0]. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

=== Report #6, 3 July ===

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

=== Report #7, midterm, 10 July ===

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

== References ==
* [0] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics", (ISBN 0-19-505013-4)
* [1] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [2] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [3] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [4] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [5] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]

V.krige GSoC 2009

2009-07-14T12:55:34Z

⚠️AnneGhisla:

=== v.krige: Python porting and wxPython GUI addition ===
Anne Ghisla's [http://socghop.appspot.com/student_project/show/google/gsoc2009/osgeo/t124023165994 Google Summer of Code 2009 project], mentored by Martin Landa and Michael Barton

== Aim of the project ==

As GRASS presently lacks [[kriging]] capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in ksh and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters.
I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI. All time left will be dedicated to addition of further functionality, in respect of the most needed.

== State of the art ==

''' Breaking news: Ordinary kriging is up and running both from GUI and CLI!''' not all the options are available for gstat, anyway is it a great goal to see that the whole process ends in writing a GRASS raster map with the result. Note also that the module suggests a filename based on the input data map name. One step further towards the One-Click Interface.

[[File:Schermata-Kriging Module.png|450px|left]]

Have a look at it from svn:

svn co https://svn.osgeo.org/grass/grass-addons/vector/v.krige v.krige

Dependency check is performed on grass-python module, R, rpy2 and R packages gstat and spgrass6. If something is missing, the module won't start. Some graceful popup window will be set up in the near future. At the moment it aborts with a message in the shell.

Kriging relies on R package gstat, the most widespread. geoR tab is now hidden as it doesn't provide any functionality, but if anyone is interested in using it instead of gstat I'll put this todo higher in the list.

The list of point layers is provided by VectorSelect class (gselect module) to provide uniformity of layout with wxGUI. The filtering is done once at the start of the module, then if the user adds a suitable point layer she/he will press the Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.

== Installation ==

Please refer to [[Compile_and_Install#Scripts]].

=== Notes for Debian GNU/Linux ===

Install the dependiencies:

aptitude install R python-rpy2

'''Attention! python-rpy IS NOT SUITABLE.'''

To install R packages, use either R's function (as root):

install.packages("gstat", dep=T)
install.packages("spgrass6", dep=T)

either the brand new Debian packages [5], add to repositories' list for 32bit:

deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

or, for 64bit:

deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

and get the packages via

aptitude install r-cran-gstat r-cran-spgrass6

=== Notes for Windows ===

Please use OSGeo4W Installer to get all dependencies, except R and its packages. More to come.

== Bulletin Board ==

* '''TODOs'''
** '''Document dependencies''' - continue fill up html template page
** Cleanup code! Refactoring brings refactoring.
** '''Splash screen at module load'''.
*** Check '''dependencies''' all before interface load. If something is missing, a popup window will give a clear message.
** Continue integrating '''gstat functions'''

* '''IDEAS TO DISCUSS'''
** Create a '''package''' to delegate dependencies check!
** '''Variogram fit''': in a separated window, with allowed interactive model fit, using Python plot libraries.

* '''BLOCKING ISSUE(S)'''
** NULL

== Documentation ==

Kriging theory from Isaaks and Srivastava's "An Introduction to Applied Geostatistics" [0]. Great book.

== Users feedback and other kriging software ==

* Call for users has been done on gfoss.it, grass-it and grass-users, r-sig-geo and r-sig-ecology mailing lists. Thanks to Giovanni Manghi and João Tiago from GFOSS.pt and Giovanni Allegri for user advices, and to Edzer Pebesma, Paul Hiemstra, Ebrahim Jahanshiri, Dylan Beaudette for support on R side.

* There are (have been) some GRASS modules that perform kriging, like:
** v.surf.krige, v.variogram: no longer developed by authors, difficult to port.
** s.surf.krig: deprecated since GRASS 6 series.
** scripts including R and spgrass6: are the concrete basis upon which build the module.

* Obtained ArcGIS availability for comparison of interface and functionality, because it is AFAIK the widespread tool used for kriging. Also Isats [1] is a valuable source of ispiration for interface design.

== Planned Timeline ==

Draft:
* create a wxPython interface for ordinary kriging. Will follow Humane Interface rules [2].
* integrate R package ''automap''
* '''midterm deadline''': have a working module that performs ordinary kriging.
* integrate more R functions from ''gstat'' and ''geoR'', giving the user the choice between gstat and geoR (kriging results vary in respect of implementation)

== Weekly Reports, from SoC mailing list [3] ==

=== Report #1, 29 May ===

* Done: I dedicated this week to documentation and discussion with users and developers.
** Documentation: I'm reading "An introduction to Applied Geostatistics" [0], as I need to understand the theory behind kriging functions provided by R. On wxPython side, wxPython wiki is the main source of information, together with the code of GRASS wxPython interface.
** Community discussion: Feedback on interface design and R has been collected on various mailing lists. Also, a group of Portuguese ArcGIS users is interested in giving advice and test the new module.

* Planned for next week
I plan to define which functions (and consequently which R packages) are to be included into the module. I plan to first include package automap (a wrapper for gstat), then gstat advanced functions, then geoR (an "ecological vicariant" of gstat), all alvailable on CRAN [4]. This will allow R users to keep using their preferred functions, as kriging results are implementation-dependent.
Then I'll work on wxPython interface and get a draft as soon as possible. The interfaces that I use as model are ArcGIS' kriging module and Isatis. I won't replicate their structure, rather see what are the provided features and create v.autokrige interface following Humane Interface guidelines.

* Bottleneck(s)
I'm experiencing some difficulties, mainly with wxPython, as I never used it before, and also with kriging, for the same reason :) but I'm not worried nor blocked. Last year GSoC project was a bet and I succeeded, this year it's even harder but I can rely on some more experience and, as always, on mentor and community support.

=== Report #2, 5 June ===

* Done
** Ended "An Introduction to Applied Geostatistics", great source of information of what the module is supposed to do. Now I can be both developer and user, not discarding any of the hints of other users.
** Some progress on the interface: I'm getting used of wxWidgets, even if the lack of a graphical designer slows down my work. wxDesigner seems good, but I think it is also good for me to learn the meaning of each line of code. The interface is quite ready for automap and GRASS integration.

* Planned for next week
End of interface essential features and integration of automap most automated functions - ideally, the user will pick up the point layer containing data and press OK.

* Bottleneck(s)
The only bottleneck is wxWidgets handling, but not so much as one week ago.

=== Report #2.5, 11 June ===

First of all, the interface is almost finished. See a screenshot on the wiki page [0].
The layout includes a notebook with a page for each R package (automap, gstat and geoR), with the available options. Another layout could be a chiocebox wht the three packages on the top of Kriging section, that redraws the section accourding to the user's choice.
Let me know which one do you prefer, feel free also to suggest something new.

The R-GRASS integration is on its way: autofitting the variogram on a map obtained from a DEM sample [1] works in the proof of concept. rpy2 is extremely helpful and does not require much more code than the original R code. More to come in the next days.

The idea for variogram fitting is to plot the variogram in a new frame and add some controls like sliders and/or text boxes to fill up with
nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible.

=== Report #3, 12 June ===

this weekly report will be very short, as yesterday I sent this email
[0] and made little progress.

I'm having some problems in using autoKrige() function work, AFAIK
because of projection information handling.

=== Report #4, 19 June ===

this week I made steady progress on the module.
What I've done:
* renamed the module v.krige, as its features will go beyond automatic kriging.
* addition of choicebox with only numerical columns, as interpolation will be based on such variables
* refactoring on interface population - more to come
* started documentation page

Next week I plan to create the splashscreen during dependencies check
and data load, and examine how to integrate gstat functions.

=== Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event]) ===

just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on
spearfish data, see this tutorial [0]. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters.

Next week I plan to adapt the interface to each R package's available options and consider how to solve lag issues in populating interface.

The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region.

=== Report #6, 3 July ===

this week I worked on removing parameters hardwired in the code, binding them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output raster map name and eventually overwrite it.
I'm going to implement CLI in these next days, it will very likely need to reorganise the code and clearly split interface from model.

Blocking issues - none.

=== Report #7, midterm, 10 July ===

this week has been full of improvements:
* CLI with optional arguments is up and running
* interface creation is no more delayed by vector map filtering
* dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing
* automap page merged with gstat: they share the same algorithms
* geoR page hidden, no implementation yet
* deep refactoring of the rpy code, moved into a separate controller class
* interface fills up all options except input data map - minimum interaction required (2 clicks)

next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques.

Blocking issues - none.

== References ==
* [0] Isaaks and Srivastava, 1989: "An Introduction to Applied Geostatistics", (ISBN 0-19-505013-4)
* [1] http://www.geovariances.com/software/video-data-investigation-with-isatis-exploratory-data-analysis-ar0353.html
* [2] Jef Raskin, 2000: "The Humane Interface: New Directions for Designing Interactive Systems" (ISBN 0-201-37937-6)
* [3] OSGeo SoC mailing list http://lists.osgeo.org/pipermail/soc/
* [4] CRAN: Spatial view http://cran.r-project.org/web/views/Spatial.html
* [5] cran2deb repository https://stat.ethz.ch/pipermail/r-sig-debian/2009-July/000805.html

[[Category:GSoC]]