[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 <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
>
>
>
-------------- próxima parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160224/a23c8716/attachment-0001.html>
-------------- próxima parte ----------
A non-text attachment was scrubbed...
Name: v.net.distance.jpg
Type: image/jpeg
Size: 18947 bytes
Desc: não disponível
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160224/a23c8716/attachment-0001.jpg>