GPS-Track-Visualisierer
Leitung: | Anders, Elias, Thiemann |
Jahr: | 2017 |
Vortragsseminar
Lukas Schack | Ajax und Web 2.0 |
Jakob Unger | Kartendienst-APIs im Web 2.0 |
Dominik Sander | Freie GPS-Track-Visualisierer |
Motivation
In Zeiten der immer günstiger werdenden GPS-Handgeräte und –Uhren nutzen immer mehr Sportler verschiedenster Disziplinen (Wandern, Segeln, Laufen, Skaten, Fahrrad- und Motorradfahren, Gleitschirmfliegen, Kanu, Bergsteigen etc.) die Möglichkeit, mithilfe des frei verfügbaren GPS-Dienstes ihren zurückgelegten Weg aufzuzeichnen. Die so gewonnenen Tracks können nicht nur in Verbindung mit Luftbildern oder Kartenmaterial zum Nachvollziehen und Dokumentieren der Tour verwendet werden, sondern bieten darüber hinaus vielseitige Möglichkeiten der Analyse. Sportler können sich Größen, wie Geschwindigkeit, Steigung, Höhe, etc. auf Basis der aufgezeichneten Daten berechnen und anzeigen lassen. Dadurch bieten sich GPS-Tracks als modernes Werkzeug zur Trainings- und Leistungsanalyse an.
Ziel
Ziel des Projekts war die Erstellung eines Onlineservice, der beliebige Tracks auf Basis einer interaktiven Karte darstellt und angesprochene Größen berechnet und visuell verdeutlicht. Somit sollte es einem Nutzer möglich sein, von jedem internetfähigen PC seinen Track hochzuladen und analysieren zu lassen. Augenmerk war hierbei besonders auf eine einfache und anschauliche Darstellung des Tracks und seiner Eigenschaften zu legen, um eine bestmögliche Interpretierbarkeit für jeden Benutzer zu ermöglichen.
Das Ganze sollte mithilfe eines bestehenden Kartendienstanbieters umgesetzt werden. Firmen wie Google, Microsoft, Yahoo, etc. stellen im Rahmen ihrer Dienste entsprechende Schnittstellen (sogenannte APIs: Application Programming Interface) zur Verfügung, die sich relativ einfach in eigene Webservices einbinden und für eigene Zwecke modifizieren lassen.
Umsetzung
Anfangs musste festgelegt werden, auf Basis welcher Programmiersprache und welches Kartendienstanbieters das Projekt umgesetzt werden sollte. Als Programmiersprache stellte sich sehr schnell JavaScript (JS) als beste Lösung heraus, da dieses in nahezu jedem Browser und plattformunabhängig implementiert ist. Außerdem sind die Kartendienstanbieter-APIs überwiegend in JavaScript geschrieben beziehungsweise werden darüber angesprochen. Ein weiterer für JS sprechender Aspekt ist die große Verfügbarkeit an Online-Tutorien und Foren mit entsprechender Hilfestellung.
Für die Umsetzung in einer Website mussten wir außerdem HTML (Hypertext Markup Language) einsetzen, in welches der JavaScript-Code eingebettet wurde. Um gegebene GPS-Tracks einzulesen nutzten wir Funktionen zum Auslesen von XML-Daten (Extensible Markup Language), da das GPX-Format (GPS Exchange Format) nach diesem Standard aufgebaut ist.
Bei der Wahl des Kartendienstes schwankten wir längere Zeit zwischen Microsoft Virtual Earth und Google Maps. Beide haben im Vergleich zu den Mitbewerbern wie Yahoo, Maps24 und OpenStreetMaps eine gute Kartenqualität, die unseren Ansprüchen entspricht. Als weiteren Entscheidungspunkt legten wir die Online-Dokumentation zugrunde, die auf den ersten Blick bei Microsoft besser zu sein scheint. Doch auch Google liefert umfangreiche Hilfe und Beispiele – nur weniger aufwändig in Szene gesetzt. Die Entscheidung für Google fiel dann aufgrund der Gelände-Karten-Ansicht. Nur dieser Anbieter liefert eine Karte, die farblich dezent und durch Schummerung mit leichten Höhenlinien Höhenunterschiede gut darstellt. In dieser Ansicht lassen sich die visualisierten Größen eines GPS-Tracks leichter nachvollziehen: Größenänderungen können sofort auf die Gestalt des Geländes zurückgeführt werden. Ein Nachteil des Microsoft Produkts liegt außerdem in der automatischen Interpolation von Punkten bei der Darstellung, wodurch Details des Tracks verloren gehen können und dem Nutzer der tatsächliche Verlauf der Route vorenthalten wird.
Als weiteren Schritt musste festgelegt werden, was aus dem GPX-File extrahiert und analysiert wird und wie diese Daten dann sinnvoll visualisiert werden sollen. Kenngrößen wie Steigung, Geschwindigkeit, Vertikalgeschwindigkeit usw. lassen sich durch Farbe, Dicke, Punktabstand und Ähnliches darstellen. Wir wählten zunächst die Geschwindigkeit, dargestellt durch die Farbwahl aus und planten später weitere Kenngrößen bzw. Visualisierungsarten hinzuzufügen. Für das Beispiel der Geschwindigkeit wählten wir Gelb für mittlere Geschwindigkeiten, rötliche Farbtöne für hohe und ins Blaue gehende für niedrige.
Die Aufbereitung der Daten beinhaltet zunächst das Parsen, also das Auslesen der Daten, aus dem GPX-File sowie ein Resampling und anschließend eine Klassifizierung. Beim sogenannten Resampling werden die meist in unregelmäßigen Abständen vorliegenden GPS-Punkte nach der Zeit oder der Strecke (je nach zu berechnender Größe) mittels Interpolation in ein gleichmäßiges Raster umgerechnet. Es liegt dann also ein Track vor, der beispielsweise alle 5 Sekunden oder alle 10 Meter einen Punkt hat. Im Rahmen der Klassifizierung werden diese Punkte dann in Klassen eingeteilt, anhand derer die Darstellung erfolgt. Detailierter geht die auf der Website verlinkte Programmdokumentation auf diese Schritte ein.
Bewertung
Wie sich schnell herausstellte, war das verfügbare Zeitfenster recht klein, was das Verwerfen vieler Ideen zu Folge hatte. Auch die Verkleinerung der Entwicklergruppe auf zwei Personen machte sich hierbei bemerkbar. Die begonnene Implementierung der Geschwindigkeit, dargestellt durch die Farbe, funktioniert allerdings bei allen Testtracks. Das Ergebnis bei nicht zu langen Tracks erscheint zügig und auch die Farbwahl ist intuitiv verständlich. Die Idee einen Webservice zur Visualisierung von GPS-Tracks zu entwickeln ist also umgesetzt und kann nun um weitere Funktionalitäten erweitert werden.
Ausblick
Alle weiteren Kenngrößen wie beispielsweise die Steigung müssten noch implementiert werden. Hierzu ist nur noch recht wenig Aufwand nötig, da viele Funktionen, die für mehrere Kenngrößen benötigt werden, wie beispielsweise das Berechnen der Varianz, bereits implementiert sind. Auch weitere Darstellungsarten können noch folgen.
Auch in der Implementierung selbst gibt es noch Optimierungspotenzial. Viele Funktionen haben eine Komplexität von O(n²), was bei kurzen Tracks kaum auffällt. Wertet man jedoch längere Tracks aus, kann die API bzw. die JS-Engine der Browser schnell überlastet sein. Das Problem umfangreicher Tracks mit tausenden Punkten wäre ein weiterer Punkt, der Spielraum für Weiterentwicklungen gibt. Hier böte sich eine Vergrößerung der Punktabstände (und damit einer Verkleinerung der Punktmenge) je nach Zoomstufe und eine Beschränkung des Tracks auf den sichtbaren Fensterausschnitt an.
Link: