The Project That Changed How I Work With Geodata
I've built many tools over the years, but one project in particular pushed me into a new way of thinking about geospatial work. It started from a simple frustration: every time someone needed data for a specific area, the process was always the same — searching different portals, checking formats, cleaning files, converting them, loading everything into a GIS, and only then beginning to understand what was actually inside. It was repetitive, slow, and completely unnecessary in 2025.
So I decided to automate the whole thing.
The result is a system that can take a short request — just an area on the map and a sentence describing what the user needs — and turn it into a full, ready-to-use dataset. Behind the scenes it evaluates the request, chooses the best data source, downloads it, checks its quality, prepares it, converts it into the formats people actually use, and finally creates a web map to explore everything instantly. What used to take an afternoon now happens in the background, almost silently.
The funny thing is that the more I refined it, the more I realized this wasn't just a downloader. It was becoming a small decision-making engine. It learned when to rely on OpenStreetMap, when to switch to OvertureMaps, and when an Open Data portal had the richer geometry. It also handles composite results — cases where the user wants something that doesn't exist as a single dataset. The system goes and builds it, combining layers and creating new ones when needed. That was the moment I understood I wasn't just creating a tool, but a tiny ecosystem.
One of my favorite examples is the California buildings explorer. I used the same pipeline to collect millions of footprints from OvertureMaps and serve them through vector tiles. The result is a smooth web map where you can explore entire cities without overwhelming your browser. Seeing this run for the first time felt like a proof of concept for the entire idea: geodata should move fast, feel light, and be immediately explorable.
What I enjoy most about this project is how invisible it becomes. The user sees a simple interface, a clean folder, and a map that opens in the browser. All the complexity stays inside — automated, predictable, and repeatable. For me, it marks the moment where GIS stops being a collection of manual operations and becomes a real workflow, something closer to data engineering than traditional mapping.
And that's why this project is still my favorite. It didn't just solve a problem; it changed how I think about geospatial work, and it created the foundation for everything I'm building next.
The Problem: Repetitive Geodata Workflows
I've built many tools over the years, but one project in particular pushed me into a new way of thinking about geospatial work. It started from a simple frustration: every time someone needed data for a specific area, the process was always the same — searching different portals, checking formats, cleaning files, converting them, loading everything into a GIS, and only then beginning to understand what was actually inside. It was repetitive, slow, and completely unnecessary in 2025.
So I decided to automate the whole thing.
The Solution: An Automated Geodata System
The result is a system that can take a short request — just an area on the map and a sentence describing what the user needs — and turn it into a full, ready-to-use dataset. Behind the scenes it evaluates the request, chooses the best data source, downloads it, checks its quality, prepares it, converts it into the formats people actually use, and finally creates a web map to explore everything instantly. What used to take an afternoon now happens in the background, almost silently.
Evolution: From Tool to Decision-Making Engine
The funny thing is that the more I refined it, the more I realized this wasn't just a downloader. It was becoming a small decision-making engine. It learned when to rely on OpenStreetMap, when to switch to OvertureMaps, and when an Open Data portal had the richer geometry. It also handles composite results — cases where the user wants something that doesn't exist as a single dataset. The system goes and builds it, combining layers and creating new ones when needed. That was the moment I understood I wasn't just creating a tool, but a tiny ecosystem.
Example: California Buildings Explorer
One of my favorite examples is the California buildings explorer. I used the same pipeline to collect millions of footprints from OvertureMaps and serve them through vector tiles. The result is a smooth web map where you can explore entire cities without overwhelming your browser. Seeing this run for the first time felt like a proof of concept for the entire idea: geodata should move fast, feel light, and be immediately explorable.
Philosophy: Invisible Complexity
What I enjoy most about this project is how invisible it becomes. The user sees a simple interface, a clean folder, and a map that opens in the browser. All the complexity stays inside — automated, predictable, and repeatable. For me, it marks the moment where GIS stops being a collection of manual operations and becomes a real workflow, something closer to data engineering than traditional mapping.
Impact: A New Way of Thinking
And that's why this project is still my favorite. It didn't just solve a problem; it changed how I think about geospatial work, and it created the foundation for everything I'm building next.