<div dir="ltr"><div><div><div><div><div>Hi Moritz,<br><br></div>Thank you for your test!<br><br></div>Can you try to run v.net.distance with the same sample data?<br><br>v.net.distance --overwrite input=mynet@PERMANENT output=distance_7779_7780 from_layer=2 from_cats=7779 to_layer=2 to_cats=7780 arc_column=FT_COST arc_backward_column=TF_COST<br><br>v.net.distance --overwrite input=mynet@PERMANENT output=distance_7780_7779 from_layer=2 from_cats=7780 to_layer=2 to_cats=7779 arc_column=FT_COST arc_backward_column=TF_COST<br><br></div></div>In the image attached, green line is the result of the first run (from_layer=2 from_cats=7779 to_layer=2 to_cats=7780), and red line is the result of (from_layer=2 from_cats=7780 to_layer=2 to_cats=7779).<br><br>It seems that it calculates the route in the reverse way. What do you think?<br><br></div><div>Thank you very much!<br><br></div><div>Best regards,<br></div><div>Pedro<br><br></div><div><br></div><br><div><div><div><br><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-23 16:27 GMT+00:00 Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 23/02/16 15:44, Pedro Venâncio wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I was testing the v.net.distance (in QGIS) and noticed something<br>
strange. Apparently the route is calculated in a reverse way.<br>
<br>
If you see in this screencast<br>
<br>
<a href="https://dl.dropboxusercontent.com/u/5772257/qgis/processing_grass_v_net_distance.ogv" rel="noreferrer" target="_blank">https://dl.dropboxusercontent.com/u/5772257/qgis/processing_grass_v_net_distance.ogv</a><br>
<br>
<br>
I have a network of streets with two-way (green) and some with only<br>
one-way (in red, with the arrow indicating the direction of traffic).<br>
The two-way cost is in "dois_senti" field of the attribute table, and<br>
the sections of one-way have -1 value in the "um_senti" field of the<br>
attribute table.<br>
<br>
The starting point is the orange pentagon ("ponto_inicio"), and the<br>
destination point is the green star ("ponto_chegada").<br>
<br>
As you can see, v.net.distance calculate the route in the reverse way,<br>
that is, when I choose "ponto_inicio" as "from", and "ponto_chegada" as<br>
"to" (first run in the screencast), it gives me the route by the south<br>
("ponto_chegada" -> "ponto_inicio"). In the second run, I choose<br>
"ponto_chegada" as "from", and "ponto_inicio" as "to", and it uses the<br>
one-way street. So, the topology is respected, but it seems that "from"<br>
and "to" are used in a reverse manner.<br>
<br>
I thought it might be a mistake in implementing the tool in QGIS<br>
Processing, but then I performed the same procedure on GRASS 7.0.2<br>
native, and the result is the same.<br>
<br>
Médéric Ribreux has done also some tests and concluded that from_layer<br>
is used as to_layer.<br>
<br>
It seems to be a GRASS problem because the point layers order is correct:<br>
- layer 2 is imported from FROM_CENTERS QGIS layer.<br>
- layer 3 is imported from TO_CENTERS QGIS layer.<br>
- layer 2 is used as from_layer in v.net.distance.<br>
- layer 3 is used as to_layer in v.net.distance.<br>
<br>
He has tried with v.net.path and got the same results than for<br>
v.net.distance.<br>
<br>
Could it be a mis-interpretation of forward and backward costs? A bug?<br>
Or simply how the tool works?<br>
</blockquote>
<br>
<br></div></div>
I cannot reproduce this with the NC demo data set;<br>
<br>
<a href="http://v.net" rel="noreferrer" target="_blank">v.net</a> -c streets_wake op=nodes out=mynet<br>
v.db.update map=mynet@user1 column=TF_COST value=-1 where=ONE_WAY='FT'<br>
v.db.update map=mynet@user1 column=FT_COST value=-1 where=ONE_WAY='TF'<br>
echo "1 7779 7780<br>
<a href="tel:2%207780%207779" value="+351277807779" target="_blank">2 7780 7779</a>" | v.net.path mynet out=paths arc_column=FT_COST arc_backward_column=TF_COST<br>
<br>
Display:<br>
d.vect map=mynet@user1<br>
d.vect map=mynet@user1 display=shape,dir where="ONE_WAY='FT' OR ONE_WAY='TF'" color=red attribute_column=ONE_WAY yref=top<br>
d.vect map=mynet@user1 layer=2 display=shape,cat cats=7779-7780 fill_color=255:165:0 icon=basic/circle label_layer=2<br>
d.vect map=paths@user1 display=shape,cat cats=1 color=0:128:0 width=2 label_color=0:128:0<br>
d.vect map=paths@user1 display=shape,cat cats=2 color=128:0:128 width=2 label_color=128:0:128<br>
<br>
gives the expected result (see attached image).<br>
<br>
Note that the line connecting 7779 and 7780 directly has a one_way value of 'TF' meaning that it is one-way in direction to-from, i.e. from 7780 to 7779 (direction of the line being indicated by the arrows).<br>
<br>
Errors can occur if the costs are not well-defined or too small. In the source code of the Vect_net_build_graph() function which builds the network graph the path is found upon, it says:<br>
<br>
"Internal format for edge costs is integer, costs are multiplied before conversion to int by 1000"<br>
<br>
This means that if you have a cost lower than 1/1000, you might end up with costs = 0.<br>
<br>
This is noted as a todo in the source code:<br>
<br>
"/* TODO int costs -> double (waiting for dglib) */"<br>
<br>
But AFAICS, dglib still uses integers for costs.<br>
<br>
This is not mentioned in the man page, and should be.<br>
<br>
Please verify if this is the origin of your problem.<br>
<br>
If yes, please post a bug report on bad documentation. If this isn't the problem, please post a bug report with a reproducible example.<span class="HOEnZb"><font color="#888888"><br>
<br>
Moritz<br>
<br>
<br>
</font></span></blockquote></div><br></div>