TSP with fixed source & destination

[levifelling]

Extending TSP solver to support the case where both the source and
destination nodes are specified.

I'm not sure if this case is covered somewhere already, but I didn't see a way to do it. I needed to solve TSP for multiple locations between a fixed start and end point. My solution is fairly trivial, I simply added new seed (tspd_seed) and score (tspd_score) functions to tsp_solver to handle the case where a destination is specified. There is probably a cleaner way to do this, but my C programming skills are limited.

[dkastl]

Hi Levi,
Thanks for this idea and patch! I think this use case makes sense.
So basically you extended the current TSP function by one parameter, right? If one doesn't provide this parameter, will it still work as before?

[levifelling]

Correct, omitting the destination param will fall back to the existing tsp
logic.
On Nov 18, 2011 7:52 PM, "Daniel Kastl" <
reply@reply.github.com>
wrote:

Hi Levi,
Thanks for this idea and patch! I think this use case makes sense.
So basically you extended the current TSP function by one parameter,
right? If one doesn't provide this parameter, will it still work as before?

---

Reply to this email directly or view it on GitHub:
#49 (comment)

[timmy85]

Will it work if I just install the routing_tsp.sql file or what do I have to do more to get it to work?

[levifelling]

You will need to grab the modified C src files, build the updated pgrouting library from source, then apply the routing_tsp.sql patch to your database.

[timmy85]

Thanks for quick answer! I will test that on monday!

9 mar 2012 kl. 14.25 skrev Levi Felling:

You will need to grab the modified C src files, build the updated pgrouting library from source, then apply the routing_tsp.sql patch to your database.

---

Reply to this email directly or view it on GitHub:
#49 (comment)

[timmy85]

I've managed to get it to work but the tsp is working for about 2 seconds when run it with 25 nodes and I think the result isnt that great. I had the same problem with the original tsp.
Now Im trying tsp_dijkstra but the "relation tsp_test does not exist".
Can I somehow make the tsp function work longer and get better results? Am I doing something wrong? The sql is working but I think it is impossible to get a good route in that short time

[darekgorski]

Hi Timmy,
I've conducted some tests and I've got tsp results in about 500 ms with 25 nodes.
My configuration: VM VirtualBox with Ubuntu Server 11.10 (512MB RAM), PostgreSQL 9.1.3 (default postgresql.conf), Postgis 1.5.3.
Routing table with about 6000 nodes.

In order to use tsp wrappers you have to either change in them table name from "tsp_test" to " ' || quote_ident(geom_table) || ' " (but there is problem with dead nodes) or prepare separate table with nodes ids and its coordinates.
I'm using vertices_tmp table generated by assign_vertex_id() function with additional x and y columns.

According to tsp documentation:
"The tsp solution is based on ordering the points using straight line (euclidean) distance between nodes... It is not an exact solution..."

[woodbri]

I just replaced the TSP solver so we are no longer dependent on the GAUL libs, see SHA: 0876b70 The new solver assume that the nodes will be in a loop. You can specify a start point like before. I'll have to look into how make it work with an endpoint. If anyone wants to take a pass at that I would love the help, as I have a lot of other 2.0 issues to deal with.

[woodbri]

I just committed change to develop that now support an optional end point if you want to optimize a point to point route instead of a loop from a depot.