
Hosted by MapScaping · EN

Open source software runs a huge chunk of the geospatial world — but somebody still has to pay for it. In this episode I sit down with Marco Bernasocchi creator of QField and CEO of OpenGIS.ch, to dig into the awkward question most open source projects avoid: how do you keep something free and open while paying real people to build and maintain it? Marco has been in the open source world since 2007, and he's grown QField into a tool with over two million downloads and a team of 14 behind it. We talk through how the money actually works — from sponsored feature development, to donations, to the cloud service that now funds most of what they do. Marco makes a compelling case that the real product isn't the software at all; it's convenience. You can always run it yourself. Paying just makes life easier — and keeps the project alive for everyone who can't. We also get into why he refuses to say "free software," what maintainer burnout really looks like, and his advice for any developer quietly drowning in a project they love but can't afford to keep running. A candid conversation about money, sustainability, and being a good citizen in the open source ecosystem.

Ian Schuler is the CEO of Development Seed — the team behind a lot of the open source tooling that quietly holds up the geospatial world. He's been at the helm for over a decade, and in this conversation, we dig into what he calls the great retooling: the idea that cloud-native geospatial is about to flip from an emerging pattern to the dominant one, and that AI is the thing tipping it over the edge. The argument is simple — agents want to discover your data, query it, transform it, and hand back an answer. If your data isn't in a format they can reach, you're simply not part of the conversation anymore. A really enjoyable one. I hope you get as much out of it as I did. Register for the forum 👉 https://2026.cloudnativegeo.org — This episode is sponsored by the Cloud Native Geospatial Forum. The CNG Forum 2026 runs October 6–9 at Snowbird, Utah — three days of real-world cloud-native geospatial (STAC, COGs, GeoParquet, Zarr, and more) with the teams actually building this stuff at scale, plus a hands-on workshop day to kick things off. Register at https://2026.cloudnativegeo.org

What is Earth observation, really — and why, after fifty years of satellite imagery, is it still not "mainstream"? In this episode, I'm joined by Aravind Ravichandran, founder of TerraWatch, an independent research and advisory firm focused entirely on Earth observation. Aravind writes the TerraWatch newsletter, runs the EO Summit, and spends his time thinking about the strategy and economics of the industry more deeply than just about anyone. We start with a deceptively simple question — is Earth observation even an industry? — and end up somewhere more interesting: Aravind's argument that when the technology truly succeeds, it becomes invisible, quietly embedded in agriculture, insurance, energy, and defense the same way weather satellites already are. Along the way, we get into: Why 60+ countries are now building their own satellite constellations, and whether they'll still exist in five years What Planet restricting imagery access really means — and why Aravind thinks they were "punished for doing something progressive" The technology is actually moving the needle: hyperspectral data going free, AI foundation models, edge computing on satellites, and inter-satellite laser links Which use cases are genuinely picking up (utilities, parametric insurance) — and which were always hype (counting cars in parking lots) The defense paradox: how the industry that built Earth observation may also be the biggest thing holding back its commercial future Some open questions we sit with: If satellite data is critical infrastructure, what happens when someone turns it off? Should high-resolution imagery of the whole world be open — and what are the privacy and security costs if it is? And can sixty countries ever pool their data, or will sovereignty always trump logic?

Ryan Shields has one of the most interesting careers in geospatial — from remote sensing for conservation in the Caribbean, to disaster response data engineering with FEMA, to his current role turning spatial data into animation assets for Johnny Harris's YouTube channel at New Press. In this episode, Ryan counts down the 10 tools he's using right now to tell map stories that reach millions of viewers. We cover Felt, PostGIS on Crunchy Bridge, Geo Layers 3 for After Effects, CShapes for historical borders, Natural Earth, MapTiler, Mapshaper, the new GDAL pipeline syntax, GRASS GIS, and how he's stitching it all together with Claude Code and VS Code. Along the way we get into how LLMs are changing geospatial workflows, why command-line tools are well-suited to AI agents, the limits of de facto vs de jure borders in historical datasets, and how better tooling is making data journalism viable for small communities that newsrooms usually overlook. Whether you're a cartographer, data engineer, journalist, or just map-curious, this one is packed with links worth chasing. Tools & resources mentioned in this episode Felt — https://felt.com PostGIS — https://postgis.net Crunchy Bridge — https://www.crunchybridge.com Geo Layers 3 (After Effects extension) — https://aescripts.com/geolayers/ ⚠️ verify CShapes (historical borders dataset) — https://icr.ethz.ch/data/cshapes/ ⚠️ verify Open Historical Map — https://www.openhistoricalmap.org Natural Earth — https://www.naturalearthdata.com Eduard (Swiss-style hillshading app) — https://www.eduard.earth ⚠️ verify Shaded Relief (Tom Patterson) — https://www.shadedrelief.com MapTiler — https://www.maptiler.com MapTiler Engine — https://www.maptiler.com/engine/ EPSG.io — https://epsg.io Mapshaper — https://mapshaper.org GDAL — https://gdal.org GRASS GIS — https://grass.osgeo.org QGIS — https://qgis.org DBeaver — https://dbeaver.io Claude Code — https://claude.com/claude-code ⚠️ verify VS Code — https://code.visualstudio.com Geodata Viewer (VS Code extension) — search "Geodata Viewer" in the VS Code marketplace PAI – Personal AI Infrastructure (Daniel Miessler) — https://github.com/danielmiessler ⚠️ verify exact repo Deep State Map (Ukraine conflict) — https://deepstatemap.live Johnny Harris (YouTube) — https://www.youtube.com/@johnnyharris Projects I'm working on Quick Map Tools — https://quickmaptools.com Hunting NZ — https://huntingnz.com NZ Elevation Tools — https://nzelevationtools.com Smart Query Tools — https://smartquerytools.com

Nadine Alameh is back — former CEO of the Open Geospatial Consortium, and now CEO and co-founder of Lunate AI, a six-month-old company sitting right at the messy intersection of geospatial and AI. In this conversation, Nadine breaks down the three types of clients she's seeing right now: government agencies standing at the edge of the river, wondering whether to jump in, startups from outside the geospatial world stumbling in with big ideas, and organizations that know they need to modernize but don't know who to call. We get into why the real value today is in experience and advisory rather than raw coding, why "moving up the stack" matters more than ever, and how AI agents are quietly reshaping everything — from how satellites get tasked to how dashboards (or whatever replaces them) get built. We also talk about the death of the one-size-fits-all dashboard, world models and simulations, why trust and guardrails are the actual hard work, and what it takes to go from a flashy proof-of-concept to something a bank can rely on every morning. If you're a GIS professional thinking about where to position yourself, a startup founder wandering into the geospatial world, or someone trying to figure out how AI fits into your workflows — this one's for you.

What happens when you put professional-grade aerial mapping in the hands of the people who actually live in the places being mapped? In this episode, I'm joined by Rebecca Firth, Executive Director of the Humanitarian OpenStreetMap Team (HOT) — a global community of around 750,000 people building free and open-source maps in the places that need them most. We dig into HOT's Drone Tasking Manager: a tool that lets local residents, using low-cost consumer drones, capture professional-quality aerial imagery of their own communities. Rebecca explains how it works under the hood, how dozens of pilots can coordinate to produce a single seamless mosaic, and the assumptions her team got wrong along the way — from over-engineered task locking to worrying about the wrong problems entirely. We also talk about what this looks like on the ground in Freetown, Sierra Leone, where the same drone imagery is now being used across seven city departments — for waste collection planning, disability access, flood mitigation, and soon, thermal mapping during heat waves to support local-led climate adaptation. If you care about mapping, drones, open data, or the simple idea that local people with local tools can solve problems faster than anyone flying in from outside — this one's for you. Thank you to today's sponsor, Geo Business - Registration is free.

This episode examines the Common Space initiative, a non-profit project dedicated to building and launching high-resolution optical satellites designed specifically for humanitarian purposes, such as aiding populations at risk from climate events and conflict. Although there are over a thousand Earth observation satellites currently in orbit, high-resolution imagery remains largely inaccessible to humanitarians, journalists, and civil rights groups due to high costs, restrictive licensing, and the prioritization of defense and intelligence tasking. Common Space aims to bridge the gap between low-resolution public goods (like Landsat and Sentinel) and expensive commercial options by offering 50 to 70-centimeter resolution imagery with open licensing. The project plans to utilize a "club good" funding model, where humanitarian groups can access the data for free, while commercial and government entities pay to participate to fund the system's continued operations. How will a community-driven governance model successfully navigate the ethical risks and potential misuse of releasing high-resolution conflict data in real-time? Learn more about Commonspace here https://www.commonspace.world/ Or connect with the founders here https://www.linkedin.com/in/billfgreer/ https://www.linkedin.com/in/rhiannan-price/

I've been playing around with a lot of large language models lately, and it is absolutely fascinating to watch them work. But what happens when you bring that directly into QGIS? Right now, AI in the geospatial industry is a lot like a fast, enthusiastic new intern, incredibly helpful, and sometimes completely wrong, but improving at a rate that no human can compete with. As we hand more of our geoprocessing tasks over to these algorithms, and computing becomes more pervasive, are our own GIS skills becoming obsolete? Or are we just unlocking radically different opportunities to rethink our careers?

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?