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.
Benchmark auf dem realen IST-Datensatz (~88 Mio Zeilen), nicht auf Spielzeugdaten
Bei dieser Größe am RAM-Limit (6,1 GB) — keine Lazy Evaluation
Query-Planung + Streaming: scan_parquet('*.parquet') liest ~1.035 Tages-Parquets als einen Datensatz
pl.from_pandas() / df.to_pandas() für den Wechsel zwischen kleinen und großen Operationen
~400 CH-Unternehmen → BETREIBER_ID 85:3849 (VBZ), PRODUKT_ID = Tram
2023–2025, nur Format v1 (v2 ab Mitte 2025 ausgeklammert)
nur REAL-GPS-Messungen; Durchfahrten & Zusatzfahrten raus
FAELLT_AUS_TF = true bewusst drin — extremster Verspätungsfall
21 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.
- data.stadt-zuerich.ch · ZIP/TXT · CC0
- 3 Jahrgänge, gesamtes ZVV-Netz
- Auf VBZ-Tram-Linien filtern, 2024 als Primärreferenz
- 10+ GTFS-Tabellen → 4 Parquets (routes, stops, shapes, trips)
- Join über bpuic (Haltestellen-ID) → stop_name, stop_lat, stop_lon
- +3 Spalten im Master
- data.stadt-zuerich.ch (UGZ, Wapo, ERZ) · CSV/Parquet · CC0
- 3 Quellen, unterschiedliche Auflösung
- Auf ein stündliches Raster konsolidieren
- 2 Referenzstationen: Stampfenbachstrasse (Stadtlage) + Mythenquai (Seelage)
- floor(1h) als Join-Schlüssel zu den Tram-Zeitstempeln
- +7 Spalten (u.a. temperature, precipitation, wind_speed, flood_intensity)
- Keine strukturierte Open-Data-Quelle verfügbar
- Manueller Crawl: Gemini, Perplexity, Transfermarkt
- Schwellenwert > 1.000 Besucher, Stadt Zürich, 2023–2025
- FCZ/GC-Spiele, Street Parade, Züri Fäscht …
- Als CSV aufgebaut, Join über das Datum
- +4 Spalten (event_name, event_type, event_size, event_location)
- data.stadt-zuerich.ch · GeoJSON · CC0
- Stadtkreis-Grenzen, sofort verwendbar
- Jeder Haltestelle ihren Stadtkreis zuordnen
- 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.
vbz_master.parquet — eine Zeile pro Halt (~230 je Fahrt), angereichert mit Fahrplan, Wetter, Events und Stadtkreis. 1:1 reproduzierbar über die 9 Notebooks.
| Quelle | Spalten | Beispiele |
|---|---|---|
| IST (Verkehr) | 10 | operating_date, trip_id, line_name, arrival_delay, canceled, stop_sequence |
| GTFS (Fahrplan) | 3 | stop_name, stop_lat, stop_lon |
| Geo (Stadtkreis) | 2 | district_nr, district_name |
| Meteo (Wetter) | 7 | temperature, precipitation, wind_speed, flood_intensity |
| Events | 4 | event_name, event_type, event_size, event_location |
| Master gesamt | 26 | eine Zeile pro Halt-Ereignis |
26 Spalten, erwartete Typen (date, timestamp[us], float, dictionary …)
94.358.531 Zeilen — deckungsgleich mit dem ursprünglichen Referenz-Datensatz
Left-Join-Nulls plausibel (z.B. event_* an event-freien Tagen)
Voller Lauf 00–08 erzeugt denselben Master — idempotent, resume-fähig
- 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
- 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.
Format v2
Ab Ende 2025 wechselt opentransportdata.swiss auf Format v2 (großer VBZ-Fahrplanwechsel Dez 2025) — Integration in einer späteren Iteration.
trip_id / UMLAUF_ID-Brücke
Durchgängige Fahrt-Identität herstellen — Voraussetzung für richtungsspezifische und Kaskadenanalysen.
Feature-Anreicherung
Weitere abgeleitete Merkmale aus dem Master (z.B. Standzeit/Puffer je Halt) als Modellierungsgrundlage.
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