Modellvergleich · Benchmark 08

21 Läufe im direkten Vergleich.

Die Einzelwerte zeigen die Variation innerhalb von 7 Agent-Modell-Systemen; Mittelwert, Median, Spannweite und Standardabweichung werden aus allen freigegebenen Läufen berechnet.

Modellvergleich mit EinzelrunsEinzelne Laufwerte, Spannweite und Mittelwert jedes Agent-Modell-Systems auf einer gemeinsamen Skala von 0 bis 100 Punkten.

Exakte Laufwerte und Kennzahlen

Modell	Laufwerte	Mittel	Median	Minimum	Maximum	Streuung
Claude Opus 5Claude Code · Cloud	92 · 91 · 90	91,0	91,0	90	92	0,8
Claude Sonnet 5Claude Code · Cloud	85 · 85 · 86	85,3	85,0	85	86	0,5
Qwen3.8-Flash-NextOpenCode · lokal · HP ZBook	81 · 83 · 87	83,7	83,0	81	87	2,5
GPT-5.6 SolCodex CLI · Cloud	78 · 83 · 83	81,3	83,0	78	83	2,4
GPT-5.6 TerraCodex CLI · Cloud	78 · 75 · 79	77,3	78,0	75	79	1,7
GPT-5.6 LunaCodex CLI · Cloud	71 · 72 · 75	72,7	72,0	71	75	1,7
Claude Haiku 4.5Claude Code · Cloud	53 · 59 · 52	54,7	53,0	52	59	3,1

Zusammensetzung der BewertungMittlere Beiträge der sechs Bewertungsbereiche für jedes Agent-Modell-System.

Sechs Bewertungsbereiche je Lauf

Die Werte sind die gewichteten Beiträge vor der abschließenden Rundung des Gesamtergebnisses.

Modell	Lauf	Ergebnis	Harte Prüfungen bestanden	Harte Artefakt- und Vollständigkeitsprüfungen	Erforderliche SpatialAgents-Skills	Fachliche Rubrik	Visuelle Übereinstimmung	Zielgerichtete Werkzeugwahl	Vermeidung redundanter Aufrufe
Claude Opus 5	1	92	15/15	25,0	10,0	35,0	18,2	3,3	0,0
Claude Opus 5	2	91	15/15	25,0	10,0	35,0	16,3	5,0	0,0
Claude Opus 5	3	90	15/15	25,0	10,0	33,5	17,7	3,3	0,0
Claude Sonnet 5	2	85	15/15	25,0	10,0	31,5	15,0	3,3	0,0
Claude Sonnet 5	3	85	15/15	25,0	10,0	32,5	13,7	3,3	0,0
Claude Sonnet 5	4	86	15/15	25,0	10,0	31,0	14,7	5,0	0,0
Qwen3.8-Flash-Next	1	81	15/15	25,0	10,0	29,5	11,8	5,0	0,0
Qwen3.8-Flash-Next	2	83	15/15	25,0	10,0	31,0	13,6	3,3	0,0
Qwen3.8-Flash-Next	3	87	15/15	25,0	10,0	32,5	14,6	5,0	0,0
GPT-5.6 Sol	1	78	15/15	25,0	10,0	33,0	9,7	0,0	0,0
GPT-5.6 Sol	2	83	15/15	25,0	10,0	33,0	15,1	0,0	0,0
GPT-5.6 Sol	3	83	15/15	25,0	10,0	32,0	15,6	0,0	0,0
GPT-5.6 Terra	1	78	15/15	25,0	10,0	32,0	10,8	0,0	0,0
GPT-5.6 Terra	2	75	15/15	25,0	10,0	31,0	9,2	0,0	0,0
GPT-5.6 Terra	3	79	15/15	25,0	10,0	31,5	12,8	0,0	0,0
GPT-5.6 Luna	1	71	15/15	25,0	10,0	29,5	6,3	0,0	0,0
GPT-5.6 Luna	2	72	15/15	25,0	10,0	33,0	3,8	0,0	0,0
GPT-5.6 Luna	3	75	15/15	25,0	10,0	30,5	9,2	0,0	0,0
Claude Haiku 4.5	1	53	13/15	21,7	10,0	15,0	0,1	5,0	1,0
Claude Haiku 4.5	2	59	14/15	23,3	10,0	16,5	0,2	5,0	4,0
Claude Haiku 4.5	3	52	12/15	20,0	10,0	11,5	0,6	5,0	5,0

Fachliche Kriterien im VergleichMittlerer Erfüllungsgrad aller elf fachlichen Kriterien über sämtliche freigegebenen Runs.

Kriterienmittel mit Laufwerten

Jede Zelle nennt zuerst das Mittel und darunter sämtliche Rohpunkte der freigegebenen Läufe.

Kriterium	Max.	Claude Opus 5	Claude Sonnet 5	Qwen3.8-Flash-Next	GPT-5.6 Sol	GPT-5.6 Terra	GPT-5.6 Luna	Claude Haiku 4.5
Initialer Plan vorhanden und nachvollziehbar	5	5,00Läufe 5 · 5 · 5	4,67Läufe 4 · 5 · 5	5,00Läufe 5 · 5 · 5	5,00Läufe 5 · 5 · 5	5,00Läufe 5 · 5 · 5	4,33Läufe 4 · 4 · 5	3,33Läufe 4 · 2 · 4
geo-api konsequent genutzt	10	10,00Läufe 10 · 10 · 10	9,67Läufe 10 · 9 · 10	7,67Läufe 5 · 9 · 9	10,00Läufe 10 · 10 · 10	9,67Läufe 10 · 10 · 9	10,00Läufe 10 · 10 · 10	2,33Läufe 3 · 3 · 1
Sechs Gefahren-Indizes physikalisch plausibel	10	10,00Läufe 10 · 10 · 10	9,33Läufe 9 · 9 · 10	8,67Läufe 8 · 9 · 9	9,00Läufe 9 · 9 · 9	9,00Läufe 9 · 9 · 9	8,33Läufe 8 · 9 · 8	5,33Läufe 5 · 7 · 4
Multi-Geometrie-Sampling sauber	8	8,00Läufe 8 · 8 · 8	8,00Läufe 8 · 8 · 8	8,00Läufe 8 · 8 · 8	8,00Läufe 8 · 8 · 8	7,67Läufe 8 · 7 · 8	7,33Läufe 8 · 8 · 6	3,33Läufe 2 · 5 · 3
HAND-Inundation und Statistik	5	5,00Läufe 5 · 5 · 5	4,33Läufe 4 · 4 · 5	4,33Läufe 5 · 4 · 4	4,33Läufe 5 · 5 · 3	5,00Läufe 5 · 5 · 5	4,00Läufe 3 · 5 · 4	1,00Läufe 1 · 2 · 0
Klimaprojektion und Klassen-Shift	7	6,67Läufe 7 · 7 · 6	6,67Läufe 7 · 7 · 6	6,67Läufe 7 · 7 · 6	7,00Läufe 7 · 7 · 7	6,33Läufe 6 · 7 · 6	7,00Läufe 7 · 7 · 7	4,33Läufe 5 · 5 · 3
Evakuierungs-Routen mit Vulnerabilitäts-Analyse	5	5,00Läufe 5 · 5 · 5	4,33Läufe 5 · 4 · 4	4,67Läufe 5 · 4 · 5	4,67Läufe 5 · 5 · 4	4,33Läufe 5 · 4 · 4	4,00Läufe 3 · 4 · 5	1,00Läufe 1 · 1 · 1
Charts: Aussage statt nur Plot	5	4,67Läufe 5 · 5 · 4	4,33Läufe 4 · 5 · 4	4,33Läufe 4 · 4 · 5	3,67Läufe 3 · 4 · 4	3,33Läufe 3 · 3 · 4	3,67Läufe 4 · 4 · 3	3,00Läufe 3 · 3 · 3
QGIS-Layer-Baum sauber organisiert	5	4,67Läufe 5 · 5 · 4	4,00Läufe 4 · 5 · 3	3,33Läufe 3 · 2 · 5	4,00Läufe 4 · 4 · 4	2,67Läufe 3 · 2 · 3	3,33Läufe 2 · 5 · 3	2,00Läufe 3 · 2 · 1
RESULTS.md als echter Bericht	5	5,00Läufe 5 · 5 · 5	4,67Läufe 5 · 5 · 4	5,00Läufe 5 · 5 · 5	5,00Läufe 5 · 5 · 5	5,00Läufe 5 · 5 · 5	5,00Läufe 5 · 5 · 5	3,00Läufe 3 · 3 · 3
Self-Review-Loop genutzt	5	5,00Läufe 5 · 5 · 5	3,33Läufe 3 · 4 · 3	4,33Läufe 4 · 5 · 4	4,67Läufe 5 · 4 · 5	5,00Läufe 5 · 5 · 5	5,00Läufe 5 · 5 · 5	0,00Läufe 0 · 0 · 0

Zeit und Token

Nicht die Geoverarbeitung kostet die Zeit, sondern das Schreiben.

Die Zeitaufteilung ist aus den Adapter-Traces rekonstruiert: Modellzeit, Geoverarbeitung, QGIS-Steuerung und Dateizugriffe müssen zusammen die Wanduhr ergeben.

Wohin die Laufzeit gehtMittlere Laufzeit je Modell, aufgeteilt in Modellzeit, Geoverarbeitung und übrige Werkzeugzeit; rechts die Schreibgeschwindigkeit in Token pro Sekunde.

Das lokale Modell verbringt im Mittel 8,24 Minuten mit der Geoverarbeitung und liegt damit vor Opus 5. Sein Rückstand bei der Wanduhr entsteht beim Schreiben: 32 Token je Sekunde einschließlich Prefill (43 in reiner Generierung) gegenüber 86 bis 103 bei den Claude-Modellen. Das Rendering in QGIS kostet bei allen gemessenen Modellen zusammen unter einer halben Minute je Modell.

Laufzeit je Lauf

Claude Haiku 4.5 braucht im Mittel 9,4 Minuten je Lauf, Qwen3.8-Flash-Next 2 Stunden und 11 Minuten. Die übrigen Cloud-Modelle liegen zwischen 33 und 56 Minuten. Die Zeitbilanz darüber zerlegt die Laufzeit für vier Systeme; diese Tabelle nennt die Wanduhr für alle sieben.

Modell	Laufzeit je Lauf in Minuten (min–max)	Mittel	Läufe
Claude Opus 5	34,0–52,8	41,3	3
Claude Sonnet 5	53,8–58,6	56,3	3
Qwen3.8-Flash-Next	85,7–162,8	130,5	3
GPT-5.6 Sol	29,2–61,6	42,0	3
GPT-5.6 Terra	32,2–35,9	33,8	3
GPT-5.6 Luna	28,2–36,3	33,4	3
Claude Haiku 4.5	8,0–10,3	9,4	3

Wanduhrzeit je Lauf aus dem Score-Export, gelesen am 19.09.2026; für alle sieben Systeme, ohne Aufschlüsselung nach Modell- und Geoverarbeitungszeit.

Werkzeugaufrufe je Lauf

Die Spanne reicht von 31 bis 471 Aufrufen je Lauf. Der längste Lauf brauchte 2 Stunden und 43 Minuten für 341 Aufrufe. Die Läufe liefen nicht-interaktiv: Eine Rückfrage an einen Menschen war technisch nicht möglich. Die Erlaubnis zum Arbeiten wird einmal am Anfang erteilt, nicht bei jedem Schritt.

Modell	Werkzeugaufrufe je Lauf (min–max)	Mittel	Läufe
Claude Opus 5	280–288	284,0	3
Claude Sonnet 5	307–403	358,7	3
Qwen3.8-Flash-Next	341–471	392,0	3
GPT-5.6 Sol	209–264	232,7	3
GPT-5.6 Terra	201–249	218,7	3
GPT-5.6 Luna	177–256	223,3	3
Claude Haiku 4.5	31–92	60,7	3

Werkzeugaufrufe je Lauf aus dem Score-Export, gezählt am 18.09.2026; die Läufe liefen nicht-interaktiv, eine Rückfrage an den Nutzer war technisch nicht möglich.

Token je LaufMittlerer Tokenverbrauch je Lauf in Millionen für jedes Agent-Modell-System.

Mehr Token kaufen keine besseren Karten: Sonnet 5 verbraucht das Fünffache der GPT-5.6-Varianten und landet vier Punkte darüber; das lokale Modell liegt beim Verbrauch etwa gleichauf mit Opus 5 und war als einziges auf Kontext-Kompaktierungen angewiesen.

Kostenbilanz

Was ein Lauf kostet.

Die Kosten je Lauf sind aus den Tokenzahlen errechnet — Anthropic-Tarife laut Herstellerdokumentation, GPT-5.6-Tarife aus zwei gegeneinander abgeglichenen Tarifübersichten; der lokale Lauf zahlt nur Strom.

Was ein Lauf kostetMittlere Kosten je Lauf in US-Dollar für jedes Agent-Modell-System, aufgeteilt nach Kostenposten; der lokale Lauf zahlt nur Strom.

Bezahlt wird nicht das Schreiben, sondern das Wiederlesen: Bei Sonnet 5 entfallen 81 Prozent der Laufkosten auf das Lesen des eigenen Kontexts und 9 Prozent auf die Textausgabe. Je Punkt kosten Opus 5 und Sonnet 5 dasselbe — 0,28 gegen 0,27 Dollar —, Opus liegt dabei 5,7 Punkte höher. Der lokale Lauf kostet 0,06 Dollar Strom; die Anschaffung des Notebooks für rund 4.000 Dollar ist darin nicht enthalten und entspricht etwa 160 Opus-Läufen.

Ohne Rabatte und ohne die Kosten der Bewertung selbst. Die GPT-5.6-Läufe vom 19.08.2026 sind zu Tarifen vom 18.09.2026 gerechnet. Die Stromkosten sind mit 0,35 EUR je Kilowattstunde angesetzt; die 70 Watt stammen aus dem Maschinenvergleich und sind nicht am Netzteil gemessen.

Wo gerechnet wird

70 Watt gegen 1.200.

Sechs der sieben Modelle sind nur über das Netz erreichbar und rechnen auf Beschleunigern, die ihre Betreiber in Gigawatt-Anlagen stellen. Das siebte lag während der Messung auf dem Schreibtisch und zog aus einem 140-Watt-Netzteil.

Lokal · vollständig im Haus

HP ZBook Ultra G1a

Rechenwerk: Ryzen AI Max+ PRO 395 mit Radeon 8060S, 70 W GPU-Budget, 140-W-Netzteil
Speicher: 128 GiB LPDDR5X, von CPU und GPU gemeinsam genutzt — dedizierter Grafikspeicher: 0,5 GiB
Modell: Qwen3.8-Flash-Next, 176,9 Mrd. Parameter, davon 10 von 512 Experten je Token aktiv
Betrieb: halogen-Server im eigenen Netz, Kontext 262.144 Token; 886 Token/s beim Lesen, 39,9 Token/s beim Schreiben
Herkunft: eigene Messung am 08.09.2026 auf dem Gerät, das die Läufe gerechnet hat

Rechenzentrum · Anthropic

Claude Opus 5, Sonnet 5, Haiku 4.5

Rechenwerk: AWS Trainium2 und Google-TPU im Verbund
Anlage: Project Rainier, rund 500.000 Trainium2-Beschleuniger, von AWS am 29.10.2025 in Betrieb gemeldet
Ausbau: bis zu 1 Mio. Google-TPU „Ironwood“ zugesagt (Google, April 2026); ein Verbund dieser Bauart fasst 9.216 Chips mit je 192 GB Speicher
Aufwand: 35,6 bis 94,5 Mio. Token je Lauf, jede Anfrage über das Netz
Herkunft: Mitteilungen von AWS und Google; die Leistungsaufnahme je Chip nennt keiner der Beteiligten

Rechenzentrum · OpenAI

GPT-5.6 Sol, Terra, Luna

Rechenwerk: NVIDIA-Beschleuniger, betrieben über Azure und das Programm Stargate
Anlage: Stargate: 500 Mrd. US-Dollar, Ziel 10 GW Anschlussleistung (OpenAI, Januar 2025)
Ausbau: Standort Abilene, Texas: über 450.000 GB200-Beschleuniger bei 1,2 GW — Presseangabe, vom Betreiber nicht bestätigt
Aufwand: 17,7 bis 19,1 Mio. Token je Lauf, jede Anfrage über das Netz
Herkunft: Mitteilung von OpenAI; Bestückung und Leistungsaufnahme je Standort sind nicht veröffentlicht

Ein Beschleuniger gegen ein Notebook

Der Blackwell B200 ist der Baustein, aus dem die Anlagen oben bestehen — im Rack-Verbund GB200 NVL72 stecken 72 davon. Verglichen wird hier ein einzelner Beschleuniger mit dem ganzen Notebook.

Kennwert	ZBook Ultra G1a	NVIDIA B200	Faktor
Speicher für das Modell	128 GB LPDDR5X, von CPU und GPU gemeinsam genutzt	186 GB HBM3e	1,5 ×
Speicherbandbreite	256 GB/s, gemessen rund 215 GB/s	8.000 GB/s	31 ×
Rechenleistung FP16	rund 30 TFLOPS (Radeon 8060S, 40 Recheneinheiten)	2.500 TFLOPS, ohne Sparsity gerechnet	84 ×
Leistungsaufnahme	70 W GPU-Budget, 140-W-Netzteil für das ganze Gerät	bis 1.200 W, nur der Beschleuniger	17 ×
Anschaffung	rund 4.000 $, vollständiges Gerät mit Display und 2-TB-SSD	30.000 bis 55.000 $, Bauteil ohne Preisliste der Hersteller	8 – 14 ×

Die erste Zeile entscheidet darüber, ob ein Modell überhaupt läuft: Ein Modell mit 177 Milliarden Parametern muss in den Speicher passen. Das Notebook hält dieselbe Größenordnung bereit wie der Beschleuniger — es liest sie nur 31-mal langsamer, und daher kommen die 39,9 Token pro Sekunde. Der Aufgabe hat das nicht geschadet: 87 Punkte im besten Lauf, einer mehr als der beste Lauf von Sonnet 5.

B200: NVIDIA-Datenblatt „Blackwell“ (Dezember 2024), Variante mit 1.200 W wie im GB200 NVL72; die dortigen Rechenwerte gelten mit Sparsity, der FP16-Wert oben ist davon die Hälfte. ZBook: eigene Messung am 08.09.2026.

Aufgabenrahmen

Vier Fragen bilden den Arbeitsrahmen.

Die Aufgabe verbindet physikalische Gefahrenindizes, drei Geometrietypen, Statistik, Klimaszenarien und ein strukturiertes QGIS-Projekt.

01
Welche räumlichen Muster zeigen sechs Naturgefahren über Stuttgart?
02
Wie sind Restaurants, Gebäude und Straßen dem Hochwasserrisiko ausgesetzt?
03
Wie korrelieren die Gefahren und wie lässt sich ein gewichteter Komposit bilden?
04
Wie verschiebt sich das Risikobild unter RCP 4.5 und RCP 8.5 bis 2050?

Vollständiger Originalprompt

Der Arbeitsauftrag im Wortlaut.

Der folgende Text entspricht exakt dem Promptfeld der Benchmarkaufgabe. Technische Bezeichner bleiben unverändert.

Prompt als Markdown

Vollständiger Benchmarkprompt

Auftrag

Das Amt für Umweltschutz und Katastrophenvorsorge der Stadt Stuttgart braucht eine integrierte Multi-Hazard- und Klimarisiko- Bewertung für das Stadtgebiet. Stuttgarts Kessellage, das Neckartal, die Hanglagen am Rand und der städtische Wärmeinsel-Effekt machen den Standort besonders aussagekräftig — sechs Naturgefahren wirken hier räumlich sehr unterschiedlich, und der Klimawandel verändert das Bild bis 2050 zusätzlich.

Du sollst diese Analyse end-to-end durchführen — von der Daten- beschaffung über die Berechnung der Gefahren-Indizes bis zu einer publikationsreifen Karten-Komposition und einem schriftlichen Bericht. Die Bewertung soll vier Kernfragen beantworten:

Topografie & Gefahren: Welche räumlichen Muster zeigen die sechs Naturgefahren über das Stadtgebiet?
Multi-Geometrie-Exposition: Welche Restaurants (Punkte), Gebäude (Polygone) und Straßenabschnitte (Linien) sind dem Hochwasser-Risiko am stärksten ausgesetzt?
Statistik & Komposit-Bewertung: Wie korrelieren die Gefahren untereinander, wie verteilen sich die Werte, und wie sieht ein gewichteter Komposit-Score aus?
Klima-Projektion: Wie verschiebt sich das Risikobild unter RCP 4.5 und RCP 8.5 bis 2050?

Bibliotheks-Empfehlung und Skill-Konsultation

Für die geodatenbasierten Berechnungen sollst du primär die geo-api-Bibliothek nutzen — sie bündelt unter GeospatialRaster und GeospatialVector genau die Datenquellen (OSM, Microsoft Planetary Computer, DWD/CORDEX, Open-Meteo) und Algorithmen (Terrain- Derivate, Spectral Indices, Zonal Statistics, Routing), die du hier brauchst. Lies dazu vor der ersten Code-Aktion den Skill geo-api. Wo geo-api keinen direkten Algorithmus hat (z.B. spezielle Vektor-Operationen, statistische Aggregationen), entscheide selbst über Fallback-Pakete — die Skills geopandas-shapely, xarray-rioxarray, rasterio, grass-gis, gdal-binaries, pyproj und qgis-styles sind verfügbar und sollen ergänzend konsultiert werden wenn die Aufgabe es erfordert.

Für QGIS-Visualisierung (Layer-Tree, Styling, Screenshots, Bookmarks, Layout) nutze die QGIS-MCP-Bridge über den Skill spatial-agent-bridge. Den Workflow-Skill bench (Coverage-Tasks- Sektion) musst du auch konsultieren — er beschreibt das RESULT.json-Schema und den Self-Review-Loop für Screenshots.

Tool-Wahl ist explizit deine Entscheidung — der Prompt schreibt keine konkreten Funktions- oder Modul-Namen vor. Begründe in deinem initialen Plan kurz, welchen Pfad du gehst und warum.

Vorgehen

Beginne mit einem schriftlichen Plan (3–8 Sätze) in der RESULT.json unter summary.plan — welche Phasen du in welcher Reihenfolge angehst, welche Skills du gelesen hast, welche Datenquellen du benutzt. Erst dann mit der Implementierung beginnen.

Erstelle früh die Verzeichnisstruktur:

artifacts/
├── data/
│   ├── basemaps/
│   ├── osm/                  (Restaurants, Gebäude, Straßen, Bezirke)
│   ├── terrain/              (DEM + Derivate)
│   ├── hazards/              (6 Gefahren-Indizes + Komposit + Inundationszonen)
│   ├── analysis/             (Sampling-Resultate, Aggregationen)
│   └── climate/              (RCP-skalierte Resultate)
├── charts/                   (matplotlib-PNGs)
└── screenshots/              (QGIS-Screenshots)

Speichere das QGIS-Projekt unter artifacts/stuttgart_hazards.qgz. Setze das Projekt-CRS bewusst (EPSG:25832 ist eine naheliegende Wahl für Süddeutschland).

Phase 1 — Studiengebiet definieren und Basisdaten beschaffen

Bestimme das Studiengebiet: das Stadtgebiet Stuttgart mit den umgebenden Höhenrücken (Bopser, Killesberg, Frauenkopf), insgesamt eine BBox von ca. 10 × 10 km. Hole für dieses Gebiet:

ein digitales Höhenmodell mit ca. 30 m Auflösung (Copernicus GLO-30 via Microsoft Planetary Computer ist Standard);
einen OSM-Basemap-Layer;
die OSM-Vektordaten: alle Restaurants (POI), alle Gebäude- Polygone, das fahrbare Straßennetz, die Stadtbezirks-Grenzen.

Hinweis zur DEM-Beschaffung: lade nur den AOI-Ausschnitt herunter, nicht ganze Kachel-Stapel.

Organisiere die geladenen Layer in QGIS in einem sinnvollen Layer- Baum (Gruppen wie "Terrain/Rohdaten", "Urban/Gebäude", "POI", "Verwaltung/Bezirke", "Basemaps"). Style-Beispiele aus dem Skill qgis-styles sind willkommen.

Mache am Ende der Phase einen Übersichts-Screenshot.

Phase 2 — Terrain-Derivate

Aus dem DEM müssen die wichtigsten Geländeableitungen entstehen. Mindestens nötig sind:

Hangneigung (Slope, in Grad)
Exposition (Aspect, 0-360°)
topographische Position (z.B. TPI auf ~330 m Fensterradius)
topographic wetness index (z.B. TWI)
Ruggedness (z.B. TRI)
Profil-Krümmung
Höhe über nächstem Vorfluter (HAND)
Flow Accumulation
Hillshade (für Visualisierung)

Welche Library/welches Tool du verwendest, ist offen — geo-api hat für viele davon einen terrain-Accessor, GRASS GIS bietet spezialisierte Module (siehe Skill grass-gis), GDAL-CLI hat ein paar Basics (siehe Skill gdal-binaries). HAND ist meist der aufwändigste Schritt (Flow-Accumulation → Stream-Extraktion → vertikale Distanz).

Performance-Hinweis: Watershed-Algorithmen (besonders HAND und Flow-Accumulation) können bei naiver Python-Implementierung auf einem 10×10 km / 30-m-DEM mehrere zehn GB RAM verbrauchen. Wenn du merkst dass dein Prozess >20 GB RSS belegt, brich ab und wechsle den Pfad — GRASS GIS' r.watershed ist auf großen DEMs deutlich RAM-effizienter als Python-Pendants (zeit-tested C-Code). Alternativ kannst du den DEM vor der HAND-Berechnung downsamplen (~60 m statt 30 m halbiert die Pixel-Zahl und ein Viertel den RAM- Bedarf). Dokumentiere die Wahl unter summary.hazard_formulas.

Style die Derivate so dass die Information klar wird: Hillshade als Graustufen-Hintergrund; Slope warm; TPI divergierend (Täler/Rücken); TWI sequenziell (trocken→nass); HAND sequenziell (nahe Vorfluter→ hoch darüber).

Screenshot der Derivate-Übersicht (Hillshade + halbtransparenter Slope ist ein guter Default).

Phase 3 — Sechs Gefahren-Indizes und ein Komposit

Berechne aus den Terrain-Derivaten sechs normalisierte Gefahren- Indizes (jeweils auf [0,1] skaliert, 1 = höchste Gefahr) sowie einen gewichteten Komposit. Folgende Indizes mit folgenden physikalischen Begründungen sind erwartet:

Index	Was es modelliert	Empfohlene Komponenten
Wind-Exposition	Rücken und Westhänge sind Wind-exponiert	TPI, Westhang-Maß, relative Höhenposition, Slope
Frost-Risiko	Kaltluft sammelt sich in Tälern und feuchten Senken	Talposition (Inverse von TPI), TWI, niedrige Höhenposition
Hochwasser-Risiko	Tiefliegend nahe Vorflutern mit großem Einzugsgebiet	Inverse HAND, TWI, Flow-Accumulation
Hitzestress	Niedrige Höhe + Südhang + Stadtfaktor	Höheninverse, Südhang-Maß, urbaner Faktor (Konstante)
Hangrutsch	Steil + nass + konkav	Slope, TWI, Konkavität
Erosion (LS-Faktor)	RUSLE-LS-Faktor aus Flow × Slope	Flow-Accumulation, Slope-Funktion

Die genauen Formeln und Gewichte sind dein Ermessen — orientiere dich an Standard-Literatur (RUSLE für Erosion, TPI für Wind, HAND für Flood). Dokumentiere die gewählten Formeln in der RESULT.json unter summary.hazard_formulas.

Komposit: gewichtete Summe der sechs Indizes (deine Gewichts-Wahl, begründet — typischerweise Flood + Heat höher in einer städtischen Hitze-/Hochwasser-Domäne).

Screenshots: pro „signature"-Gefahr (Wind, Flood, Heat, Hangrutsch) eine eigene Karte über Hillshade, plus eine Komposit-Übersichts- Karte.

Zusätzlich: HAND-basierte Inundations-Zonen für drei Szenarien (1 m / 2 m / 5 m Wasserspiegel über nächstem Vorfluter). Die Zonen als Polygone exportieren (z.B. nach GPKG). Berechne und melde pro Szenario: geflutete Fläche (km²), Anzahl betroffener Gebäude, Gesamtlänge betroffener Straßen (km).

Phase 4 — Multi-Geometrie-Exposition

Drei verschiedene Geometrie-Typen sollen mit Hazard-Werten beprobt werden. Das ist bewusst so gewählt — sie verlangen unterschiedliche Raster-zu-Vektor-Extraktionsmethoden:

Restaurants (Punkte): für jeden Punkt die Werte aller 6 Gefahren
Höhe + Slope ziehen. Daraus Komposit-Score pro Restaurant berechnen (Gewichte sind deine Wahl, dokumentieren). Vier Risikoklassen (Niedrig / Mittel / Hoch / Sehr Hoch).
Gebäude (Polygone): pro Polygon den Hochwasser-Index aggregieren (Zonal-Statistics oder Centroid-Sampling — wähle was sinnvoll ist). Vier Risikoklassen.
Straßen (Linien): pro Segment ebenfalls den Hochwasser-Index aggregieren. Vier Risikoklassen, plus Linienbreite proportional zum Score in der Visualisierung.

Export aller drei Resultate jeweils als GPKG unter artifacts/data/analysis/. Die Restaurant-Resultate zusätzlich als GeoJSON und CSV.

Bezirks-Level-Aggregation: die Restaurants per Spatial-Join den Stadtbezirken zuweisen, pro Bezirk Mittelwert/Anzahl/% Hochrisiko berechnen, als Choropleth-Polygone in QGIS visualisieren.

Screenshots: pro Geometrie-Typ ein dedizierter Screenshot (Restaurants/Gebäude/Straßen jeweils nach Risikoklasse), plus Bezirks-Choropleth, plus die drei Inundationszonen.

Phase 5 — Statistik und Charts

Generiere mindestens sieben Charts als PNG unter artifacts/charts/ (matplotlib ist der naheliegende Default). Mindest-Inventar:

Korrelations-Heatmap der 6 Gefahren über alle Restaurants (6×6, Pearson, divergierende Farbskala mit annotierten Werten);
Histogramm-Panel der 6 Gefahren (Verteilungs-Form je Hazard);
Radar-Charts der Top-5 risikoreichsten Restaurants;
Balkendiagramm Restaurant-Anzahl pro Risikoklasse;
Scatter Höhe × Hochwasser-Score (mit Trendlinie);
Boxplots pro Risikoklasse über alle 6 Gefahren;
Klima-Vergleichs-Balkendiagramm (Baseline vs RCP 4.5 vs RCP 8.5).

Chart 7 wird in Phase 7 berechnet, kann aber als Skelett schon hier vorbereitet sein.

Phase 6 — Hochrisiko-Inspektion und Evakuierungs-Routing

Selektiere die Restaurants mit Komposit-Score > 0.50. Zoome auf das räumliche Cluster der höchsten Konzentration und das einzelne Restaurant mit dem höchsten Score (eigene Screenshots).

Wähle die drei Restaurants mit dem höchsten Komposit-Score und berechne für jedes eine Fußgänger-Route zu einem sicheren Punkt (z.B. ein Punkt mit HAND > 10 m auf einem Höhenrücken). Die Routen-Berechnung kann über OSM-Routing erfolgen (geo-api hat dafür eine Routing-Komponente; alternativ OSMnx für Graph-basiertes Routing, siehe entsprechende Skills).

Identifiziere Routensegmente die durch Flood-prone-Bereiche (Hochwasser-Index > 0.5) laufen — das sind „vulnerable" Segmente. Report: Routen-Länge, geschätzte Gehzeit, vulnerable Anteil.

Screenshot der drei Routen mit Hervorhebung der vulnerable Segmente.

Phase 7 — Klimaprojektion (RCP 4.5 und RCP 8.5, Horizont 2050)

Wende für jeden Restaurant-Punkt Klima-Skalierungsfaktoren auf die baseline-Gefahren-Werte an. Orientierungswerte für das CORDEX- Ensemble bis 2050 (Region Süddeutschland):

Gefahr	RCP 4.5 Faktor	RCP 8.5 Faktor	Richtung
Wind	~1.00	~1.00	statisch
Frost	~0.77	~0.55	abnehmend
Hochwasser	~1.03	~1.07	leicht steigend
Hitze	~1.80	~2.59	stark steigend
Hangrutsch	~1.00	~1.00	statisch
Erosion	~1.03	~1.07	leicht steigend

Du kannst diese Faktoren direkt nutzen (Quelle: EURO-CORDEX EUR-11, MPI-M-MPI-ESM-LR, 2050) oder per geo_api.ClimateDataApi feinere Werte holen wenn das mit deinem Workflow passt. Dokumentiere in RESULT.json welche Faktoren du benutzt hast.

Pro Restaurant: skaliere jede Gefahr (gedeckelt auf 1.0), berechne den Komposit neu, ordne neue Risikoklasse zu. Speichere die Resultate als CSV unter artifacts/data/climate/. Berichte die Klassen- Verschiebung (% in jeder Klasse pro Szenario).

Generiere Chart 7 mit den realen Daten. Screenshot: side-by-side Restaurants Baseline vs RCP 8.5 in QGIS.

Phase 8 — Finalisierung

Layer-Baum für die Publikation aufräumen — eine saubere Hierarchie mit Analyse-Ergebnissen oben, Gefahren in der Mitte, Rohdaten/ Basemap unten.

Finaler Komposit-Screenshot: Hillshade + 2-m-Inundationszone semitransparent + Gebäude nach Hochwasser-Risiko + Restaurants nach Komposit-Risikoklasse + Evakuierungs-Routen sichtbar.

Schreibe einen Bericht unter artifacts/RESULTS.md (deutsch oder englisch, deine Wahl) mit den üblichen Sektionen: Executive Summary, Studiengebiet, Methodik, Ergebnisse pro Phase, Klima- Projektionen, Empfehlungen. Charts via Markdown einbetten.

Self-Review-Loop für jeden Screenshot

Aus Skill bench PROTOCOL §10 (Coverage-Tasks): nach jedem Screenshot prüfe das Bild bevor du weiter gehst. Wenn du Claude Code bist, öffne das PNG mit deinem Read-Tool und prüfe visuell. Wenn du Codex bist, nutze Bash + Python/PIL um die Pixel-Verteilung zu checken (ein std < 5 deutet auf ein leeres/uniformes Bild hin). Wenn der Screenshot die Erwartung nicht erfüllt (leer, falsch zentriert, falsche Layer sichtbar, identisch zur vorigen Phase), korrigiere und schieße neu. Maximal zwei Retries pro Phase. Dokumentiere Retries in RESULT.json unter summary.review_notes[].

Screenshot-Regeln (verbindlich)

Führe nach jedem load_project zuerst eine map_navigation aus (z. B. zoom_to_layer oder set_extent), bevor du den ersten Screenshot machst — der Canvas-Extent ist nach dem Projektladen in dieser Umgebung undefiniert und ergäbe ein leeres Bild.
Rufe get_map_screenshot IMMER mit expliziten Maßen auf: width=1600, height=1000 (dpi Default 96). Die Fenstergeometrie ist in dieser Umgebung nicht verlässlich — verlasse dich nie auf die Canvas-Größe.
Nutze NIEMALS include_overlays=true — der Widget-Grab-Pfad liefert in dieser Umgebung leere Bilder. Map-Tips sind für diese Aufgabe nicht erforderlich.
Prüfe nach jedem Screenshot den content_hash der Antwort: ist er identisch zum vorherigen Screenshot, hat sich die Karte nicht geändert — dann stimmt etwas mit Sichtbarkeit/Extent nicht (Self-Review-Loop!).

RESULT.json — was rein muss

Die RESULT.json muss dem Schema aus dem bench-Skill (PROTOCOL.md) genügen — das verlangt auf oberster Ebene zwingend task_id, run_index, mode, summary, hard_checks und anti_checks. Für jede anti.never:-Regel dieser Task muss ein anti_checks[]-Eintrag mit id, violation und evidence existieren — ein fehlender Eintrag wird als Verstoß gewertet.

Unter summary:

plan: dein initialer Plan-String (siehe oben);
phases_completed: Array ["1", "2", ..., "8"];
data_sources_used: Liste der Datenquellen-Endpunkte mit Versionen (z.B. {"copernicus_glo30": "dem 1.0", "osm_overpass": "<date>"});
hazard_formulas: Dict mit den von dir gewählten Formeln und Gewichten pro Gefahr;
climate_factors_used: Dict mit den Skalierungsfaktoren je Hazard für RCP 4.5 und RCP 8.5;
composite_weights: Dict mit deinen Gewichten für den Komposit- Score pro Geometrie-Typ;
screenshots_written: Liste der relativen Pfade;
charts_written: Liste der relativen Pfade;
inundation_stats: Dict pro Szenario {"1m": {"area_km2": ..., "buildings_affected": ..., "streets_km_affected": ...}, "2m": {...}, "5m": {...}};
risk_class_distribution: Dict {"baseline": {"Niedrig": <pct>, "Mittel": <pct>, "Hoch": <pct>, "Sehr Hoch": <pct>}, "rcp45": {...}, "rcp85": {...}};
top_10_risk_restaurants: Liste mit Name (oder ID), Bezirk, Komposit-Score, dominanter Gefahr;
evacuation_routes: Liste mit Start-Restaurant, Ziel-Koordinate, Routen-Länge_m, Gehzeit_min, vulnerable_km;
failures: Array {phase, action, error} für jeden Schritt der nicht durchging;
review_notes: Self-Review-Loop-Dokumentation;
abort_reason: String oder null.

Aufräumen am Schluss

Alle temporären QGIS-Layer, Gruppen, Bookmarks, Layouts gehören in einen Tree-Knoten Benchmark/B08_stuttgart_hazard_climate_risks/run_<N>, damit der nächste Run aus einem sauberen Zustand starten kann. Datei-Outputs in artifacts/ bleiben erhalten — die sind das Resultat der Aufgabe.

Prüfmaßstab

100 Punkte aus sechs Bewertungsbereichen.

Vollständigkeit, fachliche Qualität, visuelle Aussage und Werkzeugnutzung werden getrennt bewertet und anschließend zusammengeführt. Die Läufe nutzten das Forschungssystem des Instituts mit zusätzlichen Fachskills für Geoprocessing und der Geospatial API. Wie ein Benchmark aufgebaut ist und was er belegt, steht im dreizehnten Abschnitt der Grundlagen.

25Harte Artefakt- und Vollständigkeitsprüfungen
10Erforderliche SpatialAgents-Skills
35Fachliche Rubrik
20Visuelle Übereinstimmung
5Zielgerichtete Werkzeugwahl
5Vermeidung redundanter Aufrufe

15 harte Prüfungen

01
Eine strukturierte Ergebnisdatei ist vorhanden.
02
Der vollständige Ergebnisbericht ist vorhanden.
03
Das QGIS-Projekt wurde gespeichert.
04
Mindestens zwölf QGIS-Screenshots wurden erzeugt.
05
Mindestens fünf Diagramme wurden erzeugt.
06
Mindestens drei GeoPackages mit Analyseergebnissen liegen vor.
07
Die Inundationszonen liegen als GeoPackage vor.
08
Die Klimaszenarien liegen als tabellarische Daten vor.
09
Mindestens sechs Bearbeitungsphasen sind dokumentiert.
10
Mindestens zwölf Screenshotpfade sind dokumentiert.
11
Mindestens fünf Diagrammpfade sind dokumentiert.
12
Die Formeln der Gefahrenindizes sind dokumentiert.
13
Fläche, Gebäude und Straßenlänge der Inundationsszenarien sind dokumentiert.
14
Die Risikoklassen für Baseline und Klimaszenarien sind dokumentiert.
15
Drei Evakuierungsrouten mit Kenngrößen sind dokumentiert.

Lauf 3 bildet die dokumentierte Fallstudie. Seine Karten, Kennzahlen und das QGIS-Projekt bleiben gemeinsam an diesen Lauf gebunden.

87/100Ergebnis
15/15harte Prüfungen
65/70Rubrikpunkte
17/17Pflichtansichten
7/7Diagramme
73 %visuelle Übereinstimmung

Die SpatialAgents des Referenzlaufs nutzten die Geospatial API für Datenbeschaffung und Terrainverfahren, ergänzten geeignete Python- und GIS-Werkzeuge, bauten die Analyseprodukte als gemeinsame Dateien auf und überführten sie in ein strukturiertes QGIS-Projekt.

Die Fallstudie umfasst 656 Restaurants, 77.302 Gebäude, 11.992 Straßenobjekte, 3 Inundationsszenarien, 3 Evakuierungsrouten und 3 Risikostände für Baseline und Klimaentwicklung bis 2050.

Fachliche Ergebnisse des Referenzlaufs

Klimaverschiebung und Inundationsfolgen.

Diese Werte gehören ausschließlich zum dokumentierten Referenzlauf und ändern sich nicht durch weitere Vergleichsläufe.

Verschiebung der KlimarisikoklassenAnteile der vier Risikoklassen für Baseline, RCP 4.5 und RCP 8.5 im dokumentierten Referenzlauf.

Auswirkungen der InundationstiefenBetroffene Fläche, Gebäude und Straßenlänge bei 1, 2 und 5 Metern im dokumentierten Referenzlauf.

Inundationsscreening

Tiefe	km²	Gebäude	Straßen-km
1 m	11,238	5.741	121,68
2 m	13,606	7.914	164,45
5 m	20,012	13.394	279,62

Risikoklassen bis 2050

Szenario	Niedrig	Mittel	Hoch	Sehr Hoch
Baseline	2,60 %	75,90 %	21,30 %	0,20 %
RCP 4.5	0,30 %	13,70 %	84,50 %	1,50 %
RCP 8.5	0,00 %	15,70 %	83,10 %	1,20 %

Drei Evakuierungsrouten

Start	m	min	vulnerabel km	vulnerabel
Santini	1.975,7	23,7	0,001	0,1 %
Restaurant Spvgg Cannstatt	1.933,1	23,2	0,001	0,1 %
Köfteci Tuncay	1.975,1	23,7	0,001	0,1 %

Die Inundationsflächen, betroffenen Gebäude und Straßenlängen wachsen mit zunehmender Tiefe monoton. Zugleich steigt der gemeinsame Anteil Hoch und Sehr hoch von 21,5 % in der Baseline auf 86,0 % unter RCP 4.5; unter RCP 8.5 liegt er bei 84,3 %.

Sieben Diagramme

Zusammenhänge, Profile und Klimaverschiebung.

Die Korrelationsmatrix, die Radarprofile und die Klassenverschiebung tragen die Hauptaussagen. Vier weitere Diagramme dokumentieren Verteilungen und Beziehungen.

KorrelationsmatrixKorrelationsmatrix der sechs Gefahrenindizes mit beschrifteten Pearson-Koeffizienten.

GefahrenverteilungenSechs Histogramme zeigen die Werteverteilung von Wind, Frost, Hochwasser, Hitze, Hangrutschung und Erosion.

Profile der fünf höchsten RestaurantwerteRadarprofile vergleichen die sechs Gefahrenanteile der fünf höchstbewerteten Restaurants.

Restaurants je RisikoklasseBalkendiagramm mit der Zahl der Restaurants in vier Risikoklassen.

Höhe und HochwasserwertStreudiagramm von Geländehöhe und Hochwasserindex mit Trendlinie.

Gefahren nach RisikoklasseBoxplots vergleichen alle sechs Gefahrenindizes über die vier Restaurant-Risikoklassen.

Klimabedingte KlassenverschiebungBalkendiagramm vergleicht die Restaurant-Risikoklassen für Baseline, RCP 4.5 und RCP 8.5.

Karten und QGIS-Ansichten

Sechs Motive führen durch das räumliche Ergebnis.

Projektaufbau, Komposit, Gebäudeexposition, Inundation, Evakuierung und Klimavergleich bilden die primäre Kartenstrecke.

Projektübersicht und DatenbasisDEM, lokale OSM-Basemap, Restaurants, Gebäude und Bezirke im Stuttgarter Untersuchungsraum.

Komposit-GefahrenkarteDer gewichtete Komposit verbindet Tal-, Gewässer-, Hitze- und Hangmuster mit Restaurantpunkten.

Gebäude nach Hochwasserrisiko77.257 Gebäudepolygone zeigen erhöhte Klassen vor allem in tieferen Korridoren.

InundationszonenGestaffelte 1-m-, 2-m- und 5-m-Zonen folgen Gewässern und tieferen Geländebereichen.

EvakuierungsroutenDrei Fußrouten führen von hoch bewerteten Restaurants zu einem sicheren Ziel; vulnerable Teilstücke sind markiert.

Baseline und RCP 8.5Die Gegenüberstellung macht den Anstieg hoher und sehr hoher Restaurantklassen bis 2050 sichtbar.

Alle 17 Pflichtansichten öffnen

TerrainableitungenHillshade und Hangneigung machen Talsohle, Hänge und Höhenrücken sichtbar.

Wind-ExpositionDer Windindex hebt Rücken und exponierte Hänge gegenüber der Tallage hervor.

HochwasserindexGewässerkorridore erscheinen als räumlich zusammenhängende Bänder erhöhter Werte.

HitzestressHohe Werte konzentrieren sich auf tiefe, verdichtete Tallagen und südexponierte Bereiche.

HangrutschungSteile, feuchte Talkanten treten gegenüber flacheren Bereichen hervor.

Restaurant-Risiko656 Restaurants sind anhand der sechs Gefahrenwerte in vier Kompositklassen dargestellt.

Straßen nach Hochwasserrisiko11.992 Straßenobjekte sind über Klasse und Linienbreite nach Hochwasserwert differenziert.

Risiko nach StadtbezirkDie Bezirksaggregation fasst mittleres Restaurantrisiko, Anzahl und Hochrisikoanteil räumlich zusammen.

Hochrisikoauswahl33 Restaurants mit einem Kompositwert über 0,50 zeigen räumliche Konzentrationen.

Detail des höchsten WertsDer Detailausschnitt verortet das höchstbewertete Restaurant im umgebenden Gefahrenraster.

AbschlusskompositionHillshade, 2-m-Inundation, Gebäude, Restaurants und Routen sind in einer gemeinsamen QGIS-Ansicht kombiniert.

Fachliche Einordnung

Aussagekraft und Grenzen der Analyse.

Die Grenzen gehören zur Interpretation der Karten und Kennzahlen und sind Teil des dokumentierten Ergebnisses.

01
Das 30-m-Raster glättet kleinräumige Geländeformen.
02
Die HAND-Auswertung des Referenzlaufs ist eine DEM-basierte Approximation und keine hydraulische Simulation.
03
Vollständigkeit und Detailgrad der OpenStreetMap-Daten variieren räumlich.
04
Die Klimafaktoren bilden ein regionales Szenario für 2050 und keine lokale Extremereignissimulation.
05
Die Ergebnisse sind ein vergleichendes räumliches Screening und keine amtliche Hochwasser- oder Gefahrenkarte.

Erzeugte Geodaten

Vom 30-m-Raster bis zur Evakuierungsroute.

Das Inventar trennt Eingangs- und Kontextdaten, Terrainableitungen, Gefahrenprodukte und Ergebnisvektoren. Das Downloadpaket enthält eine dateigenaue Fassung.

Eingang und Kontext

Datensatz	Geometrie	Format	CRS	Umfang	Anzahl	Herkunft und Rolle
Untersuchungsraum	Ausdehnung	QGIS / GeoPackage	EPSG:25832	10 × 10 km	1	OpenStreetMap Nominatim gemeinsamer Analyseausschnitt
Höhenmodell	Raster	GeoTIFF	EPSG:25832	342 × 345 cells	117.990	Copernicus DEM GLO-30 30-m-Grundlage der Terrain- und Gefahrenanalyse
Restaurants	Punkte	GeoPackage / GeoJSON / CSV	EPSG:25832	10 × 10 km	656	OpenStreetMap punktbezogene Expositionsanalyse
Gebäude	Polygone	GeoPackage	EPSG:25832	10 × 10 km	77.302	OpenStreetMap flächenbezogene Hochwasserexposition
Fahrbare Straßen	Linien	GeoPackage	EPSG:25832	10 × 10 km	11.992	OpenStreetMap linienbezogene Hochwasserexposition
Fußwegenetz	Kanten	OpenStreetMap graph	EPSG:25832	10 × 10 km	94.304	OpenStreetMap Berechnung der Evakuierungsrouten
Stadtbezirke	Polygone	GeoPackage	EPSG:25832	Stuttgart	19	OpenStreetMap räumliche Aggregation

Terrainableitungen

Datensatz	Geometrie	Format	CRS	Umfang	Anzahl	Herkunft und Rolle
Terrainraster	Raster	GeoTIFF	EPSG:25832	342 × 345 cells each	9	Copernicus DEM derived Slope, Aspect, TPI, TWI, TRI, Profilkrümmung, Flussakkumulation, HAND und Hillshade

Gefahren und Klima

Datensatz	Geometrie	Format	CRS	Umfang	Anzahl	Herkunft und Rolle
Sechs Gefahrenindizes	Raster	GeoTIFF	EPSG:25832	342 × 345 cells each	6	terrain and urban derivatives Wind, Frost, Hochwasser, Hitze, Hangrutschung und Erosion auf [0,1]
Multi-Hazard-Komposit	Raster	GeoTIFF	EPSG:25832	342 × 345 cells	1	weighted hazard indices gemeinsame räumliche Risikodarstellung
Inundationszonen	Polygone	GeoPackage	EPSG:25832	10 × 10 km	3 scenarios	DEM-based HAND approximation Screening für 1 m, 2 m und 5 m
Klimaszenarien	Punkte und Tabellen	GeoPackage / CSV	EPSG:25832	656 restaurants	3 × 656	EURO-CORDEX orientation factors in the task Baseline, RCP 4.5 und RCP 8.5 bis 2050

Ergebnisvektoren

Datensatz	Geometrie	Format	CRS	Umfang	Anzahl	Herkunft und Rolle
Restaurants mit Risikoattributen	Punkte	GeoPackage / GeoJSON / CSV	EPSG:25832	10 × 10 km	656	sampled hazard rasters sechs Gefahren, Komposit und Risikoklasse
Gebäude mit Hochwasserrisiko	Polygone	GeoPackage	EPSG:25832	10 × 10 km	77.257	sampled flood raster Gebäudeexposition in vier Klassen
Straßen mit Hochwasserrisiko	Linien	GeoPackage	EPSG:25832	10 × 10 km	11.992	sampled flood raster Straßenexposition in vier Klassen
Hochrisikoauswahl	Punkte	GeoPackage	EPSG:25832	10 × 10 km	33	restaurant composite Restaurants mit Komposit über 0,50
Evakuierungsrouten	Linien und Punkte	GeoPackage	EPSG:25832	central Stuttgart	3	OpenStreetMap pedestrian network Routen, Start- und Zielpunkte mit vulnerablen Teilstrecken

QGIS-Projekt mit Geodaten

Das Ergebnis lokal in QGIS öffnen.

Das bereinigte Paket enthält das portable Projekt, die referenzierten Daten und ein dateigenaues Manifest.

ZIP · 27,7 MB

QGIS-Paket herunterladen

relative QGIS-Datenquellen
GeoTIFF, GeoPackage, GeoJSON und CSV
README auf Deutsch und Englisch
Datenmanifest und Attribution

Enthält Informationen aus OpenStreetMap: © OpenStreetMap-Mitwirkende, ODbL 1.0. Höhenmodell und Ableitungen verwenden Copernicus DEM GLO-30. Die vollständigen Zuordnungen stehen im Paket.

OpenStreetMap Lizenz ↗ · Copernicus DEM ↗ · Öffentliche Benchmarkdaten ↗

Zweite Akte · B20–B27

Behördenakte Alpen: acht Aufgaben auf offenen ALKIS-Daten.

Claude Sonnet 5 in der Cloud gegen Qwen3.8-Flash-Next auf dem Notebook — acht Behördenaufgaben von der HQ100-Betroffenheit bis zur Geometrie-Reparatur, 34 gültige Läufe, jede Prüfung mit Evidenz und Kartenbild dokumentiert.

Behördenakte öffnen

SpatialAgents Benchmark 08