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

[Pedro Venâncio]

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?

Thanks!

Best regards,
Pedro
-------------- próxima parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160223/92944d81/attachment.html>