V.krige GSoC 2009: Difference between revisions
⚠️AnneGhisla (talk | contribs) (→State of the art: updates - upload screenshot) |
⚠️AnneGhisla (talk | contribs) (added ToDo list) |
||
Line 15: | Line 15: | ||
It is quite complete, allows the user to choose among automap (default choice), gstat (advanced functions) and geoR. | It is quite complete, allows the user to choose among automap (default choice), gstat (advanced functions) and geoR. | ||
These three packages are not all required; if the user already uses R for kriging, the interface will load the package(s) present in R library. If none of the packages is available a popup message will ask for installation of at least one of the packages and abort. That is, crash gracefully and with clear explanation. I know what it means to crawl among missing dependencies and I don't want my users to be puzzled by inexplicable error messages. | These three packages are not all required; if the user already uses R for kriging, the interface will load the package(s) present in R library. If none of the packages is available a popup message will ask for installation of at least one of the packages and abort. That is, crash gracefully and with clear explanation. I know what it means to crawl among missing dependencies and I don't want my users to be puzzled by inexplicable error messages. | ||
Line 26: | Line 27: | ||
'''Variogram autofit is up and running!!''' The column with values in bound in the code and the data are not in spearfish, but it works! | '''Variogram autofit is up and running!!''' The column with values in bound in the code and the data are not in spearfish, but it works! | ||
== ToDo list == | |||
* Document dependencies | |||
* Set command line interface | |||
* Automap's autoKrige() error with projections - wait for patch | |||
* Refactor R packages page creation | |||
* Filter suitable point vector maps without creating lag before interface creation - splash screen? Delay filtering after interface appear? | |||
== Documentation == | == Documentation == |
Revision as of 14:07, 15 June 2009
v.autokrige: Python porting and wxPython GUI addition
Anne Ghisla's 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 bash 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
Writing the wxPython interface - have a look at it from svn:
svn co https://svn.osgeo.org/grass/grass-addons/vector/v.autokrige2 v.autokrige2
It is quite complete, allows the user to choose among automap (default choice), gstat (advanced functions) and geoR.
These three packages are not all required; if the user already uses R for kriging, the interface will load the package(s) present in R library. If none of the packages is available a popup message will ask for installation of at least one of the packages and abort. That is, crash gracefully and with clear explanation. I know what it means to crawl among missing dependencies and I don't want my users to be puzzled by inexplicable error messages.
Question: another layout can be a Choicebox with the three packages and in respect of the choice the drawing of corresponding widgets. Opinions welcome.
Anne vs. Sizers: 1 - 0! Now the window has the minimal size around the widgets. It costs two lines of code but AFAIK seems not possible to use only one.
On GRASS side, I succeeded in populating a wxChoicebox with vector layers of the mapset in use, furthermore discarding maps with no points. This second filter requires some time if there are lot of maps, so I'm considering to first set up the interface and in the meanwhile the user inspects the options perform this operation. It is not dead long (few seconds on my 2GB-RAM and Intel Core2Duo laptop, using spearfish dataset), but it creates an evident lag between the call of the module and the creation of interface.
GRASS and R integration are really smooth with Python. In next days I'll build the minimum-option kriging procedure via automap, hopefully for next report. Variogram autofit is up and running!! The column with values in bound in the code and the data are not in spearfish, but it works!
ToDo list
- Document dependencies
- Set command line interface
- Automap's autoKrige() error with projections - wait for patch
- Refactor R packages page creation
- Filter suitable point vector maps without creating lag before interface creation - splash screen? Delay filtering after interface appear?
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 are available on SoC mailing list [3]
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] http://lists.osgeo.org/pipermail/soc/