Reflektionen

Am Anfang des Projekts stand der Wunsch, ein Thema zu bearbeiten, das unsere gemeinsamen Interessen verbindet und gleichzeitig einen klaren Raumbezug hat. Als erste Idee wurde ein Ansatz mit Schneedaten vom WSL-Institut für Schnee- und Lawinenforschung SLF verfolgt, doch bei weiterer Recherche sind wir über den ICON-CH1-EPS Datensatz gestolpert. Da wir beide gerne auf dem Fahrrad unterwegs sind, rückte die Idee einer Routinganwendung schnell in den Vordergrund. Dadurch entstand der Gedanke, diese Daten nicht nur ergänzend anzuzeigen, sondern direkt in die Routenberechnung einzubeziehen.

So stand die Idee einmal. Doch wie setzt man solch ein Projekt um? Der Start war zunächst holprig. Wir mussten abschätzen, welche Technologien sich für unser Vorhaben eignen, wie die verfügbaren Daten aufgebaut sind und welche Anforderungen sich daraus für die Umsetzung ergeben. Viele richtungsweisende Entscheidungen schienen anzustehen, ohne ein fundiertes Wissen darüber zu haben. Dies wirkte zu Beginn fast schon lähmend. Hier half nur Googeln, Dokumentationen zu überfliegen und Examples auszuprobieren, um in möglichst viele Richtungen blicken und die «ceiling height» eines Tools abschätzen zu können. Dies war ein grosses Learning, wenn es einen fast schon überwältigt: sich einen kurzen Überblick über die Tools und Technologien verschaffen und dann auf leichten Füssen eines nach dem anderen durchgehen und ausprobieren. So kann man am ehesten das Potenzial abschätzen. Wenn es nicht klappt, ist das auch eine Information.

Eine erste wichtige Entscheidung betraf die Routingtechnologie. Zu Beginn haben wir PG-Routing als mögliche Grundlage betrachtet, da es im Bereich geodatenbasiertes Routing naheliegend ist. In den ersten Tests zeigte sich jedoch, wie mühselig es ist, OSM-Daten samt Topologie einzulesen. Ebenfalls zeichnete sich ab, dass ein Routing mit dynamischen Kosten nur sehr schwer umzusetzen ist. Hier hat OSMnx in Kombination mit NetworkX überzeugt. Diese Lösung bot uns mehr Flexibilität beim Aufbau, der Bearbeitung und der Analyse des Routinggraphen. Nachdem erste Graphen geladen und einfache Routen berechnet werden konnten, wurde das Projekt technisch greifbarer.

Auch der Bezug und die Verarbeitung der Wetterdaten stellten eine grosse Herausforderung dar. Die MeteoSwiss-Daten mussten zunächst verstanden, heruntergeladen und in ein geeignetes Format überführt werden. Besonders anspruchsvoll war, dass einige Werkzeuge eine Linux-Umgebung voraussetzen. Zusätzlich mussten wir klären, welche Variable für unser Ziel geeignet ist und wie aus den vorhandenen Vorhersagedaten stündliche Niederschlagsinformationen abgeleitet werden können.

Ein zentraler und fachlich besonders spannender Teil des Projekts war die Verknüpfung der Wetterdaten mit den Kanten des Graphen. Der Graph besteht aus zehntausenden von Kanten, welche alle mit der Zelle verschnitten werden müssten, um ihnen die Daten der Wetterzelle zuzuweisen. Hier gäbe es ein grosses Performance-Problem. Durch viel Skizzieren konnte die räumliche Verknüpfung durch eine attributive ersetzt werden, was am Ende den gleichen Effekt hat, nur performanter.

Währenddem die Routinglogik erarbeitet wurde, wurde auch die Vorprozessierung und das Frontend umgesetzt. Der Einsatz von KI-Werkzeugen war dabei eine grosse Unterstützung. Die grössere Herausforderung lag weniger darin, eine Webseite aufzubauen, sondern ein möglichst schlichtes, verständliches und funktionales Layout zu gestalten. Besonders das Rendern des Regens war anspruchsvoll, da hier sowohl die räumliche als auch die zeitliche Komponente beachtet werden musste.

Eine weitere Herausforderung bestand darin, Frontend, API und Routinglogik sauber miteinander zu verbinden. Nachdem die einzelnen Komponenten in sich funktionierten, mussten die Schnittstellen definiert und die Abläufe zusammengeführt werden. Dabei half es, den gesamten Prozess zuerst als Dummy aufzubauen. So konnten die einzelnen Puzzleteile wie Routinggraph, Wetterdaten, API-Call, Routenberechnung und Visualisierung Schritt für Schritt eingesetzt werden. Diese Vorgehensweise machte sichtbar, wo noch die z.B. die Datenvorprozessierung der Meteodaten angepasst oder Funktionen ergänzt werden mussten.

Auch die Dokumentation war aufwändiger als erwartet. Eine Schwierigkeit bestand darin, die Dokumentation so aufzubauen, dass sie vollständig ist, aber keine unnötigen Wiederholungen enthält. KI war auch hier hilfreich, um Abläufe aus dem Code in verständliche Texte zu übertragen und erste Formulierungen zu erarbeiten. Trotzdem zeigte sich, dass der Feinschliff, die Kontrolle der Inhalte und eine konsistente Struktur viel Zeit benötigen.

Insgesamt sind wir mit dem Projekt zufrieden. Der entwickelte Prototyp zeigt, dass Wetterdaten grundsätzlich in eine Routingentscheidung integriert werden können und dass dadurch neue, praxisnahe Fragestellungen entstehen. Gleichzeitig wurden auch Grenzen sichtbar. Dazu gehören unter anderem die räumliche und zeitliche Auflösung der Wetterdaten. Auch ist je nach Regenkonstellation ein wetterbasiertes Routing nur bedingt hilfreich. Für eine produktive Anwendung wären weitere Optimierungen, zusätzliche Wetterparameter und eine stabilere Datenverarbeitung notwendig.

Das Projekt war für uns sehr lehrreich. Wir konnten Erfahrungen mit Routinggraphen, Wetterdaten, APIs und Frontend-Entwicklung sammeln. Besonders wertvoll war die Erkenntnis, dass komplexe Geodatenanwendungen am besten schrittweise entwickelt werden: zuerst mit einfachen Tests, danach mit klaren Skizzen der Abläufe und erst anschliessend mit der Zusammenführung der einzelnen Komponenten. Viele dieser Erfahrungen können wir in zukünftigen Projekten wiederverwenden.