Based on what we have discussed (including some off-list), the best shot seems to be using directions based on r.watershed on the carved DEM together with the given (not computed) streams for HAND (streams are also used for the carving and r.lake steps).
An alternative is using streams from r.watershed, but only those which fall into a buffer around the given streams (for more context, see some of my previous emails when I already mentioned this). Getting the directions for a stream, as I suggested, is of course useless except for using it for updating the direction raster which may or may not bring a minor improvement (probably not worth complicating the workflow). Vaclav On Wed, Oct 3, 2018 at 5:46 PM Shane Carey <[email protected]> wrote: > > Hi Vaclav, > > I have checked the output from r.watershed with what you have calculated and I do see differences in the value obtained by both. Could it be a rounding issue perhaps? The only other difference I see is that the output from r.watershed is a complete raster as opposed to just the river network. See image attached to explain what I mean. Does that make any difference? > > > Le gach dea ghui, > Shane Carey > GIS and Data Solutions Consultant > > > On Tue, Oct 2, 2018 at 12:07 PM Shane Carey <[email protected]> wrote: >> >> Ok cool. When I I try to run the r.stream.distance with this new new stream direction layer (that I calculated with r.mapcalc "streams_direction_8 = int((streams_direction + 45) / 45)" ), >> >> it just hangs on the part that says: "caclulating downstream parameters". So I am not sure what is going on here - have you any ideas on this? >> >> Also, could you explain a little about what this expression is doing: (streams_direction + 45) / 45) >> >> Thanks Vaclav >> >> >> Le gach dea ghui, >> Shane Carey >> GIS and Data Solutions Consultant >> >>
_______________________________________________ grass-user mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-user
