[GRASS-user] Count points in a network between two locations

[Moritz Lennert]

On 04/02/13 12:29, Markus Metz wrote:
> On Sat, Feb 2, 2013 at 12:51 PM, Moritz Lennert
> <mlennert at club.worldonline.be>  wrote:
>> On 01/02/13 19:55, Markus Metz wrote:
>>>
>>> On Fri, Feb 1, 2013 at 6:39 PM, Moritz Lennert
>>> <mlennert at 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 at 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.

Using the old version of v.net.allpairs and then submitting the result 
to v.clean tool=rmdupl:

time v.clean allpairs out=allpairs_rmdupl tool=rmdupl --o
real	0m10.943s
user	0m4.616s
sys	0m5.596s

going from

Number of nodes: 34
Number of primitives: 1156
Number of points: 34
Number of lines: 1122

to

Number of nodes: 34
Number of primitives: 595
Number of points: 34
Number of lines: 561

which just seems to fusion forward and backward paths.

Trying to run with tool=break,rmdupl gives me the following error:

ERROR: Nodes not available for line 1

Moritz