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

Agentic Coding for GIS People with Ujaval Gandhi

 

What can you actually do with AI coding agents if you're a GIS professional who doesn't write code? And where do you start?

 

Ujaval Gandhi spent 15 years at Google working on Google Earth, Google Maps and Google Earth Engine. Today he runs Spatial Thoughts, where he makes open learning material that helps people pick up modern geospatial tools. We recorded this conversation in person at the Cloud Native Geospatial Forum 2026 in Snowbird, after meeting in the hallway and talking about his in-depth tutorial on agentic coding for geospatial practitioners.

In this episode we cover:

- What agentic coding is, and how a coding agent differs from copy-pasting code out of a chatbot

- What a "harness" is (tools like Claude Code and Codex), and why running in a terminal with access to your files matters for GIS work

- Setting ground rules with an agents.md or claude.md file so your agent uses trusted tools like GeoPandas, Xarray and rioxarray instead of making things up

- How agents can check their own work by making maps, looking at them, and spotting problems like a wrong projection

- Using "plan mode" to work through a problem with the agent, such as choosing a hotspot analysis method and its settings, before anything gets built

- Running sensitivity analyses because trying different settings is now fast and cheap

- Pulling in web services, databases, and basemaps alongside your local files

- Connecting agents to QGIS through MCP (Model Context Protocol), and letting the agent install things for you

- Are AI agents good cartographers? Computer use, taste, and where map-making is heading

- Being more ambitious: taking on hard problems like SAR processing and data fusion that used to feel out of reach

- Will software interfaces go away, or will every tool add an interface built for agents?

- The big question: what is our job now? Outsourcing the work vs. outsourcing the understanding

- Should newcomers still learn Python? (Yes, but being able to read code matters more than writing it)

- Choosing models, and deciding which parts of your work you should never outsource

 

Spatial Thoughts: https://spatialthoughts.com
Ujaval's agentic coding tutorial for geospatial practitioners: https://courses.spatialthoughts.com/agentic-coding-geospatial.html

High-Precision Location for Everything That Moves

GPS gets you to the right street. Point One gets you to the right door, down to one or two centimeters. In this episode, I talk with Aaron, founder and CEO of Point One Navigation, about what it takes to deliver location 100 times more accurate than standard GPS, and why no single technology can do it alone.

We start in orbit and work our way down. Aaron explains how Point One uses every major satellite system (GPS, Galileo, GLONASS and BeiDou) and removes about 95 percent of the signal error, without any new satellites or chips. He also gives an honest take on the pros and cons of the new low Earth orbit constellations, and on why they won't magically give you centimeter accuracy indoors.

We then get into building an RTK correction network from scratch: thousands of one-by-one meter land leases, in-house hardware designed to run for 10 years in the middle of nowhere, and why "cables are the enemy." From there we talk about sensor fusion, and how combining RTK, low-cost motion sensors and physics-based models gets high performance out of cheap hardware.

We also cover the "multiplayer world," where robots, autonomous cars, forklifts and drone fleets share their location to coordinate safely. Then we look at sovereign infrastructure and the impact of GPS jamming, the hard problem of moving smoothly between indoors and outdoors, and how better maps and better location keep driving each other forward.

Aaron also talks about FUSE, a conference Point One is hosting on November 19th in San Francisco. If you're building anything that depends on location, this one is for you.

 

fuse.pointonenav.com/sf discount code: FUSEMAPSCAPING

Point clouds still feel a little bit like magic to me. You walk through a room, a city, or even just your living room with a scanner or your phone, and you can recreate it afterwards. But on their own, point clouds aren't actually that smart. So what would it mean for every single point to know not just where it is, but what it is, and how it relates to everything around it?

My guest this week is Dr. Florent Poux, an adjunct professor, director of the 3D GeoData Academy, and author of 3D Data Science with Python. Florent has spent around 15 years on this one problem, and he developed the idea of the smart point cloud. And, as he pointed out just before we hit record, he's also a human, which we can't take for granted these days.

In this conversation, we get into:

What a smart point cloud is, and the layers behind it: geometry, semantics, topology, and behavior

How you build one, whether you start with a survey scanner, a drone, or a phone video

Why foundation models are great at proposing meaning but terrible at being accountable for it

Why the boring, older machine learning approach is sometimes the right choice

What changes when you can query your data in plain language, and why an agent should query a graph rather than read billions of points

Why you should build your own tools rather than rent everyone else's

Where world models, wearables, and 3D Gaussian splats fit into all of this

And somewhere along the way, we come back to Borges and the old idea of a perfect one-to-one map of the world: beautiful, faithful, and completely useless.

If you work with point clouds, 3D data, or AI in the geospatial world, this one is worth your time.

Florent's 3D GeoData Academy and his book 3D Data Science with Python are great places to continue exploring.

https://learngeodata.eu/

Cloud-Native Geospatial for Small Teams: How the Utah Geological Survey Did It

What happens when a small, technical team at a state agency decides to go cloud native? They don't have terabytes of satellite imagery. They have lots of small datasets, lots of scientists and lots of people who just want to get at the data.

In this episode, I talk with Marshall Robinson and Clinton Lunn from the Data Management Program at the Utah Geological Survey. They moved from a traditional ArcGIS Server setup to Postgres and GeoServer, and then to a cloud-native pipeline built on GeoParquet, PMTiles, and a STAC catalog.

What I really wanted from this conversation was recipes. Picture a GIS person at a local council (say, here in New Zealand) who's curious about this stuff and needs a proof of concept to take to their manager. Where do they start?

We talk about:

Why "it's cheaper" isn't a good enough reason to switch, and why it had to work and be better (they still turned off two servers and saved around $25,000 a year)

Adding things in slowly instead of ripping everything out. Postgres is still their source of truth, and the cloud-native layer is bolted on top

The "why should I care?" question from data users, and how one layer can be exposed 10 different ways so nobody has to change their workflow

Using industrial-strength tools on small data, and whether that's worth it

How new data gets from the field (or the core warehouse) into their public web apps

New staff who know Python, pointing your favourite LLM at a STAC catalog, and why machines finding your data matters

Where this is going: Zarr, Icechunk, time-series data and derivative products

The stack: Postgres, DuckDB, dbt, GDAL, GitHub Actions / Cloud Build, GeoParquet in bucket storage, STAC, PMTiles and DuckLake

Their advice if you want to try this: Start small. Tinker locally. Be kind to yourself. Let an agent help you with best practices and documentation. Before building anything yourself, connect to something that already exists (like STAC Index) to see how it works.

 

This episode is sponsored by The Cloud Native Geospatial Forum 2026

You can register at 2026.cloudnativegeo.org

We already have a map. Actually, we have lots of maps. So why did Overture build another one?

My guest in this episode is Amy Rose, CTO of the Overture Maps Foundation, and she makes a pretty compelling case. Overture isn't trying to replace OpenStreetMap — it sits downstream from it, and from hundreds of other sources, doing the unglamorous work of standardising all of that into something you can actually put into production. A light touch, as Amy puts it. Enough structure to be usable, not so much that the dataset starts trying to be everything for everybody.

We spend a good chunk of the conversation on GERS — the Global Entity Reference System. It's a persistent ID stamped on buildings, roads, places, and addresses, which means the same building in OpenStreetMap, Google, Microsoft, and the City of Vancouver all share one identifier. If you've ever wrestled a messy spatial join into submission at 11pm, you'll understand immediately why this matters. And because Overture keeps all the source records, you're not stuck with their choice of polygon. You can go and pick your own.

We also get into metadata, which Amy points out has been a dirty word for most of our careers — everybody wants it, nobody wants to write it. Except now it matters more than ever, because the biggest users of geospatial data aren't people anymore. They're machines. Humans are good at filling in missing context. Machines just produce a plausible answer and move on. That's a problem when there's critical infrastructure or human lives involved.

Plus: whether "authoritative" still means anything, how signals and evidence might replace traditional contribution models, why there's no best representation of anything — only fit for purpose — and what Amy would add to Overture next if every other problem were magically solved.

A really enjoyable conversation, and one that changed how I think about what a map actually is.