RunFlow
RunFlow plant Laufrouten durch Wien mit 72 % weniger Ampeln pro Kilometer – für 7 % mehr Weg.
Datenblatt
| Sachnummer | JS-2026-01 |
|---|---|
| Zeitraum | 01–09/2026 |
| Rolle | Konzept, Bewertung und Tests; Code mit KI-Assistenz |
| Werkzeuge | Python · FastAPI · networkx · OpenStreetMap · Leaflet · Docker |
| Kernergebnis | 3,63 → 1,00 Ampeln pro km (−72 %) bei 7 % mehr Weg; 20 von 20 Testrunden innerhalb ±10 % der Zieldistanz |
| Status | Live-Demo |
1Ergebnis
Zone B
Beispielstrecke A → B: 4 Ampeln auf 2,51 km. Gestrichelt: die Routen bei den anderen Werten.
- Ampeln / km
- 1,00
- Umweg (Median)
- +33 %
Messung: 40 zufällige Strecken (1,5–4 km) in den inneren Bezirken, aktuelles Wegenetz, 05.10.2026. Ein Zielkonflikt wie in der Tourenplanung: Jeder Meter Umweg muss sich durch weniger Wartezeit bezahlt machen.
Live-Demo
2Problem und Motivation
Zone CRote Ampeln brechen den Laufrhythmus, und übliche Lauf-Apps optimieren nur die Distanz. In Wien heißt das: alle paar hundert Meter eine Kreuzung mit Ampel.
3Aufbau
Zone D- 01Kartendaten: OpenStreetMap
- 02Wegenetz: 131 000 Knoten, Meter je Wegtyp
- 03Kostenfunktion: Weg × Faktor + 100 m je AmpelMein Teil
- 04Suche: A*
- 05Rundlauf-Kalibrierung: ±8 %Mein Teil
Die Kostenfunktion ist eine Abwägung wie in der Logistik: Jede Ampel kostet 100 „virtuelle Meter“ (≈ 36 s Warten bei 6:00 min/km). Ruhige Wege zählen 1,0, Gehsteige an Hauptstraßen 1,2, Stiegen 1,5.
Hier steckt die eigentliche Entscheidung: Was ist eine Ampel wert?4Prüfung
Zone EFehlversuch
Die erste Version sah fertig aus und zeichnete plausible Routen. Erst das Nachmessen an 40 Teststrecken zeigte: Durch ein Detail der Bibliothek networkx bekam jede Kante dasselbe Gewicht – der Router zählte Straßenstücke statt Meter und Ampeln. Beim Nachmessen auf dem neu gebauten Wegenetz (Okt. 2026) lagen die Werte deutlich höher: Das alte Netz hatte vermutlich Ampeln beim Vereinfachen verloren, die alten Absolutwerte waren zu optimistisch.
| Kenngröße | Erste Version | Korrigiert |
|---|---|---|
| Ampeln pro km (A → B) | 1,58 | 0,38 |
| Weglänge vs. Luftlinie (Median) | 1,41× | 1,27× |
| Rundläufe innerhalb ±10 % der Zieldistanz | 0 % | 95 % |
| Startzeit / Arbeitsspeicher | 15 s / 1,8 GB | 1,5 s / 0,4 GB |
5Erkenntnis und nächste Iteration
Zone F- Code, der in der Demo funktioniert, kann trotzdem falsch sein. Eine Messung mit Zahlen findet, was ein Blick auf die Karte übersieht.
- Fakten (im Wegenetz gespeichert) und Regeln (beim Start angewendet) trennen: So lässt sich die Gewichtung ändern, ohne Daten neu zu laden.
- Echte Daten sind unordentlich: OpenStreetMap bildet eine Kreuzung mit 2–5 Ampel-Knoten ab, die erst gruppiert werden mussten.
Nächste Iteration
Abbiegeabhängige Ampelstrafe: Wer an einer Ampelkreuzung rechts abbiegt, ohne zu queren, soll nicht bestraft werden. Dafür braucht es einen kantenbasierten Graphen.
Technische Details: Kostenfunktion und Suche
w(u,v) = Σ Länge je Wegtyp × Faktor (+10 % bei Kopfsteinpflaster) + 100 m, wenn v eine neue Ampelkreuzung betritt.
Alle Faktoren ≥ 1, daher unterschätzt die Luftlinie die Restkosten nie: A* liefert die optimale Route für dieses Kostenmodell.
Ampel-Knoten, die durch eine Kante ≤ 30 m verbunden sind, gelten als eine Kreuzung (88 % der Ampel-Knoten haben einen Nachbarn in 30 m).
Technische Details: Rundläufe
Zwei Hilfspunkte bilden mit dem Start ein rechtwinkliges Dreieck. Bereits benutzte Wege kosten das Zehnfache (Brücken das Doppelte), damit der Rückweg anders verläuft; Sackgassen-Stichwege werden entfernt.
Liegt die Länge mehr als 8 % daneben, wird das Dreieck skaliert (max. 5 Versuche). Test auf dem aktuellen Netz: 20 von 20 Rundläufen (5 und 10 km) innerhalb ±10 %, Median-Abweichung 3,8 %.