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

GRASS GIS GRASS GIS developer
,
1

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

2

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@user1 column=TF_COST value=-1 where=ONE_WAY='FT'
v.db.update map=mynet@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@user1
d.vect map=mynet@user1 display=shape,dir where="ONE_WAY='FT' OR ONE_WAY='TF'" color=red attribute_column=ONE_WAY yref=top
d.vect map=mynet@user1 layer=2 display=shape,cat cats=7779-7780 fill_color=255:165:0 icon=basic/circle label_layer=2
d.vect map=paths@user1 display=shape,cat cats=1 color=0:128:0 width=2 label_color=0:128:0
d.vect map=paths@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

(attachments)

v_net_path_example.png

3

Hi Moritz,

Thank you for your test!

Can you try to run v.net.distance with the same sample data?

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

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

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

It seems that it calculates the route in the reverse way. What do you think?

Thank you very much!

Best regards,

Pedro

(attachments)

v.net.distance.jpg

···

2016-02-23 16:27 GMT+00:00 Moritz Lennert <mlennert@club.worldonline.be>:

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@user1 column=TF_COST value=-1 where=ONE_WAY=‘FT’
v.db.update map=mynet@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@user1
d.vect map=mynet@user1 display=shape,dir where=“ONE_WAY=‘FT’ OR ONE_WAY=‘TF’” color=red attribute_column=ONE_WAY yref=top
d.vect map=mynet@user1 layer=2 display=shape,cat cats=7779-7780 fill_color=255:165:0 icon=basic/circle label_layer=2
d.vect map=paths@user1 display=shape,cat cats=1 color=0:128:0 width=2 label_color=0:128:0
d.vect map=paths@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

4

On 24/02/16 01:53, Pedro Venâncio wrote:

Hi Moritz,

Thank you for your test!

Can you try to run v.net.distance with the same sample data?

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

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

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

It seems that it calculates the route in the reverse way. What do you think?

I confirm. I've created a bug report: https://trac.osgeo.org/grass/ticket/2936.

Moritz