GSoc 2026 - Second coding Period

pgRouting pgrouting-dev
21

@cvvergara i have the same question for pgr_planarFaces, so adding what i found
in case it helps answer both.

planarFaces needs 3 values (face_id, edge_id, side) so II_t_rt doesn’t fit either. i mapped it to IID_t_rt as face_id->from_vid, edge_id->to_vid, side->cost, and made planar_process.h/planar_driver.cpp for it.

i looked at joining allpairs_process since it already takes IID_t_rt, but do_allpairs dispatches with if (which == JOHNSON) {…} else {floydWarshall}, not a switch. adding a third case there without restructuring would silently run floydWarshall on planarFaces calls. its process() helper also goes through matrix_to_tuple, which is built for distance-matrix output and doesn’t fit
face traversal results.

what made me keep a separate pair is that astar_process.h and\ shortestPath_process.h both use Path_rt as two separate files, so the organizing unit looks like the family rather than the return type.

mayur’s case looks similar, maxWeightedMatching sits in max_flow but maxFlow_process
uses Flow_t so it can’t join that one either.

is one process/driver per family the intended rule, or should functions share whichever existing pair already matches their return type?

one more thing that might matter for the answer the planar family now has 5 functions across 3 of us, with 3 different return shapes:

isPlanar ------------------------> bool (scalar)
boyerMyrvold ------------------> IID_t_rt
planarFaces -------------------> IID_t_rt (mine)
makeMaximalPlanar----------> II_t_rt (mohit)
makeBiconnectedPlanar ----> II_t_rt (mohit)

so if the rule is one pair per family, the planar family can’t have a singleone unless something converts. right now mohit’s two are going through coloring_driver and mine through planar_driver, so the same directory is split across two drivers. wanted to flag that since it affects how the three of us coordinate, not just my function.

22

About the suitable one:

pgr_maxWeightedMatching returns IID_t_rt (from_vid, to_vid, cost), so coloring_process.h doesn’t seem suitable since it currently only supports II_t_rt

Then of course you don’t use coloring process

Then of course you follow those.

23

For the moment we only have:

ls include/drivers/*.hpp
include/drivers/allpairs_driver.hpp  include/drivers/metrics_driver.hpp  include/drivers/ordering_driver.hpp  include/drivers/shortestPath_driver.hpp

which return: IID_t_rt**, int, int64_t**, and Path_rt** respectively

git grep ');' include/process/*
include/process/allpairs_process.h:        IID_t_rt**, size_t*);
include/process/metrics_process.h:uint64_t pgr_process_metrics(const char*, int);
include/process/ordering_process.h:        int64_t**, size_t*);
include/process/shortestPath_process.h:        Path_rt**, size_t*);

There are 2 + 1 options:

  • One of them fits your return type
    • If it fits your return type, then use an existing one. Just like we did on the example.
  • None of them fit your return type
    • If it does not fit your return type, then create the process and driver files for the new return type.
  • The +1 option it will fit a return type of something else in the future, for example pgr_foo done by student A, and pgr_bar done by student B fit the same return type, then both create their process and driver, I will consolidate into one later on. (note if A=B then I will still consolidate in the future)