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

[Moritz Lennert]

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 ?

Moritz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb.txt.gz
Type: application/x-gzip
Size: 3291 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20130204/6099459b/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.gz
Type: application/x-gzip
Size: 25022 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20130204/6099459b/attachment-0003.bin>