// the find
pgRouting/pgrouting
Repository contains pgRouting library. Development branch is "develop", stable branch is "master"
pgRouting is a PostgreSQL extension that sits on top of PostGIS and exposes graph routing and network analysis as SQL functions. It's the standard choice if you need Dijkstra, A*, TSP, max-flow, or contraction hierarchies without leaving your database. Aimed at GIS developers building navigation, logistics, or network analysis features who already run PostGIS.
- Algorithm breadth is genuinely impressive: bidirectional Dijkstra and A*, Yen's K-shortest paths, Chinese Postman, flow algorithms (Boykov-Kolmogorov, push-relabel, Edmonds-Karp), contraction hierarchies, and VRP all ship as first-class SQL functions — you'd need multiple libraries to match this outside the DB.
- The 'withPoints' family solves the real-world problem of snapping arbitrary GPS coordinates onto road segments without requiring exact node IDs, which is the first thing navigation code actually needs and most toy routing examples skip.
- Turn restriction support via TRSP (Turn Restriction Shortest Path) is included and documented — missing from most simpler implementations but essential for any realistic road network.
- Active CI matrix (Ubuntu, CentOS, macOS, Windows) with doc-query tests that actually run SQL against a live DB to verify examples — the kind of test discipline that catches silent breakage in a C extension.
- The SQL API requires passing inner SQL as untyped strings — `pgr_dijkstra('SELECT id, source, target, cost FROM edges', 1, 5)` — so schema mismatches produce cryptic C-level errors with no column name context. Debugging wrong-column issues is painful.
- No incremental graph update mechanism: the graph is rebuilt from table data on every query. For dynamic scenarios (live traffic, frequent edge weight changes), you're re-scanning the whole edges table each time, which gets expensive at scale.
- Build requirements are annoying: Boost version determines C++ standard requirement (pre-1.75 needs C++03/11, 1.75+ needs C++14), plus PostGIS, CMake ≥ 3.12, and Sphinx for docs. Getting a consistent build across environments takes real effort.
- TSP is heuristic-only (no exact solver); the docs are honest about it, but if you need an optimal route for small instances (say, < 20 stops), you'll want a dedicated solver and pgRouting won't tell you how far off its answer is.