Large language models are fluent in text but blind to geometry — they can't natively reason that a point falls inside a polygon, or count features within a radius. Yet the most natural way to ask a spatial question is in plain language: "Which neighborhood has the most bike lanes?" This talk walks under the hood of a system that bridges that gap using entirely open-source geospatial building blocks.

We start with the Model Context Protocol (MCP) — the open standard for exposing tools to AI assistants — and show how a geospatial service can register spatial_query and nearby_features as callable tools. Any MCP-aware client (a QGIS plugin, a web app, a desktop AI assistant) can then ask spatial questions and get back answers, GeoJSON/PMTiles, and an interactive map.

Then we open the engine. The pipeline is:

1. Ingest vector data (GeoJSON, Shapefile, GeoPackage — 40+ formats) via pyogrio/GDAL and GeoPandas, with no hardcoded schema.
2. Index every feature into a multi-resolution H3 hexagonal grid (using h3 and the Rust-accelerated h3ronpy), storing the result as columnar Apache Parquet.
3. Answer by routing the question through an LLM that generates SQL, executed on DuckDB directly against the Parquet H3 index — with spatial joins expressed as hexagon-cell intersections.

We'll cover the hard parts honestly: keeping the LLM from hallucinating column names, grounding it with SQL few-shot examples, and why H3 hexagons turn "is X inside Y" into a cheap integer join instead of an expensive geometry operation.

Attendees leave understanding how MCP works, why H3 + DuckDB + Parquet is a powerful FOSS stack for AI-facing spatial services, and a reusable architecture for building their own.