hexbike

In Großstädten wird Bike-Sharing immer beliebter und immer mehr Städte integrieren solche Systeme. Eines der bekanntesten Bereitsteller für Bike-Sharing ist nextbike. Zu den deutschen Städten, die nextbike-Systeme integriert haben zählen Mannheim, Leipzig und Köln. Aber auch Städte aus anderen Ländern, wie Großbritannien und die USA verwenden nextbike.

Für dieses Projekt wird die Stadt Köln bezüglich der Fahrradnutzung während der Winterzeit näher untersucht. Dafür werden öffentliche Daten von nextbike und Wetterdaten von Yahoo verwendet und ausgewertet. Die Daten werden zum einen in einem Liniendiagramm angezeigt und zum anderen in einer hexagonalen Karte von Köln. Mithilfe Nutzerinteraktionen lassen sich zusätzliche Informationen zu jeder Stunde einsehen. Das Projekt zeigt, dass die Fahrradnutzung über die Urlaubszeit vom 24.12.2017 bis zum 02.01.2018 stark abnimmt und das Wetter keinen Einfluss auf die Fahrradnutzung hat.

———> Hier geht’s zum Quellcode

Inhalt

1. Motivation
2. Konzept und Hypothese
3. Datenerhebung und Auswertung
   1. nextbike-API
4. Yahoo-API 3. Datenbereinigung 4. Datenbank 5. Ausfälle - Fehlende Daten 6. Prozess
5. Prototyp und Ergebnisse
   1. Visualisierung
   2. Erkenntnisse
   3. Implementierung
6. Fazit
7. Das Team

Motivation

Im Rahmen der Vorlesung Grundlagen der Visualisierung (GDV) an der Hochschule Mannheim, geleitet von Herr Prof. Dr. Nagel, sollten die Studierende im Wintersemester 2017/18 eine interaktive Visualisierung zum Thema “Urbane Ebenen” erstellen. Dafür sollte eine Stadt aus der EU mit über 100.000 Einwohnern ausgewählt werden. Wir entschieden uns für Köln, da Köln viele hochwertige Daten offen zur Verfügung stellt und bei nextbike in Köln die Regel besteht, die Fahrräder nach der Benutzung an einer beliebigen Kreuzung abzustellen. Dies fanden wir interessant und wollten dieses Verhalten näher untersuchen.

Konzept und Hypothese

Dieses Projekt untersucht das Nutzerverhalten von nextbike in Köln während des Zeitraums vom 13.12.2017 bis 13.01.2018. Die Daten dafür wurden in dem genannten Zeitraum von der offenen nextbike-API erhoben. Ziel ist es, anhand der GPS-Daten der verfügbaren Fahrräder herauszufinden, ob die Fahrradnutzung während der Feiertage erkennbar abnimmt. Hierfür wurde die folgende These formuliert:

In der Urlaubszeit zwischen dem 24.12.2017 und dem 02.01.2018 wird das nextbike Angebot weniger genutzt.

Um die Nutzung visuell nachverfolgen zu können, wurde über die Karte von Köln ein Netz aus Hexagonen gelegt. Diese Hexagone repräsentieren echte geographische Bereiche. In jedem Bereich wird die Anzahl der abgestellten Fahrräder gezählt. Befindet sich kein Fahrrad innerhalb eines Hexagons, so behält es die Farbe grau. Ist dies nicht der Fall, so bekommt das Hexagon die Farbe Rot, wobei die Anzahl der Fahrräder die Farbsättigung bestimmt. Je mehr Fahrräder desto kräftiger die rote Farbe. Zusätzlich wird in einem Koordinatensystem unterhalb der Karte die Anzahl der verfügbaren Fahrräder stündlich pro Tag in Form eines roten Graphen dargestellt. Ein zweiter blauer Graph zeigt an, welche Temperatur stündlich pro Tag herrschte. Diese Angaben werden mit einer Datum- und Wetteranzeige neben dem Koordinatensystem ergänzt. Somit wird dem Betrachter ein umfassender Überblick über die Nutzung von nextbike-Fahrrädern während der Winterzeit gewährleistet und es kann erforscht werden, ob die Ab- oder Zunahme der Nutzung von der Temperatur, dem Tag und der Tageszeit abhängt.

Datenerhebung und Auswertung

In diesem Abschnitt wird geschildert, wie die visualisierten Daten beschafft und verarbeitet wurden. Die Daten kommen grundsätzlich aus zwei Quellen: Die Fahrraddaten für Köln wurden von der öffentlichen nextbike API über einen Monat im Zehn-Minuten-Takt gecrawlt. Die gleichzeitig erhobenen Wetterdaten kamen über ein bereits vorhandendes Python Package von Yahoo Wetter.

Zu Beginn war geplant, dass die gecrawlten Daten fortlaufend im Pickle-Format gespeichert und zum Schluss in GeoJson umgewandelt werden. Pickle hat den Vorteil, dass Daten sozusagen einfach dazu geschrieben werden können. Das genutzte Raspberry Pi war allerdings bei einer Dateigröße von bereits knapp über 100 Megabyte überfordert und brach den Schreibvorgang ab. So musste die Pickle-Datei alle zwei Tage in GeoJson umgewandelt und zurück gesetzt werden.

nextbike-API

Die benutzen Fahrraddaten stammen von der nextbike-API. Diese bietet die nextbike-Daten im xml und Json-Format an. Die Entscheidung fiel auf Json, da dieses Format wesentlich kompatibler für dieses Projekt war.

nextbike API Link für Köln im Json-Format: https://api.nextbike.net/maps/nextbike-live.json?city=14

Yahoo-API

Die Wetterdaten wurden über ein Python Package bezogen, welches die Yahoo Wetter API benutzt. Die Daten wurden zeitgleich mit den Fahrraddaten erhoben und besitzen denselben Zeitstempel und können so mit den Fahrraddaten über den Parameter time beziehungsweise timestamp (siehe Fahrraddaten Beispiel) verbunden werden.

Beispiel Json Wetter:

{   
    "humidity": "76",
    "temp": 2.2222222222222223,
    "text": "Mostly Cloudy",
    "time": "2017-12-13 05:30:03.527415",
    "wind": {
        "chill": "30",
        "direction": "155",
        "speed": "14"
    }
}

Datenbereinigung

Um besser mit den Daten arbeiten zu können, wurden die Stationen und die Fahrräder voneinander getrennt. Dazu wurden erst einmal allgemein Fahrräder und Stationen in zwei Gruppen unterteilt. Da sich einige Fahrräder aber auch in Stationen befinden, mussten diese aus den Stationen herausgelesen und zu den übrigen Fahrrädern hinzugefügt werden.

Die Fahrräder, die aus einer Station kommen, haben einen Verweis auf diese über den Parameter stationid. Bei Fahrrädern, welche nicht in einer Station sind ist dieser mit 0 belegt (Wichtig: es gibt keine Station mit der Id 0).

Die Fahrrad- und Stationsdaten wurden bereinigt, indem überflüssige Daten entfernt wurden. Danach wurden sie in das GeoJson Format umgewandelt. Folgend jeweils ein Beispiel für die Fahrraddaten und die Stationsdaten, eine detaillierte Beschreibung aller Parameter befindet sich hier: https://api.nextbike.net/api/documentation/#realtime_locations_as_xml

Beispiel GeoJson Fahrrad:

{
    "geometry": {
        "coordinates": [
            50.9543549,
            6.8909351
        ],
        "type": "Point"
    },
    "properties": {
        "address": "",
        "bike_type": 0,
        "boardcomputer": 7745,
        "maintenance": false,
        "name": "BIKE 21065",
        "number": "21065",
        "state": "ok",
        "stationid": 0,
        "stationiduid": 0,
        "timestamp": "2017-12-13 05:20:03.604815",
        "uid": 379211
    },
    "type": "Feature"
}

Beispiel GeoJson Station:

{
    "geometry": {
        "coordinates": [
            50.9429485,
            6.958015
        ],
        "type": "Point"
    },
    "properties": {
        "bike_numbers": [],
        "bike_racks": 0,
        "bike_types": [],
        "bikes": 0,
        "free_racks": 0,
        "maintenance": false,
        "name": "Hauptbahnhof",
        "number": 4826,
        "rack_locks": false,
        "spot": true,
        "terminal_type": "free",
        "timestamp": "2017-12-13 05:20:03.604815",
        "uid": 35409
    },
    "type": "Feature"
}

Datenbank

Nach dem Aufnahmezeitraum lagen fünfzehn GeoJson-Dateien vor. Diese hatten insgesamt eine Größe von zwei Gigabyte. Um die Daten nicht im Frontend filtern und komplett laden zu müssen und so die Visualisierung unnötig zu verlangsamen, wurden die Daten in eine MySQL-Datenbank übertragen. Über vordefinierte Views kann sich das Frontend erst allgemeine und später detailliertere Daten ziehen. So wird verhindert, dass alle Daten auf einmal ins Frontend geladen werden.

Ausfälle - Fehlende Daten

Aufgrund von Änderungen an der Json-Struktur seitens nextbike, gab es leider einige Ausfälle die dazu führten, dass in bestimmten Zeitintervallen Daten fehlen. In der folgenden Tabelle sind alle fehlenden Zeitintervalle aufgelistet.

Da wir bereits mit Ausfällen seitens des Raspberry Pis’ gerechnet hatten, haben wir Vorkehrungen in Form eines Slackbots getroffen. Um Ausfälle des Pi’s schnell zu erkennen, haben wir nach jedem Durchlauf skriptgesteuert eine Nachricht in einen Slackchannel mit der Anzahl der gescrapten und der gesamten Räder geschrieben. Auf diesem Wege konnten wir fehlerhafte Durchläufe schnell erkennen und das Problem beheben.

Beispiel Nachrichten des Slackbots:

Prozess

Um zu sehen, wie unsere Daten auf einer interaktiven Karte aussehen würden, haben wir anfangs einen ersten einfachen Prototyp mit Leaflet und d3.js erstellt. Diese erste Visualisierung veranlasste uns dazu, einen zeitlichen und räumlichen Vergleich mit den Fahrraddaten zu erstellen, wozu wir einige Scribbles anfertigten. Zu Beginn wollten wir den Vergleich bezirksweise darstellen, doch nach Empfehlung unseres Professors entschieden wir uns dafür, eine hexagonale Karte zu verwenden.

Erster Prototyp:

Scribbles:

Prototyp und Ergebnisse

Visualisierung

Karte

Eine stundengenaue Visualisierung mit der Verteilung der freien nextbikes wurde mit einem Raster aus Hexagonen realisiert, die jeweils einen Kilometer Durchmesser haben. Erste Überlegungen, die neun Kölner Stadtteile als Grundlage zu nutzen, wurden verworfen, da dies viel zu ungenau für ein sichtbares Ergebnis gewesen wäre. Für eine noch bessere Darstellung, könnte der Durchmesser auf einen halben Kilometer reduziert werden. Davon haben wir aus Performance-Gründen abgesehen, da zu viele Hexagone berechnet werden müssten und das Visualisierungserlebnis dadurch getrübt werden würde. Die Hexagone sind entweder leer und grau umrandet, wenn in diesem Bereich kein nextbike verfügbar oder haben eine rötliche Füllung in fünf Abstufungen, die jeweils einen Bereich an verfügbaren nextbikes darstellt. Eine höhere Anzahl an Abstufungen führte dazu, dass kaum noch Unterschiede zwischen den Hexagonen erkennbar waren. Die aktuelle Anzahl an Abstufungen ist eine gute Mischung aus Abgrenzbarkeit und Informationsgewinn. Beim Hovern über ein Hexagon, wird die Anzahl der freien nextbikes im Stile eines Tooltips dargestellt. Die Haupt-Kartenansicht zeigt ganz Köln. Es ist möglich, eine Zoomstufe hinein zu zoomen, falls ein bestimmter Bereich von Interesse ist. Es gibt keine weiteren Zoomstufen außer diesen beiden, da eine noch nähere oder weiter entferntere Ansicht keinen Mehrwert hat.

Graph und Wetteranzeige

Im unteren Bereich der Visualisierung wird ein Graph mit zwei Linien dargestellt. Dieser zeigt den gesamten Zeitraum, in dem Daten erfasst wurden. Die rote Linie stellt die Anzahl der freien nextbikes pro Stunde dar. Die blaue Linie zeigt die Temperatur an. Beim Hovern über die Linien, wird eine senkrechte Orientierungslinie und ein Tooltip angezeigt, der den Zeitstempel, die Anzahl der freien nextbikes und die Temperatur wieder gibt. Weitere Details zu zum Wetter werden rechts vom Graphen dargestellt. Bei einem Klick auf den Graphen, werden die nextbike-Daten in der darüber liegenden Karte auf den ausgewählten Zeitpunkt aktualisiert. Zur Navigation durch den Graphen wurden zusätzlich Buttons integriert, die alternativ auch per Tastatur ausgelöst werden können. Es ist möglich, einzelne Stunden vor und zurück zu skippen, zurück zum Anfang zu springen und die Zeitleiste automatisch weiter laufen zu lassen. Die Darstellung der erhobenen Daten in einem Zehn-Minuten-Takt war viel zu kleingranular. Es wurde entschieden, dass nur die Datensätze zu jeder vollen Stunde dargestellt werden, da die Visualisierung sonst zu unübersichtlich geworden wäre.

Zeitraffer-Animation

Unterhalb der Legende stehen dem Betrachter vier Buttons zur Verfügung mit denen er einen Zeitraffer starten und stoppen kann. Er hat ebenfalls die Möglichkeit eine Stunde nach vorne und eine Stunde nach hinten zu navigieren. Zusätzlich zu den Buttons sind Tastaturanweisungen möglich. Die Tasten dafür sind unter den entsprechenden Buttons abgebildet.

Erkenntnisse

Unsere Hypothese “In der Urlaubszeit zwischen dem 24.12.2017 und dem 02.01.2018 wird das nextbike Angebot weniger genutzt.” wurde bestätigt. Wenn der Bereich vor dem 24.12. und der Bereich vom 24.12 bis zum 02.01. miteinander verglichen wird, so lässt sich erkennen, dass im zweiten Bereich im Durchschnitt viel mehr Fahrräder frei verfügbar sind als im ersten Bereich. Ergo wurden dort weniger Fahrräder genutzt. Auch der Wechselkontrast zwischen Tag und Nacht fällt dort geringer aus. Das Wetter hat auf die Nutzung der Fahrräder keine Auswirkungen gehabt. Abgesehen davon konnten wir beobachten, dass sich die meisten Fahrräder üblicherweise im Zentrum befinden.

Implementierung

Um die verschiedenen Aufgaben der Applikation aufzuteilen wurde die Software in zwei Teilen aufgeteilt: * Frontend für die Visualisierung der Daten * Backend für die Datenbankanbindung und Bereitstellung der Daten

Frontend

Das Frontend ist ausschließlich für die Visualisierung und Darstellung der Daten zuständig. Der Betrachter hat die Möglichkeit mittels Interaktionen mit der Maus und Tastatur zwischen Stunden und Tagen zu wechseln und die Hexagone näher zu inspizieren. Für das Frontend werden drei Frameworks verwendet: * Leaflet * Turf.js * D3.js

Leaflet ist ein JavaScript-Framework für die Einbindung interaktiver Karten in mobile Anwendungen oder Webapplikationen. In diesem Projekt wird Leaflet verwendet, um eine interaktive Karte von Köln einzubinden. Diese Karte kann anhand von Skins in ihrem Aussehen verändert werden.

http://leafletjs.com

Turf.js ist ebenfalls ein JavaScript Framework für die Analyse von Geodaten. Speziell wurde hier hexGrid von Turf verwendet, um das Netz von Hexagonen über Köln zu zeichnen. Der Durchmesser und die Geo-Koordinaten der Hexagone können manipuliert werden. Somit war es möglich, nextbikes mit Geo-Koordinaten den Hexagonen zuzuordnen.

http://turfjs.org/docs/#hexGrid

Für die grundlegenden Funktionalitäten wird das Framework D3.js verwendet. Mit Hilfe von D3.js ist es möglich HTML- oder SVG-Elemente mittels DOM-Manipulationen zu erstellen, zu manipulieren oder zu löschen. In hexbike wird D3.js verwendet, um das Liniendiagramm, die Legende und die Wetteranzeige zu erstellen. Auch die Interaktionen mit der Maus und Tastatur wurden mittels D3.js implementiert.

https://d3js.org

Backend

Im Gegensatz zum Frontend ist das Backend ausschließlich für die Bereitstellung der Daten für das Frontend zuständig. Dafür hat es Zugriff auf eine MySQL-Datenbank in der die Daten gespeichert sind.

Für das Backend wird Node.js in Verbindung mit Express.js verwendet. Dies sorgt für einen leichtgewichtigen Server der schnell die Daten aus der Datenbank abfragen und Daten an das Frontend schicken kann.

https://nodejs.org/en/

https://expressjs.com/

MySQL ist eine relationale Datenbank und wurde zur Ablage der gesammelten Daten verwendet. Um die nextbike-Daten von der MySQL-Datenbank zu erhalten, werden spezielle Queries an die Datenbank gesendet. Sobald über den Graphen ein bestimmter Zeitpunkt ausgewählt wird, wird eine Datenbankabfrage für dieses Datum ausgeführt und die Ergebnisse zurück gegeben. Das Backend ist auch dafür verantwortlich auf Anfragen hin die Daten an das Frontend zu senden.

https://www.mysql.com

Fazit

Das Liniendiagramm zeigt die Wetterdaten und die Anzahl verfügbarer Fahrräder in einem Zeitraum von einem Monat an. Anhand dessen lässt sich unsere Hypothese bestätigen. Die hexagonale Karte bietet zudem eine ansehnliche Übersicht über den Aufenthalt der Fahrräder. Dieser lässt sich im zeitlichen Verlauf durch die Media-Buttons verfolgen. Um genau diese Vergleichbarkeit von einer Stunde zur nächsten anschaulicher zu gestalten, wäre es sinnvoll, die Anzeigegeschwindigkeit technisch zu optimieren. Auch die Karte selbst kann verbessert werden. Sie bietet leider nicht den gewünschten Erkenntnisgewinn. Hier könnte man bei einer möglichen Weiterentwicklung der Visualisierung dem Betrachter anbieten, den Radius der Hexagone dynamisch zu verändern, um entweder die Fahrradinformationen zu abstrahieren oder zu konkretisieren. Ein weiteres mögliches Feature wäre, eine Small-Multiple-View in einer neuen Ansicht zu erstellen, um die interessanten Bereiche (vor und während der Urlaubszeit) direkt gegenüberzustellen, indem das Liniendiagramm für jeden einzelnen Tag aufgeteilt wird. Diese zweite Ansicht mit 30 einzelnen Liniendiagrammen wäre über einen Switch erreichbar. Über diesen Switch könnte man des Weiteren eine dritte Ansicht hinzufügen, in der ganz andere Daten gezeigt werden. Ein Beispiel wäre die Darstellung der zurückgelegten Distanzen der Fahrräder innerhalb eines Tages in einem Balkendiagramm. Hier würden dann ebenfalls alle Tage einzeln abgebildet werden. Zu guter Letzt könnte man die Anzeige der Wetterform in einem hochwertigen Design transparent im Hintergrund einblenden.

Das Team

(Von links nach rechts) Christopher Hansen, Miguel Caballero, Dustin Noah Young, Florian Hrycaj