On Mon, Feb 4, 2013 at 1:49 PM, Moritz Lennert <mlenn...@club.worldonline.be> wrote: > On 04/02/13 12:29, Markus Metz wrote: >> >> On Sat, Feb 2, 2013 at 12:51 PM, Moritz Lennert >> <mlenn...@club.worldonline.be> wrote: >>> >>> On 01/02/13 19:55, Markus Metz wrote: >>>> >>>> >>>> On Fri, Feb 1, 2013 at 6:39 PM, Moritz Lennert >>>> <mlenn...@club.worldonline.be> wrote: >>>>> >>>>> >>>>> On 01/02/13 11:44, Johannes Radinger wrote: >>>>> >>>>> >>>>>> the problem is that the v.net.allpairs lines are partly >>>>>> overlapping (sharing parts). So there >>>>>> are several barriers on partly overlapping lines, but I want to select >>>>>> all barriers per line category. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> IIUC v.net.allpairs actually creates several duplicate segments which >>>>> seems >>>>> contrary to GRASS topology rules. >>>> >>>> >>>> >>>> GRASS topology supports overlapping lines. >>> >>> >>> >>> Yes, but having several overlapping line segments that are actually the >>> representation of the exact same path kind of seems against the idea of >>> not >>> duplicating information if not necessary. >>> >>> >>>> >>>>> Shouldn't these rather be represented by >>>>> single segments with multiple category values (like v.buffer in grass7) >>>>> ? >>>> >>>> >>>> >>>> Yes, but only if the segment directions are also identical. For >>>> example, if backward direction costs are identical to forward >>>> direction costs, the path from node A to node B is a duplicate of the >>>> path from node B to node A, but in reverse direction. >>> >>> >>> >>> Right, didn't think about direction here. I was more thinking about the >>> situation where paths from A to B, C, D, E all have a common part before >>> forking to the respective destination later on. >>> >>> But I guess even for this situation overlapping lines are not so much of >>> an >>> evil to justify making this into an issue. >> >> >> Fixed in r54893. > > > v.net in=roadsmajor points=schools_wake out=network --o op=connect > thresh=500 > time v.net.allpairs input=network@user1 output=allpairs cats=1-999 --o > > r53630 > > real 0m0.992s > user 0m0.416s > sys 0m0.436s > > > r54893 > > Ctrl-C at 78%: > real 26m37.379s > user 26m12.010s > sys 0m10.641s > > This is on a very old system (P4 !), but still, this seems a very strong > performance regression.
Fixed in r54895. Instead of cleaning up duplicates afterwards, the module now avoids duplicates. > > Trying to run with tool=break,rmdupl gives me the following error: > > ERROR: Nodes not available for line 1 The type option was missing, or in other words, tool=break works only for lines and boundaries, points are not supported, and a corresponding test is (yet) missing. Markus M _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user