I recently worked with pgRouting on a graph that contained around 31 millions of edges and got nice results in terms of computation time (a few seconds). You're doing a really nice job for those who want to compute routes in a database context!
Anyway, in a lot of routing situations, we want to get results in less than one second, and I was wondering if some optimization could be possible for pgRouting.
TL;DR
I read on the GsoC 2022 program that implementing Contraction Hierarchies is still a valid idea. Hence comes my question: are you interested in a contribution on that topic? Do you still consider the Contraction Hierarchies algorithm has an added value for pgRouting?
Contraction in pgRouting
Knowing that Contraction Hierarchies are a game changer for fast routing purpose, I was wondering if they were implemented in pgRouting. Then I read the pgRouting documentation, digged into the pgRouting mailing list archive and read #440 (which confuses me a bit).
By cross-referencing information from the GsoC 2016 contraction report, I understand that the implemented features are dead end and linear contractions, and that Contraction Hierarchies are not implemented. Is it correct?
Another confusing point for me is that there are CH vertices, CH edges and CH graphs in the pgRouting API: in this context I hypothesize that "CH" means "Contraction Hierarchies", but I may be wrong?
Improvement
As far as I understand the different contraction algorithms, there is a seminal difference between the pgRouting contractions and the Contraction Hierarchies. While the formers act on the graph topology, the latter considers the edge weights and evaluates every vertex in the graph in order to build a node ordering (the higher the node is in the hierarchy, the less likely its contraction is). Of course, it means that the contracted graph is valid as long as the weights are static.
In order to implement Contraction Hierarchies, one should first implement this node ordering procedure, whose outputs are a set of shortcuts (as in other contraction algorithms) and a rank in the hierarchy for each vertex (this is the big difference). This preprocessing could be another contraction referenced in include/contraction/pgr_contract.hpp.
Then comes the routing query itself, that has to be run in the ordered graph (with shortcuts). This query algorithm is closed to a bidirectional Dijkstra, but highly depends on the vertex ordering. I do not know where could be the best place for such a querying algorithm; could a brand new chquery subfolder do the job?
External resources
The Contraction Hierarchies is mainly described by the following papers:
As a side note, there is a Github repo handled by the research team, with (amongst other things) a C++ implementation of Contraction Hierarchies. Considering this could help to design a proof of concept within the pgRouting API.
Hello the pgRouting team,
I recently worked with pgRouting on a graph that contained around 31 millions of edges and got nice results in terms of computation time (a few seconds). You're doing a really nice job for those who want to compute routes in a database context!
Anyway, in a lot of routing situations, we want to get results in less than one second, and I was wondering if some optimization could be possible for pgRouting.
TL;DR
I read on the GsoC 2022 program that implementing Contraction Hierarchies is still a valid idea. Hence comes my question: are you interested in a contribution on that topic? Do you still consider the Contraction Hierarchies algorithm has an added value for pgRouting?
Contraction in pgRouting
Knowing that Contraction Hierarchies are a game changer for fast routing purpose, I was wondering if they were implemented in pgRouting. Then I read the pgRouting documentation, digged into the pgRouting mailing list archive and read #440 (which confuses me a bit).
By cross-referencing information from the GsoC 2016 contraction report, I understand that the implemented features are dead end and linear contractions, and that Contraction Hierarchies are not implemented. Is it correct?
Another confusing point for me is that there are CH vertices, CH edges and CH graphs in the pgRouting API: in this context I hypothesize that "CH" means "Contraction Hierarchies", but I may be wrong?
Improvement
As far as I understand the different contraction algorithms, there is a seminal difference between the pgRouting contractions and the Contraction Hierarchies. While the formers act on the graph topology, the latter considers the edge weights and evaluates every vertex in the graph in order to build a node ordering (the higher the node is in the hierarchy, the less likely its contraction is). Of course, it means that the contracted graph is valid as long as the weights are static.
In order to implement Contraction Hierarchies, one should first implement this node ordering procedure, whose outputs are a set of shortcuts (as in other contraction algorithms) and a rank in the hierarchy for each vertex (this is the big difference). This preprocessing could be another contraction referenced in include/contraction/pgr_contract.hpp.
Then comes the routing query itself, that has to be run in the ordered graph (with shortcuts). This query algorithm is closed to a bidirectional Dijkstra, but highly depends on the vertex ordering. I do not know where could be the best place for such a querying algorithm; could a brand new
chquerysubfolder do the job?External resources
The Contraction Hierarchies is mainly described by the following papers:
As a side note, there is a Github repo handled by the research team, with (amongst other things) a C++ implementation of Contraction Hierarchies. Considering this could help to design a proof of concept within the pgRouting API.