Die Verspätungen im Zürcher Tramnetz sind vorhersagbar — weil sie im Fahrplan-Design verankert sind, nicht im zufälligen Betrieb.
Was vorhersagbar ist, ist steuerbar. Das Modell bestätigt die Analyse: prev_trip_delay ist das stärkste neue Feature in v2, MAE sinkt von 45,7 s auf 18,56 s. Fahrplan-Redesign an L11 ist der Hebel.
Inhaltsübersicht
Der gesamte Daten-Lifecycle von Rohdaten bis Vorhersage-Modell
Analyse
Identifikation der Entstehungsmuster und Einflussfaktoren. Analyse in 6 Dimensionen: Temporal · Räumlich · Netzwerk · Meteorologie · Events · Zieldefinition.
Vorhersage
Machine-Learning Modelling für die Verspätungsvorhersage. Folgen sie Mustern, die ein Modell lernen kann? — LightGBM, MAE 18,56 s (arrival_delay in Sekunden), −63 % vs. Baseline.
Ø Ankunftsverspätung pro Haltestelle. Hotspots ausschliesslich in peripheren Stadtkreisen 7, 11, 12.
- Feiertage sind der beste Tagestyp: −9,9 s vs. Normal
- Der Rückgang des motorisierten Individualverkehrs (MIV) an Feiertagen überwiegt jeden Event-Effekt
- Event-Wirkung ist ein Abend-Phänomen (18–22h): tagsüber kein messbarer Unterschied
- Reale Ankunfts- und Abfahrtszeiten aller Tramhalte 2023–2025
- Granularität: Fahrt × Haltestelle × Timestamp
- Enthält canceled = True Fahrten — bewusst behalten (relevante Extremfälle)
- Geplante Ankunfts-/Abfahrtszeiten, dwell_time, stop_sequence
- Liniengeometrien und Haltestellen-Koordinaten (lat/lon)
- Join-Key: trip_id × stop_id × service_date
Master-Datensatz
Der Master-Datensatz entsteht in zh-tram-data aus den VBZ IST-Daten, angereichert um GTFS, Meteo Schweiz und Event-Kalender — 94,4 Mio. Zeilen, 26 Features. Er liefert die Basis für alle Analysen in diesem Projekt.
GTFS (Fahrplandaten)
Für Karten, Geo-Visualisierungen und Tramlinien-Darstellungen wurde GTFS zusätzlich gesondert geladen — der Master-Datensatz allein liefert keine Liniengeometrien und Streckenverläufe.
- Stündliche Messwerte: Temperatur, Niederschlag, Windgeschwindigkeit
- Join über Zeitstempel (hour-level) auf IST-Daten
- Abgeleitete Flags: has_rain, has_snow, has_heavy_rain, is_hot
- Grossveranstaltungen Zürich 2023–2025: Konzerte, Messen, Sport
- Kategorisierung: event_type, event_size, event_weight
- Ergebnis: 94,4 Mio. Zeilen · 26 Features · 541 MB Parquet
- Linientopologie: 16 Linien, ca. 190 Haltestellen
- Kontext-Features: n_lines_at_stop, n_stops_line
- Basis für linienübergreifendes Lernen (stop_sequence_pct)
- arrival_delay in Sekunden, aus IST- vs. Soll-Zeit berechnet
- OTP-Schwellwert: Ankunft ≤ 2 Minuten Verspätung
- canceled = True bewusst als Extremfall im Target erhalten
Was an einem Halt beginnt, endet nicht dort:
Ohne Standzeit-Puffer überträgt sich jede Verspätung strukturell auf die Folgefahrt — messbar auf allen 16 Linien, am stärksten auf L11.
Anomalie
Hotspots an Endstationen, nicht an zentralen Knotenpunkten. Null Überschneidung mit den dichtest bedienten Haltestellen.
Gradient
Der Delay wächst entlang der Strecke. L11: Verspätung am Streckenende doppelt so hoch wie am Anfang.
Mechanismus
71,3 % aller Haltestellen haben 0 Sekunden eingeplante Standzeit. Kein Puffer, keine Erholung möglich.
Kaskade
Pearson r ≥ 0,85 zwischen aufeinanderfolgenden Halts auf allen 16 Linien. Systematisch, kein Einzelfall.
Es ist ein Fahrplan-Design-Thema.
Was im Fahrplan nicht vorgesehen ist, kann im Betrieb nicht ausgeglichen werden.
Wetter & Events
Zwei externe Einflussfaktoren sind messbar und erheblich: Schnee (+54 s) und Grossevents (bis +66 s bei Fachmessen). Doch das Grundniveau der Verspätung bleibt auch bei optimalen Bedingungen konstant hoch. Externe Faktoren verstärken, was intern bereits strukturell angelegt ist.
Betriebsbedingte Faktoren
Trotz Bauphasen, Streckensperrungen und Fahrplanumstellungen hält die VBZ das System bemerkenswert stabil. Die Verspätungslevel schwanken durch diese Eingriffe kaum. Die Ursache liegt nicht in externen Störungen, sondern im Fahrplan-Design selbst.
Die Struktur der Daten ist nicht linear.
Linie × Haltestelle × Tageszeit × Wetter × Event interagieren auf eine Weise, die kein handcodiertes Modell erfassen kann — und prev_trip_delay liefert ein Echtzeit-Signal für einen Feedback-Loop im Modell.
| Ansatz | Features | MAE (Test) | Verbesserung |
|---|---|---|---|
| Baseline (Stop Mean) | — | 50,0 s | Ausgangspunkt |
| LightGBM v1 — Zeit · Wetter · Netz-Features · kein Live-Signal · MBE +8,3 s | 32 | 45,7 s | −4,3 s |
| LightGBM v2 — +prev_trip_delay · +stop_sequence_pct · Isotonic-Kalibrierung · MBE −0,69 s | 34 | 18,56 s | −31,4 s (−63 %) |
Feature Engineering schlägt Hyperparameter-Tuning.
Der Sprung von v1 auf v2 kam nicht durch einen besseren Algorithmus. Das richtige Signal aus der Analyse wurde mit dem Kaskadenindikator (prev_trip_delay) sichtbar gemacht.
18,56 Sekunden bestätigen die Analyse.
prev_trip_delay erklärt den Sprung von 45,7 s auf 18,56 s MAE. Das Signal war in den Daten — die EDA hat es zuerst aufgezeigt, das Modell hat es bestätigt.
Die Kaskadenanalyse (r ≥ 0,85) hat die Feature-Wichtigkeit korrekt antizipiert — das Signal steckt in den Daten, nicht im Algorithmus.
Das Modell kombiniert Tageszeit, Linie, Haltestelle, Wetterlage und den Verspätungsstatus des Vorgänger-Trips zu einer konkreten Sekundenvorhersage. So lassen sich kritische Situationen identifizieren, bevor die Kaskade einsetzt.
- dwell_time = 0 s an 71,3 % aller Haltestellen ist das Root-Cause-Feature
- +10 s Puffer an 3–5 kritischen Koppelstellen unterbricht den Kaskadeneffekt
- prev_trip_delay ist das stärkste Feature — und in Echtzeit aus VBZ-System verfügbar
- MAE 18,56 s auf Test 2025: Produktionsreife bereits nachgewiesen
- Peak 21h: 67,9 s — nicht der Morgen (7h: 48,9 s unter Netzschnitt)
- Spitzenlastmomente sind kalendarisch planbar
- Kreis 11: OTP 83 %, Ø 68,3 s — strukturell benachteiligt, nicht situativ
- district_nr gehört zu den Top-Features im Modell
- VBZ IST-Daten · GTFS · Meteo Schweiz · Event-Kalender
- 94,4 Mio. Zeilen · 26 Features · 541 MB Parquet
- 3 vollständige Betriebsjahre · 16 Linien · ca. 190 Haltestellen
- 66 dokumentierte Befunde in 12 Jupyter-Notebooks
- Python · Polars (85 Mio. Zeilen, lazy evaluation) · Jupyter · uv
- LightGBM (Modellierung) · Plotly (Visualisierung) · Streamlit (Dashboard)
- Trainingszeit LightGBM v2: ca. 18 Minuten auf Consumer-Hardware
- Claude Code für iterative Analyse, Code-Refactoring, Dokumentation
- Promptbasiertes Scaffolding: von der Idee zur Notebook-Struktur in Minuten
- Menschliche Entscheidungsverantwortung bleibt bei allen Finding-Interpretationen
- Vollständiger Code auf GitHub, alle Datenquellen öffentlich
- Data Engineering vollständig reproduzierbar via Polars-Pipeline
- Alle Befunde rückverfolgbar auf Finding-IDs in den Notebooks
Warum sind Fahrtrichtungen asymmetrisch?
Welche Linien dämpfen Delays, welche verstärken sie?
Beim interaktiven Erkunden der 16 Linien entstehen neue Fragen. Diese Ad-hoc-Entdeckungen sind Signale für strukturelle Potenziale und wurden bereits in 7 Opportunities formuliert.
3 von 7 der Opportunities
- Direction-Asymmetrie (~10 s Delta zwischen Richtung A/B)
- Stop-Variabilität (Puffer-Stops vs. zeitkritische Stops)
- Kaskaden-Verstärker vs. -Dämpfer pro Linie
Was vorhersagbar ist, ist steuerbar.
Dieses Projekt zeigt: Datenanalyse ist kein akademisches Artefakt, sondern das Fundament für operative Entscheidungen. Das interaktive Dashboard macht diese Erkenntnisse direkt steuerbar — Szenarien lassen sich simulieren, um Entscheidungen fundiert zu begründen.
Linien erkunden · Linien vergleichen · Verspätungen vorhersagen