pgRouting was first called *pgDijkstra*, because it implemented only shortest
path search with *Dijkstra* algorithm. Later other functions were added and the
library was renamed to pgRouting. This chapter will cover selected pgRouting
algorithms and some of the attributes required.

- pgr_dijkstra
- Exercise 1 - Single Pedestrian Routing.
- Exercise 2 - Many Pedestrians going to the same destination.
- Exercise 3 - Many Pedestrians departing from the same location.
- Exercise 4 - Many Pedestrians going to different destinations.

- pgr_dijkstraCost
- Exercise 5 - Many Pedestrians going to different destinations, interested only on the aggregate cost.

- pgr_astar
- Exercise 6 Single Pedestrian Routing with A*.

Dijkstra algorithm was the first algorithm implemented in pgRouting. It doesn’t
require other attributes than `id`

, `source`

and `target`

ID and `cost`

.
You can specify when to consider the graph as directed or undirected.

Signature Summary

```
pgr_dijkstra(edges_sql, start_vid, end_vid)
pgr_dijkstra(edges_sql, start_vid, end_vid, directed)
pgr_dijkstra(edges_sql, start_vid, end_vids, directed)
pgr_dijkstra(edges_sql, start_vids, end_vid, directed)
pgr_dijkstra(edges_sql, start_vids, end_vids, directed)
RETURNS SET OF (seq, path_seq [, start_vid] [, end_vid], node, edge, cost, agg_cost)
OR EMPTY SET
```

Description of the parameters can be found in pgr_dijkstra.

Note

- Many pgRouting functions have
`sql::text`

as one of their arguments. While this may look confusing at first, it makes the functions very flexible as the user can pass any`SELECT`

statement as function argument as long as the returned result contains the required number of attributes and the correct attribute names. - Most of pgRouting implemeted algorithms do not require the network geometry.
- Most of pgRouting functions do not return a geometry, but only an ordered list of nodes.

Identifiers for the Queries

The assignment of the vertices identifiers on the source and target columns may be different, the following exercises will use the results of this query. For the workshop, some locations of the FOSS4G Bonn event are going to be used. These locations are within this area http://www.openstreetmap.org/#map=15/50.7101/7.1262

```
SELECT osm_id, id FROM ways_vertices_pgr
WHERE osm_id IN (33180347, 253908904, 332656435, 3068609695, 277708679)
ORDER BY osm_id;
osm_id | id
------------+-------
33180347 | 13224
253908904 | 6549
277708679 | 6963
332656435 | 1458
3068609695 | 9224
(4 rows)
```

The corresponding `id`

, used in the workshop, and a sample route:

Exercise 1 - “Single pedestrian routing”

- The pedestrian wants to go from vertex
`13224`

to vertex`6549`

. - The pedestrian’s cost is in terms of length. In this case
`length`

, which was calculated by osm2pgrouting, is in unit`degrees`

. - From a pedestrian perspective the graph is
`undirected`

, that is, the pedestrian can move in both directions on all segments.

```
SELECT * FROM pgr_dijkstra('
SELECT gid AS id,
source,
target,
length AS cost
FROM ways',
13224, 6549, directed := false);
```

Note

- With more complex SQL statements, using JOINs for example, the result may be
in a wrong order. In that case
`ORDER BY seq`

will ensure that the path is in the right order again. - The returned cost attribute represents the cost specified in the
`edges_sql::text`

argument. In this example cost is`length`

in unit “degrees”. Cost may be time, distance or any combination of both or any other attributes or a custom formula. `node`

and`edge`

results may vary depending on the assignment of the identifiers to the vertices given by osm2pgrouting.

Exercise 2 - “Many Pedestrians going to the same destination.”

- The pedestrians are located at vertices
`6549`

,`1458`

and`9224`

. - All pedestrians want to go to vertex
`13224`

. - The cost to be in meters using attribute
`length_m`

.

```
SELECT * FROM pgr_dijkstra('
SELECT gid AS id,
source,
target,
length_m AS cost
FROM ways',
ARRAY[6549, 1458, 9224], 13224, directed := false);
```

Exercise 3 - “Many Pedestrians departing from the same location”

- All pedestrians are starting from vertex
`13224`

. - The pedestrians want to go to locations
`6549`

,`1458`

and`9224`

. - The cost to be in seconds, with a walking speed
`s = 1.3 m/s`

and`t = d/s`

```
SELECT * FROM pgr_dijkstra('
SELECT gid AS id,
source,
target,
length_m / 1.3 AS cost
FROM ways',
13224, ARRAY[6549, 1458, 9224], directed := false);
```

Exercise 4 - “Many Pedestrians going to different destinations.”

- The pedestrians are located at vertices
`6549`

,`1458`

and`9224`

. - The pedestrians want to go to destinations
`13224`

or`6963`

. - The cost to be in minutes, with a walking speed
`s = 1.3 m/s`

and`t = d/s`

```
SELECT * FROM pgr_dijkstra('
SELECT gid AS id,
source,
target,
length_m / 1.3 / 60 AS cost
FROM ways',
ARRAY[6549, 1458, 9224],
ARRAY[13224, 6963],
directed := false);
```

Note

Inspecting the results, looking for totals (when edge = -1):

- If they go to vertex 13224: the total time would be approximately:
`58.54119347 = 19.9557289926127 + 6.63986000245047 + 31.9456044752323`

- If they go to vertex 6963: the total time would be approximately:
`41.268599693 = 13.5539128131556 + 8.34274572465808 + 19.3719411554243`

When the main goal is to calculate the total cost, for example to calculate
multiple routes for a cost matrix, then `pgr_dijkstraCost`

returns a more
compact result.

Signature Summary

```
pgr_dijkstraCost(edges_sql, start_vid, end_vid)
pgr_dijkstraCost(edges_sql, start_vid, end_vid, directed)
pgr_dijkstraCost(edges_sql, start_vid, end_vids, directed)
pgr_dijkstraCost(edges_sql, start_vids, end_vid, directed)
pgr_dijkstraCost(edges_sql, start_vids, end_vids, directed)
RETURNS SET OF (start_vid, end_vid, agg_cost)
OR EMPTY SET
```

Description of the parameters can be found in pgr_dijkstraCost

Exercise 5 - “Many Pedestrians going to different destinations returning aggregate costs.”

- The pedestrians are located at vertices
`6549`

,`1458`

and`9224`

. - The pedestrians want to go to destinations
`13224`

or`6963`

. - The cost to be in minutes, with a walking speed
`s = 1.3 m/s`

and`t = d/s`

- Result as aggregated costs.

```
SELECT *
FROM pgr_dijkstraCost('
SELECT gid AS id,
source,
target,
length_m / 1.3 / 60 AS cost
FROM ways',
ARRAY[6549, 1458, 9224],
ARRAY[13224, 6963],
directed := false) ORDER BY end_vid;
```

A-Star algorithm is another well-known routing algorithm. It adds geographical information to source and target of each network link. This enables the routing query to prefer links which are closer to the target of the shortest path search.

Signature Summary

```
pgr_costResult[] pgr_astar(sql text, source integer, target integer, directed boolean, has_rcost boolean);
```

Returns a set of `pgr_costResult`

(seq, id1, id2, cost) rows, that make up a path.

Description of the parameters can be found in pgr_astar.

Exercise 6 - “Single Pedestrian Routing with Astar.”

- The pedestrian wants to go from vertex
`13224`

to vertex`6549`

. - The pedestrian’s cost is length, in this case
`length`

is in`degrees`

.

```
SELECT seq, id1 AS node, id2 AS edge, cost FROM pgr_astar('
SELECT gid::integer AS id,
source::integer,
target::integer,
length::double precision AS cost,
x1, y1, x2, y2
FROM ways',
13224, 6549, false, false);
```

Note

- The result of Dijkstra and A-Star might not be the same, because of the heuristic component.
- A-Star is theoretically faster than Dijkstra algorithm as the network size is getting larger.
- A new Version of A-Star is under development.

There are many other functions available with the latest pgRouting release, most of them work in similar ways. For the complete list of pgRouting functions see the API documentation: http://docs.pgrouting.org/