Web-Crawling und Erreichbarkeitsvisualisierung

Leopold-Franzens-Universität Innsbruck
Institut für Informatik
Datenbanken und Informationssysteme
Web-Crawling und Erreichbarkeitsvisualisierung
von Events
Bachelor-Arbeit
Nikolaus Risslegger
betreut von
DI Nikolaus Krismer
Prof. Dr. Günther Specht
Innsbruck, 31. Oktober 2015
Zusammenfassung
Die Darstellung von Ereignispunkten - Points of Interest (POIs) im
Web ist aus dem Umfeld der interaktiven Kartendarstellung kaum mehr
wegzudenken. Die gängigen Umsetzungen haben jedoch alle gemeinsam,
dass Informationen zur Erreichbarkeit eines Punktes nur unvollständig
verfügbar sind. Entweder werden diese mit Hilfe eines öffentlichen Verkehrsmittels und nahegelegenen Haltestellen umgesetzt (wobei dann häufig
auf den Weg zwischen Haltestelle und POI selbst vergessen wird) oder
unter Verwendung eines PKWs.
Sinnvoller für den Kunden, den Verkehrsteilnehmer, wäre es, bekannte
Algorithmen aus dem Feld der Erreichbarkeitsanalysen zu verwenden,
um Kombinationen mehrerer Verkehrsmittel zu erlauben. Genau dies
ist das Ziel dieser Bachelor-Arbeit. Hier werden Isochrone verwendet,
um das Einzugsgebiet“ eines POIs zu berechnen. Dafür nicht beliebi”
ge Punkte zur Berechnung herangezogen, sondern nur solche, an denen
eine Veranstaltung stattfindet. Es bedarf folgedessen der Umsetzung eines Crawling-Mechanismus, um geeignete Punkte zu ermitteln. Diese
werden dann mit einer Isochronen-Berechnung kombiniert, um eine Erreichbarkeit für Events zu visualisieren.
Abstract
The visualisation of Point Of Interests (POI) is a well-known feature in
interactive maps and hardly indispensable. The current solutions have
in common, that information about the point’s reachability is incomplete. In many cases the reachability is calculated on basis of the public
transport system (where the way between the bus stop and the event is
mostly ignored) OR a car.
More useful calculations for the customer could be computed with algorithms from the field of reachability analysis. This would improve the
reachability information, since multiple transportation systems could be
combined. That’s exactly the goal of this BSc thesis. Isochrones are
used to calculated a reachability region“ of a POI. Furthermore, not
”
all POIs are allowed as query point, only points where an event is planned. Therefore a crawling mechanism has to be implemented to get such
points. These points are then combined with algorithms from isochrone
algorithms to visualize the correct reachability of an event.
Inhaltsverzeichnis
1 Einleitung
1.1 Aufgaben und Ziele . . . . . . . . . . . . . . . . . . . . . .
1.2 Inhaltlicher Aufbau der Arbeit . . . . . . . . . . . . . . .
2 Grundlagen
2.1 Mashups . . . . . . . . . . . . . . . . . .
2.2 Web-Mapping . . . . . . . . . . . . . . .
2.2.1 Anforderungen an Kartensysteme
2.2.2 Vorteile digitaler Kartensysteme
2.3 State of the Art . . . . . . . . . . . . . .
2.3.1 Event-Karten . . . . . . . . . . .
2.3.2 Öffentliche Verkehrsdaten . . . .
3 Umsetzung
3.1 Event Crawling . . . . . . . . . . . .
3.1.1 POI-Anbieter . . . . . . . . .
3.1.2 Import der Daten . . . . . . .
3.2 Server und verwendete Technologien
3.2.1 Datenbank und ORM . . . .
3.2.2 Caching der Daten . . . . . .
3.2.3 Ruby on Rails . . . . . . . .
3.3 REST-API . . . . . . . . . . . . . .
3.3.1 Grundlagen . . . . . . . . . .
3.3.2 Aufbau . . . . . . . . . . . .
3.4 Event Visualisierung . . . . . . . . .
3.4.1 Technische Grundlagen . . .
3.4.2 Bedienung . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
.
.
.
.
.
.
.
3
4
7
7
8
9
9
10
.
.
.
.
.
.
.
.
.
.
.
.
.
13
14
14
17
21
22
24
24
28
28
30
32
32
36
4 Ausblick
38
Abbildungsverzeichnis
39
Literaturverzeichnis
44
III
Kapitel 1
Einleitung
Ein digitales Kartensystem bietet heutzutage neben der klassischen Kartenansicht und eines Navigationssystems weitere Funktionen an. Google Maps beispielsweise, visualisiert die aktuelle Verkehrslage, integriert
Geschäfte und Firmen und zeigt deren Informationen meist in Verbindung mit google+ an, wie z.B. die Öffnungszeiten, Benutzerbewertungen oder Angebote. Microsoft Bing, Apple Karten sowie OpenStreetMap
verfügen über ähnliche Angebote und Dienstleistungen.
Trotz den vielfältigen Möglichkeiten, die die digitalen Kartensysteme
bisher bieten, stehen sie bei manchen Diensten vor Schwierigkeiten.
Ein Beispiel ist die Integration von Daten der öffentlichen Verkehrsmittel. Viele Verkehrsbetriebe stellen ihre Daten nicht der Allgemeinheit
über eine offene Schnittstelle zur Verfügung, was eine Integration kaum
ermöglicht. Außerdem besteht die Schwierigkeit, die regionalen Verkehrsbetriebe (z.B. Wiener Linien, Verkehrsverbund Tirol) mit größeren Betrieben (z. B. ÖBB, DB etc.) zu synchronisieren.
Die vorliegende Arbeit beschäftigt sich mit einer weiteren Möglichkeit:
der Interaktion von Eventdaten bzw. sogenannten Points of Interest
(POIs). Es stehen verschiedene Anbieter von POIs zur Verfügung, die
eine relativ ähnliche Struktur besitzen, aber nicht einfach miteinander
genutzt werden können. In dieser Sparte hat sich noch kein Anbieter
global absetzen können und regionale Anbieter konkurrieren mit Hilfe
von sozialen Netzwerken um die Vormachtstellung.
1.1
Aufgaben und Ziele
Die zwei Komponenten - Web-Mapping und digitale Eventkalender - sollen in einer Applikation vereint werden.
Neben allen Features einer interaktiven Karte sollen ausgewählte Events
im umliegenden Bereich aufscheinen. Dem Nutzer werden Filteroptionen und Detailansichten ermöglicht. Dabei ist darauf zu achten, dass
1
KAPITEL 1. EINLEITUNG
die Benutzbarkeit und die Übersichtlichkeit des gesamten Systems nicht
darunter leidet, sondern die Eventdarstellung als leichtgewichtiges Plugin implementiert ist. Wesentlich hierbei ist, den Benutzer nicht mit
zu viel Informationen zu überfordern, sondern die Veranstaltungen zu
gruppieren und die Anzeige durch ein Filtersystem zu regulieren. Außerdem soll die Eventvisualisierung in ein bestehendes System eingebettet
werden, das eine Isochronen-Berechnung für öffentliche Verkehrsmittel
bereitstellt.
Isochrone bezeichnen in der Verkehrsgeographie die Verbindungslinien
aller Orte, die von einem Ausgangspunkt aus in der selben Zeit erreichbar sind. Eine Isochronen-Karte, selbst oft unter dem Begriff Isochrone“
”
geführt, ist demnach eine Landkarte, die jene Verbindungslinien darstellt. Isochronen-Karten werden seit mindestens vierzig Jahren in der
Stadt- und Verkehrsplanung herangezogen. [GBCI11] Mit dieser Technik
ist es möglich, die Einzugsgebiete für die einzelnen Punkte zu berechnen
und die aktuellen Events im jeweiligen Isochron anzeigen zu lassen.
Die Eventdaten werden von einer offenen Schnittstelle ausgelesen und
müssen nicht manuell eingetragen werden. Dieses Event-Crawling soll im
Hintergrund ablaufen und den Benutzer in keinster Weise berühren. Dabei wird keine neue Plattform erstellt, sondern bestehende Eventprovider
genutzt und deren Daten in das System integriert. Die Administration
der Anwendung wird dadurch erheblich minimiert.
1.2
Inhaltlicher Aufbau der Arbeit
Nach der Einleitung beschäftigt sich Kapitel 2 mit den Grundlagen von
web-mapping-Systemen und erörtert den aktuellen Stand der Forschung
(2015). Dabei werden die wichtigsten Begriffe in Bezug auf die Arbeit
abgegrenzt.
In Kapitel 3 werden die technischen Schwerpunkte der Arbeit dargestellt. Zunächst werden die serverseitigen Strukturen definiert und die
Schwierigkeiten bei der Importierung der Event-Daten gezeigt. Der Aufbau der eigens erstellten REST-API wird ebenfalls in diesem Kapitel
dargelegt. Es folgt die Beschreibung der Implementierung des Clients
und eine kurze Einleitung über die Verwendung des Apps.
Zum Schluss werden in Kapitel 4 Optimierungsmöglichkeiten an der
Datenbank und mögliche Verfahren für eine Erweiterung des ImportVerfahren erörtert.
Die Quellen bzw. Informationen der Abbildungen befinden sich im Abbildungsverzeichnis.
2
Nikolaus Risslegger
Kapitel 2
Grundlagen
Die stetige Weiterentwicklung der Browser und des HTML-Standards
ermöglichen heute eine einfache plattformunabhängige Programmierung.
Applikationen nutzen die Interaktion mit den Benutzern bzw. verbinden
sich mit anderen Web-Services und verwenden deren Ressourcen. Das
entwickelte System basiert auf den Grundsätzen einer web 2.0 Applikation: [KHW08] [Ker06]
• Generischer Inhalt: Die Daten werden von Benutzern editiert
und erstellt. Folglich wächst durch eine rege Community der Inhalt
des Tools.
• Das Web als Plattform: Die Plattform ist in jedem HTML5fähigen Browser nutzbar und eine eigene Adaption des Tools auf
die verschiedenen Endgeräte, wie Smartphones oder Tablets, ist
nicht nötig.
• Vernetzung: Web-Apps nutzen Komponenten und Web-Services,
die von anderen Entwicklern bereitgestellt werden.
Einzelne Dienste werden nicht getrennt genutzt, Webinhalte und
Dienste werden über offene Programmierschnittstellen von anderen Diensten verwendet.
• Software Updates: Der klassische Software-Lebenszyklus ist hinfällig. Serverseitige Updates bemerken die Benutzer nicht, clientseitige Apps werden nach einer Aktualisierung neu geladen.
Bei dieser Arbeit handelt es sich beim Client um eine HTML5-Anwendung, sie benötigt somit keine zusätzliche Software und ist auf allen
Endgeräten (Desktop, Tablet, Smartphone) benutzbar.
Durch die Verwendung verschiedener Ressourcen von unterschiedlichen
Quellen (Event-Daten und die Fahrpläne der öffentlichen Verkehrsmittel) kann dieses App als Mashup eingestuft werden. Der Begriff Mash”
up“ wird in Kapitel 2.1 abgegrenzt.
3
KAPITEL 2. GRUNDLAGEN
Die zentrale Ansicht der App ist eine interaktive Kartenansicht. Die Entwicklungen in diesem Bereich werden in Kapitel 2.2 erläutert.
In Kapitel 2.3 werden aktuelle Technologien und Verfahren von vergleichbaren Anwendungen gezeigt.
2.1
Mashups
Mashups sind Webapplikationen, die sich durch die Verwendung und
Integration von unterschiedlichen Quellen auszeichnen. Gartner definiert
in [RSHM08] Mashups wie folgt:
A mashup is a lightweight tactical integration of multisourced
applications or content into a single offering.
Die Verzahnung der Applikationen untereinander und Integration externer Daten ist eine gängige Methode, um Applikationen einfacher, kostengünstiger und sicherer zu entwickeln. Die führenden Internetunternehmen wie Yahoo1 , Facebook2 und vor allem Google3 bieten zumindest einen Teil kostenfrei über APIs (Application Programming Interface) an.
Für die Service-Provider ermöglicht sich somit ein sicherer Weg, dass ihre
Daten auch von externen Applikationen genutzt werden. Damit wächst
der Bekanntheitsgrad des Providers, dessen Daten verwendet und kostenlos durch die Benutzer aktualisiert werden.
Durch eine mögliche Benutzer-Authentifizierung über die externe Applikation (z.B. OAuth 2.0 - siehe Kapitel 3.1.2) werden auch weitere
Informationen über den Endbenutzer gesammelt. Als häufige Schnittstelle zur Kommunikation zwischen Diensten werden REST-APIs (siehe
Kapitel 3.3) verwendet.
Abbildung 2.1 zeigt den Grad der Integration von externen Diensten in
neue Services und gliedert die Mashups in drei Stufen.
• Mashups der ersten Stufe: Es werden externe Daten von einer
API geladen, um sie dann umformatiert in der eigenen Web-App
oder der Homepage anzuzeigen. Beispiele hierfür sind Beiträge aus
Social Media-Kanälen (tweets, instagram-fotos), Like-Boxen oder
Gefällt mir-Angaben von Facebook.
Für den Anbieter ist die Einbettung eine indirekte Erlösquelle und
erreicht somit weitere Benutzer. Außerdem werden Cookies gesetzt, um das Surfverhalten der Benutzer zu analysieren. Diese
Daten werden vom Anbieter weiterverwendet.
1
developers.yahoo.com
facebook.com/developers
3
developers.google.com
2
4
Nikolaus Risslegger
KAPITEL 2. GRUNDLAGEN
Abbildung 2.1: Klassifikation von Mashups
• Mashups der zweiten Stufe: Die Inhalte werden in die WebApplikation eingebunden und mit bestehenden Inhalten kombiniert. Beispielsweise nutzt ein Immobiliendienst Google Maps und
stellt auf der Karte umliegende Verkaufsobjekte dar.
Das Ziel ist es, mit fremden Inhalten die eigene Applikation zu erweitern und dem Nutzer einen höheren, für ihn positiven Nutzen,
zu bieten.
• Mashups der dritten Stufe: Inhalte und Anwendungen von
zwei oder mehr Anbietern werden kombiniert, dass die Anwendung einen völlig neuen Dienst darstellt. In diese Kategorie kann
diese Bachelorarbeit eingestuft werden.
Die Anzahl von Mashups steigt stetig an, dadurch hat auch die Verwendung von Web-APIs in den letzten Jahren stark zugenommen. Abbildung 2.2 zeigt den rasanten Anstieg der Anzahl von Web-APIs und die
Wichtigkeit für die führenden Anbieter, auf dem Markt präsent zu sein.
Nikolaus Risslegger
5
KAPITEL 2. GRUNDLAGEN
Abbildung 2.2: Anstieg der Web-APIs von 2005 bis 2013
ProgrammableWeb analysiert und listet die beliebtesten Web-APIs auf:4
1. Google Maps: Google Maps API erlaubt den Zugriff über eine
REST-Schnittstelle, die eine einfache Einbindung über Javascript
oder eine serverseitige Integration ermöglicht.
2. Twitter: Das Blogging Service des Dienstes beinhaltet zwei RESTful APIs, um Daten aus dem Netzwerk abzufragen und zu posten.
3. YouTube: Die von Google übernommene API unterstützt alle
Aktionen zum Hinzufügen, Suchen etc. von Videos.
4. Flickr: Das von Yahoo geführte Foto-Portal stellt eine API zur
Verfügung, mit der Bilder, Feeds, Freunde etc. ausgelesen und bearbeitet werden können.
5. Facebook: Die Facebook-API (siehe 3.1.2) bietet alle Methoden
an, um mit dem sozialen Netzwerk interagieren zu können.
Das gesamte Projekt ist als Mashup verschiedenster Technologien zu
sehen: Die Eventvisualisierung kann als Plugin in die Doktorarbeit isochrone-web von Nikolaus Krismer gesehen werden.
Isochrone-web nutzt als Kartendienst leaflet5 und verwendet die Daten
von diversen Verkehrsbetrieben. Leaflet ermöglicht auch weitere Layers
wie z.B. von Bing-Maps oder Google-Maps zu visualisieren. Die gesamte
4
6
www.programmableweb.com/category/all/apis?order=field_popularity
Nikolaus Risslegger
KAPITEL 2. GRUNDLAGEN
Funktionsweise und die Integration der unterschiedlichen Webdienste
wird in Kapitel 3 erklärt.
2.2
Web-Mapping
Die Kartenansicht ist die zentrale Ansicht für den Endbenutzer des
Tools, damit erfolgen alle Interaktionen und die Auswahl der Events.
Die digitale Kartentechnologie wurde 2005 populär, als Google Maps6
2005 seinen Kartendienst veröffentlichte und die Kartennutzung revolutionierte.
Traditionell werden Pläne und Karten auf Papier gedruckt, wobei ihre
thematischen Ebenen wie Gelände, Straßen, Flüsse in unterschiedlichen
Farben, Schattierungen, etc. gekennzeichnet werden. Bis zum Ende des
20. Jahrhunderts war dies die einzige Möglichkeit, kartographisches Wissen weiterzugeben.
Mittlerweile gibt es eine breite Sparte an digitalen Kartenanbietern:
Google Maps, Bing Maps, Apple Karten oder Leaflet sind die bekanntesten, daneben gibt es weitere kleine und regionale/nationale Landkartensysteme. Karten kategorisieren, definieren, arrangieren, lokalisieren bestimmte Gebiete der Erdoberfläche und erleichtern die Denkweise und das Handeln auf vierlerlei Hinsicht, es veranschaulicht für den
Benutzer raumbezogene Daten und schwer formulierbare räumliche Zusammenhänge.
In Kapitel 2.2.1 werden die klassischen Anforderungen und Aufgaben der
klassischen Kartographie erläutert, anschließend bringt Kapitel 2.2.2 die
Vorteile digitaler Kartensysteme näher.
2.2.1
Anforderungen an Kartensysteme
Kartographie behandelt die Interpretation und Darstellung von raumbezogenen Informationen: die Sachaussage über ein Objekt und dessen
geometrische Festlegung in einem Bezugssystem. Kartographische Darstellungen bestehen aus einem System geometrisch gebundener Zeichen
aus einem endlichen, mit vereinbarter Bedeutung versehenen Zeichenvorrat. Darunter ist die Karte am bedeutsamsten; die übrigen Formen
(Luftbild, Panorama, Globus) gelten als kartenverwandte Darstellungen.
[HGM94]
Das Hauptproblem analoger Karten ist der begrenzte Raum und die
Schwierigkeit, relevante Informationen übersichtlich darzustellen. Entweder ist die Karte auf ein bestimmtes Gebiet spezialisiert und kann
5
6
www.leafletjs.com
www.google.com/maps
Nikolaus Risslegger
7
KAPITEL 2. GRUNDLAGEN
in diesem Landkreis viele Details darstellen oder es werden bei einem
entsprechend großen Maßstab auf nicht relevante Daten verzichtet.
2.2.2
Vorteile digitaler Kartensysteme
Die technischen Möglichkeiten, die Zugänglichkeit von öffentlichen Daten und die rasche Entwicklung von Informations- und Kommunikationstechnologien haben in den letzten Jahren in der Kartographie für
grundlegende Änderungen und Vorteile gesorgt. Geodaten und geographische Anwendungen waren zuvor nur für Experten zugänglich. Heute
kann die breite Öffentlichkeit mit den Hilfsmitteln ohne gröbere Kenntnisse über Geodaten oder Kartographie die Online Maps nutzen.
Für alltägliche Handlungen wie die Auswahl des nächsten Cafés oder Bestimmung einer Route mit inkludierten Echtzeitdaten der Verkehrslage
werden heute Karten-Applikationen benutzt. Dies liegt an den vielen
Erleichterungen und Vorteilen, die die digitale Darstellung bringt:
• Flexibilität: Bei analogen Plänen muss ein Maßstab gewählt werden: Dabei muss ein Kompromiss zwischen der dargestellten Fläche
und der detaillgetreuen Darstellung getroffen werden.
Eine digitale Karte lässt sich beliebig benutzen, sie lässt sich ohne
Schwierigkeiten verkleinern oder vergrößern.
• Interaktion: Moderne Kartensysteme arbeiten mit sozialen Netzwerken, Verkehrsbetrieben und weiteren Plattformen zusammen.
So kann bei einer Firmensuche gleichzeitig die Route geplant werden, wobei das aktuelle Verkehrsaufkommen (siehe Abbildung 2.3)
bei der Berechnung berücksichtigt wird.
• Layers: Eine statische Karte spezialisiert sich auf ein bestimmtes Thema: beispielsweise Wanderkarten, topologische Karten oder
historische Karten. Bei modernen Systemen können die Ebenen
(=layers) beliebig gewählt werden.
Google Maps7 bietet eine Schnittstelle an, womit Benutzer eigenständig neue Objekte in die Karte eintragen bzw. bestehende Karten ausbessern können.
• Aktualisierung: Analoge Kartensysteme sind nach einiger Zeit
nicht mehr aktuell, da Landstriche umgewidmet werden oder Neubauten entstehen. Die Aktualisierung der online-Mapping übernimmt meist der Betreiber, außer der Betreiber ist die Community
selbst (OpenStreetMap).
7
8
www.google.at/mapmaker
Nikolaus Risslegger
KAPITEL 2. GRUNDLAGEN
Abbildung 2.3: Darstellung der normalen Verkehrslage in Innsbruck
montags, 9:00 Uhr (google maps)
2.3
State of the Art
Nachdem das World Wide Web 1989 enstand, gab es schon wenige Jahre später die erste web-mapping Anwendung: Der von Xerox entwickelte
PARC Map Viewer verwendete eine geographische Datenbank um Daten on demand zu erstellen und anzuzeigen. [Put94]
Viele Länder entwickelten eigene regionale Kartensysteme. Um 2005 erreichten die Dienste Multimap (Großbritannien) bis zu 7.3 Millionen,
Mapquest (USA) 47 Millionen Besucher. Google revolutionierte mit den
Diensten Google Maps und Google Earth die digitale Kartographierung.
Schon 2007 wurde Google Maps von über 71 Millionen Besuchern genutzt und es gab über 50.000 Webseiten die die Dienste von Google
verwendeten. [HSP08]
Mittlerweile nutzen mehrere Millionen Besucher Map-Anwendungen täglich und wie im vorherigen Kapitel beschrieben, entwickeln sich die WebMapping-Systeme in vielen Arten weiter. Die Problemstellung dieser Arbeit, die Integration von Eventdaten in ein Kartensystem wird bis dato
von keiner App berücksichtigt, dies zeigt folgendes Kapitel 2.3.1. Anschließend wird in Kapitel 2.3.2 die aktuelle Lage des Datenexports von
öffentlichen Verkehrsmitteln beschrieben.
2.3.1
Event-Karten
Die Darstellung von Events ist für die Karten-Betreiber bis dato nicht
implementiert. Einzig Google Maps liefert brauchbare Daten: Wie Abbildung 2.4 zeigt, werden bei einer Suche nach Veranstaltungen oder
Nikolaus Risslegger
9
KAPITEL 2. GRUNDLAGEN
Events die Veranstaltungszentren geliefert, Veranstaltungsdaten sind jedoch nicht sichtbar.
Abbildung 2.4: Ergebnisse der Suche Events in Innsbruck via Google
Maps
Um eine große Anzahl von Datensätzen anzuzeigen, verwendet Google Maps unterschiedlich große Marker: sichtbare Einträge in der Liste
links werden hervorgehoben, andere erscheinen als kleinere Punkte. Diese Technik eignet sich bei großem Zoomfakter gut, bei größerem Maßstab
verliert der Benutzer schnell den Überblick. Ein Clustering der Daten
wäre von Vorteil.
Microsofts Kartendienst Bing Karten und OpenStreetMap liefern zu den
Suchtermen Events“ oder Veranstaltungen“ keine sinnvollen Ergebnis”
”
se.
2.3.2
Öffentliche Verkehrsdaten
Die Integration von Daten aus den öffentlichen Verkehrsbetrieben ist
in Österreich nicht einfach. Es gibt für jedes Bundesland eigenständige
Betriebe (Tiroler Verkehrsbetriebe, Kärntner Linien, etc.), die nur widerwillig ihre Daten für die Öffentlichkeit zugänglich machen.
Das Thema Open Data wird stiefmütterlich behandelt. Derzeit wird an
einer österreichweiten, einheitlichen Lösung gearbeitet, die bei der Verkehrsauskunft Österreich angesiedelt werden soll. Es sei nicht sinnvoll,
wenn jedes Verkehrsunternehmen und jeder Verkehrsverbund eine eige”
ne Open Data-Lösung“ aufbaue.
Bei Verwendung von Google Maps fällt auf, dass die Daten der ÖBB integriert sind, diese haben einen exklusiven Vertrag für die Verwendung
der Daten. Die Initiative offene Öffis schildert das Problem:8
10
Nikolaus Risslegger
KAPITEL 2. GRUNDLAGEN
Die ÖBB hat bewiesen, dass es für sie technisch kein Problem
ist, ihre Daten anderen zu geben – sie hätte dies problemlos
auch als Open Data machen können, so dass auch andere
Unternehmen die ÖBB-Daten in ihre Apps und Services integrieren können.
Österreichweit bieten momentan nur die Linz AG9 und die Wiener Linien10 ihre Abfahrtsdaten und Routenplanung als Open Data an.
8
www.offene-oeffis.at/2013/12/17/google-bekommt-oebb-daten/
data.linz.gv.at/daten/LinzAGLinien/
10
open.wien.at/site/datenkatalog/?search-term=wiener+linien&
connection=and#showresults
9
Nikolaus Risslegger
11
Kapitel 3
Umsetzung
Für die Umsetzung des Projektes wird eine Server-Client-Architektur
gewählt, die die Aufgaben hat, das Event-Crawling und die Visualisierung sinnvoll zu teilen. Abbildung 3.1 visualisiert das Schema des
entwickelten Systems, wobei alle Komponenten seperat weiterentwickelt
werden können.
Abbildung 3.1: Aufbau des Systems
Es gibt einen eigenständigen Server, der die Veranstaltungen von externen Quellen importiert, aufbereitet und über eine REST-Schnittstelle
anbietet. Die Daten können von mehreren verschiedenen Client-Systemen
genutzt werden.
Welche Schwierigkeiten das Crawling und Zwischenspeichern von Events
von den Big Data-Anbietern wie Twitter, Facebook oder Google bereitet, wird in Kapitel 3.1 beschrieben. In Kapitel 3.2 wird die Wahl des
relationalen DB-Managementsystems und der Aufbau der Serverarchi13
KAPITEL 3. UMSETZUNG
tektur erläutert. Die Aufrufe und der Aufbau der REST-API wird in
Abschnitt 3.3 beschrieben.
Die clientseitige Arbeit, genauer die Visualisierung und die Integration
in das Projekt IsoMap“ wird in Kapitel 3.4 erläutert.
”
3.1
Event Crawling
Um die Entwicklung und vor allem die Administration einer eigenständigen Event-Plattform zu vermeiden, werden die POIs aus einem öffentlichen Veranstaltungsportal geladen. Die Prioritäten bei der Auswahl
des Anbieters werden nachfolgend aufgelistet:
• Angebot: Die Plattform muss regional unabhängig sein und ein
möglichst breites Spektrum von Veranstaltungen abdecken.
• Preis: Die Administration für den Veranstalter, sowie der remoteZugriff für die Applikation, dürfen keine Kosten verursachen.
• ständige Verfügbarkeit, Wachstum: Die Plattform sollte auch
in Zukunft weiter bestehen und zu jeder Zeit erreichbar sein.
• Attribute: Geo-Informationen der POIs sind essentiell notwendig, andere Attribute wie Eintrittspreise, Veranstalter etc. sind
vernachlässigbar.
Das Kapitel 3.1.1 beschreibt Vor- und Nachteile ausgewählter Anbieter und erklärt, warum Facebook als Schnittstelle gewählt wird. Der
Authentifizierungs-Prozess und der Import der Daten werden in Kapitel 3.1.2 erläutert.
3.1.1
POI-Anbieter
Die Veranstaltungsorganisation von Tourismusbetrieben, Verkaufsstellen, Gemeinden, etc. wird unterschiedlich gelöst. Die Eventkalender sind
in den kleinen, regionalen Anbietern statisch in ihren Websiten eingebunden. Der wichtigste Punkt für die Anbieter ist meist ein gutes Ranking
bei Suchmaschinen. Dies wird durch Search Engine Optimization - das
Einfügen von Metadaten, entsprechende HTML-Tags - erreicht, und ist
aus marketingtechnischer Sicht wichtiger, als eine Schnittstelle zum Abgreifen der Daten bereitzustellen.
Ein Feature von Google zeigt (siehe Abbildung 3.2) aktuelle Veranstaltungen in der Umgebung als Feed. Um in dieser Ansicht aufzuscheinen,
müssen die Daten in einem vorgegebenen Schema1 in den Websiten deklariert werden, um von Google als Veranstaltung erkannt zu werden,
das Listing 3.1 zeigt ein Beispiel.
1
14
schema.org/Event
Nikolaus Risslegger
KAPITEL 3. UMSETZUNG
Abbildung 3.2: Darstellung von Events mit der Google-Websuche mit
Hilfe von schema.org Event-Tags
Listing 3.1: Event-Schema
< s c r i p t t y p e=” a p p l i c a t i o n / l d+j s o n ”>
{
” @context ” : ” h t t p : // schema . o r g ” ,
” @type ” : ” TheaterEvent ” ,
”name” : ”Noch e i n m a l v e r l i e b t von Joe D i P i e t r o ” ,
” u r l ” : ” h t t p : //www. k e l l e r t h e a t e r . a t / s p i e l p l a n / 4 7 / noch−
einmal−v e r l i e b t . htm” ,
” s t a r t D a t e ” : ” 2 0 1 5−0 8−0 6T2 0 : 0 0 : 0 0 . 0 0 0 ” ,
” location ” : {
” @type ” : ” P e r f o r m i n g A r t s T h e a t e r ” ,
”name” : ”INNSBRUCKER KELLERTHEATER” ,
”sameAs” : ” h t t p : //www. k e l l e r t h e a t e r . a t ” ,
” address ” : {
” @type ” : ” P o s t a l A d d r e s s ” ,
” s t r e e t A d d r e s s ” : ” Adolf−P i c h l e r −P l a t z 8 ” ,
” a d d r e s s L o c a l i t y ” : ” Innsbruck ” ,
” addressRegion ” : ” Tirol ” ,
” postalCode ” : ”6020” ,
” a d d r e s s C o u n t r y ” : ”AT”
}
}
}
</ s c r i p t >
Die Websites müssten eigens indiziert und gecrawlt werden, da Google
keine Export-Möglichkeit der fertigen Daten anbietet (Stand Juli/2015).
Dafür würde ein großes Serversystem benötigt werden, um selbst nur
einen kleinen Teil des world-wide-webs zu crawlen. Folgend wird eine
Importquelle aus diversen Event-Plattformen oder den Social MediaNetzwerken gesucht.
Event-Netzwerke
Ein POI-Netzwerk zeichnet sich durch die Interaktionen mit den Benutzern und das dadurch stetig wachsende Angebotsprogramm aus. Im Vergleich zu Single-Pages wird das Administrations-Recht der Events von
einigen einzelnen Berechtigten auf alle registrierte Benutzer übertragen.
Der wichtigste Punkt einer Eventplattform ist somit die Benutzeranzahl,
Nikolaus Risslegger
15
KAPITEL 3. UMSETZUNG
daraus folgt der Wiedererkennungswert und die Marktpräsenz.
Upcoming“ war von 2004 bis April 2013 ein solches, stark frequen”
tiertes Veranstaltungsportal. Es kombinierte die Funktionen eines sozialen Netzwerkes und einer Eventdatenbank. Das Portal wurde durch die
starke Usercommunity populär, erweiterte Filterfunktionen für Veranstaltungen rundeten das Angebot ab.
2007 wurde die Plattform von Yahoo! übernommen und begann anschließend Veranstaltungen von kommerziellen Quellen zu importieren.
Neben den bestehenden Exportmöglichkeiten via iCalendar und RSS,
stand auch die Möglichkeit zur Verfügung, die Daten über eine offene API-Schnittstelle zu suchen und zu verwalten. 2013 wurde das Portal geschlossen, wobei der Gründer Andy Baio 2014 eine KickstarterKampagne (30.000 Dollar in 90 Minuten) erfolgreich durchführte, um
das Portal wiederzueröffnen. [Bal14] [Bai13] Bis dato ist das Projekt2
aber noch nicht online.
Eine Alternative stellt die Plattform Eventful“ 3 dar. Gegründet wurde
”
der Online-Event-Manger im Jahr 2004 und ist mittlerweile eine SubMarke der CBS Corporation. Wie bei ähnlichen Plattformen übernehmen
die registrierten Benutzer die Administration der Veranstaltungen. Daneben stehen klassische Filtermöglichkeiten nach Zeit, Künstler, Ort und
anderen Tags zur Verfügung. Die Suchmöglichkeit steht auch über eine
API4 zur Verfügung, welche die Daten in XML liefert. In Europa ist
die Plattform kaum bekannt und besitzt wenig Events, weshalb sie als
Importquelle für das Projekt ausscheidet.
Soziale Netzwerke, allen voran Google+, Twitter oder Facebook, erweitern stetig ihren Umfang und bieten unter anderem folgende Funktionen
an: Private und öffentliche Gruppen ermöglichen den Interessensaustausch unbekannter Personen; Hashtagging vereinfacht die Kategorisierung öffentlicher Beiträge in Themengebiete. Es gibt ebenfalls Integrationen von Veranstaltungsplattformen in den sozialen Netzwerken.
Weiters erstellen Firmen, Sportvereine, Organisationen und öffentliche
Personen Seiten, um ihre Fans mit Neuigkeiten zu versorgen. Die Verbindung wird nach dem Producer-Consumer-Modell aufgebaut: Die Follower erhalten nach dem Abonnement der Seite alle Benachrichtigungen derselben. Durch die gute internationale wie regionale Präsenz und
der ausgereiften API erfolgt der Veranstaltungsimport über Facebook.
[ZZ11]
Es gibt keinen vergleichbaren Anbieter, der einen ähnlich großen Benutzerstamm und folglich dementsprechend viele Veranstaltungen beinhal2
upcoming.org
eventful.com
4
api.eventful.com/docs/events/search
3
16
Nikolaus Risslegger
KAPITEL 3. UMSETZUNG
tet und diese weiters über eine offene Schnittstelle anbietet. Google+
scheidet als brauchbare Alternative aus, da in unseren Gegenden dieses
Netzwerk nicht ausreichend genutzt wird.
Facebook als Eventanbieter
Als erster Schritt muss eine Veranstaltung durch eine öffentliche Seite
oder eine Privatperson angelegt werden (Abbildung 3.3). Die wichtigste
Einstellung ist die Sichtbarkeit: Öffentliche Events werden von Suchmaschinen indiziert und jeder kann die angegebenen Informationen auslesen. Privatveranstaltungen sollten als solche gekennzeichnet werden, um
unnötige Resonanz zu vermeiden.
Abbildung 3.3: Sichtbarkeitseinstellungen eines Events, Facebook
Facebook legt das Hauptaugenmerk auf die Interaktion mit den Benutzern: Auf der Pinnwand der Veranstaltung können Videos, Fotos oder
Statusupdates gepostet werden. Dadurch werben die Teilnehmer indirekt bei deren Freunden für das Ereignis. Für den Veranstalter ist das
ein Vorteil, er erreicht kostengünstig potentielle Teilnehmer. Der Kontakt mit den Besuchern vereinfacht sich ebenfalls: Über die Plattform
können Updates bezüglich Wetter oder Anfahrt kommuniziert werden.
3.1.2
Import der Daten
Alle großen Web-Plattformen wie z.B. Twitter, Facebook, Yahoo oder
Google bieten ihre Daten über verschiedene Schnittstellen an. Dabei
verfolgen die Unternehmen unterschiedliche Ansätze, sei es das Format
für den Request, die Authentifizierung oder die Response-Daten: Yahoo
ermöglicht den Zugriff ihrer Daten über eine an den SQL-Standard angelehnte Abfragesprache (YQL - Yahoo Query Language). Listing 3.2
zeigt eine Abfrage mit YQL aus der Weather API5 :
5
developer.yahoo.com/weather/h
Nikolaus Risslegger
17
KAPITEL 3. UMSETZUNG
Listing 3.2: Wetterabfrage für Innsbruck mit Yahoo! Wetter API
SELECT ∗ FROM w e a t h e r . f o r e c a s t
WHERE woeid
IN (SELECT woeid FROM geo . p l a c e s ( 1 )
WHERE t e x t=” i n n s b r u c k , aut ” )
Eine Alternative stellt der Zugriff der Daten über eine REST-API mit
eindeutigen URI und entsprechenden GET-Parametern dar (Google, Facebook, Twitter). Listing 3.3 zeigt eine Routenberechnung von Innsbruck
nach Schwaz mit der google-maps-API.
Listing 3.3: Zugriff google-maps-API
h t t p s : / / maps . g o o g l e a p i s . com/maps/ a p i / d i r e c t i o n s / j s o n ? o r i g i n=
I n n s b r u c k&d e s t i n a t i o n=Schwaz&a v o i d=highways&mode=w a l k i n g
Der Zugriff auf die Daten über die Facebook-API und der Import in das
System beschreiben folgende Unterkapitel.
Facebook graph API
Mit der seit 2007 zugänglichen Graph-API ist es möglich, Daten aus
der Facebook-Plattform zu lesen und zu schreiben. Der Zugriff basiert
auf einer low-level HTTP-API und ermöglicht den Zugriff auf folgende
Informationen:6
• nodes: - Elemente wie Personen, Seiten, Kommentare oder Fotos
• edges: - stellen die Verbindungen zwischen den nodes dar: Person
x postet Foto y auf Seite z.
• fields: - sämtliche Attribute der nodes, wie Titel, Geburtstag, etc.
Mit GET-requests werden die Daten abgerufen:
Listing 3.4: Fetching von FB-Daten der Uni Innsbruck - request
GET
graph . f a c e b o o k . com
/ uniinnsbruck ?
f i e l d s =id , name , w e b s i t e , b i r t h d a y
Ist eine Authentifizierung (siehe Kapitel 3.1.2) bzw. der Content für
den Access-Token nicht freigegeben, erfolgt eine Facebook-interne Fehlermeldung.
6
18
developers.facebook.com/docs/graph-api
Nikolaus Risslegger
KAPITEL 3. UMSETZUNG
Listing 3.5: Fetching von FB-Daten der Uni Innsbruck - error-response
” error ” : {
” message ” : ”An a c c e s s t o k e n i s r e q u i r e d t o r e q u e s t t h i s
resource . ” ,
” t y p e ” : ” OAuthException ” ,
” code ” : 104
}
Bei entsprechenden Access-Rechten werden die Daten im JSON-Format
übermittelt.
Listing 3.6: Fetching von FB-Daten der Uni Innsbruck - response
{
” i d ” : ” 75851196267 ” ,
”name” : ” U n i v e r s i t ä t I n n s b r u c k ” ,
” w e b s i t e ” : ”www. u i b k . ac . a t / ” ,
” b i r t h d a y ” : ” 10/15/1669 ”
}
OAuth
Facebook verwendet eine Implementierung des OAuth 2.0 Protokolls7
um die Identität eines Web-Apps zu authentifizieren und limitiert über
Access-Tokens die bereitgestellten Daten.
OAuth stellt eine Verifizierung des Benutzers zur Verfügung, ohne dessen Account-Passwort zu verwenden. Das Service wurde 2006 initiiert,
ausgehend von Blaine Cook (Twitter) und weiteren Entwicklern, die kritisierten, dass es keinen Authentifizierungsstandard gibt. Im April 2010
wurde Version 1.0 veröffentlicht. [HL10]
OAuth 2.0 ist nicht abwärtskompatibel, aber vereinfacht die Kommunikation zwischen den Teilnehmern und wurde 2012 publiziert. [Har12]
Folgende Aktionen bietet das OAuth-Protokoll an:
• Posten von Informationen des Benutzers im Stream (Twitter/Facebook)
• Zugriff zu Inhalten, Bearbeiten und Speichern von Dokumenten
(Dropbox, Google Docs)
• Lesezugriff auf Benutzerdaten, wie Facebook-Freunde, Google-Kontakte etc.
Mittlerweile unterstützen mehr als 300 Webservices die Authentifizierung via OAuth 2.0. [Boy12]. Abbildung 3.4 zeigt die Interaktion zwischen den vier Rollen (Resource Server, Resource Owner, Client, Authorization Server ):
7
oauth.net/2
Nikolaus Risslegger
19
KAPITEL 3. UMSETZUNG
(A) Der Client sendet eine Anfrage an den Resource Owner (facebookBenutzer) oder wird über einen Authorization Server (facebook
Login) umgeleitet.
(B) Nach erfolgreichem Login erhält der Client einen Authorization
grant für die bereitgestellten Daten.
(C) Anschließend wird ein acces token angefordert, welches den Zugriff
auf die Daten vom Resource Server ermöglicht.
(D) Der Authorization Server erkennt den Client durch den authorization grant und stellt nach der Validierung der Daten einen access
token zur Verfügung.
(E) Mittels access token kann der Client die Daten am Resource Server
anfragen.
(F) Ist der token gültig, werden die Daten geliefert.
Die Kommunikation zwischen den authorization server und resource server werden nicht im Protokoll festgelegt. Facebook verschweißt in der
Implementierung den Teil von Rescue Owner und Authorization Server.
[Har12]
Abbildung 3.4: Funktionsweise OAuth 2.0 [Har12]
Facebook bietet neben den user tokens u.a. app tokens an, die ebenfalls
auf die Graph-API zugreifen, aber keinen expliziten Login benötigen.
Der Zugriff auf öffentliche Daten ist erlaubt, es ist nicht möglich, mit
einem app-token persönliche Daten zu lesen bzw. schreiben.
Die Authentifizierung unterscheidet sich zum klassischen OAuth-Prozess
wie folgt: Als erster Schritt wird eine Facebook-App angelegt und die Zugriffsberechtigungen festgesetzt. Für das fetching der öffentlichen Events
reichen die Standardeinstellungen aus: email, public profile, user friends.
20
Nikolaus Risslegger
KAPITEL 3. UMSETZUNG
Anstatt der Login-Daten des Benutzers (Resource Owner ) werden die
App-Id und das App-Secret zur Anmeldung verwendet.8
Import
Die Eventdaten direkt aus der Graph-API mittels Koordinaten abzufragen ist nicht möglich. Facebook grenzt die API-Calls stark ein und
indiziert die Events nach ID, Veranstalter, Name, Veranstaltungsort.
Folglich müssen die Veranstalter (Personen oder Seiten) bekannt sein,
um deren Veranstaltungen indizieren zu können.
Eine Suche nach Pages basierend auf Städten oder Geo-Koordinaten
wird nicht unterstützt, somit müssen die Veranstalter-Seiten bekannt
sein, um deren POIs auszulesen. Dies erschwert den Import essentiell,
denn die Page-IDs müssen manuell eingetragen werden. Somit unterscheidet sich diese Variante wenig von der vermiedenen manuellen Aufnahme einzelner Seiten mit den Event-Meta-Tags. (Siehe Listing 3.1).
Mit einem POST-request werden dem Server Name (der eindeutige Slug
in der URL) oder die ID übergeben (siehe Listing 3.7) und die Seite wird
als Event Provider in die Datenbank aufgenommen. Ab dem nächsten
Event-Fetching werden die POIs der Seite importiert.
Listing 3.7: Hinzufügen einer Seite als POI-Provider
Remote Address : 8 2 . 1 5 0 . 2 0 9 . 1 8 3 : 8 0
Request URL: h t t p : / / aod . web−c r o s s i n g . com/ a p i / page
Request Method : POST
Request Payload : { u i d : ” u n i i n n s b r u c k ” }
S t a t u s Code : 2 0 1 C r e a t e d
3.2
Server und verwendete Technologien
Das Fetching der Daten über die Graph-API anhand Geo-Daten ist
nicht möglich, das Projekt fordert eine eigene, passende Schnittstelle.
Durch die Aufteilung in die Client-Server-Struktur ist eine Erweiterung
der POI-Anbieter einfach und erfordert lediglich kleine Anpassungen am
Server.
Das System läuft auf einem Ubuntu 14.04.02 LTS9 , mysql 5.5.4310 ,
ruby 1.9.311 und rails 4.1.612 . Dieses Kapitel beschreibt die Wahl der
Datenbank, Informationen über das Cachen von Daten von Drittanbietern und den Algorithmus für das Fetching der Daten. Die REST-API
wird in Kapitel 3.3 behandelt.
8
developers.facebook.com/docs/facebook-login/access-tokens
www.ubuntu.com/desktop
10
www.mysql.com
11
www.ruby-lang.org/en
12
rubyonrails.org
9
Nikolaus Risslegger
21
KAPITEL 3. UMSETZUNG
3.2.1
Datenbank und ORM
Ruby on Rails (RoR) greift auf einem in C geschriebenen Adapter auf
die Datenbanken zu und unterstüzt unter anderem MySQL, DB2, Microsoft SQL Server und Postgres. Mit dem Object Relational Mapping
übernimmt RoR den kompletten Zugriff auf die Datenbank und das darunter liegende DBMS kann zu jederzeit ausgetauscht werden. Die Klassennamen werden direkt Datenbanktabellen zugeordnet, die Datensätze
stellen die Objekte, Spalten die Attribute dar. Auf umständliche Konfiguration wie z.B. bei Hibernate wird verzichtet, Ruby arbeitet mit
vorgegebenen Konventionen: Als Beispiel ist der Tabellenname immer
der Name des Models in Plural. Die Konfigurationsdatei (Listing 3.8)
enthält den Treiber, Verbindungsdaten und Parameter für unterschiedliche Deploy-Modi. [BK07]
Listing 3.8: Datenbankkonfiguration
development :
a d a p t e r : mysql2
encoding : utf8
d a t a b a s e : <%= ENV[ ’DB ’ ] %>
username : <%= ENV[ ’USER ’ ] %>
password : <%= ENV[ ’PW’ ] %>
host : l o c a l h o s t
p o r t : 3306
p o o l : 10
MySQL
Die Wahl für mysql als Datenbankverwaltungssystem begründet sich
durch die einfache Administration. Es bestehen keine besonderen Anforderungen an die Datenbank. Das relationale Datenschema wird von
der Graph-API teilweise übernommen.
Tabelle 3.1:
Feld
id (P KEY)
description
endTime
startTime
name
created at
updated at
venue id (F KEY)
page id (F KEY)
privacy
location
22
Model Event
Type
bigint (20) unsigned
text
varchar(255)
varchar(255)
varchar(255)
datetime
datetime
bigint(20) unsigned
bigint(20) unsigned
varchar(255)
varchar(255)
Nikolaus Risslegger
KAPITEL 3. UMSETZUNG
Tabelle 3.1 zeigt am Beispiel des Event-Models die Strukur einer Veranstaltung. Die rails-typischen Attribute created at und updated at werden für interne Zwecke verwendet. Auffällig sind die extrem großen Datentypen (bigint) für die Primary- und Foreign-Schlüssel, die von der
Graph-API übernommen werden.
Die Beibehaltung der ID’s erleichtert die Synchronisierung bei den Updates mit der Plattform. Durch die Verwendung eines Anbieters benötigt
das System keine internen unique keys. Bei einer Integration weiterer
Anbieter in das System folgt ein Umbau des Models und erfordert mindestens zwei ID’s pro Event (da die Event-ID des Anbieters nicht mehr
als unique angenommen werden kann).
Die importierten Start- und Endzeiten werden von der API nativ übernommen, welche diese auch als String-Objekt speichert, und nicht in ein
Datetime-Objekt konvertiert.
Alternativen
Bei einer Erweiterung des Importsystems und einem enormen Anstieg
der Daten wäre eine Verwendung eines nosql-Systems wie CouchDB13
zu überlegen. Im Gegensatz zu relationalen Modellen speichern diese
Systeme die Daten dokumentenbasiert als JSON-Objekte. Die Struktur
der einzelnen Datensätze könnte unterschiedliche Attribute beinhalten.
Objekte von verschiedenen Providern müssen nicht extra verarbeitet
werden.
Dabei stellt sich die Frage, welche zusätzlichen Daten für das Projekt
benötigt werden. Außerdem stellt sich bei der Verwendung eines ORMappers die Sinnhaftigkeit einer nosql-Datenbank dar. Rails unterstützt
MongoDB, ein Mapper ist implementiert, doch die Vorteile in Bezug auf
Geschwindigkeit und Flexibilität einer no-sql Datenbank werden durch
das Mapping eingeschränkt.
Bei stark steigenden Benutzeranfragen sollte das Datenbanksystem zu
postgres-SQL getauscht werden, das nativ MVCC unterstützt. Multiversion Concurrency Control (MVCC) ist das umfassende Transaktionskonzept, welches gleichzeitigen Datenzugriff ohne Geschwindigkeitseinbußen ermöglicht. Bei Löschen, Hinzufügen oder Updates werden intern
veschiedene Versionen der Objekte angelegt. Lese-Zugriffe benötigen keine Locks, sie greifen automatisch auf das zu jenem Zeitpunkt aktuelle
Objekt zu.
Nachteile dieser Variante sind die extremen Overhead-Kosten beim Ändern der Objekte und der zusätzliche Speicherbedarf durch die Kopien.
Bis auf das Hinzufügen eines neuen Anbieters durch den Benutzer werden alle Inserts und Updates von einer zentralen Stelle seriell ausgeführt.
13
couchdb.apache.org
Nikolaus Risslegger
23
KAPITEL 3. UMSETZUNG
3.2.2
Caching der Daten
Provider stellen ihre Daten und Rechenleistung zur Verfügung, jedoch
regulieren sie das Speichern der Informationen auf externen Servern.
Drittanwendungen sollen die Daten direkt von der API auslesen und
nicht auf ihren eigenen Server zwischenspeichern. Durch das Caching
können die Anbieter die Aufrufe nicht tracken und verlieren so die Kontrolle der Zugriffe.
Facebook verfolgt hier eine ähnliche Linie, die Daten sollten wenn möglich
direkt über die API geladen werden, eine Zwischenspeicherung der Daten ist aber erlaubt:
If you cache data you receive from us, use it to improve your
app’s user experience and keep it up to date.14
Die Aktualisierung passiert bei dem System durch einen Cron-Job, der
das Fetching der Daten alle drei Stunden aufruft. Vom Veranstalter
gelöschte Events werden aus der Datenbank entfernt und alle anderen
aktualisiert. Durch diese Vorgehensweise werden die Graph-Aufrufe via
Facebook gering gehalten, aber trotzdem eine aktuelle Liste der Veranstaltungen garantiert.
3.2.3
Ruby on Rails
Die Verwendung von Ruby on Rails als Web-Framework ermöglicht
einfache Erweiterbarkeit, unterstützt moderne Programmierparadigmen
und ist open-source.
Die Frameworks wie Microsoft .NET oder die Technologien von Java 2 Enterprise Edition (J2EE) sind für das Projekt zu vielschichtig,
benötigen relativ viel Overhead und stellen für diese Projektgröße einen
zu großen Aufwand bei der Einrichtung und Konfiguration dar. Im Gegensatz wäre php eine Alternative: Dieses Framework wird von diversen
Entwicklern in unterschiedliche Inkremente erweitert, somit vermischen
sich die unterschiedlichen Ansätze. [BK07]
Die Eigenheiten und Vorteile von Ruby on Rails werden in diesem Kapitel erläutert.
Grundlagen
Ruby on Rails ist ein serverseiteges Framework, basierend auf der Programmiersprache Ruby, einer objektorientierten Skript-Sprache. Vorgestellt wurde das Projekt im Juli 2004, die aktuelle Version 4.2.0 wurde
am 19. Dezember 2014 veröffentlicht. Es beinhaltet seit dem Start die
14
24
developers.facebook.com/policy
Nikolaus Risslegger
KAPITEL 3. UMSETZUNG
Unterstützung von Ajax, das zu dieser Zeit einige Vorteile in der dynamischen Webentwicklung brachte und bescherte dem Framework großen
Erfolg. [VH10]
Ruby on Rails zeichnet sich durch folgende Prinzipien aus:
• Model-View-Controller: Als Grundgerüst des Frameworks liegt
die typische Gliederung des Programmes in Daten (=Model), Controller (=Logik) und deren Darstellungen (=Views). Die elementare Gliederung schafft somit ein einfaches Zusammenspiel der Komponenten, wobei auf eine möglichst lose Kopplung zu achten ist.
Ein Aufruf der API wird folgend abgearbeitet:
1. Der Aufruf /api/events wird durch den integrierten RoutingMechanismus zum entsprechenden Controller weitergeleitet.
2. Der Controller greift auf die Daten der Models zu, hier gilt
das Paradigma: thin controller, thick models - um redundante
Codezeilen im Controller zu vermeiden.
3. Die Ausgabe der Daten wird über den Controller in einem
View in der gewünschten Repräsentation (json, html) dargestellt.
Abbildung 3.5: Schematische Darstellung des MVC-Paradigmas
• Convention over Configuration: Ruby verwendet das DesignParadigma exzessiv und verlangt vom Programmierer die Einhaltung der vorgegebenen Richtlinien, wie die einheitliche Namensgebung und Ordnerstruktur.
Nikolaus Risslegger
25
KAPITEL 3. UMSETZUNG
Für größere Projekte erleichtert sich der Aufwand enorm, da der
gesamte Konfigurationsaufwand wegfällt. Ein Beispiel ist die Verbindung zwischen Model und Datenbank, bzw. die einfache Datenbankverbindung, siehe Kapitel 3.2.1.
• Don’t repeat yourself: Dem Entwickler wird nahegelegt, dass
jedes Stück Wissen eine einzige, eindeutige und maßgebliche Re”
präsentation in einem System hat.“ [VH10]
Dadurch wird redundante Information vermieden und es gibt keine
Code-Duplikate, die Projekte sind einfacher und nur an einer Stelle zu modifizieren, falls es eine Änderung geben sollte. Mit Active
Records legt Rails die Attribute der Models durch das Auslesen
der Spalten der Datenbanktabellen fest. Die Informationen werden kein zweites Mal im Quellcode oder in einem config-Files definiert, somit werden Fehler durch inkonsistente Daten vermieden.
Die getter- und setter-Methoden erstellt Rails automatisch.
Aufbau
Die Hauptaufgabe, der Import und das Selektieren für die Ausgabe
der POI’s, wird im Event-Controller realisiert. Um den Zugriff auf die
Graph-API von Facebook zu vereinfachen, wird das RubyGem Koala
1.1015 verwendet.
RubyGems (kurz Gem) bezeichnet den offiziellen Paketmanager von Ruby und definiert dafür einen Standard. Es übernimmt die Administration
und Versionsverwaltung der eingebundenen Pakete und erleichtert dem
Programmierer die Arbeit mit externen Bibliotheken. Die Erweiterung
wurde im November 2003 entwickelt und ist nun Teil der Standard Bibliothek von ruby.
Wie das Listing 3.9 zeigt, erfolgt der Zugriff über das Gem Koala auf
das graph-Objekt über die globale Variable graph. Dieses Objekt erhält
über eine App-Permission mittels OAuth2 - siehe 3.1.2 alle benötigten
Berechtigungen.
Listing 3.9: Zugriff auf graph-API
Page . a l l . map do | page |
begin
e v e n t s = graph . g e t o b j e c t ( page . i d . t o s + ’ / e v e n t s ’ )
...
Das Codestück 3.10 zeigt das grundlegende Prinzip der Selektion und
Ausgabe. Es werden alle Events berücksichtigt, die im Umkreis der gegebenen Parameter liegen. Folgend dem Prinzip don’t repeat yourself
erfolgen die Berechnungen und Überprüfungen im Model: thin controller - thick model.
15
26
github.com/arsduo/koala
Nikolaus Risslegger
KAPITEL 3. UMSETZUNG
Listing 3.10: Eventselektion
e v e n t s = Event . a l l
e v e n t s = e v e n t s . s e l e c t { | ev |
ev . i n r a n g e ( param [ : l a t ] , param [ : l o n ] , params [ : r a d i u s ] )
ev . h a s c o o r d i n a t e s
}
end
respond with events
if
Als grundlegende Berechnung muss der Abstand der gegebenen Koordinaten und dem Event berechnet werden. Dafür wird das gem Geocoder16 verwendet. Das Plugin nutzt zur Berechnung der Entfernung die
Haversine-Formel.
Listing 3.11: Distanzberechnung
def d i s t a n c e t o ( l a t , l o n )
s t a r t = [ lat , lon ]
d e s t = [ s e l f . venue . l a t i t u d e , s e l f . venue . l o n g i t u d e ]
s e l f . d i s t a n c e = ( Geocoder : : C a l c u l a t i o n s . d i s t a n c e b e t w e e n (
s t a r t , d e s t ) ∗ 1 0 0 ) . round / 1 0 0 . 0
return s e l f . d i s t a n c e
end
Im folgenden Codestück 3.12 wird die Filterung der Veranstaltungen
gezeigt, wenn mehrere Koordinaten übergeben werden. Die Events werden selektiert, falls sie in mindestens einen Umkreis (der Radius wird
global übergeben) eines Koordinatenpaares fallen.
Die möglichen Aufrufsadressen werden in Kapitel 3.3.2 beschrieben.
Listing 3.12: Filterung der Eventdaten bei mehreren Koordinaten
i f event params [ : coords ] . present ?
e v e n t s = Event . a l l
e v e n t s . each do | ev |
ev . s e t c o o r d i n a t e s i f ev . h a s c o o r d i n a t e s
ev . d i s t a n c e t o ( e v e n t p a r a m s [ : l a t ] , e v e n t p a r a m s [ : l o n ] )
h a s c o o r d i n a t e s && p a r a m s c o o r d i n a t e s ?
end
i f ev .
myevents | | = Array . new
carray = event params [ : coords ] . s p l i t ( ” , ” )
c a r r a y . each do | cu |
c = cu . s p l i t ( ” : ” )
n e a r e v e n t s = e v e n t s . s e l e c t { | ev |
ev . i n r a n g e ( c [ 0 ] , c [ 1 ] , e v e n t p a r a m s [ : r a d i u s ] )
has coordinates
}
myevents . c o n c a t n e a r e v e n t s
end
r e s p o n d w i t h ( myevents )
16
i f ev .
www.rubygeocoder.com
Nikolaus Risslegger
27
KAPITEL 3. UMSETZUNG
3.3
REST-API
Web-Services beschreiben Schnittstellen zum Datenaustausch über das
World Wide Web und bieten ein neues Programmier- bzw. Systemparadigma zum Datenaustausch von verteilten Systemen. Alle Rechner agieren autonom und kommunizieren über festgelegte Standards (APIs).
Abbildung 3.6 visualisiert die einfache Grundstruktur: Clients senden
Servern Anfragen, die nach einiger Zeit (asynchron) die gewünschten
Informationen liefern.
Abbildung 3.6: Grundstruktur eines Webservices
Viele Web-Services arbeiten mit komplexen Protokollen wie SOAP (ursprünglich für Simple Object Access Protocol), um den Datenaustausch
zu vereinfachen. Die erwarteten Parameter bzw. die Rückgabetypen werden festgelgt, eine gewisse Typsicherheit ist vorhanden. SOAP ist ein
industrieller Standard des World Wide Web Consortiums (W3C).
Representational State Transfer (REST) definiert ein weiteres Programmierparadigma für verteilte Systeme, das einen einfachen Ansatz verwendet, sodass dessen Aufrufe leichtgewichtiger aufgebaut sind. Die Grundlagen werden in Kapitel 3.3.1 erläutert.
3.3.1
Grundlagen
Thomas Roy Fielding beschreibt im Jahr 2000 in seiner Dissertation
einen Architekturstil den er REpresentational Stae Transfer Archtetkur
oder kurz REST bezeichnet. Damit wird kein eigenes Protokoll oder
Standard für das Web-Service verwendet, sondern diese Denkweise versucht die Spezifikationen des World Wide Web zu verwenden.
Das Paradigma basiert auf dem Client-Server Modell, bei dem der Client auf Ressourcen, die der Server bereitstellt, über eine eindeutige URI
(Uniform Resource Identifier) zuzugreifen. Auch bei mehreren Anfragen
von verschiedenen Clients liefert eine URI immer denselben eindeutigen
Inhalt.
Typischerweise wird als Transportprotokoll HTTP (Hypertext Transport Protocol) verwendet und dessen Befehle genutzt: GET, POST,
PUT, DELETE und andere. Die bereitgestellten Daten sind beispielsweise Textdaten (JSON, XML, CSV) oder auch visuelle Ressourcen wie
28
Nikolaus Risslegger
KAPITEL 3. UMSETZUNG
Bilder und HTML-Seiten, somit ist theoretisch jede Homepage, die statische Inhalte anbietet REST-konform.
Die Zahlen der verwendeten Web-Service, welche auf REST basieren,
steigen stetig. Folgende Vorteile bietet die Architektur:
• Overhead: Ein Vorteil ist der geringe Overhead und die somit optimierte Ausnutzung der Bandbreite. SOAP stützt sich auf XML
zur Repräsentation der Daten und verwendet HTTP als Transportprotkoll (HTTP-POST requests). Um den Datenaustausch durchzuführen, werden im XML-Payload neben den Nutzdaten auch
noch Meta-Daten mitgesendet.
Im Gegensatz werden bei REST-Services keine Metadaten übertragen, da eine Adresse immer dieselbe Ressource liefert. Als Format für die Nutzdaten kann auch das wesentlich schlankere JSONFormat verwendet werden.
• Unabhängigkeit: Server und Client können auf unterschiedlichen Betriebssystemen arbeiten und in verschiedenen Programmiersprachen implementiert sein. Die Clients benötigen keine besondere Funktionalität, sondern müssen nur HTTP verstehen: damit vereinfacht sich der Zugriff von verschiedenen Plattformen
(mobile App, Dektop-Version bzw. Website) enorm. Bei Updates
oder Änderungen am Server muss der Client nicht sofort angepasst
werden.
• Durchsichtigkeit: Eine REST-Anfrage wird schon in den HTTPHeader definiert: GET requests greifen lesend auf die Ressourcen
zu, während POST, PUT und DELETE den Datenbestand ändern.
SOAP-Anfragen können Firewall-Administratoren vor Probleme
stellen, da in der Anfrage nicht direkt ersichtlich ist, ob die Daten
verändert werden.
• Status: Der Server kennt seinen Status und interessiert sich nicht
für die Sessions der Clients. Die Clients erledigen selbstständig
ihre Anfragen und legen die Reihenfolge, Parallelität etc. fest. Damit arbeiten beide Seiten eigenständig und müssen sich um keine
Synchronisation bemühen.
Die Nachteile treten bei komplexeren Systemen auf: REST folgt keiner
Standardisierung und jede URI auf einem Server kann unterschiedliche
Formate und Daten liefern, die Typ-Sicherheit ist nicht gegeben. Daraus
folgt eine geringe Effizienz, da der Informationsaustausch zwischen den
Schnittstellen nicht auf mögliche, spezielle Anforderungen der Komponenten eingehen kann.
Nikolaus Risslegger
29
KAPITEL 3. UMSETZUNG
3.3.2
Aufbau
Der Webserver ist nur lesend aufrufbar und unterstützt keine POST,
PUT oder DELETE-Requests. Die Daten werden automatisch mit einem
Cronjob17 aktualisiert.
Listenansichten
Für Listenansichten bzw. die Mapansicht werden die Events mit relativ
kleinen Datensatz übertragen, wie Listing 3.13 zeigt. Die Größe eines
Elements beträgt ca. 400-1000 Bytes.
Neben der Event-ID, dem Namen und des Zeitpunktes (Ende ist optional) werden die Koordinaten und auch die Luftlinie des Events zu
den übergebenen Koordinaten-Parametern geliefert, das eine Sortierung
nach Nähe ermöglicht. Weiter werden die Page-ID und Venue-ID mitgeliefert, um eventuell weitere Events des Anbieters abrufen zu können.
Listing 3.13: Aufbau eines Event-Entries
” id ” : 938705509484838 ,
” endTime ” : n u l l ,
” s t a r t T i m e ” : ” 2 0 1 5−0 8−2 7 1 9 : 0 0 : 0 0 ” ,
”name” : ”FERNWEH : : : HMBC” ,
” venue id ” : 135128885185 ,
” page id ” : 135128885185 ,
” l o c a t i o n ” : ” Treibhaus Innsbruck ” ,
” d i s t a n c e ” : 2 . 39 ,
” coords ” : {
” l a t i t u d e ” : 47 . 2676 ,
” l o n g i t u d e ” : 11 . 3965
}
Folgende Abfragen können an die API gestellt werden:
• Alle Events: Alle momentan vorhandenen Events werden über
die Adresse
/ api / event
abgerufen. Dabei werden auch die Daten mitgesandt, welche keine
Koordinatendaten besitzen. Das Attribut distance ist null.
• Radius: Um Veranstaltungen innerhalb eines bestimmten Gebietes zu erhalten, werden dem Service drei Parameter mitgeliefert:
lat (Latitude), lon (Longitude) und der radius. Der Aufruf
a p i / e v e n t ? l a t =47.2854551& l o n =11.3787899& r a d i u s =3
liefert alle Events in Innsbruck (laut Koordinaten) und dessen Umgebung von drei Kilometer.
17
In Unix-Systemen (wie das verwendete Server-Betriebssystem ubuntu) kann der
Cron-Daemon-Dienst wiederkehrende Aufgaben (cronjobs) automatisch zu bestimmten Zeiten automatisiert ausführen.
30
Nikolaus Risslegger
KAPITEL 3. UMSETZUNG
• Radien: Es besteht die Möglichkeit, der API mehrere Koordinaten in einem Aufruf zu übergeben. Dabei werden die Koordinaten
in folgender Form Lat:Lon,Lat,Lon,... geliefert. Der Radius ist für
alle Parameter derselbe und nicht für jedes Paar separat konfigurierbar. Ein Beispielsaufruf lautet:
/ a p i / e v e n t ? c o o r d s = 4 7 . 3 4 3 4 : 1 7 . 4 3 3 4 , 2 3 . 4 3 3 : 1 2 . 5 4 4 & r a d i u s =10
• Seite: Die Events einer Seite werden mithilfe der Page-ID geholt.
/ a p i / e v e n t ? page =135128885185
Detailansicht
In der erweiterten Ansicht werden zusätzlich noch die Beschreibung des
Events und die Veranstalter-Daten mitgeliefert. Die URI für eine Detailabfrage lautet:
/ a p i / e v e n t ? u i d =938705509484838
Die Daten enthalten unter Anderem detaillierte Angaben zu den Veranstalter, wie Listing 3.14 zeigt.
Listing 3.14: Detailansicht Event
” id ” : 938705509484838 ,
” description ” : ” Info ” ,
” endTime ” : n u l l ,
” s t a r t T i m e ” : ” 2 0 1 5−0 8−2 7 1 9 : 0 0 : 0 0 ” ,
”name” : ”FERNWEH : : : HMBC” ,
” venue id ” : 135128885185 ,
” page id ” : 135128885185 ,
” l o c a t i o n ” : ” Treibhaus Innsbruck ” ,
” coords ” : {
” l a t i t u d e ” : 47 . 2676 ,
” l o n g i t u d e ” : 11 . 3965
},
” venue ” : {
” id ” : 135128885185 ,
” c i t y ” : ” Innsbruck ” ,
” country ” : ” Austria ” ,
” l a t i t u d e ” : 47 . 2676 ,
” l o n g i t u d e ” : 11 . 3965 ,
” s t r e e t ” : ” A n g e r z e l l g a s s e 8” ,
” z i p ” : ”6020” ,
” c r e a t e d a t ” : ” 2 0 1 5−0 4−2 8T1 7 : 3 3 : 0 9 . 0 0 0Z” ,
” u p d a t e d a t ” : ” 2 0 1 5−0 4−2 8T1 7 : 3 3 : 0 9 . 0 0 0Z”
},
” page ” : {
” id ” : 135128885185 ,
” category ” : ” Arts / entertainment / n i g h t l i f e ” ,
”name” : ” T r e i b h a u s I n n s b r u c k ” ,
” about ” : ” Kulturprogramm f u e r S t a d t b e n u t z e r . ” ,
” l i n k ” : ” h t t p s : //www. f a c e b o o k . com/ t r e i b h a u s i b k ” ,
” username ” : ” t r e i b h a u s i b k ” ,
” c r e a t e d a t ” : ” 2 0 1 5−0 3−1 2T2 2 : 1 0 : 5 3 . 0 0 0Z” ,
” u p d a t e d a t ” : ” 2 0 1 5−0 3−1 2T2 2 : 1 0 : 5 3 . 0 0 0Z” 1
}
Nikolaus Risslegger
31
KAPITEL 3. UMSETZUNG
3.4
Event Visualisierung
Die Visualisierung der Daten kann in jedem Projekt und in beliebiger
Progammiersprache erfolgen, sofern diese die REST-Calls durchführen
kann. In dieser Arbeit ist der clientseitige Teil in die Arbeit von Nikolaus
Krismer eingebunden, welche den Titel isochrone-web18 trägt.
Die Arbeit verwendet verschiedene Algorithmen, um Isochrone zu berechnen. Mit den Daten von öffentlichen Verkehrsmitteln werden ausgehend von einem Startpunkt mögliche Ziele berechnet, die in gegebener
Zeit erreicht werden können. Diese Bereiche werden farblich hervorgehoben.
Als praktische Anwendung dieser Berechnungen werden die Eventdaten in das Projekt importiert und mit dessen Werten die Isochrone berechnet. Somit werden Einzugsgebiete der Veranstaltungen dargestellt.
Umgekehrt kann ein Benutzer der App die Veranstaltungen in seiner
unmittelbaren Nähe bestimmen, die er mit den öffentlichen Verkehrsmitteln erreichen kann.
Abbildung 3.7 zeigt das Ergebnis der Arbeit: In den grünen ClusterElementen sind gruppierte Veranstaltungen, um das Einzugsgebiet von
maximal 10 Minuten berechnet worden sind, dieses Gebiet ist blau hinterlegt. Dabei werden die örtlichen Bus-Verbindungen (Haltestellen werden in der Grafik orange dargestellt) berücksichtigt, aber auch der eventuell mögliche Fußweg, der die verwinkelten Enden des Isochrones hervorruft.
Details über die Funktionsweise der verwendeten Algorithmen zur Berechnung der Isochrone sind in der Arbeit [GBCI11] beschrieben.
In den folgenden Unterkapitel werden ausgewählte, relevante Spezifikationen näher beschrieben. Kapitel 3.4.1 beschreibt die technische Umsetzung, Kapitel 3.4.2 erklärt die Benutzung des Plugins.
3.4.1
Technische Grundlagen
Das System ist eine eigenständige Web-Anwendung und nutzt das Framework Node.js19 . Diese Technik basiert auf der JavaScript-Laufzeitumgebung V8, die eigentlich für den Browser Google Chrome (erste
Version 2009) entwickelt wurde. Die aktuelle Version 4.0.0 wurde am 8.
September 2015 veröffentlicht.
In Vergleich zu herkömmlichen Serverarchitekturen wie PHP/Ruby auf
einen Apache-Web-Server wird bei Node.js nicht für jede eintreffende
Anfrage ein neuer Thread gestartet. Es wird die asynchrone Architektur von JavaScript genützt, die eine parallele Verarbeitung von ClientVerbindungen und Datenbankzugriffen ermöglicht.
18
19
32
https://dbis-git.uibk.ac.at/krismer/isochrone-web
https://nodejs.org/
Nikolaus Risslegger
KAPITEL 3. UMSETZUNG
Abbildung 3.7: Visualisierung des Einzugsgebietes (max. zehn Minuten)
von ausgewählten Veranstaltungen
Diese Funktionsweise bringt große Performancevorteile bei mehreren Anfragen, ist ressourcenschonender und zeitgesteuerte Aktionen sind einfacher zu realisieren. Somit eignet sich Node.js für Web-Anwendungen,
die oft lange Berechnungen ausführen bzw. auf externe Ressourcen zugreifen, bevor sie einem Request antworten. [Bet14]
Mit der Verwendung von integrierten Modulen (vergleichbar mit Bibliotheken), welche grundlegende Funktionen für Netzwerkanwendungen bereitstellen, werden komplexe Anwedungen einfach realisiert: zum
Beispiel ermöglicht das HTTP-Modul das Hosten eines Webservers. Listing 3.15 zeigt den gesamten Codes eines HTTP-Servers, der mit einer
einfachen Response-Nachricht antwortet.
Listing 3.15: Node.js Web-Service
v a r h t t p = r e q u i r e ( ’ http ’ ) ;
var s e r v e r = http . c r e a t e S e r v e r ( f u n c t i o n ( req , r e s ) {
r e s . writeHead ( 2 0 0 , { ’ Content−Type ’ : ’ t e x t / p l a i n ’ } ) ;
r e s . end ( ’ H a l l o ! ’ ) ;
} ) . l i s t e n ( 8080 ) ;
Als Web-Mapper wird leaflet20 verwendet, ein OpenSource Projekt, welches durch ein Node.Js Modul im Projekt verankert ist. Leaflet bietet
ebenfalls zahlreiche Plugins an, die in der Arbeit verwendet werden. Für
die übersichtliche Darstellung der zahlreichen Veranstaltungen wird das
20
leafletjs.com/
Nikolaus Risslegger
33
KAPITEL 3. UMSETZUNG
Marker-Cluster Plugin benutzt, welches Marker in der Landkarte gruppiert und zu einem Cluster (siehe Abbildung 3.7) zusammenfasst, wenn
zu viele Marker auf kleinen Raum vorhanden sind.
Um den umfangreichen Build-Prozess und die Modulverwaltung zu vereinfachen, werden die Tools bower21 und gradle22 verwendet.
Event-Plugin
Das implementierte Plugin besteht aus zwei javascript-Dateien und einigen Stubs in diversen Files des isochrone-web Projektes. Die Datei
Event.js beinhaltet die Klasse Event mit ihren Membervariablen und
den dazugehörigen getter-Methoden. Der Konstruktor legt das Objekt
an, setzt das standardmäßige Icon und generiert einen leaflet-Marker,
der das Clustering ermöglicht, siehe Listing 3.16. Hier wird auch das
Popup-Element angelegt, welches nach Klick auf den Marker erscheint.
Um das Event als Start- oder Endpunkt bei der Isochronen-Berechnung
zu verwenden, ist eine Setter-Methode implementiert, die dem EventObjekt zusätzlich ein farblich unterschiedliches Icon zuweist.
Listing 3.16: Initialisierung Eventobjekt
f u n c t i o n i n i t E v e n t ( data ) {
name = data . name ;
i d = data . i d ;
s t a r t T i m e = data . s t a r t T i m e ;
endTime = data . endTime ;
c o o r d i n a t e s = L . l a t L n g ( [ data . c o o r d s . l a t i t u d e , data . c o o r d s .
longitude ] ) ;
icon = L . icon ({
i c o n U r l : ’ images / i c o n g r e e n . png ’
}) ;
marker = L . marker ( c o o r d i n a t e s , {
t i t l e : data . name ,
icon :
icon
}) ;
c o n t a i n e r = $ ( ’<d i v /> ’ ) ;
c o n t a i n e r . html ( ’<h3> ’+name+ ’</h3> ’ ) ;
i f ( startTime ) {
c o n t a i n e r . append ( ’<p> ’+ $ . t ( ’ e v e n t . s t a r t ’ ) +
’ : <b> ’ + s t a r t T i m e + ’</b></p> ’ ) ;
}
i f ( endTime ) {
c o n t a i n e r . append ( ’<p> ’+ $ . t ( ’ e v e n t . s t o p ’ ) +
’ : <b> ’ + endTime + ’</b></p> ’ ) ;
}
v a r popup = L . popup ( ) . s e t C o n t e n t ( c o n t a i n e r [ 0 ] ) ;
marker . bindPopup ( popup ) ;
}
21
22
34
bower.io/
https://gradle.org/
Nikolaus Risslegger
KAPITEL 3. UMSETZUNG
Der Zugriff auf das Webservice und die Verwaltung der Veranstaltungen wird mit der Klasse eventService realisiert. Zur Vereinfachung der
API-Calls wird das Node.js-Modul superagent23 eingebunden und dessen Funktionalitäten genutzt. Dieses Modul und dessen Aufrufe stellt die
einzige Schnittstelle zwischen dem entwickelten Server und dem Client
dar.
Ein Zugriff auf die REST-API, um die Event-Daten zu laden und die
Erstellung der Event-Objekte zeigt Listing 3.17. Vor dem Anlegen eines
Event-Objektes werden am Client die Daten überprüft, da unsinnige
Daten nicht ausgeschlossen werden dürfen. Bei Fehlschlagen des Aufrufes (Server überlastet oder nicht erreichbar) wird der Aufruf zu einem
späteren Zeitpunkt erneut gestartet.
Listing 3.17: Laden der Eventdaten
request
. g e t ( addr )
. end ( f u n c t i o n ( r e s ) {
i f ( r e s . ok ) {
r e s . body . f o r E a c h ( f u n c t i o n ( e ) {
i f ( EventService . validCoords ( e ) ) {
e v e n t s . push (new Event ( e ) ) ;
}
}) ;
l o g g e r . debug ( ” f i n i s h e d g e t t i n g e v e t n s ” ) ;
if ( callback ) {
c a l l b a c k ( events , getEventMarkers ( ) ) ;
}
} else {
l o g g e r . e r r o r ( ” an e r r o r o c c u r e d f e t c h i n g e v e n t d a t a ” ) ;
setTimeout ( fetchEvents ( l a t l n g , radius , c a l l b a c k ) ,
reconnectInterval ) ;
}
}) ;
Die Darstellung der Events auf der Map wird durch eine layer realisiert,
eine Kernfunktion von leaflet. Somit ist das Hinzufügen und Löschen
trivial (Listing 3.18).
Listing 3.18: Interaktion Events/Map
this . c l e a r = function ( ) {
map . removeLayer ( ” e v e n t d a t a ” ) ;
events . s p l i c e (0 , events . length ) ;
};
t h i s . showEvents = f u n c t i o n ( ) {
map . addLayer ( g e t E v e n t M a r k e r s ( ) , ” e v e n t d a t a ” , true ) ;
};
Weitere Infomationen können aus dem Sourcecode im Anhang entnommen werden.
23
https://visionmedia.github.io/superagent
Nikolaus Risslegger
35
KAPITEL 3. UMSETZUNG
3.4.2
Bedienung
Die Bedienung des Plugins ist auf das Benutzen mit üblichen Eingabegeräten wie Maus oder Touchpad/Touchscreen ausgelegt, eine reine Tastaturbedienung ist nicht implementiert. Die Event-Erweiterung
schränkt die Ansicht und Bedienung des gesamten Systems nicht ein,
es existiert lediglich ein kleines Kalender-Symbol im rechten oberen Eck
der Map, die auf die Erweiterung hinweist. Nach dessen Klick öffnet sich
ein Dialogfenster und bietet dem Benutzer die Möglichkeit zur Vorselektierung der Events:
• All: Es werden alle zur Verfügung stehenden Veranstaltungsdaten
geladen und angezeigt.
• Mapcenter: Alle Eventdaten im gegebenen Umkreis (zweites Eingabefeld) der aktuellen Map-Ansicht werden geladen. Dabei werden dem Server die Koordinaten der Karte übermittelt, der Radius
kann in einem separaten Auswahlfeld definiert werden.
• Dataset: Der Benutzer wählt mittels einer Select-Box (drittes Inputfeld) eine der geladenen Datensätze aus, von dem IsochronBerechnungen möglich sind.
Nach der Auswahl werden die Daten on-the-fly in die Selectbox Available Events geladen. Das kann durch die gewählte Datengröße und der
vorhandenen Internetverbindung einige Sekunden in Anspruch nehmen.
Gewünschte Events werden ausgewählt und in die Selectbox Selected
Events hinzugefügt, diese Veranstaltungen werden für die IsochronenBerechnungen berücksichtigt. In der Kartenansicht werden alle gefundenen Veranstaltungen angezeigt, wobei die Marker der ausgewählten
orange sind, alle anderen grün.
Abbildung 3.8 zeigt die Veranstaltungen im Raum Bozen an, dabei werden 4 Stück für die Isochronen-Berechnung herangezogen.
Durch einen Doppelklick auf ein Event oder Klick auf den Button Details
werden erweitertete Veranstaltungsinformationen angezeigt. Im Hintergrund wird ein weiterer REST-Call an den Server gesendet, um diese
Details (Technische Infos siehe Kapitel 3.3.2) zu erhalten.
Die Berechnung kann in der Hauptansicht durch den Klick auf den Button isochrone und anschließender Bestimmung der maximalen Entfernung gestartet werden, die Checkbox Event-Isochrone muss gewählt
sein, um die selektierten Event-Punkte als Startpunkte verwenden zu
können. Das System akzeptiert mehrere Koordinaten-Paare zur Bestimmung der Isochrone.
Abbildung 3.9 zeigt die farblich unterschiedlichen Marker, wobei nur der
gelbe für die Isochron-Berechnung herangezogen wird (in diesem Fall trivial, da alle Marker die selben Koordinaten haben).
36
Nikolaus Risslegger
KAPITEL 3. UMSETZUNG
Abbildung 3.8: Wahl von Dataset bz liefert 17 Events aus Bozen.
Abbildung 3.7 zeigt das Ergebnis einer Berechnung, der blau hinterlegte
Bereich ist im angegebenen Zeitrahmen erreichbar, dabei werden drei
Eventstandpunkte (die Marker sind geclustert) verwendet. Erkennbar
ist dies durch den separaten Bereich im Südosten, der das Gebiet für die
6 Events berechnet.
Abbildung 3.9: Detailansicht Isochrone-Berechnung des ausgewählten
Events
Nikolaus Risslegger
37
Kapitel 4
Ausblick
Ziel dieser Arbeit war es, eine einfache Anwendung zu entwickeln, die
eine praktische Verwendung der Isochronen-Berechnung zeigt und dabei die Möglichkeiten verschiedener APIs ausnützt und diese zusammenführt. Hervorzuheben ist die einfache Verwendung und ausgereifte
Dokumentation der Facebook-API (wobei andere APIs ähnlich simpel
zu bedienen sind) und die relativ kurze Supportzeit selbiger (die verwendete API ist ab 2016 als veraltet eingestuft). Auch die Integrierung
von bestehenden Plugins und Bibliotheken (ruby on rails oder leaflet)
ist einfach zu vollziehen, da die Mächtigkeit dieser modernen Programmiersprache durch viele Benutzerplugins steigt.
Es wird gezeigt, dass die web-mapping Technologien noch stark erweiterbar sind und weitere Informationen bereitgestellt werden können (Veranstaltungen und öffentliche Verkehrsmittel): Heute gibt es in Österreich
noch keine Kartenansicht, die mit allen öffentlichen Verkehrsbetrieben
interagiert. Das liegt aber vorwiegend daran, dass staatsnahe Betriebe
(nicht nur in Österreich) auf die Bereitstellung ihrer Daten über eine offene und standardisierte Plattform verzichten. Somit erschweren sie die
Erstellung von solchen interessanten Apps.
Die Bereitstellung von Event-Daten ist ähnlich ernüchternd, bis dato
gibt es keinen Anbieter einer großen Event-Plattform. Es versuchen
sich kleine Anbieter am Markt zu positionieren und stellen ihre Veranstaltungen für den Benutzer zur Verfügung, auf eine Bereitstellung
der Daten über eine standardisierte Form wird größtenteils verzichtet.
Verständlicherweise, denn damit könnte man Besucherverluste verzeichnen, da die Benutzer eine größere Plattform für die Eventsuche nutzen
könnten. Ein interessanter Ansatz ist die Darstellung der Veranstaltungen mit dem Meta-Event-Tag (siehe Listing 3.1).
Ein Ausbau der Applikation ist relativ einfach möglich, da das Tool modular aufgebaut ist. Folgende Features können verbessert bzw. weiter
38
APPENDIX
ausgebaut werden:
• Erweiterung der Event-Quellen: Die Einbindung von Seiten,
welche das Event-Meta-Tag verwenden.
Dabei wird auf ein Crawlen des Netzes, wie Google es praktiziert,
verzichtet, da die Serverleistung dafür keinesfalls ausreicht. Wie die
IDs der Veranstalter-Pages aus Facebook werden die URIs manuell
am Server registriert.
• Zeitbasierte Suche: Ein API-Call mit Zeitangaben ermöglicht
die Anzeige aktueller Events bzw. zu einem bestimmten Zeitpunkt.
• Beliebteste Events: Anlegen einer Statistik, welche die Views
der einzelnen Events protokolliert. Anschließend kann ein API-Call
die beliebtesten Events liefern.
• Clientseitige Listenansicht: Am Client könnte neben den Markern eine optionale, sortierbare Tabelle der Events direkt in der
Map angezeigt werden.
Generell zeigt das App nur einen Lösungsvorschlag für das gegebene
Problem und ist als Prototyp dieser Art zu sehen.
Nikolaus Risslegger
39
Abbildungsverzeichnis
2.1
2.2
2.3
2.4
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
Klassifikation von Mashups, Mashups und weborientierte
Architekturen als Technologie-Trends des Web 2.0, Nils
Hommen, 2007, Seite 109 . . . . . . . . . . . . . . . . . . 5
Screenshot von www.programmableweb.com/api-research,
aufgenommen am 2015-09-12 . . . . . . . . . . . . . . . . 6
Screenshot von https://goo.gl/maps/qt2sJHRfR2U2, aufgenommen am 2015-10-06 . . . . . . . . . . . . . . . . . . 9
Screenshot von https://goo.gl/maps/GsMSMv1Tdp52, aufgerufen am 2015-10-06 . . . . . . . . . . . . . . . . . . . . 10
Eigene Illustration . . . . . . . . . . . . . . . . . . . . . .
Screenshot von https://goo.gl/MTQYiY, aufgerufen 201510-06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Screenshot facebook.com, aufgerufen 2015-09-10 . . . . . .
Funktionsweise OAuth, The OAuth 2.0 authorization framework, Dick Hardt, 2012, Seite 6 . . . . . . . . . . . . .
Eigene Illustration . . . . . . . . . . . . . . . . . . . . . .
Eigene Illustration . . . . . . . . . . . . . . . . . . . . . .
Screenshot isochrone-web, aufgenommen am 2015-09-12 .
Screenshot isochrone-web, aufgenommen am 2015-09-12 .
Screenshot isochrone-web, aufgenommen am 2015-09-12 .
41
13
15
17
20
25
28
33
37
37
Literaturverzeichnis
[Bai13]
A. Baio: The Death of Upcoming.org, Website, 2013,
URL
http://waxy.org/2013/04/the_death_of_
upcomingorg/, vistited 2015-07-19.
[Bal14]
R. Baldwin: Andy Baio crowdfunds $30,000 in 90 minutes
to relaunch community event site Upcoming, Website, 2014,
URL http://goo.gl/70ifM4, vistited 2015-07-19.
[Bet14]
D. Betz: Generisches Mehrbenutzer-Framework auf Basis von Node. js und Webtechnologien am Beispiel eines
Stundenplan-Gestalters, (2014), pages 40–44.
[BK07]
M. Bächle and P. Kirchberg: Ruby on Rails., IEEE Software,
volume 24(6), (2007), pages 105–108.
[Boy12]
R. Boyd: Getting started with OAuth 2.0, O’Reilly Media,
Inc., 2012.
[GBCI11]
J. Gamper, M. Böhlen, W. Cometti and M. Innerebner:
Defining isochrones in multimodal spatial networks, Proceedings of the 20th ACM international conference on Information and knowledge management, ACM, pages 2381–
2384.
[Har12]
D. Hardt: The OAuth 2.0 authorization framework, Internet
Engineering Task Force, 2012, URL http://tools.ietf.
org/html/rfc6749.html.
[HGM94]
G. Hake, D. Grünreich and L. Meng: Kartographie: Visualisierung raum-zeitlicher Informationen, Walter de Gruyter,
1994.
[HL10]
E. Hammer-Lahav: The oauth 1.0 protocol, Internet Engineering Task Force, 2010, URL https://tools.ietf.org/
html/rfc5849.
[Hom07]
N. Hommen: Mashups und weborientierte Architekturen als
Technologie-Trends des Web 2.0, volume 2, pages 103–120.
43
APPENDIX LITERATURVERZEICHNIS
[HSP08]
M. Haklay, A. Singleton and C. Parker: Web mapping 2.0:
The neogeography of the GeoWeb, Geography Compass, volume 2(6), (2008), pages 2011–2039.
[Ker06]
M. Kerres: Potenziale von Web 2.0 nutzen, A. Hohenstein
(ed.), Handbuch E-Learning, Deutscher Wirtschaftsdienst,
München, 2006, pages 1–3.
[KHW08]
T. Kilian, B. H. Hass and G. Walsh: Grundlagen des Web
2.0, Web 2.0, Springer, 2008, pages 3–21.
[MG09]
P. Mell and T. Grance: Effectively and securely using the
cloud computing paradigm, NIST, Information Technology
Laboratory, pages 304–311.
[MWDT07] E. M. Maximilien, H. Wilkinson, N. Desai and S. Tai: A
domain-specific language for web apis and services mashups,
Springer, 2007.
[Put94]
S. Putz: Interactive information services using World-Wide
Web hypertext, Computer Networks and ISDN Systems, volume 27(2), (1994), pages 273–280.
[RB10]
B. Rubinger and T. Bultan: Contracting the facebook API,
arXiv preprint arXiv:1009.3715.
[RSHM08] J. Richardson, K. Schlegel, B. Hostmann and N. McMurchy:
Magic quadrant for business intelligence platforms, Core research note G, volume 154227.
[Ste08]
D. Stenmark: Web 2.0 in the business environment: The
new intranet or a passing hype?, ECIS, volume 2008, pages
2064–2075.
[TMF10]
R. Troncy, B. Malocha and A. T. Fialho: Linking events
with media, Proceedings of the 6th International Conference
on Semantic Systems, ACM, page 42.
[VH10]
G. Vossen and S. Hagemann: Unleashing Web 2.0: From
concepts to creativity, Elsevier, 2010.
[ZZ11]
D. Zarrella and A. Zarrella: Das Facebook-Marketing-Buch,
O’Reilly Germany, 2011.
44
Nikolaus Risslegger