Dear GRASS team,
I’m a second-year engineering student based in Bangalore, India.
I came across the GRASS GIS project for GSoC quite late, but the moment I read the proposal, I immediately understood its importance—because I’ve personally faced the exact problem it aims to solve.
During my undergraduate research on landslide susceptibility mapping in the Rudraprayag district of Uttarakhand—one of the most disaster-prone regions in India—I relied entirely on GRASS GIS 8.2 for my geospatial analysis. I used tools such as r.watershed for drainage network derivation, r.slope.aspect for terrain parameters, r.mapcalc to generate over 25,000 slope units, and r.to.vect for downstream analysis.
The model I built, using data generated entirely through GRASS GIS, achieved an AUC-ROC score of 0.968 with a Random Forest algorithm and outperformed existing pixel-based approaches in the literature for this region.
I conducted the full workflow in Jupyter Notebooks.
The Problem I Faced
When I attempted to visualize my slope unit delineation results using the InteractiveMap widget in a Jupyter Notebook, I ran into a critical limitation: I couldn’t add a legend.
Without a legend, the visualization was essentially unusable for presentation or interpretation. The only workaround was to export the output, manually edit it in QGIS to add a legend, and then bring it back into the notebook. This broke the entire workflow and made iterative experimentation unnecessarily tedious.
This wasn’t a minor inconvenience—it actively blocked my ability to present and refine my research effectively.
Observations from the Codebase
While exploring the grass.jupyter source code, I found that the core foundation is already strong. Classes like Map, InteractiveMap, Map3D, and SeriesMap are well designed.
However, the layer that connects analysis to publication-ready output—the part researchers rely on the most—feels incomplete.
Interestingly, all the required building blocks already exist:
-
Custom HTML support via Folium’s
MacroElement(used by libraries like leafmap for legends) -
GRASS color tools (
r.colors,v.colors) -
A working Matplotlib pipeline
The functionality is there—the integration is what’s missing.
My Contribution So Far
As part of my test-of-skills contribution, I identified and fixed a bug in the grass.jupyter module where get_backend() returned "ipyleaflet" even when the import failed.
I opened PR #7240, where I:
-
Added proper type checking
-
Improved error handling
-
Wrote pytest cases to cover edge scenarios
What I Plan to Build
I aim to focus on improving the research workflow within notebooks by implementing:
1. Legend Support for InteractiveMap
An add_legend() method that reads GRASS color tables using r.colors.out and generates a dynamic HTML/CSS legend using Folium’s MacroElement.
This will support:
-
Raster and vector layers
-
Continuous and categorical color ramps
-
Custom positioning and titles
2. Pythonic Symbology Interface
A clean Python API for managing GRASS symbology, replacing command-line usage with intuitive functions such as:
-
set_color_ramp() -
set_categorical_colors() -
set_class_breaks()
3. Publication-Ready Matplotlib Integration
Enhancements to generate journal-quality outputs directly from notebooks, including:
-
Configurable DPI (150 default, 300+ for publications)
-
North arrow and scale bar support
-
Direct export to PNG and PDF
4. Notebook UX Improvements
-
Cleaner layer representations
-
Better error messages
-
Session configuration utilities
-
Example notebooks demonstrating real research workflows
Final Note
Regardless of the outcome of GSoC, I intend to work on these features. This is something I genuinely needed during my research, and I want to build it for others who use GRASS GIS in notebook-based workflows. Mentorship through GSoC would be extremely valuable, but my motivation to contribute exists independently of it. I’ve already started exploring the InteractiveMap implementation and plan to begin feature development in mid-April
— Anish Udupa Photon079 (Photon) · GitHub Email: anish79u@gmail.com