Inhaltsübersicht
Die wichtigsten Technical Insights als Data-Science Deep-Dive
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.
Quelle: Datenpipeline aus dem Schwesterprojekt zh-tram-data.
- 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
| Ansatz | Logik | MAE (Test) |
|---|---|---|
| Grand Mean | Immer Netz-Ø vorhersagen (56,3 s) | 50,6 s |
| Hour Mean | Ø nach Tagesstunde | 50,5 s |
| Line Mean | Ø nach Linie | 50,4 s |
| Stop Mean | Ø nach Haltestelle (stärkste naive Baseline) | 50,0 s |
Stop Mean gewinnt —
weil Haltestellen strukturell unterschiedlich sind.
Grand Mean, Hour Mean und Line Mean liegen alle innerhalb 1 Sekunde beieinander — reine Mittelwert-Strategien nach Zeit oder Linie bringen keinen Vorteil. Erst die Aufschlüsselung nach Haltestelle trifft den strukturellen Unterschied im Delay-Level. Jedes Modell muss diesen Benchmark schlagen.
- hour, weekday, month, season, year
- is_weekend, is_november, is_holiday
- is_late_night_weekend (Kombinations-Feature)
- line_name, stop_name (native categoricals — kein One-Hot)
- district_nr, n_lines_at_stop, n_stops_line
- is_start_stop, is_end_stop, dwell_time
- temperature, precipitation, wind_speed
- has_rain, has_heavy_rain, has_snow, has_flood, is_hot
- has_event, event_type, event_size, event_weight, event_weight_x_hour
- prev_trip_delay: Verspätung des Vorgänger-Trips an diesem Halt — echtzeit-verfügbar
- stop_sequence_pct: normierter Streckenfortschritt (0–1) — linienübergreifend lernbar
- Ergebnis: MAE 45,7 s → 18,56 s, −63 %
| Version | Neue Features | MAE (Test) | MBE (Test) | OTP-Verbesserung |
|---|---|---|---|---|
| Baseline (Stop Mean) | — | 50,0 s | — | — |
| LightGBM v1 | 32 Features (Zeit · Wetter · Netz) | 45,7 s | +8,3 s | 71,9 % → 77,5 % |
| LightGBM v2 | +prev_trip_delay, +stop_sequence_pct (34 total) | 18,56 s | −0,69 s | → kalibriert |
Der Sprung kam aus der Analyse, nicht aus dem Algorithmus.
v1 war systematisch zu optimistisch (MBE +8,3 s), v2 kalibriert auf MBE −0,69 s. Der Sprung auf 18,56 s MAE (−63 %) erklärt sich vollständig durch das neue Feature prev_trip_delay — nicht durch ein besseres Modell.
Eine Workflow-Entscheidung, keine Qualitätskompromittierung.
XGBoost erreicht auf dem Validation-Set vergleichbare Qualität, braucht aber 5× mehr Trainingszeit. Für iteratives Feature Engineering über mehrere Wochen ist LightGBM die klar überlegene Wahl.
Die Kaskadenanalyse (r ≥ 0,85 netzweit) hat die Feature-Wichtigkeit korrekt antizipiert. Das Modell bestätigt: Das Signal steckt in den Daten, nicht im Algorithmus.
- 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
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