Geodatenanalyse & Standortintelligenz

Beinahe jeder operative Datensatz hat ein „Wo“ - Filialen, Kunden, Flurstücke, Anlagen, Vorfälle -, aber wenige Teams können es über eine Stecknadel auf der Karte hinaus nutzen. KI senkt die Einstiegshürde: Fragen in natürlicher Sprache werden zu räumlichem SQL, unsaubere Adressen werden geokodiert, Satellitenbilder werden in Embeddings und Merkmale umgewandelt, und räumliche Modelle bewerten Standorte für Standortwahl, Risiko und Logistik. Typischer Nutzen: schnellere, besser begründbare Standortentscheidungen ohne eigenes GIS-Team.

Problem & Nutzen

• Heute: GIS-Arbeit erledigen Spezialisten in Desktop-Werkzeugen (QGIS, ArcGIS Pro); Business-Analysten exportieren CSVs und fügen Koordinaten in BI-Werkzeuge ein. Adressen sind unsauber, Ebenen liegen in unterschiedlichen Koordinatenreferenzsystemen (CRS) und Formaten vor, und die Antwort auf „Welche unserer Standorte liegen innerhalb von 20 Minuten Entfernung zu einem hochwassergefährdeten Gebiet?“ dauert Tage.
• KI-Nutzen: (1) Text-zu-räumlicher-Abfrage für Nicht-Experten, (2) automatisierte Geokodierung und Datenfusion, (3) vortrainierte Erdbeobachtungs-Modelle (EO) und Embeddings, die maßgeschneiderte Bildpipelines ersetzen, (4) räumliches ML für Nachfrage, Eignung und Risiko, (5) agentische Workflows, die Datenzugriff, Analyse und Kartenausgabe verketten.
• Die Datenversorgung verbessert sich: Copernicus-Sentinel-Daten sind kostenlos und offen, das Copernicus Data Space Ecosystem bietet APIs und Cloud-Verarbeitung, die INSPIRE-Richtlinie und die Verordnung über hochwertige Datensätze (High-Value Datasets) öffnen öffentliche Geodaten, und Overture Maps und OpenStreetMap liefern globale Basisebenen [1][2][3][4]. Eine belegte, allgemeingültige ROI-Zahl gibt es nicht; messen Sie gegen Ihre eigene Basislinie.

Varianten

• Handel / Immobilien: Standortwahl, Einzugsgebiete, Kannibalisierungsanalyse.
• Logistik & Außendienst: Netzplanung, Fahrzeit-Isochronen, Optimierung von Liefergebieten (für Noteinsätze siehe OPT-029).
• Versicherung & Finanzen: Bewertung der Naturgefahren-Exposition von Portfolios, Geo-Anreicherung von Risikodaten.
• Energie & Versorger: Standortwahl für Netze und Anlagen, Eignung für Solar/Wind, Vegetationsmanagement.
• Öffentlicher Sektor & Kommunen: Stadtplanung, Hitzeinsel- und Hochwasseranalysen, Open-Data-Portale.
• Landwirtschaft & Umwelt: Flurstücksüberwachung, Landnutzungsänderung (siehe VIS-021, VIS-049, VIS-038).
• Private Nutzung: Routen-/Reiseplanung, Immobiliensuche mit Pendelfiltern (geringe Komplexität, Weg A).

So funktioniert es

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-zu-räumlicher-Abfrage: Ein LLM erzeugt aus einer Frage und einer Schemabeschreibung PostGIS-/DuckDB-spatial-/BigQuery-GIS-SQL oder GeoPandas- Code; die Ausführung läuft in einer Sandbox, und die Ergebnisse werden vor der Anzeige geprüft (CRS, Einheiten, Zeilenanzahl).
• EO-Foundation-Modelle: Vortrainierte Modelle (z. B. Prithvi-EO von NASA/IBM, Clay, Google AlphaEarth Foundations-Embeddings, mit ESA/Copernicus verbundene Vorhaben) erzeugen Embeddings je Pixel oder Kachel, die in Klassifikation, Ähnlichkeitssuche („finde Gebiete, die so aussehen“) und Änderungserkennung mit wenigen Labels einfließen [5][6].
• Räumliches ML: Gradient Boosting oder tabellarische Foundation-Modelle mit räumlichen Merkmalen (Distanz, Dichte, H3-Aggregate); immer mit räumlicher Kreuzvalidierung bewerten, da zufällige Aufteilungen über räumliche Autokorrelation Informationen durchsickern lassen.
• Mensch-in-der-Schleife (Human-in-the-Loop): Der Analyst bestätigt erzeugte Abfragen, CRS- und Grenzwahl und gibt aus Scores abgeleitete Entscheidungen frei.

Datenaufbereitung

Geodaten liegen im Mittelstand im ERP und CRM (Adressen), in Liefer- und Flottensystemen (GPS-Spuren), in Excel-Listen von Filialen oder Kunden und in externen Quellen wie offenen Daten (OpenStreetMap, Geoportale von Behörden, Zensusraster). Typische Lücken: falsch geschriebene oder unvollständige Adressen, fehlende Koordinaten, gemischte Koordinatenreferenzsysteme, veraltete Kartenebenen, personenbezogene Standortdaten ohne klare Rechtsgrundlage und Lizenzen, die eine Weiterverwendung verbieten.

Konkrete Schritte: Ebenen und ihre Lizenzen auflisten (GUIDE-003, PREP-001); Adressen und Anlagen aus ERP/CRM extrahieren (PREP-005); Tabellenkalkulationen in saubere Tabellen überführen (PREP-011); Adressen mit einem Geokodierer wie Nominatim oder einem kommerziellen EU-Dienst geokodieren und deduplizieren; auf ein einziges CRS vereinheitlichen (EPSG:25832 oder 4326); Ebenendefinitionen dokumentieren (PREP-012); Bewegungsdaten pseudonymisieren oder auf Rasterzellen aggregieren (PREP-022); Zweck und Rechtsgrundlage prüfen (PREP-025). Werkzeuge: QGIS, PostGIS, GeoPandas, DuckDB spatial. Verwandt: DATA-003. Grober Aufwandsanteil: 30–40 Prozent, überwiegend Adressbereinigung.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg B. Fragen zur Standortwahl oder Routenplanung brauchen die eigenen Kunden-, Filial- oder Flottendaten in Kombination mit Geodaten-APIs; kein einzelnes Produkt passt, daher funktioniert eine schlanke Cloud-Pipeline am besten.
• Großunternehmen: Weg C. Ein interner Geodaten-Stack (PostGIS, QGIS, offene Modelle) bedient viele Abteilungen (Baukasten-Effekt) und hält Standortdaten von Kunden und Anlagen im Haus.
• Entwickler: Weg C. Open-Source-Geobibliotheken und Modelle mit offenen Gewichten laufen auf HW2 mit voller Kontrolle.
• Öffentlicher Sektor: Weg C. Behörden sollten eine offene Geodateninfrastruktur in einer souveränen deutschen oder EU-Cloud betreiben, im Einklang mit den Vergaberegeln und der Pflicht, Bürgerdaten in der souveränen Domäne zu halten.

Weg A — Kaufen (Standardsoftware)

• GIS-Plattformen mit KI-Assistenten: Esri ArcGIS (KI-Assistenten in ArcGIS Pro / Online; in EU-Regionen einsetzbar), Felt (kollaborative Webkarten mit KI), CARTO (Cloud-nativ, läuft auf Snowflake / BigQuery / Databricks; KI-Agenten für räumliche Analysen), Foursquare Studio, Google Earth Engine / Maps Platform.
• Standortdaten & Analytik: HERE (EU, Routing- und Standortdienste), TomTom (EU, Karten und Verkehr), Mapbox, Geoapify (EU, Geokodierungs-/Routing-APIs), Placer.ai und Anbieter von Passantenfrequenzen wie Unacast (DSGVO-Grundlage prüfen).
• EO-Analytik als SaaS: Planet, Sentinel Hub / Planet Insights Platform (EU-Wurzeln), EOX (EU), Satellogic.
• Weg A wählen, wenn: Standard-Anforderungen an Standortwahl oder Dashboards, keine eigene GIS-Entwicklung, EU-Region verfügbar.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Daten + Rechenleistung: PostGIS auf verwaltetem Postgres (EU-Region), BigQuery GIS, Geodatenfunktionen von Snowflake oder Databricks, Copernicus Data Space Ecosystem (openEO, Sentinel-Hub-APIs), Microsoft Planetary Computer STAC, Google Earth Engine [2][7].
• LLM-Schicht: ein Spitzenmodell (Claude, Gemini, GPT, Mistral) mit Werkzeugen: Schema-Abfrage, SQL-Ausführung, Geokodierer-Aufruf, Kartendarstellung; MCP-Server für PostGIS/QGIS existieren. Strukturierte Ausgaben für GeoJSON nutzen.
• Geokodierung & Routing: HERE, TomTom, Geoapify oder selbst betriebenes Pelias/Nominatim für Massen- oder sensible Adressen.
• Visualisierung: deck.gl, MapLibre, Kepler.gl, Streamlit/Dash-Frontends.
• Weg B wählen, wenn: Sie individuelle Workflows über proprietäre Daten benötigen und einige Entwickler haben.

Weg C — Selbst betreiben (Open Source)

• Stack: PostGIS, DuckDB spatial, GDAL, GeoPandas, Rasterio, Apache Sedona, QGIS, GeoServer, STAC (pystac, stackstac), OpenStreetMap-Auszüge, Routing mit Valhalla/OSRM/GraphHopper, Geokodierung mit Pelias/Photon, MapLibre-Frontend.
• Modelle: offene EO-Modelle über TorchGeo und TerraTorch (Prithvi-EO, Clay, SatMAE-Familie, SAM-basierte Segmentierung für Bilder) plus ein offenes LLM (Qwen, Llama, Mistral, Klasse gpt-oss) für Text-to-SQL [5][6][8].
• Hardware: HW1 für Vektoranalytik; HW2 für EO-Embeddings auf regionalen Ausschnitten und ein quantisiertes LLM mit ca. 30B; HW3/HW4 für Bildpipelines im nationalen Maßstab.
• Weg C wählen, wenn: Adressen oder Standortspuren sensibel sind oder Datensouveränität gefordert ist.

Weg D — Eigenes Training

Lohnt sich bei fachspezifischen EO-Aufgaben (Anbaukulturen, Dachmaterialien, Anlagenerkennung), bei denen generische Embeddings schwächeln. Erfordert Hunderte bis Tausende gelabelte Kacheln oder Polygone und räumlich getrennte Validierungsregionen; ein vorhandenes Geodaten-Foundation-Modell feintunen, statt von Grund auf zu trainieren.

Stand der Technik (2026)

• Embeddings als Produkt: globale jährliche EO-Embedding-Ebenen (z. B. Googles AlphaEarth-Foundations- Datensatz in Earth Engine) und offene Modelle (Prithvi-EO, Clay) machen Landbedeckungs- und Änderungs- analysen mit wenigen Labels ohne vollständige ML-Pipelines machbar [5][6].
• Cloud-native Formate: COG, GeoParquet, STAC und Zarr sind die Standard-Austauschformate; Overture Maps veröffentlicht GeoParquet-Releases [4].
• LLM-gesteuerte GIS-Agenten: Schnittstellen in natürlicher Sprache gibt es inzwischen in großen Plattformen; Forschungssysteme (z. B. Agenten im Stil von GeoLLM/GIS-Copilot) zeigen mehrstufige Workflows, doch die Erfolgsquoten sinken bei Aufgaben mit mehreren Ebenen und mehrdeutiger Geografie.
• Grenzen und Fehlerbilder: LLMs verwechseln CRS und Einheiten (Grad vs. Meter), übersehen Topologiefehler, halluzinieren Ortsnamen und behandeln den Antimeridian oder mehrdeutige Toponyme falsch. Das Modifiable Areal Unit Problem und räumliche Autokorrelation können naive Statistiken entwerten. Auf bestimmte Sensoren trainierte Foundation-Modelle übertragen sich nur unvollkommen auf andere Regionen und Jahreszeiten; Wolkenbedeckung begrenzt optische Daten. Erzeugtes räumliches SQL als nicht vertrauenswürdig behandeln, bis es an bekannten Fällen validiert ist.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack wie DATA-001 (NL-zu-SQL) und DATA-006: semantische Schicht, Schema-Retrieval, SQL-Sandbox; dazu eine räumliche Engine.
• Datenaufbereitung: DATA-003 (Adressdeduplizierung, Stammdaten), DATA-007 (Katalogisierung von Geodaten, INSPIRE-Metadaten).
• Bilddaten: VIS-021 (Landnutzung / Änderungserkennung), VIS-049 (EUDR), VIS-058 (Katastrophenschäden), VIS-061 (InSAR), VIS-038 (Behördenprüfungen) teilen sich den Fernerkundungs-Stack (HW2–HW3).
• Nachgelagert: DATA-002 (kartenbasierte Dashboard-Erzählungen), OPT-029 (Ressourceneinsatz), SCI-010 (Klimamodelle als Gefahrenebenen).

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen; Preise je Nutzer oder nach Verbrauch; Geokodierungs- und Kachel-APIs werden je Anfrage abgerechnet.
• Weg B: 2–4 Monate für einen ersten produktiven Workflow; Kostentreiber sind Datenlizenzen, Bildverarbeitung und LLM-Tokens.
• Weg C: 3–6 Monate; GIS-/Data-Engineering-Kompetenz ist der Hauptkostenpunkt, dazu eine GPU für EO-Modelle.
• Kennzahlen: Trefferquote und Lagegenauigkeit der Geokodierung, Zeit von der Frage bis zur Karte, Anteil der erzeugten Abfragen, die an einem Benchmark-Satz korrekt sind, Modellgenauigkeit unter räumlicher Kreuzvalidierung, Vorlaufzeit der Entscheidung, Datenaktualität.

Menschen & Veränderung

Beziehen Sie die Abteilungsleitung ein, die die Entscheidung verantwortet (Expansion, Logistik, Planung), sowie die Geschäftsleitung für das Budget. Die IT stellt Datenbank- und API-Zugang bereit; die Datenverantwortlichen für Kunden- und Flottendaten geben die Quellen frei. Die/der Datenschutzbeauftragte und Legal/Compliance werden gebraucht, wenn Adressen, Kundenstandorte oder Fahrzeugspuren Personen betreffen: Rechtsgrundlage prüfen, wo möglich aggregieren, eine DSFA durchführen, wenn Bewegungsdaten systematisch ausgewertet werden (Art. 35 DSGVO), und mit jedem Geodaten- oder KI-Anbieter einen AVV abschließen (GUIDE-005).

Betriebsrat: abhängig vom Einzelfall. Die Analyse von Standorten oder Märkten berührt ihn nicht, aber die Verfolgung von Firmenfahrzeugen oder Bewegungen von Beschäftigten ist geeignet, das Verhalten zu überwachen, und löst § 87 Abs. 1 Nr. 6 BetrVG aus; § 90 Abs. 1 Nr. 3 verlangt frühzeitige Information, wenn sich Routen oder Planungsprozesse ändern. Öffentlicher Dienst: Personalrat.

Fördern Sie die KI-Kompetenz (Art. 4 KI-Verordnung) mit Beispielen für Kartenfallen, z. B. Maßstabseffekte und veraltete Ebenen (GUIDE-006). Beginnen Sie mit einer konkreten Frage und einer kleinen Pilotgruppe von Planern (GUIDE-009). Typische Sorge: „Wir werden getrackt.“ Begegnen Sie ihr mit schriftlichen Regeln: keine individuelle Verfolgung, aggregierte Ergebnisse, Speicherfristen. Behalten Sie den Menschen die Kontrolle: Karten und Rankings informieren die Entscheidung, eine Person gibt Standorte und Routen frei.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): typischerweise minimales Risiko. Das Risiko steigt, wenn Ergebnisse in Entscheidungen nach Anhang III einfließen (z. B. Kreditwürdigkeit oder Versicherungstarife nach Adresse, Sicherheitskomponenten kritischer Infrastruktur, Anspruch auf öffentliche Leistungen). Die Verbote nach Art. 5 sind relevant, wenn Standort- oder Mobilitätsdaten für Social Scoring oder prädiktives Profiling von Einzelpersonen genutzt werden. Die KI-Kompetenz nach Art. 4 gilt.
• DSGVO: Adressen, GNSS-Spuren und Mobilfunk-Standortdaten sind personenbezogene Daten; präzise oder längsschnittliche Mobilitätsdaten können Wohnort, Arbeitsplatz, Religion oder Gesundheit offenbaren (besondere Kategorien). Aggregation, k-Anonymitäts-Schwellen, Zweckbindung und DSFA nutzen; Einwilligung/Rechtsgrundlage für Passantenfrequenzdaten Dritter prüfen (Positionen des EuGH und der Datenschutzbehörden zu Standortdaten und ePrivacy sind zu beachten).
• Datenlizenzen & Branchenregeln: OSM steht unter der ODbL (Share-Alike für abgeleitete Datenbanken), Copernicus hat eine kostenlose, vollständige und offene Lizenz, nationale Kataster können die Nutzung einschränken; der EU Data Act und die Durchführungsverordnung zu hochwertigen Datensätzen beeinflussen den Zugang zu öffentlichen Geodaten [3][4]. Die Nutzung von Bildern aus Verteidigung und kritischer Infrastruktur wird gesondert behandelt (VIS-051).
• Gegenmaßnahmen: dokumentierte CRS/Einheiten, räumlich getrennte Validierung, menschliche Freigabe bei Standort- oder Risikoentscheidungen, Audit-Logs der erzeugten Abfragen, Verarbeitung in EU-Regionen.

Erste Schritte

1. Wählen Sie eine Entscheidung (z. B. Ranking neuer Standorte oder Hochwasser-Exposition des Portfolios) und inventarisieren Sie die vorhandenen Standortdaten.
2. Bereinigen und geokodieren Sie Adressen (DATA-003), speichern Sie sie in PostGIS/GeoParquet mit explizitem CRS.
3. Fügen Sie offene Ebenen hinzu (OSM/Overture, Copernicus, nationale Gefahrenkarten) und bauen Sie die Basislinie in QGIS oder CARTO.
4. Ergänzen Sie einen LLM-Assistenten für Text-zu-räumlichem-SQL über das Schema; testen Sie ihn an 30–50 bekannten Fragen mit Referenzantworten.
5. Ergänzen Sie räumliches ML oder EO-Embeddings nur, wenn die Basislinie messbaren Mehrwert ungenutzt lässt; validieren Sie räumlich.

Quellen

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