| 39 | | '''Report #1, 29 May''' |
| 40 | | |
| 41 | | * Done: I dedicated this week to documentation and discussion with users and developers. |
| 42 | | ** 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. |
| 43 | | ** 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. |
| 44 | | |
| 45 | | * Planned for next week |
| 46 | | 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. |
| 47 | | 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. |
| 48 | | |
| 49 | | * Bottleneck(s) |
| 50 | | 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. |
| 51 | | |
| 52 | | '''Report #2, 5 June''' |
| 53 | | |
| 54 | | * Done |
| 55 | | ** 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. |
| 56 | | ** 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. |
| 57 | | |
| 58 | | * Planned for next week |
| 59 | | 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. |
| 60 | | |
| 61 | | * Bottleneck(s) |
| 62 | | The only bottleneck is wxWidgets handling, but not so much as one week ago. |
| 63 | | |
| 64 | | '''Report #2.5, 11 June''' |
| 65 | | |
| 66 | | First of all, the interface is almost finished.. |
| 67 | | 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. |
| 68 | | Let me know which one do you prefer, feel free also to suggest something new. |
| 69 | | |
| 70 | | 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. |
| 71 | | |
| 72 | | 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 |
| 73 | | nugget, sill and range values. This will involve Python graphics, not R, as the former is more flexible. |
| 74 | | |
| 75 | | '''Report #3, 12 June''' |
| 76 | | |
| 77 | | this weekly report will be very short, as yesterday I sent this email (Report 2.5, see above) and made little progress. |
| 78 | | |
| 79 | | I'm having some problems in using autoKrige() function work, AFAIK because of projection information handling. |
| 80 | | |
| 81 | | '''Report #4, 19 June''' |
| 82 | | |
| 83 | | this week I made steady progress on the module. |
| 84 | | What I've done: |
| 85 | | * renamed the module v.krige, as its features will go beyond automatic kriging. |
| 86 | | * addition of choicebox with only numerical columns, as interpolation will be based on such variables |
| 87 | | * refactoring on interface population - more to come |
| 88 | | * started documentation page |
| 89 | | |
| 90 | | Next week I plan to create the splashscreen during dependencies check and data load, and examine how to integrate gstat functions. |
| 91 | | |
| 92 | | '''Report #5, 26 June (at [http://wiki.osgeo.org/wiki/OSGeo_Hacking_Event_2009 OSGeo Bolsena Hacking Event])''' |
| 93 | | |
| 94 | | just few minutes ago I succeded in completing the kriging procedure with gstat functions. It runs with a proof-of-concept dataset based on |
| 95 | | spearfish data. Martin helped me a lot in getting the standard wxGUI comboboxes to run properly with filters. |
| 96 | | |
| 97 | | 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. |
| 98 | | |
| 99 | | The blocking issue about autoKrige() and projections is no more valid as I create the grid myself based on GRASS region. |
| 100 | | |
| 101 | | '''Report #6, 3 July''' |
| 102 | | |
| 103 | | this week I worked on removing parameters hardwired in the code, binding them to the interface instead. |
| 104 | | 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; |
| 105 | | set the output raster map name and eventually overwrite it. |
| 106 | | 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. |
| 107 | | |
| 108 | | Blocking issues - none. |
| 109 | | |
| 110 | | '''Report #7, midterm, 10 July''' |
| 111 | | |
| 112 | | this week has been full of improvements: |
| 113 | | * CLI with optional arguments is up and running |
| 114 | | * interface creation is no more delayed by vector map filtering |
| 115 | | * dependencies are checked all at the beginning - no risk of mid-process crashes if something is missing |
| 116 | | * automap page merged with gstat: they share the same algorithms |
| 117 | | * geoR page hidden, no implementation yet |
| 118 | | * deep refactoring of the rpy code, moved into a separate controller class |
| 119 | | * interface fills up all options except input data map - minimum interaction required (2 clicks) |
| 120 | | |
| 121 | | next week I plan to implement the splashscreen and add further functionalities, hopefully different kriging techniques. |
| 122 | | |
| 123 | | Blocking issues - none. |
| 124 | | |
| 125 | | '''Report #8, 17 July''' |
| 126 | | |
| 127 | | this week I added Command output tab and the option for block kriging, and updated documentation with more precise information on dependencies. |
| 128 | | I'll add splashscreen only as dependency check and command output will be fixed: next week I plan to work on these latter issues. |
| 129 | | |
| 130 | | Nothing in particular is blocking progress, just some hardest stone sometimes. |
| 131 | | |
| 132 | | '''Report #9, 24 July''' |
| 133 | | |
| 134 | | 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. |
| 135 | | |
| 136 | | 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 |
| 137 | | for R. A general cleanup of the code is also welcome... |
| 138 | | |
| 139 | | No blocking issues atm. |
| 140 | | |
| 141 | | '''Report #10, 31 July''' |
| 142 | | |
| 143 | | good news from v.krige: |
| 144 | | * fixed optional parameters also in interface - activated by a checkbox, otherwise R's NA value is correctly set |
| 145 | | * interactive variogram fit is on its way - stay tuned! |
| 146 | | |
| 147 | | Next week I plan to set up interactive variogram using matplotlib functions and get the stabler code possible for feature freeze. |
| 148 | | |
| 149 | | |
| 150 | | '''Report #11, 7 August''' |
| 151 | | |
| 152 | | 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. |
| 153 | | Variogram plotting is on its way - I discarded matplotlib to avoid further dependencies, in favour of wx.lib.plot. |
| 154 | | |
| 155 | | |
| 156 | | '''Report #12, 14 August''' |
| 157 | | |
| 158 | | 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. |
| 159 | | Documentation includes a full example using Spearfish dataset and all informations about dependencies. |
| 160 | | |
| 161 | | Many thanks to all who have helped me writing v.krige: GRASS and R developers, OSGeo SoC crew, wise friends, all testers. |
| 162 | | I hope this module will attract people towards GRASS and R, and provide a valid alternative to closed-source kriging tools. |
| | 39 | Available on http://grasswiki.osgeo.org/wiki/V.krige_GSoC_2009 . |
