v.net.iso: different results depending on direction

[mlennert]

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).

[mlennert]

image showing different result depending on direction

[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.

[neteler]

Ticket retargeted after 7.0.1 milestone closed

[neteler]

Ticket retargeted after milestone closed

[neteler]

Ticket retargeted after milestone closed

[neteler]

Ticket retargeted after 7.0.3 milestone closed

[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.

[mlennert]

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

Closing the bug as invalid.