[GRASS-dev] grass toolboxes idea continued (g.extension)

Hi,

I have added (r50024) very initial support of "toolboxes idea" (see
[1] for detailed information) to `g.extension` (see notes at wiki
[2]). Any feedback, support, improvements welcomed.

Martin

[1] http://grass.osgeo.org/wiki/Toolboxes
[2] http://grass.osgeo.org/wiki/Toolboxes#Managing_toolboxes

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Hello,
I'm not in the mood to digg deeply into this concept. It looks similar
to R packages, right? Can we borrow most of (design) from R to not
reinvent the wheel and to learn from their mistakes/success?

Also, if we have an option to start a new, why limit ourselves to
single or double letter as toolbox prefix? I assume, all modules in a
toolbox should have a common prefix, like hy.flow, right?

Just drinking morning tea,
Maris.

2012/1/2 Martin Landa <landa.martin@gmail.com>:

Hi,

I have added (r50024) very initial support of "toolboxes idea" (see
[1] for detailed information) to `g.extension` (see notes at wiki
[2]). Any feedback, support, improvements welcomed.

Martin

[1] http://grass.osgeo.org/wiki/Toolboxes
[2] http://grass.osgeo.org/wiki/Toolboxes#Managing_toolboxes

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Hi,

On Tue, Jan 3, 2012 at 8:31 AM, Maris Nartiss <maris.gis@gmail.com> wrote:

Hello,
I'm not in the mood to digg deeply into this concept. It looks similar
to R packages, right? Can we borrow most of (design) from R to not
reinvent the wheel and to learn from their mistakes/success?

Why not use a modified version of pip [0] (a tool for installing and
managing Python packages)?

with Pip you can add/change repository, compile C/Fortran module,
manage dependencies, install from some version control system (use
URLs like hg+http://domain/repo -- or prefix git+, svn+ etc), and
using virtualenv [1].

my 2 cents.

Pietro

[0] http://pypi.python.org/pypi/pip - https://github.com/pypa/pip
[1] http://pypi.python.org/pypi/virtualenv

Hi,

2012/1/3 Maris Nartiss <maris.gis@gmail.com>:

I'm not in the mood to digg deeply into this concept. It looks similar
to R packages, right? Can we borrow most of (design) from R to not
reinvent the wheel and to learn from their mistakes/success?

we share just the idea, I don't know technical solution of providing R
packages so deeply. Anyway there is no so big overlap from my POV
(speaking about technical solution).

Also, if we have an option to start a new, why limit ourselves to
single or double letter as toolbox prefix? I assume, all modules in a
toolbox should have a common prefix, like hy.flow, right?

Not at all, toolbox should be just set of modules, see initial example
for "Hydrology" toolbox. Toolbox is described in XML file [1] which
currently contains name, code, correlate toolboxes and list of
modules, eg.

Hydrology (HY)
* r.stream.basins
* r.stream.channel
* r.stream.distance
* r.stream.extract
* r.stream.order
* r.stream.segment
* r.stream.slope
* r.stream.snap
* r.stream.stats

Currently it means that if you run

g.extension -t ext=HY

it will install all r.stream modules from addons a register them in
GRASS_ADDON_BASE/modules.xml and GRASS_ADDON_BASE/toolboxes.xml. It's
already implemented. What should be done

* g.extension should modify wxGUI menu to add new items for each module
* g.extension should register new toolbar related to the given toolbox.

Any kind of help is very welcomed. Personally I have very limited time
for these tasks.

Martin

[1] https://svn.osgeo.org/grass/grass-addons/grass7/toolboxes.xml

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Hi,

2012/1/3 Pietro <peter.zamb@gmail.com>:

Why not use a modified version of pip [0] (a tool for installing and
managing Python packages)?

with Pip you can add/change repository, compile C/Fortran module,
manage dependencies, install from some version control system (use
URLs like hg+http://domain/repo -- or prefix git+, svn+ etc), and
using virtualenv [1].

interesting links, I took liberty to record it as 'propose 3' on wiki page [1].

Martin

[1] http://grass.osgeo.org/wiki/Toolboxes#Propose_3

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Since there are at least four major FOSS desktop GIS
projects (GRASS, SAGA, SEXTANTE + gvSIG, QGIS + GRASS plugin),
each of which faces the same problem of sorting geoprocessing
tools into groups, I wonder: Would it be worth the effort
to try to establish a common hierarchy/grouping standard for
for geoprocessing tools across GIS? Sort of like the LSB
(http://en.wikipedia.org/wiki/Linux_Standard_Base) for
Linux file system hierarchies?

I imagine this would make it much easier for users to work
with different FOSS GIS and always find the tools they need.

A common standard could also include labels and descriptions,
plus their translations into different languages, and of
course icons for GUIs.

Ben

--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
  
  benducke AT fastmail.fm

On Mon, Jan 2, 2012, at 17:15, Martin Landa wrote:

Hi,

I have added (r50024) very initial support of "toolboxes idea" (see
[1] for detailed information) to `g.extension` (see notes at wiki
[2]). Any feedback, support, improvements welcomed.

Martin

[1] http://grass.osgeo.org/wiki/Toolboxes
[2] http://grass.osgeo.org/wiki/Toolboxes#Managing_toolboxes

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Hi Ben,

This is very good idea.
At the moment it sounds more like useful tool for developers, not directly users. Mentioned projects implement common libraries and modules in their own style and structure. And I don't think it will change soon. This is however good moment to start discussion about unified hierarchy.
But this can be good point to start with common tags. Such tags (simple to implement and transparent) will help developers build toolboxes and implement frameworks [1].

regards,
Robert
[1] http://polymeris.github.com/qgis/

W dniu 03.01.2012 21:31, Benjamin Ducke pisze:

Since there are at least four major FOSS desktop GIS
projects (GRASS, SAGA, SEXTANTE + gvSIG, QGIS + GRASS plugin),
each of which faces the same problem of sorting geoprocessing
tools into groups, I wonder: Would it be worth the effort
to try to establish a common hierarchy/grouping standard for
for geoprocessing tools across GIS? Sort of like the LSB
(http://en.wikipedia.org/wiki/Linux_Standard_Base) for
Linux file system hierarchies?

I imagine this would make it much easier for users to work
with different FOSS GIS and always find the tools they need.

A common standard could also include labels and descriptions,
plus their translations into different languages, and of
course icons for GUIs.

Ben