Hi @cvvergara , @robe
Following our community bonding discussion about the cost concern, I did a deep audit of the codebase. Here are my findings and I’d appreciate your guidance on following:
1] pgr_contraction vs planar augmentation
In our meeting you mentioned pgr_contraction as a reference . I studied it carefully and found a key difference:
pgr_contraction creates shortcut edges that replace existing paths. For example, when path u → v → w is contracted, the shortcut u → w gets cost = cost(u→v) + cost(v→w). This is mathematically exact : pgr_dijkstra on the contracted graph produces the same shortest-path costs as on the original graph. That’s why contraction needs and has meaningful cost values.
pgr_makeBiconnectedPlanar and pgr_makeMaximalPlanar are fundamentally different — they add structural edges to improve graph properties (biconnectivity, triangulation), not to replace or shortcut any existing path. There is no existing path being shortcutted, so there is no cost to derive.
Both serves different purpose than what contraction does :
-
Planar augmentation → prepares graphs for graph drawing and structural algorithms for example : chrobak_payne_straight_line_drawing() — requires maximal planar input canonical_ordering() — requires maximal planar input
-
Mesh generation / triangulation for computational geometry
-
Network redundancy analysis (biconnected = no single point of failure)
None of these downstream algorithms use edge costs. They operate purely on graph topology (which vertices are connected to which).
2. pgr_makeConnected
I verified pgr_makeConnected across all layers (SQL → C SRF → C++ driver → algorithm → Boost call) and ran both the official docquery tests . Everything passes:
pgr_makeConnected returns (seq, start_vid, end_vid) without a cost column, and it works correctly. The documentation states: “The algorithm does not consider traversal costs in the calculations.” So I think we can follow the exact pattern for makeBiconnected and makeMaximal .
Since pgRouting functions never modify the input, the pipeline works as: call makeConnected → user INSERTs returned edges (with their chosen cost) → call makeBiconnectedPlanar on the updated table → user INSERTs → call makeMaximalPlanar. Same pattern as pgr_contraction’s documentation tutorial.
Regarding the cost i want your guidance what we should prefer .
Given that these are structural/topological operations (not routing operations), I see two clean approaches:
Option 1: Match pgr_makeConnected : no cost column
sql :
pgr_makeBiconnectedPlanar(TEXT,
OUT seq BIGINT,
OUT start_vid BIGINT,
OUT end_vid BIGINT)
then user adds edges with their own cost when inserting :
INSERT INTO edges(source, target, cost, reverse_cost)
SELECT start_vid, end_vid, 1.0, 1.0 – user chooses cost
FROM pgr_makeBiconnectedPlanar(‘…’);
Option 2: Include cost column with a default value
pgr_makeBiconnectedPlanar(TEXT,
OUT seq BIGINT,
OUT start_vid BIGINT,
OUT end_vid BIGINT,
OUT cost FLOAT) – default 0 or 1
-
Output can be piped directly into INSERT
-
More convenient for the user
If we go with Option 2, we could also apply the same change to pgr_makeConnected for consistency across the pipeline.
Which approach does the community prefer? I’m ready to proceed with implementation either way. I lean toward Option 1 (matching pgr_makeConnected) since these are graph structure operations, but I’m happy to go with Option 2 if that’s preferred.
Thanks!
Mohit