Agentic Coding for GIS People

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.  

Republished Episode - I wanted to resurface this episode because positioning is everything, and it's a great overview of how it works.   Right now you are being bathed in radio signals from about 35 satellites, each one 20,000 km away, and every one of them is weaker than the noise floor of the receiver trying to hear it. That is GNSS, and it is the only technology on Earth that can tell you where you are in an absolute sense. Sandy Kennedy runs applied research for autonomy and positioning at Hexagon. In this conversation she walks through how satellite positioning actually works, why centimetre accuracy is so hard to get, and what the next generation of positioning looks like. We cover low earth orbit constellations, visual positioning, Wi-Fi, 5G and ultra wideband, and the one thing every one of those systems still quietly borrows from GPS. If you have ever wondered whether visual positioning is going to replace GNSS, or why nobody has just put GPS satellites in low earth orbit already, this one is for you. Show notes Sandy Kennedy is the Vice President of Innovation for Autonomy and Positioning at Hexagon. Her group does applied research: finding better ways to do what Hexagon's positioning products already do, and finding new things they could do in the future. This episode is a tour of positioning from the top down. We start 20,000 km up with the GNSS constellations, look at what a low earth orbit constellation would change, then come back down to Earth for visual positioning, Wi-Fi, 5G, ultra wideband and the private networks used in mines and warehouses. The through line is that none of these technologies replaces the others. They each have environments where they are strong and environments where they fall over, and the real work ahead is making them hand off to each other seamlessly. What "better positioning" actually means Sandy's old grad supervisor used to ask "better in which parameter?" Better depends on the job. For positioning it usually comes down to availability (how often you can get a fix), whether that fix is accurate enough to be useful, and then accessibility: can the receiver be made small enough, cheap enough and cool enough to go where it is needed. Power is not just power, it is also heat. How GNSS works Every constellation (GPS, Galileo, BeiDou, GLONASS) is a state-owned, state-operated set of synchronised satellites in medium earth orbit. Your receiver measures the time a signal took to arrive, multiplies by the speed of light, and gets a distance. Four satellites give you four unknowns: X, Y, Z and your clock offset from system time. More satellites give you redundancy, and in this case redundancy is a good thing. In open sky today a receiver can see about 35 satellites at once, each broadcasting on around three frequencies. Why centimetre accuracy is hard - The signal is below the noise floor of your receiver. There nto. You have to fish it out. - Broadcast orbits are only accurate to metres. That is remarkable for something 20,000 km away, but if you want centimetres you need precise orbits from   a correction service. - The troposphere delays the signal and changes with water vapour. The ionosphere is dispersive and tears code and carrier apart, and it follows the solar   cycle. Multi-frequency receivers can observe and remove mostally. - Multipath. In a prairie there is nothing to bounce off. Over water there is more. In a city you are surrounded by hard metal and stone, and the receiver   has to work out which arrival was the direct line of sight. Why not just put GNSS satellites in low earth orbit? Daniel pitches it as a startup idea and Sandy takes it apart, fairly. LEO is cheaper to launch to, satellites need less radiation hardening, the signal arrives stronger and cuts through foliage better (not buildingte slices through the atmosphere in a way that helps separateorbital, atmospheric and multipath errors quickly. LEO satellites can also position themselves using the existing GNSS constellations above them. The catch: a LEO pass is about 10 minutes horizon to horizon versuorbits are more disturbed by gravity variations and solaractivity, and if you want to broadcast inside the protected L-band there is a very large amount of spectrum paperwork ahead of you. Going to a higher band gives smaller antennas and jamming resilience but brings back te TV owners know well. Would we design GNSS differently today? Sandy is careful here. There were good reasons for MEO, for L-band and for the signal structure. The one thing newer constellations like Galileo are adding is authentication. GPS is a one-way broadcast with an o means unlimited passive users who never reveal themselves tothe system, and also an easy target for spoofing and jamming. Two-way systems like 5G can authenticate, but at the cost of a user limit and the user having to identify themselves to the network. Visual positioning versus GNSS Daniel raises the LinkedIn claims that visual positioning is "killing GPS". Sandy's answer: visual positioning is how humans navigate, and it is excellent at the immediate surroundings, which is exactly the dense urba But it has to be tied to a database of known coordinates tomean anything in an absolute sense, it is useless in the middle of the ocean, and it still needs a master clock, which almost always comes from GNSS. Her framing: GNSS gives you a coordinate, visual positioning givesordinate does not mean you are not lost. Terrestrial positioning Wi-Fi is good enough to get you to the right city block or building, but decentralised access points with unverified coordinates make it neither precise nor secure. 5G can do angle of arrival, which turns positionin problem instead of a resection, but the solution is computedat the network operator, not on your device, and only for members of the network. Ultra wideband and GNSS-like ground transmitters work well in warehouses and mines but they are proprietary, someone has to install andsation always lags the first proprietary wave. The future Not one breakthrough technology, but seamless combination. A logistics vehicle that moves from the truck into the warehouse and back out again is still hard to position across that boundary. Centimetre positioning rticularly small last-mile and warehouse robots that sharespace with people. Sandy also points out an inversion: reality capture treats moving objects as noise, while navigation treats them as the most important thing in the scene. Why positioning gets overlooked Position is the given quantity in every physics problem, so nobody thinks about it until it is missing. Computer vision is intuitive because it emulates what Sandy calls our "meat circuits and eyeballs". GNSS and innd estimation, but they are computationally light, need notraining data, and offer a capability humans do not have. And the thing that most surprises Sandy compared with ten years ago is that space is now a legitimate topic. It is not just Star Trek anymore. Connect with Sandy on LinkedIn https://www.linkedin.com/in/sandy-kennedy-569a6a4/ Related episodes SBAS, a base station in the sky https://mapscaping.com/podcast/satellite-based-augmentation-system-a-base-station-in-the-sky/ Navigating the past, present and future of GNSS https://mapscaping.com/podcast/navigating-the-past-present-and Where does Google's blue dot come from? https://mapscaping.com/podcast/how-google-calculates-your-location/ Alternate short description, if you prefer a question-led hook Is visual positioning going to kill GPS? Why hasn't anyone just put GNSS satellites in low earth orbit? And why does every "GPS alternative" still need GPS for its clock?

Earlier this year I ran a small experiment called the Geospatial Launchpad — six weeks of working closely with a couple of people to help them push their geospatial projects forward. West was one of them. His project is Sentinel Bird (sentinelbird.com): an archive of every Sentinel-2 visit over the Gaza Strip since 2015, with 10-meter resolution imagery for each district, interactive comparison sliders, change-over-time timelapses, and a downloadable press pack — all free, no accounts, no paywall, licensed for anyone to use for anything. In this conversation, we get into what Sentinel Bird is, why West built it, and everything he ran into along the way — the marketing, the SEO, the feedback, all the stuff that has nothing to do with the tech but everything to do with whether a project actually goes anywhere. We talk about: How frustration with English-language media coverage after October 7th turned into a geospatial side project The foundation models West is training on Sentinel-1 SAR and Sentinel-2 optical data for damage detection Making the pipeline location-agnostic, and why tiling across orbital passes is harder than it looks "The agenda is in the data" — building something opinionated without saying a word Why URL structure is the thing you should think hardest about before you hit publish the first time Watching a real human use your site, and how humbling that is Using AI to audit your own site — what was useful, and what advice to ignore The ethics of monetizing a project you'll never put behind a paywall What worked and what didn't in the Geospatial Launchpad, and what I'd change next time West is currently open to work opportunities. If you check out Sentinel Bird and think there's something there, email him at hello @ sentinelbird.com https://sentinelbird.com/  If you're working on your own project and a bit of structure and accountability sounds appealing, there's a link in the show notes — register your interest, and if enough people are keen, I'll run the Launchpad again. Sign up for the next Geospatial Launch Pad     This episode is sponsored by xweather.com Start building with an MCP-ready weather API today. The free developer tier gives you 15,000 free API calls every month. No credit card required. No expiry. Get your free weather API key at xweather.com.  

Where does one field end and the next one begin? It sounds trivial right up until you try to answer it. In this episode, I'm joined by Hannah Kerner — Assistant Professor at Arizona State University, AI Lead for NASA Harvest and NASA Acres, and Research Advisor for Taylor Geospatial — to talk about Fields of the World.   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    

In this episode I'm joined by Apurva Shah, co-founder and CEO of Duality AI, a company building virtual worlds — or "world models" for robots and physical AI systems. Apurva's path here is an unusual one. He spent most of his career in animation, first at Pacific Data Images (which later became DreamWorks) and then over a decade at Pixar. His co-founder, Mike Taylor, comes from the other end of the spectrum entirely: a controls engineer who led field robotics at Caterpillar, deploying house-sized haul trucks at Australian mines. As Apurva puts it, if he's the pixels, Mike is the atoms. We talk about why real-world data, as valuable as it is, is never enough on its own — and how synthetic data can be used to deliberately fill the gaps and biases that creep into any collected dataset. Some of the things we get into: The difference between digital twins and 3D assets and why Duality treats twins as modular building blocks you compose into scenarios, rather than as one monolithic environment How they build environments from the ground up using DEM data, satellite imagery, photogrammetry and biome catalogues and why building them this way means everything is annotated from the start Calibrating virtual sensors against real ones, including synthetic aperture radar, and why sensor noise characteristics matter as much as physics Predicting how a material will behave across the spectrum (infrared, SAR) just from its visual response — and when that prediction breaks down Why "clutter" only becomes clutter once you know what you're looking for, and why it doesn't need to be perfect Modelling star fields for localisation in space, where there are no roads or buildings to navigate by Explicit versus generative world models, and why you need both A project with AWS simulating emergency ambulance routing through a city, complete with autonomous vehicles, traffic control and teleoperated human agents Where Duality is not the right tool molecular scale, virtual patients, drug discovery And yes, a story about robotics companies renting Airbnbs, trashing them, and leaving Towards the end we get into the bigger questions: whether AI takes our jobs or makes us better at them, where the line sits between "good enough" and slop, and why Apurva — a self-described humanist — thinks virtual environments are the one place where human and machine intelligence can genuinely learn from each other. Find out more at duality.ai, or dig into their technical writing at duality.ai/blogs

My guest today is Tyler Reid, co-founder and CTO of Xona, a company building the first commercial satellite navigation system. We get into why Tyler and his team are moving satellites into low Earth orbit and what that unlocks. Stronger signals that can penetrate indoors, more resilient timing infrastructure, and better security against jamming and spoofing. GPS sits 20,000 kilometres out. Xona sits at 1,100, with signals around 100 times stronger and a planned constellation of 258 satellites. Tyler came at this from the autonomous vehicle world at Ford, where the problem was simple enough: ten meters gets you to the store, but it doesn't keep a car in its lane. We also talk about time, and how much of the world quietly depends on GPS to keep its clocks honest. Why countries are suddenly so interested in owning their own infrastructure. And the question Xona gets asked constantly: if you're broadcasting that close to GPS, aren't you the jamming problem? If you're interested in what the future of GNSS might look like, you're really going to enjoy this one. More at xonaspace.com, or reach out to Tyler on LinkedIn.