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

GRASS GIS GRASS GIS developer
1

hi,

at the Vienna Code Sprint we're discussing moving the r.stream.* -modules to
trunk.

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.

2

Hi Folks,

···

I very much appreciate the efforts in the code sprint this week!

On Thu, Mar 27, 2014 at 8:54 AM, Helmut Kudrnovsky <hellik@web.de> wrote:

  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

If r.stream.basins can replicate the functionality of r.water.outlet, I would prefer 3 . Some argument might be made for a conservative approach for option 2 for version 7.0 and drop r.water.outlet in version 7.1, but 7.0 is in development status. Why not make the change now?

Doug

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@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.

3

On 27/03/14 14:08, Newcomb, Doug wrote:

Hi Folks,

I very much appreciate the efforts in the code sprint this week!

On Thu, Mar 27, 2014 at 8:54 AM, Helmut Kudrnovsky <hellik@web.de
<mailto:hellik@web.de>> wrote:

    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

If r.stream.basins can replicate the functionality of r.water.outlet, I
would prefer 3 . Some argument might be made for a conservative
approach for option 2 for version 7.0 and drop r.water.outlet in version
7.1, but 7.0 is in development status. Why not make the change now?

As long as results are identical, +1. If not, this should be explored further.

Moritz

4

Hi,

···

On Thu, Mar 27, 2014 at 2:20 PM, Moritz Lennert <mlennert@club.worldonline.be> wrote:

On 27/03/14 14:08, Newcomb, Doug wrote:

  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

If r.stream.basins can replicate the functionality of r.water.outlet, I
would prefer 3 . Some argument might be made for a conservative
approach for option 2 for version 7.0 and drop r.water.outlet in version
7.1, but 7.0 is in development status. Why not make the change now?

As long as results are identical, +1. If not, this should be explored further.

I reproduced the example given in the manual page (NC dataset) of r.water.outlet using r.stream.basin:

g.region rast=elev_lid792_1m -p


```
r.watershed elev_lid792_1m thresh=5000 accum=accum_5K drain=draindir_5K basin=basin_5K
r.water.outlet input=draindir_5K output=basin_A30 coord=638740.423248,220271.519225
```

```
r.stream.basins dirs=draindir_5K@testing coors=638740.423248,220271.519225 basins=basin_rstreambasins

```

```
r.mapcalc expression="diff=basin_rstreambasins-basin_A30"

```

```
[r.info](http://r.info) diff
 +----------------------------------------------------------------------------+
 | Layer:    diff                           Date: Thu Mar 27 14:34:25 2014    |
 | Mapset:   testing                        Login of Creator: madi            |
 | Location: nc_spm_08                                                        |
 | DataBase: /home/madi/grassdata                                             |
 | Title:     ( diff )                                                        |
 | Timestamp: none                                                            |
 |----------------------------------------------------------------------------|
 |                                                                            |
 |   Type of Map:  raster               Number of Categories: 0               |
 |   Data Type:    CELL                                                       |
 |   Rows:         750                                                        |
 |   Columns:      700                                                        |
 |   Total Cells:  525000                                                     |
 |        Projection: Lambert Conformal Conic                                 |
 |            N:     220750    S:     220000   Res:     1                     |
 |            E:     639000    W:     638300   Res:     1                     |
 |   Range of data:    min = 0  max = 0                                       |
 |                                                                            |
 |   Data Description:                                                        |
 |    generated by r.mapcalc                                                  |
 |                                                                            |
 |   Comments:                                                                |
 |    basin_rstreambasins - basin_A30                                         |
 |                                                                            |
 +----------------------------------------------------------------------------+

```

Best regards,
madi

```

```

```

```

–

Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

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

Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission.

5

On Thu, Mar 27, 2014 at 1:54 PM, Helmut Kudrnovsky <hellik@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

6

On 4/6/14, Markus Metz <markus.metz.giswork@gmail.com> wrote:

...because the results of the all-in-RAM and the
external-memory mode are not identical.

Are both wrong?

markusN

7

Hi Markus,

2014-04-06 15:52 GMT+02:00 Markus Metz <markus.metz.giswork@gmail.com>:

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

?

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.

I would say that better would be to keep them activated in trunk. At
least for testing on Windows. When I was doing minor clean-up of this
modules (messages, out-dated code) in Vienna I discovered that there
is quite huge code duplication across several of these module. It
would make sense to think probably about internal library for these
modules.

Martin

8

Hi Markus,

2014-04-06 15:52 GMT+02:00 Markus Metz <markus.metz.giswork@gmail.com>:

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.

do you agree to remove r.stream.* modules (with one exception
r.stream.extract) from release branch 70?

Martin

9

Markus Metz wrote:

IMHO, the modules should also be disabled in trunk,

I'm not a fan of having disabled code in trunk.

Code which isn't being compiled will be overlooked when API changes
(or build system changes, etc) are made, and will start to suffer from
bit-rot.

If compilation generates errors, that serves as a reminder to do
something about it.

If you're worried about people trusting a module's output, add a
G_warning().

--
Glynn Clements <glynn@gclements.plus.com>