V.krige GSoC 2009: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
No edit summary
mNo edit summary
Line 9: Line 9:
== State of the art ==
== State of the art ==


''' Breaking news: Ordinary kriging with gstat is up and running!''' there are still some parameters hardwired to the code, anyway is it a great goal to see that the whole process ends in writing a GRASS raster map with the result.
''' Breaking news: Ordinary kriging with gstat or automap is up and running!''' there are still some parameters hardwired to the code (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]]


'''Writing the wxPython interface, with GRASS bindings and part of R bindings''' - have a look at it from svn:
'''Writing the wxPython interface, with GRASS bindings and part of R bindings''' - have a look at it from svn:


'''Attention: The module is now called v.krige''', as its functions go beyond automatic kriging.
svn co https://svn.osgeo.org/grass/grass-addons/vector/v.krige v.krige


svn co https://svn.osgeo.org/grass/grass-addons/vector/v.krige v.krige
[[File:Schermata-Kriging Module.png|450px|left]]


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.  
Line 23: Line 21:
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.


Question: another layout can be a Choicebox with the three packages and in respect of the choice the drawing of corresponding widgets. Opinions welcome.  
Question: another layout can be a Choicebox with the three packages and in respect of the choice the drawing of corresponding widgets. Opinions welcome. [Until now, all preferences went to the Notebook.]


The lsit 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 a Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.
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 a Refresh button to force addition to the list. Automatic refresh on popup has been tested as too time and resource consuming.


== Installation ==  
== Installation ==  
Line 46: Line 44:
** '''Variogram fit''': in a separated window, with allowed interactive model fit?
** '''Variogram fit''': in a separated window, with allowed interactive model fit?


* '''BLOCKING ISSUES'''
* '''BLOCKING ISSUE(S)'''
** Widget hiding in different notebook pages... I don't have the patience to spend time for this now...
** Widget hiding in different notebook pages: I'm getting the list of children of the ParametersSizer, but can't call Enable method on them. It is possible to hide them but it's not my target. Putting all target widgets on a Panel or finding the way to getattr them can be a solution but it's not beautiful code. Hm.


== Documentation ==
== Documentation ==

Revision as of 14:57, 30 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 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 with gstat or automap is up and running! there are still some parameters hardwired to the code (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.

Writing the wxPython interface, with GRASS bindings and part of R bindings - have a look at it from svn:

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

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. [Until now, all preferences went to the Notebook.]

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

Bulletin Board

  • TODOs
    • Document dependencies - continue fill up html template page
    • Set CLI (SWIG?)
    • Refactor the code where widgets are created and set into sizers, like LayerBook's __createModifyPage in dbm.py
    • Continue integrating gstat functions
  • IDEAS TO DISCUSS
    • Filter the maps after interface creation - wx.CallAfter/threads... have to grep documentation and examples
    • Initial sanity checks:
      • Check dependencies all before interface load. If something is missing, a popup window will give a clear message.
      • Create a package to delegate dependencies check!
    • Variogram fit: in a separated window, with allowed interactive model fit?
  • BLOCKING ISSUE(S)
    • Widget hiding in different notebook pages: I'm getting the list of children of the ParametersSizer, but can't call Enable method on them. It is possible to hide them but it's not my target. Putting all target widgets on a Panel or finding the way to getattr them can be a solution but it's not beautiful code. Hm.

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