[GRASS-dev] [GRASS GIS] #2719: r.watershed + D8 (unexpected results)

#2719: r.watershed + D8 (unexpected results)
--------------------+-------------------------
Reporter: 180875 | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone:
Component: Raster | Version: unspecified
Keywords: | CPU: x86-64
Platform: Linux |
--------------------+-------------------------
Dear GRASS Gurus,

During the last days I've discovered a strange behaviour of r.watershed
and D8. The used DEM is the result from a landscape evolution model and
there are no depressions. I cannot use MFD as the D8-FlowDirections input
data of a variety of tools I’ve written during the last years.

I got obviously wrong values for the flow accumulation of r.watershed and
D8. The number of cells in the Flow Accumulation grid at the outlet point
was significantly smaller than the area of the analyzed catchment (spatial
resolution in north south and east west direction is 1) also computed with
GRASS using r.water.outlet and a conversion to Vector (Area).
I checked Flow Accumulation at the the outlet with an alternative code of
a colleague and the contributing drainage area was exactly the value of
the catchment size computed with r.water.outlet.

I further found some deviations in the flow direction grid. In some cases
the flow routing leads to the lowest neighbouring cell which however might
not be the steepest decent. r.watershed chooses sometimes a diagonal flow
direction while the local channel gradient would be greater in horizontal
direction.
I started some test runs with very simple geometries. I've defined a ramp
with r.mapcalc that dips in north direction and I expected that this will
also be shown by the flow direction of r.watershed. However, this is not
the case. The synthetic DEM features a watershed!!! See attachment. It
seems that r.watershed fills the region (without need). This strange
behavior disappears by applying the "multiple flow direction" algorithm.

I have tested with the latest versions grass70 , grass71 and grass645.
Here is a test simple test case (grass71) that documents the misbehavior
of r.watershed and D8.
g.region w=0 e=1000 s=0 n=1000 res=1 -p
r.mapcalc "DEM = 1000 - y()"
r.watershed -s elevation=DEM@PERMANENT accumulation=ACC drainage=DIR

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2719&gt;
GRASS GIS <https://grass.osgeo.org>

#2719: r.watershed + D8 (unexpected results)
---------------------+-------------------------
  Reporter: 180875 | Owner: grass-dev@…
      Type: defect | Status: new
  Priority: normal | Milestone:
Component: Raster | Version: unspecified
Resolution: | Keywords:
       CPU: x86-64 | Platform: Linux
---------------------+-------------------------
Changes (by 180875):

* Attachment "acc.png" added.

Flow Accumulation of the case (ramp)

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2719&gt;
GRASS GIS <https://grass.osgeo.org>

#2719: r.watershed + D8 (unexpected results)
---------------------+-------------------------
  Reporter: 180875 | Owner: grass-dev@…
      Type: defect | Status: new
  Priority: normal | Milestone: 7.0.1
Component: Raster | Version: unspecified
Resolution: | Keywords: r.watershed
       CPU: x86-64 | Platform: Linux
---------------------+-------------------------
Changes (by martinl):

* keywords: => r.watershed
* milestone: => 7.0.1

Old description:

Dear GRASS Gurus,

During the last days I've discovered a strange behaviour of r.watershed
and D8. The used DEM is the result from a landscape evolution model and
there are no depressions. I cannot use MFD as the D8-FlowDirections input
data of a variety of tools I’ve written during the last years.

I got obviously wrong values for the flow accumulation of r.watershed and
D8. The number of cells in the Flow Accumulation grid at the outlet point
was significantly smaller than the area of the analyzed catchment
(spatial resolution in north south and east west direction is 1) also
computed with GRASS using r.water.outlet and a conversion to Vector
(Area).
I checked Flow Accumulation at the the outlet with an alternative code of
a colleague and the contributing drainage area was exactly the value of
the catchment size computed with r.water.outlet.

I further found some deviations in the flow direction grid. In some cases
the flow routing leads to the lowest neighbouring cell which however
might not be the steepest decent. r.watershed chooses sometimes a
diagonal flow direction while the local channel gradient would be greater
in horizontal direction.
I started some test runs with very simple geometries. I've defined a ramp
with r.mapcalc that dips in north direction and I expected that this will
also be shown by the flow direction of r.watershed. However, this is not
the case. The synthetic DEM features a watershed!!! See attachment. It
seems that r.watershed fills the region (without need). This strange
behavior disappears by applying the "multiple flow direction" algorithm.

I have tested with the latest versions grass70 , grass71 and grass645.
Here is a test simple test case (grass71) that documents the misbehavior
of r.watershed and D8.
g.region w=0 e=1000 s=0 n=1000 res=1 -p
r.mapcalc "DEM = 1000 - y()"
r.watershed -s elevation=DEM@PERMANENT accumulation=ACC drainage=DIR

New description:

Dear GRASS Gurus,

During the last days I've discovered a strange behaviour of r.watershed
and D8. The used DEM is the result from a landscape evolution model and
there are no depressions. I cannot use MFD as the D8-FlowDirections input
data of a variety of tools I’ve written during the last years.

I got obviously wrong values for the flow accumulation of r.watershed and
D8. The number of cells in the Flow Accumulation grid at the outlet point
was significantly smaller than the area of the analyzed catchment (spatial
resolution in north south and east west direction is 1) also computed with
GRASS using r.water.outlet and a conversion to Vector (Area).
I checked Flow Accumulation at the the outlet with an alternative code of
a colleague and the contributing drainage area was exactly the value of
the catchment size computed with r.water.outlet.

I further found some deviations in the flow direction grid. In some cases
the flow routing leads to the lowest neighbouring cell which however might
not be the steepest decent. r.watershed chooses sometimes a diagonal flow
direction while the local channel gradient would be greater in horizontal
direction.
I started some test runs with very simple geometries. I've defined a ramp
with r.mapcalc that dips in north direction and I expected that this will
also be shown by the flow direction of r.watershed. However, this is not
the case. The synthetic DEM features a watershed!!! See attachment. It
seems that r.watershed fills the region (without need). This strange
behavior disappears by applying the "multiple flow direction" algorithm.

I have tested with the latest versions grass70 , grass71 and grass645.
Here is a test simple test case (grass71) that documents the misbehavior
of r.watershed and D8.

{{{
g.region w=0 e=1000 s=0 n=1000 res=1 -p
r.mapcalc "DEM = 1000 - y()"
r.watershed -s elevation=DEM@PERMANENT accumulation=ACC drainage=DIR
}}}

--

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2719#comment:1&gt;
GRASS GIS <https://grass.osgeo.org>

#2719: r.watershed + D8 (unexpected results)
---------------------+-------------------------
  Reporter: 180875 | Owner: grass-dev@…
      Type: defect | Status: new
  Priority: normal | Milestone: 7.0.3
Component: Raster | Version: svn-trunk
Resolution: | Keywords: r.watershed
       CPU: x86-64 | Platform: Linux
---------------------+-------------------------
Changes (by neteler):

* version: unspecified => svn-trunk
* milestone: 7.0.1 => 7.0.3

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2719#comment:2&gt;
GRASS GIS <https://grass.osgeo.org>

#2719: r.watershed + D8 (unexpected results)
---------------------+-------------------------
  Reporter: 180875 | Owner: grass-dev@…
      Type: defect | Status: new
  Priority: normal | Milestone: 7.0.3
Component: Raster | Version: svn-trunk
Resolution: | Keywords: r.watershed
       CPU: x86-64 | Platform: Linux
---------------------+-------------------------

Comment (by mmetz):

Replying to [ticket:2719 180875]:
> Dear GRASS Gurus,
>
> During the last days I've discovered a strange behaviour of r.watershed
and D8. The used DEM is the result from a landscape evolution model and
there are no depressions. I cannot use MFD as the D8-FlowDirections input
data of a variety of tools I’ve written during the last years.
>
> I got obviously wrong values for the flow accumulation of r.watershed
and D8. The number of cells in the Flow Accumulation grid at the outlet
point was significantly smaller than the area of the analyzed catchment
(spatial resolution in north south and east west direction is 1) also
computed with GRASS using r.water.outlet and a conversion to Vector
(Area).
> I checked Flow Accumulation at the the outlet with an alternative code
of a colleague and the contributing drainage area was exactly the value of
the catchment size computed with r.water.outlet.

This could only happen if the catchment is not fully covered by the DEM.
In this case, edge cells are not contributing to the catchment because for
edge cells it is not possible to say where the drain to.
>
> I further found some deviations in the flow direction grid. In some
cases the flow routing leads to the lowest neighbouring cell which however
might not be the steepest decent. r.watershed chooses sometimes a diagonal
flow direction while the local channel gradient would be greater in
horizontal direction.
> I started some test runs with very simple geometries. I've defined a
ramp with r.mapcalc that dips in north direction and I expected that this
will also be shown by the flow direction of r.watershed. However, this is
not the case. The synthetic DEM features a watershed!!! See attachment.
It seems that r.watershed fills the region (without need). This strange
behavior disappears by applying the "multiple flow direction" algorithm.
>
> I have tested with the latest versions grass70 , grass71 and grass645.
> Here is a test simple test case (grass71) that documents the misbehavior
of r.watershed and D8.
>
> {{{
> g.region w=0 e=1000 s=0 n=1000 res=1 -p
> r.mapcalc "DEM = 1000 - y()"
> r.watershed -s elevation=DEM@PERMANENT accumulation=ACC drainage=DIR
> }}}

The correction for diagonal flow bias missed two special cases. Fixed in
trunk r67189, please test.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2719#comment:3&gt;
GRASS GIS <https://grass.osgeo.org>

#2719: r.watershed + D8 (unexpected results)
---------------------+-------------------------
  Reporter: 180875 | Owner: grass-dev@…
      Type: defect | Status: new
  Priority: normal | Milestone: 7.0.3
Component: Raster | Version: svn-trunk
Resolution: | Keywords: r.watershed
       CPU: x86-64 | Platform: Linux
---------------------+-------------------------

Comment (by mlennert):

Replying to [comment:3 mmetz]:
> Replying to [ticket:2719 180875]:
> > I further found some deviations in the flow direction grid. In some
cases the flow routing leads to the lowest neighbouring cell which however
might not be the steepest decent. r.watershed chooses sometimes a diagonal
flow direction while the local channel gradient would be greater in
horizontal direction.
> > I started some test runs with very simple geometries. I've defined a
ramp with r.mapcalc that dips in north direction and I expected that this
will also be shown by the flow direction of r.watershed. However, this is
not the case. The synthetic DEM features a watershed!!! See attachment.
It seems that r.watershed fills the region (without need). This strange
behavior disappears by applying the "multiple flow direction" algorithm.
> >
> > I have tested with the latest versions grass70 , grass71 and grass645.
> > Here is a test simple test case (grass71) that documents the
misbehavior of r.watershed and D8.
> >
> > {{{
> > g.region w=0 e=1000 s=0 n=1000 res=1 -p
> > r.mapcalc "DEM = 1000 - y()"
> > r.watershed -s elevation=DEM@PERMANENT accumulation=ACC drainage=DIR
> > }}}
>
> The correction for diagonal flow bias missed two special cases. Fixed in
trunk r67189, please test.

I tested with above test case and the results now seem coherent (i.e.
homogenous direction and accumulation from top to bottom).

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2719#comment:4&gt;
GRASS GIS <https://grass.osgeo.org>

#2719: r.watershed + D8 (unexpected results)
----------------------+-------------------------
  Reporter: 180875 | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: normal | Milestone: 7.0.7
Component: Raster | Version: svn-trunk
Resolution: invalid | Keywords: r.watershed
       CPU: x86-64 | Platform: Linux
----------------------+-------------------------
Changes (by martinl):

* status: new => closed
* resolution: => invalid

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2719#comment:10&gt;
GRASS GIS <https://grass.osgeo.org>