Geospatial analytics & location intelligence

Roughly every operational dataset has a "where" - stores, customers, parcels, assets, incidents - but few teams can use it beyond a pin on a map. AI lowers the entry barrier: natural-language questions become spatial SQL, messy addresses are geocoded, satellite imagery is turned into embeddings and features, and spatial models score locations for siting, risk and logistics. Typical benefit: faster, more defensible location decisions without a dedicated GIS team.

Problem & value

• Today: GIS work is done by specialists in desktop tools (QGIS, ArcGIS Pro); business analysts export CSVs and paste coordinates into BI tools. Addresses are dirty, layers come in different CRS and formats, and answering "which of our sites are within 20 minutes of a flood-prone area?" takes days.
• AI value: (1) text-to-spatial-query for non-experts, (2) automated geocoding and data fusion, (3) pretrained Earth-observation (EO) models and embeddings that replace bespoke image pipelines, (4) spatial ML for demand, suitability and risk, (5) agentic workflows that chain data access, analysis and map output.
• Data supply is improving: Copernicus Sentinel data is free and open, the Copernicus Data Space Ecosystem offers APIs and cloud processing, the INSPIRE directive and the High-Value Datasets regulation push public geodata into open access, and Overture Maps and OpenStreetMap provide global base layers [1][2][3][4]. No sourced, universal ROI figure exists; measure against your own baseline.

Variants

• Retail / real estate: site selection, catchment areas, cannibalisation analysis.
• Logistics & field service: network design, drive-time isochrones, delivery-zone optimisation (see OPT-029 for emergency deployment).
• Insurance & finance: natural-hazard exposure scoring of portfolios, geo-enrichment of risk data.
• Energy & utilities: grid and asset siting, solar/wind suitability, vegetation management.
• Public sector & municipalities: urban planning, heat-island and flood analysis, open-data portals.
• Agriculture & environment: parcel monitoring, land-use change (see VIS-021, VIS-049, VIS-038).
• Private use: route/trip planning, property search with commute filters (low complexity, Path A).

How it works

sources (vector, raster, addresses, business data)
  -> ingestion & harmonisation (CRS, formats, COG/GeoParquet, STAC catalogues)
  -> geocoding & enrichment (address -> coordinates; join with admin units, H3/S2 cells)
  -> feature layer (spatial joins, isochrones, EO embeddings, hazard layers)
  -> analysis (spatial SQL, spatial ML, suitability / MCDA, optimisation)
  -> LLM interface (question -> spatial SQL / Python; result narration)
  -> map, dashboard, export (human review of assumptions)

• Text-to-spatial-query: an LLM generates PostGIS / DuckDB-spatial / BigQuery GIS SQL or GeoPandas code from a question and a schema description; execution is sandboxed and results are checked (CRS, units, row counts) before display.
• EO foundation models: pretrained models (e.g. Prithvi-EO from NASA/IBM, Clay, Google AlphaEarth Foundations embeddings, ESA/Copernicus-linked efforts) produce per-pixel or per-tile embeddings that feed classification, similarity search ("find areas that look like this") and change detection with few labels [5][6].
• Spatial ML: gradient boosting or tabular foundation models with spatial features (distance, density, H3 aggregates); always evaluate with spatial cross-validation, since random splits leak through spatial autocorrelation.
• Human-in-the-loop: the analyst confirms generated queries, CRS and boundary choices, and signs off on decisions derived from scores.

Data preparation

Geospatial data in an SMB lives in the ERP and CRM (addresses), delivery and fleet systems (GPS traces), Excel lists of branches or customers, and external sources such as open data (OpenStreetMap, authority geoportals, census grids). Typical gaps: misspelt or incomplete addresses, no coordinates, mixed coordinate reference systems, outdated map layers, personal location data without a clear legal basis, and licences that forbid reuse.

Concrete steps: list the layers and their licences (GUIDE-003, PREP-001); extract addresses and assets from ERP/CRM (PREP-005); clean spreadsheets into tidy tables (PREP-011); geocode and deduplicate addresses with a geocoder such as Nominatim or a commercial EU service; harmonise to one CRS (EPSG:25832 or 4326); document layer definitions (PREP-012); pseudonymise or aggregate movement data to grid cells (PREP-022); check purpose and legal basis (PREP-025). Tools: QGIS, PostGIS, GeoPandas, DuckDB spatial. Related: DATA-003. Rough share of effort: 30-40 percent, mostly address cleaning.

Implementation paths

Which path for whom

• SMB: Path B. Site-selection or routing questions need the company's own customer, branch or fleet data combined with geodata APIs; no single product fits, so a thin cloud pipeline works best.
• Enterprise: Path C. An internal geodata stack (PostGIS, QGIS, open models) serves many departments (Baukasten effect) and keeps location data of customers and assets in-house.
• Developer: Path C. Open-source geospatial libraries and open-weight models run on HW2 with full control.
• Public: Path C. Authorities should run open geodata infrastructure on sovereign German or EU cloud, in line with procurement rules and the duty to keep citizen data in the sovereign domain.

Path A - Buy (off-the-shelf)

• GIS platforms with AI assistants: Esri ArcGIS (AI assistants in ArcGIS Pro / Online; deployable in EU regions), Felt (collaborative web maps with AI), CARTO (cloud-native, runs on Snowflake / BigQuery / Databricks; AI agents for spatial analysis), Foursquare Studio, Google Earth Engine / Maps Platform.
• Location data & analytics: HERE (EU, routing and location services), TomTom (EU, maps and traffic), Mapbox, Geoapify (EU, geocoding/routing APIs), Placer.ai and Unacast-type foot-traffic providers (check GDPR basis).
• EO analytics SaaS: Planet, Sentinel Hub / Planet Insights Platform (EU roots), EOX (EU), Satellogic.
• Choose A when: standard site-selection or dashboard needs, no in-house GIS engineering, EU region available.

Path B - Build on cloud APIs

• Data + compute: PostGIS on managed Postgres (EU region), BigQuery GIS, Snowflake or Databricks geospatial functions, Copernicus Data Space Ecosystem (openEO, Sentinel Hub APIs), Microsoft Planetary Computer STAC, Google Earth Engine [2][7].
• LLM layer: a frontier model (Claude, Gemini, GPT, Mistral) with tools: schema lookup, SQL execution, geocoder call, map render; MCP servers for PostGIS/QGIS exist. Use structured outputs for GeoJSON.
• Geocoding & routing: HERE, TomTom, Geoapify, or self-hosted Pelias/Nominatim for bulk or sensitive addresses.
• Visualisation: deck.gl, MapLibre, Kepler.gl, Streamlit/Dash front-ends.
• Choose B when: you need custom workflows over proprietary data and have a few developers.

Path C - Self-host (open source)

• Stack: PostGIS, DuckDB spatial, GDAL, GeoPandas, Rasterio, Apache Sedona, QGIS, GeoServer, STAC (pystac, stackstac), OpenStreetMap extracts, Valhalla/OSRM/GraphHopper routing, Pelias/Photon geocoding, MapLibre front-end.
• Models: open EO models via TorchGeo and TerraTorch (Prithvi-EO, Clay, SatMAE family, SAM-based segmentation for imagery) plus an open LLM (Qwen, Llama, Mistral, gpt-oss class) for text-to-SQL [5][6][8].
• Hardware: HW1 for vector analytics; HW2 for EO embeddings on regional extents and a ~30B LLM quantised; HW3/HW4 for national-scale imagery pipelines.
• Choose C when: addresses or location traces are sensitive, or data sovereignty is a requirement.

Path D - Custom training

Worth it for domain-specific EO tasks (crop types, roof materials, asset detection) where generic embeddings underperform. Needs hundreds to thousands of labelled tiles or polygons and spatially separated validation regions; fine-tune an existing geospatial foundation model rather than training from scratch.

State of the art (2026)

• Embeddings as a product: global annual EO embedding layers (e.g. Google's AlphaEarth Foundations dataset in Earth Engine) and open models (Prithvi-EO, Clay) make "few-label" land-cover and change analysis feasible without full ML pipelines [5][6].
• Cloud-native formats: COG, GeoParquet, STAC and Zarr are the default exchange formats; Overture Maps ships GeoParquet releases [4].
• LLM-driven GIS agents: natural-language interfaces now ship in major platforms; research systems (e.g. GeoLLM-/GIS-Copilot-style agents) show multi-step workflows, but success rates fall on multi-layer tasks with ambiguous geography.
• Limits and failure modes: LLMs confuse CRS and units (degrees vs. metres), miss topology errors, hallucinate place names, and mishandle the antimeridian or ambiguous toponyms. Modifiable areal unit problem and spatial autocorrelation can invalidate naive statistics. Foundation models trained on specific sensors transfer imperfectly across regions and seasons; cloud cover limits optical data. Treat generated spatial SQL as untrusted until validated on known cases.

Shared resources & combinations

• Same stack as DATA-001 (NL-to-SQL) and DATA-006: semantic layer, schema retrieval, SQL sandbox; add a spatial engine.
• Data prep: DATA-003 (address deduplication, master data), DATA-007 (cataloguing geodata, INSPIRE metadata).
• Imagery: VIS-021 (land use / change detection), VIS-049 (EUDR), VIS-058 (disaster damage), VIS-061 (InSAR), VIS-038 (public-authority checks) share the remote-sensing stack (HW2-HW3).
• Downstream: DATA-002 (map-based dashboard narratives), OPT-029 (resource deployment), SCI-010 (climate models as hazard layers).

Effort, cost & KPIs

• Path A: days to weeks; per-seat or consumption pricing; geocoding and tile APIs billed per request.
• Path B: 2-4 months for a first production workflow; cost drivers are data licences, imagery processing and LLM tokens.
• Path C: 3-6 months; GIS/data engineering skills are the main cost, plus a GPU for EO models.
• KPIs: geocoding match rate and positional accuracy, time from question to map, share of generated queries correct on a benchmark set, model accuracy under spatial cross-validation, decision lead time, data freshness.

People & change

Involve the department lead who owns the decision (expansion, logistics, planning) and management for budget. IT provides database and API access; data owners of customer and fleet data release the sources. The DPO and legal/compliance are needed when addresses, customer locations or vehicle traces relate to persons: check the legal basis, aggregate where possible, run a DPIA if movement data is evaluated systematically (Art. 35 GDPR) and sign an AVV with each geodata or AI provider (GUIDE-005).

Works council: depends. Analysing sites or markets does not touch it, but tracking company vehicles or staff movements is suited to monitor behaviour and triggers §87(1) no. 6 BetrVG; §90(1) no. 3 requires early information when routes or planning processes change. Public sector: staff council.

Support AI literacy (Art. 4 AI Act) with examples of map-based pitfalls, e.g. scale effects and outdated layers (GUIDE-006). Start with one concrete question and a small pilot group of planners (GUIDE-009). Typical concern: "we will be tracked". Address it with written rules: no individual tracking, aggregated outputs, retention limits. Keep humans in control: maps and rankings inform the decision, a person signs off on sites and routes.

Risks, regulation & compliance

• EU AI Act: typically minimal risk. It becomes higher-risk when outputs feed Annex III decisions (e.g. creditworthiness or insurance pricing by address, critical-infrastructure safety components, public-benefit eligibility). Art. 5 prohibitions are relevant if location or mobility data is used for social scoring or predictive profiling of individuals. Art. 4 AI literacy applies.
• GDPR: addresses, GNSS traces and mobile-location data are personal data; precise or longitudinal mobility data can reveal home, workplace, religion or health (special categories). Use aggregation, k-anonymity thresholds, purpose limitation and DPIA; check consent/legal basis for third-party footfall data (CJEU and DPA positions on location data and ePrivacy apply).
• Data licences & sector rules: OSM is ODbL (share-alike on derived databases), Copernicus has a free, full and open licence, national cadastres may restrict use; the EU Data Act and High-Value Datasets implementing regulation affect access to public geodata [3][4]. Defence and critical-infrastructure imagery use is covered separately (VIS-051).
• Mitigations: documented CRS/units, spatially separated validation, human sign-off on siting or risk decisions, audit logs of generated queries, EU-region processing.

Getting started

1. Pick one decision (e.g. new site ranking or portfolio flood exposure) and inventory the location data you hold.
2. Clean and geocode addresses (DATA-003), store in PostGIS/GeoParquet with an explicit CRS.
3. Add open layers (OSM/Overture, Copernicus, national hazard maps) and build the baseline in QGIS or CARTO.
4. Add an LLM text-to-spatial-SQL assistant over the schema; test on 30-50 known questions with ground-truth answers.
5. Add spatial ML or EO embeddings only if the baseline leaves measurable value on the table; validate spatially.

Sources

1. Copernicus programme, Sentinel data access and licence - https://www.copernicus.eu/en/access-data
2. Copernicus Data Space Ecosystem - https://dataspace.copernicus.eu/
3. European Commission - INSPIRE directive - https://knowledge-base.inspire.ec.europa.eu/
4. Overture Maps Foundation documentation - https://docs.overturemaps.org/
5. Prithvi-EO / IBM-NASA geospatial foundation models - https://github.com/NASA-IMPACT/Prithvi-EO-2.0
6. Google DeepMind - AlphaEarth Foundations - https://deepmind.google/discover/blog/alphaearth-foundations-helps-map-our-planet-in-unprecedented-detail/
7. Microsoft Planetary Computer - https://planetarycomputer.microsoft.com/
8. TorchGeo - https://github.com/microsoft/torchgeo
9. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj