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

[Markus Metz]

On Mon, Feb 4, 2013 at 1:49 PM, Moritz Lennert
<mlennert at club.worldonline.be> wrote:
> 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.

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