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.
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 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. The inefficient method, running r.watershed 14,000 times, never considers basins and is therefore not impacted by this issue. -k. Please excuse brevity. Sent from pocket computer with tiny non-haptic feedback keyboard. > On 31 Aug 2017, at 21:18, Micha Silver <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>>>> [email protected] >>>>>>> https://lists.osgeo.org/mailman/listinfo/grass-user >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> grass-user mailing list >>>> [email protected] >>>> 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
_______________________________________________ grass-user mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-user
