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

Moritz Lennert mlennert at club.worldonline.be
Mon Feb 4 09:54:36 PST 2013


On 04/02/13 17:17, Markus Metz wrote:
> On Mon, Feb 4, 2013 at 5:01 PM, Markus Metz
> <markus.metz.giswork at gmail.com>  wrote:
>> On Mon, Feb 4, 2013 at 4:41 PM, Moritz Lennert
>> <mlennert at club.worldonline.be>  wrote:
>>> On 04/02/13 16:07, Markus Metz wrote:
>>>>
>>>> On Mon, Feb 4, 2013 at 3:41 PM, Moritz Lennert
>>>
>>>
>>>>> Now I get a segfault. gdb full backtrace and DEBUG=3 log attached. Do you
>>>>> need something else ?
>>>>
>>>>
>>>> Should be fixed in r54897.
>>>>
>>>
>>> The module runs now and very fast, but weirdly enough I cannot display the
>>> category values in the resulting map. Using wxgui, I get
>>>
>>> The command 'd.vect map=allpairs at user1 type=point,line,area,face
>>> display=shape,cat' has failed
>>>
>>> The same for
>>>
>>> d.vect map=allpairs at user1 layer=1 type=line display=shape,cat
>>>
>>> Trying to run this on the command line:
>>>
>>> d.mon cairo
>>> d.vect map=allpairs at user1 layer=1 type=line display=shape,cat
>>>
>>>
>>> Gives me a seg fault at
>>>
>>> Debug=3:
>>> D3/3: cat lab: field = 1, cat = 1121
>>> D3/3: Vect_read_next_line(): next_line = 53
>>> D3/3: V2_read_next_line_nat()
>>> D3/3: Vect__Read_line_nat: offset = 95566
>>> D3/3:     type = 2, do_cats = 1 dead = 0
>>> D3/3:     n_cats = 96
>>> D3/3:     n_points = 41
>>> Erreur de segmentation
>>>
>>>
>>> gdb:
>>> Program received signal SIGSEGV, Segmentation fault.
>>> dig_alloc_points (points=0x313231, num=42) at struct_alloc.c:338
>>> 338         alloced = points->alloc_points;
>>
>> The segfault is caused by d.vect because the maximum text length is
>> 100 characters only !!! I'm going to fix it.
>
> Fixed in r54906.

Great, thanks !

>
>>
>>> Looking at the map I do get out of the operation (attached) I would think
>>> that the list of cats for a given segment might just be too long... I guess
>>> my idea was maybe not so wise and your original implementation was actually
>>> better.
>
> It displays now correct, but "correct" means long read lines with
> category numbers. Actually, the display would look the same with
> duplicate lines.

I think duplicated lines display cats one above the other, not in a line 
like this. I agree that displaying them as such is not terribly useful, 
except for checking specific results.

Now I tested a possible response to Johannes' initial question:

v.distance from=allpairs from_layer=1 from_type=line to=allpairs 
to_layer=2 to_type=point upload=cat,dist col=to_cat,dist -a dmax=0.0001 
table=dists

gives me a table with distance from all nodes that lie on the different 
paths. dmax=0.0001 avoids that a distance is calculated to each segment 
of the same line. You actually don't really need upload=dist, but it 
can't hurt as a check. You still get a double count for each node lying 
in the middle of a line as it will be counted as connected to both 
sides. So, to get the count of nodes lying on each path:

db.select sql="select from_cat, count(*) from (select distinct * from 
dists) group by from_cat"

Moritz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: v_distance_point_to_line.png
Type: image/png
Size: 20610 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20130204/b1e779cc/attachment-0001.png>


More information about the grass-user mailing list