Issues with vectorisation of thinned flow accumulation through r.to.vect on QGIS

Question

I'm trying to produce a shapefile river network from a flow accumulation raster using the r.to.vect function and I've overcome some difficulties regarding bit depth and thinned raster.

n.b. I don't have the original DEM from which the flow accumulation raster was derived, so I can't rely on the Channel Network and Drainage Basins function.

My objective is to obtain a river network with the 'upcells' value of the old HydroSHEDS river network dataset but my result presents some issues that I didn't find a way to solve in an automatic way:

Here we have a thinned boolean raster and the resulted line vector.

1. The first issue is the ambiguity between adjacent cells (red circle) that makes the r.to.vect create redundant lines;
2. The second issue occurs when there is a right angle between cells, but only in the horizontal/vertical direction (blue circle). In this case, the r.to.vect function splits the lines close to these right angles, as we see from the 'id' label (the element 758 is split from element 755, likewise the element 759 is split from element 764, but this doesn't occur for element 764).

The second issue affects the next step of my workflow when I'm going to use v.rast.stats to assign for each feature the maximum value of the flow accumulation map raster. This is the result:

The line vectors are now graduated based on the flow accumulation value (red labels) but the v.rast.stats can't compute statistics for some of these short segments generated by the second issue (elements 759 and 794; the element 799 is not relevant because is redundant)

I've tried some optional configurations of the r.to.vect function but it doesn't seem able to handle these two issues.

Is there a way to overcome them in an automatic/semi-automatic way?

Answer 1

Since you tagged the question also with GRASS, I would point out that neither of these problems occur when delineating stream networks using the r.watershed module in GRASS. That module uses multi-flow direction (MFD) to determine flow direction, thus avoiding the splits in the red circle. And I've never seen a stream reach get split in the middle as you show in the blue circle.

Lacking the original DEM, you might try to buffer the streams by a distance enough to remove the "red" ambiguity, then "unbuffer" (buffer with negative the same distance) to restore the lines.