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

GRASS GRASS user
1

Hi,

I have a network (proper GRASS network) and two point vectors.
One is representing sampling stations the second contains locations
of migration barriers with a certain value for its permeability (0-1).
Both point vectors are located on the network (snapped via v.distance
and v.in.db). Now I'd like to get all the migration barriers that
are between any pairwise combination of the sampling stations. In other
words, I want to get all sampling stations that are located between one
sampling station and another one (all possible combinations). Moreover
I'd like to get the sum and product of the permeability values of all
barriers inbetween. Is there such a tool in GRASS GIS?

What I thought about the solution: 1) Getting paths (vectors) connecting
all pairwise sampling stations (but how) and 2) extracting the barriers
that are located on each connecting line?

Any suggestions?

best regards,

Johannes

2

On 30/01/13 14:18, Johannes Radinger wrote:

Hi,

I have a network (proper GRASS network) and two point vectors.
One is representing sampling stations the second contains locations
of migration barriers with a certain value for its permeability (0-1).
Both point vectors are located on the network (snapped via v.distance
and v.in.db).

Note that v.net allows you to easily connect points to the network. And in Grass7, it allows you to snap the points onto the network.

Now I'd like to get all the migration barriers that
are between any pairwise combination of the sampling stations. In other
words, I want to get all sampling stations that are located between one
sampling station and another one (all possible combinations). Moreover
I'd like to get the sum and product of the permeability values of all
barriers inbetween. Is there such a tool in GRASS GIS?

What I thought about the solution: 1) Getting paths (vectors) connecting
all pairwise sampling stations (but how)

v.net.allpairs, if you set the cost of all arcs to 0 and only assign the permeability values as costs to the barrier nodes, then I guess the cost value in the resulting attribute table should give you the sum of permeability values (but I'm not sure, you'll have to test).

and 2) extracting the barriers
that are located on each connecting line?

I guess a simple v.distance between the v.net.allpairs vector lines and the barriers plus some SQL should give you that info.

Moritz

3

On Thu, Jan 31, 2013 at 3:10 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 30/01/13 14:18, Johannes Radinger wrote:

Hi,

I have a network (proper GRASS network) and two point vectors.
One is representing sampling stations the second contains locations
of migration barriers with a certain value for its permeability (0-1).
Both point vectors are located on the network (snapped via v.distance
and v.in.db).

Note that v.net allows you to easily connect points to the network. And in
Grass7, it allows you to snap the points onto the network.

Now I'd like to get all the migration barriers that
are between any pairwise combination of the sampling stations. In other
words, I want to get all sampling stations that are located between one
sampling station and another one (all possible combinations). Moreover
I'd like to get the sum and product of the permeability values of all
barriers inbetween. Is there such a tool in GRASS GIS?

What I thought about the solution: 1) Getting paths (vectors) connecting
all pairwise sampling stations (but how)

v.net.allpairs, if you set the cost of all arcs to 0 and only assign the
permeability values as costs to the barrier nodes, then I guess the cost
value in the resulting attribute table should give you the sum of
permeability values (but I'm not sure, you'll have to test).

Thank you, that might work. I just realized that my permeabilities are
given as probability and they are added up by a multiplication rule. Thus
I don't need the sum but rather the product or at least a list of all barries
between to sampling stations....

and 2) extracting the barriers
that are located on each connecting line?

I guess a simple v.distance between the v.net.allpairs vector lines and the
barriers plus some SQL should give you that info.

Hi,

thats what I tried now, v.distance to get from barriers to nearest
vector lines from v.net.allpairs,
but 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.

So, a solution could be to loop over the all lines (categories) and
use v.select as
v.select does not have any option for stratified selection (e.g. per
category)...
I'll try that now, but any other recommendations are mostly welcome...

Johannes

Moritz

4

On 01/02/13 11:44, Johannes Radinger wrote:

Thank you, that might work. I just realized that my permeabilities are
given as probability and they are added up by a multiplication rule. Thus
I don't need the sum but rather the product or at least a list of all barries
between to sampling stations....

At this stage costs can only be summed AFAIK.

thats what I tried now, v.distance to get from barriers to nearest
vector lines from v.net.allpairs,
  but 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. Shouldn't these rather be represented by single segments with multiple category values (like v.buffer in grass7) ?

So, a solution could be to loop over the all lines (categories) and
use v.select as
v.select does not have any option for stratified selection (e.g. per
category)...
I'll try that now, but any other recommendations are mostly welcome...

How about v.distance -a to get a complete distance matrix between nodes and paths and then select those elements where distance = 0 (supposing that you snapped the nodes onto the network) ?

Moritz

5

On Fri, Feb 1, 2013 at 6:39 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 01/02/13 11:44, Johannes Radinger wrote:

Thank you, that might work. I just realized that my permeabilities are
given as probability and they are added up by a multiplication rule. Thus
I don't need the sum but rather the product or at least a list of all
barries
between to sampling stations....

At this stage costs can only be summed AFAIK.

thats what I tried now, v.distance to get from barriers to nearest
vector lines from v.net.allpairs,
  but 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.

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.

So, a solution could be to loop over the all lines (categories) and
use v.select as
v.select does not have any option for stratified selection (e.g. per
category)...
I'll try that now, but any other recommendations are mostly welcome...

How about v.distance -a to get a complete distance matrix between nodes and
paths and then select those elements where distance = 0 (supposing that you
snapped the nodes onto the network) ?

Another idea would be to look at linear referencing, the v.lrs.* modules.

Markus M

6

On 01/02/13 19:55, Markus Metz wrote:

On Fri, Feb 1, 2013 at 6:39 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 01/02/13 11:44, Johannes Radinger wrote:

Thank you, that might work. I just realized that my permeabilities are
given as probability and they are added up by a multiplication rule. Thus
I don't need the sum but rather the product or at least a list of all
barries
between to sampling stations....

At this stage costs can only be summed AFAIK.

thats what I tried now, v.distance to get from barriers to nearest
vector lines from v.net.allpairs,
   but 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.

Moritz

7

On Sat, Feb 2, 2013 at 12:51 PM, Moritz Lennert
<mlennert@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@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.

Markus M

8

On 04/02/13 12:29, Markus Metz wrote:

On Sat, Feb 2, 2013 at 12:51 PM, Moritz Lennert
<mlennert@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@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@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

9

On Mon, Feb 4, 2013 at 1:49 PM, Moritz Lennert
<mlennert@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@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@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@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

10

On 04/02/13 14:52, Markus Metz wrote:

On Mon, Feb 4, 2013 at 1:49 PM, Moritz Lennert
<mlennert@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@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@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@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

(attachments)

gdb.txt.gz (3.21 KB)
log.gz (24.4 KB)

11

On Mon, Feb 4, 2013 at 3:41 PM, Moritz Lennert
<mlennert@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@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@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@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@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

12

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@user1 type=point,line,area,face display=shape,cat' has failed

The same for

d.vect map=allpairs@user1 layer=1 type=line display=shape,cat

Trying to run this on the command line:

d.mon cairo
d.vect map=allpairs@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;

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.

> Sprinting a bit fast,
>

Hey, that's what sprints are for, no ? I'd call this "agile" programming :wink:

Moritz

(attachments)

map.png

13

On Mon, Feb 4, 2013 at 4:41 PM, Moritz Lennert
<mlennert@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@user1 type=point,line,area,face
display=shape,cat' has failed

The same for

d.vect map=allpairs@user1 layer=1 type=line display=shape,cat

Trying to run this on the command line:

d.mon cairo
d.vect map=allpairs@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. Another bug in d.vect is
the use of

sprintf(text, "%s%d", text, cat),

for which the behaviour is undefined.

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.

Sprinting a bit fast,

Hey, that's what sprints are for, no ? I'd call this "agile" programming :wink:

Thanks :wink:

Markus M

14

On Mon, Feb 4, 2013 at 5:01 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:

On Mon, Feb 4, 2013 at 4:41 PM, Moritz Lennert
<mlennert@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@user1 type=point,line,area,face
display=shape,cat' has failed

The same for

d.vect map=allpairs@user1 layer=1 type=line display=shape,cat

Trying to run this on the command line:

d.mon cairo
d.vect map=allpairs@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.

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.

Markus M

15

On 04/02/13 17:17, Markus Metz wrote:

On Mon, Feb 4, 2013 at 5:01 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:

On Mon, Feb 4, 2013 at 4:41 PM, Moritz Lennert
<mlennert@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@user1 type=point,line,area,face
display=shape,cat' has failed

The same for

d.vect map=allpairs@user1 layer=1 type=line display=shape,cat

Trying to run this on the command line:

d.mon cairo
d.vect map=allpairs@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

(attachments)

v_distance_point_to_line.png

16

On 04/02/13 18:54, Moritz Lennert wrote:

On 04/02/13 17:17, Markus Metz wrote:

On Mon, Feb 4, 2013 at 5:01 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:

On Mon, Feb 4, 2013 at 4:41 PM, Moritz Lennert
<mlennert@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@user1 type=point,line,area,face
display=shape,cat' has failed

The same for

d.vect map=allpairs@user1 layer=1 type=line display=shape,cat

Trying to run this on the command line:

d.mon cairo
d.vect map=allpairs@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.

Forget this, I guess I was trying to do too many things at the same time yesterday to check correctly. Actually the v.distance call does not work for this purpose since v.distance only uses the very first cat value of each segment, and so the distance matrix only gives me the those paths that have the lowest cat value, not all paths, without any warning. So, not only do you not get all paths, but for those paths you do get, the number of nodes might not be correct since only those segments of a given path where the path cat of that path is the first in the long list of path cats will be taken into account.

If you turn the v.distance call around to calculate distances from nodes to paths, i;e.:

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

you get the warning

ATTENTION : More cats found in to_layer

Actually in the code of v.distance, there is a TODO at that point related to this issue:

"/* TODO: all cats of given field ? */"

So, either we have to enhance v.distance to take into account all cat values in a given layer, or for this particular issue, the old version of v.net.allpairs is actually easier to use. Maybe a flag to v.net.allpairs could allow to not remove duplicates ?

Moritz

17

On Tue, Feb 5, 2013 at 5:22 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 04/02/13 18:54, Moritz Lennert wrote:

in the code of v.distance, there is a TODO at that point related to
this issue:

"/* TODO: all cats of given field ? */"

So, either we have to enhance v.distance to take into account all cat values
in a given layer, or for this particular issue, the old version of
v.net.allpairs is actually easier to use. Maybe a flag to v.net.allpairs
could allow to not remove duplicates ?

In the current version, v.net.allpairs does not remove duplicates, it
avoids duplicates. The current output is more in accordance with the
GRASS vector model, but if this output is more (or too) difficult to
post-process, it can be reverted to the old behaviour. I would suggest
to wait for some more feedback.

Markus M

18

On 05/02/13 16:56, Markus Metz wrote:

On Tue, Feb 5, 2013 at 5:22 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 04/02/13 18:54, Moritz Lennert wrote:

in the code of v.distance, there is a TODO at that point related to
this issue:

"/* TODO: all cats of given field ? */"

So, either we have to enhance v.distance to take into account all cat values
in a given layer, or for this particular issue, the old version of
v.net.allpairs is actually easier to use. Maybe a flag to v.net.allpairs
could allow to not remove duplicates ?

In the current version, v.net.allpairs does not remove duplicates, it
avoids duplicates.

Yes, sorry for the misformulation.

The current output is more in accordance with the
GRASS vector model, but if this output is more (or too) difficult to
post-process, it can be reverted to the old behaviour.

I'm all for the accordance with the vector model, and so am not sure I would like to see this reversed. Ideally, it is v.distance that would need to be enhanced to take into account multiple cats in from and to features.
However, if enhancing v.distance proves a bigger challenge, I thought that maybe we could create a flag in v.net.allpairs that if set would create output in the old way (duplicate lines) in order to allow treatment such as the v.distance one I explained.

I would suggest
to wait for some more feedback.

Ok.

Happy hacking at the sprint !

Moritz

19

On Tue, Feb 5, 2013 at 5:54 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 05/02/13 16:56, Markus Metz wrote:

On Tue, Feb 5, 2013 at 5:22 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 04/02/13 18:54, Moritz Lennert wrote:

in the code of v.distance, there is a TODO at that point related to
this issue:

"/* TODO: all cats of given field ? */"

So, either we have to enhance v.distance to take into account all cat
values
in a given layer, or for this particular issue, the old version of
v.net.allpairs is actually easier to use. Maybe a flag to v.net.allpairs
could allow to not remove duplicates ?

In the current version, v.net.allpairs does not remove duplicates, it
avoids duplicates.

Yes, sorry for the misformulation.

What I meant was that it is not possible to simply deactivate
duplicate removal because duplicates are never created. Adding such a
flag would mean to add the code of the version with duplicates, then
run either version 1 or version 2.

Markus M

The current output is more in accordance with the
GRASS vector model, but if this output is more (or too) difficult to
post-process, it can be reverted to the old behaviour.

I'm all for the accordance with the vector model, and so am not sure I would
like to see this reversed. Ideally, it is v.distance that would need to be
enhanced to take into account multiple cats in from and to features.
However, if enhancing v.distance proves a bigger challenge, I thought that
maybe we could create a flag in v.net.allpairs that if set would create
output in the old way (duplicate lines) in order to allow treatment such as
the v.distance one I explained.

I would suggest
to wait for some more feedback.

Ok.

Happy hacking at the sprint !

Moritz