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 <[email protected]>: > 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 [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
