[GRASS-dev] v.net.distance/path calculate the route in the reverse way

[Moritz Lennert]

On 23/02/16 15:44, Pedro Venâncio wrote:
> Hi,
>
> I was testing the v.net.distance (in QGIS) and noticed something
> strange. Apparently the route is calculated in a reverse way.
>
> If you see in this screencast
>
> https://dl.dropboxusercontent.com/u/5772257/qgis/processing_grass_v_net_distance.ogv
>
>
> I have a network of streets with two-way (green) and some with only
> one-way (in red, with the arrow indicating the direction of traffic).
> The two-way cost is in "dois_senti" field of the attribute table, and
> the sections of one-way have -1 value in the "um_senti" field of the
> attribute table.
>
> The starting point is the orange pentagon ("ponto_inicio"), and the
> destination point is the green star ("ponto_chegada").
>
> As you can see, v.net.distance calculate the route in the reverse way,
> that is, when I choose "ponto_inicio" as "from", and "ponto_chegada" as
> "to" (first run in the screencast), it gives me the route by the south
> ("ponto_chegada" -> "ponto_inicio"). In the second run, I choose
> "ponto_chegada" as "from", and "ponto_inicio" as "to", and it uses the
> one-way street. So, the topology is respected, but it seems that "from"
> and "to" are used in a reverse manner.
>
> I thought it might be a mistake in implementing the tool in QGIS
> Processing, but then I performed the same procedure on GRASS 7.0.2
> native, and the result is the same.
>
> Médéric Ribreux has done also some tests and concluded that from_layer
> is used as to_layer.
>
> It seems to be a GRASS problem because the point layers order is correct:
> - layer 2 is imported from FROM_CENTERS QGIS layer.
> - layer 3 is imported from TO_CENTERS QGIS layer.
> - layer 2 is used as from_layer in v.net.distance.
> - layer 3 is used as to_layer in v.net.distance.
>
> He has tried with v.net.path and got the same results than for
> v.net.distance.
>
> Could it be a mis-interpretation of forward and backward costs? A bug?
> Or simply how the tool works?


I cannot reproduce this with the NC demo data set;

v.net -c streets_wake op=nodes out=mynet
v.db.update map=mynet at user1 column=TF_COST value=-1 where=ONE_WAY='FT'
v.db.update map=mynet at user1 column=FT_COST value=-1 where=ONE_WAY='TF'
echo "1 7779 7780
2 7780 7779" | v.net.path mynet out=paths arc_column=FT_COST 
arc_backward_column=TF_COST

Display:
d.vect map=mynet at user1
d.vect map=mynet at user1 display=shape,dir where="ONE_WAY='FT' OR 
ONE_WAY='TF'" color=red attribute_column=ONE_WAY yref=top
d.vect map=mynet at user1 layer=2 display=shape,cat cats=7779-7780 
fill_color=255:165:0 icon=basic/circle label_layer=2
d.vect map=paths at user1 display=shape,cat cats=1 color=0:128:0 width=2 
label_color=0:128:0
d.vect map=paths at user1 display=shape,cat cats=2 color=128:0:128 width=2 
label_color=128:0:128

gives the expected result (see attached image).

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

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:

"Internal format for edge costs is integer, costs are multiplied before 
conversion to int by 1000"

This means that if you have a cost lower than 1/1000, you might end up 
with costs = 0.

This is noted as a todo in the source code:

"/* TODO int costs -> double (waiting for dglib) */"

But AFAICS, dglib still uses integers for costs.

This is not mentioned in the man page, and should be.

Please verify if this is the origin of your problem.

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.

Moritz


-------------- next part --------------
A non-text attachment was scrubbed...
Name: v_net_path_example.png
Type: image/png
Size: 29587 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160223/99b776f0/attachment-0001.png>