The MapScaping Podcast - GIS, Geospatial, Remote Sensing, earth observation and digital geography

Geospatial Product Swiss Army Knife
1. The "Build It and They Won't Come" Trap
We have all seen it: a talented geospatial professional spends months—perhaps years—perfecting a technically sophisticated web map or a niche data service, only to release it to a deafening silence. In our industry, the "build it and they will come" philosophy is a fast track to zero traction.

Precision is the enemy of progress when it is applied to the wrong problem.

Daniel and Stella Blake Kelly explored a remedy for this pattern. Stella—a New Zealand-born, Sydney-based strategist and founder of the consultancy Cartisan—didn’t start with a master plan. She "fell into" the industry after being inspired by a lecturer with bright blue hair and a passion for GIS that rivaled a Lego builder’s creativity. Today, she helps organizations move from "making things" to "building products that matter" using a framework she calls the Product Swiss Army Knife.

--------------------------------------------------------------------------------

2. The 7-Step Framework: More Than Just a Map
Many geospatial experts suffer from a technology-first bias, prioritizing data accuracy over strategic utility. To counter this, Stella advocates for a disciplined, seven-tool toolkit designed to bridge the gap between GIS and Product Design:

Vision: Establish a clear statement of what you are building and why it needs to exist.

User Needs: Move beyond assumptions to identify real users and their specific friction points.

Market & Context: Analyze the existing ecosystem (competitors, data, and workflows) to find your gap.

Features: Ruthlessly prioritize "must-haves" to define a lean Minimum Viable Product (MVP).

Prototypes & User Flows: Map out the user’s journey through the service before writing a line of code.

Proof of Concept: Create a tangible, working version to prove the technical and market logic.

Launch & Learn: Release early to gather real-world data and iterate based on evidence.

This structure forces builders to treat the "spatial" element as a solution rather than the entire product. To illustrate User Needs (Tool #2), Stella suggests using formal User Stories to step out of the technical mindset:

"As a solar panel marketer, I want to find potential customers with enough roof surface area so that I can reach out to them and provide an accurate quote."

By grounding the project in a specific human problem, the developer stops building for themselves and starts building for the market. As Stella notes:

"The thing about the product Swiss Army knife... is that it can be applied to almost any situation where there is an end consumer, where somebody is going to use the thing, the service that you make."

--------------------------------------------------------------------------------

3. The "200 Tools" Strategy: Programmatic Market Validation
Daniel shared an unconventional approach to product discovery that serves as a masterclass in Market Context (Tool #3). Leveraging AI, he has built nearly 200 simple geospatial tools—such as a "Roof Area Calculator"—not as final products, but as a "sandbox" for discovery.

This is Programmatic Market Validation. Instead of starting with a complex SaaS model, Daniel uses these micro-tools to find "winners" via organic search traffic. By observing where the internet already has unsolved spatial queries, he lets the market dictate which products deserve a full-scale build. In this new landscape, the barrier to entry has shifted: the competitive advantage is no longer "coding ability"—it is strategic experimentation.

--------------------------------------------------------------------------------

4. Not All Traffic is Equal: The High-Value Keyword Insight
One of the most surprising takeaways from this experimentation is the direct link between specific geospatial problems and commercial value. A general GIS data tool might get thousands of views, but a "Roof Area Calculator" generates significantly higher programmatic advertising revenue.

The reason? Market Context. The keyword "roofing" implies high-value intent; a user measuring their roof is likely in the market for a new one, making them incredibly valuable to advertisers. Understanding the commercial landscape surrounding a user's problem is the difference between a struggling hobby project and a viable MicroSaaS.

--------------------------------------------------------------------------------

5. The Precision Paradox: Why GIS Experts Struggle with UX
There is a fundamental tension between the geospatial technical mindset and the product design mindset. GIS professionals are trained to be exact, precise, and correct. Designers, however, are taught to be wrong, gather feedback, and iterate.

Daniel illustrated this with a "Hot Jar" anecdote. He once built a site where users were failing to move through the revenue funnel. Heat maps revealed the issue wasn't the data—it was the layout. Users weren't scrolling down far enough to see the critical action button. The data was perfect, but the UX was broken.

Stella emphasizes that building a product requires the humility to accept that "the best designers of products are the users themselves." Success often comes from moving a button or simplifying a flow, not from adding another decimal point of precision to the underlying geometry.

--------------------------------------------------------------------------------

6. Launching "Soft" to De-Risk the Rollout
The "perfectionism trap" is the primary reason geospatial products fail to launch. Builders fear that "releasing slop" will damage their brand. However, Stella suggests the Soft Launch (Tool #7) as a vital de-risking mechanism.

A soft launch allows you to:

Prevent Stagnation: Avoid the "quiet abandonment" of projects that never see the light of day.

Validate Demand: Ensure people actually want the tool before committing to months of development.

Build Brand and Trust: In a world where anyone can spin up a tool with AI, trust is the ultimate differentiator.

Launching early ensures continuous improvement and prevents the high-stakes pressure of a single "grand opening" that may miss the mark entirely.

--------------------------------------------------------------------------------

7. Conclusion: The Final Ponderance
Building successful geospatial products is about empathy and process, not just pixels and polygons. Whether you are building a global API or an internal tool for a government agency, the principles of the Swiss Army Knife remain the same.

At the recent Phosphag workshop in Oakland, the range of products—from print maps to digital twins—all shared a common hurdle: the energy to push through the "perfection barrier."

As you look at your current projects, ask yourself: Am I building this because the data exists, or because a human has a problem I can solve?

Success in the modern landscape requires a diversity of skills—brand, marketing, and distribution. If you aren't embarrassed by your first version, you’ve already lost the market. Stop building in the dark. Get out there and build the thing.

Why Machine-Writing Code is the Best (and Most Dangerous) Thing for Geospatial:
 
The current discourse surrounding AI coding is nothing if not polarized. On one side, the technofuturists urge us to throw away our keyboards; on the other, skeptics dismiss Large Language Models (LLMs) as little more than "fancy autocomplete" that will never replace a "real" engineer. Both sides miss the nuanced reality of the shift we are living through right now.
 
I recently sat down with Matt Hansen, Director of Geospatial Ecosystems at Element 84, to discuss this transition. With a 30-year career spanning the death of photographic film to the birth of Cloud-Native Geospatial, Hansen has a unique vantage point on how technology shifts redefine our roles. He isn’t predicting a distant future; he is describing a present where the barrier between an idea and a functioning tool has effectively collapsed.
 
The "D" Student Who Built the Future
Hansen’s journey into the heart of open-source leadership began with what he initially thought was a terminal failure. As a freshman at the Rochester Institute of Technology, he found himself in a C programming class populated almost entirely by seasoned professionals from Kodak. Intimidated and overwhelmed by the "syntax wall," he withdrew from the class the first time and scraped by with a "D" on his second attempt.
For years, he believed software simply wasn't his path. Today, however, he is a primary architect of the SpatioTemporal Asset Catalog (STAC) ecosystem and a major open-source contributor. This trajectory is the perfect case study for the democratizing power of AI: it allows the subject matter expert—the person who understands "photographic technology" or "imaging science"—to bypass the mechanical hurdles of brackets and semi-colons.
"I took your class twice and thought I was never software... and now here I am like a regular contributor to open source software for geospatial." — Matt Hansen to his former professor.
 
The Rise of "Vibe Coding" and the Fragmentation Trap
 
We are entering the era of "vibe coding," where developers prompt AI based on a general description or "vibe" of what they need. While this is exhilarating for the individual, it creates a systemic risk of "bespoke implementations." When a user asks an AI for a solution without a deep architectural understanding, the machine often generates a narrow, unvetted fragment of code rather than utilizing a secure, scalable library.
The danger here is a catastrophic loss of signal. If thousands of users release these AI-generated fragments onto platforms like GitHub, we risk drowning out the vetted, high-quality solutions that the community has spent decades building. We are creating a "sea of noise" that could make it harder for both humans and future AI models to identify the standard, proper way to solve a problem.
 
Why Geospatial is Still "Special" (The Anti-meridian Test)
 
For a long time, the industry mantra has been "geospatial isn’t special," pushing for spatial data to be treated as just another data type, like in GeoParquet. However, Hansen argues that AI actually proves that domain expertise is more critical than ever. Without specific guidance, AI often fails to account for the unique edge cases of a spherical world.
Consider the "anti-meridian" problem: polygons crossing the 180th meridian. When asked to handle spatial data, an AI will often "brute force" a custom logic that works for a small, localized dataset but fails the moment it encounters the wrap-around logic of a global scale. A domain expert knows to direct the AI toward Pete Kadomsky’s "anti-meridian" library. AI is not a subject matter expert; it is a powerful engine that requires an expert navigator to avoid the "Valley of Despair."
 
Documentation is Now SEO for the Machines
 
We are seeing a counterintuitive shift in how we value documentation. Traditionally, README files and tutorials were written by humans, for humans. In the age of AI, documentation has become the primary way we "market" our code to the machines.
If your open-source project lacks a clean README or a rigorous specification, it is effectively invisible to the AI-driven future of development. By investing in high-quality documentation, developers are engaging in a form of technical SEO. You are ensuring that when an AI looks for the "signal" in the noise, it chooses your vetted library because it is the most readable and reliable option available.
 
From Software Developers to Software Designers
 
The role of the geospatial professional is shifting from writing syntax to what Hansen calls the "Foundry" model. Using tools like GitHub Specit, the human acts as a designer, defining rigorous blueprints, constraints, and requirements in human language. The machine then executes the "how," while the human remains the sole arbiter of the "what" and "why."
Hansen’s advice for the next generation—particularly those entering a job market currently hostile to junior engineers—is to abandon generalism. Don't just learn to code; become a specialist in a domain like geospatial. The ability to write Python is becoming a commodity, but the ability to design a system that accounts for the nuances of remote sensing is an increasingly rare and valuable asset.
 
History Repeats: The "Priesthood" of Assembly
 
This shift mirrors the 1950s, when the "priesthood" of assembly programmers looked at the first compilers with deep suspicion. Kathleen Booth, who wrote the first assembly language, lived in a world where manual coding was an arcane, elite skill. Those early programmers argued that compilers were untrustworthy and that a human could always write "better" code by hand.
They were technically right about efficiency, but they were wrong about the future. Just as the compiler was "good enough" to allow us to move "up the stack" and take on more complex problems, AI is the next level of abstraction. We might use a "Ralph Wiggum script"—a loop that feeds AI output back into itself until the task is "done"—and while it may be a brute-force method, it is often more productive than the perfection of the past.
 
Conclusion: The Future is a Specialist's Game
 
We are moving away from being the writers of code and toward being the designers of systems. While the "syntax wall" has been demolished, the requirement for domain knowledge has only grown higher. The keyboard isn't dying; it is being repurposed for higher-level architectural thought.
 
As the industry experiences a "recursive improvement" of these tools, the question for every professional is no longer about whether the machine can do your job. It’s whether you have the specialized expertise to tell the machine what a "good enough" job actually looks like. Are you prepared to stop being a coder and start being a designer?

How can you accurately aggregate and compare point-based data from different parts of the world? When analyzing crime rates, population, or environmental factors, how do you divide the entire globe into equal, comparable units for analysis?
 
For data scientists and geospatial analysts, these are fundamental challenges. The solution lies in a powerful class of tools called Discrete Global Grid Systems (DGGS). These systems provide a consistent framework for partitioning the Earth's surface into a hierarchy of cells, each with a unique identifier. The most well-known systems, Google's S2 and Uber's H3, have become industry standards for everything from database optimization to logistics.
 
However, these systems come with inherent trade-offs. Now, a new DGGS called A5 has been developed to solve some of the critical limitations of its predecessors, particularly concerning area distortion and analytical accuracy.
 
Why Gridding the Globe is Harder Than It Looks
The core mathematical challenge of any DGGS is simple to state but difficult to solve: it is impossible to perfectly flatten a sphere onto a 2D grid without introducing some form of distortion. Think of trying to apply a perfect chessboard or honeycomb pattern to the surface of a ball; the shapes will inevitably have to stretch or warp to fit together without gaps.
 
All DGGS work by starting with a simple 3D shape, a polyhedron, and projecting its flat faces onto the Earth's surface. The choice of this initial shape and the specific projection method used are what determine the system's final characteristics. As a simple analogy, consider which object you’d rather be hit on the head with: a smooth ball or a spiky cube? The ball is a better approximation of a sphere. When you "inflate" a spiky polyhedron to the size of the Earth, the regions nearest the sharp vertices get stretched out the most, creating the greatest distortion.
 
A Quick Look at the Incumbents: S2 and H3
 
To understand what makes A5 different, it's essential to have some context on the most popular existing systems.
 
Google's S2: The Cube-Based Grid
The S2 system is based on projecting a cube onto the sphere. On each face of this conceptual cube, a grid like a chessboard is applied. This approach is relatively simple but introduces significant distortion at the cube’s vertices, or "spikes." As the grid is projected onto the sphere, the cells near these vertices become stretched into diamond shapes instead of remaining square. S2 is widely used under the hood for optimizing geospatial queries in database systems like Google BigQuery.
 
Uber's H3: The Hexagonal Standard
Uber's H3 system starts with an icosahedron—a 20-sided shape made of triangles. Because an icosahedron is a less "spiky" shape than a cube, H3 suffers from far less angular distortion. Its hexagonal cells look more consistent across the globe, making it popular for visualization. H3's immense success is also due to its excellent and user-friendly ecosystem of tools and libraries, making it easy for developers to adopt.
However, H3 has one critical limitation for data analysis: it is not an equal-area system. This was a deliberate trade-off, not a flaw; H3 was built by a ride-sharing company trying to match drivers to riders, a use case where exact equal area doesn't particularly matter. To wrap a sphere in hexagons, you must also include exactly 12 pentagons—just like on a soccer ball. If you look closely at a football, you'll see the pentagonal panels are slightly smaller than the hexagonal ones. This same principle causes H3 cells to vary in size. The largest and smallest hexagons at a given resolution can differ in area by a factor of two, meaning that comparing raw counts in different cells is like comparing distances in miles and kilometers without conversion. For example, cells near Buenos Aires are smaller because of their proximity to one of the system's core pentagons, creating a potential source of error if not properly normalized.
 
Introducing A5: A New System Built for Accuracy
A5 is a new DGGS designed from the ground up to prioritize analytical accuracy. It is based on a dodecahedron, a 12-sided shape with pentagonal faces that is, in the words of its creator, "even less spiky" than H3's icosahedron.
 
The motivation for A5 came from a moment of discovery. Its creator, Felix Palmer, stumbled upon a unique 2D tiling pattern made of irregular pentagons. This led to a key question: could this pattern be extended to cover the entire globe? The answer was yes, and it felt like uncovering something "very, very fundamental." This sense of intellectual curiosity, rather than a narrow business need, is the foundation upon which A5 is built.
A5's single most important feature is that it is a true equal-area system. Using a specific mathematical projection, A5 ensures that every single cell at a given resolution level has the exact same area. This guarantee even accounts for the Earth's true shape as a slightly flattened ellipsoid, not a perfect sphere.
 
This is a game-changer for analysis. By providing cells of identical size, A5 eliminates the need for analysts to perform complex area-based normalization. This prevents a common source of error and dramatically simplifies workflows when calculating metrics like population density, risk exposure, or any other value that depends on a consistent spatial unit.
 
A5 vs. H3 vs. S2: A Head-to-Head Comparison
The choice of base polyhedron and projection method results in significant differences between the major DGGS. Here is a direct comparison of their key technical characteristics.

Metric

A5

H3

S2

Base Polyhedron

Dodecahedron (12 pentagonal faces)

Icosahedron (20 triangular faces)

Cube (6 square faces)

Equal-Area Cells

Yes (Exact)

No (Up to 2x area variation)

No

Max Resolution

~30 square millimeters

~1 square meter

~1 square centimeter

Global Hierarchy

Yes (Single top-level world cell)

No (122 top-level cells)

Yes (6 top-level cells)

 
The A5 Ecosystem and its "Polyglot Mirroring" Approach
 
The success of H3 proves that a powerful mathematical system is not enough; it needs a rich ecosystem of accessible tools to gain adoption. A5 is being built with this principle in mind, but with a novel development strategy.
 
This approach is called "polyglot mirroring." Instead of building a single core library in C and creating language bindings, A5 maintains separate, complete, and equivalent codebases in multiple languages, including TypeScript, Python, and Rust. To keep these distinct codebases synchronized, Large Language Models (LLMs) are used to port changes and new features from one language to another. This strategy makes the system more accessible and maintainable for developers within each language's native community.
 
The power of this approach was proven in a true "wow moment" during A5's development. The creator, having never written a single line of Rust, fed the existing TypeScript and Python versions and a comprehensive test suite to an LLM. After about a week of guided iteration, the model produced a complete, working, high-performance Rust library. This demonstrates how modern tools can enable a single developer to build and maintain a truly multi-lingual ecosystem, something that would have been impossible just a few years ago.
 
Conclusion: When Should You Choose A5?
 
A5 offers a powerful and precise alternative to existing global grid systems. Its primary advantages make it the ideal choice for specific, demanding use cases.
 
• Statistical Validity: Any analysis where equal-area cells are paramount for accuracy is a prime candidate for A5. This includes density mapping, demographic studies, environmental modeling, and financial risk assessment.
• Extreme Resolution: For applications requiring precision beyond what H3 or S2 can offer, A5's ability to index down to cells of approximately 30 square millimeters provides unmatched granularity.
• Efficient Global Hierarchy: Workflows that need to query data at a global scale benefit from A5's simple hierarchy, which starts from a single cell representing the entire world. In contrast, loading global data with H3's 122 top-level cells could require 122 separate requests, creating unnecessary complexity and inefficiency.
To explore the A5 system, see detailed visualizations, and understand the technical comparisons in more depth, visit the official website at a5geo.org.

The Open-Source Conundrum
 
Many successful open-source projects begin with passion, but the path from a community-driven tool to a sustainable business is often a trap.
 
The most common route—relying on high-value consulting contracts—can paradoxically lead to operational chaos. Instead of a "feast or famine" cycle, many companies find themselves with more than enough work, but this success comes at a cost: a fragmented codebase, an exhausted team, and a growing disconnect from the core open-source community.
 
This episode deconstructs a proven playbook for escaping this trap: the strategic transition from a service-based consultancy to a product-led company.
 
Through the story of Jeroen Ticheler and his company, GeoCat, we will analyze how this pivot creates a more stable business, a healthier open-source community, and ultimately, a better product for everyone.

Open-source software is often described as "free," a cornerstone of the modern digital world available for anyone to download, use, and modify. But this perception of "free" masks a growing and invisible cost—not one paid in dollars, but in the finite attention, time, and mounting pressure placed on the volunteer and community maintainers.
 
This hidden tax is most acute when it comes to security.
 
Jody from Geocat, a long-time contributor to the popular GeoServer project, pulled back the curtain on the immense strain that security vulnerabilities place on the open-source ecosystem.
 
His experiences reveal critical lessons for anyone who builds, uses, or relies on open-source software.