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

[Moritz Lennert]

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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Pedro Venâncio]

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






2016-02-23 16:27 GMT+00:00 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@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
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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@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


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev