Crawlen von GPX Dateien aus Sportstrecken ... - Userpage

Projektdokumentation
Crawlen von GPX Dateien aus Sportstrecken
Michael Klingen, Carsten Dreßke
klingenm@fu-berlin.de, carsten.dresske@fu-berlin.de
Betreuer: Sebastian Müller
Berlin, 12. September 2013

Zusammenfassung
Ziel dieses Projektseminars war die Entwicklung und Implementierung
eines Programms zum automatisierten Sammeln von GPS-
Strecken. Hierzu mussten geeignete Onlinedatenquellen gesucht werden,
deren Funktionsweise ein Crawlen zulässt. Im Projektverlauf stellte
es sich als sinnvoll dar, zielgerichtet, nach Fortbewegungsarten selektiert,
Streckendaten zu sammeln, was einer Klassifikation und späteren
Analyse und Auswertung entgegenkommen sollte.
Nachdem eine Auswahl an geeigneten Quellen in die Implementierung
eingebunden worden sind, wurden geeignete Testfälle generiert, die
beispielhaft die Verwendung des Crawlers im Zusammenspiel mit den
einzelnen Onlinequellen zeigen sollten. Dadurch konnte die Funktionsweise
des Crawlers erprobt werden. Das Projekt endete mit einer
Kurzpräsentation in der AG Datenbanken und Informationssysteme.
Eine Ausführung möglicher Erweiterung, welche diskutiert wurden, ist
ebenfalls Bestandteil dieser Projektdokumentation.
Abstract
The development and implementation of an automated crawling
program for GPS sportstracks was one main objective during this
course. Therefore it was necessary to identify suitable online-sources
which allow automated crawling. In the implementation phase of
project a structured classification by movement modes of the data due
to further analyzing purposes became more important. After selecting
and implementing applicable crawling sources test cases were created
a demonstration of the implementation and to illustrate the usage of
the program. The project ended with a presentation in front of the
databases workgroup. In the end this document gives a brief overview
for future extension possibilities.

Inhaltsverzeichnis
1 Aufgabenstellung 1
2 Motivation 1
3 Verwandte Arbeiten 1
4 Projektaufbau 2
5 Probleme 3
6 Datenquellen 3
6.1 Strava . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.2 GPSies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.3 OpenStreetMap . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.4 MapMyTracks . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7 technische Grundlagen 5
8 Austauschformate 5
8.1 GPX - GPS Exchange Format . . . . . . . . . . . . . . . . . . 5
8.2 CSV - Comma-separated values . . . . . . . . . . . . . . . . . 6
9 Implementierung 7
10 Testszenarios 7
11 Bewertung des Projektverlaufs 10
12 Zusammenfassung 10
13 Ausblick und mögliche Erweiterungen 10

1 Aufgabenstellung Klingen, Dreßke
Einleitung Dieses Projekt wurde im Rahmen des Seminars Datenverwaltung
im Sommersemester 2013 an der Freien Universität in der Arbeitsgruppe
Datenbanken und Informationssysteme angefertigt.
1 Aufgabenstellung
Im Projektverlauf wurde folgende Projektzielsetzung erarbeitet. Ziel des
Projekts war das automatische Crawlen von Jogging- oder Rennradstrecken
aus sozialen Netzwerken oder vergleichbaren Onlinediensten und deren
Transformation in das GPX Format. Es sollten gängige Dienste unterstützt
werden. Das Crawlen sollte eingeschränkt auf den eigenen Account unter
Berücksichtigung der entsprechenden Policy funktionieren. [Mü]
2 Motivation
Im Gegensatz zu automatisch generierten GPS-Spuren stellen reale Daten
eine praxisnahe Grundlage für weiterführende Auswertung dar. Dabei
müssen ebenso das Fehlverhalten von Nutzern, die beispielsweise unzutreffende
oder irreführende Klassifikationen vornehmen, wie auch die Unschärfe
der GPS-Positionsbestimmung mittels handelsüblicher GPS-Empfängern
durch Auswertungsalgorithmen kompensierbar sein. Darüber hinaus werden
in der Praxis keine festen Frequenzen zur Aufzeichnung der Positionen verwendet,
was wiederum keine negativen Einflüsse auf die Modellierung haben
sollte.
3 Verwandte Arbeiten
Ein großer Datenbestand an klassifizierten Streckendaten ist für bereits
durchgeführte Projekte des Seminars eine wichtige Datenquelle, um die Güte
der Algorithmen zu verifizieren oder bestehende Klassifizierungsmodell zu
verfeinern. Eine Anwendung ist beispielsweise die automatisierte Erkennung
des Bewegungsmodus anhand von GPS-Spuren. [MK]
1

4 Projektaufbau Klingen, Dreßke
4 Projektaufbau
Im folgenden werden die einzelnen Bearbeitungsphasen des Projektes kurz
dargestellt. Neben den Inhalten sind auch die zeitlichen Umfänge aufgeführt.
06.04.2013 Projektstart
Aufgabenname Beschreibung zeitlicher Umfang
Analyse Anforderungen werden definiert. 12 Stunden
Es werden Verfügbarkeit von
getaggten (Fahr-)Spuren im Internet
überprüft und mögliche
Bezugsquellen lokalisiert.
Proof of Concept Eine Demoapplikation wird entworfen
16 Stunden
die (Fahr-)Spuren aus ver-
schiedenen Quellen laden und abspeichern
kann.
07.05.2013 Meilenstein 1
Aufgabenname Beschreibung zeitlicher Umfang
Design
Die Architektur des Crawlers wird 12 Stunden
mittels Klassen- und Sequenzdiagrammen
geplant.
21.05.2013 Meilenstein 2
Aufgabenname Beschreibung zeitlicher Umfang
Implementierung Die geplante Funktionalität wird 60 Stunden
implementiert und getestet.
12.06.2013 Präsentation
Aufgabenname Beschreibung zeitlicher Umfang
Vorstellung der In einer Abschlusspräsentation vor 30 Minuten
Ergebnisse
der Arbeitsgruppe wird der Projektverlauf
reflektiert und die Funktionalität
des Crawlers vorgeführt.
Übergabe der Dokumentation
Tabelle 1: Meilensteine
2

5 Probleme Klingen, Dreßke
5 Probleme
Bei der Analyse der Aufgabenstellung ließen sich folgende Teilfragestellungen
ableiten.
Was sind die Anforderungen?
In Rücksprache wurden folgenden Anforderungen ermittelt und festgehalten.
funktionale Anforderungen
• (Fahr-)Spuren sollen aus Onlinequellen gecrawled werden.
• Die Nutzung des Crawlers soll konsolenbasiert unter der Verwendung
eine Reihe von definierten Parametern möglich sein.
• Die gecrawlten (Fahr-)Spuren sollen lokal gespeichert werden.
• Der Zielordner zum Speichern der (Fahr-)Spuren kann vom Benutzer
frei gewählt werden. Der Pfad, in dem das Programm liegt ist der
Standardausgabepfad.
• Das Zielformat zum Speichern der (Fahr-)Spuren kann vom Benutzer
gewählt werden. Folgende Formate werden angeboten: GPX, CSV.
GPX ist der Standardausgabetyp.
nicht funktionale Anforderungen
• GPL v2 Lizenzen dürfen nicht verwendet werden.
Welche Art von Quellen sind brauchbar?
Die Datenquellen sollten nach Möglichkeit eine breite Datenbasis mit verschiedenen
Bewegungsmodi darstellen. Eine Abfrage sollte über eine Web-
API durchgeführt werden können.
Wie werden Daten aus diesen Quellen abgerufen?
Üblicherweise werden Anfrage an RESTful APIs per http-Requests gestellt.
6 Datenquellen
Dieser Abschnitt soll die Datenquellen, welche als geeignet identifiziert wurden
kurz beschreiben. Die Verfügbarkeit einer API war dabei das primäre
Auswahlkriterium. Der Datenbestand in allen ausgewählten Quellen wird
von öffentlichen Nutzern generiert und bereitgestellt.
3

6.1 Strava Klingen, Dreßke
6.1 Strava
Ausgehend von einer breit angelegten Suche nach geeigneten Datenquellen
wurde zunächst die Lauf- und Radfahrcommunity Strava 1 für geeignet befunden.
Hier findet ein weltweiter Austausch von Streckendaten zwischen aktiven
Sportlern statt. Die Plattform besitzt eine API, welche in früheren Versionen
Entwicklern von externen Applikationen frei zur Verfügung gestellt
wurde. Jedoch wurde innerhalb der Projektlaufzeit eine Versionsumstellung
an der API vorgenommen, so dass eine Nutzung nur nach vorheriger Registrierung
und anschließender Zuteilung eines Developer API-Keys möglich
ist. Diese wurde durchgeführt, jedoch bleib eine Reaktion der Plattformbetreiber
aus, was dazu führte, dass ein Test dieser Quelle im Crawler nicht
umgesetzt werden konnte.
6.2 GPSies
GPSies 2 ist eine Plattform zum Austausch von Streckendaten für verschiedenste
Freizeitaktivitäten. Es bietet einen umfangreichen Datenbestand, welcher
zum Teil mit aussagekräftigen Tags versehen ist. Nach Rücksprache mit dem
Betreiber der Plattform war es möglich, einen API-Key zur Anbindung der
Datenquelle an den zu entwickeldenden Crawler zu erhalten. Dabei wurde
darauf hingewiesen, dass zur Zeit nur limitierte Serverressourcen verfügbar
sein. Eine exzessive Nutzung des Dienstes wird daher vom Betreiber ausgeschlossen
und führt zur Sperrung des API-Keys. Mit einer Anfrage können
jedoch bis zu 100 GPX-Tracks zurückerhalten werden. Als Parameter werden
dabei eine BoundingBox und ein Streckentyp (Bewegungsmodus) verwendet,
was im Hinblick zur späteren Auswertung und Analyse einen Vorteil
gegenüber den anderen Quellen darstellt.
6.3 OpenStreetMap
Das OpenStreetMap 3 Projekt bietet neben weltweitem Kartenmaterial auch
die Möglichkeit zum Austausch von Streckendaten innerhalb der Karten. Es
handelt sich hierbei ebenfalls um eine sehr umfangreiche Quelle, die über
eine API angesprochen werden kann.
Ähnlich der Arbeitsweise von GPSies wird ebenfalls mit einer BoundingBox
zur Eingrenzung des Suchbereiches gearbeitet. Im Gegensatz zu GPSies werden
die Strecken nicht im GPX-Format zurückgegeben und müssen daher
geparsed und aufbereitet werden.
1 www.strava.com
2 www.gpsies.com
3 www.openstreetmap.org
4

6.4 MapMyTracks Klingen, Dreßke
6.4 MapMyTracks
Diese Quelle 4 ist wiederum eine Community von Rad- und Laufathleten,
die zur gegenseitigen Motivation und zum Erfahrungsaustausch aktuelles
Trainingsstreckenmaterial austauschen. Der Dienst bietet eine API. Jedoch
unterscheidet sich der Abruf von Daten grundlegend von GPSies und Open-
StreetMap. Es ist hier nur möglich auf die Strecken von anderen Nutzern
der Community zuzugreifen.
Zu diesem Zweck wird ein “Freundesnetzwerk” unter den Nutzern aufgebaut.
Um nun die Daten der Community zu sammeln, ist ein aktiver Nutzer-
Login notwendig. Testweise wurde ein Login samt personalisierter Authentifizierung
angelegt, der mit aktiven Nutzern Freundesverknüpfungen hergestellt
hat. Man spricht dabei von “Followern” anderer Nutzer, die die
Aktivitäten eines Nutzer einsehen können. Auf die Daten anderer Nutzer
konnten somit erfolgreich zugegriffen werden. Ein rekursives Durchsuchen
des Netzwerks ist denkbar.
7 technische Grundlagen
Die Daten werden von den diversen Anbietern über so genannten RESTful
Webservices zur Verfügung gestellt. Die Kommunikation mit den einzelnen
Webservices erfolgt mittels HTTP-Requests sowie HTTP-Responses.
Die Strava API 5 , die GPSies API 6 , die OpenStreetMap API 7 und die
MapMyTracks API 8 definieren alle erforderlichen Komponenten für eine
erfolgreiche Kommunikation mit dem entsprechenden Dienst. Auch die Interpretation
der erhalten Antwort wird dort eingehend beschrieben.
8 Austauschformate
Durch den Auftragssteller des Projekts wurden die Formate zur Persistierung
und zum Austausch benannt und Falle des eigenen CSV-Formats definiert.
8.1 GPX - GPS Exchange Format
Zur Persistierung und zur Standardisierung beim Austausch von GPS-Spuren
wurde auf ein weit verbreitetes Format zurückgegriffen. Das GPX-Format ist
ein in XML formuliertes Austauschformat bei dem zusätzlich zu den GPS-
Punkten weitere Metainformationen hinterlegt werden können. Dabei gibt
es verschiedene Erweiterungen des Standards. Die bekannteste wurde durch
4 www.mapmytracks.com
5 http://strava.github.io/api/v3/
6 www.gpsies.com/api/GPSiesAPI.pdf
7 www.openstreetmap.org
8 http://www.mapmytracks.com/about
5

8.2 CSV - Comma-separated values Klingen, Dreßke
den GPS-Gerätehersteller Garmin [Gar] eingeführt.
Im folgenden ist ein kurzes Minimalbeispiel einer GPX-Datei gegeben. Dabei
wird am Track (trk) die Metainformation des Namens durch den entsprechenden
Tag hinterlegt. GPS-Spuren können aus verschiedenen Segmenten bestehen,
die wiederum ausgewählten einzelnen GPS-Punkten bestehen. Zur weiteren
Auswertung ist es notwendig, dass der Aufnahmezeitpunkt des GPS-
Punktes vermerkt wird, was einen Rückschluss auf die Bewegungsgeschwindigkeit
zulässt. Im Beispiel Beispiel wurde zusätzlich die Höhe ü.N.N. erfasst.
Alfeld -Sack - Wehrstedt on GPSies .com
141.0
2010 -01 -01 T24 :00:00Z
130.0
2010 -01 -01 T24 :00:47Z
Listing 1: GPX-Beispiel Listing
8.2 CSV - Comma-separated values
Das Projekt soll als Datenquelle für das in der Vergangenheit im Rahmen
des in der Vergangenheit erstellten Agg2Graph Frameworks dienen. Darin
wurde ein CSV-Format definiert, was im folgenden kurz benannt werden
soll. Die Ausgabe des Crawlers entspricht dieser Struktur.
Type ,
Segment ,
Punkt ,
Breitengrad ( Grad ),
L n g e n g r a d ( Grad ),
H h e (m),
Peilung ( Grad ),
Genauigkeit (m),
Geschwindigkeit (m/s),
Zeit ,
6

9 Implementierung Klingen, Dreßke
Leistung ( Watt ),
Trittfrequenz ( Umdrehungen pro Minute ),
Herzfrequenz ( S c h l g e pro Minute ),
Akkustatus
Listing 2: CSV-Beispiel Listing
9 Implementierung
Die Aufgabe wurde als eine AllInOne-Lösung in Java entwickelt. Java bereitete
die Möglichkeit bereitet neben der konsolenbasierten Eingabe auch die
Logik in einfacher Form umzusetzen. Als Entwicklungsplattform wurde Netbeans
sowie zur Vereinfachung der Logik die Plugins Apache Commons CLI,
Selenium, Apache Commons Compress.
Apache Commons CLI ermöglicht auf einfach Art und Weise eine Verwendung
der über die Konsole eingegebenen Parametern. Da dies für ein konsolenbasiertes
Programm unabdingbar ist wurde hier auf die fertige Bibliothek
zurückgegriffen.
Selenium ist eigentlich als Webtesting Framework gedacht, was ein automatisiertes
Testen einer Webpage ermöglichen soll. Der Ansatz, bzw. die Fähigkeit
sich frei auf einer Webseite zu bewegen und mit ihr in jeder erdenklichen
Form zu interagieren wurde genutzt um benötigte Informationen der Datenquellen
auf ihren Webseiten in Erfahrung zu bringen.
Apache Commons Compress ist eine Sammlung gängiger Kompressionsverfahren.
Da die zu crawlenden Dateien rein textbasiert sind und ein gewisser
Teil redundant ist lassen sich die Spuren wunderbar komprimieren und somit
Speicherplatz, Performance und Trac sparen. Einigen Anbieter verteilten
die angefragten Spuren in komprimierter, welche mittels dieser Bibliothek
wieder entpackt wurden.
10 Testszenarios
Im folgenden sollen die mit dem Crawler durchgeführten Funktionstests
näher erläutert werden. Dabei wurden für jede angebundene Datenquelle
zwei Queries erprobt, die sowohl den Export im GPX- als auch im CSV-
Format demonstrieren sollen. Ebenso wurden die Möglichkeiten zur Klassifikation
der Bewegungsart anhand von Tags berücksichtigt.
7

10 Testszenarios Klingen, Dreßke
Datenquelle 1 - GPSies
Der nachfolgende Aufruf des Crawlers demonstriert die Arbeitsweise des
Crawlers für die Datenquelle GPSies. Zur Nutzung ist ein gültiger API-Key
zwingend notwendig (Parameter k).
java -jar GPXCrawler.jar -d 1 -k jpjqggfbhtyyrxyr
-b 10.0,51.0,11.2,52.3 -r dl/gpsies -t jogging
Hierbei werden in einer definierten Boundingbox (Parameter b) alle Tracks
des Typs jogging gesucht und im Anschluss in das Verzeichnis “dl/gpsies”
abgelegt. Darin wird automatisch ein Unterordner jogging angelegt, was die
weiterführende Analyse und Auswertung der Daten erleichtern soll.
Das zweite Beispiel zur Nutzung von GPSies zeigt die Verwendung eines
anderen Bewegungsmodus und den Export in das CSV-Format.
java -jar GPXCrawler.jar -d 1 -k jpjqggfbhtyyrxyr
-b 10.0,51.0,11.2,52.3 -f csv -r dl/gpsies -t walking
Datenquelle 2 - MapMyTracks
Bei der Verwendung von MapMyTracks ist die Übergabe der Nutzerzugangsdaten
erforderlich (Parameter -u -p). Des weiteren wird in diesem Beispiel
die Verwendung des Count-Parameters c demonstriert, mit dessen Hilfe eine
Begrenzung des Suchumfangs möglich ist.
java -jar GPXCrawler.jar -d 2 -u gpxTester -p gpxcrawl
-r dl/mmt -c 10
Dieser Aufruf exportiert die Daten im CSV-Format.
java -jar GPXCrawler.jar -d 2 -u gpxTester -p gpxcrawl
-f csv -r dl/mmt -c 15
Datenquelle 3 - OpenStreetMap
Die Nutzung von OpenStreetMap ist vergleichbar mit GPSies. Einzig die
direkte Auswahl des Tracktyps ist nicht möglich, so dass eine dynamische
Auswertung während des Suchvorgangs ausgeführt wird, welche eine Klassifikation
der Daten ermöglicht.
java -jar GPXCrawler.jar -d 3 -b 10.0,51.0,10.2,51.5
-r dl/osm
Auch hier ist der Export im CSV-Format möglich.
java -jar GPXCrawler.jar -d 3 -b 13.0,52.4,13.2,52.6
-f csv -r dl/osm
8

10 Testszenarios Klingen, Dreßke
Ergebnisse der Testszenarios
Die Ausgabedateien der Tests werden in einer übersichtlichen Ordnerstruktur
abgelegt.
#tree -L 3 dl/
dl
gpsies
csv
walking
gpx
jogging
mmt
csv
walk
gpx
walk
osm
csv
unknown
gpx
unknown
car
16 directories, 316 files
Der Umfang der gesammelten Daten betrug bei der Durchführung der Testdurchläufe
316 Dateien mit einem Gesamtdatenvolumen von 83 MB.
#du -sh dl/
83M dl/
Auf diesem Wege kann somit in kürzester Zeit eine umfangreiche Datenbasis
zur weiterführenden Auswertung gesammelt werden. Projektauswertung
In diesem Abschnitt sollen einige Punkte und Auffälligkeiten innerhalb der
Bearbeitungsphase des Projektes dargestellt werden, um die eigene Arbeit
zu reflektieren und mögliche, sinnvolle Erweiterungen für künftige Projekte
aufzuzeigen.
9

11 Bewertung des Projektverlaufs Klingen, Dreßke
11 Bewertung des Projektverlaufs
Innerhalb des Projektverlaufs wurde von einer zunächst angedachten offline
Anbindung eines Dumps des Datenbestandes von OpenStreetMap hin
zu einer online Lösung gewechselt. Dadurch sind jederzeit die aktuellsten
Daten der Datenquelle verfügbar, womit auf den wachsenden Datenbestand
zugegriffen werden kann. Dadurch sind auch künftig eingepflegte Daten für
das Projekt erschlossen. Leider war es nicht möglich, einen API-Key für das
Strava-Projekt zu erhalten. Somit konnte diese Datenquelle nicht getestet
werden. Jedoch wurde eine Anbindung hierzu mit Hilfe der API Dokumentation
implementiert.
12 Zusammenfassung
Alle Anforderungen des Auftragsgebers wurden umgesetzt und konnten in
einer Abschlusspräsentation demonstriert werden. Unter dem Punkt Literaturtests
wurde gezeigt, dass der Crawler unter realistischen und praxisnahen
Einsatzszenarios verwendbare und auswertbare Daten sammelt, was
die primäre Zielsetzung dieses Projektes dargestellt hat. Ebenso wird die
Klassifikation von Streckendaten unterstützt, was eine Optimierung der Algorithmen
zur Modellierung der weiterführenden Projekte ermöglicht.
Auf Grundlage dessen kann von einer erfolgreichen Projektumsetzung gesprochen
werden.
13 Ausblick und mögliche Erweiterungen
Es wurden zahlreiche externe Libraries in das Projekt eingebunden, was zur
Folge hatte, dass die lauffähige Version des Crawlers eine etwas auffällige
Größe erreicht hat (ca. 50MB). Dadurch ist ein etwas erhöhter Ressourcenverbrauch
bei der Versionierung feststellbar gewesen. Es wäre denkbar, diesen
Overhead zu reduzieren, indem möglicherweise auf einzelne Datenquellen
verzichtet würde. Dies wäre durch Analyse der gelieferten Daten denkbar.
Durch den Wegfall einzelner Libraries könnte die Applikation resourceneffizienter
verwaltet werden.
Darüber hinaus wäre eine Anbindung weiterer Datenquellen vorstellbar. Dies
dazu notwendigen Überlegungen und implementationstechnischen Vorgehensweisen
sind in der Kurzdokumentation näher ausgeführt.
10

Literatur
Klingen, Dreßke
Literatur
[Gar] Garmin. http://www8.garmin.com/xmlschemas/GpxExtensionsv3.xsd.
[MK] Marc Simons Manuel Kotlarski. Projektseminar -
Erkennung des Mobilitätsmodus (completed 2013, available
from FU internal access). http://userpage.fuberlin.de/semu/intern/2013
project transportation mode.pdf.
[Mü] Sebastian Müller. http://userpage.fu-berlin.de/semu/ps13/.
11