Running r.basin using r.to.vect basin boundaries and r.to.vect
r.stream.extract weighted streams (but same issue using unweighted streams).
So far, of 7 sub-basins on which I've run the module only 4 complete
successfully. The other three go through the entire process then fail with
the error message that the outlet needs to be on a stream channel created by
r.stream.extract.
I use the same protocol on each sub-basin: zoom in very close to where the
sub-basin boundary and stream channel cross, then note the x, y coordinates
from the status line on the display window frame.
What might account for this same process, using the same r.stream.extract
map, to work on some sub-basins and fail on others?
The other three go through the entire process then fail with
the error message that the outlet needs to be on a stream channel created
by
r.stream.extract.
AFAIK from my r.basin-tests the outlet-point has to be exactly on stream
channel created by r.stream.extract
I use the same protocol on each sub-basin: zoom in very close to where
the
sub-basin boundary and stream channel cross, then note the x, y coordinates
from the status line on the display window frame.
maybe following ML-disscussion could be helpfull to find the exact crossing
of stream and boundary:
[GRASS-user] intersection between two lines vector to obtain points:
I get a similar issue some time ago (but with a vector input) and wrote a little script to work only with raster (no need to transform back to vector)
it’s using r.distance (http://grass.osgeo.org/grass64/manuals/html64_user/r.distance.html), wich “Locates the closest points between objects in two raster maps” and output an ascii line with the intersection point …
you just need to input your 2 raster with basin boundaries and streams, and it will do the job for all your objects at once
Running r.basin using r.to.vect basin boundaries and r.to.vect
r.stream.extract weighted streams (but same issue using unweighted streams).
So far, of 7 sub-basins on which I’ve run the module only 4 complete
successfully. The other three go through the entire process then fail with
the error message that the outlet needs to be on a stream channel created by
r.stream.extract.
I use the same protocol on each sub-basin: zoom in very close to where the
sub-basin boundary and stream channel cross, then note the x, y coordinates
from the status line on the display window frame.
What might account for this same process, using the same r.stream.extract
map, to work on some sub-basins and fail on others?
would you mind to write your suggestion in the r.basin wiki page[1]?
done, please expand if needed
Hi Helmut:
I think you had a typo between the names crosspoints and crosspointscat in one line. I took the liberty of fixing, and changing a few other layer names for readability. If you could have a look to be sure it still reads correctly?
The next addition might be how feed these crosspoints X and Y straight into the easting and northing of r.basins…
BTW, thanks for mentioning my blog earlier in the thread
The next addition might be how feed these crosspoints X and Y straight into the easting and northing of r.basins…
you mean something like (untested):
#!/usr/bin/env python
fin = open(“crosspoints”,“r”)
fout = open(“commands”,“w”)
linesout = (line.rstrip().split() for line in fin)
cmd = ‘r.basin map=dem prefix=bas%s easting=%s northing=%s threshold=10000\n’
fout.writelines(cmd % (n, easting, northing) for n,(easting,northing) in enumerate(linesout))
Hi, I run the example of r.basin and I get this message at the end:
Traceback (most recent call last):
File “/home/admin-lsc/Grass/Modulos/r.basin.py”, line 427, in
sys.exit(main())
File “/home/admin-lsc/Grass/Modulos/r.basin.py”, line 235, in main
mainchannel = float(dict_mainchannel[‘Length’]) / 1000
KeyError: ‘Length’
On Wed, Jun 6, 2012 at 5:12 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
The other three go through the entire process then fail with
the error message that the outlet needs to be on a stream channel created
by
r.stream.extract.
AFAIK from my r.basin-tests the outlet-point has to be exactly on stream
channel created by r.stream.extract
I use the same protocol on each sub-basin: zoom in very close to where
the
sub-basin boundary and stream channel cross, then note the x, y coordinates
from the status line on the display window frame.
maybe following ML-disscussion could be helpfull to find the exact crossing
of stream and boundary:
[GRASS-user] intersection between two lines vector to obtain points:
On Thu, Jun 7, 2012 at 5:31 PM, David Montoya <jdmonto0@gmail.com> wrote:
Hi, I run the example of r.basin and I get this message at the end:
Traceback (most recent call last):
File “/home/admin-lsc/Grass/Modulos/r.basin.py”, line 427, in
sys.exit(main())
File “/home/admin-lsc/Grass/Modulos/r.basin.py”, line 235, in main
mainchannel = float(dict_mainchannel[‘Length’]) / 1000
KeyError: ‘Length’
Which example do you refer to (exact commands and dataset)? and when did you download r.basin? On which OS and grass version?
Micha wrote an excellent description that answered a number of questions
for me. Now I'm ready to try r.basin again and want to check the validity of
my understanding of how I got where I now am and where it's going with
r.basin.
The input to r.stream.extract came from r.watershed with this command:
Prior to running v.out.ascii to save the cross_points in a text file I
carefully manually deleted extraneious tiny sub-basins and cross_points at
the confluences of stream channels. This reveals that many cross_points are
not on sub-basin boundaries generated by r.watershed.
In Micha's blog article the cross_points.txt file is used as input to
r.water.outlet which generates the appropriate catchments. I assume this is
also true for r.basin; i.e., it will generate its own basins and sub-basins
based on the outlet points in the cross_points.txt file. Is this assumption
correct?
In Micha’s blog article the cross_points.txt file is used as input to
r.water.outlet which generates the appropriate catchments. I assume this is
also true for r.basin; i.e., it will generate its own basins and sub-basins
based on the outlet points in the cross_points.txt file. Is this assumption
correct?
I did the example suggested on the wiki page, the same maps and the same commands. I’m using Grass 6.4.2svn under Ubuntu, I’m going to update the addons because I downloaded them one year ago
On Thu, Jun 7, 2012 at 11:15 AM, Margherita Di Leo <diregola@gmail.com> wrote:
David,
On Thu, Jun 7, 2012 at 5:31 PM, David Montoya <jdmonto0@gmail.com> wrote:
Hi, I run the example of r.basin and I get this message at the end:
Traceback (most recent call last):
File “/home/admin-lsc/Grass/Modulos/r.basin.py”, line 427, in
sys.exit(main())
File “/home/admin-lsc/Grass/Modulos/r.basin.py”, line 235, in main
mainchannel = float(dict_mainchannel[‘Length’]) / 1000
KeyError: ‘Length’
Which example do you refer to (exact commands and dataset)? and when did you download r.basin? On which OS and grass version?
Regards,
madi
–
Dr. Margherita Di Leo
–
David Montoya González
Ing. Forestal, Universidad Nacional de Colombia
Laboratorio de Sistemas Complejos, UNAL Medellin
On Fri, Jun 8, 2012 at 4:09 PM, David Montoya <jdmonto0@gmail.com> wrote:
I did the example suggested on the wiki page, the same maps and the same commands. I’m using Grass 6.4.2svn under Ubuntu, I’m going to update the addons because I downloaded them one year ago
yes this could be the problem, something has been updated in the code. Please update r.basin and all the add-ons it is based on, and report any problem. Thanks,
In Micha’s blog article the cross_points.txt file is used as input to
r.water.outlet which generates the appropriate catchments. I assume this is
also true for r.basin; i.e., it will generate its own basins and sub-basins
based on the outlet points in the cross_points.txt file. Is this assumption
correct?
Regarding the threshold value in your auxilliary parsing.py script, do you think it might be better to calcuclate a suggested value from the size of the original DEM, rather than just put in some random 10,000 or so.
Obviously the user has to understand, and change the threshold to suit his needs, but if the script is going to contain some value, maybe it should be something “reasonable”. I thought, for example to choose a suggested thresh size of num_cells/100. i.e.:
N=r.univar -g | grep "^n=" | cut -d "=" -f 2
THRESH=$(( $N / 100))
Does that sound reasonable? Since the python auxilliary script runs independently of GRASS, I’m not sure how how this would all merge together. But it’s worth thinking about.
)