<html style="direction: ltr;">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body bidimailui-charset-is-forced="true" style="direction: ltr;"
text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 08/31/2017 11:03 PM, Ken Mankoff
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:B3BE7D14-2DDD-496E-8787-1314692940A7@gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div>Hi Micha,</div>
<div><br>
</div>
<div>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.</div>
</blockquote>
Yes, each pixel gets a single flow direction, one of 8 directions.<br>
<br>
<blockquote type="cite"
cite="mid:B3BE7D14-2DDD-496E-8787-1314692940A7@gmail.com">
<div><br>
</div>
<div>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 </div>
</blockquote>
That can happen only for a single pixel at the very peak of a
mountain. <br>
<blockquote type="cite"
cite="mid:B3BE7D14-2DDD-496E-8787-1314692940A7@gmail.com">
<div>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. <br>
</div>
</blockquote>
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.<br>
<br>
<blockquote type="cite"
cite="mid:B3BE7D14-2DDD-496E-8787-1314692940A7@gmail.com">
<div><br>
</div>
<div>The inefficient method, running r.watershed 14,000 times,
never considers basins and is therefore not impacted by this
issue. <br>
</div>
</blockquote>
Not sure I understand that.<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:B3BE7D14-2DDD-496E-8787-1314692940A7@gmail.com">
<div><br>
-k.
<div><br>
</div>
<div>Please excuse brevity. Sent from pocket computer with tiny
non-haptic feedback keyboard. </div>
</div>
<div><br>
On 31 Aug 2017, at 21:18, Micha Silver <<a
href="mailto:tsvibar@gmail.com" moz-do-not-send="true">tsvibar@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
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. <br>
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.<br>
<br>
<div class="moz-cite-prefix">On 08/31/2017 10:04 PM, Ken
Mankoff wrote:<br>
</div>
<blockquote type="cite"
cite="mid:81312416-5630-44ED-9B5B-EBC2CCF0FE42@gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
<div>Yes. This! What you wrote. </div>
<div><br>
</div>
<div>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?<br>
<br>
-k.
<div><br>
</div>
<div>Please excuse brevity. Sent from pocket computer with
tiny non-haptic feedback keyboard. </div>
</div>
<div><br>
On 31 Aug 2017, at 20:51, Micha Silver <<a
href="mailto:tsvibar@gmail.com" moz-do-not-send="true">tsvibar@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
I'm also not clear what you are asking. But risking a
guess:<br>
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.<br>
<br>
--<br>
Micha<br>
<br>
<div class="moz-cite-prefix">On 08/31/2017 09:30 PM,
Thomas Adams wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGxgkWhJ8PWAh+Av1u5KUcLHvqa5NZZvqx+SQzJ0eVz2h3e-0A@mail.gmail.com">
<div dir="ltr">
<div>
<div>Ken,<br>
<br>
</div>
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...<br>
<br>
</div>
Tom<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Aug 31, 2017 at
2:24 PM, Ken Mankoff <span dir="ltr"><<a
href="mailto:mankoff@gmail.com"
target="_blank" moz-do-not-send="true">mankoff@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="auto">
<div>Hi Tom,</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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). </div>
<div><br>
</div>
<div>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. </div>
<div><br>
-k.
<div><br>
</div>
<div>Please excuse brevity. Sent from
pocket computer with tiny non-haptic
feedback keyboard. </div>
</div>
<div>
<div class="gmail-h5">
<div><br>
On 31 Aug 2017, at 19:59, Thomas Adams
<<a href="mailto:tea3rd@gmail.com"
target="_blank"
moz-do-not-send="true">tea3rd@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>
<div>Ken,<br>
<br>
</div>
I'm confused about what you
are trying to do with
r.watershed, because the
output from the module is:<br>
<br>
accumulation=name <br>
Name for output accumulation
raster map <br>
Number of cells that drain
through each cell <br>
tci=name <br>
Name for output topographic
index ln(a / tan(b)) map <br>
spi=name <br>
Stream power index a * tan(b)
<br>
Name for output raster map <br>
drainage=name <br>
Name for output drainage
direction raster map <br>
basin=name <br>
Name for output basins raster
map <br>
stream=name <br>
Name for output stream
segments raster map <br>
half_basin=name <br>
Name for output half basins
raster map <br>
Each half-basin is given a
unique value <br>
length_slope=name <br>
Name for output slope length
raster map <br>
Slope length and steepness
(LS) factor for USLE <br>
slope_steepness=name <br>
Name for output slope
steepness raster map <br>
Slope steepness (S) factor for
USLE <br>
<br>
</div>
I think you want a hydrologic
model, and r.watershed is NOT
that. What are you trying to
obtain?<br>
<br>
</div>
Tom<br>
<div>
<div><br>
<br>
<br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu,
Aug 31, 2017 at 1:47 PM, Ken
Mankoff <span dir="ltr"><<a
href="mailto:mankoff@gmail.com" target="_blank" moz-do-not-send="true">mankoff@gmail.com</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hi List,
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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 </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div> -k.</div>
</div>
<br>
______________________________<wbr>_________________<br>
grass-user mailing list<br>
<a
href="mailto:grass-user@lists.osgeo.org"
target="_blank"
moz-do-not-send="true">grass-user@lists.osgeo.org</a><br>
<a
href="https://lists.osgeo.org/mailman/listinfo/grass-user"
rel="noreferrer"
target="_blank"
moz-do-not-send="true">https://lists.osgeo.org/mailma<wbr>n/listinfo/grass-user</a><br>
</blockquote>
</div>
<br>
<br>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
grass-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:grass-user@lists.osgeo.org" moz-do-not-send="true">grass-user@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/grass-user" moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/grass-user</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918</pre>
</div>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918</pre>
</div>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918</pre>
</body>
</html>