GSoC 2026 Introduction – Mohit

[Mohit242-bit]

Hello pgrouting community,

I’m Mohit, an engineering student with growing experience in C++ and Python, and a strong interest in routing algorithms and spatial systems. I’ve set up my local development environment, gone through the documentation, and started exploring the structure of the pgRouting modules to understand the workflow.

As I work toward contributing consistently and preparing for GSoC 2026, I’m looking for guidance on good starting points especially in areas like documentation improvements, test coverage, or small algorithm-related tasks where new contributors can be useful early on.

Any recommended issues, resources, or onboarding directions would be greatly appreciated. I’m looking forward to learning from the community and supporting the project wherever I can.

Best regards,
Mohit

[cvvergara]

welcome @Mohit242-bit

You posted in the wrong category, I moved your post.
You need to join the Pgrouting developers - OSGeo Discourse group to post here.

Please review - GSoC Ideas: 2026 · pgRouting/pgrouting Wiki · GitHub

It’s still a work in progress but should be enough to give you an idea of what is expected.

[Mohit242-bit]

Hello pgRouting Community,
I’m Mohit Rawat, and I’m thrilled to share my progress on the GSoC pgRouting application. I’ve just completed the first five core tasks:
→Intent of Application
→Experience with GitHub & Git
→Build locally pgRouting
→Get familiar with C++
→Get familiar with pgrouting
Diving into the pgRouting codebase has been exciting understanding how routing algorithms work in real-world scenarios was eye-opening. Unlike before when I only knew algorithms like Dijkstra theoretically, I hadn’t seen real-world applications until now. The workshop was particularly insightful ,seeing Dijkstra and other algorithms in action through hands-on exercises gave me a much deeper understanding of it.
I’m now drafting my proposal according to GSoC guidelines and have also started working on “Resource Constrained Shortest Path algorithm.” It’s exciting to explore this feature and gain new insights from it.
I’m genuinely interested in contributing to pgRouting beyond GSoC, as working on real-world applications excites me the most. I’d love to hear from mentors about potential areas where I can make the most impact, whether it’s implementing new graph algorithms or improving existing functionality.
Looking forward to collaborating with this amazing community!
Best regards,
Mohit Rawat

[Mohit242-bit]

Hi all,

As part of my preparation for my main GSoC proposal, I’ve been exploring the pgRouting codebase and experimenting with various algorithms to get familiar with the project. During this process, I identified two issues that I believe could improve usability and clarity for users and contributors.

I’d like to ask if it’s okay to proceed with these changes, and if there are any specific guidelines I should follow.

1. King Ordering Documentation Inconsistency

While testing the ordering algorithms, I ran both pgr_cuthillMckeeOrdering and pgr_kingOrdering on the same OSM-derived graph. Both functions returned identical node orders, which matches the “reverse” order as described in the Cuthill-McKee documentation. However, the King Ordering documentation doesn’t mention that it returns the reverse order, which could confuse users.

Suggestion: Update pgr_kingOrdering.rst to clarify that it returns the reverse King ordering of an undirected graph, consistent with the Cuthill-McKee documentation.

2. Odd Cycle Detection in pgr_bipartite

Currently, pgr_bipartite only returns an empty set when a graph is not
bipartite, with no information about why. For large graphs, this makes
debugging difficult. Boost provides find_odd_cycle()
( Boost Graph Library: find_odd_cycle ),
which identifies the actual odd cycle breaking bipartiteness, but this
isn’t currently exposed in pgRouting.

Suggestion: Add a function (e.g., pgr_findOddCycle) that returns the odd cycle when a graph is not bipartite. This would help users debug and fix their data more efficiently, especially for large graphs.

If these suggestions make sense, I’m happy to implement them. Please let me know if there are specific contribution guidelines or review processes I should follow.

Best regards,
Mohit Rawat

[Mohit242-bit]

Note: These are not part of my main GSoC proposal, but are warm-up contributions to get familiar with the codebase and contribute to the community during the working phase.

[Mohit242-bit]

Hello @cvvergara ,

This is regarding **PR #3018:** Documentation: Clarify pgr_kingOrdering returns reverse order (Fixes #3017) by Mohit242-bit · Pull Request #3018 · pgRouting/pgrouting · GitHub , which you recently closed.

Thank you for the detailed feedback. I completely agree with you that we should strictly follow standard terminology and that ‘Reverse King Ordering’ is not a standard term. I apologize if my previous PR title suggested inventing a new algorithm name .I was not able to explain properly.
I wanted to clarify that my motivation came from reading the `kingOrdering.hpp` implementation code itself, which seems to explicitly reverse the Boost output.

1. Implementation Details (The Source of the ‘Reverse’ Behavior) You asked if I read the code, and I did find a specific detail that explains the results. In kingOrdering.hpp, the wrapper function uses a reverse iterator when copying the results from Boost:

Because of rbegin(), the sequence returned to the pgRouting user is the exact reverse of the standard King Ordering produced by Boost.

2. Relation to Cuthill-McKee (Why I made the comparison) I mentioned Cuthill-McKee because, when testing pgr_kingOrdering and pgr_cuthillMckeeOrdering on the same graph, I observed that both functions returned identical node sequences.(see the image attached below):

Since pgr_cuthillMckeeOrdering is explicitly documented as returning the Reverse Cuthill-McKee order, seeing the exact same output from pgr_kingOrdering led me to conclude that our King implementation was also essentially “reversed” relative to what users might expect from the standard algorithm.

The confusion arose because:

• pgr_cuthillMckeeOrdering documentation explains its reversed behavior.

• pgr_kingOrdering implementation (due to the rbegin() iterator) produces the same type of reversal but the documentation doesn’t mention it.

My goal in the PR was simply to create consistency between these two functions so that users aren’t confused as to why they get identical “reversed” results when the documentation only mentions it for one of them.

Proposal I agree we should not call it ‘Reverse King Ordering’. However, since the code does strictly reverse the output, would it be acceptable to add a note about this behavior?

• Current Text: Returns the King ordering of undirected graph.

• Suggested Note: ‘Note: This implementation returns the King ordering sequence in reverse order (using reverse iterators on the Boost output).’

This way, we document the actual behavior of the function for users debugging their graph, without incorrectly renaming the underlying algorithm.

[cvvergara]

Hello,
Maybe you don’t know how to follow code.
But the code has

inv_perm  // inverse permutation

But when added to the the boost function

inv_perm.rbegin()

Which passes the container in reverse order
So at the end the order is not reversed.

Documentation, I think is the most difficult to review, on word changes the meaning of everything, and one has to follow all the code (or make tests) to prove a point.

Please forget about “fixing” documentation.
You can start a thread (here) and discuss possible documentation errors about the functions, but you need to support your claim. (not syntax or grammar those are good with PR)

Please focus on the PR that you are working on that is most important.

[Mohit242-bit]

Ok Mam, got it! Thank you for the clear explanation about rbegin() and the advice on documentation I understand your point now. I’m happy to see PR #3019 merged! Thank you for your guidance and support .

[Mohit242-bit]

Hello @cvvergara ,

I’ve been exploring the pgRouting codebase and testing outputs of various implemented algorithms. While working with pgr_bipartite, I noticed it returns an empty set when a graph isn’t bipartite, with no information about why it failed.

For small graphs this isn’t a major issue, but with large graphs, users face difficulty identifying exactly where the odd cycle exists or how many odd cycles are present.

The Idea: Boost already provides find_odd_cycle() in the same header (<boost/graph/bipartite.hpp>). I could expose this to return the problematic vertices instead of an empty result, so users can see exactly where the problem exists.

My Question: Is this worth implementing? I want to make sure there isn’t a specific reason it wasn’t already implemented. If this seems useful, I can create a GitHub issue and implement the function.

Implementation Approaches: If we proceed, there are two possible approaches:

1. Modify

   pgr_bipartite: Make it return the odd cycle vertices (with color=-1) when the graph fails the bipartite test

2. Create new pgr_findOddCycle() function: This would keep the current pgr_bipartite behavior unchanged (returning empty for non-bipartite graphs) and add a separate function specifically for finding odd cycles. Users could then choose which function to use based on their needs.

I’ve verified Boost compatibility and studied the existing code. Happy to implement this if you think it would be useful!

Best regards,

Mohit

[cvvergara]

I cant copy paste from images

[cvvergara]

I cant recreate without data

[Mohit242-bit]

Hi @cvvergara , apologies for the screenshot! Here is the SQL queries to reproduce the issue using a simple odd cycle (triangle) graph:

DROP TABLE IF EXISTS test_edges;
CREATE TABLE test_edges (
id BIGINT,
source BIGINT,
target BIGINT,
cost FLOAT,
reverse_cost FLOAT
);

INSERT INTO test_edges VALUES
(1, 1, 2, 1, 1),
(2, 2, 3, 1, 1),
(3, 3, 1, 1, 1);

SELECT * FROM pgr_bipartite(‘SELECT id, source, target, cost, reverse_cost FROM test_edges’);

As you can see, this returns 0 rows, which confirms the empty set result for non-bipartite graphs.

My implementation:

Instead of returning an empty set for non-bipartite graphs, return the vertices that form the odd cycle so users can see WHERE the problem is.

[cvvergara]

My implementation:

Instead of returning an empty set for non-bipartite graphs, return the vertices that form the odd cycle so users can see WHERE the problem is.

No.
Definitively its a no.

I do not know what you are trying to do.
The function as it is looks right. If it can not be be-partitioned then it return empty set.
You can create a new function: pgr_theNameOfTheFunction that finds the vertices that participate in odd cycles.

In general, in this thread, kinda looks like you want to change existing code, and your introduction is about GSoC.
For GSoC we want new code, specially a function from boost that is not implemented here yet.
If you want to implement something that is not on boost, we are open as long as:

• You also implement something from boost first

For example:
Maoguang Wang participated on 2017 with the 5 component functions that are in boost (see note) and in 2018 he participated implementing the pgr_chinesePostman which is not in boost.

If you want to implement the new function pgr_theNameOfTheFunction you also need to implement a function from boost, and it would be the 375 hr program. Where the implementation of the function from boost would be “done” in “at most” 3 weeks and the other function, non boost related, would take much more of your time.

Note:

• 2017: He implemented 5 functions: The additional 4 functions represent that he can work out a lot of code during the GSoC program.
• 2018: He implemented a function from boost + his original code for the Chinese Postman algorithm

Regards
Vicky

[Mohit242-bit]

Hii @cvvergara

Thank you for the guidance and for the detailed explanation. I apologize for the confusion; I realize that I didn’t explain my intentions clearly in my previous post.

To clarify:

• I will NOT modify pgr_bipartite. I completely agree that we must maintain existing behavior and avoid breaking changes.

• pgr_findOddCycle is not my GSoC proposal. I have always intended it only as a small warm-up contribution to get familiar with the pgRouting workflow (SQL → C → C++ → Boost) and project standards.

• My actual GSoC proposal will focus on the Resource Constrained Shortest Path (r_c_shortest_paths) algorithm, which I understand is a much more complex and appropriate scope for the program.

Since I have already prepared the logic for pgr_findOddCycle as a new function, I would love to submit it as a standalone contribution if you agree. This would help me demonstrate that I can correctly follow the “new Function” architecture before I move on to the more complex RCSP proposal.

Best regards,

Mohit

[robe]

This sounds like a good plan. I think doing pgr_findOddCycle would be a good challenge to prove your capability and that we could even check before GSOC starts since it’s not your GSOC project..

We could perhaps even later on, put a notice on bipartite that states to use this new function to find odd cycle.

[cvvergara]

@Mohit242-bit

r_c_shortest_paths its not that easy, if you are only doing a boost function find a simpler one.

Actually the:
A simpler function of Boost + pgr_findOddCycle can be part of the GSoC proposal

I definitively will not be helping you on any “warm up” function.
And if you read the GSoC rules any coding done before the coding period is not part of the GSoC program. This rule purpose is because GSoC contributors have a Job/School commitments and a life, thus, preventing them to do unnecessary work.

You must instead do the following:

• Focus on the tasks
  • we will review the tasks when the time comes
• You can start writing a proposal
  • we will see it when the time comes

Please review the GSoC timeline keeping in mind that potential GSoC contributors and GSoC mentors: have jobs/school and a life, so we all must try to stick as much as possible to the program timeline.

PR’s like this one that is no task related, where you are making me re-follow the code (which I did follow when it was on the development stage) and re-read the function documentation on boost (which I read constantly during the development stage), and re-read the function implementation in boost (which I read constantly during the development stage) to be able to take a decision on a word change, is time consuming and adds no value to the GSoC tasks, but it took around 2 to 3 hours of my time to review that PR.

[Mohit242-bit]

Thank you for the guidance. I apologize for the confusion and for taking up your time with the documentation PR; I understand your points about respecting the timeline and the project’s complexity.

I’ll focus on finishing the required tasks for now. I’m genuinely interested in contributing to pgRouting long-term, so I’ll make sure to follow the process correctly moving forward.

Best regards,

Mohit