[GRASS-user] Repeated r.watershed runs

Ken Mankoff mankoff at gmail.com
Thu Aug 31 13:03:35 PDT 2017


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 <tsvibar at 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 <tsvibar at 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 <mankoff at 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 <tea3rd at 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 <mankoff at 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 at lists.osgeo.org
>>>>>>> https://lists.osgeo.org/mailman/listinfo/grass-user
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> grass-user mailing list
>>>> grass-user at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20170831/19603d35/attachment-0001.html>


More information about the grass-user mailing list