Welcome to my Google Summer of Code 2026 experience blog. I documented my progress here week by week while contributing to GRASS under NumFOCUS.

About the Ecosystem

  • What is GSoC? Google Summer of Code is a global program that pairs students with open-source organizations to work for 8-12 weeks on a programming projects, helping students gain real-world experience while improving open-source software.
  • What is GRASS? Geographic Resources Analysis Support System (GRASS) is a powerful, free, and open-source Geographic Information System used for geospatial data management, image processing, and spatial modeling.
  • What is NumFOCUS? NumFOCUS is a non-profit organization that supports open-source scientific computing, providing fiscal, legal, and administrative support to projects like GRASS.

My Project Overview

Title: Add Spatio-Temporal Datasets Support to GRASS Data Catalog GUI

Mentors: Anna Petrasova and Stefan Blumentrath

Project Summary: Before this project, the GRASS Data Catalog only queried standard spatial maps and bypassed the temporal database and STDS entirely. As a result, Space Time Datasets were completely invisible in the catalog interface, forcing users to manage them exclusively via the command line. The project extended the existing Data Catalog architecture to natively support STDS, showing STDS alongside the standard spatial maps and fetching and displaying STRDS, STVDS, and STR3DS objects inside their respective mapset trees. It also enhanced Data Catalog functionality, such as context menus and other operations, so the GUI could fully recognize, search, and interact with STDS objects. Beyond these GUI integrations, the project resolved critical bugs and improved core temporal tools to smooth the overall user workflow.

📖 My Experience

Community Bonding & Setup

Date: May 1, 2026 to May 24, 2026

During the first week of the Community Bonding Period, I had my introductory call with the GRASS team. All the mentors and selected students introduced themselves, and we discussed some basic details about how the program would move forward. We also had the opportunity to ask questions. The meeting felt more like a friendly conversation than a formal professional meeting, which made it very welcoming.

The following week, my mentor scheduled another meeting focused specifically on the project I was selected for. This meeting included only the people directly involved in the project. We discussed the project scope, and my mentors shared resources about the temporal framework and its documentation so that I could gain a better understanding of the tools and concepts involved.

While going through the documentation, I came across a small documentation issue and quickly opened a pull request to fix it. Overall, the Community Bonding Period was quite relaxed and primarily focused on learning, understanding the project, and getting familiar with the codebase and community rather than actively contributing code.

Week 1: Coding Period

Date: May 25, 2026 to May 31, 2026

The coding period officially began this week, and with it came the start of my GSoC journey. Unfortunately, I was dealing with some health issues during the week, which limited the amount of work I could contribute. I informed my mentors about the situation in the first few days, and they were incredibly understanding and supportive, which I really appreciated.

Despite the circumstances, I stayed involved by working on a few existing tasks and open pull requests. I contributed to adding JSON output support for r.geomorphon, worked on some GUI feature enhancements, and looked into a temporal framework issue related to importing STDS datasets.

While it wasn’t the most productive week in terms of coding output, it helped me stay connected with the project and gradually get into the development workflow. I’m looking forward to being fully back on track and contributing more in the coming weeks.

Week 2: Coding Period

Date: June 1, 2026 to June 7, 2026

The second week started on a positive note. Just like in the first week, we had a project meeting, and we decided to make it a weekly occurrence to keep everyone aligned and ensure steady progress throughout the summer.

This week, I primarily focused on adding format options to several temporal tools, including t.list and t.rast.univar. Over the course of the week, I opened around five to six pull requests related to these enhancements. Overall, it was a much more productive week compared to the first one.

While working on these feature additions, I also ran into a few pre-existing bugs. This is something you often encounter in open-source projects, especially when working in areas that haven’t been explored or tested extensively. Sometimes, while trying to solve one issue, you discover another problem that needs to be fixed first before you can continue with your original task.

This is actually one of the things I enjoy most about open source. It provides a realistic glimpse into how real-world software projects operate. Things are rarely perfect, and there is always room for improvement. Working through these challenges not only helps improve the project but also teaches valuable problem-solving and debugging skills.

With these tasks completed, the week came to an end. We scheduled our next meeting and are now gradually beginning to shift our focus toward the main objective of my GSoC project: Adding Spatio-Temporal Dataset Support to the GRASS Data Catalog GUI.

Week 3: Coding Period

Date: June 8, 2026 to June 14, 2026

The third week got off to a great start. I opened a couple of pull requests to add JSON output support for additional temporal tools, continuing the work from the previous week.

As usual, we had our weekly project meeting, where we discussed how to gradually move toward the main goal of my GSoC project. One of the key topics was the performance of the existing temporal modules. Before integrating them into the GUI, we talked about understanding their execution time and identifying opportunities to optimize them wherever possible.

My mentors also suggested that I take a deeper look at the temporal import modules and the overall temporal framework. The goal was to better understand how everything fits together and identify any areas that could be improved before starting the GUI integration.

Alongside these tasks, I worked on a few miscellaneous issues and opened some quick pull requests to address them. This week was also a bit challenging since I had my college exams, making it difficult to dedicate as much time as I would have liked. Fortunately, I was able to balance both my exams and GSoC work without falling behind.

As the week came to an end, I noted down the tasks for the following week and started preparing to shift my focus from smaller contributions toward the core implementation of my project.

Week 4: Coding Period

Date: June 15, 2026 to June 21, 2026

As I mentioned in last week’s blog, I spent this week taking a closer look at the temporal core framework and the import modules to see if there was any room for optimization. One of the main goals was to optimize an import module that is used by almost every temporal tool. During our weekly meeting, my mentor mentioned that this single import was taking around 3 seconds on their machine. Since the GUI will eventually need to use these modules multiple times, such a delay could make the interface feel unresponsive, so improving this was an important step before moving on to the GUI implementation.

My first idea was to experiment with something like lazy imports using __getattr__ in __init__.py, so that modules would only be imported when actually needed instead of loading everything upfront. However, before trying that approach, I decided to profile the existing implementation to better understand where the time was actually being spent.

To my surprise, the same import that took around 3 seconds on my mentor’s machine was taking only 0.17 seconds on mine. At first, I assumed I had measured it incorrectly because such a huge difference didn’t seem very realistic. I emailed my mentors with the results, and they were equally surprised. They asked me to run the exact same command they had used, but I still observed the same timing.

After discussing it further, my mentor confirmed that the measurements were correct and that the issue wasn’t on my side. It turned out to be something related to the operating system. Since I’m using macOS, the import was already well optimized there, while on Linux there was a bug that caused the import to be significantly slower. My mentors fixed the underlying issue, and it seems that the import performance is no longer a bottleneck.

With that investigation completed, I finally opened a draft pull request for the main goal of my GSoC project. My mentors suggested that I keep updating the PR description as development progresses, so from this point onward, most of my work will happen in this single PR as I gradually add support for Spatio-Temporal Datasets (STDS) and related features.

We also had a discussion about how STDS should be represented in the GUI. At the moment, there isn’t an existing icon for it, so we’ll likely need to design one. My mentors asked if I’d be interested in creating it. I’m definitely not much of an artist, but it sounds like a fun opportunity, so let’s see how that goes! For now, it’s not blocking development, and I’m using a temporary icon while continuing with the implementation.

Overall, this week was quite interesting. It involved a fair bit of profiling, debugging, and understanding the internals of the temporal framework before finally taking the first real step toward implementing the main project. And with that, another productive week came to an end.

Week 5: Coding Period

Date: June 22, 2026 to June 28, 2026

This week, I finally started working on the main goal of my GSoC project. Before my project, the GRASS Data Catalog GUI did not support Spatio-Temporal Datasets (STDS), so this week marked the beginning of implementing that support.

To get started, I first listed the basic and essential features that needed to be implemented before adding more advanced functionality. My mentor, Stefan, also suggested an approach for listing STDS efficiently and improving the overall performance.

At that time, t.list , which is the temporal module used to query and list space-time datasets along with some of their metadata, did not support the mapset="*" option. Because of this limitation, the only way to retrieve datasets from all mapsets at once was to temporarily modify the search path, add all required mapsets using g.mapset , execute t.list, and then restore the user’s original search path. I started by implementing this workflow in the GUI.

Alongside that, I added lazy loading for each dataset returned by t.list, implemented a few basic context menu actions for the STDS nodes, and opened the initial draft pull request. Although the basic functionality was in place, there were still several areas that needed improvement.

To further optimize the GUI, my mentor later added support for mapset="*" directly to t.list. This allowed me to retrieve datasets from all mapsets in a single call for each dataset type, making the implementation both simpler and more efficient. They also helped identify and optimize several other parts of the workflow to ensure that integrating STDS into the Data Catalog would not cause the GUI to freeze or become unresponsive.

Like every other week, we had our weekly project meeting where we discussed the current progress, talked through these optimization ideas, and prioritized the tasks that needed to be completed next. Besides working on the main project, I also fixed a few smaller issues that were indirectly affecting the implementation.

Overall, this week felt like a major milestone since I finally began implementing the core functionality of my project. There is still a lot left to do, but seeing the first version of STDS support working inside the Data Catalog was definitely exciting.

If some of the terms like datasets, mapsets, or temporal framework are unfamiliar, I highly recommend exploring the following resources:

These provide a good introduction to the temporal framework and make it easier to follow along with the development process described in these blogs.

Week 6: Coding Period

Date: June 29, 2026 to July 5, 2026

This week, I picked up right where I had left off with the draft pull request for my main project. I received a few suggestions from other members of the GRASS community, most of which were related to the icons and the overall presentation of the new STDS nodes in the Data Catalog.

My mentors also suggested that I focus on improving the overall structure of the implementation as much as possible. The idea was to have a solid foundation that could be discussed with the wider community in the following week, especially regarding the context menu options and which features would be the most useful for users.

We also had a discussion about potentially changing the entire hierarchical structure of the Data Catalog. After considering the pros and cons, we decided not to make that change for now and instead continue building on the existing structure.

Overall, this was a relatively steady week. I mainly focused on refining my draft pull request and worked on a few smaller issues that were either directly or indirectly affecting the GUI integration. While there weren’t any major new features added, the week was important for improving the codebase and preparing the implementation for further review.

One interesting difference this week was that one of my mentors was traveling, while the other was very flexible and gave me the option to either have a one-on-one meeting or skip the weekly meeting altogether. Since I already had a clear set of tasks to work on, I decided to skip the meeting and continue with the implementation. That said, we were still in touch throughout the week via email and GitHub comments whenever there were discussions or feedback on the pull request.

This week was also special because the GSoC Midterm Evaluations took place from 6th to 10th July. During this period, I completed my evaluation of my mentors, and they completed theirs for me. Once everything was submitted, all that was left was to wait for the results after the evaluation deadline.

And with that, another week of GSoC came to an end.

Week 7: Coding Period

Date: July 6, 2026 to July 12, 2026

This week, I continued working on the main draft pull request for my project. Most of my time was spent improving the implementation by adding more functionality to the STDS nodes and the maps contained within them. I also focused on making the overall user experience more intuitive by refining the available context menu options and improving the overall interaction with the Data Catalog.

There were still a few optimization challenges that needed attention, so I spent some time identifying areas where the implementation could be made more efficient before moving on to additional features.

As usual, we had our weekly project meeting. My mentors shared feedback on the current state of my pull request and discussed comments they had received from other community members. We talked about the overall structure of the implementation, which context menu options users would expect to see, and which features would provide the most value. Based on that discussion, they helped me prioritize the remaining tasks by distinguishing between the features that were essential for the initial implementation and those that could be added later.

Apart from the main project, I also worked on a few smaller issues and experimented with some of the ideas suggested during our discussions. These smaller improvements helped make the implementation cleaner and more polished.

On a personal note, this week was particularly exciting because I successfully passed my GSoC Midterm Evaluation and received my first stipend. It was a rewarding milestone and a nice reminder that all the work over the past several weeks was paying off.

Overall, this was a great week, both in terms of project progress and personal milestones. I’m excited to continue building on this momentum in the weeks ahead.

Week 8: Coding Period

Date: July 13, 2026 to July 19, 2026

Week 8 got off to a great start. I began by working on an enhancement to the existing t.list tool, adding support for querying multiple dataset types in a single command. This made t.list more consistent with tools like g.list, which already supported this functionality. There were a few design discussions and some valuable feedback from my mentors along the way, but by the end of the week I had addressed all of the suggested changes.

Alongside this, I continued improving my main project pull request by adding more features and making several optimizations to the implementation.

One of the biggest improvements this week came from a new gui_support module that my mentor introduced. This module significantly improved the way temporal data is loaded in the GUI. Previously, the implementation relied on running tools such as t.rast.list separately for each dataset inside a mapset, which was not very efficient. The new approach instead performs SQL queries directly, allowing the required information to be fetched much more efficiently.

This change had a major impact on the overall performance of the Data Catalog. It greatly reduced loading times and also made it possible to handle a few tricky cases much more cleanly. For example, I was now able to prevent maps that are already registered inside an STDS from appearing again in the regular standalone maps list.

The new implementation also helped solve one of the issues I had been dealing with since the early stages of the project. Up until Week 7, my approach was to list only the STDS initially and lazily load the maps when the user double-clicked on a dataset. While this worked, it introduced several complications, especially when reloading mapsets and keeping the tree structure in sync. With the new gui_support module, I was able to simplify the workflow, fix those issues, and make the overall implementation much more robust.

Overall, this week was heavily focused on optimization rather than adding completely new features. Although much of the work happened behind the scenes, it resulted in a faster, cleaner, and more reliable implementation for the GUI. With these improvements in place, I now have a much stronger foundation to continue building the remaining features of the project.

Week 9: Coding Period

Date: July 20, 2026 to July 26, 2026

This week, I started by completing the remaining context menu options in the Data Catalog GUI that had been suggested by my mentors during our earlier discussions. With most of the core functionality now in place, this felt like a good opportunity to polish the overall user experience and fill in the missing pieces.

Unlike the previous weeks, there were no scheduled meetings during Weeks 9 and 10, so this week was relatively relaxed. Even without meetings, I continued working on the project and kept my mentors updated through GitHub and email whenever needed.

Apart from improving the Data Catalog, I also started working on adding support for passing an env parameter to the temporal framework, allowing calls such as tgis.init(env=env). Initially, I expected this to be a relatively small task, but once I started exploring the implementation, I realized that it was much larger than anticipated. The changes touched several parts of the temporal framework, including files that I wasn’t yet familiar with. Rather than rushing into such a fundamental change, I decided to pause the work for the time being and informed my mentor about it. As a result, I haven’t opened a pull request for this feature yet.

I also addressed some review feedback on another pull request related to t.list, where I had added support for specifying multiple dataset types in a single command, such as type=strds,stvds. It was nice to see that work moving closer to completion as well.

Overall, this wasn’t my most productive week in terms of the number of contributions, but it was still an important one. As the GSoC coding period is gradually coming to an end, my focus has shifted from implementing new features to polishing the existing work, addressing review feedback, and wrapping everything up.

At this point, the main draft pull request is almost complete from my side. My goal is to finish the remaining work by next week so that we can begin the final review process and, hopefully, get everything merged before the end of the 11th or 12th week.

With that, Week 9 came to an end.

Week 10: Coding Period

Date: July 27, 2026 to Aug 2, 2026

As planned, I started this week by wrapping up the main draft pull request from my side so that my mentors could begin reviewing it and, hopefully, get it merged soon. This week, I added a few remaining features, including search and filtering support for STDS in the Data Catalog. I also spent a good amount of time cleaning up the code. Since the pull request had grown significantly over the past few weeks, it required a careful line-by-line review to remove unnecessary code, simplify the implementation wherever possible, and keep the codebase clean and maintainable.

Another improvement I worked on was how module dialogs are launched from the context menu. Instead of using the --ui option to open a separate module window, I experimented with launching the module dialog directly on top of the existing GUI. I feel this provides a much more seamless user experience and is closer to what users would naturally expect. Along with these changes, I completed a number of other smaller improvements and, for now, finished all the planned work on the main pull request. I also converted it from a draft pull request into a regular pull request and am now waiting for my mentors to begin the review process. At this stage, I’m hoping that only smaller changes will be needed based on the review and that all the major implementation work is now complete.

Apart from the main project, I also spent some time experimenting with integrating g.gui.animation into the GUI as a separate tab, with the long-term goal of making it accessible directly from the context menu for STDS. I thought this could be a useful addition alongside the main project.

While testing the integration, however, I ran into an unexpected issue. When I tried opening animations containing a large number of maps or layers, the GUI became unresponsive and my machine started heating up significantly. Interestingly, the feature worked perfectly fine with smaller datasets. To make sure the issue wasn’t caused by my changes, I tested the original implementation without any modifications and observed the same behavior. After discussing it with my mentor, we concluded that it was most likely a performance issue rather than a bug introduced by my implementation.

I started investigating the problem and plan to push the pull request during the first couple of days of Week 11 so that my mentors can test it as well and we can decide how to move forward. If everything goes well, I would love to get this feature completed before the end of the coding period, as I think it would nicely complement the work done for STDS support in the Data Catalog.

Overall, this week was largely about polishing, cleaning up, and preparing the project for review, while also exploring one additional feature that could further improve the user experience. With that, another productive week came to an end.

Week 11: Coding Period

Date: Aug 3, 2026 to Aug 9, 2026

As planned last week, I opened a pull request to address the performance issues I encountered while integrating g.gui.animation. The changes seem to be working well for now, but the PR still needs to go through review before it can be merged, so I’m waiting for feedback from my mentors.

Apart from this, I also worked on fixing a few edge cases in the main STDS pull request. These were some smaller issues that came up while testing the implementation, but I wanted to make sure they were properly handled before the final review. I’m hoping to get the main PR merged by next week.

Since Week 11 also marked the time when we had to submit our final work product documentation, I spent some time refining my GRASS Wiki project page as well. You can check it out here: GRASS Wiki - Project Page

I have tried to make the page beginner-friendly so that even someone with little or no prior knowledge of STDS can understand what the project is about, what I worked on, and how the different pieces fit together. It also serves as a summary of the work I completed throughout GSoC 2026.

Apart from these tasks, I also started working toward another goal: integrating g.gui.animation into the GUI as a tab, similar to the existing GModeler tab, and eventually making it accessible through the context menu for STDS as well. However, this work depends on the performance improvements from the animation PR. Once those changes are reviewed and merged, I’ll be able to continue with the integration.

So, for the final week, my main goals are to get the animation performance PR reviewed, complete the g.gui.animation integration if possible, and most importantly, get the main STDS pull request merged.

And with that, I’m getting very close to wrapping up my GSoC journey for this year. It’s been a long and exciting journey so far, and I’m looking forward to making the final push in the last week!

Week 12: Coding Period

Date: Aug 10, 2026 to Aug 16, 2026

Finally, I reached the last week of my GSoC project!

Looking back, when I first started this project, it honestly felt a little overwhelming. I wasn’t sure if I would be able to complete everything I had planned, or even how far I would get. But as the weeks passed, I gradually made progress, one step at a time. What initially felt like a huge task slowly started coming together, and before I knew it, I was already at the final week.

This week, I spent less time on the main STDS pull request since most of the major work there was already completed. I mainly addressed some reviewer feedback and left a comment explaining the changes and current status of the PR.

Apart from that, I worked on several other tasks that I had planned along the way. These included fixing the animation performance issue, integrating g.gui.animation as a tab in the GUI, fixing a window resizing issue in g.gui.tplot, adding an option to show the full database path in tooltips for database nodes, and working on a few other temporal-related improvements.

Some of these weren’t part of the primary goal of my project, but we had added them to our GitHub project board at the beginning, and I wanted to see how many of those additional tasks I could complete alongside the main project. I managed to make pull requests for these changes as well, which felt like a nice way to wrap up the coding period while covering as much of the planned work as possible.

Another important task this week was preparing my final work product documentation. Since I had to submit a work product link as part of the GSoC final evaluation, I spent some time making sure my GRASS Wiki project page was properly organized and documented. My mentors had suggested creating this project page during the first week, and I had also confirmed with them that I could use it as my final work product link.

You can find the final project page here:

GRASS Wiki, GSoC 2026: Add Spatio-Temporal Dataset Support to Data Catalog in GUI

I tried to make the page as beginner-friendly as possible so that someone who isn’t already familiar with STDS or the GRASS temporal framework can still understand what the project was about, what I worked on, and what was accomplished during the coding period.

And with that, my GSoC journey officially comes to an end.

It definitely feels a little strange to say that after spending the last few months working on this project almost every week. I learned a lot not just about GRASS and its temporal framework, but also about working on a large open-source project, collaborating with mentors and the community, reviewing and improving my own code, dealing with unexpected issues, and gradually turning a project proposal into something real.

Of course, there are still a few things left to finish, and I plan to continue working on them even after the GSoC coding period ends. So this might be the end of the GSoC coding period, but hopefully not the end of my contributions to GRASS.

And finally, thank you for reading this blog all the way to the end! I hope these weekly updates gave you some idea of what my GSoC journey looked like behind the scenes.

If you’re planning to apply for GSoC in the future, don’t be afraid to give it a try. It might feel overwhelming at first as it did for me but you don’t need to know everything when you start. Take it one step at a time, keep learning, ask questions, and keep contributing.

Good luck, and I hope to see you as a GSoC contributor someday!

Thanks for reading!