1Genese & Motivation
2Ausgangssituation
3Daten Reduktion
4Daten Anreicherung
5Daten Zusammenführung
6Masterdatensatz als Resultat
7Limitierungen
Dieses Projekt entstand als Abschlussarbeit einer Data-Science-Fortbildung — der Rahmen war bewusst offen: nicht welches Modell, sondern welches Thema war die große Herausforderung.
Gesucht war ein Thema, an dem sich Data Science nicht abstrakt anfühlt, sondern an einem Alltagsbeispiel mit echtem Impact nachvollziehbar wird.
Daten sollen sinnstiftend eingesetzt werden — mit greifbarem Bezug zum Alltag, zur Lebensqualität, im besten Fall zur Nachhaltigkeit.
Öffentlicher Verkehr trifft das genau: täglich erlebbar, gesellschaftlich relevant, datenreich. Die Recherche führte über den ÖPNV nach Zürich.
Ziel
- Ein einziger, sauberer Master-Datensatz der realen VBZ-Tram-Halte
- Angereichert mit Fahrplan, Wetter, Events und Geografie
Fokus
- Der Weg dorthin: Recherche · Filterung · Zusammenführung · Qualitätssicherung
- Bewusst nicht Modellierung
Einordnung
- Data-Engineering-Grundlage für zh-tram-flow (Analyse & Verspätungsvorhersage)
Warum Zürich Außergewöhnlich gute Open-Data-Landschaft fürs Tramnetz (VBZ) — frei zugänglich, gut dokumentiert, granular genug für echte Analyse.
1
Reduzieren38 GB schweizweit → VBZ Tram Zürich (~400 Betreiber → 1)
2
Richtige WerkzeugePolars statt Pandas — ~4× schneller und sparsamer, per Benchmark belegt
3
Fokus21 → 10 Spalten, ~11 % Zeilen raus — echte Halte plus Ausfälle
Fahrplan (GTFS) · +3 Spalten
Wetter (Meteo) · +7 Spalten
Stadtkreise (Geo) · +2 Spalten
Events · +4 Spalten (von Hand recherchiert)
10 → 26 Spalten — vier gezielt recherchierte Kontextquellen, integriert in den Master-Datensatz.
Vier Quellen → drei Joins → Qualitätsprüfung → vbz_master.parquet.
94,4 M
Halt-Ereignisse
26
Spalten aus 5 Quellen
9
Notebooks, 00–08
100 %
reproduzierbar
vbz_master.parquet — eine Zeile pro Halt (~230 je Fahrt), angereichert mit Fahrplan, Wetter, Events und Stadtkreis. 1:1 reproduzierbar über die 9 Notebooks.
Grenze 1 · Backlog #1
trip_id ↔ GTFS nicht direkt matchbar- IST-FAHRT_BEZEICHNER (85:3849:…) und GTFS-trip_id (1.T0.1-10-…): 0 % Overlap
- Richtungsspezifische Analysen & Kaskadeneffekt bräuchten eine Umlauf-basierte Brücke
Grenze 2 · Backlog #2
UMLAUF_ID beim Reduktions-Schritt verworfen- Wäre die direktere Brücke für Kaskadenanalyse als trip_id-Kontinuität
- Nachträglich = volles Reprocessing ab den Roh-ZIPs
Bewusst dokumentierte Grenzen, nicht übersehene Fehler. Transparenz über Known Issues gehört zu sauberem Data Engineering.
Recherche · Reduktion · Anreicherung · Vereinigung
Master-Datensatz als Data-Engineering-Fundament für das Analyse-Projekt zh-tram-flow