The r.stream* modules have been around for quite awhile and are very useful.
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
for r.stream* and r.geomorphon (both worth to be included into the core) it would be useful
to contact the developers (Jarek) -
Vasek, can you please email him to ask about their interest
in getting the modules included and make the necessary adjustments?
From my discussion with Jarek last year I got an impression that they have improved versions
of these modules, but I am not sure how those conform to the GRASS core standards in terms
of portability. However, they were interested in having the modules in core GRASS.
Helena
On Jul 5, 2016, at 4:31 AM, Helmut Kudrnovsky <hellik@web.de> wrote:
The r.stream* modules have been around for quite awhile and are very useful.
regarding the r.stream.*-modules, some tickets may be solved first:
Helena Mitasova
Professor at the Department of Marine,
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu http://geospatial.ncsu.edu/osgeorel/publications.html
"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”
2016-07-05 15:06 GMT+02:00 Helena Mitasova <hmitaso@ncsu.edu>:
for r.stream* and r.geomorphon (both worth to be included into the core) it would be useful
to contact the developers (Jarek) -
please remember that r.stream modules has been already included in
trunk and later removed (before 7.0). The main reason was that the
modules give slightly different results when using memory swap
(AFAIR). There is also huge duplication of code (some parts should be
moved to a new library).
This discussion is actually a bit old, but maybe it is not too late to consider adding selected addons to trunk?
However, also:
i.segment.hierarchical (though manual is not yet complete)
v.class.mlpy (drawback: requires mlpy library) or v.class.ml and
r.randomforest
could nicely complement the image classification tools in GRASS.
r.gwr would strengthen the general modeling power of GRASS.
The wx.metadata modules would be very relevant for institutional users too, but I guess the currently numerous dependencies prohibit to move them to core…
This discussion is actually a bit old, but maybe it is not too late to
consider adding selected addons to trunk?
From my personal user point of view the r.streams.* modules and
r.geomorphon are indeed top candidates for inclusion in core!
However, also:
i.segment.hierarchical (though manual is not yet complete)
I've been working on trying to understand the exact functioning of the module and on writing some documentation on this, but this has been side-tracked by the many other priorities at work...
v.class.mlpy (drawback: requires mlpy library) or v.class.ml and
r.randomforest
could nicely complement the image classification tools in GRASS.
+1
In the same line, it might be nice to add:
i.segment.stats and r.object.geometry.
And possibly also v.class.mlR and i.segment.uspo...
This discussion is actually a bit old, but maybe it is not too late to
consider adding selected addons to trunk?
From my personal user point of view the r.streams.* modules and
r.geomorphon are indeed top candidates for inclusion in core!
However, also:
i.segment.hierarchical (though manual is not yet complete)
I’ve been working on trying to understand the exact functioning of the module and on writing some documentation on this, but this has been side-tracked by the many other priorities at work…
v.class.mlpy (drawback: requires mlpy library) or v.class.ml and
r.randomforest
could nicely complement the image classification tools in GRASS.