GSoC 2026 Proposal Idea: XAI-Driven Satellite Imagery Segmentation in GRASS Python API

Hi GRASS GIS Mentors and Community,

My name is Sourish, I am a Computer Science student preparing a proposal for GSoC 2026. I have been exploring the codebase and recently had my first PR merged into main (grass.script: updating core.py with Python type hints - https://github.com/OSGeo/grass/pull/7130 ). I currently have a local development environment set up on Linux, compiled from source, and I’m eager to tackle a larger challenge.

I am very interested in the “Add your research idea to GRASS” category specifically bridging the gap between the GRASS Python API and modern interpretable deep learning workflows.

The Problem:
While deploying deep learning for geospatial analysis (like land cover or infrastructure segmentation) it is becoming standard that these models are often act as “black boxes.” GIS professionals need to trust the predictions, which requires knowing exactly why a model classified a specific pixel as a road or a building. Furthermore, running heavy AI models usually excludes users without dedicated GPUs.

The Proposed Solution:
I am proposing a new Python-based GRASS toolset that integrates PyTorch and ONNX Runtime to perform CPU-friendly, Explainable AI (XAI) segmentation on raster data (GeoTIFFs). The workflow operates as follows:

  1. Data Ingestion via PyGRASS API Bridge
    The tool accepts a user’s raster map and reads it via the native, object-oriented PyGRASS API bridge. By hooking directly into grass.script and the C-backend via Python, the tool maintains full geospatial integrity and metadata consistency throughout the NumPy conversion process, ensuring that every AI prediction remains georeferenced to the real world.
  2. Tiling Engine — Memory-Safe Chunking

A custom Tiling Engine prevents memory overflow by avoiding the loading of entire giga-pixel satellite scenes into RAM. Instead, it processes data as discrete chips (e.g., 256×256 pixels), allowing for high-resolution inference even on standard consumer hardware with limited memory. Each chip is then normalised (pixel values scaled from 0–255 to 0–1) before inference.

diagram-export-3-6-2026-5_33_00-PM.png

3. ONNX Inference Path — CPU-Optimised Segmentation
Each normalised tile is passed through a pre-trained segmentation model (e.g., a hybrid CNN-Transformer) using ONNX Runtime for optimised CPU inference. This path produces a predicted Segmentation Mask per tile to identify geographic features such as roads, buildings, and land cover classes.
4. PyTorch Grad-CAM Path — Explainability (Independent from ONNX)
In a separate parallel process the same tile is passed through the equivalent PyTorch model. A Grad-CAM (Gradient-weighted Class Activation Mapping) Hook captures gradients at the final convolutional layer to generate a spatial Explainability Heatmap. Note: Grad-CAM requires access to the intermediate layer gradients which ONNX Runtime does not expose. Therefore, the XAI path runs exclusively via PyTorch while ONNX handles optimised CPU inference independently. This heatmap provides visual evidence for each segmentation decision allowing users to verify that the model is responding to relevant geographic features rather than noise or artifacts.
5. Reassembly & Geospatial Export
The per-tile Segmentation Masks and Explainability Heatmaps are stitched back into full-resolution images. Using PyGRASS the final outputs are written back into the GRASS GIS database as two distinct map layers with full OGC-compliant coordinate reference system (CRS) metadata preserved end-to-end from input GeoTIFF to final GRASS raster layer.

Why Me?

My academic background focuses heavily on deep learning architectures specifically utilizing hybrid CNN-Transformers and Explainable AI techniques (Grad-CAM) for complex high-stakes image segmentation. Combined with my full-stack experience in Python and C, I am confident I can build a clean, optimized bridge between these ML frameworks and the GRASS database.

I would love to hear your thoughts on this direction. Is this a feature the community would find valuable? Are there specific pre-trained models or segmentation targets (e.g., roads, agriculture) the core team would prefer this tool to be optimized for?

Looking forward to your feedback

Best regards,
Sourish Dutta Sharma
[https://github.com/Sourish-spc]

Hi Sourish,

that sounds in principle interesting.

Things I would encourage you to look at and maybe incorporate in your proposal are:

  1. the concept of imagery groups (see e.g.: Introduction to GRASS GIS as a starting point) in GRASS and how they can be used when applying AI models (here also so called semantic lables can be important to map bands in the imagery group to bands fed to the AI model).

  2. tools like v.mkgrid (v.mkgrid - GRASS GIS manual) or r.tileset (r.tileset - GRASS GIS manual) provide functionality that could serve as a basis for a “tiling engine” you mention. Here also the g.region tool is important to be familiar with…

  3. For reading and writing numpy arrays you can have a look at grass.script package — Python library documentation documentation and pygrass.raster package — Python library documentation documentation

That said, I wrote a GRASS tool at work for applying AI models to satellite imagery: actinia_modules_nve/src/imagery/i.pytorch at main · NVE/actinia_modules_nve That can be of interest for you, and maybe a basis for improvements. This can also be applied in a spatio-temporal context, meaning on SpaceTimeRasterDatasets: actinia_modules_nve/src/temporal/t.pytorch.predict at main · NVE/actinia_modules_nve

So, the temporal GIS (TGIS) concept in GRASS may be relevant for you satellite imagery idea as well…

Cheers

Stefan

Hi Stefan,

Thank you for the pointers. I have spent a lot of time studying both repositories and trying things out in my local GRASS environment. This has been very helpful in making things clear to me.

Regarding imagery groups and semantic labels: I created a test imagery group with three raster bands that have semantic labels like S2_B2, S2_B3 and S2_B4 using i.group and r.support. After reading through the group_to_dict function in the i.pytorch.predict.py file I can see how semantic labels are used to match the band order to the model’s input channels via the configuration JSON. My revised proposal will use a GRASS imagery group as input instead of a raw GeoTIFF and it will use semantic labels to automatically align the bands.

On tiling: I tried using both v.mkgrid and r.tileset on a 360×360 test region. The r.tileset automatically split the region into four 180×180 tiles respecting a 256-pixel maximum. It outputted the west, south, east, north, columns and rows per tile. This is the tile definition format that your create_tiling function works with. Instead of building a custom tiling engine from scratch my proposal will use r.tileset and v.mkgrid and it will use g.region to manage the computational region for each tile.

On the core contribution: after reading both i.pytorch.predict.py and t.pytorch.predict.py I can see that the inference runs on pure PyTorch using .pt model files. This actually makes it easier to integrate Grad-CAM than I originally proposed because the gradients are already accessible in the PyTorch graph. A Grad-CAM hook could be added directly alongside the existing predict_torch function as an output band without requiring any separate runtime.

My revised proposal would focus on extending i.pytorch.predict to include an XAI output band via Grad-CAM and extending t.pytorch.predict so that the explainability heatmap is also registered in the output STRDS enabling temporal analysis of model explainability across time-series imagery.

Would this direction align with what you had in mind, and would you be open to mentoring this project?

Best regards,
Sourish

@Sourish when evaluating proposals, we look heavily on the contributor’s record, meaning contributions to the GRASS project, ideally related to the proposed topic. So I would encourage you to strengthen that. I don’t have specific ideas right now, but perhaps look at issues related to the topic (imagery, temporal) and try to contribute in some way (documentation, code, or even deep analysis of a problem can be valuable).

Hi Anna,

Thank you for the advice. I will look into open issues related to imagery and temporal in the GRASS GitHub and try to contribute further before the proposal deadline.

Best regards,

Sourish

Hi Anna,

Following your advice, I investigated open issues concerning the temporal module and i found issue #4231 (t.rast.import fails when creating a new project). I reproduced this bug in GRASS 8.4.2, located a deprecated g.mapset option gisdbase renamed to dbase in stds_import.py, and submitted a fix:

I will continue looking for more opportunities to contribute before the proposal deadline.

Best regards,
Sourish

Update: the PR was just merged — https://github.com/OSGeo/grass/pull/7178

Hi @Sefan,

I wanted to follow up as the GSoC 2026 contributor application period opens tomorrow. Since receiving your initial feedback, I have been actively contributing to the GRASS codebase. I was able to reproduce issue #4231 regarding the temporal module and provided a fix for the deprecated g.mapset option used in stds_import.py, which has been merged into the repository (#7178).
I have revised my proposal based on your feedback, including imagery groups with semantic label mapping, developing the tiling concept based on r.tileset and v.mkgrid, and clarifying that Grad-CAM is run exclusively via PyTorch separately from the ONNX inference path.
Would you be willing to officially mentor this project for consideration during GSoC 2026? I would like to ensure that I have a confirmed mentor prior to tomorrow when I plan to submit my proposal.

Thanks,
Sourish

Hei Sourish,

As mentioned, the topic is in general quite interesting to me. I use Satellite imagery and also deep learning in my daily work, so that fits in principle well.
That said, I / we cannot make any promises up-front as all project-proposals will be evaluated and ranked by the team of mentors from the GRASS-community. It depends how many proposals get send, how many slots the GRASS project gets allocated from the organization (NUMFOCUS), and the like. So, yes, consider me interested to be a mentor for a deep-learning / imagery topic, but please allow me a couple of comments:

  • a second mentor would be needed as I am unavailable lager parts of July

  • I have not read your proposal in detail (did you provide a link to a document somewhere?), so I cannot really comment on it more specific

  • My general comment would be that

    • the inference itself is not the biggest issue I would like to see solved in this context (as there are working tools for GRASS (even if they may be improved)). What I would be looking for is better support for full ML / deep learning workflows (MLOps)
    • Please check out also other existing deep learning tools, like e.g. i.ann.maskrcnn - GRASS GIS Manual, so you have a good overview over previous, related work.
    • In the temporal domain, handling of imagery and image metadata is not ideal, also here would be some improvements needed (hence my topic suggestion), improvements here would also benefit deep learning applications (and all other imagery tools).

I am looking forward to reading your proposal and will comment on it more specific once you share a link or a document.

Kind regards,

Stefan

Hi Stefan,

Thank you for your response and for considering mentorship for this project.
Here is my proposal document: [GRASS]Add Grad-CAM XAI - Google Docs
I have reviewed i.ann.maskrcnn and noted how it approaches supervised classification using CNN in GRASS GIS. My proposal is complementary rather than overlapping it adds Grad-CAM explainability output to the existing PyTorch inference pipeline rather than duplicating detection functionality.
I understand that a second mentor will be needed to cover July and I am fully open to whoever the GRASS community suggests.
Looking forward to your detailed feedback.

Kind regards,
Sourish

Hi Stefan,
I have also completed my second proposal for the Searchable Metadata in Space Time Datasets idea. Here is the document: Searchable Metadata in Space Time Datasets - Google Docs

While preparing this proposal I studied the TGIS codebase in depth tracing the bug in issue #3394 to the missing mapset ownership check at line 539 of abstract_map_dataset.py, confirmed by the C library documentation at line 1600 of c_libraries_interface.py. I also studied the PR #7043 for issue #7041 and addressed the specific review comments which inclues placing DateTimeEncoder in grass.script.utils, implementing print_json() across all three STDS types and using G_OPT_F_FORMAT.
Looking forward to your feedback on both proposals before the March 31 deadline.

Kind regards,
Sourish

Hei Sourish,

Thank you. I commented directly in the google docs.

Cheers,
Stefan

Hi Stefan,

Thank you for the honest and detailed feedback on both proposals. I really appreciate you taking the time to guide me. I will withdraw the Grad-CAM XAI proposal and focus entirely on the Searchable Metadata in Space Time Datasets proposal. I have already incorporated your feedback from the Google Doc comments and updated the proposal accordingly.

Looking forward to your continued feedback.

Kind regards,

Sourish