landam / grass-gis-git-migration-test

0 stars 0 forks source link

v.net.salesman and forward/backward movement cost #57

Open landam opened 5 years ago

landam commented 5 years ago

Reported by lluis on 9 May 2011 13:59 UTC I'm doing some '''network analysis''' with GRASS GIS and I'm surprised because is not possible to consider forward/backward costs movements in v.net.salesman as it is possible with the v.net.path module. I would like to see this option in upcoming releases of GRASS because I believe that this enhancement could be so valuable for grass users

I'm working with streets of a city, so distinguish between one-way streets and bidirectional streets is something critical for me.

I'm working with grass 6.4.2svn under Ubuntu Congratulations for your work

Llus

Operating system

Linux

Migrated-From: https://trac.osgeo.org/grass/ticket/1357

landam commented 5 years ago

Attachment from mlennert on 10 May 2011 15:21 UTC commands used for testing https://trac.osgeo.org/grass/attachment/ticket/1357/v_net_salesman_test.sh

landam commented 5 years ago

Comment by mmetz on 10 May 2011 12:55 UTC Implemented in grass 7, https://trac.osgeo.org/grass/changeset/46229, please test!

Markus M

landam commented 5 years ago

Comment by mlennert on 10 May 2011 15:18 UTC Replying to [comment:1 mmetz]:

Implemented in grass 7, https://trac.osgeo.org/grass/changeset/46229, please test!

Here are the results of an abritrary test on in the NC demo dataset:

http://geog-pc40.ulb.ac.be/grass/equalcost.png equal cost in both directions

http://geog-pc40.ulb.ac.be/grass/diffcost.png different cost in each direction for one way streets

I'll attach the script with the relevant commands I used.

At first view, the results seem to be coherent, but probably need more detailed testing.

Moritz

landam commented 5 years ago

Comment by Lluis on 11 May 2011 07:24 UTC Great! It seems to work properly. I've been doing some tests using open street map cartography, and it seems that I'm getting valid results. I will try to do more tests but it seems to work correctly.

Thanks a lot for your work and effort, Moritz!

Llus

Replying to [comment:2 mlennert]:

Replying to [comment:1 mmetz]:

Implemented in grass 7, https://trac.osgeo.org/grass/changeset/46229, please test!

Here are the results of an abritrary test on in the NC demo dataset:

http://geog-pc40.ulb.ac.be/grass/equalcost.png equal cost in both directions

http://geog-pc40.ulb.ac.be/grass/diffcost.png different cost in each direction for one way streets

I'll attach the script with the relevant commands I used.

At first view, the results seem to be coherent, but probably need more detailed testing.

Moritz

landam commented 5 years ago

Comment by mlennert on 11 May 2011 08:51 UTC Replying to [comment:3 Lluis]:

Thanks a lot for your work and effort, Moritz!

Markus did the work, I just did the testing, so I think the thanks should go to him. ;-)

I think this should be backported at least to grass6dev.

Moritz

landam commented 5 years ago

Comment by mmetz on 11 May 2011 09:10 UTC Replying to [comment:4 mlennert]:

Replying to [comment:3 Lluis]:

Thanks a lot for your work and effort, Moritz!

Markus did the work, I just did the testing, so I think the thanks should go to him. ;-)

Thanks to both of you for additional testing!

I think this should be backported at least to grass6dev.

OK.

BTW, there is also v.net.steiner using the same cost for both directions, no option to define different forward/backward moving costs.

Markus M

landam commented 5 years ago

Comment by mlennert on 11 May 2011 09:37 UTC Replying to [comment:5 mmetz]:

Replying to [comment:4 mlennert]:

Replying to [comment:3 Lluis]:

Thanks a lot for your work and effort, Moritz!

Markus did the work, I just did the testing, so I think the thanks should go to him. ;-)

Thanks to both of you for additional testing!

I think this should be backported at least to grass6dev.

OK.

BTW, there is also v.net.steiner using the same cost for both directions, no option to define different forward/backward moving costs.

Another module where this might be an issue is v.net.components. Actually there is no cost parameter at all in this module, but strong or weak connection is defined by direction, and I don't understand how this direction is defined.

Moritz

landam commented 5 years ago

Comment by neteler on 23 Nov 2015 06:30 UTC What is the state here? G7 done and G6 wontfix?

landam commented 5 years ago

Comment by mlennert on 23 Nov 2015 09:08 UTC Replying to [comment:7 neteler]:

What is the state here? G7 done and G6 wontfix?

I would definitely say wontfix for G6. For G7, v.net.steiner still does not have directions, so as a reminder maybe this bug should either be renamed, or a different bug opened for v.net.steiner.

landam commented 5 years ago

Modified by @landam on 12 May 2016 06:42 UTC

landam commented 5 years ago

Modified by @landam on 25 Aug 2016 15:51 UTC

landam commented 5 years ago

Comment by @landam on 27 Aug 2016 13:42 UTC Milestone renamed

landam commented 5 years ago

Comment by neteler on 26 Jan 2018 11:40 UTC Ticket retargeted after milestone closed

landam commented 5 years ago

Modified by neteler on 12 Jun 2018 20:48 UTC

landam commented 5 years ago

Comment by @landam on 25 Sep 2018 16:51 UTC All enhancement tickets should be assigned to 7.6 milestone.

landam commented 5 years ago

Comment by @landam on 25 Jan 2019 21:07 UTC Ticket retargeted after milestone closed