[GRASS-dev] could r.stream.* become part of GRASS core?

Dear list,

as user involved in hydrological analysis, I think r.stream.* modules
are essential tools in GRASS GIS.
Their availability filled in the empty space left by the Horton
Machine / Fruid Turtles library (by prof. Rigon and his fantastic
team) no more supported for GRASS GIS.

Quality, scientific value and great performances of r.stream.*
algorithms it’s out of the question, IMHO
Looking in the user mailing list and searching on the web can confirm
that many users really appreciate those modules even if some people
have trouble with the AddOns installation process.

So, could those modules be part of Grass core in the next releases?
As part of GRASS GIS core, I think they could be fruitfully become
available also in the QGIS GRASS toolbox.

Regards,
Enrico

Ciao Enrico,

I agree that the quality of the r.stream.* modules is out of question. For what concerns including it into the core, I would like to point you out the discussion [1] about the concept of toolboxes. The general orientation is not to include field specific groups of modules into the core and make them available in an easy way when required. In case you meet any issue concerning the installation of the add-ons, please do not hesitate to report to the list or file a ticket.

Ciao

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

On Sat, Sep 8, 2012 at 11:10 PM, Enrico Gallo <enrico.gallo@gmail.com> wrote:

Dear list,

as user involved in hydrological analysis, I think r.stream.* modules
are essential tools in GRASS GIS.
Their availability filled in the empty space left by the Horton
Machine / Fruid Turtles library (by prof. Rigon and his fantastic
team) no more supported for GRASS GIS.

Quality, scientific value and great performances of r.stream.*
algorithms it’s out of the question, IMHO
Looking in the user mailing list and searching on the web can confirm
that many users really appreciate those modules even if some people
have trouble with the AddOns installation process.

So, could those modules be part of Grass core in the next releases?
As part of GRASS GIS core, I think they could be fruitfully become
available also in the QGIS GRASS toolbox.

Regards,
Enrico


grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Margherita DI LEO
Postdoctoral Researcher
European Commission - DG JRC
Forest Resources and Climate
I-21020 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-leo@jrc.ec.europa.eu

Hi,

since the r.stream.* modules are continuously requested and IMHO sufficiently
tested (according to user reports), I would move them to core if there are
no objections.

Markus

+1

On Thu, Nov 15, 2012 at 11:23 AM, Markus Neteler <neteler@osgeo.org> wrote:

Hi,

since the r.stream.* modules are continuously requested and IMHO sufficiently
tested (according to user reports), I would move them to core if there are
no objections.

Markus


grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@fws.gov

The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.

since the r.stream.* modules are continuously requested and IMHO

sufficiently

tested (according to user reports), I would move them to core if there are
no objections.

+1

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/could-r-stream-become-part-of-GRASS-core-tp5000607p5016760.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

I agree that the quality of the r.stream.* modules is out of question.

these are very nice and useful modules with high quality.

For what concerns including it into the core, I would like to point you
out the discussion [1] about the
concept of toolboxes. The general orientation is not to include field
specific groups of modules into
the core and make them available in an easy way when required.

but how can we guide "normal" users that such interesting tools are in the
addons?

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/could-r-stream-become-part-of-GRASS-core-tp5000607p5016768.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15/11/12 23:41, Helmut Kudrnovsky wrote:

I agree that the quality of the r.stream.* modules is out of question.

these are very nice and useful modules with high quality.

For what concerns including it into the core, I would like to point you out the discussion
[1] about the concept of toolboxes. The general orientation is not to include field specific
groups of modules into the core and make them available in an easy way when required.

but how can we guide "normal" users that such interesting tools are in the addons?

That is an interesting and important question. One way would be to have one sub menu named
"Available Add-Ons" which is updated automatically from the official Add-On repository.
When one entry is selected, the extension manager could be opened to make installation easy.
And in the menu, it could be reflected which ones are already installed.

Just an idea,

Cheers

Rainer

----- best regards Helmut -- View this message in context:
http://osgeo-org.1560.n6.nabble.com/could-r-stream-become-part-of-GRASS-core-tp5000607p5016768.html

Sent from the Grass - Dev mailing list archive at Nabble.com.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCl9OMACgkQoYgNqgF2egr+ZQCfRo+coiU2QhmR8ty3bVyVMqjx
vx4An2PDm84nsCM5wZegeH27kaxo9uGu
=66J1
-----END PGP SIGNATURE-----

On 16/11/12 09:10, Rainer M Krug wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15/11/12 23:41, Helmut Kudrnovsky wrote:

I agree that the quality of the r.stream.* modules is out of question.

these are very nice and useful modules with high quality.

For what concerns including it into the core, I would like to point you out the discussion
[1] about the concept of toolboxes. The general orientation is not to include field specific
groups of modules into the core and make them available in an easy way when required.

Please also note the discussion in this thread [1], where most developpers rather seem to plead for integrating more modules directly into trunk.

Toolboxes would then rather be menu blocks that you can activate or not, organising your GUI access to the relevant modules.

Moritz

[1] http://lists.osgeo.org/pipermail/grass-dev/2012-October/060565.html

On Thu, Nov 15, 2012 at 5:23 PM, Markus Neteler <neteler@osgeo.org> wrote:

Hi,

since the r.stream.* modules are continuously requested and IMHO sufficiently
tested (according to user reports), I would move them to core if there are
no objections.

Coming back to this topic (delayed due to my "outage" in winter): no
objections, it seems.

r.regression.* might be another trunk candidate set.

Overview:
http://grasswiki.osgeo.org/wiki/AddOns/GRASS_7

Markus

Hi,

2013/4/4 Markus Neteler <neteler@osgeo.org>:

On Thu, Nov 15, 2012 at 5:23 PM, Markus Neteler <neteler@osgeo.org> wrote:

since the r.stream.* modules are continuously requested and IMHO sufficiently
tested (according to user reports), I would move them to core if there are
no objections.

only after major clean-up. If nobody else will do it, I could take a
look on the modules later in July.

Martin

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

Markus N wrote:

> since the r.stream.* modules are continuously requested
> and IMHO sufficiently tested (according to user reports), I
> would move them to core if there are no objections.

Coming back to this topic (delayed due to my "outage" in
winter): no objections, it seems.

I would be happy to see r.stream.* become part of the core.

At the risk of hijacking the thread, for those concerned that
the menus look like a 747 cockpit of options and so are not user
friendly, I'd again suggest a solution of "GUI views" settable
from the preferences menu, to hide or show different menu items.

From work packaging for debian, and from work trying to get

g.extension working for everyone everywhere, the idea of breaking
the core up into lots of addon toolboxes really makes me shudder.
Not having to fight with out-of-sync toolboxes is one of the
reasons I switched to GRASS in the first place :), and I've
gotten at least two papers out of easy access to modules which
performed processes that were typically not used in my field of
study, which I otherwise may never have looked at. I didn't get
much feedback about the "GUI views" idea before, but I'd still
like to hear thoughts about the approach. ?

Very much straying offtopic now, I'd also advocate a series of
wrapper scripts to run from GUI buttons for simple-mode d.vect.
(see also my d.* helper/wrapper scripts in g6 addons like d.varea,
d.stations, and d.mark) I feel the current d.vect GUI window
is a bit overwhelming, but that's no reason to break up the base
module, since wrapper scripts can handle the "simple views",
and the full d.vect module gui could be there for "advanced"
mode.

r.regression.* might be another trunk candidate set.

Overview:
http://grasswiki.osgeo.org/wiki/AddOns/GRASS_7

I've no experience with r.regression.* as I don't do that much
multi-spectral stuff, but if MarkusM was the author that's good
enough for me wrt the code quality side of things. wrt the "how
esoteric is it?" side of things, in general I'd say low-level
tools/building blocks suitable for multiple purposes and useful
as intermediary steps in scripts are a good match for 'core'.

re. other modules to consider-
One day I'd like to put the finishing touches on d.barb in g6
addons and then port it to g7 with an eye to getting it into
g7 core for its d.rast.arrow-for-vectors capabilities.
time, time, time..

best,
Hamish

On Thu, Apr 4, 2013 at 10:21 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2013/4/4 Markus Neteler <neteler@osgeo.org>:

On Thu, Nov 15, 2012 at 5:23 PM, Markus Neteler <neteler@osgeo.org> wrote:

since the r.stream.* modules are continuously requested and IMHO sufficiently
tested (according to user reports), I would move them to core if there are
no objections.

only after major clean-up. If nobody else will do it, I could take a
look on the modules later in July.

I can take care of r.stream.extract and the r.regression.* modules.
After that I will look at the other r.stream.* modules, but of course
I am happy for any help!

Markus M

On Thu, Apr 4, 2013 at 9:00 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:

On Thu, Apr 4, 2013 at 10:21 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2013/4/4 Markus Neteler <neteler@osgeo.org>:

On Thu, Nov 15, 2012 at 5:23 PM, Markus Neteler <neteler@osgeo.org> wrote:

since the r.stream.* modules are continuously requested and IMHO sufficiently
tested (according to user reports), I would move them to core if there are
no objections.

...

I can take care of r.stream.extract and the r.regression.* modules.

(r.regression.multi is now in GRASS 7 trunk, thanks)

After that I will look at the other r.stream.* modules, but of course
I am happy for any help!

cd grass-addons/grass7/raster/
LIST="r.stream.basins/ r.stream.distance/ r.stream.order/
r.stream.slope/ r.stream.stats/ r.stream.channel/ r.stream.extract/
r.stream.segment/ r.stream.snap/"
for i in $LIST ; do cd $i ; make MODULE_TOPDIR=$HOME/grass70 ; cd .. ; done

I see just a few (minor?) compiler warnings left. May be move them into trunk?

markusN