Bericht - Persönliche Webseiten der Informatik

Projektbericht
Ruben Schempp
Maps on Rails
Fakultät Technik und Informatik
Department Informatik
Faculty of Engineering and Computer Science
Department of Computer Science
I
Ruben Schempp
Maps on Rails
Ausarbeitung eingereicht im Rahmen der Veranstaltung Projekt
im Wintersemester 2007/2008
im Studiengang Master of Science Informatik
am Department Informatik
der Fakultät Technik und Informatik
der Hochschule für Angewandte Wissenschaften Hamburg
Betreuender Prüfer: Prof. Dr. Kai von Luck
Abgegeben am 28. Februar 2008
Inhaltsverzeichnis
II
Inhaltsverzeichnis
1 Einführung
1.1 Arbeitsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
2 Vision
2.1 Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
2
3
3 Evaluierung
3.1 Kartendienst . . . . . . . .
3.2 Ruby on Rails . . . . . . .
3.3 Google Maps on Rails . . .
3.3.1 Yellow Maps for Ruby
3.4 JavaScript . . . . . . . . .
3.5 Google vs. Yahoo! Maps . .
3.6 Aktualisierungsstrategie . .
3.7 Yahoo! Maps on Rails . . .
3.7.1 Rails Helper . . . . .
3.8 Web-Browser . . . . . . . .
.
.
.
.
.
.
.
.
.
.
4
4
5
5
6
7
7
8
10
12
12
4 Wirtschaftskontakte
4.1 Geoinformationsysteme der Stadt Hamburg . . . . . . . . . . . . . . . . . .
4.2 UbiLabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13
14
5 Zusammenfassung
5.1 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
15
16
Literaturverzeichnis
17
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Abbildungsverzeichnis
III
Abbildungsverzeichnis
3.1 (Google) Maps on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 (Yahoo!) Maps on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
11
4.1 OpenLayers
14
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 Einführung
1
1 Einführung
In diesem Bericht werden die Erfahrungen und Ergebnisse des Projekts vorgestellt. Das Projekt schließt an die Vorarbeiten des vergangenen Semesters in Anwendungen I [Schempp,
2007] an. Es wurde parallel zu den Arbeiten Anwendungen II [Schempp, 2008a] und Seminar
[Schempp, 2008b] durchgeführt. In den drei erwähnten Arbeiten werden die Vorbereitungen
auf die Masterarbeit beschrieben. Es wird eine Anwendung namens Maps on Rails an Hand
eines Szenarios (Einsatzleitstelle) beschrieben.
Ziel der Projektarbeit war ein erstes praktisches Herangehen an die Aufgabenstellung zu
ermöglichen, um so zu sehen, welche Möglichkeiten und vor allem welche Probleme bei der
Umsetzung der Anwendung auftreten. Für Maps on Rails war zu allererst zu prüfen, ob sich
die Anforderungen des Szenarios auch tatsächlich mit der favorisierten Technik umsetzen
lassen.
1.1 Arbeitsumgebung
Die Programmierung der prototypischen Versuche und Anwendung erfolgte in Ruby mit dem
Framework Ruby on Rails. Wo nötig, wurden auch HTML, CSS und JavaScript eingesetzt.
Als Datenbank kam SQLite (mit einem Plugin für Rails) zum Einsatz. Der in Rails integrierte
Webrick-Server wurde ebenfalls verwendet. Auf dem Client kam i.d.R. der Firefox Browser
zum Einsatz. Die Programmierung erfolgte unter MacOS 10.5 mit dem Editor TextWrangler.
Die Verwendung von Locomotive als Rails-Werkzeug für MacOS ist nicht unbedingt empfehlenswert, solange es mit der bereits in MacOS installierten Ruby-Version und mit dem
Umgang auf der Kommandozeile keine Probleme gibt.
Als Verbesserung kann die Entwicklungsumgebung Eclipse oder auch Aptana Studio eingesetzt werden. Aptana Studio1 ist eine von Eclipse abstammende, aber speziell auf WebEntwicklung spezialisierte IDE, die eine Ruby on Rails Unterstützung bietet. Eine kostenpflichtige Alternative stellt auch die Entwicklungsumgebung IntelliJ IDEA2 dar.
1
2
Siehe: http://www.aptana.com/studio
Siehe: http://www.jetbrains.com/idea
2 Vision
2
2 Vision
Die Vision des Projekts besteht in einer ersten prototypischen Umsetzung des Szenarios.
Letztlich soll die Anwendung Maps on Rails auf einem Großbildschirm eines Leitstands einsetzbar sein. Die Nutzung des Kartenmaterials von Google Maps und der Einsatz von Ruby
on Rails ist ebenfalls vorgesehen. Die Anwendung soll zudem im Browser lauffähig sein, um
so auf mehreren Geräten und Plattformen einsatzfähig zu sein. Zur Bedienung sind langfristig bessere Eingabekonzepte als Maus und Tastatur wünschenswert. Hier gibt es mit der
Multitouch-Technologie und dem Eye- und Motiontracker weiterführende Möglichkeiten.
2.1 Szenario
Das Szenario wurde bereits in den drei eingangs erwähnten Ausarbeitungen vorgestellt.
Es beschreibt ein Mehrbenutzersystem auf Kartenbasis als Rich Internet Application. Diese Web-Anwendung soll allen Teilnehmern ortsbezogene Informationen möglichst zeitnah
präsentieren. Mit ortsbezogenen Informationen sind in diesem Szenario in erster Linie Positionsangaben (von Menschen oder Fahrzeugen) gemeint. Auf Seite der Teilnehmer soll, beim
Einsatz unterschiedlicher Endgeräte, nicht mehr als ein Web-Browser von Nöten sein.
2.2 Ziele
Mit Blick auf die Vision ist das Ziel in erster Linie die Evaluation der für Maps on Rails benötigten Techniken im praktischen Einsatz. Dies betrifft vor allem Ruby on Rails und die
(Bibliotheken der) Kartendienste Yahoo! Maps [Yahoo! Inc., 2008] und Google Maps [Google
Inc., 2007b]. Nach Möglichkeit soll bis zum Ende des Projekts ein aussagekräftiger Prototyp
erstellt werden. An diesem soll beurteilt werden, ob und wie eine Integration eines Kartendienstes in einer Ruby on Rails Anwendung gelingen kann.
2 Vision
3
2.3 Vorgehensweise
Zu aller erst soll die zum Arbeiten in der Hochschule für Angewandte Wissenschaften Hamburg nötige Infrastruktur geschaffen werden. Als nächstes soll der Kartendienst Google Maps
untersucht werden, um die Möglichkeiten und Grenzen seiner Fähigkeiten in Bezug auf das
Szenario zu bewerten. Der folgende Schritt soll das Erkunden von Ruby on Rails und dessen
Konzepten sein, sodass eine Integration des Kartendienstes erfolgen kann.
3 Evaluierung
4
3 Evaluierung
Dieses Kapitel berichtet über die Eignung von und Erfahrungen mit verschiedenen Komponenten, die im Projekt eingesetzt bzw. behandelt wurden. Die Programmiersprache Ruby
wird hier nicht erneut behandelt, stattdessen wird auf [Schempp, 2006] verwiesen. Als gutes
Nachschlagewerk für Ruby hat sich [Thomas u. a., 2005] erwiesen.
Auf die Vorstellung der Komponenten wird hier ebenfalls verzichtet, sofern diese im Rahmen
der eingangs erwähnten Ausarbeitungen bereits vorgestellt worden sind. Die Behandlung
der Themen der folgenden Unterkapitel erfolgt chronologisch analog zur Bearbeitungsreihenfolge im Projekt.
3.1 Kartendienst
Kartendienste gibt es inzwischen verhältnismäßig viele. Doch nur wenige bieten eine API
an. Zwei auf den ersten Blick geeignet erscheinende Kartendienste, die auch schon in
vielen Mashups genutzt wurden, sind Yahoo! und Google Maps. Beide bieten JavaScriptBibliotheken, die sich nicht großartig voneinander unterscheiden, für die Einbindung in die
eigene Webseite an.
Für das weitere Vorgehen wurde Google Maps gewählt. Mit Google Maps lassen sich Marker auf der Karte positionieren, die ein Informationsfenster öffnen können. Diese Marker
lassen sich bewegen und löschen. Wichtig zu erwähnen ist, dass die Ortsinformationen für
die angezeigten Marker nicht bei Google, sondern in der eigenen Anwendung bzw. Webseite
verbleiben. Dieser Punkt war eine der erforderlichen Voraussetzungen für das Szenario. Die
bereits durch den Google Maps Dienst [Google Inc., 2007a] im Internet bekannte GeocodingFunktion (Ortssuche), wird ebenfalls von der API angeboten. Google Maps war nach dieser
ersten Einschätzung für die Darstellung der Informationen gut geeignet.
Bei ersten Tests stellte sich schnell heraus, dass die API Dokumentation von Google Maps
an einigen Stellen Fehler aufweist. Glücklicherweise existieren für viele Funktionen Codebeispiele, an denen man sich orientieren kann.
3 Evaluierung
5
3.2 Ruby on Rails
Für eine Einführung in Ruby on Rails ist das Buch „Agile Web-Development with Rails“
[Thomas und Hannson, 2006] zu empfehlen, das in die Strukturen von Rails einführt. Es
behandelt auch Themenbereiche wie das Testen der Anwendung, auf das im Projekt aus
Zeitgründen verzichtet wird. An Hand der Beispiele dieses Buches war es möglich, sich mit
den grundlegenden Konzepten von Rails vertraut zu machen. Erwähnenswert sind etwa die
„Migrations“, ein Konzept zum Generieren der SQL Data Definition Language. Mit datenbankunabhängigem Ruby-Code kann so das Datenbankschema beschrieben werden, aus dem
dann (angepasst an das jeweilige Datenbanksystem) der SQL-Code erzeugt wird, der die
Tabellen definiert. Auch Änderungen am Datenbankschema werden unterstützt. Ferner gibt
es eine Versionierung des Schemas, das eine Migration sowohl rückwärts als auch vorwärts
erlaubt.
Durch das Active Record Framework zur Datenbankanbindung erhält man nach der Definition einer Tabelle automatisch Zugriff auf entsprechende Objekte, die jeweils in einer Zeile
der Tabelle gespeichert sind. Konstruktoren und Zugriffsmethoden werden dabei gleich mit
erstellt. Dank der Namenskonventionen von Active Record wird aus dem Tabellennamen der
Klassenname erzeugt, sodass die Klasse direkt genutzt und erweitert werden kann. Active
Record unterstützt auch Transaktionen.
Rails bringt für die Programmierung von Webseiten mit dynamischem Inhalt eine integrierte Unterstützung der AJAX-Technologie mit, um HTML-Templates für die View (der
MVC-Architektur) zu erstellen. Dort können Aktionen für Ereignisse vorgesehen werden,
die JavaScript-Code ausführen. Als Unterstützung für die JavaScript-Programmierung bringt
Rails das Prototype-Framework1 mit.
3.3 Google Maps on Rails
Hilfestellung bei den ersten Schritten der Integration von Google Maps in eine Ruby on Rails
Anwendung sowie einige Anregungen für die Benutzeroberfläche gibt das Buch „Google
Maps Applications with Rails and Ajax“ [Lewis, 2007].
Die Einbindung einer Google Maps Karte in eine Ruby on Rails Anwendung ist grundsätzlich
kein Problem. Bestimmte Funktionen wie das Zoomen oder das Verschieben des Kartenausschnitts stehen sofort zur Verfügung. Abbildung 3.1 zeigt diesen frühen Zustand einer
Anwendung, bei der nur ein paar Bedienknöpfe auf der Karte vorhanden sind. Im Grunde
genommen hat die Karte aber noch nichts mit der tatsächlichen Anwendung zu tun, außer
1
Siehe: http://www.prototypejs.org/
3 Evaluierung
6
Abbildung 3.1: Eine einfache Google Maps Karte. [Google Inc., 2007a]
dass der Kartenausschnitt auf der Webseite dargestellt wird. Noch gibt es z.B. keine Informationen auf der Karte.
Um Marker2 auf einer Karte anzuzeigen, bedarf es einiger JavaScript-Anweisungen. Diese
Anweisungen können entweder statischer – und das wäre für eine interaktive Anwendung
ein schlechter Ansatz – oder dynamischer Art sein. Dynamisch bedeutet in diesem Fall, dass
der JavaScript Code zur Laufzeit der Anwendung durch Auslösung eines Ereignisses vom
Server an den Client geschickt wird, um einen Marker anzuzeigen. Ein Spezialfall davon wäre
die Erzeugung eines Markers durch den Benutzer. An dieser Stelle kommt RJS (Remote
JavaScript) zum Einsatz: Statt als Antwort auf eine Anfrage des Clients ein (fertiges) Stück
HTML zurückzuschicken, wird nun eine JavaScript-Vorlage aufgerufen und an den Client
gesendet.
3.3.1 Yellow Maps for Ruby
YM4R3 ist ein Plugin für Ruby on Rails, das eine kleine API für bestimmte Aktionen wie das
Geocoding mitbringt. Mit der YM4R/GM4 Erweiterung steht eine Ruby-Bibliothek für Rails
zur Verfügung. Diese ist nicht ganz vollständig implementiert, ermöglicht aber eine gut strukturierte Ansteuerung und Programmierung der Google Maps Karte.
2
Im Folgenden werden Marker, als einfachster Typ von Informationen, stellvertretend für alle darstellbaren
Informationstypen behandelt.
3
Yellow Maps for Ruby [Vellut, 2007a]
4
Yellow Maps for Ruby, Google Maps Plugin for Rails [Vellut, 2007b]
3 Evaluierung
7
Es können nun in Ruby Objekte erzeugt werden, die einen Marker in der Google Maps
Karte repräsentieren. Die Eigenschaften können etwa aus der Datenbank gelesen werden.
Der eigentliche Marker wird aber weiterhin durch JavaScript erzeugt. Dieses kann etwa zur
Laufzeit durch den YM4R/GM Plugin erzeugt werden und mit der RJS-Technik an den Client
gesandt werden, der daraufhin den Marker darstellt.
Leider ist die Implementierung von Y4MR/GM nicht ganz vollständig und sehr stark an
der Bibliothek von Google Maps orientiert. Dies führt dazu, dass man doch immer wieder
JavaScript-Code selbst schreiben muss. Man bekommt so zum Preis eines „hybriden Ansatzes“ einen schnellen Start in der Anwendungsentwicklung mit Google Maps geboten.
3.4 JavaScript
Die Programmierung in JavaScript ist ein Thema für sich, das hier nicht in der Tiefe behandelt
werden soll. Mit der objektorientierten und systematischen Programmierung in Sprachen wie
Smalltalk oder Ruby hat sie nicht viel gemein. In JavaScript selbst ist ohne die Verwendung
von weiteren Frameworks nicht besonders viel zu erreichen bzw. nur auf Umwegen. Jedoch
ist JavaScript der einzige Weg ohne zusätzliche Browser-Plugins Programmcode zu schreiben, der in unterschiedlichen Browsern läuft. (Auch wenn es an dieser Stelle durchaus unterschiedliche Interpretationen des Codes durch die Browser gibt.) Durch JavaScript lässt sich
die Bibliothek von Google Maps und auch die AJAX-Technologie für die Web-Anwendung
nutzen. Ruby on Rails bietet hier durch seine JavaScriptHelper Klassenbibliothek eine gute
Hilfestellung bei der Programmierung.
3.5 Google vs. Yahoo! Maps
An die Grenzen von Google Maps stößt man, wenn man die Position der Marker per JavaScript verändern möchte. Dies funktioniert in der Benutzeroberfläche per Hand gut. Jedoch
gibt es darüber hinaus keine Möglichkeit die einmal gesetzten Eigenschaften eines Markers
zu ändern. Der einzige Ausweg ist das Löschen und das anschließende neue Erstellen eines Markers. Dabei müssen allerdings alle EventListener, die zu einem Marker gehören, mit
gelöscht werden, um so alle Referenzen auf gelöschte Marker zu vernichten. Einen Schritt
weiter gedacht, stellt man dann fest, dass ein Marker und dessen Referenz nur auf dem
Client existieren, sodass man keine Möglichkeit hat, ihn direkt vom Server aus zu löschen.
Das ist nicht einmal möglich, wenn man die Referenz des Markers hätte, da diese auf jedem
weiteren Client einen anderen Wert besitzt.
3 Evaluierung
8
Google Maps erlaubt es an dieser Stelle nicht einen einmal gesetzten Marker zu ändern bzw.
zu löschen. Zwei Auswege gibt es jedoch. Die Erste wäre das Löschen aller Marker und das
anschließende neue Erstellen aller Marker, was jedoch äußerst unzufriedenstellend ist. Die
Zweite wäre ein Framework in JavaScript, das einem Objekt bzw. Marker einen eindeutigen
Bezeichner zuordnet. So kann der Server dem Framework auf der Clientseite den ObjektBezeichner und die jeweilige Nachricht übergeben, die dann lokal auf jedem Client umgesetzt wird. Doch auch diese Lösung ist im Rahmen des Projekts keine zufriedenstellende
Lösung, da sie mit einem zu großen Aufwand verbunden ist und in JavaScript durchgeführt
werden muss.
Hier lohnt sich ein Blick auf die Bibliothek von Yahoo! Maps. Dort gibt es zwar weniger Konfigurationsmöglichkeiten und auch keine Möglichkeit den Marker von Hand zu verschieben.
Doch diese Funktionalität ist an dieser Stelle zu vernachlässigen. Der entscheidende Unterschied ist, dass das Kartenobjekt von Yahoo! Maps eine Liste von Markern führt, deren
Namen bzw. Bezeichner man selbst bei der Markererstellung vergeben kann. So kann jedem Marker ein eindeutiger (und globaler) Bezeichner zugeordnet werden, auf den bei Bedarf auch zugegriffen werden kann. Dies ist bei dem beschriebenen Problem – das Löschen
eines einzelnen Markers – von entscheidendem Vorteil, da nun wirklich nur dieser eine Marker betroffen ist und alle anderen Marker davon unberührt bleiben. Daraus ergeben sich
drei Vorteile: Eine bessere Performance auf dem Client, eine geringere Datenmenge für die
Übertragung zum Client und eine – progammiertechnisch gesehen – schöne, einwandfreie
und direkte Umsetzung.
Die beschriebene Schwierigkeit war der Grund, die Entwicklung fortan mit Yahoo! Maps weiterzuführen.
Ein anderes Problem betraf die Programmierung der Aktionen für den Links-Klick und den
Doppelklick mit der Maus. Die Bibliotheken von Google als auch von Yahoo! waren nicht
in der Lage einen Doppelklick korrekt zu erkennen. An Stelle eines Doppelklicks wurden
zwei einzelne Klicks und ein Doppelclick ausgeführt, was – je nach Funktionsbelegung –
zu einer größeren Verwirrung bei der Bedienung führen kann. Hier ist, wie an so mancher
Stelle, ein wenig Nacharbeit notwendig. Ein Lösungsweg ist die verzögerte Ausführung des
einfachen Linksklicks, der bei einem Doppelklick abgefangen wird und so nicht ausgeführt
werden kann.
3.6 Aktualisierungsstrategie
Ein zentraler Punkt, den es zu klären galt, betrifft die Verteilung der aktualisierten Daten
an alle Clients, sodass jeder Client den gleichen, aktuellen Datenbestand vorliegen hat. Da
es sich bei Maps on Rails um eine Web-Anwendung handelt, müssen Anfragen für eine
3 Evaluierung
9
Aktualisierung vom Client an den Server geschickt werden. Dieser kann nicht von sich aus
tätig werden. Die aktuellen Daten können nur auf Anfrage eines Clients an (ausschließlich)
diesen versendet werden.
Im ersten Schritt wird jedem Marker die Zeit seiner letzten Veränderung zugeordnet. So kann
bei jeder Veränderung des Datenbestandes die aktuelle Zeit auf den Client übertragen werden. Bei der nächsten Aktualisierung kann der Server dann abgleichen, ob der Zeitstempel
des Clients mit dem größten Zeitstempel aller Marker übereinstimmt. Falls nicht, müssen alle
Marker, deren Zeitstempel größer als der des Clients ist, aktualisiert werden.
Im zweiten Schritt muss dem Fall Rechnung getragen werden, dass auf den Clients (noch)
Marker existieren können, die inzwischen von einem anderen Teilnehmer gelöscht worden
sind und deshalb aus der Datenbank des Servers verschwunden sind. Diese Marker werden
in dem zuerst genannten Schritt nicht erfasst (da für sie kein Zeitstempel vorliegt). Es ist
also nötig, bei der Aktualisierungsanfrage eines Clients, zusätzlich zum Zeitstempel auch
eine Liste mit Bezeichnern der Marker mitzusenden. Durch den Abgleich dieser Liste mit der
Marker-Datenbank des Servers kann auch dieses Problem behoben werden.
Für die Antwort des Servers auf das Ergebnis einer Aktualisierungsanfrage des Clients gibt
es demnach folgende Möglichkeiten:
• Kein Zeitstempel (auf Server oder Client) vorhanden: Komplette Aktualisierung aller
Marker
• Die Daten sind aktuell (Zeitstempel gleich): Aktualisierung mit leerem Inhalt
• Der Zeitstempel des Clients ist älter als der des Servers: Neuere Marker aktualisieren
• Für die beiden letzen Fälle muss zusätzlich geprüft werden, ob es Marker gibt, die nur
auf dem Client existierenden: Diese Marker müssen gelöscht werden.
• Der Zeitstempel des Clients ist neuer bzw. jünger als der des Servers: Dieser Fall
kann nur vorkommen, wenn der Marker mit dem größten Zeitstempel gelöscht wurde.
Er wird durch die vorhergehende Prüfung ebenfalls abgefangen und muss daher nicht
gesondert behandelt werden.
Die Aktualisierungsstrategie stellt die Grundlage für den Einsatz von Maps on Rails als Mehrbenutzersystem dar. Durch sie wird, ohne dass der Server Zustandsinformationen über irgendeinen Client speichert, der aktuelle Zustand an alle Clients übertragen. Dabei werden
ausschließlich die für den Client nötigen Informationen (nur die Veränderungen) übertragen.
Die Übertragung der Änderungen erfolgt mittels Remote JavaScript-Technik. Die Antwort auf
die AJAX-Anfrage des Clients ist JavaScript-Code, der auf dem Client ausgeführt wird, um
die Änderungen in der Karte vorzunehmen.
3 Evaluierung
10
Die Aktualisierung wird von den Clients periodisch ausgeführt und macht so eine Kartenanwendung mit sich dynamisch ändernden Daten möglich. Sofern nur statische Marker dargestellt würden, wäre ein solcher Algorithmus nicht notwendig. Viele derartige „statische“
Web-Anwendungen finden sich im Internet. Manche von ihnen aktualisieren alle Marker in
periodischen Abständen, bei anderen muss dies durch ein Neuladen der Seite bzw. Anwendung manuell geschehen.
Während der Entwicklungsphase war es ohne Probleme möglich, mit einigen Browsern zugleich auf die Anwendung zuzugreifen. Ohne das Ergebnis genauer zu erläutern, hat der
Web-Server auf dem Entwicklungsrechner ca. 40 Anfragen pro Sekunde bearbeiten können. Eine konkrete Aussage über die Performanz des Systems kann hieraus, auf Grund unzureichender und ungesicherter Informationen über die Rahmenbedingungen, sicher nicht
gefolgert werden.
3.7 Yahoo! Maps on Rails
Die Entwicklung von Maps on Rails auf Basis von Yahoo! Maps musste nun ohne den
YM4R/GM Plugin voran gehen, da dieser nur für Google Maps geeignet war. Wie sich schnell
herausstellte, lässt sich in relativ kurzer Zeit mit den Helpern von Rails ein guter Ersatz erstellen. Darauf wird im folgenden Unterkapitel eingegangen.
Der Einsatz von Yahoo! Maps erforderte einige Änderungen in der Umsetzung der Anwendung. So war es beispielsweise nicht mehr nötig für jedes Mausereignis einen eigenen EventListener zu schreiben. Die Funktionalität fällt an dieser Stelle geringer aus. Jedoch werden
diese Listener automatisch erzeugt und so bleibt einem die relativ umständliche Definitionen der Listener in JavaScript erspart. Ein Mehraufwand ist hingegen bei der Gestaltung der
Benutzeroberfläche nötig. Yahoo! erlaubt keine editierbaren Eingabefelder in den Informationsfenstern, sodass die Editiermasken ausserhalb der Karte dargestellt werden müssen.
Dies ist für eine Eingabe von wenigen Informationen sicher ein Nachteil. Bei der Eingabe von
mehreren Eigenschaften kann es aber auch ein Vorteil sein, da die Eingabe von der aktuellen
Darstellung auf der Karte entkoppelt wird. Wenn etwa eine Aktualisierung des Karteninhalts
stattfindet, bleibt die Eingabemaske davon unberührt und der Benutzer kann seine Eingabe
fortsetzen, ohne dabei unterbrochen zu werden.
Abbildung 3.2 zeigt ein Bild des aktuellen Prototypen. Auf die grafische Gestaltung wurde,
zugunsten der Funktionalität im Rahmen des Projekts, kein großer Wert gelegt. Zu erkennen
sind verschiedene Marker auf der Karte und eine Bedienleiste im oberen Kartenbereich. Am
rechten Bildrand ist eine Informationsleiste vorgesehen, die bisher aber nur sehr rudimentär
umgesetzt worden ist. Unter der Karte besteht die Möglichkeit die Ortssuche einzusetzen.
3 Evaluierung
Abbildung 3.2: Der Prototyp Maps on Rails während der Entwicklung.
11
3 Evaluierung
12
Alle anderen Knöpfe am unteren Bildrand dienen der Entwicklung und sind nicht weiter zu
beachten.
3.7.1 Rails Helper
Ruby on Rails bietet die Möglichkeit sogenannte Helper für den Gültigkeitsbereich eines
Controllers zu definieren. Hier lassen sich bestimmte Funktionalitäten kapseln, etwa wiederkehrende Aktionen oder, wie in diesem Fall umgesetzt, die Generierung des JavaScriptCodes.
Der Helper stellt eine Art spezialisierte Ruby-Bibliothek dar, die (zur Laufzeit aufgerufen) den
nötigen JavaScript-Code für die Ansteuerung der Karte erzeugt. Dieser JavaScript-Code
kann an einer Stelle gekapselt werden. Die Kapselung ermöglicht eine saubere Trennung
zwischen JavaScript und Ruby-Code, sowie zwischen der Steuerung des Programmablaufs
und der Anzeige. Durch diese Trennung wird auch die Übersichtlichkeit des Quellcodes gefördert. In der View kann dann auf die (an anderer Stelle gekapselte) Funktionalität für die
Steuerung des Programmablaufs zugegriffen werden, um den nötigen Code per Remote JavaScript an den Client zu senden. Die eigentliche Aufgabe der View, die die Erzeugung der
Anzeige auf dem Client betrifft, bleibt davon weitestgehend unberührt. Diese Trennung der
Belange entspricht auch der Einhaltung des Model-View-Controller Architekturmusters.
3.8 Web-Browser
Im Rahmen des Projekts wurde ein kurzer Test der Anwendung in verschiedenen Browsern
vollzogen. Die Anwendung lief in Firefox 2.x und Safari 3.x ohne Probleme. Im Internet Explorer 7 und Opera 9.x gab es geringe Abweichung bei der Darstellung. Die Anwendung
funktionierte jedoch erstaunlicherweise in vollem Umfang. Je nach weiterer Ausführung des
Projektes sind hier aber durchaus Probleme zu erwarten.
4 Wirtschaftskontakte
13
4 Wirtschaftskontakte
4.1 Geoinformationsysteme der Stadt Hamburg
Im Rahmen des Projekts kam ein Besuch beim Landesamt für Geoinformation und Vermessung der Stadt Hamburg zu Stande. Dort beschäftigt man sich auch mit einer sehr ähnlichen
Thematik, aber bedient sich einer völlig anderen technischen Umsetzung. Man kann den dort
gewählten Weg gewissermaßen als professionellere Herangehensweise betrachten. Dieses
Unterkapitel soll kurz auf die Rückschlüsse für das Projekt eingehen.
Kartendienste wie Google oder Yahoo! Maps bieten bei weitem nicht den Funktionsumfang
eines professionellen Geoinformationssystems. Die Kartendienste sind am Endbenutzer orientiert und bieten beispielsweise eine gute Ortssuche und Routenplanung. Professionelle
Systeme basieren auf anderen Techniken und sind nicht über eine verhältnismäßig einfache
JavaScript-Bibliothek einzubinden. Es gibt Lösungen, die auf den Standards des OGC1 basieren und auf den Web Map Service (WMS) und den Web Feature Service (WFS) aufbauen.
Beides sind Web-Services. WMS beschreibt den standardisierten Zugriff auf Kartenmaterial.
WFS beschreibt den Zugriff und die Manipulation von geographischen bzw. raumbezogenen
Daten.
Um ein System zu bauen, das auf diesen Web-Services aufbaut, müssen eigene Server für
diese Dienste betrieben werden2 . Das Kartenmaterial kann sicher aus einer bestehenden
Quelle bezogen werden, aber die darzustellenden Daten müssen durch einen speziellen
Dienst zur Verfügung gestellt und persistent gemacht werden. Dieser Dienst muss selbst
aufgesetzt werden, da die Daten (nach den Anforderungen an das Szenario) im eigenen
System und nicht bei einem anderen Anbieter gespeichert werden sollen. I.d.R. werden bei
solchen Systemen Karten und Daten zusammen in einer Ebene angezeigt, sodass dabei ein
wenig Interaktivität der Anwendung verloren geht3 .
Der große Vorteil solcher standardisierter Dienste liegt in ihrer Interoperabilität und der Offenheit der Standards. Im Vergleich zu den proprietären Lösungen von Google und Yahoo!
Maps, die zudem weitere (auch lizenzrechtliche) Nutzungeinschränkungen mit sich bringen,
1
Open Geospatial Consortium, siehe http://www.opengeospatial.org/standards/.
Für entsprechende Dienste, siehe http://www.deegree.org/.
3
Man denke dabei an die verschiebbaren Marker von Google Maps.
2
4 Wirtschaftskontakte
14
Abbildung 4.1: Satellitenbild des OpenLayers-Kartendienstes. [OSGeo, 2008]
gibt es auch freie Kartendienste. Abbildung 4.1 zeigt den freien Kartendienst OpenLayers,
der ebenfalls eine JavaScript API zur Verfügung stellt.
Auf Grund des begrenzten zeitlichen Rahmens des Projekts werden diese Ansätze hier nicht
weiter vertieft. Ferner liegt das Hauptaugenmerk des Projekts nicht auf der Evaluation verschiedener Geoinformationsysteme und deren Kartenmaterial, sondern auf Entwicklung eines Ruby on Rails Systems mit – wenn man so will, irgendeinem, – Kartendienst.
4.2 UbiLabs
Im Rahmen eines Vortrags des GameCityLabs, in dem wir unsere Projekte im Collaborative Workplace der Hochschule für Angewandte Wissenschaften Hamburg vorstellten, kam
ein Kontakt mit der Firma Ubilabs4 zustande. Ubilabs entwickelt verschiedene MashupAnwendungen mit Google Maps und setzt seit Neuestem auch Ruby on Rails ein. Eine
weiterführende Zusammenarbeit im Rahmen der Masterarbeit ist angedacht.
4
Siehe: http://www.ubilabs.net/
5 Zusammenfassung
15
5 Zusammenfassung
Dieser Bericht steht in Zusammenhang mit den Arbeiten am Leitstandszenario im Seminar, Anwendungen I und Anwendungen II. In Kapitel 2 wurden zuerst die Vision, die Ziele
und die Vorgehensweise vorgestellt. Kapitel 3 beschreibt die evaluierten Techniken mit ihren Möglichkeiten und Grenzen und diskutiert einige Überlegungen, die zur Erstellung des
Prototypen notwendig waren. In diese Kategorie fallen etwa Ruby on Rails, JavaScript bzw.
AJAX, Google und Yahoo! Maps und die Anwendung Maps on Rails selbst.
5.1 Fazit
Abschließend kann festgestellt werden, dass das Projekt erfolgreich gelaufen ist und das Resultat im gewünschten Bereich liegt. Aufgrund des beschränkten zeitlichen Rahmens nahmen der Aufbau der Infrastruktur im Labor und die Einarbeitungszeit in die Techniken einen
überproportional großen Teil der Projektzeit ein.
Die Evaluation der diskutierten Techniken im Rahmen des Szenarios war erfolgreich. Es
ist mit einer gewissen Einarbeitungszeit möglich eine interaktive Kartenanwendung prototypisch mit Ruby on Rails als Web-Anwendung umzusetzen, wie das Arbeitsergebnis des
Projekts zeigt. Wünschenswert wäre eine noch tiefergehende Beschäftigung mit dem Ruby
on Rails Framework gewesen. Einige Aspekte wie z.B. das Testen konnten im Projekt leider
nicht betrachtet werden. Auf jeden Fall war das Arbeiten mit Ruby on Rails angenehm und
motivierend.
Die Programmierung in JavaScript war des Öfteren sehr mühsam und relativ kompliziert, da
einfache Dinge oft nicht auf dem direkten Weg zu erreichen waren. Sicherlich spielte hier
auch die mangelnde Erfahrung in der Programmierung von JavaScript eine Rolle.
Der Einsatz der Kartendienste war eng mit den Schwierigkeiten von JavaScript verbunden,
gestaltete sich aber relativ problemlos. Nichtsdestotrotz wäre das ein oder andere Mal eine
bessere Unterstützung durch die Bibliotheken der Kartendienste sinnvoll gewesen. Dies trifft
beispielsweise bei der Gestaltung von Eingabemasken innerhalb des Kartenausschnitts und
insbesondere bei der Manipulation von bestehenden Markern zu. Hier besteht für die weitere
Entwicklung der Bibliotheken der Kartendienste noch genügend freies Potential.
5 Zusammenfassung
16
5.2 Ausblick
Nachdem hier gezeigt wurde, dass die Integration eines Kartendienstes in Ruby on Rails
in einer gewinnbringenden Art und Weise möglich ist, kann das Thema in der anstehenden
Masterarbeit weiter vertieft werden. Mehrere Punkte sind noch nicht behandelt worden und
an einigen Stellen gibt es noch Verbesserungsbedarf. Eine kleine Auswahl anzugehender
Bereiche sind die Integration einer Benutzerverwaltung, die Nutzung einer Datenbank mit
Geoinformations-Erweiterung, die Darstellung von Flächen mittels Polygonen und die Verbesserung des User-Interfaces. Hier ist z.B. auch an Usability-Tests zu denken.
Weitere interessante Gebiete sind die Nutzung eines freien Kartendienstes (z.B. OpenLayers) und die Steuerung von Maps on Rails mit neuen Eingabegeräten wie Multitouch,
Eyetracker und Motiontracker, sofern dies für einen Einsatz in einer Einsatzleitstelle an einer
Powerwall einen Sinn ergibt. Die Anwendung Maps on Rails kann im Zuge dieser Umsetzungen weiter ausgebaut werden. Dabei soll der Schwerpunkt aber noch stärker auf der
Evaluation von Ruby on Rails liegen.
Literaturverzeichnis
[Google Inc. 2007a]
G OOGLE I NC.: Google Maps. 2007. – URL http://maps.
google.de/. – Zugriffsdatum: 11.11.2007
[Google Inc. 2007b]
G OOGLE I NC.: Google Maps API. 2007. – URL http://www.
google.com/apis/maps/. – Zugriffsdatum: 26.11.2007
[Hansson 2008]
H ANSSON, David H.: Rails Framework Documentation. 2008. – URL
http://api.rubyonrails.com/. – Zugriffsdatum: 25.02.2008
[Lewis 2007]
2007
[OSGeo 2008]
L EWIS, Andrew: Google Maps Applications with Rails and Ajax. Apress,
OSG EO, Open Source Geospatial Foundation: OpenLayers. 2008. – URL
http://www.openlayers.org/
[Schempp 2006]
S CHEMPP, Ruben: Aktuelle Entwicklungen im Bereich von Programmiersprachen, Hochschule für Angewandte Wissenschaften Hamburg, Bachelorarbeit,
2006. – URL http://users.informatik.haw-hamburg.de/~ubicomp/
arbeiten/bachelor/schempp.pdf
[Schempp 2007]
S CHEMPP, Ruben: Anwendungen I: Verteilte Web-Anwendungen
mit Ruby.
2007. –
URL http://users.informatik.haw-hamburg.
de/~ubicomp/projekte/master2007/schempp/bericht.pdf. – Zugriffsdatum: 07.02.2008
[Schempp 2008a] S CHEMPP, Ruben: Anwendungen II: Interaktive Karten als Rich Internet Applications. 2008. – URL http://users.informatik.haw-hamburg.
de/~ubicomp/projekte/master07-08-aw/schempp/bericht.pdf.
–
Zugriffsdatum: 29.02.2008
[Schempp 2008b]
S CHEMPP, Ruben:
Seminar: Maps on Rails.
2008. –
URL
http://users.informatik.haw-hamburg.de/~ubicomp/projekte/
master07-08/schempp/bericht.pdf. – Zugriffsdatum: 29.02.2008
[Thomas u. a. 2005] T HOMAS, Dave ; F OWLER, Chad ; H UNT, Andy: Programming Ruby:
The Pragmatic Programmers’ Guide. Second Edition. The Pragmatic Programmers, 2005.
– ISBN 0-9745140-5-5
Literaturverzeichnis
[Thomas und Hannson 2006]
T HOMAS, Dave ; H ANNSON, David H.:
Development with Rails. Pragmatic Bookshelf, 2006
[Vellut 2007a]
18
Agile Web-
V ELLUT, Guilhem:
Yellow Maps for Ruby. 2007. – URL http://
rubyforge.org/projects/ym4r/. – Zugriffsdatum: 07.02.2008
[Vellut 2007b] V ELLUT, Guilhem: Yellow Maps for Ruby, Google Maps Plugin for Rails.
2007. – URL http://ym4r.rubyforge.org/ym4r_gm-doc/. – Zugriffsdatum:
07.02.2008
[Yahoo! Inc. 2008]
YAHOO ! I NC.: Yahoo! Maps API. 2008. – URL http://developer.
yahoo.com/maps/ajax/V3.7/reference.html. – Zugriffsdatum: 07.02.2008