Routing algorithms may be used with some more imagination that the actual road related routing - it is just a matter of defining a specific meaning of a cost of traveling via an edge. With the appropriate data, one can build routing solutions for hiking paths, calculate routes that avoid built-up areas, or take into account some road works that add penalty costs to some edges. It is also possible to calculate drive time zones, and from there, one could go on to defining the best locations of service centers.

As we saw, using pgRouting is rather straightforward and its usage is usually down to select * from <routing_algorythm> (<SQL for edges>, start, end, <options>). This makes it very easy to start with and then, as one becomes more familiar with the available functionality, to tweak the function parameters in order to improve the achieved results.

Exposing the functionality of pgRouting via web services is also quite simple, and from there, we're just a step away from consuming such services by external clients.

To summarize this into two words: pgRouting rocks (as well as PostGIS of course)!

As a final note it is worth remembering that, for larger graphs, it is good practice to work on a subset of the data for better performance - one could pre-filter the data with a bounding box to limit the number of edges to work with.