GSoC 2026 Week 12 Report: Implementation of Planar Face Extraction and K-Core Decomposition Algorithms to pgRouting

Md Sakir Ahmed
Github id: sakirr05
Mentors: @cvvergara, @robe
Organization: OSGeo / pgRouting
OSGeo Profile: OSGeo Profile Link
Project Wiki: Github Wiki Link
Repository: Repo Link

Hello everyone,

This is my twelfth weekly report of Official coding period for GSoC 2026

Week 12 Report (17 august ~ 23 august)

What did I get done this week?

Architecture question settled:

  • Asked on Discourse whether the process/driver pair goes per family or per return type. @cvvergara answered that the return type is the unit: use an existing pair if it matches, create one if none does, and if two students need the same new type both create their own and she consolidates later
  • Checked do_allpairs before deciding: it dispatches with if (which == JOHNSON) {…} else {floydWarshall} instead of a switch, and routes everything through matrix_to_tuple which cannot shape face output. betweennessCentrality and boyerMyrvold also return IID_t_rt and still have standalone drivers, so planar_process / planar_driver stays

pgr_planarFaces - PR #627:

  • Fixed pgr_isPlanar in planar-family.rst, it was under official-start although its own page declares Experimental
  • Found the main sample-graph diagram wrong: edges 1-8 were right but 9-18 did not match the edges table (edge 9 drawn 1 – 9 when it is 11 – 16, edge 18 8 – 12 when it is 13 – 14). Fixed all ten, verified by diffing the diagram against a live query
  • Documented the exact error on non-planar input, ERROR: Graph is not planar, confirmed by running a K5 rather than guessing the wording

pgr_coreNumbers - PR #637:

  • Found a factual error: the full-graph example called the 2-core “vertices 6 through 12, plus 15, 16, 17”, but that includes vertex 9, which hangs off vertex 8 by edge 14 alone and is core 1. Checked against the docquery result, core 2 is 6, 7, 8, 10, 11, 12, 15, 16, 17
  • Replaced three descriptive paragraphs with a bullet list

Boost Proof of Concept - PR #625 and PR #636:

  • Opened the coreNumbers PoC and pinned boost_minor to [55, 56, 57] on both, so 1.55 fails and proves 1.56 is the real floor, matching BOOST_MINIMUM_VERSION
  • Switched the download to archives.boost.io after finding a SourceForge timeout in a CI log was being read as a Boost incompatibility

Am I blocked on anything?

No

References:

1] Link to wiki page: wiki link

2] Link to github repository: github repository

3] Link to pull requests: