On Sun, Mar 27, 2011 at 8:05 AM, Hamish <[email protected]> wrote: ... > - "Design GRASS toolboxes environment, see GRASS repository layout proposal > for detailed information. This would also include general clean up and > organization of existing GRASS modules in trunk and add-ons." > -> We can't dump a student into such a contentious area without coming > to some consensus on the design ourselves first. Personally I consider > the breaking up of GRASS's 400 modules into a series of optional > toolboxes to be a massive mistake.
Why? > GEM already exists, but no one wants to use it, .. because it is overkill (since some lines of script to almost the same). > g.extention is at its core fundamentally a hack (I say as a > coauthor), etc.--there's still a lot of maturing of ideas to do. The > wiki addons page is getting rather long, but we aren't on the scale of > needing something like CRAN yet.. For sure the *easy* integration of extra functionality is wanted by many users. For sure also the possibility to "just" have the hydro part (or whatever) of GRASS with a few clicks which would then also (ideally) provide a GUI with only these modules in it. I find that idea quite good. > - "Design sophisticated Python scripting interface for GRASS". -> I don't > get it. What is it? What would it do which python + grass.py doesn't > already? Maybe you can but it is neither sufficiently documented (see all the related questions) nor sufficiently structured/complete to be a Python API to GRASS or whatever you want to call it. Markus _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
