Bedarf/Problem und Zielgruppe

Trockenheitslagen müssen von Fachstäben (Kanton/Gemeinde) und Fachstellen in kurzer Zeit beurteilt und in verständlicher Sprache kommuniziert werden, aber entsprechende Informationen / Texte zu erstellen ist aufwändig, Daten und Diagramme oft nicht einfach lesbar für Fachfremde («Nicht-Experten). Das führt zu hohem manuellem Aufwand, uneinheitlichen Lagebildern und verzögerten, schwer vergleichbaren Berichten. Betroffen sind Gemeindeführungsstäbe, kantonale Führungsstäbe, Fachstellen (Wasser, Wald, Landwirtschaft, Umwelt), Lagezentren, sowie Kommunikationsstellen der Verwaltung. Sehr spannend wäre es wenn ein Kantonsvertreter direkt vor Ort wäre.

(Nicht) verfügbare Daten

Verfügbar (für Prototyp, soweit öffentlich oder am Hackathon zugänglich):

• Trockenheitsplattform des Bundes www.trockenheit.ch: Aktuelle Trockenheitsindikatoren und Kartenlayer aus dem Trockenheitskontext Bund (Lage, Indikatoren, regionale Einteilung): WMS und API Im speziellen: Numerische Daten der Trockenheitsplattform, BGDI STAC Collection ch.bafu.trockenheitsdaten-numerisch: Maschinenlesbare Indikator-Zeitreihen pro Region, geeignet als primäre Datenquelle für das Briefing.

• Administrative Geodaten für Regionalisierung (Gemeinden, Kantone, Einzugsgebiete, Warnregionen), mindestens als Geometrien und IDs.

  • Warnregionen als SHP files
  • swissBOUNDARIES3D (Gesamtdatensatz)*: Landes-, Kantons-, Bezirks- und Gemeindegrenzen in Vektorform, Aktualisierung jährlich.
  • swissBOUNDARIES3D Gemeindegrenzen*: Kleinste administrative Einheit, Grundlage für Gemeindebriefings.
  • swissBOUNDARIES3D Kantonsgrenzen*: Grenzen der 26 Kantone.
  • swissBOUNDARIES3D Bezirksgrenzen*: Zwischenebene zwischen Kanton und Gemeinde.

• Grundlegende Metadaten, Legenden, Methodentexte für konsistente Interpretation der Indikatoren: Handbuch

• Einheitliche, dokumentierte Schnittstellen (API) für den automatisierten Bezug aller relevanten Layer in einem konsistenten Format.WMS und API und Feature API

• Empfohlene Terminologie für Trockenheitsbulletin

• Entwicklung eines Trockenheitsbulletins für Graubünden

• Trockenheitswarnungen und Verhaltensempfehlungen (38 Warnregionen): Definition der Warnregionen, Gefahrenstufen sowie ausformulierte Auswirkungsbeschreibungen pro Stufe (verwendbar als Textbaustein-Vorlage).

• Beispiele

  • Bulletin Trockenheit im Kanton GB_Beispiel_Landwasser_2023
  • Bulletin Trockenheit im Kanton SG 20230710
  • Trockenheitsbulletin_fiktives_20180726_bereinigt
  • Trockenheitsbulletin_fiktives_20180628_bereinigt
  • Point sécheresse du 10 juillet 2024
  • Warnung_bulletins_Kantone
  • Warnung_bulletins_Bund

Einige weitere Nützliche Daten

• Hydrologische Daten (Abfluss, Pegel, Grundwasser, Temperatur):

  • Hydrodaten.admin.ch, Portal hydrologische Daten und Vorhersagen: Aktuelle und historische Werte zu Abfluss, Wasserstand, Wassertemperatur, Grundwasser sowie Hochwasservorhersagen.
  • Aktuelle hydrologische Daten beziehen (BAFU): Übersicht der Bezugswege (LINDAS, App «Meine Pegel», SMS-Dienst).
  • LINDAS Linked Data Service (Bund): SPARQL-Endpoint für Abfluss, Wasserstand, Wassertemperatur und Hochwassergefahrenstufen, Aktualisierung alle 10 Minuten.
  • Messstationen Wassertemperatur, opendata.swiss: Standorte des BAFU-Temperaturmessnetzes an Fliessgewässern.
  • Messstationen hydrologische Untersuchungsgebiete (HUG): Rund 40 Einzugsgebiete mit langjährigen Reihen für Abfluss, Gebietsniederschlag und Verdunstung.
  • Trockenheit und Grundwasser, NAQUA (BAFU): Beobachtungsindikatoren der Nationalen Grundwasserbeobachtung NAQUA (Quellabflüsse, Grundwasserstände, Grundwassertemperatur).

• Meteorologische und klimatologische Daten (MeteoSchweiz Open Data):

  • Open Data Portal MeteoSchweiz: Einstiegsseite zu OGD-Datenangeboten seit Mai 2025.
  • Open Data Dokumentation MeteoSchweiz: Technische Anleitung zum Datenbezug über die STAC-API.
  • Automatische Wetterstationen SMN, Collection ch.meteoschweiz.ogd-smn: Bodenmessnetz, Standardgranularitäten (10 min, Stunde, Tag, Monat, Jahr).
  • NBCN Klimastationen, Homogene Messwerte: Lange homogenisierte Zeitreihen (Temperatur, Niederschlag), Basis für Klimavergleiche.
  • Klimanormwerte 1961 bis 1990 und 1991 bis 2020: Referenzwerte für Temperatur, Niederschlag und weitere Grössen, Vergleichsbasis für CDI und SPI.
  • Trockenheitsindikatoren MeteoSchweiz, Drought indices: Beschreibung der Indizes (z.B. SPI, Trockenperioden, aufeinanderfolgende Trockentage).
  • Räumliche Klimadaten, bodengestützt (Gitterdaten ogd-surface-derived-grid): Übersicht der OGD-Collections inkl. flächendeckender Niederschlags- und Temperaturraster.

• Satellitengestützte Vegetations- und Trockenheitsindikatoren (swissEO):

  • swissEO VHI, Vegetation Health Index: Tagesaktueller Vegetationszustand (10 m), kombiniert Vegetationskondition (VCI) und Thermalkondition (TCI) zu VHI, Vergleich zu Referenzperiode 1991 bis 2020.

• Verwandte Indikatoren (Korrelate Trockenheit):

  • Waldbrandgefahr.ch (BAFU): Tägliche Waldbrandgefahrenstufen pro Warnregion, Massnahmen der Kantone.
  • Datensatz Waldbrandgefahrenwarnung (ch.bafu.gefahren-waldbrand_warnung): Maschinenlesbare Tageswerte über WMS und REST-API der BGDI.
  • Schneehydrologische Vorhersagen und Wasseräquivalent (MeteoSchweiz): Schneewasseräquivalent absolut und relativ, relevant für Frühjahrs-Trockenheitsbewertung.

• Schnittstellen und API-Zugriff (Karten):

  • STAC API Dokumentation (DE): Konzepte (Collection, Item, Asset) und Abfragebeispiele.
  • Technische Dokumentation geo.admin.ch: Übersicht aller Webdienste und Release-Notes.
  • map.geo.admin.ch, Viewer mit Permalink-Funktion: Kartenviewer zur visuellen Validierung und für teilbare Permalinks von Layer-Kombinationen.
  • WMS-Dienst geo.admin.ch: Standardisierte Kartendienste (WMS, WMTS) für die direkte Einbindung von Karten in das Briefing-Layout.

Nicht verfügbar oder klärungsbedürftig (kann Teil der Challenge sein):

• Einheitliche, dokumentierte Empfehlungen/ Vorschlag Massnahmen pro Trockenheitsstufe für den automatisierten Vertrieb für verschiedene biographische Regionen: Die Bewältigung ist Aufgabe der Kantone. Wenn ein Kantonsvertreter anwesend ist könnte darauf eingegangen werden.

• Zeitreihen in ausreichend hoher zeitlicher Auflösung für standardisierte Berichte (je nach Produkt und Aktualisierung).

• Operative Verwaltungsdaten zu Massnahmen, Einschränkungen, Entnahmen, Bewässerungsverboten, Schadensmeldungen, falls gewünscht.

Erwarteter Nutzen

• Auf den lokalen Kontext abgestimmte Lageberichte zur Trockenheit entstehen in Minuten statt Stunden und sind zwischen Regionen vergleichbar.

• Gemeindestäbe und Fachstellen erhalten Werkzeug zur Erstellung eines konsistenten, nachvollziehbaren Lagebild/Massnahmenkatalog mit klarer Quellenlage und Indikatorerklärung in verständlicher Sprache (im Gegensatz zu komplexeren Diagrammen und Datengrafiken)

• Auch Medien können diese Informationen einfacher wiederverwenden (als Diagramme und wissenschaftliche Grafiken), womit eine grössere Reichweite der Inhalte erzielt werden kann.

• Kommunikation wird kohärenter, weil Textbausteine (werden bereitgestellt) und Kernaussagen auf denselben Daten basieren.

• Ein Bulletin wird auch verfügbar wenn von Seiten Bund keine Warnung aktiv ist (aktuell wird nur ein Trockenheitsbulletin erstellt, wenn eine Warnung aktiv ist, aus Ressourcengründen)

-> erlaubt somit frühzeitige Erkennung von Verschärfungen wird bewusster vom Zielpublikum aufgenommen, weil Trends besser kommunizierbar werde

Ziel für den Hackathon

• Prototyp “One Click Drought Briefing”: Auswahl einer Region (Gemeinde/Kanton) und eines Zeitfensters, danach automatisierte Generierung eines Briefings (Webansicht plus Export als PDF/HTML).

• Inhaltlicher Mindestumfang: 2 bis 4 Kernindikatoren, 1 bis 2 Karten, 1 Zeitreihe, kurze standardisierte Textzusammenfassung inkl. Unsicherheiten und Quellen. Optional: Übersetzung in FR und IT.

• Technischer Mindestumfang: reproduzierbare Pipeline (Datenbezug, Aggregation, Template), lauffähig mit offenen oder am Hackathon bereitgestellten Daten

Lösungsansätze

Mögliche Ansätze:

• Datenpipeline: Indikatoren beziehen, auf Zielregion aggregieren (Flächenmittel, Perzentile, Anteil “kritisch”), konsistente Zeitfensterlogik.

• Briefing-Template: feste Struktur (Lage, Entwicklung, Einordnung, Datengrundlage), automatische Befüllung durch Kennzahlen und Karten.

• Textgenerierung: regelbasierte Textbausteine, optional zusätzlich ein Assistenzmodus, der Erklärtext aus Metadaten erzeugt, aber keine neuen Fakten erfindet.

• UX: Zwei Modi, “Behördenbriefing” (knapp, standardisiert, für Fachstellen oder Krisenstäbe) und “My Trockenheitsbulletin” (verständlicher, mehr Erklärung, für ein breites Zielpublikum oder Medien).

• Qualität: Plausibilitätschecks (fehlende Daten, Ausreisser, Aktualität), Anzeige von Datenstand und Abdeckung.

Bereits ausprobiert (realistisch formulierbar, ohne Überclaim):

• Konzept und Grobstruktur eines standardisierten Trockenheitsbriefings (Abschnitte, Kennzahlen, Karten).

• Erste Prototyp-Idee zur Regionalaggregation von Indikatoren und zur automatischen Textbausteinlogik.

• Abgleich typischer Nutzerfragen von Fachstellen, um Inhalt und Sprache des Briefings zu definieren

Einschränkungen

• Datenzugang und Lizenzen: Es dürfen nur Daten genutzt werden, die offen sind oder für den Hackathon rechtlich und technisch freigegeben werden; keine personenbezogenen oder vertraulichen Verwaltungsdaten.

• Nachvollziehbarkeit: Ergebnisse müssen reproduzierbar sein (Code, Datenquellen, Parameter, Versionen), damit eine spätere Integration möglich ist.

• Quellenpflicht: Jede Kennzahl, Karte und Textaussage im Briefing muss auf klar benannte Datenquellen und Datenstände verweisen; keine nicht belegten Interpretationen.

• Scope: Fokus auf Prototyp und Kernnutzen (ein Regionalbriefing mit wenigen Indikatoren) statt Vollabdeckung aller Themen.

• Architektur: Möglichst offene Standards, einfache Deploybarkeit, keine harten Abhängigkeiten von proprietären Systemen, die in der Verwaltung nicht betrieben werden können.

• Qualitätsgrenzen: Indikatoren haben Unsicherheiten, Auflösungsgrenzen und Aktualisierungszyklen; diese müssen im Briefing sichtbar gemacht werden (Datenstand, Abdeckung, Limitierungen).

• Sprache und Zielpublikum: Behördenmodus knapp, konsistent, ohne Alarmismus; optionaler Public Modus getrennt, damit Produkte nicht vermischt werden.

Nachhaltigkeit

• Weiterverwendung: Der Prototyp soll als Grundlage für einen Piloten dienen (Minimalprodukt für 1 bis 2 Regionen) und in bestehende Trockenheitskommunikation bzw. Portalumfeld überführt werden, falls technisch und organisatorisch tragfähig.

• Ressourcen intern: Bereitstellung von fachlicher Begleitung und Produktverantwortung (Use Cases, Textbausteine, Qualitätssicherung) sowie technischem Review (Datenpipeline, Aggregationslogik, Reproduzierbarkeit); grob 1 bis 2 Personen mit Teilpensum über mehrere Wochen nach dem Hackathon, Budget primär über Arbeitszeit.

• Einbezug Teilnehmende: Fortführung über öffentliches Repository, Issues, kurze Follow-up Sessions, klare Roadmap für ein Pilotziel; Beitragende können gezielt bei UX, Datenpipeline, Exportlayout und Dokumentation weiterarbeiten, sofern Lizenz und Rahmen passen.

• Das Hackathon-Team wird für seinen Beitrag anerkanntIXQANOS9.pdf