Changes between Version 3 and Version 4 of wxGUIDevelopment/vkrige


Ignore:
Timestamp:
Jul 16, 2013 6:30:24 AM (6 years ago)
Author:
aghisla
Comment:

Removed weekly reports

Legend:

Unmodified
Added
Removed
Modified
  • wxGUIDevelopment/vkrige

    v3 v4  
    3737== Weekly Reports, from SoC mailing list [4] ==
    3838
    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.
     39Available on  http://grasswiki.osgeo.org/wiki/V.krige_GSoC_2009 .