San Francisco CaltrainTownsend at 4th
SQL · Mobility Analytics · Geodata
Urban flow.
Decoded.
Eine explorative Analyse von 336.789 Fahrten, die Stationsnutzung, zeitliche Muster und Kundensegmente im Bike-Sharing-System der Bay Area sichtbar macht.
Analyse erkunden →StatusAbgeschlossenes Datenprojekt
RolleEigenständige Analyse
RepositoryÖffentlich auf GitHub ↗
Verifikation336.789 Fahrten ausgewertet
336.789Fahrten
70Stationen
689Fahrräder
17 minØ Fahrtdauer
Die Fragestellung
Wie bewegt sich eine Region auf zwei Rädern?
Der Datensatz enthält hunderttausende Fahrten zwischen Stationen in San Francisco, San Jose, Mountain View, Palo Alto und Redwood City. Die Aufgabe bestand darin, diese Bewegungen mit SQL und Python zu untersuchen und Muster verständlich darzustellen.
Im Zentrum standen fünf Fragen: Welche Stationen sind besonders stark genutzt? Wann entstehen Nachfragespitzen? Wie unterscheiden sich Städte? Welche Rolle spielen Abonnements? Und welche räumlichen Beziehungen werden auf einer Karte sichtbar?
Interaktive Datenansicht
Nachfrage hat einen Rhythmus.
Wechsle zwischen Stunden, Wochentagen und Städten. Die Darstellung basiert auf den aggregierten Ergebnissen der ursprünglichen SQL-Analyse.
FAHRTEN NACH UHRZEIT
Pendlerverkehr zeichnet zwei klare Spitzen.
Die stärkste Nachfrage entsteht morgens gegen 8 Uhr und am späten Nachmittag gegen 17 Uhr.
42.551Fahrten um 08:00 Uhr – der höchste Stundenwert
Stationen
Caltrain ist der stärkste Mobilitätsknoten.
Die Station an der Townsend Street führt sowohl bei Starts als auch bei Zielen. Das deutet auf eine besonders enge Verbindung zwischen Bike Sharing und regionalem Bahnverkehr hin.
Market at SansomeDowntown
Harry Bridges PlazaFerry Building
Embarcadero at SansomeWaterfront
Starts Ziele
Analyseprozess
Von relationalen Tabellen zur Mobilitätsgeschichte.
Die Fahrten lagen in einer PostgreSQL-Datenbank. SQL-Abfragen aggregierten Stationen, Fahrräder, Dauer, Wochentage, Stunden und Kundentypen. Pandas übernahm die weitere Aufbereitung; Folium verband die Ergebnisse mit Stationskoordinaten.
Die Fallstudie behält die belegbaren Analysewerte bei und übersetzt die damaligen Notebook- und Kartenresultate in eine eigenständige, responsive Webdarstellung.
Filtern, gruppieren und Kennzahlen direkt in PostgreSQL bilden.
Abfrageergebnisse ordnen und für Vergleiche vorbereiten.
Stationskoordinaten und Nutzungswerte geografisch verbinden.
Aus Tabellen klare Aussagen zu Nutzung und Verhalten ableiten.
Kundensegmente
87 % der Fahrten stammen von Abonnenten.
291.890 Subscriber-Fahrten stehen 44.899 Fahrten durch gelegentliche Kunden gegenüber. Zusammen mit den Pendlerpeaks spricht das für eine starke Nutzung im regelmäßigen Alltag.
87%Subscriber
291.890Subscriber
44.899Customer
Was das Projekt zeigt
Analyse endet nicht bei einer Tabelle.
Die Stärke des Projekts liegt in der Verbindung mehrerer Perspektiven: Datenbankabfragen erklären Größenordnungen, zeitliche Aggregationen zeigen Verhalten und Karten geben dem Ergebnis räumlichen Kontext.
Gleichzeitig wurde sichtbar, wie wichtig reproduzierbare Pfade, dokumentierte Datenquellen und konsistente Benennungen sind. Genau diese Erkenntnisse prägen meine späteren Datenprojekte.
Analytische Tiefe
Jede Kennzahl beginnt mit einer präzisen Frage.
Die Analyse übersetzt Bewegungsdaten in mehrere Körnungen: einzelne Fahrt, Stunde, Wochentag, Station, Stadt, Fahrrad und Kundentyp. Erst die Kombination dieser Ebenen macht Nutzungsmuster sichtbar.
Wann entsteht Nachfrage?
Stunden- und Wochentagsgruppen zeigen Pendlerpeaks, ohne einzelne Fahrten als typische Nutzung zu überinterpretieren.
Welche Stationen verbinden Systeme?
Start- und Zielrankings machen Caltrain-Knoten sichtbar und geben Hinweise auf intermodale Wege.
Wer nutzt das Netz regelmäßig?
Subscriber und gelegentliche Kunden werden getrennt aggregiert. Die Daten beschreiben Nutzungstypen, keine individuellen Motive.
Wo konzentriert sich Aktivität?
Stationskoordinaten verbinden SQL-Ergebnisse mit räumlichem Kontext und machen Unterschiede zwischen Teilnetzen lesbar.
Grenzen der Interpretation
Die Daten erklären beobachtete Fahrten, aber weder ausgefallene Nachfrage noch Ursachen wie Wetter, Events oder Stationskapazität. Eine nächste Version würde Datenstand, Query-Versionen und Kontextdaten reproduzierbar dokumentieren.