<div dir="ltr"><div><div><div><div>Markus,<br><br></div>Thank you very much for you insights; Yes, I have seen significant differences between DEM derived streams and those from other sources. I have not attempted burning the streams into the DEM as Micha suggested. FORTUNATELY, I had a 100m DEM from the USGS that was fine for my uses; so, the problem area that I had was resolved and I did not have to resort to such drastic measures -- it was disheartening to think I might have to resort to that.<br><br></div>So, what's really cool is that I have hydrologically modeled a good size basin (8332 sq km) at a 250 meter grid spacing; all the model parameter estimation was done using GRASS 70, as is the animation of the simulation. I'll be posting it to Vimeo later today. It's the same basin area I did previously that you saw, only the previous one had a much coarser (4km) spatial resolution.<br><br></div>Thanks all!<br><br></div>Tom<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 16, 2015 at 2:42 PM, Markus Metz <span dir="ltr"><<a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, Feb 14, 2015 at 3:45 PM, Thomas Adams <<a href="mailto:tea3rd@gmail.com">tea3rd@gmail.com</a>> wrote:<br>
><br>
</span><span class="">> The reason I need to use the D8 (SFD) algorithm is that I am generating a<br>
> file that identifies how pixels are connected hydraulically; the distributed<br>
> hydrologic model I am using requires that this connectivity be unique; so a<br>
> pixel must be uniquely connected to a single downstream pixel. Consequently,<br>
> with the GRASS scripting I have done to produce the needed ascii output file<br>
> I need, I think I have to use the D8 SFD algorithm.<br>
<br>
</span>The connectivity (drainage output of r.watershed) is always unique, no<br>
matter if you use D8 or MFD. In case of MFD, the predominant direction<br>
is used.<br>
<br>
As Micha said, r.watershed does not produce breaks in flow<br>
accumulation, it stops only at the edge of the current region and at<br>
NULL cells.<br>
<br>
Modifying a DEM to match a river network can be dangerous, I would<br>
recommend to not burn the whole river network into the DEM but modify<br>
only those parts that really need modification. Usually you will never<br>
get a perfect match between a river network created from different<br>
sources and a stream network derived from a DEM.<br>
<br>
Markus M<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Cheers!<br>
> Tom<br>
><br>
><br>
> On Sat, Feb 14, 2015 at 5:02 AM, Micha Silver <<a href="mailto:micha@arava.co.il">micha@arava.co.il</a>> wrote:<br>
>><br>
>> Hi Thomas:<br>
>><br>
>> On 02/13/2015 10:28 PM, Thomas Adams wrote:<br>
>><br>
>> Micha,<br>
>><br>
>> No, after looking at what's going-on in more detail, I think the DEM is<br>
>> too coarse (even at 90m), so the flow direction and accumulation is<br>
>> mis-directed in one critical area of the watershed. I tried using r.carve,<br>
>> but it is taking forever — after 15 minutes, no advancement of the progress<br>
>> bar…<br>
>><br>
>><br>
>> I don't see why carving into a DEM should cause r.watershed to run more<br>
>> slowly, unless you have carved out only a section of some of the streams. If<br>
>> your carving does not continue right to the outlet of the stream (i.e. to an<br>
>> ocean, or to the edge of the region) then r.watershed would actually have to<br>
>> fill in that carved out stream to find a flow path.  That could cause the<br>
>> performance hit.<br>
>><br>
>> Additionally, are you using GRASS 7.0? As you probably know some<br>
>> substantial improvements to the algorithms were introduced in 7 for several<br>
>> modules, r.watershed among them.<br>
>><br>
>> And third, why use the D8 flow direction when MFD is available (again in<br>
>> GRASS 7.0)? That could also be causing what you refer to as breaks in the<br>
>> channels. MFD is especailly good, I believe, in flat areas.<br>
>><br>
>> In any case, Keep up posted on your progress.<br>
>> Thanks,<br>
>> Micha<br>
>><br>
>><br>
>> I did not want to have to do this for my testing, but I'll probably try at<br>
>> 3 or 10 meter — lots of pixels for my basin! The problem, in general, for me<br>
>> is that I want to apply my techniques at international locations where I<br>
>> probably won't have the benefit of higher resolution DEMs, so I need to<br>
>> develop something a bit more robust…<br>
>><br>
>> Cheers!<br>
>> Tom<br>
>><br>
>> On Fri, Feb 13, 2015 at 1:15 PM, Micha Silver <<a href="mailto:micha@arava.co.il">micha@arava.co.il</a>> wrote:<br>
>>><br>
>>><br>
>>> On 02/13/2015 08:48 PM, Thomas Adams wrote:<br>
>>><br>
>>> Stefan,<br>
>>><br>
>>> A fair question; since I know the stream topology from personal<br>
>>> experience it is clear that there should be no break in the stream network<br>
>>> and the flow accumulation grid should reflect that. I am seeing the flow<br>
>>> accumulation values break at a point where they should continue to<br>
>>> accumulate downstream.<br>
>>><br>
>>><br>
>>> Are these breaks possibly caused by null pixels in the DEM?<br>
>>><br>
>>> Tom<br>
>>><br>
>>> On Fri, Feb 13, 2015 at 11:43 AM, Stefan Lüdtke <<a href="mailto:sluedtke@gfz-potsdam.de">sluedtke@gfz-potsdam.de</a>><br>
>>> wrote:<br>
>>>><br>
>>>> -----BEGIN PGP SIGNED MESSAGE-----<br>
>>>> Hash: SHA1<br>
>>>><br>
>>>> Hi Tom,<br>
>>>><br>
>>>> just out of curiosity, what do you mean by "break in the flow<br>
>>>> accumulation"?<br>
>>>><br>
>>>> Cheers,<br>
>>>><br>
>>>> Stefan<br>
>>>><br>
>>>> On 02/13/2015 07:12 PM, Thomas Adams wrote:<br>
>>>> > Hello all!<br>
>>>> ><br>
>>>> > I'm making use of the flow accumulation grid in GRASS 6.4.5<br>
>>>> > generated from r.watershed using the SFD (D8) flow algorithm. The<br>
>>>> > DEM has a 250m spatial resolution. What I'm getting is a break in<br>
>>>> > the flow accumulation in a few locations which is causing me<br>
>>>> > serious problems with subsequent processing (with help from some<br>
>>>> > here, I have put together some scripting to generate a pixel<br>
>>>> > connectivity file for a distributed hydrologic model).<br>
>>>> ><br>
>>>> > Besides going to a higher resolution DEM, are there any thoughts as<br>
>>>> > to how I can eliminate these flow accumulation breaks?<br>
>>>> ><br>
>>>> > Thank you, Tom<br>
>>>> ><br>
>>>> > --<br>
>>>> ><br>
>>>> ><br>
>>>> ><br>
>>>> > _______________________________________________ grass-user mailing<br>
>>>> > list <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
>>>> > <a href="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
>>>> ><br>
>>>><br>
>>>> - --<br>
>>>> Stefan Lüdtke<br>
>>>><br>
>>>> Section 5.4-  Hydrology<br>
>>>> Tel.: <a href="tel:%2B49%20331%20288%202821" value="+493312882821">+49 331 288 2821</a><br>
>>>> Fax: <a href="tel:%2B49%20331%20288%201570" value="+493312881570">+49 331 288 1570</a><br>
>>>> Email: <a href="mailto:sluedtke@gfz-potsdam.de">sluedtke@gfz-potsdam.de</a><br>
>>>><br>
>>>> Helmholtz-Zentrum Potsdam<br>
>>>> Deutsches GeoForschungsZentrum GFZ<br>
>>>> (GFZ German Research Centre for Geoscience)<br>
>>>> Stiftung des öff. Rechts Land Brandenburg<br>
>>>> Telegrafenberg, 14473 Potsdam<br>
>>>> - -------------------<br>
>>>><br>
>>>> PGP Public Key: <a href="http://bit.ly/13d9Sca" target="_blank">http://bit.ly/13d9Sca</a><br>
>>>> -----BEGIN PGP SIGNATURE-----<br>
>>>> Version: GnuPG v1.4.11 (GNU/Linux)<br>
>>>><br>
>>>> iQEcBAEBAgAGBQJU3kXYAAoJEB5GAbKcg+D8YqMH/jgJZ70cz69IJal6ICi66wqW<br>
>>>> lQYnnko592KAOlFDu1lReZhWWVgeA59rDsYA2Gg/rBzoL9Nst3hzIJDWqnhIWl3W<br>
>>>> YgF/vOJgTRnrNJtOibGpOc8hxrHwElxU7afYlXU8Zk+4tXdZRK4/vrQ4tKEcbY0z<br>
>>>> MrhAYjR66RRpoNf9/3WJ3s14CpPA+KEkOaysOOoTV6Ni7qZTK8rVxt+svQQoPtW+<br>
>>>> 5QwRJLkLeM6bUrqfQifHis91j4k3JSoSp7ZjIInKwi1tvCSfcFQhzvANs4x8e1Lo<br>
>>>> Q5wDbzHshhJieGKyraUZyT8cn9vszv9cm2Sf49O/0FWVz3Eyc9vsKFxVcvfEb1E=<br>
>>>> =Sy/3<br>
>>>> -----END PGP SIGNATURE-----<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>><br>
>>><br>
>>><br>
>>> This mail was received via Mail-SeCure System.<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> grass-user mailing list<br>
>>> <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
>>> <a href="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
>>> This mail was received via Mail-SeCure System.<br>
>>><br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> This mail was received via Mail-SeCure System.<br>
>><br>
>><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> grass-user mailing list<br>
> <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
</div></div></blockquote></div><br><br><div><br></div>
</div></div>