[GRASS-dev] r.stream.* to trunk - what about r.stream.basins?

Markus Metz markus.metz.giswork at gmail.com
Sun Apr 6 06:52:32 PDT 2014


On Thu, Mar 27, 2014 at 1:54 PM, Helmut Kudrnovsky <hellik at web.de> wrote:
> hi,
>
> at the Vienna Code Sprint we're discussing moving the r.stream.* -modules to
> trunk.

Please, move modules from addons to trunk only after testing.

Now the modules are even in a release branch. If have disabled them in
releasebranch_7_0 because the results of the all-in-RAM and the
external-memory mode are not identical. Further, the code needs
cleaning up. IMHO, the modules should also be disabled in trunk,
cleaned up, tested, then activated again and backported to
releasebranch_7_0.

Markus M

>
> transition most of the r.stream.* is clear, but there may be some
> overlapping between r.water.outlet, r.watershed and r.stream.basins.
>
> short comparison
>
> - r.water.outlet [2] generates a watershed basin from a drainage direction
> map and a set of coordinates representing the outlet point of watershed.
>
> - r.stream.basins [1] is prepared to delineate basins and subbasins with
> different input data.
> It can delineate basins with three methods:
>
>     Using coordinates: this option simply copies functionality of
> r.water.outlet.
>     Using vector points: it allow to manually point outlets with any method
>     Using streams (most advanced): it allow on lots of modifications. See
> examples for more details.
>
> This module is prepared to delineate unrestricted number of basins in one
> step.
>
> - r.watershed [3]:
>
> basin
>     Output map: Unique label for each watershed basin. Each basin will be
> given a unique positive even integer. Areas along edges may not be large
> enough to create an exterior watershed basin.
>         0 values indicate that the cell is not part of a complete watershed basin
> in the current geographic region.
>
>
> as cloning/doubling functionality should be avoided, how to proceed now to
> with these partly overlapping modules?
>
> to the aim of avoiding duplicates in the core, we would like to have your
> feedback about the following options:
>
> 1) to keep r.stream.basins as an add-on, demanding the delineation of
> multiple subbasins from coordinates to a user´s script looping
> r.water.outlet;
> 2) to include r.stream.basins and keep also r.water.outlet;
> 3) to include r.stream.basins in the core and remove r.water.outlet as
> obsolete.
> 4) ?
>
> regards from Vienna
>
> Madi, Helmut
>
> [1] http://grass.osgeo.org/grass70/manuals/addons/r.stream.basins.html
> [2] http://grass.osgeo.org/grass70/manuals/r.water.outlet.html
> [3] http://grass.osgeo.org/grass70/manuals/r.watershed.html
>
>
>
> -----
> best regards
> Helmut
> --
> View this message in context: http://osgeo-org.1560.x6.nabble.com/r-stream-to-trunk-what-about-r-stream-basins-tp5131543.html
> Sent from the Grass - Dev mailing list archive at Nabble.com.
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev


More information about the grass-dev mailing list