Re: [GRASS-user] Question about r.watershed and flow accumulation grid
On Sat, Feb 14, 2015 at 3:45 PM, Thomas Adams tea...@gmail.com wrote: The reason I need to use the D8 (SFD) algorithm is that I am generating a file that identifies how pixels are connected hydraulically; the distributed hydrologic model I am using requires that this connectivity be unique; so a pixel must be uniquely connected to a single downstream pixel. Consequently, with the GRASS scripting I have done to produce the needed ascii output file I need, I think I have to use the D8 SFD algorithm. The connectivity (drainage output of r.watershed) is always unique, no matter if you use D8 or MFD. In case of MFD, the predominant direction is used. As Micha said, r.watershed does not produce breaks in flow accumulation, it stops only at the edge of the current region and at NULL cells. Modifying a DEM to match a river network can be dangerous, I would recommend to not burn the whole river network into the DEM but modify only those parts that really need modification. Usually you will never get a perfect match between a river network created from different sources and a stream network derived from a DEM. Markus M Cheers! Tom On Sat, Feb 14, 2015 at 5:02 AM, Micha Silver mi...@arava.co.il wrote: Hi Thomas: On 02/13/2015 10:28 PM, Thomas Adams wrote: Micha, No, after looking at what's going-on in more detail, I think the DEM is too coarse (even at 90m), so the flow direction and accumulation is mis-directed in one critical area of the watershed. I tried using r.carve, but it is taking forever — after 15 minutes, no advancement of the progress bar… I don't see why carving into a DEM should cause r.watershed to run more slowly, unless you have carved out only a section of some of the streams. If your carving does not continue right to the outlet of the stream (i.e. to an ocean, or to the edge of the region) then r.watershed would actually have to fill in that carved out stream to find a flow path. That could cause the performance hit. Additionally, are you using GRASS 7.0? As you probably know some substantial improvements to the algorithms were introduced in 7 for several modules, r.watershed among them. And third, why use the D8 flow direction when MFD is available (again in GRASS 7.0)? That could also be causing what you refer to as breaks in the channels. MFD is especailly good, I believe, in flat areas. In any case, Keep up posted on your progress. Thanks, Micha I did not want to have to do this for my testing, but I'll probably try at 3 or 10 meter — lots of pixels for my basin! The problem, in general, for me is that I want to apply my techniques at international locations where I probably won't have the benefit of higher resolution DEMs, so I need to develop something a bit more robust… Cheers! Tom On Fri, Feb 13, 2015 at 1:15 PM, Micha Silver mi...@arava.co.il wrote: On 02/13/2015 08:48 PM, Thomas Adams wrote: Stefan, A fair question; since I know the stream topology from personal experience it is clear that there should be no break in the stream network and the flow accumulation grid should reflect that. I am seeing the flow accumulation values break at a point where they should continue to accumulate downstream. Are these breaks possibly caused by null pixels in the DEM? Tom On Fri, Feb 13, 2015 at 11:43 AM, Stefan Lüdtke slued...@gfz-potsdam.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tom, just out of curiosity, what do you mean by break in the flow accumulation? Cheers, Stefan On 02/13/2015 07:12 PM, Thomas Adams wrote: Hello all! I'm making use of the flow accumulation grid in GRASS 6.4.5 generated from r.watershed using the SFD (D8) flow algorithm. The DEM has a 250m spatial resolution. What I'm getting is a break in the flow accumulation in a few locations which is causing me serious problems with subsequent processing (with help from some here, I have put together some scripting to generate a pixel connectivity file for a distributed hydrologic model). Besides going to a higher resolution DEM, are there any thoughts as to how I can eliminate these flow accumulation breaks? Thank you, Tom -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user - -- Stefan Lüdtke Section 5.4- Hydrology Tel.: +49 331 288 2821 Fax: +49 331 288 1570 Email: slued...@gfz-potsdam.de Helmholtz-Zentrum Potsdam Deutsches GeoForschungsZentrum GFZ (GFZ German Research Centre for Geoscience) Stiftung des öff. Rechts Land Brandenburg Telegrafenberg, 14473 Potsdam - --- PGP Public Key: http://bit.ly/13d9Sca -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJU3kXYAAoJEB5GAbKcg+D8YqMH/jgJZ70cz69IJal6ICi66wqW lQYnnko592KAOlFDu1lReZhWWVgeA59rDsYA2Gg/rBzoL9Nst3hzIJDWqnhIWl3W
Re: [GRASS-user] Question about r.watershed and flow accumulation grid
Markus, 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. 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. Thanks all! Tom On Mon, Feb 16, 2015 at 2:42 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sat, Feb 14, 2015 at 3:45 PM, Thomas Adams tea...@gmail.com wrote: The reason I need to use the D8 (SFD) algorithm is that I am generating a file that identifies how pixels are connected hydraulically; the distributed hydrologic model I am using requires that this connectivity be unique; so a pixel must be uniquely connected to a single downstream pixel. Consequently, with the GRASS scripting I have done to produce the needed ascii output file I need, I think I have to use the D8 SFD algorithm. The connectivity (drainage output of r.watershed) is always unique, no matter if you use D8 or MFD. In case of MFD, the predominant direction is used. As Micha said, r.watershed does not produce breaks in flow accumulation, it stops only at the edge of the current region and at NULL cells. Modifying a DEM to match a river network can be dangerous, I would recommend to not burn the whole river network into the DEM but modify only those parts that really need modification. Usually you will never get a perfect match between a river network created from different sources and a stream network derived from a DEM. Markus M Cheers! Tom On Sat, Feb 14, 2015 at 5:02 AM, Micha Silver mi...@arava.co.il wrote: Hi Thomas: On 02/13/2015 10:28 PM, Thomas Adams wrote: Micha, No, after looking at what's going-on in more detail, I think the DEM is too coarse (even at 90m), so the flow direction and accumulation is mis-directed in one critical area of the watershed. I tried using r.carve, but it is taking forever — after 15 minutes, no advancement of the progress bar… I don't see why carving into a DEM should cause r.watershed to run more slowly, unless you have carved out only a section of some of the streams. If your carving does not continue right to the outlet of the stream (i.e. to an ocean, or to the edge of the region) then r.watershed would actually have to fill in that carved out stream to find a flow path. That could cause the performance hit. Additionally, are you using GRASS 7.0? As you probably know some substantial improvements to the algorithms were introduced in 7 for several modules, r.watershed among them. And third, why use the D8 flow direction when MFD is available (again in GRASS 7.0)? That could also be causing what you refer to as breaks in the channels. MFD is especailly good, I believe, in flat areas. In any case, Keep up posted on your progress. Thanks, Micha I did not want to have to do this for my testing, but I'll probably try at 3 or 10 meter — lots of pixels for my basin! The problem, in general, for me is that I want to apply my techniques at international locations where I probably won't have the benefit of higher resolution DEMs, so I need to develop something a bit more robust… Cheers! Tom On Fri, Feb 13, 2015 at 1:15 PM, Micha Silver mi...@arava.co.il wrote: On 02/13/2015 08:48 PM, Thomas Adams wrote: Stefan, A fair question; since I know the stream topology from personal experience it is clear that there should be no break in the stream network and the flow accumulation grid should reflect that. I am seeing the flow accumulation values break at a point where they should continue to accumulate downstream. Are these breaks possibly caused by null pixels in the DEM? Tom On Fri, Feb 13, 2015 at 11:43 AM, Stefan Lüdtke slued...@gfz-potsdam.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tom, just out of curiosity, what do you mean by break in the flow accumulation? Cheers, Stefan On 02/13/2015 07:12 PM, Thomas Adams wrote: Hello all! I'm making use of the flow accumulation grid in GRASS 6.4.5 generated from r.watershed using the SFD (D8) flow algorithm. The DEM has a 250m spatial resolution. What I'm getting is a break in the flow accumulation in a few locations which is causing me serious problems with subsequent processing (with
Re: [GRASS-user] Question about r.watershed and flow accumulation grid
Hi Thomas: On 02/13/2015 10:28 PM, Thomas Adams wrote: Micha, No, after looking at what's going-on in more detail, I think the DEM is too coarse (even at 90m), so the flow direction and accumulation is mis-directed in one critical area of the watershed. I tried using r.carve, but it is taking forever — after 15 minutes, no advancement of the progress bar… I don't see why carving into a DEM should cause r.watershed to run more slowly, unless you have carved out only a section of some of the streams. If your carving does not continue right to the outlet of the stream (i.e. to an ocean, or to the edge of the region) then r.watershed would actually have to fill in that carved out stream to find a flow path. That could cause the performance hit. Additionally, are you using GRASS 7.0? As you probably know some substantial improvements to the algorithms were introduced in 7 for several modules, r.watershed among them. And third, why use the D8 flow direction when MFD is available (again in GRASS 7.0)? That could also be causing what you refer to as breaks in the channels. MFD is especailly good, I believe, in flat areas. In any case, Keep up posted on your progress. Thanks, Micha I did not want to have to do this for my testing, but I'll probably try at 3 or 10 meter — lots of pixels for my basin! The problem, in general, for me is that I want to apply my techniques at international locations where I probably won't have the benefit of higher resolution DEMs, so I need to develop something a bit more robust… Cheers! Tom On Fri, Feb 13, 2015 at 1:15 PM, Micha Silver mi...@arava.co.il wrote: On 02/13/2015 08:48 PM, Thomas Adams wrote: Stefan, A fair question; since I know the stream topology from personal experience it is clear that there should be no break in the stream network and the flow accumulation grid should reflect that. I am seeing the flow accumulation values break at a point where they should continue to accumulate downstream. Are these breaks possibly caused by null pixels in the DEM? Tom On Fri, Feb 13, 2015 at 11:43 AM, Stefan Lüdtke slued...@gfz-potsdam.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tom, just out of curiosity, what do you mean by "break in the flow accumulation"? Cheers, Stefan On 02/13/2015 07:12 PM, Thomas Adams wrote: Hello all! I'm making use of the flow accumulation grid in GRASS 6.4.5 generated from r.watershed using the SFD (D8) flow algorithm. The DEM has a 250m spatial resolution. What I'm getting is a break in the flow accumulation in a few locations which is causing me serious problems with subsequent processing (with help from some here, I have put together some scripting to generate a pixel connectivity file for a distributed hydrologic model).
Re: [GRASS-user] Question about r.watershed and flow accumulation grid
Micha, You raise very good questions. I think you may have misunderstood; perhaps I explained poorly. r.watershed is NOT running slowly; I have had no problems with r.watershed performance. The performance slowness I have had is with r.carve -- it is running very slowly. I am also using GRASS 7.0RC1; but for the final step in one of my analysis (not what I have described here), I need to use r.arc.out, which is now handled by r.out.gdal; I have not had the chance to explore this, but the ascii output files generated by the two are different. I use a subsequent binary application (written by someone else) that reformats the GRASS r.out.arc output to a new binary grid file that is only used within the U.S. National Weather Service. So, wanting a more simplified workflow, I'm stuck with using GRASS 6.4.5 for some of this. The reason I need to use the D8 (SFD) algorithm is that I am generating a file that identifies how pixels are connected hydraulically; the distributed hydrologic model I am using requires that this connectivity be unique; so a pixel must be uniquely connected to a single downstream pixel. Consequently, with the GRASS scripting I have done to produce the needed ascii output file I need, I think I have to use the D8 SFD algorithm. Cheers! Tom On Sat, Feb 14, 2015 at 5:02 AM, Micha Silver mi...@arava.co.il wrote: Hi Thomas: On 02/13/2015 10:28 PM, Thomas Adams wrote: Micha, No, after looking at what's going-on in more detail, I think the DEM is too coarse (even at 90m), so the flow direction and accumulation is mis-directed in one critical area of the watershed. I tried using r.carve, but it is taking forever — after 15 minutes, no advancement of the progress bar… I don't see why carving into a DEM should cause r.watershed to run more slowly, unless you have carved out only a section of some of the streams. If your carving does not continue right to the outlet of the stream (i.e. to an ocean, or to the edge of the region) then r.watershed would actually have to fill in that carved out stream to find a flow path. That could cause the performance hit. Additionally, are you using GRASS 7.0? As you probably know some substantial improvements to the algorithms were introduced in 7 for several modules, r.watershed among them. And third, why use the D8 flow direction when MFD is available (again in GRASS 7.0)? That could also be causing what you refer to as breaks in the channels. MFD is especailly good, I believe, in flat areas. In any case, Keep up posted on your progress. Thanks, Micha I did not want to have to do this for my testing, but I'll probably try at 3 or 10 meter — lots of pixels for my basin! The problem, in general, for me is that I want to apply my techniques at international locations where I probably won't have the benefit of higher resolution DEMs, so I need to develop something a bit more robust… Cheers! Tom On Fri, Feb 13, 2015 at 1:15 PM, Micha Silver mi...@arava.co.il wrote: On 02/13/2015 08:48 PM, Thomas Adams wrote: Stefan, A fair question; since I know the stream topology from personal experience it is clear that there should be no break in the stream network and the flow accumulation grid should reflect that. I am seeing the flow accumulation values break at a point where they should continue to accumulate downstream. Are these breaks possibly caused by null pixels in the DEM? Tom On Fri, Feb 13, 2015 at 11:43 AM, Stefan Lüdtke slued...@gfz-potsdam.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tom, just out of curiosity, what do you mean by break in the flow accumulation? Cheers, Stefan On 02/13/2015 07:12 PM, Thomas Adams wrote: Hello all! I'm making use of the flow accumulation grid in GRASS 6.4.5 generated from r.watershed using the SFD (D8) flow algorithm. The DEM has a 250m spatial resolution. What I'm getting is a break in the flow accumulation in a few locations which is causing me serious problems with subsequent processing (with help from some here, I have put together some scripting to generate a pixel connectivity file for a distributed hydrologic model). Besides going to a higher resolution DEM, are there any thoughts as to how I can eliminate these flow accumulation breaks? Thank you, Tom -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user - -- Stefan Lüdtke Section 5.4- Hydrology Tel.: +49 331 288 2821 %2B49%20331%20288%202821 Fax: +49 331 288 1570 %2B49%20331%20288%201570 Email: slued...@gfz-potsdam.de Helmholtz-Zentrum Potsdam Deutsches GeoForschungsZentrum GFZ (GFZ German Research Centre for Geoscience) Stiftung des öff. Rechts Land Brandenburg Telegrafenberg, 14473 Potsdam - --- PGP Public Key: http://bit.ly/13d9Sca -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11
Re: [GRASS-user] Question about r.watershed and flow accumulation grid
On Sat, Feb 14, 2015 at 3:45 PM, Thomas Adams tea...@gmail.com wrote: Micha, You raise very good questions. I think you may have misunderstood; perhaps I explained poorly. r.watershed is NOT running slowly; I have had no problems with r.watershed performance. The performance slowness I have had is with r.carve -- it is running very slowly. I just tried the example mentioned in r.carve's manual page: on my small laptop it takes 2.5 seconds for 2 million pixels. How many rows/columns do you have? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Question about r.watershed and flow accumulation grid
Stefan, A fair question; since I know the stream topology from personal experience it is clear that there should be no break in the stream network and the flow accumulation grid should reflect that. I am seeing the flow accumulation values break at a point where they should continue to accumulate downstream. Tom On Fri, Feb 13, 2015 at 11:43 AM, Stefan Lüdtke slued...@gfz-potsdam.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tom, just out of curiosity, what do you mean by break in the flow accumulation? Cheers, Stefan On 02/13/2015 07:12 PM, Thomas Adams wrote: Hello all! I'm making use of the flow accumulation grid in GRASS 6.4.5 generated from r.watershed using the SFD (D8) flow algorithm. The DEM has a 250m spatial resolution. What I'm getting is a break in the flow accumulation in a few locations which is causing me serious problems with subsequent processing (with help from some here, I have put together some scripting to generate a pixel connectivity file for a distributed hydrologic model). Besides going to a higher resolution DEM, are there any thoughts as to how I can eliminate these flow accumulation breaks? Thank you, Tom -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user - -- Stefan Lüdtke Section 5.4- Hydrology Tel.: +49 331 288 2821 Fax: +49 331 288 1570 Email: slued...@gfz-potsdam.de Helmholtz-Zentrum Potsdam Deutsches GeoForschungsZentrum GFZ (GFZ German Research Centre for Geoscience) Stiftung des öff. Rechts Land Brandenburg Telegrafenberg, 14473 Potsdam - --- PGP Public Key: http://bit.ly/13d9Sca -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJU3kXYAAoJEB5GAbKcg+D8YqMH/jgJZ70cz69IJal6ICi66wqW lQYnnko592KAOlFDu1lReZhWWVgeA59rDsYA2Gg/rBzoL9Nst3hzIJDWqnhIWl3W YgF/vOJgTRnrNJtOibGpOc8hxrHwElxU7afYlXU8Zk+4tXdZRK4/vrQ4tKEcbY0z MrhAYjR66RRpoNf9/3WJ3s14CpPA+KEkOaysOOoTV6Ni7qZTK8rVxt+svQQoPtW+ 5QwRJLkLeM6bUrqfQifHis91j4k3JSoSp7ZjIInKwi1tvCSfcFQhzvANs4x8e1Lo Q5wDbzHshhJieGKyraUZyT8cn9vszv9cm2Sf49O/0FWVz3Eyc9vsKFxVcvfEb1E= =Sy/3 -END PGP SIGNATURE- -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Question about r.watershed and flow accumulation grid
On 02/13/2015 08:48 PM, Thomas Adams wrote: Stefan, A fair question; since I know the stream topology from personal experience it is clear that there should be no break in the stream network and the flow accumulation grid should reflect that. I am seeing the flow accumulation values break at a point where they should continue to accumulate downstream. Are these breaks possibly caused by null pixels in the DEM? Tom On Fri, Feb 13, 2015 at 11:43 AM, Stefan Lüdtke slued...@gfz-potsdam.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tom, just out of curiosity, what do you mean by "break in the flow accumulation"? Cheers, Stefan On 02/13/2015 07:12 PM, Thomas Adams wrote: Hello all! I'm making use of the flow accumulation grid in GRASS 6.4.5 generated from r.watershed using the SFD (D8) flow algorithm. The DEM has a 250m spatial resolution. What I'm getting is a break in the flow accumulation in a few locations which is causing me serious problems with subsequent processing (with help from some here, I have put together some scripting to generate a pixel connectivity file for a distributed hydrologic model). Besides going to a higher resolution DEM, are there any thoughts as to how I can eliminate these flow accumulation breaks? Thank you, Tom -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user - -- Stefan Lüdtke Section 5.4- Hydrology Tel.: +49 331 288 2821 Fax: +49 331 288 1570 Email: slued...@gfz-potsdam.de Helmholtz-Zentrum Potsdam Deutsches GeoForschungsZentrum GFZ (GFZ German Research Centre for Geoscience) Stiftung des öff. Rechts Land Brandenburg Telegrafenberg, 14473 Potsdam - --- PGP Public Key: http://bit.ly/13d9Sca -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJU3kXYAAoJEB5GAbKcg+D8YqMH/jgJZ70cz69IJal6ICi66wqW lQYnnko592KAOlFDu1lReZhWWVgeA59rDsYA2Gg/rBzoL9Nst3hzIJDWqnhIWl3W YgF/vOJgTRnrNJtOibGpOc8hxrHwElxU7afYlXU8Zk+4tXdZRK4/vrQ4tKEcbY0z MrhAYjR66RRpoNf9/3WJ3s14CpPA+KEkOaysOOoTV6Ni7qZTK8rVxt+svQQoPtW+ 5QwRJLkLeM6bUrqfQifHis91j4k3JSoSp7ZjIInKwi1tvCSfcFQhzvANs4x8e1Lo Q5wDbzHshhJieGKyraUZyT8cn9vszv9cm2Sf49O/0FWVz3Eyc9vsKFxVcvfEb1E= =Sy/3 -END PGP SIGNATURE- -- This mail was received via Mail-SeCure System. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user This mail was received via Mail-SeCure System. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Question about r.watershed and flow accumulation grid
Micha, No, after looking at what's going-on in more detail, I think the DEM is too coarse (even at 90m), so the flow direction and accumulation is mis-directed in one critical area of the watershed. I tried using r.carve, but it is taking forever — after 15 minutes, no advancement of the progress bar… I did not want to have to do this for my testing, but I'll probably try at 3 or 10 meter — lots of pixels for my basin! The problem, in general, for me is that I want to apply my techniques at international locations where I probably won't have the benefit of higher resolution DEMs, so I need to develop something a bit more robust… Cheers! Tom On Fri, Feb 13, 2015 at 1:15 PM, Micha Silver mi...@arava.co.il wrote: On 02/13/2015 08:48 PM, Thomas Adams wrote: Stefan, A fair question; since I know the stream topology from personal experience it is clear that there should be no break in the stream network and the flow accumulation grid should reflect that. I am seeing the flow accumulation values break at a point where they should continue to accumulate downstream. Are these breaks possibly caused by null pixels in the DEM? Tom On Fri, Feb 13, 2015 at 11:43 AM, Stefan Lüdtke slued...@gfz-potsdam.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tom, just out of curiosity, what do you mean by break in the flow accumulation? Cheers, Stefan On 02/13/2015 07:12 PM, Thomas Adams wrote: Hello all! I'm making use of the flow accumulation grid in GRASS 6.4.5 generated from r.watershed using the SFD (D8) flow algorithm. The DEM has a 250m spatial resolution. What I'm getting is a break in the flow accumulation in a few locations which is causing me serious problems with subsequent processing (with help from some here, I have put together some scripting to generate a pixel connectivity file for a distributed hydrologic model). Besides going to a higher resolution DEM, are there any thoughts as to how I can eliminate these flow accumulation breaks? Thank you, Tom -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user - -- Stefan Lüdtke Section 5.4- Hydrology Tel.: +49 331 288 2821 Fax: +49 331 288 1570 Email: slued...@gfz-potsdam.de Helmholtz-Zentrum Potsdam Deutsches GeoForschungsZentrum GFZ (GFZ German Research Centre for Geoscience) Stiftung des öff. Rechts Land Brandenburg Telegrafenberg, 14473 Potsdam - --- PGP Public Key: http://bit.ly/13d9Sca -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJU3kXYAAoJEB5GAbKcg+D8YqMH/jgJZ70cz69IJal6ICi66wqW lQYnnko592KAOlFDu1lReZhWWVgeA59rDsYA2Gg/rBzoL9Nst3hzIJDWqnhIWl3W YgF/vOJgTRnrNJtOibGpOc8hxrHwElxU7afYlXU8Zk+4tXdZRK4/vrQ4tKEcbY0z MrhAYjR66RRpoNf9/3WJ3s14CpPA+KEkOaysOOoTV6Ni7qZTK8rVxt+svQQoPtW+ 5QwRJLkLeM6bUrqfQifHis91j4k3JSoSp7ZjIInKwi1tvCSfcFQhzvANs4x8e1Lo Q5wDbzHshhJieGKyraUZyT8cn9vszv9cm2Sf49O/0FWVz3Eyc9vsKFxVcvfEb1E= =Sy/3 -END PGP SIGNATURE- -- This mail was received via Mail-SeCure System. ___ grass-user mailing listgrass-user@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/grass-user This mail was received via Mail-SeCure System. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Question about r.watershed and flow accumulation grid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tom, just out of curiosity, what do you mean by break in the flow accumulation? Cheers, Stefan On 02/13/2015 07:12 PM, Thomas Adams wrote: Hello all! I'm making use of the flow accumulation grid in GRASS 6.4.5 generated from r.watershed using the SFD (D8) flow algorithm. The DEM has a 250m spatial resolution. What I'm getting is a break in the flow accumulation in a few locations which is causing me serious problems with subsequent processing (with help from some here, I have put together some scripting to generate a pixel connectivity file for a distributed hydrologic model). Besides going to a higher resolution DEM, are there any thoughts as to how I can eliminate these flow accumulation breaks? Thank you, Tom -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user - -- Stefan Lüdtke Section 5.4- Hydrology Tel.: +49 331 288 2821 Fax: +49 331 288 1570 Email: slued...@gfz-potsdam.de Helmholtz-Zentrum Potsdam Deutsches GeoForschungsZentrum GFZ (GFZ German Research Centre for Geoscience) Stiftung des öff. Rechts Land Brandenburg Telegrafenberg, 14473 Potsdam - --- PGP Public Key: http://bit.ly/13d9Sca -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJU3kXYAAoJEB5GAbKcg+D8YqMH/jgJZ70cz69IJal6ICi66wqW lQYnnko592KAOlFDu1lReZhWWVgeA59rDsYA2Gg/rBzoL9Nst3hzIJDWqnhIWl3W YgF/vOJgTRnrNJtOibGpOc8hxrHwElxU7afYlXU8Zk+4tXdZRK4/vrQ4tKEcbY0z MrhAYjR66RRpoNf9/3WJ3s14CpPA+KEkOaysOOoTV6Ni7qZTK8rVxt+svQQoPtW+ 5QwRJLkLeM6bUrqfQifHis91j4k3JSoSp7ZjIInKwi1tvCSfcFQhzvANs4x8e1Lo Q5wDbzHshhJieGKyraUZyT8cn9vszv9cm2Sf49O/0FWVz3Eyc9vsKFxVcvfEb1E= =Sy/3 -END PGP SIGNATURE- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Question about r.watershed and flow accumulation grid
Thayer, Great suggestions! I'll give it a try... Thank you, Tom On Fri, Feb 13, 2015 at 4:56 PM, Thayer Young thaye...@yahoo.com wrote: Tom, Hopefully the higher spatial resolution data will also have higher vertical resolution. That said, if you have any idea where the stream channels are, for example a vector file, in the flat areas you can burn them into the raster using r.mapcalc. So you can rasterize vector streams (v.to.rast) and then thin the raster streams (r.thin) and use r.mapcalc to subtract a constant value where the raster stream map is. If you do not thin the raster you will get an error, as there will be ambiguous flow paths (endless loops). QGIS has a nice feature in its vector to raster tool. It will do the burn for you directly from the vector file into your DEM. You should make a backup of your DEM though first, since it edits the original file. You just add a field to the vector streams for a desired elevation. Then you select that elevation field in the vector to raster dialog and select your DEM as the output raster. After saying that yes it is OK to overwrite your DEM, it will burn the vector elevation. I have only used this to edit small areas on a raster, so I can not tell you if the burnt channel is sufficiently thinned or not. One of the big problems with using flow algorithms is that bridges and roads will frequently act like dams, causing the flow to be rerouted outside of the actual channel. To prevent this you can digitize a vector map of places where you want to cut through these dams and set a field with desired elevations as described above. -Thayer -- *From:* Thomas Adams tea...@gmail.com *To:* Thayer Young thaye...@yahoo.com *Cc:* grass-user@lists.osgeo.org grass-user@lists.osgeo.org *Sent:* Friday, February 13, 2015 5:48 PM *Subject:* Re: grass-user Digest, Vol 106, Issue 34 Thayer, Thank you for the suggestion; I just tried it with the same result. I think the area just happens to be a difficult area, that is pretty flat… Cheers! Tom On Fri, Feb 13, 2015 at 1:54 PM, Thayer Young thaye...@yahoo.com wrote: I don't know if you have tried this yet, but you may also want to look at r.terraflow. It does both D8 (single flow direction) and multiple flow direction (flow is partitioned, according to the steepness of slope, to all directions that are lower than the central cell). Supposedly you can also switch from MFD to SFD once flow exceeds a threshold, but I have not been successful at doing this. It would be a simple simulation of channelization though. Just set the D8 flag in the options tab, otherwise it will give you MFD by default. -Thayer -- Date: Fri, 13 Feb 2015 11:12:30 -0700 From: Thomas Adams tea...@gmail.com To: grass-user@lists.osgeo.org grass-user@lists.osgeo.org Subject: [GRASS-user] Question about r.watershed and flow accumulation grid Message-ID: cagxgkwgefettcjzwki3jp8wj79eb0j3fzsf6hgzt8m9-dgc...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Hello all! I'm making use of the flow accumulation grid in GRASS 6.4.5 generated from r.watershed using the SFD (D8) flow algorithm. The DEM has a 250m spatial resolution. What I'm getting is a break in the flow accumulation in a few locations which is causing me serious problems with subsequent processing (with help from some here, I have put together some scripting to generate a pixel connectivity file for a distributed hydrologic model). Besides going to a higher resolution DEM, are there any thoughts as to how I can eliminate these flow accumulation breaks? Thank you, Tom -- -- next part -- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20150213/9306343f/attachment-0001.html -- Thomas E Adams, III 718 McBurney Drive Lebanon, OH 45036 1 (513) 739-9512 (cell) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
