Log

 
20

🍂 One Click Drought Briefing

One Click Drought Briefing: Automatische Trockenheitslageberichte für Behörden Behörden für trockenheit.admin.ch. Daten nutzen, Wirkung entfalten: Automatisierte Lageberichte aus Verwaltungsdaten

Federal office of Topography swisstopo, Federal office of environment FOEN, Federal office of meteorology and climatology MeteoSwiss

Team Readme
✨ Demo
↓  Open

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):

Einige weitere NĂĽtzliche Daten

*Daten Trockenheit Kanton Bern

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

đź“Ž W5UED0UM.pdf

đź“Ž X4QPUBJG.pdf

GitHub

https://swisstopo.github.io/topo-drought-briefing/

README https://github.com/swisstopo/topo-drought-briefing/#drought-briefing-beta

Live on: https://swisstopo.github.io/topo-drought-briefing/

Teamchat

Teamchat

Next steps / backlog

Backlog

One Click Drought Briefing

Automated drought situation reports for Swiss authorities — from open federal data to a ready-to-share bulletin in seconds.

Built at GovTech Hackathon 2026 in partnership with swisstopo, BAFU (FOEN), and MeteoSwiss.

Live Demo (GitHub Pages) · Streamlit Cloud

The Problem

Challenge here 👉 https://govtech.digisus-lab.ch/project/16

During drought events, cantonal and municipal crisis teams must quickly assess the situation and communicate it in plain language. Today that means manually pulling data from multiple federal portals, interpreting technical indicators, and writing reports by hand — a process that takes hours, produces inconsistent results across cantons, and only happens at all when a federal warning is already active.

What We Built

A one-click pipeline that turns federal open data into a structured, bilingual (DE/FR) drought bulletin for any Swiss canton — in seconds. The bulletin includes:

  • Warning level badge (BAFU Gefahrenstufe 1–5) with plain-language situation summary
  • Regional breakdown — CDI, SPI-3m, soil moisture, VHI, precipitation, and discharge per Warnregion
  • Interactive map (choropleth by CDI / warning level) with static PNG fallback for export
  • Time-series chart (CDI trend + SPI-3m, 52 weeks)
  • Action recommendations driven by the warning level, populated from a YAML ruleset
  • Expert note fields per region — editable before export
  • Self-contained HTML export — no external URLs, suitable for government infrastructure
  • Data quality banner — staleness, coverage, and outlier flags surfaced automatically

How It Works

DataBundle (STAC / fixtures)
    → CantonReport (aggregation pipeline)
        → BriefingDocument (Jinja2 / YAML ruleset)
            → Streamlit UI  +  HTML export

Data is loaded from the BGDI STAC collection ch.bafu.trockenheitsdaten-numerisch, with live fallback to fixture data. Warning levels are fetched from the geo.admin.ch REST API (ch.bafu.trockenheitswarnkarte). Vegetation health (VHI) is fetched from SwissEO. All three clients fall back to bundled fixture data when the network is unavailable.

Bulletin text lives entirely in data/ruleset/canton-bulletin.yaml — no strings are hardcoded in Python. Thresholds, action recommendations, nomenclature, and section templates are all editable without touching code.

Data Sources

Source What we use
BGDI STAC ch.bafu.trockenheitsdaten-numerisch CDI, SPI, soil moisture, precipitation, hydro indices (weekly per Warnregion)
geo.admin.ch REST API ch.bafu.trockenheitswarnkarte Official BAFU warning level (Gefahrenstufe 1–5) per region
SwissEO VHI endpoint Vegetation Health Index per region
hydrodaten.admin.ch (BAFU station CSVs) Discharge (Abfluss) per hydro station with low-flow thresholds
data/kantone_warnregionen.json Canton → Warnregion mapping, center coordinates

Running Locally

Docker (recommended):

make build
make up        # → http://localhost:8501

Local (requires uv):

uv run streamlit run app.py
uv run pytest tests/ -v

Team

David Oesch · Joan Sturm · Fabia Huesler · Christopher Boodnee · Lea Stauber · Benjamin Meyer · Luca Huesler · Simon Jaun · Chantal Camenisch

Preview of external content.
👋 Contact ✨ Demo 💻 Source
All attendees, sponsors, partners, volunteers and staff at our hackathon are required to agree with the Hack Code of Conduct. Organisers will enforce this code throughout the event. We expect cooperation from all participants to ensure a safe environment for everybody.

The contents of this website, unless otherwise stated, are licensed under a Creative Commons Attribution 4.0 International License. The application that powers this site is available under the MIT license.

MIT License

Previous
GovTech Hackathon 2026
Next project