#3756: r.watershed: flow accumulation wrong with edge contamination
-------------------------------------------------+-------------------------
Reporter: itati01 | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Raster | Version: svn-
Keywords: r.watershed, flow accumulation, | releasebranch76
edge contamination | CPU: Unspecified
Platform: Unspecified |
-------------------------------------------------+-------------------------
Dear developers,
I compared the results of the flow accumulation (=facc) in the independent
Python module ''pysheds'' to '''r.watershed''' with the '''flag -a'''. The
input of ''pysheds'' was the flow direction (=fdr, D8) created by
'''r.watershed''', so the resulting rasters should be identical.
The difference in facc (=pysheds - r.watershed) is zero for most of the
raster, except for raster cells affected by edge contamination where
''pysheds'' overestimates facc compared to r.watershed. At first, I
suspected an error in the much younger pysheds, however r.watershed seems
to be the culprit.
Note: The catchment I use is crossed by a channel, which in turn is
crossed by streams. I removed this channel by setting the DEM to nodata
except for the crossings + some buffer. So, I cannot exclude edge-
contaminated cells.
Small differences are along the majority of the nodata values and they
increase downstream. The source of the problem could be a) a mis-
interpretation of negative fdr or b) wrong facc in case of edge
contamination (or unexpected behaviour). For ''pysheds'', I assumed that
the absolute value indicates the direction and the negative sign indicates
edge contamination. I was puzzled about the output of '''d.rast.arrow
type=drainage''': the arrows are shifted, e.g. -2 was identical to +1 not
+2. Also tested it with ''pysheds'' to no avail.
(By the way, the output of '''d.rast.arrow''' looks wrong, e.g. the red
rectangles in figure 1. If someone confirms this error, I can open a
separate ticket for this issue. The error in '''d.rast.arrow''' would be
here:
{{{
if (...map_type == 5) {
...
aspect_c = (int)(aspect_f + 0.5);
}
}}}
).
Most likely it is about the cumulation of negative values. Take the
rectangle in figure 2 as an example. It contains raster cells 1-9, I am
counting row-wise starting with the top left cell. One route is 8 + 9 -> 6
+ 1 -> 2 -> Channel in blue. ''Pyshed'' produces what I expect: facc == 3
for cell6 and facc == 5 for cell2, while '''r.watershed''' calculates for
all cells +1, or -1 without the flag -a.
The reason is presumably: cells 8, 9 and 1 are edge contaminated (i.e.
facc is turned to -1). So, for cell 6: facc = -1 + -1 + 1 = -1 (1 is the
default weight for all cells). The calculation for cell 2 is identical.
I suggest to ''subtract'' not to ''add'' the weights in case of edge-
contaminated upslope cells.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3756>
GRASS GIS <https://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
