id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,cpu,platform 3756,r.watershed: flow accumulation wrong with edge contamination,itati01,grass-dev@…,"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. ",defect,closed,normal,,Raster,svn-releasebranch76,fixed,"r.watershed, flow accumulation, edge contamination",,Unspecified,Unspecified