pgr_tsp - Traveling Sales Person¶
Name¶
pgr_tsp
- Returns the best route from a start node via a list of nodes.pgr_tsp
- Returns the best route order when passed a disance matrix.pgr_makeDistanceMatrix
- Returns a Eucleadian distance Matrix from the points provided in the sql result.
Synopsis¶
The travelling salesman problem (TSP) or travelling salesperson problem asks the following question: Given a list of cities and the distances between each pair of cities, what is the shortest possible route that visits each city exactly once and returns to the origin city? This algoritm uses simulated annealing to return a high quality approximate solution. Returns a set of pgr_costResult (seq, id1, id2, cost) rows, that make up a path.
pgr_costResult[] pgr_tsp(sql text, start_id integer);
pgr_costResult[] pgr_tsp(sql text, start_id integer, end_id integer);
Returns a set of (seq integer, id1 integer, id2 integer, cost float8) that is the best order to visit the nodes in the matrix. id1
is the index into the distance matrix. id2
is the point id from the sql.
If no end_id
is supplied or it is -1 or equal to the start_id then the TSP result is assumed to be a circluar loop returning back to the start. If end_id
is supplied then the route is assumed to start and end the the designated ids.
record[] pgr_tsp(matrix float[][], start integer)
record[] pgr_tsp(matrix float[][], start integer, end integer)
Description¶
With Euclidean distances
The TSP solver is based on ordering the points using straight line (euclidean) distance [1] between nodes. The implementation is using an approximation algorithm that is very fast. It is not an exact solution, but it is guaranteed that a solution is returned after certain number of iterations.
sql: | a SQL query, which should return a set of rows with the following columns: SELECT id, x, y FROM vertex_table
|
||||||
---|---|---|---|---|---|---|---|
start_id: |
|
||||||
end_id: |
|
The function returns set of pgr_costResult[]:
seq: | row sequence |
---|---|
id1: | internal index to the distance matric |
id2: | id of the node |
cost: | cost to traverse from the current node to the next node. |
Create a distance matrix
For users that need a distance matrix we have a simple function that takes SQL in sql
as described above and returns a record with dmatrix
and ids
.
SELECT dmatrix, ids from pgr_makeDistanceMatrix('SELECT id, x, y FROM vertex_table');
The function returns a record of dmatrix
, ids
:
dmatrix: | float8[][] a symeteric Euclidean distance matrix based on sql . |
---|---|
ids: | integer[] an array of ids as they are ordered in the distance matrix. |
With distance matrix
For users, that do not want to use Euclidean distances, we also provode the ability to pass a distance matrix that we will solve and return an ordered list of nodes for the best order to visit each. It is up to the user to fully populate the distance matrix.
matrix: | float[][] distance matrix of points |
---|---|
start: | int4 index of the start point |
end: | int4 (optional) index of the end node |
The end
node is an optional parameter, you can just leave it out if you want a loop where the start
is the depot and the route returns back to the depot. If you include the end
parameter, we optimize the path from start
to end
and minimize the distance of the route while include the remaining points.
The distance matrix is a multidimensional PostgreSQL array type that must be N x N
in size.
The result will be N records of [ seq, id ]
:
seq: | row sequence |
---|---|
id: | index into the matrix |
Footnotes
[1] | There was some thought given to pre-calculating the driving distances between the nodes using Dijkstra, but then I read a paper (unfortunately I don’t remember who wrote it), where it was proved that the quality of TSP with euclidean distance is only slightly worse than one with real distance in case of normal city layout. In case of very sparse network or rivers and bridges it becomes more inaccurate, but still wholly satisfactory. Of course it is nice to have exact solution, but this is a compromise between quality and speed (and development time also). If you need a more accurate solution, you can generate a distance matrix and use that form of the function to get your results. |
History
- Renamed in version 2.0.0
- GAUL dependency removed in version 2.0.0
Examples¶
- Using SQL parameter (all points from the table, atarting from 6 and ending at 5). We have listed two queries in this example, the first might vary from system to system because there are multiple equivalent answers. The second query should be stable in that the length optimal route should be the same regardless of order.
SELECT seq, id1, id2, round(cost::numeric, 2) AS cost
FROM pgr_tsp('SELECT id, x, y FROM vertex_table ORDER BY id', 6, 5);
seq | id1 | id2 | cost
-----+-----+-----+------
0 | 5 | 6 | 1.00
1 | 6 | 7 | 1.00
2 | 7 | 8 | 1.41
3 | 1 | 2 | 1.00
4 | 0 | 1 | 1.41
5 | 2 | 3 | 1.00
6 | 3 | 4 | 1.00
7 | 8 | 9 | 1.00
8 | 11 | 12 | 1.00
9 | 10 | 11 | 1.41
10 | 12 | 13 | 1.00
11 | 9 | 10 | 2.24
12 | 4 | 5 | 1.00
(13 rows)
SELECT round(sum(cost)::numeric, 4) as cost
FROM pgr_tsp('SELECT id, x, y FROM vertex_table ORDER BY id', 6, 5);
cost
---------
15.4787
(1 row)
- Using distance matrix (A loop starting from 1)
When using just the start node you are getting a loop that starts with 1, in this case, and travels through the other nodes and is implied to return to the start node from the last one in the list. Since this is a circle there are at least two possible paths, one clockwise and one counter-clockwise that will have the same length and be equall valid. So in the following example it is also possible to get back a sequence of ids = {1,0,3,2} instead of the {1,2,3,0} sequence listed below.
SELECT seq, id FROM pgr_tsp('{{0,1,2,3},{1,0,4,5},{2,4,0,6},{3,5,6,0}}'::float8[],1);
seq | id
-----+----
0 | 1
1 | 2
2 | 3
3 | 0
(4 rows)
- Using distance matrix (Starting from 1, ending at 2)
SELECT seq, id FROM pgr_tsp('{{0,1,2,3},{1,0,4,5},{2,4,0,6},{3,5,6,0}}'::float8[],1,2);
seq | id
-----+----
0 | 1
1 | 0
2 | 3
3 | 2
(4 rows)
- Using the vertices table edge_table_vertices_pgr generated by pgr_createTopology. Again we have two queries where the first might vary and the second is based on the overal path length.
SELECT seq, id1, id2, round(cost::numeric, 2) AS cost
FROM pgr_tsp('SELECT id::integer, st_x(the_geom) as x,st_x(the_geom) as y FROM edge_table_vertices_pgr ORDER BY id', 6, 5);
seq | id1 | id2 | cost
-----+-----+-----+------
0 | 5 | 6 | 0.00
1 | 10 | 11 | 0.00
2 | 2 | 3 | 1.41
3 | 3 | 4 | 0.00
4 | 11 | 12 | 0.00
5 | 8 | 9 | 0.71
6 | 15 | 16 | 0.00
7 | 16 | 17 | 2.12
8 | 1 | 2 | 0.00
9 | 14 | 15 | 1.41
10 | 7 | 8 | 1.41
11 | 6 | 7 | 0.71
12 | 13 | 14 | 2.12
13 | 0 | 1 | 0.00
14 | 9 | 10 | 0.00
15 | 12 | 13 | 0.00
16 | 4 | 5 | 1.41
(17 rows)
SELECT round(sum(cost)::numeric, 4) as cost
FROM pgr_tsp('SELECT id::integer, st_x(the_geom) as x,st_x(the_geom) as y FROM edge_table_vertices_pgr ORDER BY id', 6, 5);
cost
---------
11.3137
(1 row)
The queries use the Sample Data network.