Thanks for the  detailed answer, but, my problem is much more trivial. 

I attached a screenshot to make myself more clear.

/* The numbers refer to the categories of each line segment */

the tributary with cat 69 is fine, but the man channel consists of
multiple lines, and, in fact, a lot of tributaries look similar. As I
mentioned before, adding an additional column (to run kind of
v.dissolve) is not really feasible because I have around  600 cat
values. 

The task would be, to tell GRASS, to combine all lines of the main
channel, for this example. But I think that is quite ambitious- like
Micha wrote in his post. 





On Sat, 2012-02-11 at 15:19 -0800, Hamish wrote 

> sluedtke wrote:
> > I have been trying for some hours now but could not find any
> > solution. 
> > 
> > We do have a shape file of a river network,  but a bad one because single
> > rivers consist of multiple lines. Just think of the easiest example, a
> > river with one tributary. I would like to end up with an vector
> > dataset that holds 2 lines for this example, one for the river and one
> > for the tributary of course. In my case, the dataset holds, just as an
> > example, 10 lines, and a distinct set of them makes either the river or
> > the tributary. The lines of each set are connected by the nodes of the
> > single lines. 
> 
> so you have a vector line map of a "braided river" (be it a real one or the
> product of a computer surface water flow program which creates artifacts)
> and you wish to generalize it into an idealized schematic vector network.
> An interesting challenge.
> 
> I think the first step is to run v.buffer with a buffer distance greater
> than half the maximum width of the parallel braids. The next step is the
> reduction back to a center line, like r.thin but for vector areas. Often
> you could do v.to.rast -> r.thin -> r.to.vect, but that doesn't work well
> for rivers as they are usually long and thin: in order to fit the entire
> length of the river into the raster array you need to make the cell res
> very coarse compared to the width of the river.
> 
> so it becomes the classic "river mile" / "river centerline" problem, and
> if you have a good solution to that (especially for cases when there are
> shoals and islands in the middle of the river and you don't have full
> riverbed bathymetry to find the thalweg) I'd be very interested to hear
> about it.
> 
> the best I ever managed was v.to.rast at very high cell resolution then
> r.cost to find distance from the riverbank, then r.param.scale feature
> map to extract the ridgelines, then r.thin, and r.to.vect.
> (instead of r.param.scale you could also use r.slope.aspect and look for
> places where the slope of the cost-to-shore map is less than some small
> threshold)
> 
> another idea is to make the crappy lo-res river centerline with r.thin,
> then use v.lrs or v.transects(addons) to make step points, then run a
> moving window along the river buffer area at high raster res, using one
> of the g.region temporary zoom addon modules (g.region.point is one).
> Then patch all the new vector segments together and run v.generalize to
> smooth the result. I'm pretty confident that would work reasonably well,
> but it wouldn't be very efficient.
> 
> It would be much more efficient to have a geometric solution than one
> that needs rasterization, maybe something like filling the vector buffer
> area with lots of little circles of varying sizes, merging as many of them
> as possible, then extracting the center coord of each surviving big circle.
> 
> as I said earlier, it's an interesting problem..
> 
> 
> Hamish

<<attachment: river_network_subset.png>>

_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user

Reply via email to