See original post by Jarosław Jasiewicz
Hi all!
That rather radical ideas I present here are rather for future, at least for GRASS 8,
but I'd like present it now for long-term reflection.
Probably all notice that for over two years there is big increase in add-on repository
(including me). There are modules of different quality: from fully GRASS toolsets,
to shell or python scripts, from actively developed tools to abandoned,
from all-purpose tools to very specialized etc. I also think that that activity
will be grown due to substitute shell script by python
Similar situation is in main GRASS branch: there are modules for all like conversion tools,
interpolation methods, georeferencing etc, and very specialized modules for very limited
group of users (like wild fire), there are also some modules out of date.
I'm not enthusiastic about moving new modules into main branch. Almost every module has
different coding style and it will lasting in future that GRASS would be difficult to maintain.
On the other hand some people complains that some interesting modules are only available as
add-ons (I assume for some reasons they cannot install it)
So my suggestion is to rearrange future GRASS form two layers (main branch/add-on) into
three layers architecture:
1) GRASS core layer: much limited limited than now, only GIS environment and basic,
all-puropse tools, slow changes, great stability
2) GRASS toolset layer: oficcial GRASS thematic tools and toolsets (like terrain analysis,
hydrological analysis, photo-interpretation, landscape analysis etc,) every toolset with its
maintainer, rapid development, new ready to use tools after quality control may appear here,
also some of current main branch tool shall be moved to that layer
3) GRASS community layer: everything else like experimental, actively development new tools,
that what do not pass quality control, simple scripts, etc....
What benefits:
for developers and contributors: much clear situation and better publication path.
Toolset layer should be much more open for new tools than current GRASS main branch
for users: faster access to new tools.
There is no doubt that new tools are faster developed (less risk) than GRASS core
Binaries with toolsets could be maintained as separate apt/urpmi/pacman/yum/exe etc packages,
so it may appear in linux repository separetly form GRASS core.
There is only loose ideas. Most of them are of course taken from R (core/toolsets/rest of packages;
separate core and package development) but I think it is worth of some discuss ...
regards
Jarek
Repository layout
Current repository layout
- grass
|- trunk
|- raster/
|- vector/
|- ...
- grass-addons
|- raster/
|- vector/
|- ...
Proposed repository layout
- grass
|- trunk
|- raster/
|- vector/
|- ...
- grass-tools
|- trunk
|- raster/
|- vector/
|- ...
- grass-addons
|- raster/
|- vector/
|- ...
Proposed toolboxes
Toolbox is a topic-based set of modules used for solving common GIS analysis, like hydrology, networking, LRS, etc. Toolbox should be easily installed by the user, for this purpose could be designed module g.toolbox to
g.toolbox toolbox=hydrology operation=add
Module downloads source code of the selected modules from SVN, compile them and afterwards also install them to the user-specified (~/.grass7/tools) or system (/usr/lib/grass7) directory.
g.toolbox toolbox=hydrology operation=remove
- list of modules from given toolbox
g.toolbox -l toolbox=hydrology
User can also add/remove selected module via g.extension.
List of toolboxes
- 3D Raster
- All `r3.*` modules
List of modules (trunk)
Display
Database
General
Imagery
Misc
Postscript
| Module |
Core/Tools/Addons |
Toolbox(es)
|
| ps.map |
? |
|
Raster
3D raster
Vector
Various
List of selected AddOns modules
See GRASS AddOns for full list of available modules.
| Module |
Core/Tools/Addons |
Toolbox(es)
|
| ... |
? |
|
