1Genese & Motivation
2Ausgangssituation
3Daten Reduktion
4Daten Anreicherung
5Daten Zusammenführung
6Masterdatensatz als Resultat
7Limitierungen
8Ausblick
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.
Zürich betreibt eine außergewöhnlich gute Open-Data-Landschaft für sein Tramnetz (VBZ) — frei zugänglich, gut dokumentiert, granular genug für echte Analyse.
Auch die Recherche nach ergänzenden Zürcher Datenquellen (Wetter, Events, Geografie) war vielversprechend. Das war der Startpunkt des Projekts.
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)
Einen Datensatz bauen, mit dem eine sinnvolle, qualitativ belastbare Analyse des Zürcher Tramnetzes überhaupt erst möglich wird.
Der Leitgedanke dahinter: reduzieren was da ist, anreichern was fehlt.
38 GB
komprimierte Archiv-ZIPs
~400
Transportunternehmen CH
5
Verkehrsmittel-Arten
Die IST-Rohdaten beschreiben den gesamten öffentlichen Verkehr der Schweiz — jeder Zug, Bus, jedes Tram, Schiff, jede Seilbahn. Relevant ist ein schmaler Ausschnitt: VBZ Tram Zürich.
| Pandas | Polars | Faktor | |
|---|---|---|---|
| Ladezeit (alle Parquets) | 25,7 s | 6,6 s | ~4× |
| RAM-Verbrauch | 6,1 GB | ~1,4 GB | ~4× |
Entscheidung: Polars für alle großen Operationen (IST, Merge). Pandas bleibt für kleine Quellen (GTFS/Meteo/Events) und als Lernreferenz.
1
Betreiber & Produkt~400 CH-Unternehmen → BETREIBER_ID 85:3849 (VBZ), PRODUKT_ID = Tram
2
Zeitraum & Format2023–2025, nur Format v1 (v2 ab Mitte 2025 ausgeklammert)
3
Messqualitätnur REAL-GPS-Messungen; Durchfahrten & Zusatzfahrten raus
4
Ausfälle behaltenFAELLT_AUS_TF = true bewusst drin — extremster Verspätungsfall
5
Spalten21 Rohfelder → 10 (KEEP_COLS); Delays & stop_sequence abgeleitet
~11 % der Zeilen entfernt — übrig bleiben echte, planmäßige Halte mit GPS-Zeitstempeln, plus alle Ausfälle.
Fahrplan (GTFS)
Wetter (Meteo)
Events
Stadtkreise (Geo)
Ein Tram-Halt mit einer Verspätungszahl erklärt für sich genommen wenig. Erst der Kontext — Fahrplan, Wetter, Events, Geografie — macht Verspätung nachvollziehbar.
Also: vier gezielt recherchierte Zusatzquellen identifizieren und in den Master integrieren.
Fahrplan (GTFS)
Wetter (Meteo)
Events
Stadtkreise (Geo)
Woher
- data.stadt-zuerich.ch · ZIP/TXT · CC0
- 3 Jahrgänge, gesamtes ZVV-Netz
Was zu tun
- Auf VBZ-Tram-Linien filtern, 2024 als Primärreferenz
- 10+ GTFS-Tabellen → 4 Parquets (routes, stops, shapes, trips)
Wie übernommen
- Join über bpuic (Haltestellen-ID) → stop_name, stop_lat, stop_lon
- +3 Spalten im Master
Fahrplan (GTFS)
Wetter (Meteo)
Events
Stadtkreise (Geo)
Woher
- data.stadt-zuerich.ch (UGZ, Wapo, ERZ) · CSV/Parquet · CC0
- 3 Quellen, unterschiedliche Auflösung
Was zu tun
- Auf ein stündliches Raster konsolidieren
- 2 Referenzstationen: Stampfenbachstrasse (Stadtlage) + Mythenquai (Seelage)
Wie übernommen
- floor(1h) als Join-Schlüssel zu den Tram-Zeitstempeln
- +7 Spalten (u.a. temperature, precipitation, wind_speed, flood_intensity)
Fahrplan (GTFS)
Wetter (Meteo)
Events
Stadtkreise (Geo)
Woher
- Keine strukturierte Open-Data-Quelle verfügbar
- Manueller Crawl: Gemini, Perplexity, Transfermarkt
Was zu tun
- Schwellenwert > 1.000 Besucher, Stadt Zürich, 2023–2025
- FCZ/GC-Spiele, Street Parade, Züri Fäscht …
Wie übernommen
- Als CSV aufgebaut, Join über das Datum
- +4 Spalten (event_name, event_type, event_size, event_location)
Fahrplan (GTFS)
Wetter (Meteo)
Events
Stadtkreise (Geo)
Woher
- data.stadt-zuerich.ch · GeoJSON · CC0
- Stadtkreis-Grenzen, sofort verwendbar
Was zu tun
- Jeder Haltestelle ihren Stadtkreis zuordnen
Wie übernommen
- Spatial Join (Punkt-in-Polygon) auf die GTFS-Stops → district_nr, district_name
- +2 Spalten — bereits im Master, kein nachträglicher Join in der EDA nötig
Vier Quellen → drei Joins → Qualitätsprüfung → vbz_master.parquet.
Left Join überall: jede Tram-Fahrt bleibt erhalten. Fehlende Werte (Sensor-Ausfall, Event-freier Tag) werden null — statt die Zeile zu löschen.
Datenverlust durch Join ist der häufigste stille Bug in Merge-Pipelines. Left Join macht ihn unmöglich.
Annahme
Zwei Parquets mit datetime-Spalten joinen einfach
→
Befund
Meteo via pl.from_pandas → datetime[ns], IST nativ datetime[us]. Polars wirft SchemaError beim Join auf den stundengerundeten Schlüssel. Fix: explizit auf pl.Datetime('us') casten.
Annahme
Stündliches Wetter passt direkt zu Tram-Zeitstempeln
→
Befund
Tram-Halte sind sekundengenau, Wetter stündlich. floor(1h) auf beiden Seiten erzeugt den gemeinsamen Join-Schlüssel.
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.
1
Format v2
Ab Ende 2025 wechselt opentransportdata.swiss auf Format v2 (großer VBZ-Fahrplanwechsel Dez 2025) — Integration in einer späteren Iteration.
2
trip_id / UMLAUF_ID-Brücke
Durchgängige Fahrt-Identität herstellen — Voraussetzung für richtungsspezifische und Kaskadenanalysen.
3
Feature-Anreicherung
Weitere abgeleitete Merkmale aus dem Master (z.B. Standzeit/Puffer je Halt) als Modellierungsgrundlage.
4
Reprocessing v2
Das Resultat: ein neu prozessierter Master v2 ab den Roh-ZIPs mit den erweiterten Feldern.
Recherche · Reduktion · Anreicherung · Vereinigung
Master-Datensatz als Data-Engineering-Fundament für das Analyse-Projekt zh-tram-flow