Opened 4 years ago

Closed 4 years ago

#2669 closed defect (invalid)

v.net.iso: different results depending on direction

Reported by: mlennert Owned by: grass-dev@…
Priority: normal Milestone: 7.0.4
Component: Vector Version: svn-trunk
Keywords: network v.net.iso direction cost Cc:
CPU: Unspecified Platform: Unspecified

Description

Testing v.net.* modules to see whether the number of vertices in lines makes a difference for results (for info: it doesn't), I came upon a weird bug.

I digitized three +/- parallel lines (with different number of vertices) and start points at more or less similar positions on these lines.

Then:

v.net test_lines points=test_points op=connect thresh=500 out=network
v.db.update network col=cost qcol="length/(speed*1000/60)"
v.net.iso input=network@isochrones output=isos center_cats=1-3 costs=5,10,15,20,25,30,35,40 arc_column=cost

So cost is the same in both directions. However, the result I get is very different depending on the direction from the starting point (cf attached image - numbers are the categories from v.net.iso, blue circles are the start points).

Attachments (4)

v_net_iso_direction_bug.png (45.0 KB) - added by mlennert 4 years ago.
image showing different result depending on direction
horizontal_line.png (5.2 KB) - added by mlennert 4 years ago.
diagonal_line.png (12.5 KB) - added by mlennert 4 years ago.
vertical_line.png (6.6 KB) - added by mlennert 4 years ago.

Download all attachments as: .zip

Change History (11)

Changed 4 years ago by mlennert

Attachment: v_net_iso_direction_bug.png added

image showing different result depending on direction

comment:1 Changed 4 years ago by mlennert

Apparently the problem arises when lines are diagonal (in comparison to NS or EW direction). Here's a reproducible testcase:

  • horizontal
v.in.lines in=- out=testline sep=, --o << EOF
610000,225000
680000,225000
EOF
echo "645000|225000" | v.in.ascii in=- out=testpoint --o
v.net testline point=testpoint op=connect thresh=500 out=testnet --o
v.db.addtable testnet col="length double precision, cost double precision"
v.to.db testnet op=length col=length
v.db.update testnet col=cost qcol="length/(100*1000/60)"
v.net.iso testnet out=testiso center_cats=1-999 costs=10,20,30,40 arc_column=cost --o
  • diagonal
v.in.lines in=- out=testline sep=, --o << EOF
610000,200000
680000,300000
EOF
echo "645000|225000" | v.in.ascii in=- out=testpoint --o
v.net -s testline point=testpoint op=connect thresh=50000 out=testnet --o
v.db.addtable testnet col="length double precision, cost double precision"
v.to.db testnet op=length col=length
v.db.update testnet col=cost qcol="length/(100*1000/60)"
v.net.iso testnet out=testiso center_cats=1-999 costs=10,20,30,40,50,60,70 arc_column=cost --o
  • vectical
v.in.lines in=- out=testline sep=, --o << EOF
645000,200000
645000,300000
EOF
echo "645000|250000" | v.in.ascii in=- out=testpoint --o
v.net -s testline point=testpoint op=connect thresh=50000 out=testnet --o
v.db.addtable testnet col="length double precision, cost double precision"
v.to.db testnet op=length col=length
v.db.update testnet col=cost qcol="length/(100*1000/60)"
v.net.iso testnet out=testiso center_cats=1-999 costs=10,20,30,40,50,60,70 arc_column=cost --o

I'll attach the respective images. In the diagonal case, the isochrones are much closer towards the South-West (~37km - using the wxgui measuring tool - to reach the beginning of cat=8) than towards the North-East (~78km to reach the beginning of cat=8). As cost is defined via only one column, it should be identical in both directions.

Changed 4 years ago by mlennert

Attachment: horizontal_line.png added

Changed 4 years ago by mlennert

Attachment: diagonal_line.png added

Changed 4 years ago by mlennert

Attachment: vertical_line.png added

comment:2 Changed 4 years ago by neteler

Milestone: 7.0.17.0.2

Ticket retargeted after 7.0.1 milestone closed

comment:3 Changed 4 years ago by neteler

Milestone: 7.0.27.0.3

Ticket retargeted after milestone closed

comment:4 Changed 4 years ago by neteler

Milestone: 7.0.3

Ticket retargeted after milestone closed

comment:5 Changed 4 years ago by neteler

Milestone: 7.0.4

Ticket retargeted after 7.0.3 milestone closed

comment:6 in reply to:  1 Changed 4 years ago by mmetz

Replying to mlennert:

Apparently the problem arises when lines are diagonal (in comparison to NS or EW direction). Here's a reproducible testcase:

  • horizontal
v.in.lines in=- out=testline sep=, --o << EOF
610000,225000
680000,225000
EOF
echo "645000|225000" | v.in.ascii in=- out=testpoint --o
v.net testline point=testpoint op=connect thresh=500 out=testnet --o
v.db.addtable testnet col="length double precision, cost double precision"
v.to.db testnet op=length col=length
v.db.update testnet col=cost qcol="length/(100*1000/60)"
v.net.iso testnet out=testiso center_cats=1-999 costs=10,20,30,40 arc_column=cost --o
  • diagonal
v.in.lines in=- out=testline sep=, --o << EOF
610000,200000
680000,300000
EOF
echo "645000|225000" | v.in.ascii in=- out=testpoint --o
v.net -s testline point=testpoint op=connect thresh=50000 out=testnet --o
v.db.addtable testnet col="length double precision, cost double precision"
v.to.db testnet op=length col=length
v.db.update testnet col=cost qcol="length/(100*1000/60)"
v.net.iso testnet out=testiso center_cats=1-999 costs=10,20,30,40,50,60,70 arc_column=cost --o
  • vectical
v.in.lines in=- out=testline sep=, --o << EOF
645000,200000
645000,300000
EOF
echo "645000|250000" | v.in.ascii in=- out=testpoint --o
v.net -s testline point=testpoint op=connect thresh=50000 out=testnet --o
v.db.addtable testnet col="length double precision, cost double precision"
v.to.db testnet op=length col=length
v.db.update testnet col=cost qcol="length/(100*1000/60)"
v.net.iso testnet out=testiso center_cats=1-999 costs=10,20,30,40,50,60,70 arc_column=cost --o

I'll attach the respective images. In the diagonal case, the isochrones are much closer towards the South-West (~37km - using the wxgui measuring tool - to reach the beginning of cat=8) than towards the North-East (~78km to reach the beginning of cat=8). As cost is defined via only one column, it should be identical in both directions.

The problem/reason is that the length values in the length column are not what you expect. v.net has broken the line where the point has been snapped to. The two new lines have the same category values like the old line, i.e. identical category values, thus one common entry in the attribute table. The length value in the attribute table is thus the sum of the lengths of the two lines. You get results as expected with e.g.

v.in.lines in=- out=testline sep=, --o << EOF
610000,200000
680000,300000
EOF
echo "645000|225000" | v.in.ascii in=- out=testpoint --o
v.net -s testline point=testpoint op=connect thresh=50000 out=testnet_1 --o
v.category in=testnet_1 out=testnet type=line op=add layer=3
v.db.addtable testnet col="length double precision, cost double precision" layer=3
v.to.db testnet op=length col=length layer=3
v.db.update testnet col=cost qcol="length/(100*1000/60)" layer=3
v.net.iso testnet out=testiso center_cats=1-999 costs=10,20,30,40,50,60,70 arc_column=cost arc_layer=3 --o

Here, unique categories are created with v.category in a new layer 3.

v.net keeps the original categories when splitting up a line because these categories can encode important information such as type of the road or speed limit which in turn might be needed for cost calculation. An example is given in the manual for v.net.path.

comment:7 Changed 4 years ago by mlennert

Resolution: invalid
Status: newclosed

Thanks for the explanation. As you said, this is even mentioned in the man page.

Closing the bug as invalid.

Note: See TracTickets for help on using tickets.