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.