Re: [GRASS-user] Repeated r.watershed runs

[Micha Silver]

On 08/31/2017 11:03 PM, Ken Mankoff wrote: Hi Micha, I understand what you wrote (I think). I get that the basin product from r.watershed does not change with SFD or MFD. I think this is because the flow direction raster from r.watershed only provides the primary flow direction. Yes, each pixel gets a single flow direction, one of 8 directions. But the accumulation map doesn't know about boundaries or basins, does it? At a divide, can water can flow equally in all 8 directions? If so, I think that at the boundary of the basin delineated by That can happen only for a single pixel at the very peak of a mountain. r.water.outlet there may be a cell that contributed 49%. The flow direction would show this cell flows away from the basin boundary because 51% of it does do that, so it is not in the basin. If I use this basin as a mask, I'm losing 49% of that cell, and the many upstream cells that contribute to it. You won't have many upstream cells for those cells along the basin boundary, only the few that drain exactly along the watershed divide. And these cells will eventually become part of one basin or the other. So I guess theoretically you could "loose" some flow accumulation: 49% of the drainage from those few cells right along the watershed divide. But this would be an accurate representation of reality, since that 49% is actually not part of the basin you're investigating. The inefficient method, running r.watershed 14,000 times, never considers basins and is therefore not impacted by this issue. Not sure I understand that. The only way that r.watershed can return different results is if you input a different elevation grid. The r.watershed module is strictly a geo-morphological analysis - nothing to do with real runoff, only the terrain, slopes, flow direction, etc. It creates a theoretical model of where runoff would go. The only situation that I can envision where you would rerun r.watershed is when massive earthwork was done, and you have a new/revised elevation dataset.   -k.  Please excuse brevity. Sent from pocket computer with tiny non-haptic feedback keyboard.  On 31 Aug 2017, at 21:18, Micha Silver <tsvi...@gmail.com> wrote: The r.water.outlet module takes as input a flow direction raster that needs to be created first by r.watershed. So the SFD/MFD question is irrelevant at this stage. When you first ran r.watershed you chose which method to use for determining flow direction for each pixel. Further, SFD/MFD influences only the stream routing, not the total number of cells in the basin. I'm pretty sure that if you run r.watershed once with MFD and again with SFD, you'll get the same basin, only with slightly different stream networks. AFAIK there should never be a situation where water is directed out of the basin. So all cells that flow into cell C are then directed downstream to your final drainage point. On 08/31/2017 10:04 PM, Ken Mankoff wrote: Yes. This! What you wrote.  But the issue is that r.water.outlet make basins based on SFD, right? What if there are 10,000 cells that feed into cell C at x,y, and then cell C feeds 49% (based on MFD) into the basin. These 10,000 cells are not included in the r.water.outlet basin, are they?   -k.  Please excuse brevity. Sent from pocket computer with tiny non-haptic feedback keyboard.  On 31 Aug 2017, at 20:51, Micha Silver <tsvi...@gmail.com> wrote: I'm also not clear what you are asking. But risking a guess: You could run r.water.outlet *1 time* to get the basin. Then use that raster as a MASK, so that the next process will address only the pixels within the basin. Now do a loop with r.univar on all 14,000 flow rasters, and you'll get 14,000 results with total, min, max, mean, etc of the basin pixels for each of the flow rasters. -- Micha On 08/31/2017 09:30 PM, Thomas Adams wrote: Ken, You "want 14,000 values" of what?? Your original email stated you were "trying to determine flow past a drainage basin outlet" -- r.watershed does NOT do this, if indeed this is what you want. And you say you have "14,000 flow rasters to be used as input" -- what exactly are these 'flow rasters'; what is your goal? I may not understand... Tom On Thu, Aug 31, 2017 at 2:24 PM, Ken Mankoff <mank...@gmail.com> wrote: Hi Tom, I have 1 DEM and 14,000 flow rasters to be used as input. I want 14,000 values, one at a specific coordinate from each acc output.  I can do this by running r.watershed 14,000 times. That is slow, unless I'm missing something (e.g. It works with I.group variables or Time Series data more efficiently).  An alternative approach is possible if I knew the complete drainage basin *and* the fractional value of each cell that contributed to the basin. In this case I don't need to route. But basins from r.watershed or r.water.outlet, I think, use SFD not MFD (no cell is ever in 2 basins, are they?), and I don't know how to get the fractional contribution from each cell.    -k.  Please excuse brevity. Sent from pocket computer with tiny non-haptic feedback keyboard.  On 31 Aug 2017, at 19:59, Thomas Adams <tea...@gmail.com> wrote: Ken, I'm confused about what you are trying to do with r.watershed, because the output from the module is: accumulation=name Name for output accumulation raster map Number of cells that drain through each cell tci=name Name for output topographic index ln(a / tan(b)) map spi=name Stream power index a * tan(b) Name for output raster map drainage=name Name for output drainage direction raster map basin=name Name for output basins raster map stream=name Name for output stream segments raster map half_basin=name Name for output half basins raster map Each half-basin is given a unique value length_slope=name Name for output slope length raster map Slope length and steepness (LS) factor for USLE slope_steepness=name Name for output slope steepness raster map Slope steepness (S) factor for USLE I think you want a hydrologic model, and r.watershed is NOT that. What are you trying to obtain? Tom On Thu, Aug 31, 2017 at 1:47 PM, Ken Mankoff <mank...@gmail.com> wrote: Hi List, I'm trying to determine flow past a drainage basin outlet. The complicating factor is that I need to do this each day for 40 years. If I do "r.watershed" ~14,000 times I'll get the results, but it will take 3 days. It seems that r.watershed is likely calculating many things each time through the loop. Is there a more efficient way to this? A flag to r.watershed that isn't documented? Something with time-series? Alternatively, because I only need the flow at the outlet, I could calculate the basin, not route the flow, and instead sum the values in the basin. I assume this would take seconds or minutes rather than days. In this case I'm not sure of the best way to define the basin. I tried doing r.water.outlet upstream from the outlet, but I think this uses SFD, which means the basin may be significantly underestimated. I also tried inverting/flipping the DEM and then running r.watershed with convergence=1, and a flow equal to 0 everywhere except 1000 at the outlet (now the source due to the inversion) to see where it flooded upstream (now downstream due to the inversion). This didn't seem to work... because basins are filled and flow routes to the edge of the DEM, I could not pick out the  Any advice how to either a) efficiently route 14,000 FLOW rasters over 1 DEM or b) determine the full basin will be much appreciated. Thanks,     -k. _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user