Exploring Reproducibility in Geospatial GUIs Through Code Generation
Map2Cell is a prototype version of ipyopenlayers that explores features to enable scientific reproducibility in GUI-driven geospatial workflows.
Benjamin Szeghy 
As open science practices mature toward widespread access to geospatial data and computing increasingly frees scientists from routine geoprocessing tasks, the role of the geospatial scientist is shifting. The primary deliverable for geospatial scientistsis increasingly not just the statistical or cartographic output, but the transparent, reproducible workflows behind it (Nüst and Pebesma 2020). As such, GIS software users need a way to record, distribute, and reproduce the steps of their workflow. They also need to be able to edit and iterate on it non-linearly, and distribute it in a manner that works universally.
Existing GUI-based GIS tools aren’t providing the affordances practitioners need to make that transition. For example, ArcGIS currently offers tooling to copy geoprocessing operations as Python code. However, the output is specific to the ArcGIS API. It is generally a single tool call, and operates in much the same manner as the original GUI tool, limiting visibility into the underlying processes and preventing seamless integration with interoperable standard scientific Python tools.
Over the course of our 2026 Spring semester internship at The Eric & Wendy Schmidt Center for Data Science & Environment, Esha Potharaju and I explored a method of integrating this logic in a prototype we called Map2Cell.
Concept
In existing geospatial science software packages, data processing operations are generally accessed entirely through forms. After being configured, they run opaquely in the background. Because many tools are designed around the paradigm that the output is the entire deliverable, reproducibility is not an inherent part of established workflow. The goal of this work was to design a proof of concept that tackles all three of these drawbacks at once.
The Map2Cell prototype leverages Jupyter Notebook’s inherent scientific reproducibility from within a GUI-based workflow. It allows for visibility into and modification of the process by both the original researcher and others. Lastly, the solution was designed to help the user evolve the skills they need to do open science independent of a GUI if they so choose.
In its present incarnation, this tool is centered on drawing vector features as a proof of concept. A future iteration could extend this across more elements of the geospatial stack.
How it works
First a vector drawing feature is added to ipyopenlayers. It can be activated by clicking the pencil icon, and a dropdown menu allows the user to select the vector type they want to draw.
from ipyopenlayers import (
Map, DrawAndExport
)
m=Map(center=[-122.2264,37.0642],zoom=15)
m.add_control(DrawAndExport())
mNext, the (not so) secret sauce: the export button dynamically reads the new data on the map, and exports it as a deterministically-generated, self-contained Python snippet, and inserts it as a cell in the same notebook.
Lastly, this project explored integrating with Jupyter AI. With the Jupyter AI extension installed, Map2Cell will suggest several prompts it can send for you to the AI-enabled chat.
How to try it out
While this is a prototype not yet intended for use in real workflows, it was built openly to make it available for real users to try it and provide feedback.
To try these features, follow the installation instructions in the README. As this is an exploratory prototype, we would love to hear your feedback via a comment on the GitHub initiative or Zulip.
❤️ Thanks for reading!
Thank you for following along!
If you are new to the community, we would love to get to know you better! The best ways to get more involved are to either come to a regularly scheduled onboarding hour, or to introduce yourself in the #geojupyter channel in the Project Jupyter Zulip chat space.