Five ways I actually use AI as a geospatial data scientist
From a 3D Manhattan in one prompt to mining 1,281 of my own conversations, and why every one of them still needs a driver who knows the territory.
I’ve written over 13,000 prompts for my geospatial Python workflows. When I went back and counted, roughly one in four was me correcting the model or pushing back on its output, and about one in eight was me demanding it prove the code actually runs. So when people ask how I use AI, the honest answer isn’t “for everything.” It’s five fairly specific ways, each with a leash.
This issue walks through those five, roughly from the outside in: a frontier model building a 3D city in a stack I’ve never learned, a foundation model reading the planet from orbit, an agent I built from scratch so nothing happens off-screen, a Skill that forces the model to look at my data before it touches the code, and finally AI turned on my own habits, mining 1,281 of my conversations to see what I actually keep doing. The through-line is the same in all five: the model is fast, geography is unforgiving, and spatial errors are quiet. Everything is written out in full below, with the code, prompts, and packages linked.
1. As a builder in a stack I’ve never learned: one prompt, 46,000 buildings
When Fable 5 launched this summer, I did something I’d never done before: recorded my very first real session with a new model, live and unedited. One plain browser chat, no projects, no skill files, no desktop app, and one goal: a fully interactive 3D map of Manhattan with every building at its real height.
It got there, and the result is genuinely beautiful: glowing buildings, a neon-pink road grid, a pulse wave rolling out from the center, full camera control. It was faster than I could have built it in Python, and written entirely in WebGL, a stack I’ve honestly never learned. The final output is a single self-contained HTML file of roughly 4–5 MB, with about 46,000 extruded buildings and 10,000 road segments packed and inlined so it runs with zero network requests. But it didn’t get there alone. The AI failed to download the data three times before I uploaded it myself; the basemap didn’t work; it didn’t know which dataset to use until I pointed it at the right one; and halfway through, I dropped into a Jupyter notebook to generate the road network myself. When it reported 46,000 buildings, I could confirm that only because I know Manhattan’s footprint data very well. The tool is spectacular. It still needed a driver who knows the territory.
Then came the experiment. I had Fable write one self-contained prompt that reproduces the whole visualization, and ran it in a fresh session. The result was mostly identical, but the design drifted a bit, as some of you even pointed it out later: same prompt, same data, same model, noticeably different aesthetic choices. The post has that exact prompt plus the two OSMnx snippets to pull the data. Run it, post your version, tag me, and tell me what drifted from mine. If enough of you do, I’ll publish a gallery: one prompt, many Manhattans. Takeaway: Fable does fabelous work, but still needs sharp, surgical guidance from an expert. I can still keep my job, isn’t that wonderful?
The video, the data code, and the full prompt
2. As a layer that reads the planet: classifying buildings with Google AlphaEarth
If Fable is the model writing the code, AlphaEarth is the model reading the planet. Google’s AlphaEarth initiative condenses petabytes of satellite and remote-sensing imagery into global embeddings at 10×10 m resolution, 64 bands per pixel. That fine grain and high feature variance is exactly what makes it interesting for urban planning: you can characterize city blocks anywhere on Earth with the same rich feature set, especially once you pair it with the right vector data.
This is my most thorough GeoAI workflow so far. It downloads the AlphaEarth embeddings directly in Python through Earth Engine, with no third-party tools, pulls OpenStreetMap building footprints with OSMnx, matches the two, and puts the bands on interactive Folium maps so you can actually see what the model is encoding. Then it trains a simple binary building classifier with scikit-learn: scaling and PCA on the embeddings, oversampling to handle class imbalance, a support vector classifier, cross-validation, and a confusion matrix at the end.
This is also where I keep my “measured vs. generated” line sharpest. The embeddings are model output, but they’re distilled from real measurements, and matching them against real building footprints is how you find out whether they carry signal for your question or just look impressive on a map. It’s the most concrete answer I have to the question every foundation-model announcement raises: okay, but how do I actually use one?
The full AlphaEarth tutorial and code (paid subscribers)
3. As an engine I build from scratch: your first GeoAI agent
Agents are everywhere right now, and most tutorials hand you a framework that does the interesting part off-screen. I wanted the opposite, an agent where you can read every line. So the GeoAI agent in my Quick Guide is built from scratch: five spatial tools, a spatial index underneath them, and a hand-written agent loop that you fully understand.
It runs on Manhattan, using OpenStreetMap points of interest and the city’s neighborhood boundaries, both shipped as GeoJSON. The companion package is the complete, runnable version: the full Jupyter notebook, the agent as a command-line tool (geoai_agent.py), the dataset, pinned and tested requirements (plus a legacy set for older environments), a config file for your free Groq API key, and a one-command setup script. Unzip, drop the two GeoJSON files into a data/ folder, paste your key, run bash setup.sh. Under two minutes on any laptop: no GPU, no cloud, no paid APIs.
This is the entry point I’d hand any data scientist curious about GeoAI. You already know Python and models; what building the agent yourself teaches you is how spatial questions break down into tools, and once you’ve written the loop by hand, framework agents stop being magic. The package is free, and the full walkthrough is in the Quick Guide on Amazon.
Get the free companion package 📖
4. As a debugger, I force it to look before it fixes: the Spatial Data Interrogator
Remember that one in eight prompts where I demanded proof the code runs? Running is the easy part. Spatial analysis fails quietly: the code runs, no traceback appears, and the output looks entirely plausible, until you notice the buildings sit a few metres off the basemap, a spatial join silently returned the wrong rows, or your areas are off by a factor you never checked. And models are quick to jump to a fix before they’ve understood the problem.
So I built a Claude Skill that does the opposite: it interrogates the data before it writes any code. It starts with three visual checks. Plot every layer together and see whether they land in the same window; read the axis labels to catch degrees versus metres; zoom to feature scale, where small offsets become obvious. Only then does it apply the code-level gates: CRS printed before and after every transform, row accounting on joins, null geometries, range plausibility, and one feature verified by hand. It also carries a reference of version-drift errors across h3, OSMnx, Shapely, and rasterio, including two cases where fixing the obvious error quietly creates a worse one.
The principle underneath is the one sentence I’d want every spatial analyst to remember: metadata is an assertion, geometry is evidence. A .prj file can be missing, wrong, or attached after the coordinates were already mangled. A plot can’t lie to you. The Skill is built from my own debugging history, it’s free (pay what you want, from €0), and it earns its keep most with the faster, cheaper models that are quickest to fix a problem they haven’t understood.
Get the Spatial Data Interrogator
5. As a mirror: mining my entire Claude history
The last way is the most uncomfortable. Your Claude history knows what you actually keep doing; you don’t, at least not precisely and not in the shape that matters. So I took my complete Claude.ai export, 1,281 conversations and 470 MB, and built a pipeline to find out which recurring workstreams deserve a dedicated Project, which belong in a Skill, and which need nothing at all.
It found 7 projects, 4 skills, and one fact I did not enjoy: 8% of my conversations existed only to locate earlier conversations. The pipeline runs locally in Claude Code against your own export zip, with nothing uploaded anywhere, and takes about 90 minutes for ~1,200 conversations, mostly unattended. It’s nine prompt files run in order (reduce, sample, induce, reconcile, classify, verify, aggregate, score, build), with numeric quality gates at every step, so a broken taxonomy shows up after one batch instead of eleven, and a validator that breaks itself on purpose to prove its green light means something.
This is the network scientist in me talking: 1,281 conversations are a system, and the recurring patterns only show up once you stop reading them one at a time. The pack bundles the prompts, a setup wizard you paste into a Claude Project as a helpdesk for the whole process, the Projects-vs-Skills scoring rubric with its thresholds spelled out, and a redaction checklist for anything that leaves your machine. Redaction is on by default. No editing required: copy, paste, run in order.
🎬 Video walkthrough 📄 The full story on Substack 👉 Get the Claude History Mining Pack
The pattern across all five
Line them up and the pattern is hard to miss. The model wrote WebGL I couldn’t, AlphaEarth encoded imagery I could never process by hand, and a hand-written loop turned a language model into something that answers spatial questions. But every one of them needed the same thing from me: knowing that Manhattan has about 46,000 buildings, that a join should return a predictable number of rows, that degrees aren’t metres. AI multiplies what you already know about the territory. It doesn’t replace it.
The Fable 5 post, the GeoAI agent package, and the Spatial Data Interrogator are free; the AlphaEarth tutorial sits in the paid archive on Substack.
If the agent and AlphaEarth sections left you wanting to know what’s actually happening inside these models, that’s the book I wrote for exactly that. 101 Steps to GeoAI from Scratch picks up where the Quick Guide stops and builds ten more GeoAI architectures in PyTorch, in the same no-magic spirit as the hand-written agent loop, and there’s a free sample if you want to check the style first. And if you’d rather go from raw OpenStreetMap data and Sentinel-2 imagery to complete city-scale pipelines, the courses on satellite data science and urban analytics live on The New Science of Maps.
📖 101 Steps to GeoAI from Scratch · free sample · 🎓 The courses
