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

[Markus Metz]

On Mon, Feb 4, 2013 at 3:41 PM, Moritz Lennert
<mlennert at club.worldonline.be> wrote:
> On 04/02/13 14:52, Markus Metz wrote:
>>
>> 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.
>
>
> Now I get a segfault. gdb full backtrace and DEBUG=3 log attached. Do you
> need something else ?

Should be fixed in r54897.

Sprinting a bit fast,

Markus M
>
> Moritz