[GRASS-dev] r.stream.* to trunk - what about r.stream.basins?
hellik at web.de
Thu Mar 27 05:54:45 PDT 2014
at the Vienna Code Sprint we're discussing moving the r.stream.* -modules to
transition most of the r.stream.* is clear, but there may be some
overlapping between r.water.outlet, r.watershed and r.stream.basins.
- r.water.outlet  generates a watershed basin from a drainage direction
map and a set of coordinates representing the outlet point of watershed.
- r.stream.basins  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
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
- r.watershed :
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
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
regards from Vienna
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.
More information about the grass-dev