StoryLiner - Ein literarischer Reiseführer für den Vierwaldstättersee

Transkript

1 StoryLiner - Ein literarischer Reiseführer für den Vierwaldstättersee Masterarbeit Geomatik und Planung Herbstsemester 2013 Autorin Tabea Probst probstta@ethz.ch Abgabedatum 27. Januar 2014 Leitung Prof. Dr. Martin Raubal Betreuung Dr. Peter Kiefer Dr. Hans-Rudolf Bär Dr. Barbara Piatti Abgabedatum: 27. Januar 2014

2 I. VORWORT I Vorwort Die vorliegende Masterarbeit ist am Departement für Bau, Umwelt und Geomatik (D-BAUG) der Eidgenössischen Technischen Hochschule Zürich (ETH) im Rahmen des Masterstudiums Geomatik und Planung entstanden. Das Thema wurde am Institut für Kartografie und Geoinformation (IKG) ausgeschrieben und von September 2013 bis Januar 2014 bearbeitet. Die Arbeit steht unter der Leitung von PROF. DR. MARTIN RAUBAL und wurde von DR. PETER KIEFER, DR. HANS-RUDOLF BÄR und von DR. BARBARA PIATTI betreut. An dieser Stelle möchte ich mich beim IKG für die Unterstützung und das Zurverfügungstellen der Infrastruktur, die für diese Arbeit unverzichtbar war, bedanken. Meinen Betreuern, DR. PETER KIEFER, DR. HANS-RUDOLF BÄR und DR. BARBARA PIATTI, danke ich herzlich für ihre kompetente Unterstützung und ihre hilfreichen Inputs. Sie sind mir bei Fragen und Unklarheiten stets zur Seite gestanden und haben mich mit Tipps und Ratschlägen unterstützt. Ein herzliches Dankeschön richte ich auch an BARBARA BORN und FABIAN GSCHWEND für das Korrekturlesen sowie an alle anderen, hier nicht namentlich erwähnten Personen, welche durch Einbringen von guten Ideen und konstruktiver Kritik zum Gelingen dieser Arbeit beigetragen haben. Tabea Probst I

3 II. ZUSAMMENFASSUNG II Zusammenfassung Das Forschungsprojekt Ein literarischer Atlas Europas befasst sich mit der Literaturgeografie und somit mit der Frage: Wo spielt Literatur? Im literarischen Atlas Europas werden die Handlungsräume von literarischen Werken geografisch eingeordnet. Die Ergebnisse können auf mehrere Arten dargestellt werden. Mit einer dieser Möglichkeiten, nämlich mit der Integrierung der literarischen Daten in einen standortbezogenen Dienst, befasst sich die vorliegende Arbeit. StoryLiner, die Umsetzung dieses standortbezogenen Dienstes, ist eine Android App für Smartphones, die für die Region des Vierwaldstättersees angeboten wird. Weil vom Schiff aus zahlreiche Schauplätze des literarischen Atlas Europas sichtbar sind und die knapp dreistündige Fahrt von Luzern nach Flüelen wegen der beeindruckenden Landschaft nicht nur bei Touristen beliebt ist, wird die App für diese Schifffahrt entwickelt. Speziell an diesem standortbezogenen Dienst ist, dass der Anwender nicht selbst über den Ort und die Dauer des Aufenthalts bestimmen kann. Mit einer sorgfältigen Konzipierung der App kann die Auswirkung dieser Einschränkung minimiert werden. Damit StoryLiner rechtzeitig die Informationen zum gerade sichtbaren Schauplatz liefern kann, wird in dieser Arbeit ein Algorithmus entworfen, welcher für jeden Schauplatz eine sogenannte Trigger-Region berechnet. Diese Region erfüllt mehrere Bedingungen, die es dem Anwender ermöglichen, sich dem aktuellen Schauplatz zu widmen. Als Input für den Algorithmus werden die Koordinaten der Schauplätze und der Schiffsroute sowie ein digitales Höhenmodell für die Sichtbarkeitsanalyse benötigt. Die maximale Anzahl Trigger- Regionen, die mit diesem Werkzeug berechnet werden kann, hängt stark von der Position der Schauplätze und der Topografie ab. Für die 14 wichtigen Orte der Literatur rund um den Vierwaldstättersee können erfolgreich alle benötigten Trigger-Regionen erzeugt werden. Für die Android App werden manuell erstellte Trigger-Regionen verwendet, die zusätzlich die Fahrtrichtung und die zwei verschiedenen Routen auf dem Urnersee berücksichtigen. Sobald der Anwender eine Trigger-Region betritt, erhält er eine Benachrichtigung, welche ihn auffordert, sich die Informationen des Schauplatzes anzusehen. Der jeweilige Schauplatz ist in der Karte farblich markiert und eine aufrufbare Panorama-Ansicht weist dem Betrachter die genaue Position des Ortes. Zu den Informationen des Schauplatzes gehören neben Fotos ein Zitat, ein Hinweis zum Text und Angaben zum Autor des Buches, dessen Handlung am aktuellen Schauplatz spielt. Zusätzliche Informationen zum Ort sollen den Anwender der App animieren, diesen Ort zu besuchen. Ein Nutzertest mit einer kleinen Testgruppe zeigt, dass StoryLiner bei den Testern grundsätzlich Anklang findet und eine standortbezogene App geeignet ist, um Wissen aus dem Gebiet der Literaturgeografie zu vermitteln. Schlagwörter: Ein literarischer Atlas Europas, Literaturgeografie, standortbezogener Dienst, Android App, Trigger-Region II

4 III. ABSTRACT III Abstract The research project A Literary Atlas of Europe deals with literary geography and thus with the question: Where is literature set? The literary atlas of Europe links the scene of books with geography. The results can be displayed in several ways. The present work is concerned with one of these options, namely the integration of the literary data in a location-based service. StoryLiner, the implementation of this location-based service, is an Android app for smartphones. This app is offered for the region of Lake Lucerne. Numerous settings of the literary atlas of Europe can be seen from the ship during the nearly three-hour cruise from Lucerne to Flüelen. This app is developed for this region, because the impressive landscape is not only popular amongst tourists. The user cannot decide on the location and length of stay which is a specialty of this location-based service. With careful design of the app, the consequence of this limitation can be minimized. An algorithm is designed to compute so-called trigger regions for each setting. StoryLiner needs these regions to provide the information about the currently visible setting on time. Those regions fulfill several conditions that allow the user to dedicate themselves to the actual setting. The coordinates of the settings and the ship's route, as well as a digital elevation model for the visibility analysis are needed as input for the algorithm. The maximum number of trigger regions, which can be calculated with this tool, depends strongly on the position of the settings and the topography. For the 14 settings around Lake Lucerne all the required trigger regions can be successfully generated. Manually created trigger regions are used for the Android app. Those regions additionally take into account the direction of travel and the two different routes on the Lake of Uri. Once the user enters a trigger region, he receives a notification which prompts him to look at the information of the setting. The respective setting is highlighted on the map. A panoramic view shows the user the exact location of the place. Among photos the information of the setting includes a citation, a remark to the text and information about the author of the book, whose action takes place in the current setting. Additional information about the location animates the user of the app, to visit this place. A user test with a small test group shows that the principle of StoryLiner goes down well with the testers. A location-based app is suitable to transmit knowledge from the field of literary geography. Keywords: A Literary Atlas of Europe, Literary Geography, Location-Based Service, Android App, Trigger Region III

5 IV. INHALTSVERZEICHNIS IV Inhaltsverzeichnis I VORWORT I II ZUSAMMENFASSUNG II III ABSTRACT III IV INHALTSVERZEICHNIS IV V ABBILDUNGS- UND TABELLENVERZEICHNIS VI 1 EINLEITUNG Einführung und Problemsituation Zielsetzung Inhaltübersicht FORSCHUNGSÜBERBLICK Kartografie und Geografie Literaturgeografie Storytelling Maps Mobile Kartografie Standortbezogene Dienste Definition Technischer Hintergrund Architekturen Mobile Reiseführer ERSTELLUNG VON TRIGGER-REGIONEN Grundlagen Ansätze für die Berechnung der Trigger-Regionen Anforderungen Input-Daten Input-Parameter Verwendete Technologien Manuelle Erstellung Automatische Erstellung Ergebnisse MOBILER LITERATURFÜHRER Grundlagen IV

6 IV. INHALTSVERZEICHNIS Anforderungen Daten des «literarischen Atlas Europas» Datenpaket Verwendete Technologien Java Android Eclipse mit Android Developer Tools Plugin Erweiterung der App mit einer Karte Atlas der Schweiz Aufbau der Applikation Herunterladen des Datenpakets Karte Orientierungshilfe Galerie Literaturinformationen Ergebnisse Vorbereitung Applikationstests Ergebnisse Applikationstests FAZIT UND AUSBLICK Fazit Ausblick LITERATURVERZEICHNIS 50 ANHANG 52 A Inhalt CD B Test des Tools für Trigger-Regionen C Inhalt des Datenpakets D Anpassung der App für einen anderen See E App Auflistung und Beschreibung der Java-Files F Fragebogen für Evaluation der App G Auswertung Fragebogen H Nutzungsbestimmungen für Swisstopo-Geodaten für ETH-Angehörige I Eigenständigkeitserklärung V

7 V. ABBILDUNGS- UND TABELLENVERZEICHNIS V Abbildungs- und Tabellenverzeichnis Abbildung 1.1: Collage mit statistischen Auswertungen und Darstellungen literarischer Räume (Reuschel, 2008)... 1 Abbildung 1.2: Blick auf den Mythen... 2 Abbildung 2.1: Beispiel einer Esri Story Map von Matt Artz (Esri, 2014)... 5 Abbildung 2.2: LBS an der Schnittstelle verschiedener Technologien (nach Brimicombe und Li (2006))... 9 Abbildung 2.3: Überblick über die Architektur von standortbezogenen Diensten (aus Brimicombe und Li (2009)) Abbildung 3.1: Beispiel Beobachterpunkte-Analyse Abbildung 3.2: Beispiel Sichtfeld-Analyse Abbildung 3.3: Inputdaten (Schauplätze, Schiffsroute, DHM) für die Berechnung von Trigger-Regionen, Basiskarte von Esri Abbildung 3.4: Eingabemaske des erstellten Tools Abbildung 3.5: Manuell erstellte Trigger-Regionen (Luzern-Flüelen), Basiskarte von Esri Abbildung 3.6: Sichtfeld-Analyse am Beispiel der Rigi (links) und Schiffsroutenabschnitt mit Sicht auf Rigi (rechts) Abbildung 3.7: Berechnung einer Trigger-Region Abbildung 3.8: Automatisch generierte Trigger-Regionen Abbildung 3.9: Veränderung einer Trigger-Region beim Einfügen eines zweiten Schauplatzes Abbildung 3.10: Veränderung der Trigger-Regionen beim Einfügen eines dritten Schauplatzes...23 Abbildung 3.11: Veränderung der Trigger-Regionen beim Einfügen eines vierten Schauplatzes...23 Abbildung 3.12: Trigger-Regionen von 25 Schauplätzen(links) und von 26 Schauplätzen (rechts) Abbildung 4.1: Weltweiter Marktanteil verschiedener Smartphones 3. Quartal 2013 (nach Llamas et al. (2013)) Abbildung 4.2: An die App angepasstes Datenmodell des literarischen Atlas Europas Abbildung 4.3: Alphonse Daudet, Fotografie von Nadar (1884)...27 Abbildung 4.4: Rigibähnli (links) (Piatti, 2013), Rigi von weitem (Mitte),Intérieur-Skizze Palais Schreiber Rigi-Kulm (rechts) (Institut für Geschichte und Theorie der Architektur (gta), ETH Zürich) Abbildung 4.5: Ordnerstruktur Download-Ordner Abbildung 4.6: Überblick über den Software Entwicklungsprozess von Java (nach Oracle (2013)) Abbildung 4.7: Activity Lebenszyklus (Android Developers, 2013)...32 Abbildung 4.8: Atlas der Schweiz 3 Panorama-Ansicht...35 Abbildung 4.10: Startbildschirm Abbildung 4.10: Aufbau StoryLiner Abbildung 4.11: Herunterladen des Datenpakets VI

8 V. ABBILDUNGS- UND TABELLENVERZEICHNIS Abbildung 4.12: Basiskarte (Anne-Kathrin Weber) Abbildung 4.13: Kartenansicht Abbildung 4.14: Benachrichtigung...40 Abbildung 4.15: Infofenster, 4 Texte Abbildung 4.16: Infofenster, 1 Text Abbildung 4.17: Panorama-Ansicht am Beispiel der Rigi Abbildung 4.18: Setzen des richtigen Panoramabildes Abbildung 4.19: Galerie mit Überblick über alle Fotos (links) und Detailansicht (rechts) Abbildung 4.20: Zitat (links), Informationen zum Autor (Mitte) und Informationen zum Schauplatz (rechts) Tabelle 3.1: Hilfstabelle, Beispiel mit drei Schauplätzen Tabelle 4.1: Metadaten Panoramen VII

9 1 EINLEITUNG 1 Einleitung Dieses Kapitel liefert eine Einführung ins Thema dieser Arbeit. Dafür wird zuerst die Ausgangslage beschrieben und auf die Problemsituation eingegangen. Im zweiten Abschnitt werden die Ziele definiert, wobei neben einem Hauptziel verschiedene Zwischenziele formuliert werden. Im letzten Abschnitt des Kapitels wird eine Übersicht über den Aufbau und den Inhalt der Arbeit geliefert. 1.1 Einführung und Problemsituation Trifft man beim Lesen eines Buches auf die Beschreibung von Landschaften oder Orten, setzt sich im Kopf ein Bild zusammen, das bei jedem Leser ein wenig anders aussieht. Der Fantasie sind hierbei keine Grenzen gesetzt. Doch wie sehen diese in der Literatur vorkommenden Orte wirklich aus? Existieren sie in der Realität oder kann zumindest ein Bezug zu einem realen Ort hergestellt werden? Mit anderen Worten: wo spielt Literatur und warum spielt sie dort? Mit diesen Fragen beschäftigt sich das Projekt Ein literarischer Atlas Europas 1. Es ist ein Abbildung 1.1: Collage mit statistischen Auswertungen und Darstellungen literarischer Räume (Reuschel, 2008) Forschungsprojekt am Institut für Kartografie und Geoinformation der ETH Zürich, dessen Ziel die räumliche Erfassung und kartografische Darstellung von Orten ist, die in der Literatur eine Rolle spielen sei es als Schauplatz der Handlung oder als projizierter Ort in den Erinnerungen oder Träumen der handelnden Figuren. Für den Prototyp dieses Atlas werden drei sehr unterschiedliche Modellregionen mit einer grossen Dichte an literarischen Schauplätzen verwendet: Prag als städtischer Raum, Nordfriesland als Küsten- und Grenzregion sowie die Region Vierwaldstättersee/Gotthard als Gebirgslandschaft. (Piatti et al., 2013) Die abwechslungsreiche Landschaft rund um den Vierwaldstättersee, die von eher flachem, städtischem Gebiet in der Region Luzern bis hin zu alpinem Raum im Gebiet des Urnersees reicht, bietet zahlreiche Aktivitäten für Touristen. Die sehr beliebte, knapp drei Stunden dauernde Schiffsreise von Luzern über Weggis, Vitznau, Beckenried und Brunnen nach Flüelen stellt eine hervorragende Möglichkeit dar, die Vielseitigkeit der schweizer Landschaft hautnah zu erleben. Vom See aus sind zudem viele Orte, an denen Literatur spielt, zu sehen (siehe Beispiel in Abbildung 1.2). Deshalb liegt der Gedanke nahe, eine vergnügliche 1 Ein literarischer Atlas Europas: 1

10 1 EINLEITUNG Abbildung 1.2: Blick auf den Mythen Schifffahrt mit einer Reise durch die Schauplätze der Literatur zu verbinden. Der Schiffsreisende soll Einblicke in die verborgenen Bedeutungen hinter den ihn umgebenden Orten erhalten. Er soll etwas erfahren über die Figuren der Literatur, ihre Gedanken und vor allem über die Orte, an denen sie sich befinden. Solche literarischen Eindrücke, die eine kulturelle Bereicherung darstellen, ermöglichen vor allem ausländischen Touristen den Kontakt mit der schweizer Kultur, die mehr zu bieten hat als ein paar Kühe auf der Alp, Jodelgesang und Schokolade. Um ein solches kulturelles Erlebnis zu ermöglichen, braucht es die entsprechende technologische Unterstützung. Die Grundlage dafür soll mit dieser Arbeit geschaffen werden. 1.2 Zielsetzung Das Hauptziel der Arbeit ist die Konzeption und Umsetzung eines standortbezogenen Dienstes, der einem Touristen auf einer Schifffahrt ermöglicht, die entlang der Route relevanten Inhalte des Literaturatlas zu erleben. Dieses Hauptziel kann aufgeteilt werden in zwei Unterziele. Das Erste ist die Erstellung eines Tools, welches die automatische Berechnung von Trigger-Regionen ermöglicht. Es soll die Fähigkeit haben, für beliebige andere Seen mit verschiedenen Schauplätzen Trigger-Regionen zu berechnen, die einfach weiterverwendet werden können. Das zweite Unterziel ist die Entwicklung einer zweisprachigen (deutsch und englisch) App für Smartphones für das Beispiel des Vierwaldstättersees. Die App soll dem Reisenden den Literaturatlas näherbringen und einen Überblick über die sich an den Schauplätzen bietenden Möglichkeiten für weitere touristische Aktivitäten geben. Das heisst, einerseits sollen Informationen zu den literarisch wichtigsten Orten rund um den See sowie Hintergründe zu den Schriftstellern und Texten geliefert werden, andererseits sollen touristische Zusatzinformationen über die Region und die Schauplätze zur Verfügung stehen. Neben diesen beiden Hauptzielen sollen folgende Zwischenziele erreicht werden: Erarbeiten von Lösungsansätzen für das Präsentieren literarischer Inhalte und touristischer Zusatzinformationen Untersuchung der Auswirkungen des nicht frei wählbaren Standorts des Benutzers während der Schifffahrt auf das Präsentieren von Informationen (er ist an die Route und Geschwindigkeit des Schiffes gebunden) Umsetzung einer technischen Lösung, welche keine hohen Kosten für (ausländische) Touristen verursacht, für die der mobile Datentarif in der Schweiz sehr hoch sein kann Zum Schluss soll eine kleine Evaluation mit wenigen Testpersonen durchgeführt werden. Damit soll vor allem überprüft werden, ob die gesetzten Ziele erreicht wurden. Zudem soll die allgemeine Funktionalität der App getestet werden. Möglicherweise ergeben sich durch diese Evaluation erste Aussagen über die Nutzbarkeit der App. 2

11 1 EINLEITUNG 1.3 Inhaltübersicht In der Einleitung wird nach einer kurzen Einführung in das Thema der Arbeit und der Darstellung der Problemsituation auf die Zielsetzung eingegangen. Es wird beschrieben, was mit dieser Arbeit erreicht werden soll und welche Teilziele erfüllt werden müssen. Im Kapitel Forschungsüberblick wird versucht, die Arbeit in die aktuelle Forschung einzuordnen. Dafür werden verschiedene Aspekte sowohl im Bereich der Kartografie und Geografie als auch im Bereich der standortbezogenen Dienste aufgezeigt. Im Kapitel Erstellung von Trigger- Regionen wird beschrieben, was unter diesem Begriff verstanden wird, welche Eigenschaften eine solche Region haben muss und was für Möglichkeiten es gibt, diese zu erstellen. Es wird dargelegt, welcher Algorithmus dem Tool für die automatische Berechnung dieser Regionen zu Grunde liegt und schliesslich die damit erzielten Resultate gezeigt. Im vierten Kapitel, im Kapitel Mobiler Literaturführer, geht es um die Erstellung der Applikation für Smartphones. Auch hier werden Anforderungen definiert, bevor die Daten des Literaturatlas vorgestellt werden und auf die verwendeten Technologien eingegangen wird. Der Abschnitt Aufbau der Applikation befasst sich mit den einzelnen Modulen der Applikation. Es wird beschrieben, wie sie aufgebaut sind und in welchem Zusammenhang sie zu den anderen Elementen stehen. Zum Schluss dieses Kapitels wird auf die Ergebnisse des mobilen Literaturführers eingegangen. Das letzte Kapitel, Fazit und Ausblick, enthält abschliessende Bemerkungen zur vorliegenden Arbeiten. Es wird ein Fazit gezogen und auf mögliche Erweiterungen und Verbesserungen der erstellten App hingewiesen. 3

12 2 FORSCHUNGSÜBERBLICK 2 Forschungsüberblick Dieses Kapitel soll dazu dienen, einen Überblick über den aktuellen Stand der Forschung in den für diese Arbeit relevanten Bereichen zu verschaffen. Im Bereich der Kartografie und Geografie sind dies Informationen zur Literaturgeografie, zu sogenannten Storytelling Maps und zur mobilen Kartografie. Im zweiten Teil geht es um den eher technischen Bereich der standortbezogenen Dienste. Neben einer Definition sind darin Ausführungen zum technischen Hintergrund und der Architektur von standortbezogenen Dienste sowie einige Anmerkungen zu immer wichtiger werdenden mobilen Reiseführern enthalten. 2.1 Kartografie und Geografie Literaturgeografie Als Anstoss für die Geografie der Literatur dient die vermeintlich simple Frage: «Wo spielt Literatur?» Obwohl die Phantasie der Schreibenden an keine geografischen und topografischen Gesetzmässigkeiten gebunden ist, kann immer wieder festgestellt werden, dass Literatur an Orten spielt, die in der Realität existieren. Dies kommt daher, dass sich Autoren mit gewissen Orten und Landschaften verbunden fühlen, mit ihnen verwurzelt sind und sie deshalb zu Schauplätzen in ihren Werken ernennen. In Folge werden Autoren mit bestimmten Landschaften, Regionen oder Städten in Verbindung gebracht, zum Beispiel die Brontë Schwestern mit Yorkshire, Dickens mit London oder Jeremias Gotthelf mit dem Emmental. (Piatti, 2008) Das noch nicht vollständig etablierte Forschungsgebiet der Literaturgeografie befasst sich nicht nur mit der Frage nach dem Ort, an dem Literatur spielt sondern auch mit den Hintergründen. Weshalb spielt Literatur an einem bestimmten Ort? Wie werden bestehende geografische Räume im Laufe der Zeit genutzt, verformt, verfremdet und neu modelliert? Wie lassen sich solche fiktionalisierten Räume darstellen und deuten? (Piatti et al., 2008) Literaturgeografie kann systematisch gesehen in zwei Teile gegliedert werden. Der eine Teil untersucht Geburts-, Wohn- und Arbeitsorte von Schriftstellern und versucht, darin regionale Besonderheiten festzustellen. Der andere Teil befasst sich mit den literarisierten, das heisst mit den in der Literatur beschriebenen Orten. Diese beiden Aspekte lassen sich oft nicht genau trennen, da sich der Aufenthaltsort des Autors mit dem Handelsraum überschneiden kann. (Piatti et al., 2013) Schon zu Beginn des 2o. Jahrhunderts war die Literaturgeografie ein Thema. In der zweiten Hälfte dieses Jahrhunderts verschwanden jedoch die räumlichen Aspekte der Literatur aus nationalistischen Gründen aus dem Blickfeld der Wissenschaft. Erst in jüngster Zeit bekam das Thema einen Aufschwung, der eine neue Ära der Literaturgeografie einläutete (Piatti et al., 2013). Für die Weiterentwicklung dieser Wissenschaft braucht es nach Piatti (2008, S. 9) 4

13 2 FORSCHUNGSÜBERBLICK ein «konstruktives Zusammenspiel verschiedener Disziplinen allen voran der Literaturwissenschaft und der Kartografie». Diese Zusammenarbeit eröffnet neue Möglichkeiten und Werkzeuge für die Analyse von Literatur und deren Schauplätze. Eine weitere Möglichkeit für ein solches Zusammenspiel verschiedener Disziplinen wird im Rahmen der vorliegenden Arbeit untersucht. Die Verbindung der Literaturgeografie mit der Geoinformation soll dazu führen, literaturgeografische Inhalte mit Hilfe eines standortbezogenen Dienstes zu vermitteln Storytelling Maps Diese in den letzten Jahren aufgekommene Erweiterung von Karten ist unter verschiedenen Bezeichnungen bekannt. Story Telling with Maps 2 ist die Bezeichnung, die Esri verwendet, National Geographic benutzt den Namen Geostories 3 und MapStories 4 werden von der MapStory Foundation erstellt. Obwohl es wahrscheinlich noch zahlreiche andere Bezeichnungen dafür gibt, geht es überall um das Gleiche, nämlich um die Darstellung von verschiedenen Informationen, oder eben Stories, in einer Karte. Nach Esri (2012) ist eine Story nicht als Geschichte im eigentlichen Sinne zu verstehen, sondern als Konzept oder Botschaft, die durch eine Story Map übermittelt werden soll. Um dies zu ermöglichen, werden Karten mit Elementen verbunden, welche diese Botschaft auf einfache und deutliche Weise zu vermitteln vermögen. Solche Elemente können Titel, Texte, Legenden, Popup-Fenster, Fotografien, Videos, Audiodateien oder andere Medien und interaktive Funktionen sein. Das ganze wird in eine Benutzeroberfläche integriert und soll für ein breites, nicht technisches Publikum zugänglich und verständlich sein. Story Maps sollen informieren, bilden, unterhalten und den Benutzer miteinbeziehen. (Esri, 2012) Abbildung 2.1: Beispiel einer Esri Story Map von Matt Artz (Esri, 2014) Abbildung 2.1 zeigt ein Beispiel einer Story Map von Esri. Die Karte erzählt die Geschichte von Charles Darwin, der während seiner Reise auf der HMS Beagle zahlreiche Dinge erlebt und 2 Storytelling with Maps (Esri): 3 Geostories (National Geographic): 4 MapStories (MapStory Foundation): 5

14 2 FORSCHUNGSÜBERBLICK gesehen hat. Die Karte enthält sowohl Punkt- als auch Linienobjekte, die mit Informationen verbunden sind. Zu jeder Station gibt es Bilder und Texte, welche Hintergrundinformationen zu dieser langen Reise liefern. Lu und Arikawa (2013) sind der Ansicht, dass die Menschen neues Wissen akquirieren, indem sie es mit ihrem bisherigen Wissen, mit ihren Erfahrungen und mit den aktuellen Umständen verbinden. Herkömmliche Karten vermögen durchschnittliche Menschen, die das Lesen von Karten nicht gewohnt sind, nicht effizient mit neuem Wissen zu versorgen. Der Grund dafür ist, dass die Karten praktisch keine Verbindung zum Wissensstand und zur aktuellen Situation der Leute herstellen. Wenn Stories mit Karten verbunden werden, das heisst wenn Texte, Bilder oder Videos, die einen Bezug zum Thema haben, in Karten eingefügt werden, ermöglicht dies dem Betrachter, einen direkten Bezug zwischen diesen Stories und der realen Welt herzustellen. Wer eine Story Map erstellt, sollte verschiedene Kapitel, Abschnitte, Hervorhebungen, Verzierungen und Vereinfachungen nutzen, um die Karte möglichst beeindruckend und hilfreich zu gestalten. Ein etwas anderer Ansatz stammt nach Krygier (2013) vom New Yorker Jake Barton. Er befasst er sich mit der Leistungsfähigkeit von Karten und fragt sich, was kann mit Karten alles erreicht werden kann? Sein Projekt City of Memory 5 besteht aus einer Karte von New York, zu welcher Benutzer Stories hinzufügen, diese mit anderen verlinken und mit der Community teilen können. Dieses Projekt soll die New Yorker aufgrund einer gemeinsam erstellten Geschichte über ihre Stadt verbinden. Barton zeigt damit, dass Story Maps dazu verwendet werden können, Menschen ein Gefühl von Gemeinschaft zu geben. [murmur] ist ein ähnliches Projekt, das im Jahr 2003 in Toronto lanciert wurde. Menschen sollen alltägliche Geschichten, Anekdoten und Erinnerungen, die an spezifische geografische Orte gebunden sind, erzählen. An diesen Orten, welche für die Erfasser wichtig sind, werden [murmur]-symbole installiert, auf denen eine Nummer steht. Jeder Passant kann diese Nummer mit seinem Mobiltelefon anrufen und sich die Geschichte vor Ort anhören. Ob es sich nun um Geschichten persönlicher oder historischer Natur handelt, die intime, nachbarschaftliche Stimme, die eine alltägliche Story erzählt, steht dabei im Vordergrund. Solche Geschichten können einem unauffälligen, grauen Gebäude Leben einhauchen und die Art, wie Leute über einen Ort oder eine Stadt denken, beeinflussen. ([murmur], 2003) Zusammenfassend lässt sich sagen, dass es für Storytelling Maps zahlreiche verschiedene Möglichkeiten gibt, die ständig erweitert werden. Mit der hier vorliegenden Arbeit, die sich mit der Verbindung von Karten und literarischen Informationen beschäftigt, wird im weiteren Sinne eine Storytelling Map erstellt Mobile Kartografie Erfahrungen haben gezeigt, dass trotz zahlreicher alternativen Möglichkeiten Karten noch immer eine wichtige Rolle in der Übermittlung von raumbezogenen Informationen sind, auch auf mobilen Geräten. Mit der optimalen Verwendung von Karten auf solchen Geräten befassen sich die sogenannten Karten-basierten mobilen Dienste, ein Typ von value-added LBS (Meng & Reichenbacher, 2005). 5 City of Memory: 6

15 2 FORSCHUNGSÜBERBLICK Während der letzten Jahre haben sich die Möglichkeiten der mobilen Datenverarbeitung und der mobilen Kommunikationsnetzwerke ständig erweitert. Dadurch ist eine Lücke entstanden zwischen den modernen technologischen Möglichkeiten und den theoretischen Grundlagen der Kartografie (Hauthal & Burghardt, 2012). Dies bringt einige Veränderungen für den Bereich der Kartografie mit sich und stellt die Kartografen vor neue Herausforderungen. Nach Reichenbacher (2007) gibt es drei Haupttypen von Kartennutzung: die stationäre Kartennutzung, die mobile Kartennutzung und die universelle Kartennutzung. Während sich die stationäre Nutzung auf Computer bezieht, die ihren Standort grundsätzlich nicht ändern, geht es bei der universellen Kartennutzung um die Verwendung von Karten, die von verteilten und eingebetteten Recheneinheiten zur Verfügung gestellt und dargestellt werden. Für die vorliegende Arbeit ist vor allem die mobile Kartennutzung, also die Nutzung von Karten auf mobilen Geräten relevant. Diese Art der Nutzung wird beeinflusst von den sich ändernden Fortbewegungsarten des Benutzers, den verschiedenen Aktivitäten neben der Kartennutzung und der Möglichkeit von Ablenkungen verschiedenster Art. Eine zusätzliche Schwierigkeit sind die allgemein schwierigeren und veränderten Nutzungsbedingungen, wie zum Beispiel die kürzere zur Verfügung stehende Zeit für das Betrachten des Displays und der Karte oder die neuen Interaktions-Mechanismen für mobile Geräte. Weitere Einschränkungen bringt die Nutzung eines solchen Gerätes mit sich, welches eine sehr kleine Bildschirmgrösse, eine tiefe Auflösung, eine reduzierte Rechenleistung und Speicherkapazität, eine kurze Akkulebensdauer sowie eine kleinere Bandbreite bei der Internetverbindung aufweist. (Reichenbacher (2007); Setlur et al. (2010)) Aufgrund der oben erwähnten Gegebenheiten müssen mobile Karten anderen Anforderungen gerecht werden als Karten für Desktop-Anwendungen. Auf dem kleinen Bildschirm dürfen nicht zu viele Details gezeigt werden. Trotzdem muss der Benutzer der Karte die gewünschte Information entnehmen können. Deshalb müssen die für den mobilen Gebrauch wichtigen Informationen, wie Points of Interest (POI), Routen, Areas of Interes (AOI), Sehenswürdigkeiten, Resultate von Suchabfragen oder Multimedia-Ergänzungen wie Bilder, Texte und Musik, wirksam visualisiert werden. Um dies zu ermöglichen, können zum Beispiel der Detaillierungsgrad der Karte geändert, Hervorhebungseffekte verwendet, Objekte vereinigt oder nicht relevante Informationen weggelassen werden (Setlur et al., 2010). Nach Reichenbacher (2007) können zusätzlich die Minimaldimensionen stark vergrössert und Texte dort, wo nicht unbedingt nötig, weggelassen werden. Zusammengefasst kann gesagt werden, dass die Karte sehr stark generalisiert werden und in einem möglichst einfachen, kompakten und selbsterklärenden Interface daherkommen muss. Damit wird die Informationsdichte reduziert, sodass der Bedeutung gegenüber der Vollständigkeit der Vortritt gelassen wird. Wie bereits erwähnt, bieten mobile Geräte andere Interaktionsmöglichkeiten als Desktop- Computer. Mit Hilfe des Global Positioning Systems (GPS) können Kartendaten, angepasst an den Ort des Benutzers, in Echtzeit geliefert werden (Setlur et al., 2010). Sowohl der Informationsinhalt als auch dessen Darstellung soll an das System, die Aktivität, das Wissen und die Umgebung des Benutzers angepasst werden. Eine mobile Karte muss eine personalisierte Darstellung ermöglichen und die Anpassungen innerhalb einer vertretbaren Zeit anbringen können. Bezüglich der Verwendung von mobilen Kartenapplikationen unterscheidet Reichenbacher (2007) zwischen zwei Nutzerszenarien. Beim ersten Szenario wird das Gerät zuerst an einem 7

16 2 FORSCHUNGSÜBERBLICK bestimmten Ort benutzt, um einen Ausflug zu planen oder relevante Information auszuwählen, welche unterwegs mit zusätzlichen Informationen ergänzt werden kann. Im Gegensatz dazu ist der Benutzer des zweiten Szenarios mobil und sämtliche Information wird über das mobile Netzwerk heruntergeladen, was je nach Datenmenge zu hohen Kosten führen kann. Ein Ziel der vorliegenden Arbeit ist es, die Kosten möglichst tief zu halten. Deshalb wird grundsätzlich das erste Szenario gewählt, mit der Anpassung, dass vor Ort keine Ergänzungen mehr angebracht werden. Weil die zu erstellende App eine Karte enthalten soll, ist das Forschungsgebiet der mobilen Kartografie von grosser Bedeutung. Es muss eine Lösung gefunden werden, die für ein mobiles Gerät passend ist und trotzdem eine optimale Darstellung literarischer Daten ermöglicht. 2.2 Standortbezogene Dienste Definition Standortbezogene Dienste, besser bekannt unter dem englischen Namen (mobile) Locationbased Services oder abgekürzt (m)lbs gewinnen immer mehr an Bedeutung. Brimicombe und Li (2006, S. 109) definieren mlbs als «the delivery of data and information services where the content of those services is customised to the current or some projected location and context of the user». Das heisst so viel wie LBS sind die Lieferanten von Daten und Informationen, deren Inhalt angepasst ist an den aktuellen oder geplanten Standort des Benutzers. Somit können mobile standortbezogene Dienste den Benutzer in der mobilen Entscheidungsfindung unterstützen. Sie setzten die aktuelle Position des Benutzers mit der umliegenden Umwelt in Verbindung und sind somit in der Lage, standortspezifische Informationen zu liefern. Dies erleichtert die erfolgreiche Erfüllung von räumlich-zeitlichen Aufgaben. Zum Beispiel informieren LBS die Benutzer über den Standort von Hotels, Restaurants oder kulturellen Sehenswürdigkeiten in der Nähe oder unterstützen den Reisenden auf der Suche nach optimalen Zugverbindungen. Vielleicht sind sie einem Benutzer auch bei der Lokalisierung von Freunden und Bekannten, die sich innerhalb eines gewissen Umkreises von seiner aktuellen Position befinden, behilflich. (Raubal, 2011) Technischer Hintergrund Dank immer grösserer Verfügbarkeit und verbesserten Funktionalitäten von mobilen Geräten und deren Entwicklung vom einfachen Spielzeug zum leistungsstarken Werkzeug werden Türen für neue Technologien geöffnet. Für den Bereich der standortbezogenen Dienste braucht es neben den mobilen Geräten verschiedene Technologien, wie zum Beispiel Geoinformationssysteme (GIS), Internet oder die sogenannten neuen Informationsund Kommunikationstechnologien (NICTs). Diese Technologien, die sich kontinuierlich entwickeln, in Kombination mit dem Global Navigation Satellite System (GNSS), machen standortbezogene Dienste erst möglich. (Brimicombe & Li, 2009) Abbildung 2.2 zeigt LBS als die Überschneidung von GIS, Internet und neuen Informationsund Kommunikationstechnologien. 8

17 2 FORSCHUNGSÜBERBLICK GIS / räumliche Datenbanken Internet GIS LBS Wireless GIS Internet Wireless Internet NICTs Abbildung 2.2: LBS an der Schnittstelle verschiedener Technologien (nach Brimicombe und Li (2006)) Wie bereits erwähnt, spielt die Positionsbestimmung eine wichtige Rolle bei den LBS. Sie kann entweder aktiv, zum Beispiel über den im mobilen Gerät integrierten GPS-Empfänger, oder passiv, das heisst über eine Netzwerkverbindung wie das Mobiltelefonnetz, bestimmt werden. Der Nachteil von GPS ist, dass es im Innern von Gebäuden, an überdeckten Orten und in Städten mit hohen Häusern nicht funktioniert. Dort muss auf andere Technologien, wie Radio Frequency Identification (RFID) oder WiFi zurückgegriffen werden (Raubal, 2011) Architekturen Die Technologie standortbezogener Dienste ist eine heterogene Technologie, die eine gewisse Anzahl von Unterarchitekturen miteinander vereint. Nach Brimicombe und Li (2009) müssen für einen standortbezogenen Dienst fünf Hauptkomponenten zusammengeführt werden. Abbildung 2.3 zeigt das Zusammenspiel dieser Bestandteile. Als erstes müssen Informationen über die Realwelt, in der sich der Benutzer befindet, zur Verfügung stehen. Diese Informationen können über das Internet oder über Datenbanken erreichbar sein und an die aktuelle Position des Benutzers angepasst werden. In einem weiteren Schritt muss ausgewählt werden, welche Art eines mobilen Gerätes zum Einsatz kommen soll. Als dritte Komponente werden die Positionierungssysteme aufgeführt, die benötigt werden, um die Position des mobilen Gerätes zu bestimmen. Zusätzlich braucht es ein kabelloses Netzwerk, zum Beispiel Bluetooth, WiFi, ein mobiles Telekommunikationsnetzwerk oder eine Kombination aus den Genannten, durch welches das mobile Gerät mit dem Server kommunizieren kann. Es müssen Benutzeranfragen und die darauf folgenden Antworten des Dienstanbieters über dieses Netzwerk geschickt werden können. Der letzte Bestandteil ist der Anbieter des standortbezogenen Dienstes. Dieser enthält die für den Dienst benötigte Software (zum Beispiel ein GIS) und andere Komponenten, welche für die Bearbeitung von Abfragen und die Lieferung der standortabhängigen Antworten zuständig sind. 9

18 2 FORSCHUNGSÜBERBLICK LBS Provider GPS Wireless Netzwerk Mobiles Gerät Dienste und Datenbanken? Internet Benutzer Abbildung 2.3: Überblick über die Architektur von standortbezogenen Diensten (aus Brimicombe und Li (2009)) Neben dem bereits diskutierten Schlüsselaspekt, den Benutzer zu lokalisieren, ist es wichtig, den Kontext, in welchem der standortbezogene Dienst verwendet wird, zu kennen. Dey (2000, S. 4) definiert Kontext als «any information that can be used to characterize the situation of an entity», wobei eine Entität als «a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and application themselves» bezeichnet wird. Kontext-Bewusstsein ist nötig, um dem Benutzer in mobilen Situationen auf ihn zugeschnittene Daten zur Verfügung stellen zu können. Es kann auch dabei helfen, das Systemdesign zu verbessern, relevante Inhalte zu identifizieren und passende Dienste zu liefern. Als Kontextinformation gelten zum Beispiel die Situation und die Position des Benutzers und dessen Umgebung, sowie die aktuelle Tageszeit, das Datum oder in den LBS involvierte Technologien. Auch Charakteristiken, persönliche Vorlieben und das Verhalten des Benutzers können im Kontext enthalten sein. Ein Beispiel für einen kontextbezogenen Dienst ist eine App für das Finden von Restaurants, welche nicht nur das nächste, sondern das für ihn beste Restaurant vorschlägt. Das heisst, es werden neben der aktuellen Position des Benutzers auch seine aktuellen Präferenzen berücksichtigt (Zhu et al., 2010). Zusammenfassend sehen Brimicombe und Li (2009) die Hauptaufgabe des Kontextverstehens darin, einem Dienstanbieter die Grundlagen zu liefern, um den Benutzer in mobilen Situationen mit für ihn möglichst nützlichen Informationen zu versorgen. App-Architekturen Im Zeitalter der multifunktionalen Mobiltelefone hat sich eine sehr heterogene Systemlandschaft entwickelt. Es existieren zahlreiche mobile Plattformen, wie Android, ios, Blackberry oder WindowsPhone. Für jedes wird vom Hersteller ein Entwicklungssystem vorgegeben, das für die Entwicklung von für die Plattform kompatiblen Applikationen verwendet werden muss. Bei der Entwicklung einer Applikation stellt sich also die Frage, welche dieser Plattformen unterstützt werden sollen. Werden alle unterstützt, führt dies dazu, dass die Kosten für die Entwicklung und den Unterhalt einer Applikation in die Höhe schiessen. Es wird deshalb vermehrt versucht, Konzepte zu erarbeiten, die es ermöglichen, Anwendungen für 10

19 2 FORSCHUNGSÜBERBLICK verschiedene Mobilplattformen zu erstellen. Das Prinzip «einmal entwickeln überall ausführen» wird übertragen auf die mobile Welt. (Willnecker et al., 2012) Grundsätzlich kann zwischen drei Systemarchitekturen für Anwendungen für mobile Geräte unterschieden werden. Diese drei Arten von Anwendungen sind Web-Apps, hybride und native Apps. Während Web-Apps internetfähige Anwendungen mit speziellen Funktionalitäten für mobile Geräte sind, die von einem beliebigen Gerät über einen Web-Browser aufgerufen werden, sind native Apps auf eine bestimmte Plattform zugeschnitten, müssen heruntergeladen und installiert werden. (Mudge, 2012) Web-Apps erscheinen zunächst als mehr oder weniger plattformunabhängig, müssen jedoch Abstriche im Funktionsumfang in Kauf nehmen. Die grundlegende Technologie, die hinter solchen Web-Apps steckt, ist immer die gleiche. Alt-bekannt und bewährt werden dafür die Hypertext Markup Language (HTML), JavaScript (JS) und Cascading Style Sheets (CSS) verwendet. Um auf die Sensoren der Geräte zugreifen zu können, braucht es wiederum proprietäre Software, die von den Betreibern der Betriebssysteme zur Verfügung gestellt werden. Da für jedes dieser Betriebssysteme eine Menge an unterschiedlichen Browsern vorhanden ist, welche die HTML-Standards unterschiedlich interpretieren, kann auch bei dieser Architektur nicht von vollständiger Plattformunabhängigkeit gesprochen werden. (Willnecker et al., 2012) Mit den sogenannten hybriden Apps wird der Ansatz der Web-Apps erweitert und eine API (Application Programming Interface) zur Verfügung gestellt, die den direkten Zugriff auf die Sensoren des Gerätes erlaubt. Aus den bekannten Beschreibungssprachen aus dem Web werden mit Entwicklungswerkzeugen, zum Beispiel mit PhoneGap 6 oder Titanium Framework 7, Applikationen generiert, die einer nativen App sehr ähnlich sind. PhoneGap ist ein Open-Source Framework, mit dem solche, auf gewisse Weise plattformunabhängige, mobile Applikationen erstellt werden können. Es stellt eine Verbindung zwischen Web- Applikation, die auf HTML5, CSS und JavaScript basieren, und mobilen Geräten her. Die Web- App wird in eine Hülle eingepackt, die der jeweiligen Plattform angepasst ist und kann somit wie eine native App über den App Store, Google Play oder andere App-Verteilzentren heruntergeladen und installiert werden. (Adobe Systems Inc., 2014) Im Gegensatz dazu stehen die nativen Apps. Diese müssen mit der jeweils geforderten Entwicklungsplattform der verschiedenen Smartphone-Betriebssysteme erstellt werden. Dies bringt zwar, wie bereits erwähnt, grosse Kosten für die Entwicklung und den Unterhalt von Multiplattform-Applikationen mit sich, es kann damit jedoch noch immer der grösste Funktionsumfang erreicht werden. (Willnecker et al., 2012) Mobile Reiseführer Eine besondere Art von LBS sind mobile Reiseführer. Sie dienen dazu, einem Touristen den Besuch eines fremden Ortes einerseits zu vereinfachen und andererseits zu einem einmaligen Erlebnis zu machen. Mobile Reiseführer haben im Laufe des letzten Jahrzehnts an Bedeutung gewonnen. Für immer mehr Orte, die von Touristen besucht werden, stehen solche Reiseführer zur Verfügung, sei es als Orientierungs- und Navigationshilfe in Städten 6 PhoneGap:

20 2 FORSCHUNGSÜBERBLICK oder als Führer mit spezifischen Informationen zu einem Thema, zum Beispiel zu Ausstellungsstücken in einem Museum. Nach Kenteris et al. (2011) hat zu dieser Entwicklung vor allem die Konvergenz von Internet, Informations- und Telekommunikationstechnologie beigetragen. Dadurch ergaben sich neue Technologien für die Verbreitung von Informationen unter Touristen. Einerseits benutzen Touristen die Informationstechnologie, um sich über die Orte, die sie zu besuchen gedenken, zu informieren, andererseits macht sich die Industrie diese Technologie zunutze, um die gewünschte Information anzubieten. In Folge existieren zahlreiche Webseiten, Blogs, Touristen-Tagebücher und Wikis, welche es dem Touristen ermöglichen, sich in einem persönlichen Informationsraum zu informieren oder sich mit anderen Touristen auszutauschen. Auf der anderen Seite stehen die modernen Smartphones, mit denen unterwegs verschiedenste Applikationen, also auch mobile Reiseführer, genutzt werden können. Wird der mobile Reiseführer einer Destination zum Beispiel von der lokalen Tourismusbranche angeboten, steht diesen ein sehr leistungsstarkes Instrument für die Verteilung von Information zur Verfügung. Zusätzlich können sie sich Wissen über das Verhalten eines Gastes vor Ort aneignen, was ihnen bei der Weiterentwicklung des Reiseführers eine grosse Hilfe ist. (Elgersson, 2006) Der Entwickler eines mobilen Reiseführers muss mindesten drei Grundsätze im Hinterkopf haben: das zu verwendende Informationsmodell, der besondere Dienst, der angeboten wird und die In- und Output Modalitäten, welche im ganzen Projekt enthalten sein sollen. Bezüglich des Informationsmodells gibt es hauptsächlich drei Auswahlmöglichkeiten: ein dezentralisiertes Modell, ein zentralisiertes Modell oder ein verteiltes dynamisches Modell. Das dezentralisierte Modell ist eine on-device Lösung, bei der sämtliche verwendeten Daten auf dem Gerät gespeichert sind. Der Vorteil dieses Modells ist, dass für die Verwendung der App keine Datenverbindung mehr nötig ist, sobald die Daten lokal gespeichert sind. Ein Nachteil ist, dass Updates nicht so einfach ausgeführt werden können. Die zentralisierte Herangehensweise wird meist in Verbindung mit Hypermedia Inhalten verbunden, was einfache Updates oder den Zugriff auf verschiedene mobile Geräte ermöglicht, jedoch hohe Verbindungskosten erzeugen kann. Das verteilte dynamische Modell wird verwendet, um über die Umgebung von Netzwerkknoten spezifische Inhalte an den Benutzer zu senden. Dies setzt voraus, dass eine Netzwerkinstallation zur Verfügung steht. (Kenteris et al., 2011) Eine interessante Erweiterung von mobilen Reiseführern ist die Verwendung der Augmented-Reality-Technologie. Nach El Choubassi et al. (2010) kann diese Technologie in Verbindung mit mobilen Geräten dazu benutzt werden, Touristeninformation auf eine viel eindringlichere Art zu liefern, als auf traditionelle Weise mit Karten und Texten. Um dies zu erreichen, wird eine Kombination von Kamera, Positionierungs- und Orientierungssensoren verwendet, um die Kamera-Ansicht live mit Hinweisen zu den im Ausschnitt liegenden Objekten zu erweitern. Diese ergänzende Information wird dadurch erhalten, dass das Kamerabild mit Bildern aus einer Datenbank auf einem Server abgeglichen wird, welche aus der näheren Umgebung der aktuellen Benutzerposition stammen. 12

21 3 ERSTELLUNG VON TRIGGER-REGIONEN 3 Erstellung von Trigger-Regionen In diesem Kapitel werden die für die App benötigten Trigger-Regionen beschrieben. Es wird definiert, was in der vorliegenden Arbeit unter Trigger-Region verstanden wird. Verschiedene Ansätze für die Berechnung von Trigger-Regionen werden vorgestellt, bevor konkrete Anforderungen formuliert werden, die eine Trigger-Region erfüllen muss, damit sie ihren Zweck erfüllt. In einem nächsten Schritt werden die Daten, die für die Erstellung der Regionen notwendig sind, beschrieben. Schliesslich wird auf die zwei verschiedenen Vorgehen, das eine manuell, das andere automatisch, eingegangen. Es wird aufgezeigt, wie aus den Input-Daten Trigger-Regionen entstehen und welche Überlegungen hinter dem entwickelten Algorithmus stecken. 3.1 Grundlagen Ein Trigger ist nach dem Oxford Dictionary (2013) «an event that is the cause of a particular action, process, or situation», also ein Ereignis, welches eine bestimmte Handlung, einen Prozess oder eine Situation auslöst. Bei einer Trigger-Region ist das Ereignis als räumliches Ereignis zu verstehen. Im Zusammenhang mit standortbezogenen Diensten bedeutet dies, dass ein Prozess ausgelöst wird, sobald sich der Benutzer des Dienstes in eine solche Trigger- Region begibt Ansätze für die Berechnung der Trigger-Regionen Der erste Schritt, der bei der Berechnung der Trigger-Regionen unternommen werden muss, ist das Durchführen einer Sichtbarkeitsanalyse. Dafür gibt es in ArcGIS zwei verschiedene Werkzeuge. Das erste ist das sogenannte Beobachterpunkte Werkzeug aus der Spatial Analyst Toolbox. Aus einem digitalen Höhenmodell (Rasterdatei) und der Koordinaten der Schauplätze (Beobachterpunkte) kann ein Raster berechnet werden, dessen Zellenwerte angeben, welche Schauplätze von dort aus sichtbar sind. In einer Tabelle werden diese Ergebnisse zusammengefasst. Für jede auftretende Kombination aus sichtbaren Schauplätzen wird die Anzahl der Rasterfelder aufsummiert, von denen aus die entsprechende Kombination der Schauplätze sichtbar ist (Spalte «COUNT» in Abbildung 3.1). Die folgenden Spalten (Spalte «OBS1» bis «OBS14» in Abbildung 3.1) enthalten eine Eins für jeden sichtbaren und eine Null für jeden nicht sichtbaren Schauplatz (Esri, 2013c). Mit dieser Analyse kann herausgefunden werden, von wo aus nur ein oder zwei Schauplätze sichtbar sind. In Abbildung 3.1 sind diejenigen Rasterzellen grün hervorgehoben, von denen aus man sowohl Luzern als auch den Pilatus sehen kann. Das bedeutet in der Attributtabelle steht sowohl bei Luzern (OBS1) als auch beim Pilatus (OBS2) eine Eins. 13

22 3 ERSTELLUNG VON TRIGGER-REGIONEN Abbildung 3.1: Beispiel Beobachterpunkte-Analyse Mit dem zweiten zur Verfügung stehenden Werkzeug wird eine Sichtfeld-Analyse durchgeführt. Dieses Werkzeug ist ebenfalls Bestandteil der Spatial Analyst Toolbox. Abbildung 3.2 zeigt das Resultat einer Sichtfeld-Analyse. Aus der Ergebnistabelle des neu erstellten Rasters ist ersichtlich, wie viele Schauplätze von jeder Rasterzelle aus sichtbar sind. Von den in der Abbildung hervorgehobenen Zellen sind zwar jeweils genau fünf Schauplätze zu sehen, es ist jedoch nicht bekannt, um welche es sich handelt. Abbildung 3.2: Beispiel Sichtfeld-Analyse Um dies herauszufinden, muss die Analyse für jeden Ort separat durchgeführt werden, was ein Nachteil dieser Variante ist. Denn, wie die Beobachterpunkte-Analyse, ist die Sichtfeld- Analyse sehr rechenintensiv. Wird hingegen die Information über die Sichtbarkeit für jeden Schauplatz einzeln benötigt und es nicht wichtig ist, wie viele von wo aus gesehen werden können, eignet sich die Sichtfeld-Analyse ebenso gut. Als nächstes stellt sich die Frage wie eine Trigger-Region definiert werden soll. Dafür gibt es mehrere Möglichkeiten. Drei davon sind im nächsten Abschnitt kurz beschrieben: Für jeden Schauplatz gibt es eine Trigger-Region mit einer bestimmten Grösse (alle Trigger-Regionen sind gleich gross). Die Anzahl der Regionen ist somit klar definiert und entspricht der Anzahl der Schauplätze. 14

23 3 ERSTELLUNG VON TRIGGER-REGIONEN Eine Trigger-Region bestimmter Grösse löst Informationen zu allen aktuell sichtbaren Schauplätzen aus. Dies kann bedeuten, dass es gleich viele Trigger-Regionen wie Schauplätze gibt, indem zwar für jeden Schauplatz die «optimale» Region bestimmt wird, aber die Informationen auch in anderen Regionen, in denen der Schauplatz sichtbar ist, verfügbar sind. dass es eine reduzierte Anzahl Trigger-Regionen gibt, indem mehrere Schauplätze zusammengefasst werden. Nach welchen Kriterien sie zusammengefasst werden, müsste definiert werden. Eine Trigger-Region kann beliebig gross sein und wird direkt aus dem Resultat der Sichtbarkeitsanalyse erstellt. Das heisst, man befindet sich immer dann in der Region eines Schauplatzes, wenn dieser sichtbar ist. Dies führt dazu, dass sich die einzelnen Regionen überlappen. Bei jeder dieser drei Varianten gibt es gewisse Vor- und Nachteile. Zum Beispiel ist die verfügbare Zeit für das Studieren der Informationen über einen Schauplatz beim ersten Vorschlag begrenzt, obwohl der Schauplatz eigentlich länger sichtbar wäre. Dafür kann sich der Benutzer in dieser Zeit voll und ganz auf diesen Schauplatz konzentrieren. Mit der zweiten Möglichkeit kann der Nachteil der ersten umgangen werden, es ergibt sich dafür ein anderes Problem. Die Erstellung von Panoramen für die Orientierungshilfe (siehe Abschnitt 4.3.3) wird komplizierter, da nicht klar ist, für welchen Punkt diese generiert werden sollen. Ebenfalls ein Nachteil könnte es sein, dass der Benutzer sich zuerst Informationen über einen Schauplatz ansieht, der noch längere Zeit zu sehen ist und dafür die Informationen eines anderen verpasst, der nur kurze Zeit sichtbar ist. Neben diesen Ansätzen gibt es zwei weitere Kriterien, die berücksichtigt werden können. Es kann argumentiert werden, dass keine Informationen vorhanden sein sollen, wenn sich das Schiff an einer Anlegestelle befindet. Diese Bedingung könnte umgesetzt werden, indem ein Puffer um die Anlegestellen gelegt wird, innerhalb dessen Ausdehnung keine Trigger-Region liegen darf. Zusätzlich muss abgewägt werden, ob die Distanz zum Schauplatz als Parameter in die Berechnung einfliessen soll. Damit könnte versucht werden, die Trigger-Region möglichst nahe beim Schauplatz zu platzieren Anforderungen Für die Erstellung eines Tools muss eine der in Abschnitt vorgestellten Varianten ausgewählt werden. Da die Orientierungshilfe ein wichtiger Bestandteil der App ist und die Generierung der Panoramen bei der dritten Möglichkeit kompliziert ist, wird diese Möglichkeit ausgeschlossen. Aufgrund der Tatsache, dass der Benutzer die Region nicht kennt und somit nicht weiss, welche Orte wann und wie lange zu sehen sind, wird entschieden, die erste Variante umzusetzen. Damit ist die Gefahr, dass er einen Schauplatz verpasst kleiner und er wird auf seiner Reise durch die Schauplätze geführt. Bevor ein Algorithmus für die Berechnung entwickelt werden kann, muss definiert werden, welche Anforderungen eine Trigger- Region erfüllen muss: Die Route des Schiffes muss durch die Trigger-Region verlaufen Da sich der Benutzer auf dem Schiff aufhält, kann seine Position nicht ausserhalb der Schiffsfläche und somit nicht weit entfernt von dessen Route liegen. 15

24 3 ERSTELLUNG VON TRIGGER-REGIONEN Von jeder Trigger-Region muss ein Schauplatz sichtbar sein Optimal wäre es, wenn jeweils genau ein Schauplatz sichtbar wäre und der Benutzer seine volle Aufmerksamkeit diesem Schauplatz widmen kann. Keine räumliche Überlappung der einzelnen Trigger-Regionen Da immer nur ein Prozess ausgelöst werden soll, der Informationen über einen Schauplatz liefert, dürfen sich die Regionen nicht überlappen. Keine zeitliche Überlappung Eine Informationssequenz hat eine gewisse Dauer. Diese muss bei der Berechnung der Trigger-Regionen berücksichtigt werden, damit sich die Informationssequenzen verschiedener Schauplätze nicht überlappen. Die Dauer der einzelnen Sequenzen muss also bekannt sein. Falls nötig wird um die Region ein weiterer Puffer gelegt, der diesen zeitlichen Aspekt berücksichtigt. Es wird eine Methoden erarbeitet, mit der Regionen erstellt werden können. Diese Methode soll, wenn möglich, alle oben genannten Kriterien erfüllen Input-Daten Damit die Trigger-Regionen berechnet werden können, braucht es verschiedene Input- Daten (Abbildung 3.3). Da von den Trigger-Regionen Schauplätze sichtbar sein müssen, muss bekannt sein, wo sich diese befinden. Ein Schauplatz kann ein Berg, eine Region oder eine Ortschaft sein. Es stellt sich also die Frage, wie ein solcher Schauplatz definiert werden kann. Ein Berg wird auf einer Karte üblicherweise als Punktobjekt dargestellt. Da dieser Punkt auf der Bergspitze zu liegen kommt, ist diese Definition sicher geeignet. Doch wie sieht es mit Ortschaften aus? Ein Dorf kann nicht mit einem einzigen Punkt abgedeckt werden. Es weist eine gewisse Fläche auf und verlangt damit eher nach einer Definition durch ein Polygon. Doch auch damit ist seine Ausdehnung bezüglich der Sichtbarkeit nicht klar definiert. Sollte nur das Siedlungsgebiet, also die bebaute Fläche, oder auch die umliegenden, zur Gemeinde gehörenden Wälder, Wiesen und Hügel einbezogen werden. Ist dies definiert, bleibt die Tatsache bestehen, dass es schwieriger ist, mit einem Inputfile, das verschiedene Arten von Geometrien enthält, einen Algorithmus zu finden, der zufriedenstellende Resultate liefert. Deshalb wird entschieden, für das zu erstellende Tool die vereinfachte Annahme zu treffen, dass eine Ortschaft als Punktobjekt definiert werden kann. Das bedeutet, dass das erste Inputfile eine Feature Class ist, welche die einzelnen Schauplätze in Form von Punktobjekten enthält. Zusätzlich zur 2D-Geometrie müssen eine ID und der Name des Schauplatzes in der Attributtabelle enthalten sein. Abbildung 3.3: Inputdaten (Schauplätze, Schiffsroute, DHM) für die Berechnung von Trigger-Regionen, Basiskarte von Esri Der zweite benötigte Datensatz ist die Route, die das Schiff auf dem See zurücklegt. Da diese einzelne Polylinie nicht für die Benennung der Trigger-Regionen benötigt wird, braucht es 16

25 3 ERSTELLUNG VON TRIGGER-REGIONEN keine weiteren Attribute. Um gewährleisten zu können, dass der Schauplatz von der berechneten Region aus sichtbar ist, muss eine Sichtbarkeitsanalyse durchgeführt werden. Dafür bedarf es eines digitalen Höhenmodells (DHM), das heisst eines digitalen Rasterdatensatzes, der «die Form der Erdoberfläche in 3D beschreibt», wobei «jedes Koordinatenpaar X und Y [ ] eine Höhe Z» erhält (swisstopo, 2013). Nachfolgend werden die Datensätze beschrieben, welche konkret für die Beispielregion Vierwaldstättersee verwendet wurden. Die Koordinaten der Schauplätze wurden mit Hilfe von ArcMap aus einer Karte abgegriffen und in einem Feature Layer gespeichert. Die Schiffsroute wurde während einer Schifffahrt mit einem Garmin etrex Legend 8 Empfänger aufgezeichnet. Hierbei ist zu erwähnen, dass diese Messung nur einmal durchgeführt wurde. Das bedeutet, dass diese Route möglicherweise nicht repräsentativ für die mittlere Route ist. Die Messgenauigkeit von GPS und die Genauigkeit, mit der das Schiff auf seiner vordefinierten Route fährt, können zu Abweichungen von dieser mittleren Route führen. Da diese Genauigkeit bei der vorliegenden Arbeit keine grosse Rolle spielt und die Breite einer Trigger-Region als Input des Berechnungstools frei gewählt werden kann, werden diese Daten als genügend genau betrachtet und für das weitere Vorgehen verwendet. Als digitales Höhenmodell, der dritte Inputdatensatz, wird das DHM25 von der swisstopo 9 benutzt. Dieses Modell basiert auf der Landeskarte 1: und weist bei einer Maschenweite von 25 Metern eine Genauigkeit von 1.5 bis 10 Metern auf (swisstopo, 2013). Mit diesen drei Datensätzen werden die Trigger- Regionen, die später für die App verwendet werden, berechnet Input-Parameter Damit der Aspekt der zeitlichen Überschneidung berücksichtigt werden kann, müssen Trigger-Regionen eine Minimallänge aufweisen. Diese Länge berechnet sich aus der durchschnittlichen Schiffsgeschwindigkeit und der Zeit, die für das Betrachten der Informationen benötigt wird. Für den Vierwaldstättersee werden diesbezüglich folgende Annahmen getroffen. Die Route von Luzern nach Flüelen ist 43.8 Kilometer lang, dauert zwei dreiviertel Stunden und beinhaltet neben Start- und Zielort elf Anlegestellen, an denen das Schiff etwa drei Minuten still steht. Daraus ergibt sich eine durchschnittliche Geschwindigkeit von etwa 20 Kilometern pro Stunde. Eigene GPS-Messungen haben ergeben, dass die maximale Geschwindigkeit circa 25 Kilometer pro Stunde beträgt. Um zu gewährleisten, dass keine zeitlich überlappenden Trigger-Regionen entstehen, wird mit diesem Wert als Durchschnittsgeschwindigkeit gerechnet. Eine Informationssequenz soll ungefähr drei Minuten dauern, mit der Möglichkeit, sich die Informationen später nochmal anschauen zu können. In drei Minuten legt ein Schiff mit einer Geschwindigkeit von 25 Kilometer pro Stunde 1.25 Kilometer zurück. Es wird eine zeitliche Reserve von 1.5 Minuten addiert, was zu einer Strecke von Kilometern führt. Dieser Wert wird für die manuelle und die automatische Berechnung der Trigger-Region verwendet (siehe Abschnitte 3.3 und 3.4). 8 Garmin etrex Legend: 9 Swisstopo: 17

26 3 ERSTELLUNG VON TRIGGER-REGIONEN 3.2 Verwendete Technologien Für diesen Teil der Arbeit ist technologisch vor allem eine Software Produktepalette von Bedeutung. ArcGIS ist der Überbegriff für eine Reihe von GIS-Softwareprodukte der Firma Esri 10. Es wird hauptsächlich mit ArcMap, einem Bestandteil von ArcGIS Desktop gearbeitet. Dieses Programm kann für die Darstellung und Analyse von Geodaten genutzt werden. In der darin integrierten ArcToolbox sind zahlreiche Modellierungs- und Analyse-Werkzeuge enthalten, mit denen verschiedenste Prozesse im Bereich der Geodatenverarbeitung durchgeführt werden können (Esri, 2013b). Um ein Werkzeug erstellen zu können, das auf einem selbst entwickelten Algorithmus beruht, wird ArcPy verwendet. ArcPy ist der Nachfolger des Moduls arcgisscripting und wird oft als ArcPy-Site-Paket bezeichnet. Es soll der Grundstein für die Durchführung von geografischen Datenanalysen, Datenkonvertierungen, Datenmanagement und Kartenautomatisierungen mit Python sein. Der Vorteil von ArcPy ist, dass es auf der Programmiersprache Python basiert, welche allgemeingültig und einfach erlernbar ist. Damit können sowohl einfache als auch komplexe Skripte für verschiedene Arbeitsabläufe oder sogar ganze Anwendungen geschrieben werden. Mit ArcPy kann auf alle Geoverarbeitungswerkzeuge von ArcGIS zugegriffen werden. Ausserdem gibt es einige zusätzliche Funktionen, Klassen und Module, die das Arbeiten und Untersuchen von Geodaten erleichtern. (Esri, 2013c) Ein Python-Skript kann, wie sämtliche ArcGIS Werkzeuge, in eine Toolbox eingefügt werden. Damit bietet sich die Möglichkeit, für das Tool eine Eingabemaske (siehe Abbildung 3.4) zu erstellen. Es muss angegeben werden, welcher Name für die Eingabedateien angezeigt werden soll, um welchen Datentyp es sich handelt und ob die Eingabe obligatorisch ist. Aus diesen Informationen wird automatisch eine Eingabemaske erstellt, über welche dem Tool die nötigen Inputfiles geliefert und das Skript gestartet werden kann. (Esri, 2013c) Abbildung 3.4: Eingabemaske des erstellten Tools 3.3 Manuelle Erstellung Als Ausgangslage für die manuelle Erstellung von Trigger-Regionen dient das Resultat einer Sichtbarkeits-Analyse mit ArcMap, die für jeden Schauplatz einzeln durchgeführt wurde. Auf einer Karte werden die Regionen, auf der Schiffslinie und im sichtbaren Bereich liegend, grob eingezeichnet. Auf einer Schifffahrt wird überprüft, ob die Schauplätze von diesen Regionen aus tatsächlich sichtbar sind, und ob es möglicherweise einen besseren Platz dafür gäbe. Es wird darauf geachtet, dass die Trigger-Regionen möglichst nahe bei den Schauplätzen zu liegen kommen. Ist der Schauplatz gleichzeitig eine Anlegestelle, wird versucht, die Trigger- 10 Esri: 18

27 3 ERSTELLUNG VON TRIGGER-REGIONEN Region vor der Anlegestelle zu platzieren, um den Nutzer rechtzeitig zu informieren. Folglich müssen die Regionen zwingend für beide Fahrtrichtungen separat festgelegt werden. Zur Definition einer Trigger-Region, wird deren Mittelpunkt festgelegt. Dieser liegt auf der Linie der Schiffsroute. Damit daraus eine Fläche abgeleitet werden kann, wird ein Puffer von Metern (die Hälfte der festgelegten Länge, siehe Abschnitt 3.1.4) darum gelegt. Der Überlappungsbereich dieses Puffers mit einem Puffer von 500 Metern 11 um die Schiffsroute definiert die Trigger-Region. Abbildung 3.5: Manuell erstellte Trigger-Regionen (Luzern-Flüelen), Basiskarte von Esri In Abbildung 3.5 fällt auf, dass im südwestlichen Bereich des Sees sowohl die Trigger-Region für Flüelen als auch diejenige für die Tellsplatte doppelt vorkommen. Das kommt daher, dass auf diesem Teil des Sees zwei verschiedene Routen gefahren werden. Bei derjenigen weiter westlich werden die Anlegestellen Bauen und Isleten-Isenthal angefahren, während das Schiff bei der Zweiten auf der anderen Seeseite verkehrt und in Sisikon und bei der Tellsplatte anlegt. Mit diesen doppelt vorhandenen Regionen kann gewährleistet werden, dass die Informationen über die Schauplätze bei beiden Routen verfügbar sind. 3.4 Automatische Erstellung Für den in Abschnitt gewählten Ansatz wird ein Tool erstellt, das als Output Trigger- Regionen liefert, die direkt in die App integriert werden können. Dies sollte eigentlich mit dem in ArcGIS integrierten ModelBuilder erreicht werden. Damit können verschiedene Werkzeuge aneinandergehängt und Prozessketten erstellt werden, die automatisch ausgeführt 11 Annahme, dass die Route des Schiffs immer innerhalb von +/- 500 Metern von der eingezeichneten Route verläuft 19

28 3 ERSTELLUNG VON TRIGGER-REGIONEN werden können. Nach einigen Testversuchen musste festgestellt werden, dass die Funktionalität des ModelBuilders für diese Aufgabe nicht ausreicht. Um zu einem Ergebnis zu gelangen, müssen verschiedene Iterationen durchgeführt werden, was mit dem ModelBuilder nur beschränkt möglich ist. Es kann zwar durch einzelne Features einer Feature Klasse iteriert werden, sobald jedoch komplexere Iterationen benötigt werden, stösst man an die Grenzen des ModelBuilders. Aus diesem Grund wird das Tool schliesslich in Form eines Python-Skripts realisiert. Mit ArcPy (siehe Abschnitt 3.2) stehen sämtliche ArcGIS Werkzeuge in Python zur Verfügung. Weil es für die App essentiell ist, dass von einer Trigger-Region aus ein Schauplatz sichtbar ist, wird im ersten Schritt eine Sichtbarkeitsanalyse durchgeführt. Wie in Abschnitt bereits erwähnt, gibt es dafür zwei Möglichkeiten, die Beobachterpunkte- und die Sichtfeld- Analyse. Für diese Anwendung wird die zweite Variante gewählt und für jeden Schauplatz eine Sichtfeld-Analyse durchgeführt. Abbildung 3.6 zeigt das Resultat einer solchen Analyse am Beispiel der Rigi. Die grün eingefärbten Flächen sind diejenigen Orte, von denen aus die Rigi zu sehen ist. Rigi Abbildung 3.6: Sichtfeld-Analyse am Beispiel der Rigi (links) und Schiffsroutenabschnitt mit Sicht auf Rigi (rechts) Im nächsten Schritt werden die sichtbaren Bereiche extrahiert und mit der Schiffsroute verschnitten. Für das Beispiel der Rigi, entspricht dieser Abschnitt der grünen Linie (Abbildung 3.6 rechts). Bevor mit der eigentlichen Bestimmung von Trigger-Regionen begonnen werden kann, wird in einem Zwischenschritt eine Tabelle erstellt, welche die ID, den Namen und die Gesamtlänge der sichtbaren Abschnitte eines Schauplatzes, also die Gesamtlänge der grünen Linien, enthält. Mit Hilfe dieser Tabelle kann derjenige Schauplatz bestimmt werden, der während der Schifffahrt am wenigsten lange sichtbar ist. Ist dieser Schauplatz bestimmt, wird dessen Trigger-Region festgelegt. Bei dem fiktiven Beispiel mit den drei Schauplätzen Luzern, Pilatus und Rigi, würde also als erstes die Trigger-Region für die Rigi berechnet (Tabelle 3.1). Tabelle 3.1: Hilfstabelle, Beispiel mit drei Schauplätzen OBJECTID Name Length 0 Luzern Pilatus Rigi

29 3 ERSTELLUNG VON TRIGGER-REGIONEN Abbildung 3.7: Berechnung einer Trigger-Region Ein Schauplatz kann von mehreren, nicht zusammenhängenden Abschnitten aus sichtbar sein. Um eine Trigger-Region zu definieren, wird der längste dieser Abschnitte bestimmt und in dessen Mitte ein Punkt gesetzt. Dies ist der Mittelpunkt der Trigger-Region. Als nächstes wird ein Puffer mit einem Radius von Metern, was der Hälfte der in Abschnitt definierten Länge einer Trigger-Region entspricht, um den Punkt gelegt (siehe Abbildung 3.7, links). Im nächsten Schritt wird der Eingabewert für die Breite der Trigger-Region benötigt. Die Schiffsroute wird mit einem Puffer der halben Breite versehen und dessen Überlappung mit dem Kreispuffer bestimmt (siehe Abbildung 3.7, rechts). Somit ist eine Trigger-Region definiert und es kann eine Zeile aus der Hilfstabelle entfernt werden. Damit nicht zwei Regionen am gleichen Ort zu liegen kommen, wird derjenige Teil der Schiffsroute, der durch die festgelegte Region verläuft (rote Linie), in den sichtbaren Abschnitten von allen anderen Schauplätzen gelöscht. Jetzt kann wieder von vorne begonnen und die nächste Trigger- Region bestimmt werden. Dieser Schritt wird solange wiederholt bis die Hilfstabelle leer ist und alle Trigger-Regionen vorhanden sind. Abbildung 3.8: Automatisch generierte Trigger-Regionen 21

30 3 ERSTELLUNG VON TRIGGER-REGIONEN Wird das erstellte Tool in ArcMap aufgerufen, können die Eingabewerte und der Pfad zu den benötigten Feature Klassen angegeben und das Skript gestartet werden. Mit einem Eingabewert von 1000 Metern für die Breite der Trigger-Region und den 14 Schauplätzen, die momentan in die App integriert sind, liefert das Tool das Ergebnis, welches in Abbildung 3.8 zu sehen ist. Es wurde für jeden Schauplatz eine Trigger-Region bestimmt. Es fällt auf, dass diese gleichmässig über den ganzen See verteilt sind, was bestimmt auch mit der Anordnung der Schauplätze zusammenhängt. 3.5 Ergebnisse Wie in Abbildung 3.8 zu sehen ist, wird die erste Anforderung, dass die Route des Schiffes durch die Region verlaufen muss, in jedem Fall erfüllt. Ob der entsprechende Schauplatz von der generierten Trigger-Region wirklich sichtbar ist, kann in der Abbildung nicht erkannt werden. Da die Berechnung jedoch auf Basis einer Sichtbarkeitsanalyse ausgeführt wird, darf angenommen werden, dass auch diese Anforderung erfüllt ist. Ebenfalls aus der Abbildung ersichtlich ist, dass es keine räumlich überlappenden Regionen gibt. Wie es mit der zeitlichen Überlappung steht, kann nicht überprüft werden. Dafür müsste getestet werden, ob einem Benutzer die viereinhalb Minuten, die für die Betrachtung der Informationen gerechnet sind, ausreichen. Wenn nicht, kann es zu einer zeitlichen Überlappung kommen. Grundsätzlich kann gesagt werden, dass die gestellten Anforderungen mit dem Tool zur automatischen Berechnung der Trigger-Regionen erfüllt werden können. Um die Grenzen des Tools auszuloten, werden Tests mit verschiedenen Inputs durchgeführt und die Resultate verglichen. Interessant wäre natürlich ein Test mit Daten von einem anderen See. Da der Aufwand für die Beschaffung der benötigten Daten gross ist, werden die Test mit den vorliegenden Daten vom Vierwaldstädtersee ausgeführt. Es werden zwei verschiedene Tests durchgeführt. Beim ersten wird ein einzelner Schauplatz ausgewählt und dessen Trigger-Region berechnet. Das heisst, diese Region sollte an der für den Schauplatz optimalen Position zu liegen kommen. Nun wird ein weiterer Schauplatz hinzugefügt und geschaut, wie sich dadurch die Lage der ersten Trigger-Region verändert. Dies wird weitergeführt bis vier Schauplätze vorhanden sind. Abbildung 3.9: Veränderung einer Trigger-Region beim Einfügen eines zweiten Schauplatzes 22

31 3 ERSTELLUNG VON TRIGGER-REGIONEN Als erster Schauplatz wird der Bürgenstock gewählt. Im nächsten Schritt wird der Pilatus hinzugefügt. Wie in Abbildung 3.9 zu sehen ist, hat sich die Trigger-Region des Bürgenstocks etwas verändert, nachdem der Pilatus hinzugefügt wurde. Sie liegt nun etwas weiter westlich. Das kommt daher, dass die Region für den Pilatus zuerst festgelegt wird und diese sich zumindest teilweise in einem Gebiet befindet, von dem aus auch der Bürgenstock sichtbar ist. Wird Weggis als dritter Schauplatz eingefügt, verändert sich die Lage der Trigger- Regionen ein weiteres Mal. Abbildung 3.10: Veränderung der Trigger-Regionen beim Einfügen eines dritten Schauplatzes Abbildung 3.10 zeigt, wie sich die Region des Bürgenstocks weiter in Richtung Luzern verschiebt. Zusätzlich kommt auch die Region des Pilatus nicht mehr am gleichen Ort zu liegen, weil zuerst die Region von Weggis festgelegt wird. Zum Schluss dieses Tests über das Verhalten der einzelnen Trigger-Regionen beim Hinzufügen von weiteren Schauplätzen, wird die Rigi eingefügt. Im Vergleich zu vorher, wo der neu hinzugefügte Schauplatz immer derjenige war, dessen Trigger-Region zuerst bestimmt wurde, ist dies bei der Rigi nicht mehr der Fall. Sie wird nämlich erst nach dem Pilatus und Weggis definiert, was dazu führt, dass sich diese beiden Trigger-Regionen nicht verschieben. Anders sieht es mit derjenigen des Bürgenstocks aus. Da die Region der Rigi in die Nähe ihres vorherigen Platzes zu liegen gekommen ist, wird die Region des Bürgenstocks nach Osten verdrängt (Abbildung 3.11). Abbildung 3.11: Veränderung der Trigger-Regionen beim Einfügen eines vierten Schauplatzes 23

32 3 ERSTELLUNG VON TRIGGER-REGIONEN Das Tool passt sich also jeweils den aktuellen Gegebenheiten an. Angefangen bei dem am wenigsten lange sichtbaren Schauplatz, werden die Trigger-Regionen so festgelegt, dass sie jeweils möglichst optimal passen. Der zweite Test befasst sich mit den Grenzen des Tools. Ausgangslage ist das Resultat, das mit den 14 Schauplätzen, die für die App verwendet werden, erzielt wurde. Es werden immer mehr Schauplätze, verteilt rund um den See, hinzugefügt. Somit wird herausgefunden, wie viele Schauplätze mit diesem Tool verarbeitet werden können. Dies ist vor allem abhängig, von der Länge der Schiffsroute, von der Form des Sees, von der Topografie und von der Verteilung der Schauplätze. Beim Vierwaldstättersee handelt es sich um ein recht verwinkeltes Gewässer mit vielen Bergen rundherum. Hat der See eine etwas kompaktere Form, sind die einzelnen Schauplätze von mehreren Orten aus sichtbar und die Verteilung der Trigger- Regionen wird etwas flexibler. In Anhang B wird eine Übersicht geliefert, wie das Tool reagiert, wenn mehr als die vorliegenden 14 Schauplätze als Input verwendet werden. Abbildung 3.12 zeigt die letzten beiden Versuche mit 25 und 26 Schauplätzen. Beim letzten Versuch können zwar 26 Trigger-Regionen gefunden werden, sie erfüllen jedoch nicht mehr alle Anforderungen. Wie bei dem schwarz umrandeten Gebiet zu sehen ist, überlappen sich die Regionen. Dies kommt daher, dass die längste zusammenhängende Strecke kürzer als 1875 Meter (definierte Länge einer Trigger-Region, siehe Abschnitt 3.1.4) ist und somit eine Überlappung möglich ist. 25 Schauplätze 26 Schauplätze Abbildung 3.12: Trigger-Regionen von 25 Schauplätzen(links) und von 26 Schauplätzen (rechts) Mit einer Anzahl von 26 Schauplätzen rund um den Vierwaldstättersee kommt das erstellte Tool an seine Grenzen. Nun stellt sich die Frage, inwiefern dies ein Problem darstellt. Wie bereits erwähnt, dauert eine Schifffahrt von Luzern nach Flüelen ungefähr drei Stunden. Sind in der App 26 Schauplätze enthalten, bedeutet dies, dass dem Benutzer alle sechs bis sieben Minuten neue Informationen zur Verfügung stehen. Geht man davon aus, dass er ungefähr drei bis vier Minuten braucht, um die Texte zu lesen und die weiteren Inhalte zu betrachten, ist er mehr als die Hälfte der Fahrt mit dieser App beschäftigt. Da viele Leute nicht tagtäglich auf dem Vierwaldstättersee Schiff fahren und während der Fahrt die Aussicht geniessen und eventuell etwas trinken wollen, würde eine solche App zu viel Zeit in Anspruch nehmen. Das bedeutet, es kann ohne Bedenken gesagt werden, dass es ausreicht, wenn bis zu 20 Schauplätze eingebaut werden können. Somit erfüllt das Tool die Anforderungen und kann für die Berechnung von Trigger-Regionen verwendet werden. 24

33 4 MOBILER LITERATURFÜHRER 4 Mobiler Literaturführer Dieses Kapitel widmet sich dem zweiten Teil des in Abschnitt 1.2 definierten Hauptziels, nämlich der Umsetzung einer zweisprachigen App für Smartphones. Es beinhaltet eine Beschreibung der Grundlagen, zum Beispiel die Definition der Anforderungen an die App oder das Vorstellen der Daten aus dem Literaturatlas, und der für diesen Teil verwendeten Technologien. Es werden die einzelnen Bestandteile der App beschrieben, deren spezifische Funktion und deren Zusammenspiel mit anderen Modulen aufgezeigt. Zum Schluss dieses Kapitels werden die Ergebnisse werden die Ergebnisse aus einem kleinen Applikationstest mit wenigen Benutzern beschrieben. 4.1 Grundlagen Anforderungen Aufgrund der Zielsetzung können verschiedene Anforderungen definiert werden, welche der mobile Literaturführer erfüllen muss. Als erstes sollen die wichtigsten Inhalte des Literaturatlas zur Verfügung stehen. Das heisst, es müssen Informationen über Texte, Autoren und Schauplätze bezogen werden können, welche dem Benutzer einen Einblick in den Literaturatlas ermöglichen. Da es sich um einen standortbezogenen Dienst handelt, soll zudem die aktuelle Position des Benutzers ersichtlich sein, was nach einer Karte verlangt. Auf dieser Karte sollen ausserdem die Schauplätze sichtbar sein, damit eine erste Relation zwischen dem eigenen Standort und den Schauplätzen hergestellt werden kann. Ebenfalls wichtig, besonders für ausländische Touristen, ist es, die Kosten für das Daten-Roaming tief zu halten, wenn möglich sogar ganz zu vermeiden. Zusätzlich werden weitere Ansprüche an die App gestellt. Neben der Karte soll eine weitere Orientierungshilfe für das Auffinden der Schauplätze in der realen Welt zur Verfügung stehen. Damit der Benutzer nicht ständig auf den Bildschirm achten muss, soll ihn eine Meldung darauf aufmerksam machen, dass ein neuer Schauplatz sichtbar ist. Android ios Windows Phone Blackberry Andere 13% 3% 2% 1% 81% Abbildung 4.1: Weltweiter Marktanteil verschiedener Smartphones 3. Quartal 2013 (nach Llamas et al. (2013)) 25

34 4 MOBILER LITERATURFÜHRER Nachdem definiert ist, was in der App enthalten sein soll, muss festgelegt werden, welche Art von App erstellt wird. Wie in Abschnitt beschrieben, können drei Arten von Apps unterschieden werden. Da für eine Web-App grundsätzlich ein mobiles Netzwerk benötigt wird, fällt diese Art der Applikation weg. Es bleibt die Entscheidung zwischen hybrider und nativer App. Aufgrund der Tatsache, dass native Apps noch immer über breitere Nutzungsmöglichkeiten der geräteeigenen Sensoren verfügen und das Design dem entsprechenden Betriebssystem besser angepasst werden kann, wird entschieden, eine native App zu programmieren. Da eine native App an ein Betriebssystem gebunden ist, muss eine weitere Entscheidung getroffen werden. Dafür werden Zahlen über den Marktanteil verschiedener Betriebssysteme für Smartphones zu Hilfe genommen. Aus Abbildung 4.1 ist ersichtlich, dass der Anteil von Android Geräten im dritten Quartal des Jahres 2013 weltweit über 80 Prozent beträgt. Der Marktanteil von Apples ios Geräten beträgt gerade mal 13 Prozent. Um eine breite Masse anzusprechen wird entschieden, eine App für Android Geräte zu erstellen Daten des «literarischen Atlas Europas» Die Daten des «literarischen Atlas Europas» sind die Grundlage für den mobilen Literaturführer. Sie bestehen aus Zitaten aus verschiedensten Büchern, deren Schauplätze rund um den Vierwaldstättersee verteilt sind, aus Hinweisen zu diesen Texten, aus Hintergrundinformationen zu den Autoren und Wissenswertem über die realen Orte, an denen die Literatur spielt. Diese Daten der 14 ausgewählten Schauplätze rund um den Vierwaldstättersee werden vom Team des Literaturatlas zur Verfügung gestellt. Das Datenmodell in Abbildung 4.2 zeigt, welche Informationen vorhanden sind und wie sie miteinander in Verbindung stehen. Name ID Geometrie enthält 1 Schauplatzinfo 1 Schauplatz 1 enthält 1 (max 4) enthält m Autor/in Text Links m Bild / Foto Zitat Literaturinfo Autorenbild Titel Hinweise zum Text Abbildung 4.2: An die App angepasstes Datenmodell des literarischen Atlas Europas Damit man sich vorstellen kann, wie diese Angaben aussehen, wird in den folgenden Abschnitten für jeden Teilbereich ein Beispiel gezeigt. Alle Beispiele gehören zum Schauplatz Rigi. 26

35 4 MOBILER LITERATURFÜHRER Zitat «In diesem Augenblick überraschte ihn etwas weiter hin das ungeheure Hotel mit seinen dreihundert Fenstern zwischen den festlichen Kandelabern, die soeben im Nebel angezündet wurden.» Tartarin kann es nicht fassen «nahezu zweitausend Meter über dem Meeresspiegel ein so gewaltiges Bauwerk, durch Glasscheiben geschlossene Galerien, offene Säulengänge, sieben vielfenstrige Stockwerke und eine breite Freitreppe anzutreffen, die sich zwischen zwei Reihen auf eleganten Ständern ruhenden Leuchtern hinzog, welche dieser Bergeshöhe fast das Aussehen des Opernplatzes in winterlicher Abenddämmerung verliehen.» (Daudet, 1845) Hinweise zum Text Wenn man ganz genau hinschaut, sieht man, etwa auf halber Höhe, eine kleine Figur in Richtung Rigi-Scheidegg kraxeln, in sehr, sehr garstigem Wetter. Aber Tartarin, so sein Namen, ist gut gerüstet, er streckt in der vollen Montur des professionellen Bergsteigers. Wir zoomen etwas näher heran: Der stämmige, untersetzte Mann mit dem breiten Rücken und den wilden Büscheln ergrauenden Barthaars trägt»gelbtuchene Gamaschen«, eine Mütze, darüber eine gestrickte Haube, die Ohren, Hinterkopf und Hals schützt.»der Pickel, der Alpenstock, ein Rucksack auf dem Rücken, ein Bündel gerollter, kreuzweis übereinandergelegter Seile, Steigeisen und eiserne Haken am Gürtel einer englischen Jacke mit breiten Taschenklappen vervollständigten die Ausrüstung eines vollendeten Alpinisten.«Ganz oben, als er Schnee auf der Rigi vorfindet, wird er auch noch die»wie Stereoskope gewölbten grünen Brillengläser«aufsetzen. Schließlich, dies zur Erklärung des ungewöhnlichen Aufzugs, ist die Rigi auch nur Übungsberg für viel gewagtere Exkursionen: Tartarin will später die Jungfrau und den Mont Blanc besteigen. Unter «fürchterlichem Eisengerassel» macht er sich also auf den Weg. Im Wald streift er mit seinem Pickel die Äste, «da prasselte es auf seine Mütze wie aus der Brause einer Gießkanne.» Aber es kommt noch schlimmer, kaum tritt er aus dem Wald, wird der Regen satt und alles durchdringend. «Gott so viel Wasser!, seufzte der Südländer.» Keine Sorge, er wird es ganz nach oben schaffen, er ist immerhin der Präsident des Club des Alpines von Tarascon, eine solche Position verpflichtet! (Piatti, 2013) Hinweise zum/r AutorIn Name: Alphonse Daudet Geboren: 1840 Gestorben: 1897 Der sehr erfolgreiche Dichter Alphonse Daudet ( ) litt die letzten siebzehn Jahre seines Lebens an den Spätfolgen einer Syphilis, die ihm allmählich das Rückenmark zersetzte, ihm dauerhafte Qualen bescherte und am Schluss, fast vollständig gelähmt, in den Rollstuhl zwang. Die ersten Anzeichen dieser Krankheit machten sich 1884 bemerkbar, in dem Jahr als er sich gedanklich mit den alpinen und voralpinen Abenteuern seines unsterblichen, gipfelstürmenden Tartarins befasste. (Piatti, 2013) Abbildung 4.3: Alphonse Daudet, Fotografie von Nadar (1884) 27

36 4 MOBILER LITERATURFÜHRER Zusatzinformationen zum Schauplatz Wir schreiben die achtziger Jahre des 19. Jahrhunderts. Erst vor wenigen Jahren haben die Rigi- Bahnen ihren Betrieb aufgenommen die absolute Sensation. Zwar verfügte der Berg schon Mitte des 19. Jahrhunderts über eine bemerkenswerte Gästeinfrastruktur mit zahlreichen Unterkünften, doch dann folgten die Neuerungen Schlag auf Schlag wurde die Rigi-Zahnradbahn ab Vitznau bis Rigi Scheidegg in Betrieb genommen, 1873 dann weitergeführt bis Kulm folgte eine Bahnlinie von Kaltbad bis Scheidegg. Schließlich wurde 1875 die Bergbahn von Arth-Goldau nach Rigi Kulm eröffnet. Die Besucherzahlen stiegen sprunghaft an, von auf über pro Saison. Nun musste man nicht mehr hinaufmarschieren oder sich auf speziellen Stuhlsänften hinauftragen lassen. Das Goldene Zeitalter der Rigi beginnt und dauert an bis zum Ausbruch des Ersten Weltkrieges, als es mit dem Tourismus der Belle Epoque schlagartig zu Ende ging. An die Glanzzeiten im letzten Drittel des 19. Jahrhunderts und zu Beginn des 20. Jahrhunderts konnte die Rigi nie wieder anknüpfen. Der Berg entwickelte sich in der Nachkriegszeit eher zu einer Destination für Tagestouristen und Sporttreibende; die noch bestehenden mondänen Hotels hatten zunehmend Mühe, ihre Zimmer zu füllen. (Piatti, 2013) Link: Fotos Abbildung 4.4: Rigibähnli (links) (Piatti, 2013), Rigi von weitem (Mitte),Intérieur-Skizze Palais Schreiber Rigi-Kulm (rechts) (Institut für Geschichte und Theorie der Architektur (gta), ETH Zürich) Datenpaket Aufgrund der Anforderung an den mobilen Literaturführer werden sämtliche Daten, welche für die App benötigt werden, in einem Zip-Ordner gespeichert. Dieser Ordner kann bei der ersten Verwendung heruntergeladen und die Daten extrahiert werden. Er enthält mehrere Unterordner, dessen Struktur an das Datenmodell der Literaturatlasdaten (Abbildung 4.2) angelehnt ist. Dies soll das Einlesen und Verwenden der Daten möglichst einfach machen und eine vari- Abbildung 4.5: Ordnerstruktur Download-Ordner able Anzahl von Schauplätzen zulassen, damit die App auch auf anderen Seen eingesetzt werden kann. Abbildung 4.5 zeigt diese Ordnerstruktur. Die drei Textdateien im Hauptord- 28

37 4 MOBILER LITERATURFÜHRER ner enthalten die Koordinaten der Schauplätze, der Schiffsroute und der Trigger-Regionen (siehe Kapitel 3). Die Datei mit der Endung.tpk ist ein komprimiertes Map Tile Package, welches die Kacheln der Basiskarte enthält (siehe Abschnitt 4.3.2). Die Unterordner sind gefüllt mit den Daten des Literaturatlas und denjenigen für die Orientierungshilfe (Panoramen). In den Ordnern «photos_xy» sind sämtliche zur Verfügung stehende Bilder von den 14 Schauplätzen gespeichert. Die Daten des Literaturatlas können in Form von Text- oder HTML-Files in den Ordnern «author_a/b/c/d», «text_a/b/c/d» und «info» gefunden werden. Von den Text- und Autorenordnern gibt es jeweils vier, um pro Schauplatz vier verschiedene Texte und Autoren vorstellen zu können. Für jeden Schauplatz gibt es mindestens ein Textfile für die Autoreninfos, ein Textfile für Wissenswertes über den realen Ort und ein HTML- File mit einem Zitat und einer Beschreibung des Buches. Diese Dateien haben alle die gleiche Struktur, damit das Einlesen der Daten möglichst einfach vonstatten geht. Genauere Informationen über den Aufbau dieses Zip-Ordners und der einzelnen Dateien findet man in Anhang C. 4.2 Verwendete Technologien Java Java ist nach Gosling und McGilton (1995) eine portable, interpretierte, leistungsstarke, einfache, objekt-orientierte Programmiersprache. Sie ist darauf ausgelegt, den Herausforderungen der Applikations-Entwicklung zu genügen. Die grösste dieser Herausforderungen ist die Zurverfügungstellung von Applikationen, die ein Minimum an Systemressourcen benötigen, auf beliebigen Hard- und Software Plattformen laufen und dynamisch erweitert werden können. Java muss die Entwicklung von sicheren, leistungsstarken und sehr robusten Applikationen ermöglichen, die auf verschiedenen Plattformen in heterogenen, verteilten Netzwerken laufen. Dies bedeutet, dass die Java-Architektur neutral, portabel und dynamisch anpassungsfähig sein muss. Um diesen Anforderungen zu genügen, ist ein System entstanden, das so einfach ist, dass es problemlos von den meisten Entwicklern programmiert werden kann und das so vertraut ist, dass es von Entwicklern leicht erlernt werden kann. Es ist objekt-orientiert, um die Methoden der modernen Software-Entwicklung zu nutzen und um verteilten Client-Server Applikationen zu dienen, es ist «multithreaded», um leistungsstarke Applikationen, bei denen mehrere Aktionen gleichzeitig ablaufen können, zu ermöglichen und es ist interpretiert für eine maximale Übertragbarkeit und für dynamische Fähigkeiten. Compiler JVM Programm.java Programm.class Programm Abbildung 4.6: Überblick über den Software Entwicklungsprozess von Java (nach Oracle (2013)) 29

38 4 MOBILER LITERATURFÜHRER Wie Abbildung 4.6 zeigt, wird der Quellcode in Textdateien mit der Endung.java geschrieben. Vom Java Compiler werden die Quelldateien in.class Dateien kompiliert. Diese Dateien enthalten nicht mehr für den Menschen lesbaren Code sondern Bytecode. Dieser kann von jeder Java Virtual Machine (JVM), welche für zahlreiche verschiedene Betriebssysteme zur Verfügung steht, interpretiert werden. Die Applikation kann nun mit einer Instanz der JVM gestartet werden. Die Java Plattform besteht aus dieser JVM und dem sogenannten Java Application Programming Interface (API), einer grossen Sammlung von Software-Komponenten, die nützliche Funktionen zur Verfügung stellen. Es ist unterteilt in die zwei Gruppen Bibliotheken (auch Pakete genannt) und Schnittstellen. Dieses System ist prozessorunabhängig und kann ein wenig langsamer sein als nativer Code. Fortschritte beim Compiler und bei der JVM ermöglichen jedoch eine Leistung, die sehr nahe an diejenige von nativem Code herankommt. (Oracle, 2013) Android In den folgenden Abschnitten werden die wichtigsten Aspekte von Android kurz beschrieben. Android ist ein Open Source Projekt, das von Google geführt wird und als Betriebssystem vieler Smartphones die Grundlage für diverse Anwendungen bietet. Android Apps werden in der Programmiersprache Java geschrieben. Die Android Software Development Kit (SDK) Tools kompilieren den Code zusammen mit Daten und Ressourcen-Dateien in ein Android Package (APK). Ein APK ist eine Archivdatei mit der Endung.apk, welche alle Bestandteile einer Android App enthält und von Android Geräten benutzt wird, um die App zu installieren. Einmal installiert, läuft jede App in ihrem eigenen Sandbox-Sicherheitssystem. Das Android Betriebssystem ist ein multi-user Linux System, wobei jede App ein anderer Benutzer ist und eine eindeutige Linux Benutzer ID, die nur vom System verwendet wird, zugewiesen bekommt. Diese ID wird verwendet, um die Zugriffserlaubnis einer App auf Files zu regeln. Zudem benutzt jeder Prozess seine eigene Virtuelle Maschine (VM), was dazu führt, dass der Code einer App unabhängig von demjenigen einer anderen App läuft. Android startet den Prozess, sobald irgendwelche App-Komponenten ausgeführt werden müssen und stoppt ihn, wenn er nicht mehr benötigt oder wenn der Speicherplatz für andere Anwendungen gebraucht wird. Jede App hat somit nur Zugriff auf diejenigen Komponenten, die sie benötigt, um ihre Aufgabe zu erfüllen und für die sie die Erlaubnis hat. Dieses sogenannte Prinzip der geringsten Rechte sorgt für eine sehr sichere Umgebung. Es gibt jedoch Möglichkeiten, dass eine App Daten mit anderen Apps teilen kann und dass sie auf Systemdienste zugreifen kann. Zum Beispiel kann erreicht werden, dass zwei Apps die gleiche Linux Benutzer ID haben, was bedeutet, dass sie auf ihre jeweiligen Files zugreifen können. Zudem kann eine App die Erlaubnis verlangen, auf Gerätedaten wie Benutzerkontakte, SMS Nachrichten, Bluetooth, die SD-Karte oder die Kamera zugreifen zu dürfen. Die Erlaubnis für sämtliche dieser Zugriffe muss während der Installation vom Benutzer erteilt werden. (Android Developers, 2013) Nach diesen allgemeinen Erläuterungen zu Android, werden nun der Aufbau und die Bestandteile einer Android Applikation beschrieben. Eine Android Applikation besteht aus Applikations-Bausteinen. Jeder Baustein ist ein Punkt, durch welchen das System auf die App zugreifen kann. Obwohl nicht alle Bausteine Eintrittspunkte für den Benutzer sind und einige voneinander abhängen, existiert jeder als eigene Einheit und hat eine spezifische Rolle. Das heisst, jede Komponente ist ein einzigartiger Baustein, der dabei hilft, das allge- 30

39 4 MOBILER LITERATURFÜHRER meine Verhalten der Applikation zu definieren. Es gibt vier verschiedene Arten von Applikations-Bausteinen. Jede Art hat einen bestimmten Zweck zu erfüllen und hat einen unterschiedlichen Lebenszyklus, der festlegt, wie der Baustein erstellt und wie er freigegeben wird. Die vier Arten von Bausteinen sind Activities, Services, Content Providers und Broadcast Receivers. (Android Developers, 2013) Eine Activity stellt eine einzelne Bildschirmansicht dar und hat eine Benutzeroberfläche. Eine App für s hat zum Beispiel eine Activity, die eine Liste mit allen s zeigt, eine für das Erstellen und eine andere für das Lesen einer . Obwohl diese Activities zusammenarbeiten, um dem Benutzer ein zusammenhängendes Nutzererlebnis zu ermöglichen, sind sie unabhängig voneinander. Wenn es die App erlaubt, kann jede Activity von einer anderen App gestartet werden. (Android Developers, 2013) Ein Service ist eine Komponente, welche im Hintergrund läuft, um länger dauernde Vorgänge oder die Arbeit von entfernten Prozessen (remote processes) auszuführen. Ein Service stellt keine Benutzeroberfläche zur Verfügung. Er wird zum Beispiel dazu verwendet, Musik abzuspielen, während der Benutzer mit einer anderen App beschäftigt ist oder um Daten über ein Netzwerk zu beziehen, ohne die Nutzerinteraktion mit einer Activity zu blockieren. Ein Service wird von einer anderen Komponente, zum Beispiel von einer Activity gestartet. (Android Developers, 2013) Ein Content Provider steuert eine Reihe von gemeinsamen Applikationsdaten. Daten können in einem Dateisystem, in einer SQLite Datenbank, auf dem Web oder an irgendeinem anderen Ort, auf den die App zugreifen kann, gespeichert werden. Über den Content Provider können (sofern es der Content Provider erlaubt) andere Applikationen auf diese Daten zugreifen oder sie verändern. Zum Beispiel kann so auf gespeicherte Kontaktdaten zugegriffen werden. Ebenfalls nützlich sind Content Provider für das Lesen und Schreiben von Daten, die nur einer App zur Verfügung stehen. (Android Developers, 2013) Ein Broadcast Receiver ist eine Komponente, welche auf systemweite Broadcast Ankündigungen antwortet. Viele Broadcasts stammen vom System, zum Beispiel ein Broadcast der ankündigt, dass der Akkustand tief ist, dass der Bildschirm ausgeschaltet oder Bild aufgenommen wurde. Auch Applikationen können Broadcasts initiieren, um zum Beispiel andere Applikation zu informieren, dass Daten auf das Gerät heruntergeladen wurden, die jetzt zur Verfügung stehen. Obwohl Broadcast Receiver keine Benutzeroberfläche haben, kann eine Statusbar-Benachrichtigung erstellt werden, die den Benutzer informiert, wenn ein Broadcast Ereignis auftritt. Generell ist aber ein Broadcast Receiver eher ein Gateway zu anderen Komponenten und soll eine möglichst geringe Menge an Arbeit erledigen. (Android Developers, 2013) Ein einzigartiger Vorteil des Android Betriebssystems ist, dass jede Applikation die Komponenten einer anderen Applikation starten kann. Wenn zum Beispiel der Benutzer ein Foto mit der Gerätekamera machen soll, kann eine bereits installierte App, die dafür konzipiert ist, verwendet werden. Somit muss keine neue Komponente entwickelt werden, die diese Aufgabe übernehmen kann, sondern es kann auf bestehenden Code zugegriffen werden. Dafür muss lediglich die gewünschte Komponente aufgerufen werden und der Prozess für diese Applikation wird gestartet (wenn sie noch nicht läuft). Zudem werden alle für die Komponente benötigten Klassen initialisiert. Um auf das Beispiel mit der Kamera zurückzukommen bedeutet dies, dass die Activity, die das Foto aufnimmt, im Prozess der Kamera-App 31

40 4 MOBILER LITERATURFÜHRER und nicht im Prozess der eigenen App läuft. Ist die Aufgabe ausgeführt, wird das Resultat, zum Beispiel das Foto, an die eigene Applikation zurückgegeben und kann dort weiterverwendet werden. Für den Benutzer sieht es so aus, als ob diese Activity, im Beispiel die Kamera, Bestandteil der App wäre. (Android Developers, 2013) Sehr wichtig für die Entwicklung einer guten und flexiblen Android Applikation ist der Lebenszyklus einer Activity (Abbildung 4.7). Er wird direkt beeinflusst von seiner Verbindung mit anderen Activities und hilft, zu bestimmen, welche Funktionen zu welchem Zeitpunkt ausgeführt werden müssen. Zum Beispiel muss alles, was beim Starten der Activity erstellt werden soll in oncreate() ausgeführt werden, da die Activity diese Funktion nur beim Starten, nicht aber beim Zurückkehren nach dem Pausieren oder Stoppen der Activity, ausführt. Activity wird gestartet Activity ist beendet oncreate() ondestroy() Created Activity endet / wird vom System zerstört onstart() onrestart() Benutzer navigiert zu Activity Stopped (nicht sichtbar) Started (sichtbar) onstop() onresume() Benutzer kehrt zu Activity zurück Paused (z.t. sichtbar) Resumed (sichtbar) onpause() Activity läuft Andere Activity kommt in den Vordergrund Benutzer navigiert zu Activity App Prozess zerstört Apps mit höherer Priorität brauchen Speicherplatz Abbildung 4.7: Activity Lebenszyklus (Android Developers, 2013) Eine Activtiy kann grundsätzlich in drei Zuständen existieren: Resumed (grün) Die Activity ist auf dem Bildschirm sichtbar (im Vordergrund) und liegt im Fokus des Benutzers. Paused (gelb) Eine andere Activity ist im Vordergrund und liegt im Fokus, die pausierte Activity ist noch immer sichtbar, das heisst die zweite Activity ist teilweise transparent oder benötigt nicht den ganzen Bildschirm. Eine pausierte Activity ist noch immer vollständig da, das Activity Objekt liegt im Speicher und ist mit dem Window Manager 32

41 4 MOBILER LITERATURFÜHRER verbunden. Es kann jedoch vom System freigegeben werden, wenn der Speicherplatz benötigt wird. Stopped (rot) Die Activity ist komplett verdeckt von einer anderen Activity, sie ist also im Hintergrund. Im Unterschied zu einer pausierten Activity, ist sie nicht mehr mit dem Window Manager verbunden und für den Benutzer nicht sichtbar. Wenn der Speicherplatz benötigt wird, kann sie ebenfalls vom System freigegeben werden. Wenn eine Activity Prozess vom System freigegeben wird, muss die Activity neu erstellt werden, das heisst, oncreate() wird erneut aufgerufen Eclipse mit Android Developer Tools Plugin Eclipse ist eine Gemeinschaft für Einzelpersonen und Organisationen, welche bei der Entwicklung von Open Source Software mitwirken möchten. Die Projekte sind darauf ausgelegt, eine offene Entwicklerplattform, bestehend aus einer erweiterbaren Grundstruktur, Werkzeugen und Laufzeitumgebungen, zu bilden, welche die Entwicklung, Verteilung und das Management von Software ermöglicht. Die Eclipse-Foundation ist eine non-profit Organisation, unterstützt von ihren Mitgliedern, welche die Eclipse-Projekte betreut und dabei hilft, sowohl eine Open Source Gemeinschaft als auch ein System von ergänzenden Produkten und Diensten zu pflegen. (The Eclipse Foundation, 2013) Eine grosse Hilfe für die Entwicklung einer Android App sind die sogenannten Android Developer Tools, welche eine vollständige Java IDE (integrated development environment) anbieten. Werden diese Tools in Eclipse integriert, entsteht eine Entwicklungsumgebung, welche zahlreiche Funktionen für das Entwickeln und Testen von Android Apps enthält. (Android Developers, 2013) Erweiterung der App mit einer Karte Um eine Karte zu einer Android App hinzuzufügen, gibt es mehrere Möglichkeiten. In den folgenden Abschnitten werden drei dieser Möglichkeiten beschrieben und Gründe aufgeführt, die für, respektive gegen diese Varianten sprechen. Google Maps Android API Mit der Google Maps Android API können Karten von Google in eine Applikation integriert werden. Der Zugriff zu den Servern von Google Maps, das Herunterladen und Darstellen der Daten, sowie die Antwort auf Zoom- oder Pan-Gesten werden von der API erledigt. Es können Symbole, Linien, Polygone und verschiedene Arten von Overlays hinzugefügt werden. Damit können zusätzliche Informationen in der Karte dargestellt werden und dem Benutzer werden Interaktionen mit der Karte ermöglicht. (Google Developers, 2014) Um Google Maps in einer App zu integrieren, muss das Google Play Sevices SDK installiert, das heisst in Eclipse integriert und konfiguriert werden. Im Vergleich zu den anderen beiden Varianten für die Integrierung einer Karte, muss für Google Maps ein API Key verwendet werden. Dafür muss das Projekt bei Google registriert werden, um ein Signing-Zertifikat zu erlangen. Schliesslich müssen verschiedene Einstellungen im Manifest-File der App vermerkt werden, bevor die Karten von Google verwendet werden können. (Google Developers, 2014) 33

42 4 MOBILER LITERATURFÜHRER Der Vorteil der Google Maps API ist einerseits die sehr gute Dokumentation, andererseits der grosse Bekanntheitsgrad der Karten. Fast jeder hat schon eine Karte von Google gesehen und damit auf irgendeine Art und Weise interagiert. Man könnte damit also eine den Benutzern bekannte Karte bieten. Der grosse Nachteil dieser API ist, dass bis jetzt keine offline- Kartennutzung unterstützt wird. Das heisst, die Karte muss über ein mobiles Netzwerk geladen werden, was zu Kosten führen kann. osmdroid OpenStreetMap Tools für Android osmdroid ist zusammengesetzt aus OpenStreetMap (OSM) und Android. Damit können Karten von OpenStreetMap in eine Android App integriert werden. Es beinhaltet ein modulares Tile-Provider System, das zahlreiche online und offline verfügbare Kartenkacheln-Quellen unterstützt. Zusätzlich können Overlays hinzugefügt werden, welche die Darstellung von Symbolen und Geometrien sowie das Tracking von Orten ermöglichen. (osmdroid, 2013) Wie bereits erwähnt, ermöglicht osmdroid die Verwendung von offline Kacheln, also von Kartenkacheln, die lokal auf dem Geräte gespeichert sind. Um solche Kacheln zu generieren, kann der Mobile Atlas Creator 12 benutz werdent. Es können eine oder mehrere Karten von verschiedenen Quellen gewählt werden. Zum Beispiel stehen als Quelle OpenStreetMap Mapnik, OpenStreetMap Osmrender, OpenStreetMap Cyclemap oder OpenStreetMap Public Transport zur Verfügung, Ist die Quelle gewählt, kann das Atlas-Format auf osmdroid.zip oder osmdroid.sqlite gesetzt und der Atlas erstellt werden. Das Atlas-File wird auf die SD- Karte des Geräts gespeichert und kann von der App verwendet werden. (osmdroid, 2013) Der Vorteil von osmdroid ist, dass sehr einfach Karten aus verschiedenen Quellen erstellt und diese offline genutzt werden können. Da vom Mobile Atlas Creator nur eine gewisse Anzahl an Quellen unterstützt wird, ist man an eine dieser Karten gebunden und hat keine Möglichkeit, das Erscheinungsbild der Karte zu beeinflussen oder eigene Daten darin einzubinden. Je nach Anwendung kann dies ein Nachteil sein. ArcGIS Runtime SDK for Android Mit dem ArcGIS Runtime SDK for Android können ArcGIS Ressourcen in Android Applikationen integriert werden. Somit können Apps erstellt werden, welchen die Karten von ArcGIS Online und ArcGIS Server hinzugefügt werden können, indem eine Verbindung zu diesen Plattformen hergestellt wird (Esri, 2013d). Für die vorliegende Arbeit von besonderem Interesse ist die Möglichkeit, gekachelte Basiskarten von beliebigen Regionen zu verwenden, die lokal auf dem Gerät gespeichert sind. Zusätzlich zu einer Basiskarte kann eine Reihe von ArcGIS Tools verwendet werden, um die Karte zu analysieren und dem Benutzer weitere Informationen zur Verfügung zu stellen. Es können Werkzeuge hinzugefügt werden, die es dem Benutzer ermöglichen, die Daten zu bearbeiten, Features auf der Karte zu identifizieren oder Geoverarbeitungs-Aufgaben auszuführen und die Resultate darzustellen. Das GPS des Gerätes kann verwendet und Routing Applikationen entwickelt werden. Es können Grafiken auf die Karte gezeichnet und über Popup-Fenster Informationen geliefert werden. Zusätzlich gibt es weitere Möglichkeiten, die immer zahlreicher werden, da ständig an der Erweiterung dieses SDK gearbeitet wird. Um 12 Mobile Atlas Creator: 34

43 4 MOBILER LITERATURFÜHRER ArcGIS in Android Projekten zu verwenden kann ein Plugin in Eclipse installiert werden. Sobald ein Android Projekt in ein ArcGIS Projekt umgewandelt wurde, können sämtliche zur Verfügung stehende ArcGIS Funktionen genutzt werden. (Esri, 2013d) Ein Nachteil von ArcGIS for Android ist, dass Teile davon, besonders die offline Nutzung, noch in der Entwicklung sind. Das heisst, einzelne Klassen und Funktionen ändern sich innerhalb eines relativ kurzen Zeitraums. Methoden werden gestrichen, neue hinzugefügt, andere verändert. Dies macht es teilweise schwierig, die verschiedenen Möglichkeiten effizient einzusetzen. Bezüglich der Dokumentation kann gesagt werden, dass sehr hilfreicher Beispiel- Code zur Verfügung gestellt wird, jedoch nicht ganz so viele Hilfestellungen, Problemlösungsvorschläge und Beispiele vorhanden sind, wie zum Beispiel bei Google Atlas der Schweiz 3 Der Atlas der Schweiz 3 13 erschien zum Jubiläum «50 Jahre Nationalatlas» als interaktive Version in den vier Sprachen Deutsch, Französisch, Italienisch und Englisch. Die beteiligten Partner sind das Institut für Kartografie der ETH Zürich, das Bundesamt für Landestopografie swisstopo und das Bundesamt für Statistik BFS. Dieser interaktive Atlas beinhaltet hochwertige zweidimensionale Karten und dreidimensionale Blockbilder, Panoramen und Prismenkarten mit 2000 Themen aus den Bereichen Verkehr, Energie, Kommunikation, Natur und Umwelt, Gesellschaft, Wirtschaft, Staat und Politik. (Atlas der Schweiz, 2013) Abbildung 4.8: Atlas der Schweiz 3 Panorama-Ansicht 13 Atlas der Schweiz 3: 35

44 4 MOBILER LITERATURFÜHRER Der Atlas bietet eine Vielfalt an Darstellungs- und Analysemöglichkeiten, wie zum Beispiel die Möglichkeit, Panoramen zu generieren und abzuspeichern. Abbildung 4.8 zeigt diese Panorama-Ansicht, die zahlreiche Einstellungen für die Erstellung verschiedenster Panoramen erlaubt. Auf der Referenzkarte kann ein beliebiger Standort in der Schweiz und im grenznahen Ausland fixiert werden. Im Standortfenster können auch direkt die Koordinaten dieses Ortes eingegeben, sowie die Blickrichtung, der Öffnungswinkel, die Höhe über Meer und die Sichtweite gewählt werden. Um das Panorama den eigenen Wünschen entsprechend zu gestalten, gibt es zahlreiche Ebenen, die ein- oder ausgeblendet werden können. Zudem gibt es verschiedene Einstellung für das Wetter. Es können Wolken oder Nebel eingeblendet, sowie eine Tag- oder Nachtansicht mit Sternbildern gezeigt werden. Mit der Funktion für die Beschriftung können Ebenen der generierten Panoramen auf unterschiedliche Arten beschriftet werden. Der Atlas der Schweiz bietet zahlreiche weitere Möglichkeiten, auf die hier nicht näher eingegangen wird. 4.3 Aufbau der Applikation In diesem Kapitel werden die einzelnen Bestandteile der erstellten Smartphone Applikation mit dem Namen StoryLiner beschrieben. Es wird aufgezeigt, wie diese Bestandteile miteinander in Verbindung stehen, wofür sie benötigt werden und welche Schwierigkeiten und Probleme bei der Erstellung aufgetaucht sind. Abbildung 4.10 stellt den Aufbau der Applikation schematisch dar. Wird StoryLiner zum ersten Mal gestartet, öffnet sich eine Seite, auf der die nötigen Einstellung für das Herunterladen eines Datenpakets (siehe Kapitel 4.3.1) vorgenommen werden können. Ist das Datenpaket lokal auf dem Gerät gespeichert, öffnet sich automatisch der Startbildschirm (Abbildung 4.9), der ab dem zweiten Öffnen der App immer zuerst erscheint. Von hier aus kann bei Bedarf, das heisst wenn ein neues Datenpaket heruntergeladen werden soll, immer wieder auf die Seite Datenpaket herunterladen zugegriffen werden. Der Startbildschirm enthält ausserdem das Impressum der App, sowie eine kurze Beschreibung der Funktionalitäten (Hilfe). Der wohl wichtigste Bestandteil dieser Benutzeroberfläche ist der Knopf, mit dem die Hauptfunktion der App, der eigentliche StoryLiner, gestartet werden kann. Diese Hauptfunktion zeigt dem Benutzer eine Karte vom Vierwaldstättersee (siehe Abbildung 4.9: Startbildschirm Abschnitt 4.3.2). Sofern das GPS eingeschaltet ist, wird die Positionierung des Geräts gestartet und die aktuelle Position auf der Karte dargestellt. Klickt der Benutzer auf das Symbol eines Schauplatzes, öffnet sich ein Info-Fenster 36

45 4 MOBILER LITERATURFÜHRER mit dem Namen des Schauplatzes und drei bis sechs Symbolen, mit denen die weiteren Funktionen gestartet werden können. Es sind dies eine Panorama-Ansicht (siehe Abschnitt 4.3.3), die der Orientierungshilfe im realen Raum dient, eine Ansicht mit verschiedenen Bildern vom jeweiligen Schauplatz (siehe Abschnitt 4.3.4) und eine Ansicht, welche sämtliche Informationen über die Literatur (siehe Abschnitt 4.3.5) liefert. Gibt es für den Schauplatz nur ein Zitat, das heisst ein Buch, das teilweise dort spielt, erscheint nur ein Knopf für die dritte Ansicht, gibt es mehr als ein Zitat, erscheint die entsprechende Anzahl Knöpfe. Damit nicht zu viel Information auf einer Seite dargestellt wird, ist die Ansicht für die Literaturinformation in eine Seite mit drei Tabs aufgeteilt (siehe Abbildung 4.20). Im ersten Tab wird die Literatur an sich, das heisst ein Zitat aus dem vorgestellten Buch mit ergänzenden Hinweisen, gezeigt. Das mittlere Tab wird für die Vorstellung des Autors und das Dritte für das Liefern von Hintergrundinformationen und Wissenswertem über den realen Ort genutzt. Activity Popup 1. App - Start ab 2. App - Start Tab Datenpaket herunterladen Start Bildschirm Karte Info- Fenster Panorama- Ansicht Galerie Literaturinformationen Zitat AutorIn Karte Schauplatz Abbildung 4.10: Aufbau StoryLiner 37

46 4 MOBILER LITERATURFÜHRER Nach diesem Überblick über die Abläufe der App, wird in den folgenden Unterkapiteln näher auf die einzelnen Komponenten eingegangen. Wie bereits erwähnt, werden neben den Funktionalitäten auch die angetroffenen Probleme, die gefundenen Lösungen und mögliche Alternativen erläutert Herunterladen des Datenpakets Da für die Verwendung der App Daten benötigt werden, die lokal auf dem Gerät gespeichert sind, muss beim ersten Starten des StoryLiners die Möglichkeit bestehen, ein Datenpaket herunterzuladen. Dies wird realisiert, indem eine Variable angelegt wird, die den ersten App-Start speichert und bei jedem weiteren Öffnen dafür sorgt, dass die Ansicht für das Herunterladen des Datenpakets nicht mehr automatisch erscheint. Um schliesslich ein Datenpaket herunterzuladen, muss ausgewählt werden, ob die Daten in Deutsch oder Englisch gewünscht werden und ob man eine Internetverbindung nutzen möchte oder nicht. Zusätzlich muss angegeben werden, in welcher Fahrtrichtung man auf dem See unterwegs ist (von Luzern nach Flüelen oder von Flüelen nach Luzern) 14. Je nach Abbildung 4.11: Herunterladen des Datenpakets Auswahl wird eins von vier möglichen Datenpaketen heruntergeladen und lokal auf dem Gerät oder auf der SD Karte gespeichert. Dafür wird ein Ordner mit dem Namen der App angelegt, in welchem, abhängig von den gewählten Einstellungen, ein Unterordner mit allen benötigten Daten angelegt wird Karte Dieser Abschnitt befasst sich mit der Kartenansicht, das heisst mit der Karte an sich und mit den direkt damit verbundenen Funktionen. In Abschnitt werden drei verschiedene Möglichkeiten für die Integrierung einer Karte vorgestellt. Da die offline Nutzung eine Anforderung an die App ist, fällt Google Maps weg. Bleiben noch osmdroid und ArcGIS, welche beide in Frage kommen. Aufgrund der Tatsache, dass mit ArcGIS eigene Karten erstellt und als offline Basiskarte genutzt werden können, wird entschieden, für die Karte das ArcGIS Runtime SDK for Android zu verwenden. 14 Der Grund dafür, warum die Fahrtrichtung wichtig ist, wird in Abschnitt 3.3 aufgeführt. 38

47 4 MOBILER LITERATURFÜHRER Offline Basiskarte Als Basiskarte dient eine Karte, die bereits für Ein literarischer Atlas Europas verwendet wird. Sie basiert auf Daten von swisstopo, die von Anne-Kathrin Weber am Institut für Kartografie und Geoinformation der ETH Zürich aufbereitet wurden. Die Basiskarte ist neutral gestaltet, hinterlegt mit einem Relief und enthält die wichtigsten Elemente, die für die Orientierung notwendig sind. Dazu zählen Seen, Flüsse, Strassen, Eisenbahnlinien und Siedlungsflächen. Obwohl die Karte bereits in Form von Kacheln vorhanden ist, kann sie nicht direkt in die App integriert werden, da die API von ArcGIS dieses Format nicht einlesen kann. Für jede Zoomstufe, es sind deren drei, wird deshalb Abbildung 4.12: Basiskarte (Anne-Kathrin Weber) ein Kartenbild erstellt. Diese drei Karten werden georeferenziert und mit ArcMap neu gekachelt. Dafür wird das ArcGIS Tool CreateMapTilePackage verwendet. Damit werden Kacheln aus einem Kartendokument, also aus einem mxd, generiert und diese in Form eines komprimierten Kachelpakets gespeichert (Esri, 2013c). Dieses daraus resultierende tpk File kann, wie in Abschnitt bereits erwähnt, lokal auf einem Gerät gespeichert und als ArcGIS Local Tiled Layer, das heisst als offline Karte genutzt werden. Overlays Die Basiskarte ist nun vorhanden. In einem nächsten Schritt werden Layer hinzugefügt, die über die Basiskarte gelegt werden und die literaturgeografischen Inhalte präsentieren. Da es vor allem um die Orte geht, an denen Literatur spielt, werden diese Orte auf der Karte markiert. Ebenfalls interessant für den Benutzer ist die Schiffsroute, mit der er seine ganze Reise verfolgen kann. Abbildung 4.13 zeigt die Karte nach dem Hinzufügen der oben erwähnten Ebenen swisstopo (JD100042) Abbildung 4.13: Kartenansicht Da die ArcGIS Android API die Darstellung von Shapefiles nicht unterstützt, werden die Daten in einem GraphicsLayer, einem Objekt der ArcGIS API, dargestellt. Ein GraphicsLayer, enthält ein oder mehrere Graphic Objects. Ein solches Feature kann eine Geometrie, ein Symbol und Attribute haben. (Esri, 2013a). Um die einzelnen Graphic Objects zu erstellen, werden einfache Textdateien mit den benötigten Daten eingelesen. Es sind dies die Koordinaten der Schauplätze mit einigen Attributen (siehe Anhang C) und die Stützpunkte der Schiffsroute. Für die Schauplätze wird pro Punkt ein Symbol hinzugefügt, bei der Schiffsroute wird aus den einzelnen Stützpunkten 39

48 4 MOBILER LITERATURFÜHRER eine Polylinie gebildet. Diese Graphic Objects werden in den GraphicsLayer eingefügt und über die Basiskarte gelegt. Der letzte, für die gewünschte Funktionalität der App sehr wichitge Bestandteil der Kartenansicht ist das Laden der Trigger-Regionen. Diese werden zwar nicht als Ebene zu der Karte hinzugefügt, deren räumliche Ausdehnung muss der App jedoch bekannt sein. Ähnlich der Schiffslinie, werden die Stützpunkte der Flächen, welche die Trigger-Regionen definieren, aus einem Textfile eingelesen. Aus diesen Stützpunkten werden anschliessend Polygone erstellt. Jedes Polygon ist in sich zusammenhängend, konvex und hat keine Löcher (siehe Beispiel Trigger-Regionen in Abbildung 3.5). Die Polygone werden, wie bereits erwähnt, nicht zur Karte hinzugefügt, stehen jedoch für das weitere Vorgehen als Geometrien zur Verfügung. Mehr Informationen über die Trigger-Regionen sind in Kapitel 3 zu finden. Benachrichtigung Eine Anforderung der App ist, dass der Benutzer benachrichtigt werden soll, sobald er sich in einer Trigger-Region befindet. Um dies zu erreichen, müssen die Trigger-Regionen vorhanden sein. Wie im vorherigen Abschnitt beschrieben, stehen sie in Form von Polygonen zur Verfügung. Ebenfalls bekannt muss die aktuelle Position des Benutzers sein. Dafür wird der GPS-Empfänger des Gerätes verwendet. Um auf den Sensor zugreifen zu können, wird ein sogenannter Location Service verwendet. Dieser Dienst ist ein Bestandteil der Schnittstelle von ArcGIS und ermöglicht die Darstellung der aktuellen Geräteposition auf einer Karte. Über den Location Service kann auch auf die Koordinaten dieser Position zugegriffen werden. Nachdem nun sowohl die Trigger-Regionen als auch die aktuelle Position vorhanden sind, muss festgestellt werden, ob die Position innerhalb einer Trigger-Region liegt. Dafür wird eine Methode der Klasse Geometry Engine verwendet, die es ermöglicht, festzustellen, ob eine Geometrie innerhalb einer anderen Geometrie liegt. Dies entspricht genau der hier vorliegenden Problemstellung. (Esri, 2013a) Für jede neue Position, die der Location Service liefert, wird geprüft, ob sie innerhalb einer Trigger- Region liegt. Ist dies der Fall, wird eine Benachrichtigung ausgelöst, die dem Benutzer mitteilt, dass ein neuer Schauplatz sichtbar ist. Die Benachrichtigung erscheint als Symbol im Benachrichtigungsbereich (Abbildung 4.14). Dieser kann vom Benutzer erweitert werden, um zusätzliche Informationen dazu zu erhalten. Wird darauf geklickt, öffnet sich die Kartenansicht des StoryLiners. Dort ist nun das Symbol des Schauplatzes, in dessen Trigger-Region man sich befindet, farblich hervorgehoben. Wird die Trigger- Region verlassen, verschwindet die Hervorhebung. Die Benachrichtigung bleibt in der Benachrichtigungsleiste bis sie angeklickt wird, der Abbildung 4.14: Benachrichtigung Benutzer sie löscht oder eine neue Trigger-Region betreten wird. In diesem Fall wird sie von der neuen überschrieben. 40

49 4 MOBILER LITERATURFÜHRER Es ist zu erwähnen, dass die Benachrichtigung nur ausgelöst wird, wenn die App läuft. Das heisst entweder ist sie auf dem Bildschirm sichtbar oder sie wurde mit dem Home-Button vom sichtbaren Bereich entfernt. Wird die App, genauer gesagt die Kartenansicht, mit dem Back-Button geschlossen, wird der Location Service gestoppt und eine Benachrichtigung kann nicht ausgelöst werden. Infofenster Um Informationen über die Schauplätze zu erhalten, muss das Symbol eines Schauplatzes angeklickt werden. Es öffnet sich ein Infofenster (Abbildung 4.16), das den Namen des Schauplatzes enthält und dem Benutzer die Möglichkeit bietet, zwischen drei verschiedenen neuen Ansichten zu wählen. Mit dem Symbol ganz links kann die Panorama-Ansicht (siehe Abschnitt 4.3.3) geöffnet Abbildung 4.16: Infofenster, 1 Text Abbildung 4.15: Infofenster, 4 Texte werden. Diese Funktion steht nur zur Vefügung, wenn man sich gerade in der Trigger-Region dieses Schauplatzes befindet. Ansonsten ist das Panorama-Symbol blockiert. Ein Klick auf das mittlere Symbol öffnet eine Galerie (siehe Abschnitt 4.3.4) mit verschiedenen Bildern vom Schauplatz. Das letzte Symbol führt zu Informationen über die Literatur (siehe Abschnitt 4.3.5), die an diesem Schauplatz spielt. Gibt es von einem Schauplatz mehr als einen Text, wird das Infofenster mit der entsprechenden Anzahl an Symbolen für die Literaturinformation erweitert (Abbildung 4.15). Maximal können Informationen zu vier verschiedenen Texten eingefügt werden. Die Symbole für die Galerie und die Texte sind immer aktiv, egal ob man sich in einer Trigger-Region befindet oder nicht Orientierungshilfe Um dem Benutzer zu helfen, den Schauplatz in der momentanen Umgebung zu finden, soll eine Hilfestellung zur Verfügung stehen. Einerseits dient dazu natürlich die Karte, auf der sowohl die aktuelle Position als auch der aktuell sichtbare Schauplatz eingezeichnet sind, andererseits soll als Ergänzung eine weitere Orientierungshilfe vorhanden sein. Abbildung 4.17: Panorama-Ansicht am Beispiel der Rigi 41

50 4 MOBILER LITERATURFÜHRER Dazu dienen die mit dem Atlas der Schweiz 3 generierten Panoramen. Pro Schauplatz werden drei Panoramen mit einem Öffnungswinkel von 120 Grad erstellt, die zusammen ein 360 Grad Panorama bilden. Je nach Ausrichtung des Geräts und somit des Benutzers 15 wird das entsprechende Panorama angezeigt. Zusätzlich weist ein Pfeil in die Richtung, in die sich der Benutzer drehen muss, um den Schauplatz im Blickfeld zu haben (Abbildung 4.17). Damit die Orientierung des Gerätes festgestellt werden kann, wird der darin integrierte Kompass benutzt. Dieser liefert das aktuelle Azimut, anhand dessen das richtige Panorama gezeigt werden kann. Die drei Panoramen werden so generiert, dass sich der Schauplatz ungefähr in der Mitte eines Panoramas befindet. Das führt dazu, dass das Azimut in der Mitte der einzelnen Bilder nicht bei allen Schauplätzen gleich ist. Damit trotzdem eine korrekte Darstellung möglich ist, wird ein weiteres Textfile erstellt, das Metadaten über die Panoramen enthält. Tabelle 4.1 zeigt, wie diese Metadaten aufgebaut sind. Tabelle 4.1: Metadaten Panoramen Schauplatz ID Offset [ ] Schauplatz in Panorama Nr. Pfeilspitzenposition x y Für jeden Schauplatz wird der Offset angegeben, den das mittlere Azimut des ersten Panoramabildes von der Nordrichtung (Azimut = 0) aufweist (Abbildung 4.18). Im Atlas der Schweiz entspricht dieser Offset der Blickrichtung beim ersten Panorama. Weil ein Panorama einen Öffnungswinkel von 120 aufweist, kann der Offset zwischen 0 und 119 betragen. Mit Hilfe dieses Offsets wird für jedes Panoramabild das Azimut des linken Bildrandes berechnet. Somit ergeben sich drei Richtungsbereiche, in der jeweils ein anderes Bild angezeigt wird. Es muss nur noch getestet werden, in welchen Bereich das vom Gerät gelieferte, aktuelle Azimut fällt, um das passende Panorama auf den Bildschirm zu bringen. Offset = 0 Offset = 30 N N 30 Offset Az 270 Az Abbildung 4.18: Setzen des richtigen Panoramabildes 15 Annahme, dass der Benutzer in die Richtung schaut, in die er sein Handy ausgerichtet hat 42

51 4 MOBILER LITERATURFÜHRER Die nächste Angabe in der Tabelle betrifft den Schauplatz an sich. Es wird definiert, in welchem der drei Panoramabildern sich der Schauplatz befindet. Diese Information wird benutzt, um den Pfeil anzuzeigen, der entweder in die Richtung des Schauplatzes weist oder den Schauplatz markiert. Ist Letzteres der Fall, werden die letzten beiden Spalten der Metadaten benötigt. Diese legen fest, wo sich die Pfeilspitze genau befindet. Die Zahlen sind als Bruchteil der Gesamthöhe, respektive breite zu verstehen. Beim Panorama mit der ID 1 kommt die Pfeilspitze auf dem Punkt 0.51 * Breite und 0.43 * Höhe des Panoramas zu liegen. Wie vom Infofenster aus, kann auch von hier aus direkt auf die Literaturinformationen zugegriffen werden. Dafür muss der auf den Schauplatz weisende Pfeil angeklickt werden. Ist nur ein Text von diesem Ort vorhanden, wird direkt die Ansicht mit den Informationen angezeigt. Sind mehrere Texte vorhanden, erscheint zuerst ein Auswahlfenster, ähnlich demjenigen der Kartenansicht, wo einer der Texte ausgewählt werden kann Galerie Die Galerie soll dazu dienen, dem Benutzer einen weiteren Eindruck von den Schauplätzen zu geben. Er sieht die Orte zwar vom Schiff aus, weiss jedoch nicht, wie es vor Ort aussieht. Neben den Texten sind diese Bilder ein weiterer Weg, den Benutzer zu animieren, diese Orte zu besuchen. Abbildung 4.19: Galerie mit Überblick über alle Fotos (links) und Detailansicht (rechts) Wird die Bildergalerie geöffnet, erscheint zunächst eine Übersicht mit allen für diesen Schauplatz vorhandenen Bildern. Wird eines der kleinen Bilder angeklickt, erscheint eine grosse Ansicht des Bildes. Um durch die Galerie zu blättern, kann, wie bei Smartphones üblich, mit einer Streichbewegung von einer Seite zur nächsten gewechselt werden. Wie in Abbildung 4.19 zu sehen ist, hilft eine Reihe von kleinen Punkten dabei, den Überblick über das aktuell gezeigte und die weiteren verfügbaren Bilder zu behalten. Um dies umzusetzen wird die externe Bibliothek ViewPagerIndicator (Wharton, 2012) von GitHub verwendet. 43

52 4 MOBILER LITERATURFÜHRER Literaturinformationen Der an dieser Stelle beschriebene Bestandteil des StoryLiners ist derjenige, welcher der App überhaupt erst die literarischen Aspekte hinzufügt. Um die bereitgestellten Daten übersichtlich und ansprechend darzustellen, wird ein Layout mit drei Tabs gewählt, das eine einfache Navigation zwischen den drei Themen Zitat, Autor/in und Schauplatz ermöglicht. Abbildung 4.20 zeigt am Beispiel der Rigi, wie dieses Layout in der fertigen App erscheint. Abbildung 4.20: Zitat (links), Informationen zum Autor (Mitte) und Informationen zum Schauplatz (rechts) Für die Darstellung der Texte werden zwei verschiedene Methoden verwendet. Bei den Zitaten wird eine Lösung mit HTML angewendet. Dafür wird aus den Daten manuell ein HTML- Dokument erstellt, das von der App über eine URL geladen werden kann. In diesem Fall ist die URL der Pfad zum HTML-File, das im heruntergeladenen Ordner liegt. Der Vorteil dieser Methode ist, dass ein Text mit HTML einfach gestaltet werden kann. Es können mitten im Text kursiv oder fett gedruckte Wörter eingefügt, oder die Schriftgrösse und der Zeilenabstand definiert werden. Ebenfalls positiv ist die Tatsache, dass kein Text direkt eingelesen werden muss. Bei der zweiten Methode, die für die Tabs Autor/in und Schauplatz benutzt wird, werden die Texte in einem Textfile gespeichert und direkt eingelesen. Die einzelnen Textblöcke und das Autorenbild werden im Layout-File, das heisst in einem XML-File, erstellt, auf dem Bildschirm platziert und deren Style definiert. Wird ein Tab geöffnet, werden der entsprechende Text und das Bild in die Platzhalter eingefügt. Die Tatsache, dass einzelne Blöcke je nach Einstellung hinzugefügt, beziehungsweise entfernt werden können, ist ein Vorteil dieser Variante. Ausserdem ist der Aufwand geringer, da nicht für jede Seite ein HTML-File erstellt werden muss. Damit ein Tourist weitere Informationen über einen Schauplatz einholen kann, ist für jeden Ort mindestens ein Link zu einer weiteren Webseite aufgeführt. Dieser Link ist allerdings nur verfügbar, wenn die Einstellung Verwende Internet gesetzt ist. Somit kann der Benutzer sofort zusätzliche Auskünfte zum Schauplatz einholen. 44

53 4 MOBILER LITERATURFÜHRER 4.4 Ergebnisse Um herauszufinden, ob die App wie vorgesehen funktioniert und ob die Funktionalität sinnvoll und die Abläufe verständlich sind, wird ein kleiner Benutzertest durchgeführt. Dafür begeben sich die Testpersonen auf ein Schiff auf dem Vierwaldstättersee und verwenden die App. Während der Fahrt sollen sie einen Fragebogen ausfüllen, der einen ersten Eindruck über das Nutzererlebnis geben soll. Obwohl es sich um einen sehr kleinen Benutzertest handelt, kann eine heuristische Evaluation nach (Nielsen (1993)) ausreichen, um erste Erkenntnisse über die Nutzbarkeits-Probleme einer Benutzeroberfläche zu erlangen. Eine heuristische Evaluation wird ausgeführt, indem die bewertende Person die Benutzeroberfläche betrachtet und versucht herauszufinden, was daran gut und was schlecht ist. Heuristisch bedeutet also, zu neuen Erkenntnissen zu gelangen, ohne die Korrektheit dieser Erkenntnisse völlig bestätigen zu können. Diese Art der Evaluation beinhaltet eine kleine Anzahl an Personen, welche die Anwendung untersuchen und sie heuristisch beurteilen. Verschiedene Studien von Nielsen haben ergeben, dass mit nur fünf Testpersonen bereits 75% der Nutzbarkeits-Probleme gefunden werden können Vorbereitung Applikationstests Bevor mit der Erstellung des Fragebogens begonnen werden kann, muss definiert werden, was damit erreicht werden will. Welche Fragen sind hilfreich, um herauszufinden, wie die App läuft, was deren Vor- und Nachteile sind und was überarbeitet werden muss? Grundsätzlich soll der Fragebogen dazu dienen, die Funktionalität zu testen, den allgemeinen Eindruck, den die App hinterlässt, zu erfahren und festzustellen, ob der Umfang des Inhalts passend gewählt ist. Eine sehr wichtige Frage, die beantwortet werden soll, ist die Frage, ob diese App hilft, die Inhalte des Literaturatlas verständlich zu vermitteln. Mit anderen Worten: macht die App das, was sie tun soll? Es soll herausgefunden werden, welche weiteren Erwartungen ein Benutzer an eine solche App hat. Diese können verwendet werden, um mögliche Erweiterungen in Betracht zu ziehen und eventuell zu integrieren. Schliesslich sollen einzelne Bestandteile der App genauer analysiert werden. Einerseits wird die Nutzbarkeit der Panorama-Ansicht betrachtet, andererseits die gezeigte offline Basiskarte. Sind diese beiden Teile für die App geeignet, sind sie hilfreich und was könnte verbessert werden? Der letzte Teil, über den Schlüsse gezogen werden sollen, ist das Design und die Handhabung der App im Allgemeinen. Wie kommen das Design und der Aufbau bei den Benutzern an? Anhand dieser Überlegungen werden verschiedene Fragen formuliert. Sie werden in einem Fragebogen (siehe Anhang F) zusammengestellt und den Testpersonen vor Antritt der Schifffahrt abgegeben Ergebnisse Applikationstests Die erste Frage, die mit dem Test beantwortet werden soll, ist diejenige, ob die App das macht, was sie soll. Bezüglich ihrer Grundfunktionalität kann diese Frage mit ja beantwortet werden. Aber es muss hinzugefügt werden, dass doch noch einige Probleme auftreten. Zum Beispiel stürzt die App manchmal ab oder ein Trigger wird nicht ausgelöst. Dies führt dann auch zum Fehlen einer Benachrichtigung. Es kann leider nicht genau gesagt werden, ob dies 45

54 4 MOBILER LITERATURFÜHRER daran liegt, dass der Benutzer nie in der Trigger-Region drin war oder ob es an etwas anderem liegt. Bei zwei Testpersonen hat es gar nie einen Trigger ausgelöst. Dies lag jedoch daran, dass kein GPS-Signal empfangen werden konnte und somit keine aktuelle Position vorhanden war. Damit wird deutlich, wie abhängig die App von den Gerätesensoren ist. Denn auch die Panorama-Ansicht hat nicht überall funktioniert, was aber nicht an der App, sondern am Kompass lag. Dieser wurde mit einer Kompass-App kontrolliert und zeigt konstant zum gleichen Bildschirmrand, auch beim Drehen des Geräts. Die zweite Frage betrifft den Umfang des Inhalts, also die Informationen über die Texte, Autoren und Schauplätze. Die meisten Testpersonen finden den Umfang passend, wobei zu erwähnen ist, dass diese Aussage mit ihrem Interesse an Literatur korreliert. Die Literaturinteressierten möchten eher mehr Informationen, die weniger Interessierten eher weniger. Bei einem Punkt waren sich die Befragten jedoch einig, nämlich bei den Informationen zum Schauplatz. Dort sollten weitere Auskünfte geliefert werden. Einige genannte Beispiele sind Restauranttipps, Ausflugstipps, Wandervorschläge und Fahrpläne (Schiff, Bus und Zug). Auf die Frage, wie nützlich die Ansicht mit den Panoramen sei, kann keine zufriedenstellende Antwort gegeben werden. Da die Trigger bei zwei Testpersonen nicht ausgelöst wurden, konnte auch die Panorama-Ansicht nicht betrachtet werden. Diese ist nämlich nur aktiviert, wenn man sich in der entsprechenden Trigger-Region befindet. Zudem haben zwei Testpersonen nicht verstanden, was die Panorama-Ansicht ist, weshalb sie diese Fragen nicht beantworten konnten. Bei den restlichen zwei Personen funktionierten sowohl der Kompass als auch das GPS und die Panorama-Ansicht konnte verwendet werden. Sie wurde als hilfreich betrachtet. Eine weitere Frage, die mit dem Test beantwortet werden soll, ist diejenige nach der Eignung der Basiskarte. Hier waren sich die Testenden einig. Sie finden die Karte angemessen, würden aber eine Beschriftung der Ortschaften und eventuell der Berge wünschen. Die letzte Frage ist eher allgemeiner Natur. Es geht darum, zu sehen, wie die App grundsätzlich ankommt. Es kann gesagt werden, dass StoryLiner von den Textpersonen als interessante Sache bezeichnet wird, die weiterverfolgt werden soll. Die Icons sind klar verständlich und das Design kommt bei den Benutzern an. Diese Ergebnisse aus dem kleinen Benutzertests können nicht mit einem Applikationstest gleichgesetzt werden, es können jedoch erste Erkenntnisse gezogen werden. Vor allem die Abstürze und die anderen auftretenden Probleme müssen in einem nächsten Schritt behoben werden. 46

55 5 FAZIT UND AUSBLICK 5 Fazit und Ausblick 5.1 Fazit In der heutigen Zeit wird es immer wichtiger, Informationen auf eine möglichst innovative Art und Weise zu vermitteln. Mit der ständig wachsenden Zahl von Smartphone-Besitzern bietet sich die Möglichkeit, diese Informationsvermittlung über Applikationen für mobile Geräte zu erreichen. Die im Rahmen dieser Arbeit entwickelte Applikation, hat die Übermittlung von in der realen Welt verborgenen, literarischen Inhalten zum Ziel. Mit der entstandenen App kann gezeigt werden, dass sich literarische Inhalte für einen standortbezogenen Dienst sehr gut eignen. Auf Basis einer Karte kann dem Benutzer gezeigt werden, wo sich verschiedene Geschichten abgespielt haben. Während er sich mit den Texten auseinandersetzt, befindet sich der Benutzer in unmittelbarer Nähe des Schauplatzes. Dies führt dazu, dass er sich besser in die Geschichte und die involvierten Figuren hineinversetzen kann und ihm somit ein einmaliges Erlebnis geboten wird. Wird neben dem Inhalt, der technische Aspekt betrachtet, kann gesagt werden, dass die erstellte App die Anforderungen grundsätzlich erfüllt. Allerdings gibt es Probleme bei der Stabilität der Applikation. Es gibt noch einige Fehler, welche nicht abgefangen werden und zu Abstürzen führen. Dadurch wird das Nutzererlebnis negativ beeinflusst. Um StoryLiner der Öffentlichkeit zugänglich zu machen, sind noch einige Anpassungen vorzunehmen. Eine Besonderheit bezüglich der standortbezogenen Dienste, die im Laufe der Arbeit untersucht werden sollte, ist die Tatsache, dass der Benutzer seinen Standort nicht frei wählen kann, sondern an die Geschwindigkeit und den Ort des Schiffes gebunden ist. Er kann nicht an einem Ort stehen bleiben und die Informationen dazu vor Ort beliebig lange betrachten. Das Schiff fährt weiter und der Schauplatz verschwindet irgendwann aus dem Blickfeld. Weil die App für solche Gegebenheiten konzipiert wurde, konnten die Auswirkungen dieser Besonderheit in die Planung miteinbezogen werden. Die Texte und die Zeit, während der man sich in einer Trigger-Region befindet, wurden einander angepasst. Somit sollte für den Benutzer genügend Zeit zur Verfügung stehen, sich über einen Schauplatz zu informieren, bevor er in die nächste Trigger-Region hineinfährt. Sollte die Zeit nicht reichen, besteht die Möglichkeit, die Informationen zu einem späteren Zeitpunkt nochmal aufzurufen. Die Auswirkungen des nicht frei wählbaren Standorts können also mit dieser App berücksichtig werden. Mit dem ArcGIS Tool für die automatische Berechnung von Trigger-Regionen konnte ein Werkzeug erstellt werden, das mit wenigen Inputs Regionen generiert, von welchen aus man Schauplätze, an denen Literatur spielt, vom Schiff aus sehen kann. Sofern die entsprechenden Input-Daten zur Verfügung stehen, kann das Tool auch für andere Seen verwendet werden. 47

56 5 FAZIT UND AUSBLICK Allgemein kann gesagt werden, dass es sich bei der erstellten App um ein spannendes Projekt handelt, das einen starken Bezug zur aktuellen Forschung aufweist. Vor allem Literaturinteressierte können von einer solchen App profitieren, indem sie auf Verborgenes hingewiesen werden, das durch StoryLiner für eine kurze Zeit sichtbar gemacht wird. 5.2 Ausblick Eine erste Erweiterungsmöglichkeit für diese Arbeit besteht darin, das Tool für die automatische Berechnung von Trigger-Regionen zu optimieren. Es funktioniert zwar soweit gut, aber es wurden ein paar vereinfachende Annahmen getroffen. Es wäre zum Beispiel wünschenswert, die Schauplätze nicht in Form von Punktobjekten sondern als Polygone zu beschreiben. Es ist auch denkbar, die Trigger-Regionen ganz neu zu definieren und nicht mehr pro Schauplatz eine Region bestimmter Grösse zu erstellen. Es könnten zum Beispiel direkt die Ergebnisse aus der Sichtbarkeitsanalyse verwendet werden. Das würde bedeuten, dass die Informationen zu einem Schauplatz immer aktiv sind, wenn er sichtbar ist. Der Nachteil davon wäre, dass die Panorama-Ansicht nicht mehr verwendet werden könnte, da der Beobachtungspunkt des Schauplatzes und damit das Panorama nicht eindeutig definiert ist. Eine weitere Möglichkeit wäre es, die Trigger-Regionen nicht im vorheraus zu berechnen und im Datenpaket zu speichern, sondern diesen Schritt direkt mit der App durchzuführen. Somit könnte dem Benutzer die Wahl, über welche und wie viele Schauplätze oder Autoren er informiert werden soll, selbst überlassen werden. Er könnte auswählen, über welche Schauplätze, Autoren oder Epochen er informiert werden möchte. Aufgrund dieser Auswahl könnten anschliessend die entsprechenden Trigger-Regionen erstellt und in die App integriert werden. Somit könnte das in Abschnitt beschriebene Kontext-Bewusstsein berücksichtigt werden. Bezüglich der App wäre es interessant, zu testen, ob es mit vertretbarem Aufwand möglich ist, die App für einen anderen See bereitzustellen. Dies sollte nämlich ohne grosse Probleme möglich sein. Für die einzelnen Bestandteile der App gibt es ebenfalls Verbesserungs- und Erweiterungsmöglichkeiten. Zum Beispiel wäre es denkbar, die Texte in einem Audioformat zur Verfügung zu stellen. Dies würde es dem Benutzer ermöglichen, anstelle des Handybildschirms die Landschaft zu geniessen. Von den Testpersonen wurden zusätzliche Informationen über den Schauplatz, wie Restaurant- oder Wandertipps, gewünscht. Das heisst, es müssten weitere Datenquellen und Darstellungsmöglichkeiten gefunden werden, die für das Liefern solcher Informationen genutzt werden können. Denkbar wäre auch die sprachliche Erweiterung von StoryLiner. Für eine App, die für Touristen ausgelegt ist, wäre es von Vorteil, wenn sie in mehreren Sprachen angeboten wird. Eine englische Version ist in den Grundzügen bereits vorhanden. Ist Deutsch nicht die Standartsprache des Smartphones, auf dem StoryLiner installiert ist, erscheint die Benutzeroberfläche mit englischen Texten. Die literarischen Texte und Informationen müssten jedoch noch übersetzt werden, was mit einem grossen Aufwand verbunden ist. Da die Panorama-Ansicht nicht ganz den modernen Technologien entspricht, könnte man diese mit einer Augmented Reality Technologie ersetzen. Das Problem, dass für die Erstellung von Panoramen ein Punkt festgelegt werden muss, würde sich somit erübrigen. 48

57 5 FAZIT UND AUSBLICK Um den Benutzer schon mit der Benachrichtigung zu packen, könnte anstelle einer einfachen Nachricht ein Vorgeschmack auf den literarischen Text gegeben werden. Das könnte in Form eines Aufhängers oder eines Slogans geschehen, der den Benutzer in die Welt einer literarischen Figur hineinversetzt. Ein wichtiger Punkt, der zu betrachten ist, ist die Anpassung der App für andere Plattformen, insbesondere für iphones. Auch eine Anpassung der App für Tablets kann in Betracht gezogen werden, da immer mehr Leute solche Geräte besitzen. Der grössere Bildschirm, der dann zur Verfügung steht, würde wiederum neue Möglichkeiten mit sich bringen. 49

58 6 LITERATURVERZEICHNIS 6 Literaturverzeichnis Adobe Systems Inc. (2014). PhoneGap. (Zugriff 21. Januar 2014). Android Developers. (2013). Android, the world's most popular mobile platform. (Zugriff 01. Oktober 2013). Atlas der Schweiz. (2013). (Zugriff 01. Oktober 2013). Brimicombe, A., & Li, C. (2009). Location-based services and geo-information engineering (Vol. 21): John Wiley & Sons. Brimicombe, A., & Li, Y. (2006). Mobile Space Time Envelopes for Location Based Services. Transactions in GIS, 10(1), Daudet, A. (1845). Tartarin in den Alpes: Die Besteigung der Jungfrau und andere Heldentaten, Einführung von Daniel Anker. Zürich: AS Verlag. Dey, A. K. (2000). Providing architectural support for building context-aware applications. Georgia Institute of Technology. El Choubassi, M., Nestares, O., Wu, Y., Kozintsev, I., & Haussecker, H. (2010). An augmented reality tourist guide on your mobile devices Advances in Multimedia Modeling (S ): Springer. Elgersson, A. (2006). The mobile destination-the use of mobile services in tourism destination development. Göteborg: Götborg University. Esri. (2012). Telling Stories with Maps. Esri. (2013a). ArcGIS Android API. (Zugriff 03. Januar 2014). Esri. (2013b). ArcGIS for Desktop. (Zugriff 07. Januar 2014). Esri. (2013c). ArcGIS Resources - Hilfe (Zugriff 14. Januar 2014). Esri. (2013d). ArcGIS Runtime SDK for Android. Esri. (2014). Storytelling with Maps. (Zugriff 20. Januar 2014). Google Developers. (2014). Google Maps Android API v2. (Zugriff 10. Januar 2014). Gosling, J., & McGilton, H. (1995). The Java language environment (Vol. 2550): Sun Microsystems Computer Company. Hauthal, E., & Burghardt, D. (2012). Investigation and development of mobile touristic applications Advances in Location-Based Services (S ): Springer. Kenteris, M., Gavalas, D., & Economou, D. (2011). Electronic mobile guides: a survey. Personal and ubiquitous computing, 15(1), Krygier, J. (2013). Jake Barton s performance maps: An essay. Cartographic perspectives(53),

59 6 LITERATURVERZEICHNIS Llamas, R., Reith, R., & Shirer, M. (2013). Android Pushes Past 80% Market Share While Windows Phone Shipments Leap 156.0% Year Over Year in the Third Quarter, According to IDC. (Zugriff 15. Januar 2014). Lu, M., & Arikawa, M. (2013). Map-Based Storytelling Tool for Real-World Walking Tour. In J. M. Krisp (Ed.), Progress in location-based services (S ): Springer. Meng, L., & Reichenbacher, T. (2005). Map-based mobile services: theories, methods and implementations. Berlin Heidelberg: Springer. Mudge, J. (2012). Native App vs. Mobile Web App: A Quick Comparison. Six Revisions. [murmur]. (2003). (Zugriff 20. Januar 2014). Nadar (1884). Gaspard-FelixTournachon. Nielsen, J. (1993). Usability engineering: Morgan Kaufmann, An Imprint of Elsevier. Oracle. (2013). About the Java Technology. osmdroid. (2013). (Zugriff 29. Dezember 2013). Oxford Dictionary. (Ed.) (2013) Oxford Dictionaries. Oxford University Press. Piatti, B. (2008). Die Geographie der Literatur. Schauplätze, Handlungsräume, Raumphantasien, 2. Piatti, B. (2013). Daten für den Schauplatz Rigi. Piatti, B., Bär, H. R., Reuschel, A.-K., & Hurni, L. (2008, Dezember). Die Geographie der Fiktion - Das Projekt "Ein literarischer Atlas Europas". Kartographische Nachrichten, 6, Piatti, B., Reuschel, A.-K., Bäumler, A., Widmer, G., & Schmid, C. (2013). Ein literarischer Atlas Europas. (Zugriff 1. Oktober 2013). Raubal, M. (2011). Cogito ergo mobilis sum: the impact of location-based services on our mobile lives. The SAGE handbook of GIS and society. Sage, Los Angeles, Reichenbacher, T. (2007). Adaptation in mobile and ubiquitous cartography Multimedia Cartography (S ): Springer. Reuschel, A.-K. (2008). Collage mit statistischen Auswertungen und Darstellungen literarischer Räume: Institut für Kartografie, ETH Zürich. Setlur, V., Kuo, C., & Mikelsons, P. (2010). Towards designing better map interfaces for the mobile: experiences from example. Paper presented at the Proceedings of the 1st International Conference and Exhibition on Computing for Geospatial Research & Application. swisstopo. (2013). Höhenmodelle. ml (Zugriff 12. Januar 2014). The Eclipse Foundation. (2013). Eclipse. (Zugriff 03. Dezember 2013). Wharton, J. (2012). Android - ViewPagerIndicator. ViewPagerIndicator (Zugriff 17. November 2013). Willnecker, F., Ismailović, D., & Maison, W. (2012). Architekturen mobiler Multiplattform-Apps Smart Mobile Apps (S ): Springer. Zhu, T., Wang, C., Jia, G., & Huang, J. (2010). Toward context-aware location based services. Paper presented at the Electronics and Information Engineering (ICEIE), 2010 International Conference On. 51

60 ANHANG A INHALT CD Anhang A Inhalt CD Die folgende Abbildung zeigt den Inhalt der abgegebenen CD. Inhalt der CD 52

61 ANHANG B TEST DES TOOLS FÜR TRIGGER-REGIONEN B Test des Tools für Trigger-Regionen Die roten Kreise markieren jeweils die neu hinzugekommenen Schauplätze und Trigger- Regionen. Die lilafarbenen und die blauen Kreise zeigen bei den ersten drei Beispielen, welche Regionen sich aufgrund des neu hinzugefügten Schauplatzes deutlich verschoben haben. 14 Schauplätze 15 Schauplätze 16 Schauplätze 17 Schauplätze 20 Schauplätze Verschiedene Testergebnisse des Tools für die Berechnung von Trigger-Regionen Für mehr Informationen siehe Abschnitt

62 ANHANG C INHALT DES DATENPAKETS C Inhalt des Datenpakets Im Folgenden soll aufgezeigt werden, wie das Datenpaket, das beim ersten Start der App heruntergeladen wird, aufgebaut ist. Dafür wird neben der Ordnerstruktur auch die Struktur der einzelnen Files aufgezeigt. Die in den Bezeichnungen der Files enthaltene ID bezieht sich dabei immer auf die ID des Schauplatzes. Zitat und Hinweise zum Text Da die Möglichkeit besteht, für einen Schauplatz bis zu vier verschiedene Texte vorzustellen, gibt es vier Ordner, welche alle Zitate und Hinweise zum Text enthalten. Gibt es nur einen Text, werden die Informationen im ersten der in der Abbildung links grün umrandeten Ordnern, text_a, gespeichert. Für jeden Schauplatz ist ein HTML-File vorhanden, das folgende Struktur aufweist: Beispiel HTML-File für Zitat und Hinweise zum Text Autoren-Information Ordnerstruktur Sämtliche Informationen zu den Autoren sind, wie die Zitate und Hinweise zum Text, in vier Ordnern, in der Abbildung violett umrandet, enthalten. Ist nur ein Text vorhanden, werden die Informationen im Ordner author_a gespeichert. Pro Schauplatz gibt es ein Textfile mit der Bezeichnung author_id.txt und ein Bild des Autors mit Bezeichnung author_id.jpg. Das Textfile enthält folgende vier Zeilen: Vorname Name Geburtsjahr Todesjahr (falls vorhanden) Text über Autor Beispiel Autoreninfo 54

63 ANHANG C INHALT DES DATENPAKETS Schauplatz-Information Die Informationen zu den Schauplätzen verändern sich nicht, wenn es mehrere Texte gibt. Deshalb gibt es dafür nur einen Ordner, in der Abbildung oben orange umrandet. Der Ordner info enthält pro Schauplatz ein Textfile mit der Bezeichnung info_id.txt. Das Textfile enthält mindestens zwei Zeilen und für jeden zusätzlichen Link eine weitere Zeile: Text über Schauplatz Link zu weiteren Infos Weiterer Link Beispiel Schauplatz-Information Bilder Weil es für jeden Schauplatz beliebig viele Bilder geben kann, wird eine Lösung für die Speicherung gesucht, die möglichst einfach ist. Deshalb wird für jeden Schauplatz ein Ordner photos_id (oben blau umrandet) angelegt, in welchem alle zum Schauplatz gehörenden Bilder enthalten sind. Die Namen der Bilddateien werden in der Galerieansicht der App als Überschrift gesetzt. Panoramen Der oben rot umrandete Ordner ist für die Panoramen reserviert. Darin enthalten sind pro Schauplatz drei Panorama-Bilder mit den Bezeichnungen pano_id_1, pano_id_2 und pano_id_3. Zusätzlich zu diesen Bilddateien gibt es ein Textfile mit der Bezeichnung panorama.txt, in welchem die Metadaten zu den Panoramen (siehe Tabelle 4.1) gespeichert sind. Für den Fall, dass es zwei verschiedene Schiffsrouten gibt und somit von einem Schauplatz auf beiden Routen eine Trigger-Region vorhanden ist, gibt es die Möglichkeit, dafür ein zweites Textfile, panorama2.txt, und drei weitere Panorama-Bilder hinzuzufügen. Die Bezeichnung ändert sich von pano_id_1 zu pano_id_1_a. Die Bezeichnung für die neu hinzugefügten Panorama-Bilder ist dementsprechend pano_id_1_b. Diese Änderung wird nur bei denjenigen Panoramen vorgenommen, deren Schauplätze zwei Trigger-Regionen haben. Basiskarte Das File basemap.tpk ist direkt im Hauptordner des Datenpakets enthalten. Es ist das File, welches mit ArcMap erstellt wurde (siehe Abschnitt 4.3.2). Schauplätze Für die Schauplätze wird ein Textfile mit der Bezeichnung locations.txt erstellt, das ebenfalls direkt im Hauptordner des Datenpakets gespeichert wird. Das Textfile enthält pro Zeile einen Schauplatz mit den Attributen ID, Name, X-Koordinate, Y- Koordinate und Anzahl vorhandener Texte. Die einzelnen Attribute sind mit einem Semikolon getrennt. Beispiel Schaulatz-File 55

64 ANHANG C INHALT DES DATENPAKETS Schiffsroute Für die Schiffsroute braucht es ein einfaches Textfile mit der Bezeichnung shiproute.txt. Darin enthalten sind lediglich die Koordinaten der Stützpunkte der Schiffsroute. Pro Zeile ist ein Stützpunkt aufgeführt, zuerst die X- Koordinate, dann ein Strichpunkt und zum Schluss die Y- Koordinate. Trigger-Regionen Auch für die Trigger-Regionen wird ein Textfile, triggerregions.txt, erstellt. Darin enthalten sind die ID der Trigger-Region, der Schauplatzname, zu dem die Trigger-Region gehört, und die Stützpunkt-Koordinaten der Polygone. Um dieses Textfile zu erhalten, kann die Attributtabelle des Shapefiles trigger_regions_vertices, ein Output-File des Tools für die automatische Berechnung von Trigger-Regionen, in ein Excel-Dokument kopiert und dann als Textfile (getrennt durch Semikolon) gespeichert werden. Beispiel Schaulatz-File Beispiel Schiffsrouten-File 56

65 ANHANG D ANPASSUNG DER APP FÜR EINEN ANDEREN SEE D Anpassung der App für einen anderen See Um die App für die Verwendung auf einem anderen See vorzubereiten, müssen sämtliche Daten im Datenpaket (siehe Anhang C) ausgetauscht werden. Sämtliche Daten, die Koordinaten enthalten, inklusive der Basiskarte, müssen im Koordinatenbezugssystem EPSG: 3857 (WGS84 Web Mercator (Auxiliary Sphere)) vorliegen. Es müssen folgende Daten erstellt werden: Erstellen der offline Basiskarte Karte des Sees in ArcMap einfügen, zoomstufenabhängige Anzeige festlegen, Kachelpaket erstellen (siehe Abschnitt 4.3.2) basemap.tpk. Generierung der Panoramen Für jeden Schauplatz müssen mit dem Atlas der Schweiz 3 oder einer anderen Software, welche die Erstellung von Panoramen ermöglicht, drei Panoramen generiert werden. Zusätzlich muss ein Textfile mit den Metadaten der Panoramen (siehe Abschnitt 4.3.3) erstellt werden. panorama.txt, pano_id_1, pano_id_2, pano_id_3 Schauplätze und Schiffsroute erfassen Punkte für Schauplätze und eine Linie für die Schiffsroute erfassen und die Daten in Textfiles (Aufbau siehe Anhang C) speichern locations.txt, shiproute.txt Trigger-Regionen erstellen Verwendung des Tools für die automatische Berechnung von Trigger-Regionen, Ergebnis in Textfile speichern trigger_regions.txt Informationen zu Schauplätzen und zu Literatur Einfügen der vorhandenen Informationen in Textfiles mit vorgegebenem Format (siehe Anhang C) text_id.html, author_id.txt, info_id.txt Bilder Einfügen von Bildern / Fotos der Schauplätze, Titel der Bilder setzen, indem Name der Datei geändert wird, komprimieren (für kleinen Bildschirm braucht es nicht mehrere MB grosse Dateien) Neben diesen Daten, muss die Auswahlmöglichkeit für die Fahrtrichtung beim Herunterladen des Datenpakets angepasst werden. Dies kann im XML-Dokument spinner_arrays.xml (im Ordner res/values/ beziehungsweise res/values-de/) geändert werden. Wenn gewünscht, kann auch das Foto des Startbildschirms (drawable/im_start_image) ausgetauscht werden. Hinweis Um die App in der englischen Version zu betrachten, muss lediglich die Sprache des Handys auf Englisch gewechselt werden. 57

66 ANHANG E APP AUFLISTUNG UND BESCHREIBUNG DER JAVA-FILES E App Auflistung und Beschreibung der Java-Files Im Folgenden werden die wichtigsten Java-Files, die für die App erstellt wurden, kurz beschrieben. FirstLaunchActivity.java Diese Activity dient dem Herunterladen des Datenpakets. Sie wird nur beim ersten Start der App automatisch ausgeführt, später kann sie über das Menü in der Startansicht aufgerufen werden. Darin enthalten ist neben der Download-Funktion eine Funktion zum Entpacken der Daten. StartActivity.java Die Ansicht, die sich ab dem zweiten Start der App zuerst öffnet, wird von dieser Activity gesteuert. Sie enthält eine Hilfe, ein Impressum und einen Knopf zum Öffnen der Kartenansicht. MapActivity.java Dieses File ist das Umfangreichste. Es enthält sämtliche Funktionen, die in Verbindung mit der Karte benötigt werden. Das heisst, die Daten der offline Karte und die der anderen Ebenen werden aus den Files im lokalen Ordner gelesen und dargestellt. Zusätzlich werden die Info-Fenster erstellt sowie die Benachrichtigung beim Einfahren in eine Trigger-Region ausgelöst. LocationInfoActivity.java Die Activity enthält die drei Tabs für die Informationen zur Literatur und den Schauplätzen. Jedes der drei Tabs wird aus einem eigenen Fragment aufgebaut: FragmentText.java Enthält das Zitat und die Hinweise zum Buch FragmentAuthor.java Stellt die Informationen über den Autor dar FragmentInfo.java Beinhaltet die Informationen und die Links zu den Schauplätzen ImageGridViewActivity.java Das File ist verantwortlich für die Übersicht in der Galerie. Es lädt die Bilder aus dem lokalen Ordner und zeigt einen verkleinerten quadratischen Ausschnitt jedes Bildes, angeordnet in einem Gitter. Für diese Darstellung braucht es einen Adapter (GridViewImageAdapter.java). ImageFullScreenActivity.java Diese Activity ist der zweite Bestandteil der Galerie-Ansicht. Sie ist verantwortlich für die Grossansicht der einzelnen Bilder und deren Titel. Auch diese Activity benötigt einen Adapter (FullScreenImageAdapter.java). OverviewActivity.java Die letzte Activity regelt die Anzeige in der Panorama-Ansicht. Die einzelnen Panorama-Bilder werden vom lokalen Ordner geladen und anhand der Metadaten und der aktuellen Ausrichtung angezeigt. 58

67 ANHANG F FRAGEBOGEN FÜR EVALUATION DER APP F Fragebogen für Evaluation der App Ein mobiler Literaturführer für touristische Schiffsreisen am Beispiel des Vierwaldstättersees Allgemeine Angaben Alter: < 18 Jahre Jahre Jahre > 50 Jahre Geschlecht: weiblich männlich Beruf: Ich interessiere mich für Literatur: ja eher ja weiss nicht eher nein nein Ich habe vorher bereits vom Projekt «Ein literarischer Atlas Europas» gehört: ja nein Ich kann mich mit Hilfe einer Karte orientieren/ mit einer Karte umgehen: ja eher ja weiss nicht eher nein nein Ich besitze ein Smart Phone. ja nein Wenn ja, mit welchem Betriebssystem? Android ios (iphone) anderes Ich fahre mit dem Schiff von... nach... Aufgehalten habe ich mich auf dem Schiff hauptsächlich im Schiffsinneren auf dem Aussendeck am Bug (vorne) auf dem Aussendeck am Heck (hinten) Funktionalität / App-Aufbau Die App ist einfach zu benutzen/ zu bedienen. ja eher ja weiss nicht eher nein nein Läuft die App ohne Probleme (ohne Absturz)? Wenn nicht, wo und bei welchem Schauplatz taucht das Problem auf? ja nein 59