GSoc 2026 - Second coding Period

pgRouting pgrouting-dev
1

Hello @sakirr05 @Mayur @Mohit242-bit

We are in the second coding period. This thread will be about it.

Important announcements:

Last week meeting was canceled due to bad weather in India and for mentors to reschedule was not possible. The plan for last week meeting was to do some show and tell from your part.

That will happen this week. But not on Monday, Mentors have a work meeting that can not be avoided. Actually our regular meetings are going to change day: Friday the time will be announced soon.
Not this week though, because the show and tell from your part will happen on individual meetings.

During that show and tell you will need to:

  • Share your screen,
  • Have the camera,
  • and not be muted.

So make sure you have a good connection.

To make the appointment you need to consider that Regina and me are very busy and have many morning work meetings so our mornings is not a time slot. And in particular, tomorrow we can not have a slot for you.

@Mayur we know you are in exams, but you still need to have a slot during the week.

So, Tuesday, Wednesday, Thursday and Friday (our night, aka next day your morning) is available.

First come, first served: if A is the first one to make the appointment for Friday then B and C can not take Friday.

Time: our usual time,

  • Mexico 9pm
  • Boston 11 pm
  • India, I think, its 8:30 am, but you are in charge on verifying that.

I reiterate: make sure you have a good connection.
Don’t forget you will have to:

  • Share your screen,
  • Have the camera,
  • and not be muted.

No excuses.

Regards
Vicky & Regina

2

Hi @cvvergara @robe ,

Got it, thanks for the update.

My college has started, and my regular schedule is Monday to Friday from 9:00 AM to 6:00 PM (IST). Because of that, I won’t be available for the Tuesday–Friday morning (IST) slots.

The only time I can join is your Friday night meeting, which would be my Saturday morning (IST). If that slot is available, I’d be happy to take it.

Please let me know if that works.

Thanks!

3

Hello @cvvergara @robe,

I’m travelling this week and will have a layover specifically on Thursday, so that’s the only day I’ll be able to make a slot. I’d like to take the Thursday slot for my show and tell.

To confirm: Mexico 9pm Thursday / India 8:30am Friday.
regards
sakirr

4

2026-07-18T03:00:00Z

works for me.

5

2026-07-17T03:00:00Z

works for me.

6

Hello @cvvergara @robe,

Wednesday works for me. I will be available at the usual time (Mexico 9pm Wednesday / India 8:30am Thursday).

Regards,
Mayur

7

2026-07-16T03:00:00Z

Confirmed

8

Hi all,
Confirmed the three schedules.
Wednesday @Mayur
Thursday @sakirr05
Friday @Mohit242-bit

9

Hello all
This weeks meeting will take place 2026-07-24T03:00:00Z

Regards

10

@sakirr05

You opened a couple of issues on the pgRouting main repo:

3093
3091

Thanks for that. There is really an issue on 3091. which I will fix in 4.0.2
I will have you modify the issue. The modifications you need to do will be in the issue.

And an :check_mark: that you mentioned you used AI.
On the OSGeo board of directors we do the opposite: we mention that we did not use AI to do the motion, documents, etc.

Just a note:

  1. Don’t use images, we can not copy/paste from an image
    this image

See this 3110 as example of a good issue.

11

Forgot to mention

I normally fix the bug first then I open the issue, so I will fix then I will tell you what to modify on the issue.

12

hello all,
I have a trip this weekend, I depart on (my) Friday night.
So I am moving the meeting for (my) Thursday night. Usual time.
Regards
Vicky

13

Hi students
I need a detailed description of the boost version you need for your code to work.
A proof of concept: AKA modify your boost_version.yml, with:

critical version, (aka the one you need) say 1.80 → should pass
prev then it would be 1.79 → should fail
next then it would be 1.81 → should pass

The proof of concept should be done in a different branch, abilitate the action before pushing, make a PR, and merge it once its clear what works and what does not work.

Inform us in here, and of course the boost_version.yml will be our memory on the gsoc-pgrouting repo.

issue 3120

Boost availability

Boost has no EOL: releases are never retired and stay downloadable at
archives.boost.io. The dates below are the initial release dates.

Boost Release date Age (2026-07-31)
1.53.0 2013-02-04 ← 13 years old
1.54.0 2013-07-01
1.55.0 2013-11-11
1.56.0 2014-08-07 ← 12 years old
1.57.0 2014-11-03
1.58.0 2015-04-17 ← 11 years old
1.59.0 2015-08-13
1.60.0 2015-12-17
1.61.0 2016-05-13 ← 10 years old
1.62.0 2016-09-28
1.63.0 2016-12-26
1.64.0 2017-04-19 ← 9 years old
1.65.0 2017-08-21
1.66.0 2017-12-18
1.67.0 2018-04-14 ← 8 years old
1.68.0 2018-08-09
1.69.0 2018-12-12
1.70.0 2019-04-12 ← 7 years old
1.71.0 2019-08-19
1.72.0 2019-12-11
1.73.0 2020-04-28 ← 6 years old
1.74.0 2020-08-14
1.75.0 2020-12-11
1.76.0 2021-04-16 ← 5 years old
1.77.0 2021-08-11
1.78.0 2021-12-08
1.79.0 2022-04-13 ← 4 years old
1.80.0 2022-08-10
1.81.0 2022-12-14
1.82.0 2023-04-14 ← 3 years old
1.83.0 2023-08-11
1.84.0 2023-12-13
1.85.0 2024-04-15 ← 2 years old
1.86.0 2024-08-14
1.87.0 2024-12-11
1.88.0 2025-04-10 ← 1 year old
1.89.0 2025-08-14
1.90.0 2025-12-10
1.91.0 2026-04-22 ← 0 years old

Notes:

  • Boost has no support window and no backported security fixes.
  • Boost.Geometry requires C++14 from 1.75 onward.
  • pgRouting v3.0.0 declares a minimum of 1.53, but its vendored bgeometry
    needs boost/core/ignore_unused.hpp, added in 1.56; with -std=c++11
    (v3.0.0) boost >= 1.75 breaks geometry. Effective range: 1.56 - 1.74.
14

Hi, meeting with students august 7:
roll call: Vicky Regina

The demo that I used was Sakir’s pgr_coreNumbers.

First step: Use coloring_process

In his case its coloring_process.h becuase he returns an II_t_rt

meld ../components/makeConnected.c coreNumbers.c

In this step, the changes between files are minimal my diff between those files has 26 lines:

diff ../components/makeConnected.c coreNumbers.c | wc
     26      64     626

Basically the diff is:

  • The name of the file
  • The authors
  • The name of the function
  • The enumeration

And of course I did not make a change on makeConnected.c

git diff pgr/develop ../components/makeConnected.c

comes out empty

Commit.

Second step: Compile

Compile, in this case it does not compile, unfortunately when the code was originally copied, it also removed the environment.

Problem: CORENUMBERS is not defined
Solution: add CORENUMBERS to the enumeration, and to the utility function that gets the name.

Compile again: This time it compiles.
Of course there are no results so docqueries fail, and pgtap tests fail.

Commit any changes you had to do if any.

Third step: Join the code into coloring_driver.cpp

  • Add the corresponding #include directive
  • Add the corresponding using statement

commit

In his case:
he does some preprocessing to remove loops on the graph before checking if there are edges.

        if (which == CORENUMBERS) {
            /* remove self loops */ 
           <code to remove self loops goes here */ 
        }

Commit.

Also in his case for undirected graph he does a different insert:

        } else {
            if (which == CORENUMBERS) {
                undigraph.insert_min_edges_no_parallel(edges);
            } else {
                undigraph.insert_edges(edges);
            }

Commit.

And add the switch case for

                case CORENUMBERS:
                    results = coreNumbers(undigraph);
                    break;

Commit.

Fourth step: Compile

and TADA!!! everything works

Last step, remove the unused files

Now you are not using

  • coreNumbers_process.cpp
  • coreNumbers_process.h
  • coreNumbers_driver.cpp
  • coreNumbers_driver.hpp

Remove & commit

Compile, fix the build and commit

15

@sakirr05

I left a couple of comments on what you need to do in the body of the issues you opened #3091 and #3093.
Please Do It ASAP.
The links to them will remain for ever in the pgRouting release, so they must be improved.
Do the one for main first then from that copy/paste adjust to the one of develop
Thanks

16

@cvvergara

I’ve replied on #3091 with the updated content: re-scoped from just pgr_drivingDistance to cover all four catchment functions (pgr_drivingDistance, pgr_withPointsDD, pgr_primDD, pgr_kruskalDD), read #3127
to write it, removed the image, and added a complete copy/paste example

17

Vicky, so sorry i missed the meeting yesterday, i had a university test on the same day and with the previous schedule i got confused on the timings, my bad on that.

i went through everything you did in the demo and made all the same changes on coreNumbers.

  • moved coreNumbers.c to use coloring_process.h since it returns II_t_rt, diff against makeConnected.c came out to just 24 lines (filename, authors, function name and the enum), didnt touch makeConnected.c at all
  • added CORENUMBERS to the enum and to get_name, compiled, got the exact same “not defined” error you got then it built fine after
  • joined it into coloring_driver.cpp, added the include and using, the self loop removal before the empty edges check, the insert_min_edges_no_parallel for the undirected case, and the switch case for CORENUMBERS
  • compiled and it worked, results came back correct
  • removed coreNumbers_process.cpp, coreNumbers_process.h, coreNumbers_driver.cpp and coreNumbers_driver.hpp since nothing uses them now, fixed the CMakeLists after and it builds clean

tested it against parallel edges and self loops too and both still behave correctly after the move

18

You have to do something similar with the other function.

From now on, please dont forget to do a diff name-status against pgrouting develop branch
I am doing changes and you need from now on catch them with a merge

19

got it @cvvergara , will do the same thing for planarFaces by tomorrow

20

Hi @cvvergara,

I’m working on refactoring pgr_maxWeightedMatching following the process/driver consolidation approach discussed in the August 7 meeting.

The example was pgr_coreNumbers, which uses coloring_process and returns II_t_rt. In my case, 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.

I found that johnson, betweennessCentrality, floydWarshall, and boyerMyrvold use IID_t_rt. Should I follow one of these process/driver implementations instead?

Could you suggest which existing process/driver I should use as the equivalent of coloring_process for pgr_maxWeightedMatching?