= v.krige development =

v.krige module has been developed in 2009 by Anne Ghisla during Google Summer of Code, mentored by Martin Landa.

See http://grasswiki.osgeo.org/wiki/V.krige_GSoC_2009 for information on installation and examples.

== Bulletin Board == 

The general plan for makin v.krige functional again has been drafted by Anne, Anna and Vasek at Genova Community sprint 2013.

The module is not a native GRASS command that has an optional GUI, because variogram estimation requires user interaction on a GUI. Still, a user can run v.krige with automatic variogram fitting, despite its potential poor results. So it makes sense to move v.krige in GUI modules, and leave the processing functions (variogram fitting and kriging) in a separate script for future separation as libraries.

The idea is to follow r.li.setup structure and have one folder containing GUI file(s), processing file(s), Makefile and documentation.

''Update from GRASS Sprint in Prague'': Thanks to Anna and Vasek commits on GUI part of the module, I have been able to restore variogram preview and kriging in current trunk [http://trac.osgeo.org/grass/changeset/57146]. Still, the separation of GUI from R code is not perfect as the GUI needs to call R directly to calculate and draw the variogram. I was thinking to separate v.krige in two modules, v.variogram and v.krige itself. Then it would be possible to create a dedicated GUI that is not directly called as a module, just like Georectifier. It will always be possible to run v.variogram and v.krige as CLI modules in a script. Of course it makes little sense as the kriging process is quite heuristic. 

* '''TODOs'''
 * 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 candidate:
  * '''HPGL'''  http://hpgl.aoizora.org/ - Python/C++ library with Python API. Pro: Very rich set of functions and parallelisation. Con: Not supported on Mac
  * '''scipy''' - check if kriging functions are high-level enough to be added to GRASS without writing a kriging module from scratch.

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

Available on  http://grasswiki.osgeo.org/wiki/V.krige_GSoC_2009 .