Visualisierung historischer Daten aus OHDM mittels Osmdroid

Visualisierung historischer Daten aus OHDM mittels Osmdroid Abschlussarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) an der Hochschule für Technik und Wirtschaft (HTW) Berlin Fachbereich 4: Informatik, Kommunikation und Wirtschaft Studiengang internationale Medieninformatik 1.Gutachter: Prof. Dr.-Ing. Thomas Schwotzer 2.Gutachter: Prof. Dr. Alexander Huhn Eingereicht von Antje Stockhaus [573662] 10.02.2023 Abstract Die Open Historical Data Map (OHDM) ist ein von Herrn Prof. Schwotzer ins Leben gerufenes Open-Source-Projekt, das sich mit dem Erfassen und Verwalten von historischen Daten beschäftigt. Die Geodaten des OHDM-Projektes werden in einer Datenbank an der HTW gespeichert und jährlich um die Geodaten von Open Street Map (OSM) ergänzt. Die vorliegende Arbeit beschäftigt sich damit die gespeicherten Geodaten ortsund zeitsensitiv abzufragen und mittels Osmdroid in einer mobilen Anwendung zu visualisieren. Die Geodaten sind hierbei offline verfügbar und können so zum Beispiel für Geolog*innen, Historiker*innen, Archäolog*innen vor Ort ohne Internetverbindung genutzt werden. Die finale Anwendung lässt es zu Kartenbereiche zu einem bestimmten Zeitpunkt herunterzuladen, anzuzeigen sowie heruntergeladenes Kartenmaterial zu vergleichen, Orte zu kennzeichnen und unterschiedliche Darstellungsstile zu verwenden. Inhaltsverzeichnis 1 Einleitung ................................................................................................................ 1 1.1 Motivation ......................................................................................................... 1 1.2 Zielsetzung ........................................................................................................ 1 1.3 Aufbau und Ablauf der Arbeit .......................................................................... 2 2 Grundlagen ............................................................................................................. 3 2.1 Open Historical Data Map (OHDM) ................................................................ 3 2.1.1 OHDMConverter ..................................................................................... 3 2.2 Osmdroid ........................................................................................................... 4 2.2.1 Modular Tile Provider Architektur .......................................................... 4 2.2.2 Overlays ................................................................................................... 6 2.3 OSMbonuspack ................................................................................................. 7 2.4 Mapsforge ......................................................................................................... 7 2.4.1 Renderthemes .......................................................................................... 8 2.5 Geodaten ........................................................................................................... 8 2.5.1 OSM-XML-Dateiformat .......................................................................... 9 2.5.2 MAP-Dateiformat .................................................................................. 10 2.6 Design Patterns ............................................................................................... 11 2.6.1 MVVM .................................................................................................. 11 2.6.2 Facade Pattern........................................................................................ 11 2.6.3 Singleton Pattern ................................................................................... 12 2.6.4 Observer Pattern .................................................................................... 12 2.6.5 Factory Method Pattern ......................................................................... 12 3 Anforderungen ..................................................................................................... 14 3.1 Funktionale Anforderungen ............................................................................ 14 3.2 Nichtfunktionale Anforderungen .................................................................... 14 4 Konzept ................................................................................................................. 15 4.1 Benutzeroberfläche ......................................................................................... 15 4.1.1 Menü-Screen .......................................................................................... 16 4.1.2 Download-Screen .................................................................................. 17 4.1.3 Add-Screen ............................................................................................ 18 4.1.4 Map-Screen ............................................................................................ 19 4.1.5 Archiv-Screen ........................................................................................ 20 4.1.6 Settings-Screen ...................................................................................... 21 4.2 Systemarchitektur ........................................................................................... 21 4.3 Offline Karten ................................................................................................. 23 4.3.1 Serverseitiges Parsen der Kartendatei ................................................... 23 4.4 Datenmanagement ........................................................................................... 23 4.5 Download der Kartendateien .......................................................................... 24 4.5.1 Zugriffserlaubnisse ................................................................................ 26 5 Implementierung .................................................................................................. 28 5.1 MapViewerModel ........................................................................................... 28 5.1.1 Kartenobjekte......................................................................................... 29 5.1.2 OHDMMarker Objekte.......................................................................... 30 5.1.3 Datenspeicherung .................................................................................. 31 5.2 MapViewerView ............................................................................................. 32 5.2.1 Kartenarchiv .......................................................................................... 33 5.2.2 Visualisierung der Karten ...................................................................... 35 5.2.3 Marker ................................................................................................... 38 5.2.4 Downloaden eines Kartenbereichs ........................................................ 40 5.3 MapViewerViewModel .................................................................................. 41 5.3.1 Parsen der angefragten Kartendaten ...................................................... 42 5.3.2 Lokale Push-Benachrichtigung ............................................................. 44 5.4 ServerCommunication .................................................................................... 45 5.4.1 Anfrage der Kartendaten über HTTP .................................................... 46 5.4.2 Downloadbenachrichtigung ................................................................... 47 5.4.3 Download der Kartendatei mittels SFTP ............................................... 48 5.4.4 Geocoding .............................................................................................. 50 6 Testing ................................................................................................................... 52 6.1 Unit-Tests ........................................................................................................ 52 6.2 Integrationstests .............................................................................................. 54 6.3 End-zu-End Tests ............................................................................................ 55 6.4 Manuelle Tests ................................................................................................ 56 7 Fazit ....................................................................................................................... 58 7.1 Zusammenfassung ........................................................................................... 58 7.2 Bewertung der Ergebnisse .............................................................................. 59 7.3 Ausblick .......................................................................................................... 60 Quellenverzeichnis ............................................................................................................ i Abkürzungsverzeichnis .................................................................................................. vi Eidesstaatliche Versicherung ....................................................................................... vii Abbildungsverzeichnis Abbildung 1: Abhängigkeitsdiagramm des MapTileProviderArray [8]............................5 Abbildung 2: Abhängigkeitsdiagramm der BitmapTileSourceBase [11].........................6 Abbildung 3: Rasterdaten vs. Vektordaten [26] ................................................................9 Abbildung 4: Mockup des Menu-Screens der OHDM MapViewer App ........................16 Abbildung 5: Mockup des Download-Screens der OHDM MapViewer App.................17 Abbildung 6: Mockup des Add-Screens der OHDM MapViewer App ..........................18 Abbildung 7: Mockups des Map-Screens der OHDM MapViewer App ........................19 Abbildung 8: Mockup des Archiv-Screens der OHDM MapViewer App ......................20 Abbildung 9: Mockup des Settings-Screens der OHDM MapViewer App ....................21 Abbildung 10: Komponentendiagramm der OHDM MapViewer App ...........................22 Abbildung 11: Verteilungsdiagramm der OHDM MapViewer App ...............................26 Abbildung 12: Abhängigkeitsdiagramm der MapViewerModel Komponente ...............29 Abbildung 13: Gekürztes Klassendiagramm Map - OHDMMarker Beziehung ............30 Abbildung 14: Gekürztes Klassendiagramm der MapViewerModel Komponente ........31 Abbildung 15: Abhängigkeitsdiagramm der MapViewerView Komponente .................33 Abbildung 16: Gekürztes Klassendiagramm zur Darstellung der ArchiveActivity zu ...35 Abbildung 17: Gekürztes Klassendiagramm der MapViewActivity ...............................38 Abbildung 18: Overlay Abhängigkeitsdiagramm [15] ...................................................39 Abbildung 19: Gekürztes Klassendiagramm des MapViewerViewModels ....................41 Abbildung 20: Sequenzdiagramm für die Verarbeitung einer Kartenanfrage im MapViewerViewModel ...................................................................................................44 Abbildung 21: Gekürztes Klassendiagramm der ServerCommunication Komponente ..46 Abbildung 22: Sequenzdiagramm zum Empfangen von Push-Benachrichtigung und Herunterladen einer Kartendatei ......................................................................................50 Abbildung 23: Codebeispiel Unit-Test mit Junit .............................................................53 Abbildung 24: Codebeispiel Unit-Test mit Mockito und Junit .......................................54 Abbildung 25: Codebeispiel Integrationstest mit Mockito und Junit ..............................55 Abbildung 26: Codebeispiel End-zu-End Test mit Espresso ..........................................56 Abbildung 27: HTTP Request Body in Postman ............................................................57 1 1 Einleitung Im folgenden Kapitel wird auf die Motivation, Zielsetzung und den Ablauf der vorliegenden Arbeit eingegangen, um einen Überblick über die angestrebten Ergebnisse und ihre Beweggründe zu erhalten. 1.1 Motivation Heutzutage gibt es eine Vielzahl von Anbietern, die es Nutzer*innen ermöglicht die aktuelle Weltkarte anzusehen. Hierzu gehören allen voran Google Maps und Apple Karten sowie das Open-Source Projekt Open Street Map (OSM). Die Karten sind hierbei meist zeitlich auf das aktuelle Kartematerial beschränkt. Sie werden zum Beispiel in Google Maps durch Street View Autos und in OSM durch eine große Community von Mappern auf dem neusten Stand gehalten. Historische Kartendaten hingegen können nicht angesehen werden, da sie stetig mit den aktuellen Daten überschrieben werden. Des Weiteren werden keine zusätzlichen Informationen zu Orten hinterlegt. Das Open Historical Data Map (OHDM) Projekt möchte dies ändern und möglichst viele historische Daten aus unterschiedlichen Quellen sammeln und verwalten. Anschließend können die Informationen zu einer historischen Karte zusammengesetzt werden und eine Vielzahl an Informationen über Gebäude, Straßen und historische Orte abgerufen werden. Eine erste Webanwendung wurde bereits implementiert, um die Geodaten eines ausgewählten Zeitraums als Karte anzuzeigen [1]. Als nächsten Schritt sollen die Karten ebenfalls auf dem Smartphone visualisiert werden können. 1.2 Zielsetzung Ziel der Bachelorarbeit ist es die Daten aus der OHDM-Datenbank abzufragen und in einer Android Anwendung mit Osmdroid zu visualisieren. Ein zentraler Aspekt ist 2 hierbei, dass die Karten ohne Internetverbindung zur Verfügung stehen sollen. Ebenfalls soll es die Möglichkeit geben zwei Karten nebeneinander anzeigen zu lassen, um diese miteinander vergleichen zu können. Die heruntergeladenen Karten sollen Markierungen ermöglichen und verschiedene Darstellungsoptionen bieten. Da die Datenbankoperationen zum Auslesen der Geodaten aufgrund der großen Anzahl von Daten einige Zeit dauern kann, soll eine Lösung gefunden werden, die Nutzer*innen zu benachrichtigen, sobald die gewünschte Karte heruntergeladen wurde. Einmal geladene Karten sollen auf dem Smartphone der Nutzer*innen archiviert werden, um eine schnelle wiederholte Abfrage zu ermöglichen. Um die Kartendaten abfragen zu können, bedarf es einer entsprechenden Schnittstelle zur lokalen OHDM-Datenbank an der HTW. Serverseitig ist dies nicht Bestandteil der vorliegenden Arbeit. 1.3 Aufbau und Ablauf der Arbeit Zunächst wird das OHDM-Projekt und das Export Tool der OHDM-Datenbank vorgestellt. Anschließend werden weitere Grundlagen zu Geodaten, Dateiformaten sowie Osmdroid und der Mapsforge Bibliothek ausgearbeitet. Abgeschlossen werden die Grundlagen mit der Erläuterung von verwendeten Design Patterns. Diese bilden die Basis für die folgende Erfassung der Anforderungen an die Anwendung. Auf den Anforderungen basierend wird anschließend ein Konzept für die Benutzeroberfläche und die Softwarearchitektur der Anwendung ausgearbeitet, implementiert und getestet. Schlussendlich werden die Ergebnisse in einem Fazit zusammengefasst sowie Anregungen für Weiterentwicklungsmöglichkeiten gegeben. 3 2 Grundlagen Im folgenden Kapitel werden die Grundlagen zu OHDM und dem Export Tool OHDMConverter erläutert. Anschließend wird die Architektur von Osmdroid erklärt und Bibliotheken für das offline Kartenrendering im Zusammenhang mit Osmdroid näher beleuchtet. Des Weiteren werden Geodaten und für die Arbeit wichtige Dateiformate sowie verwendete Design Patterns vorgestellt. 2.1 Open Historical Data Map (OHDM) Das Open-Source-Projekt Open Historical Data Map (OHDM) wurde 2014 von Herrn Prof. Schwotzer gestartet und befasst sich mit der Zusammenführung und Verwaltung von historischen Geodaten. Geodaten sind Daten, die einer geografischen Lage zuordenbar sind [2]. Ideengeber für das Projekt war Open Street Map (OSM) [3], das aktuelle Geodaten zu einer Weltkarte zusammenstellt. Die Daten werden durch Mapping der OSM-Community immer wieder aktualisiert. Historische Daten hingegen werden nicht auf dem OSM-Datenserver gespeichert, sondern durch die neuen Daten der OSM-Community ausgetauscht. Dies bedeutet, dass historische Daten weder eingepflegt noch abgerufen werden können. Aus diesem Grund werden die OSM-Daten jährlich in die OHDM-Datenbank importiert [4] und es ermöglicht die Geodaten mit dem OHMDImporttool einzupflegen sowie mit dem Export Tool OHDMConverter zeitsensitiv als Karte abzufragen. 2.1.1 OHDMConverter Der OHDMConverter ist ein Java-Programm, das serverseitig auf der OHDMDatenbank ausgeführt werden kann, um Geodaten zu einem bestimmten Zeitpunkt in der Vergangenheit als Karte zu generieren. Die erstellten Karten werden über den OHDMConverter als OSM-XML-Datei bereitgestellt. Als Parameter benötigt der 10 OHDMConverter heruntergeladen werden [5]. Das OSM-XML-Dateiformat wurden von der OSM-Community entwickelt und wird verwendet, um geografische Daten zu speichern und zur Verfügung zu stellen. Gekennzeichnet ist es mit der .osm Endung. Es basiert auf der Extensible Markup Language (XML), das die Daten in einem strukturierten und menschenlesbaren Format speichert.[27] Das OSM-XML-Dateiformat verwendet verschiedene Elemente und Attribute, um geografische Objekte wie Gebäude und Straßen zu beschreiben. Jedes Objekt wird durch ein XML-Element dargestellt, das zugehörige Attribute enthält, die spezifische Informationen über das Objekt bereitstellen [27]. 2.5.2 MAP-Dateiformat Das Mapsforge Binary Map File Format (MAP-Format) ist ein von Mapsforge entwickeltes binäres Vektordatenformat. Dadurch, dass die Kartendaten binär abgespeichert werden, wird schnelles rendern von Geodaten auf Geräten mit wenig Rechenleistung und Speicherkapazitäten ermöglicht [28]. Um die Karte beim Zoomen und Verschieben auf der Benutzeroberfläche zu erzeugen, wird für jedes Zoomlevel ein Unterordner angelegt, der für jede Kachel der momentanen Bounding Box ihre Punkte, Linien und POIs speichert [28]. Eine Bounding Box beschreibt den zu sehenden rechtwinkligen Ausschnitt der Karte, der durch die maximalen und minimalen Latitude und Longitude der Karte definiert wird. POIs ist eine Abkürzung für Point of Interest und beschreibt relevante Geoobjekte auf der Karte wie zum Beispiel Sehenswürdigkeiten, Gebäude oder auch eine Parkbank. Die Reihenfolge der Kacheln wird wie bei Bildpixeln, fortlaufend nach Reihe und Spalte festgelegt [28]. 11 2.6 Design Patterns Design Patterns sind Lösungsmuster für häufig auftretende Problemstellungen in Softwarearchitekturen [29, S.1]. Die folgend erläuterten Design Patterns wurden bei der Implementierung der Anwendung genutzt. 2.6.1 MVVM Das MVVM-Muster (Model-View-ViewModel) ist ein Architekturmuster, das darauf abzielt, die einzelnen Komponenten einer Anwendung weitestgehend voneinander abzugrenzen, um die Wartbarkeit, Testbarkeit und Erweiterbarkeit der Anwendung zu verbessern. Das MVVM-Muster besteht aus drei Hauptkomponenten: dem Modell, dem View und dem ViewModel. Das Modell übernimmt die Datenhaltung der Anwendung. Das View ist die Benutzeroberfläche, über das der Benutzer mit der Anwendung interagiert und das ViewModel enthält die Geschäftslogik. Dadurch das die Kommunikation zwischen View und Model in das ViewModel ausgelagert wird, können die Verantwortungen unabhängig voneinander getestet werden. Das Modell verarbeitet erhaltene Daten des ViewModels und gibt die Ergebnisse an dieses zurück. Das ViewModel bereitet daraufhin das erhaltene Ergebnis auf, um sie wiederum an das View zur Darstellung auf der Benutzeroberfläche weiterzuleiten. [30] 2.6.2 Facade Pattern Das Facade Pattern ist ein Entwurfsmuster, das für eine Gruppe von Subsystemen eine einzige Schnittstelle bietet, um die Verwendung der Komponente zu vereinfachen und komplexere Strukturen zu verbergen. Die Implementierung erfolgt durch Programmierung einer Klasse, der Facade, die den einzigen Zugang zu allen wichtigen Funktionalitäten der darunterliegenden Klassen bietet. Auf die dahinterliegenden Klassen kann von außen nicht zugegriffen werden, da alle Details ihrer Implementierung hinter der Fassade verborgen bleiben. [29, S.185 ff.] 12 2.6.3 Singleton Pattern Das Singleton Pattern ist ein Entwurfsmuster, das sicherstellt, dass eine Klasse nur eine einzige Instanz hat. Dies sorgt dafür, dass alle Komponente der Software nur diese eine Instanz verwenden kann und verhindert Konflikte durch unbeabsichtigte Duplizierung. Besonders bei dem Zugriff auf gemeinsame Ressourcen soll meist nur eine Version zum Beispiel einer Datei oder einer ganzen Datenbank existieren. Die Implementierung des Singleton Patterns erfolgt durch eine statische Methode, welche bei Aufruf prüft, ob bereits eine Instanz in einer statischen Variable in der Klasse hinterlegt ist und zurückgegeben werden kann oder ob vorher eine Instanz erstellt werden soll. Der Konstruktor selbst wird als privat deklariert und kann somit nicht mehr von außen aufgerufen werden. [29, S.127 ff.] 2.6.4 Observer Pattern Das Observer Pattern wird eingesetzt, um Objekte zu informieren, dass eine Zustandsveränderung eines anderen Objektes stattgefunden hat. Es gibt mindestens zwei Objekte, das Subjekt und den Observer (deutsch: Beobachter). Das Subjekt ist der Benachrichtiger und der Observer der Benachrichtigte. Umgesetzt werden kann das Pattern zum Beispiel durch ein Interface, das von den Observern implementiert wird und bei Aufruf der Methode im Subjekt die implementierte Funktion ausführt. In seiner Ursprungsform besitzt das Subjekt, das seine Observer über Veränderungen informiert, zusätzlich über eine Klassenvariable, die die Observer aufführt. [29, S. 293 ff.] 2.6.5 Factory Method Pattern Das Factory Method Pattern kann verwendet werden, um verschiedene Objekte mit ähnlichen Eigenschaften über eine gemeinsame Klasse zu instanziieren. 13 Das Factory Method Pattern koppelt dabei die Implementierung der Klasse von ihrer Instanziierung ab. Die Objekterstellung erfolgt nicht durch direkten Aufruf der Klasse, sondern über eine Methode in der Factory Klasse. In der Factory Klasse wird eine Methode aufgerufen, welche verschiedene Subklassen für die Instanziierung der Objekte aufrufen kann, da sie alle das gemeinsame Interface implementieren oder von der gleichen Oberklasse erben. [29, S. 107 ff.] Gleichzeitig kann die Endkopplung von Implementierung und Instanziierung dazu genutzt werden, Objekte aus privaten Klassen über ein Interface zu erstellen, ohne ihre Implementierung von außen offen zugänglich zu machen. 14 3 Anforderungen Im folgenden Abschnitt werden funktionale und nichtfunktionale Anforderungen an die Android Anwendung erfasst. Die Zielgruppe der Android Anwendung sind Geolog*innen, Historiker*innen, Archäolog*innen, und weitere Geschichtsund Geografie interessierte Menschen, die Karten aus unterschiedlichen Zeiten sichten und miteinander vergleichen möchten, ohne auf eine Internetverbindung angewiesen zu sein. 3.1 Funktionale Anforderungen - Nutzer*innen sollen Karten durch Auswählen eines Kartenbereiches und eines Zeitpunktes herunterladen können. - Nutzer*innen sollen Orte durch Eingabe eines Suchbegriffes in einer Suchleiste leichter finden. - Nutzer*innen sollen die Karten offline ansehen und bearbeiten können. - Nutzer*innen sollen übersichtlich auf die heruntergeladenen Karten zugreifen können, um sie einzusehen, zu löschen und zu gruppieren. - Nutzer*innen sollen Karten miteinander vergleichen können. - Nutzer*innen sollen Markierungen vornehmen können. - Nutzer*innen sollen darüber informiert werden, wenn angefragte Karten offline zur Ansicht bereitstehen. 3.2 Nichtfunktionale Anforderungen - Die Karten sollen schnell geladen werden. - Die Karten sollen möglichst wenig Speicherplatz in Anspruch nehmen. - Die Benutzeroberfläche soll intuitiv gestaltet sein. - Die Kartenoberfläche soll möglichst viel der Bildschirmfläche einnehmen. 15 4 Konzept In diesem Kapitel wird ein Konzept für die Benutzeroberfläche und die Softwarearchitektur erstellt, um die ermittelten Anforderungen des vorherigen Kapitels umzusetzen. Das entworfene Konzept dient als Grundlage für die Implementierung der Android Anwendung im darauffolgenden Kapitel. 4.1 Benutzeroberfläche Die ersten visuellen Entwürfe der Benutzeroberfläche wurde in Figma erstellt. Es handelt sich hierbei um ein Interface Designtool, welches unter anderem für die Erstellung von Mockups genutzt wird. Mockups sind nicht funktionelle Designentwürfe, um eine erste visuelle Idee der zu implementierenden Anwendung zu bekommen, Designentscheidungen zu treffen und die Usability, der Oberfläche zu evaluieren. Die Benutzeroberfläche greift alle funktionalen Anforderungen gegenüber den Nutzer*innen der Anwendung aus den Anforderungen auf. Jede der folgenden Screens soll durch eine eigene Activity implementiert werden. Activities sind grundlegende Bestandteile einer Android Anwendung. Ihr Lebenszyklus ist durch Callbackmethoden dem Android Betriebssystem zugänglich und ermöglicht hierdurch das Starten, Pausieren und Beenden von Activities sowie das Zusammensetzen mehrerer Activities zu navigierbaren Anwendungen [31]. 16 4.1.1 Menü-Screen Abbildung 4: Mockup des Menu-Screens der OHDM MapViewer App Der Menü-Screen (siehe Abbildung 4) ist der Einstiegspunkt in die Anwendung. Nutzer*innen sollen über diesen auf alle Hauptfunktionen der Anwendung zugreifen können. Diese sind das Downloaden von Karten, das Anzeigen von Karten, das Anzeigen des Kartenarchivs sowie die Einstellungen zum Ändern des Kartenstils. Jede Funktion soll durch entsprechende Icons und eine kurzen Beschreibungstext gekennzeichnet werden, um Nutzer*innen eine leichte und übersichtliche Navigierung zu ermöglichen. Durch Klicken auf eine Menükarte, sollen Nutzer*innen zur entsprechenden Aktivität gelangen. Durch die Einbindung eines Menü-Screens soll auf eine Navigationsleiste verzichtet werden können. Dies ermöglicht die Anforderung die angezeigten Karten größtmöglich darstellen zu können. 17 4.1.2 Download-Screen Auf dem Download-Screen (siehe Abbildung 5) sollen Nutzer*innen gewünschte Karten herunterladen können. Über eine Suchleiste soll nach Städten, Ländern und anderen POIs gesucht werden können. Die Ergebnisse sollen nach Absenden der Suchanfrage in einem Pop-up Fenster angezeigt und nach Auswahl eines Ortes als Markierung auf der Karte erscheinen. Sobald sich Nutzer*innen für einen Bereich entschieden haben, soll mit langem Klicken auf einen Punkt auf der Karte ein rotes Rechteck erscheinen, das den Downloadbereich für die Nutzer*innen visuell eingrenzt. Mit Hilfe eines Sliders soll es Nutzer*innen möglich sein den Downloadbereich zu vergrößern oder zu verkleinern. Sobald das rote Rechteck den Downloadbereich eingrenzt, sollen zwei Knöpfe erscheinen, die es Nutzer*innen ermöglicht den ausgesuchten Bereich zu bestätigen, um zur nächsten Aktivität zu gelangen oder zu verwerfen, um eine neue Auswahl zu treffen. Des Weiteren soll es Nutzer*innen möglich sein ihre eigene Position auf der Karte über einen GPS-Knopf markieren zu lassen. Abbildung 5: Mockup des Download-Screens der OHDM MapViewer App 18 4.1.3 Add-Screen Abbildung 6: Mockup des Add-Screens der OHDM MapViewer App Nutzer*innen sollen nach Bestätigung des Downloadbereiches auf den Add-Screen (siehe Abbildung 6) weitergeleitet werden. Im Add-Screen sollen Nutzer*innen der Karte einen Titel zuteilen und einen Ordner zuweisen können. Soweit bereits Ordner bestehen, soll der Nutzer auf Klick eines Ordnericons, einen Ordner aus ihrer Liste auswählen können. Des Weiteren sollen Nutzer*innen den gewünschten Zeitpunkt der Karte über einen Kalender auswählen können. Falls Nutzer*innen keinen Titel für die Karte ausgewählt haben, soll bei Bestätigung eine Pop-up Nachricht erscheinen, die Nutzer*innen bittet einen Titel festzulegen. Das Festlegen eines Ordners für die Karte soll hingegen optional sein. 19 4.1.4 Map-Screen Abbildung 7: Mockups des Map-Screens der OHDM MapViewer App Der Map-Screen soll heruntergeladene Karten auf dem Gerät darstellen. Nutzer*innen sollen entweder durch Anklicken einer gewünschten Karte aus dem Archiv oder über den Menü-Screen auf diesen zugreifen können. Bei der Navigation aus dem MenüScreen soll die zuletzt geöffnete Karte aufgerufen werden. Durch langes Klicken auf einen Kartenpunkt sollen Nutzer*innen eine Markierung setzen können. Auf Klicken der Markierung soll sich ein Informationsfenster zur Markierung öffnen, indem Nutzer*innen einen Titel, Informationen und eine Markierungsfarbe aus einer Farbliste für die Markierung wählen können. Beim nächsten Laden der Karte sollen die markierten Orte und ihre gespeicherten Informationen wieder in die Karte geladen werden. Die Markierungen sollen ebenfalls durch einen Löschknopf im Informationsfenster entfernt werden können. Sobald Nutzer*innen mindestens zwei Karten heruntergeladen haben, soll es möglich sein zwei Karten nebeneinander darstellen zu können. Hierzu sollen Nutzer*innen über einen Plus-Knopf in einem Popup Fenster aus allen weiteren Karten, abzüglich der bereits geöffneten Karte, eine zweite Karte auswählen können. 26 Abbildung 11: Verteilungsdiagramm der OHDM MapViewer App 4.5.1 Zugriffserlaubnisse Bestimmte Zugriffe auf Gerätevariablen und -orte benötigen auf Androidgeräten die Erlaubnis des Geräteinhabers. Dies verhindert, dass Anwendungen ohne Wissen der Nutzer*innen auf sensible Daten wie den Gerätestandort oder Dokumente, Fotos und andere Medien zugreifen können, aber auch keine Internetverbindung herstellen können. In Android wird zwischen zwei Erlaubnissen unterschieden, install-time permissions und runtime permission. Beide der Erlaubnisse müssen im Manifest entsprechend deklariert werden. Install-time permissions sind Erlaubnisse, die direkt bei Installation durch das Android Betriebssystem genehmigt werden [36]. Nutzer*innen stimmen durch Downloaden der Anwendung automatisch zu die notwendigen Zugriffe zu gewähren. Dies sind in der OHDM MapViewer Anwendung die INTERNET und die NETWORK_ACCESS Erlaubnis, die notwendig sind, um in der DownloadActivity die aktuelle Karte über den Mapnik Server zu laden und das Suchen von Orten über die Suchleiste zu ermöglichen. 27 Runtime permissions hingegen müssen zusätzlich in der Anwendung genehmigt werden. Dazu zählen in der OHDM MapViewer Anwendung die MANAGE_EXTERNAL_STORAGE Erlaubnis, um die Kartendateien im externen Speicher auszulesen, sowie die ACCESS_COARSE_LOCATION Erlaubnis, um in der DownloadActivity, den derzeitigen Standort der Nutzer*innen zu markieren. Seit Android 11 hat Android seine Erlaubnisregelungen geändert und den Zugriff auf Dateien und Services außerhalb der Anwendung weiter erschwert. Um Zugriff auf Gerätespeicher außerhalb des internen Speichers der Anwendung zu erhalten, wird die MANAGE_EXTERNAL_STORAGE Erlaubnis benötigt. Da diese Erlaubnis jedoch das Auslesen aller Dateien der Nutzer*innen ermöglicht, werden nur spezielle Anwendungen wie zum Beispiel Dateimanagementanwendungen mit dieser Erlaubnis im Google Playstore zugelassen [37]. Eine Zulassung der OHDM MapViewer Anwendung zur Veröffentlichung im Google Playstore ist somit ausgeschlossen. Da eine Veröffentlichung momentan nicht vorgesehen ist, wurde diese Einschränkung für die Benutzerfreundlichkeit der Anwendung hingenommen. Falls zu einem späteren Zeitpunkt eine Veröffentlichung im Google Playstore erwünscht ist, kann mit Hilfe einer expliziten Auswahl der gewünschten Kartendatei aus dem Dateisystem der Nutzer*innen, der Ausschluss umgangen werden. Alle genannten runtime Permissions außer die ACCESS_COARSE_LOCATION sollen in der MenuActivity auf Klick einer Menüoption abgefragt werden. Die MANAGE_EXTERNAL_STORAGE Erlaubnis soll bereits in der onCreate() Methode angefragt werden, da ohne sie die Anwendung nicht funktionsfähig ist. Die ACCESS_COARSE_LOCATION soll hingegen in der DownloadActivity abgefragt werden, sobald der GPS-Knopf durch Nutzer*innen betätigt wird. 28 5 Implementierung Nachfolgend wird die Implementierung des im vorherigen Kapitel erstellten Konzepts komponentenweise erläutert. Dabei wird die detaillierte Beschreibung der Implementierung auf die Kernfunktionalitäten beschränkt. Der Quellcode ist unter folgendem Link auf Github verfügbar: https://github.com/AntjeSt/OHDMMapViewerApp.git Alle Komponenten wurden in Verwendung des Facade und des Factory Method Patterns erstellt. Die Komponenten besitzen daher eine Factoryklasse, die über jeweilige produceInstance() Methoden, das Interface der jeweiligen Facadeklasse mit ihrer Implementierung zurückgibt. Von außerhalb kann auf die Komponenten demnach nur auf die im Fassaden Interface definierten Methoden zugegriffen werden und keine Instanzen der Fassadenimplementierung erstellt werden. 5.1 MapViewerModel Die MapViewerModel Komponente ist für die Datenhaltung der Kartendaten zuständig und implementiert die beiden Klassen Map und OHDMMarker (siehe Abbildung 12). 29 Abbildung 12: Abhängigkeitsdiagramm der MapViewerModel Komponente 5.1.1 Kartenobjekte Die Map Klasse (siehe Abbildung 13) definiert alle Kartenobjekte, die in der OHDM MapViewer Anwendung verwendet werden. Jedes Kartenobjekt muss zwangsläufig einen Titel, ein Datum und eine Karten-ID erhalten. Der Titel und das Datum werden als Parameter an den Konstruktor übergeben. Die eindeutige nummerische Karten-ID wird bei Erstellung des Kartenobjektes generiert. Eine eindeutige Karten-ID gestattet das Löschen und Verändern eines Kartenobjekts, auch wenn sich andere Werte, wie der Name der Karte, ändern. Des Weiteren können Nutzer*innen beim Erstellen einer neuen Karte einen Ordner für die Karte auswählen oder erstellen. Falls der Karte ein Ordner zugewiesen wird, kann dieser über einen zweiten Konstruktor als String Parameter übergeben werden. Der eindeutige Kartendateipfad, mapFilePath besteht aus der Karten-ID und dem relativen Dateipfad, der beim Importieren der Kartendatei festgelegt wird. Anstelle eines eindeutigen Kartennamens wurde, die Karten-ID gewählt, um bei Veränderungen des Namens die Kartendatei unverändert zuordnen zu können und kein erneuter Zugriff auf die Kartendatei notwendig ist. Die mapFilePath Variable bestimmt, ob die Karte in 30 der ArchiveActivity als herunterladende Karte oder als heruntergeladene Karte dargestellt wird und somit geöffnet, gelöscht und bearbeitet werden kann. Wenn der Wert der mapFilePath Variable null ist, gilt sie als nicht heruntergeladen. Markierungen, die Nutzer*innen auf der Karte einfügen, werden in einer Arrayliste als OHDMMarker Objekte gespeichert und bei Aufruf der Karte aus der Arrayliste geladen. Alle Objektvariablen besitzen zugehörige getter und setter Methoden. Der besseren Übersicht wegen wurden diese nicht mit in das Klassendiagramm Abbildung 13 übernommen. Abbildung 13: Gekürztes Klassendiagramm Map - OHDMMarker Beziehung 5.1.2 OHDMMarker Objekte Die OHDMMarker Klasse definiert die Markierungen einer Karte. OHDMMarker sind Markierungen die, dieselben Objektvariablen wie die im MapViewerView verwendeten Osmdroid Marker (siehe Abschnitt 5.2.3 Marker) besitzen. Dies sind eine eindeutige Marker-ID, die Geoposition des Markers, ein Titel, eine Farbe und ein Informationstext. Im Gegensatz zu der Osmdroid Marker Klasse implementieren die OHDMMarker das Java Serializable Interface. Eine Serialisierung der Osmdroid Marker aus dem MapViewerView war nicht möglich, ist für die Datenspeicherung in einer Textdatei jedoch zwingend notwendig. 31 5.1.3 Datenspeicherung Alle Kartenobjekte werden in der MapViewerModelImpl Klasse in einer mapList als Arrayliste gespeichert (siehe Abbildung 14). Veränderungen und Löschung eines Kartenobjektes werden in der MapViewerModelImpl über die deleteMap(Map map) und updateMap(long mapID, String title, String folder String title) Methoden durchgeführt. Die Methoden iterieren über die mapList und suchen nach einer übereinstimmenden KartenID zu der als Parameter übergebenden KartenID. Dies gilt gleichermaßen für das Hinzufügen, Ändern oder Löschen von Markern. Für den Recents Bereich in der ArchiveActivity werden, die letzten drei geöffneten Karten nach dem Fifo-Prinzip, mittels einer eigenen Implementierung einer Queue, der RecentQueue, gespeichert. Gegenüber einer Queue hat die RecentQueue den Vorteil, dass Elemente an den Anfang der Queue hinzugefügt werden. Das Persistieren der Daten wird von der Subkomponenten FileManager durchgeführt. Bei Instanziierung des MapViewerModels über die MapViewerModelFactory wird dieser mit erstellt und liest die Kartendaten aus einer Text-Datei im internen Speicher Abbildung 14: Gekürztes Klassendiagramm der MapViewerModel Komponente 32 der Anwendung in die mapList der MapViewerModelImpl ein. Beim Einlesen der mapList durch den FileManager wird die Arrayliste serialisiert, weshalb die Map und OHDMMarker Klassen das Java Serializable Interface implementieren müssen. Je nach Nutzerinteraktion werden die Daten direkt zum Persistieren an den FileManager weitergeleitet oder vorerst nur in der mapList zwischengespeichert und bei Beenden einer Activity persistiert. Beim Löschen oder Hinzufügen eines Kartenobjektes sollen Datenverluste durch unerwartete Abbrüche der Anwendung vermieden werden. Daher wird in den entsprechenden Methoden jeweils die fileManager.saveMapListToFile() Methode aufgerufen, die die geupdatete mapList in die mapList.txt Datei liest. Des Weiteren wird das aktuell festgelegte Rendertheme und die RecentQueue über den FileManager in den SharedPreferences gespeichert. SharedPreferences ist ebenfalls eine Text-Datei die Schlüssel-Wert-Paare persistieren kann und von Android unterstützt wird. In der getTheme() Methode wird eine Referenz zur SharedPreferences Datei hergestellt und mit einem Editor bearbeitet. Beim ersten Start der Anwendung wird hier das default Rendertheme hinterlegt und bei Veränderung des Renderthemes in der SettingsActivity durch ihr neues Rendertheme ersetzt. Sobald das Rendertheme für die Darstellung der Karte angefragt wird, wird in den SharedPreferences nach dem theme Schlüssel gesucht und für den gegebenen Wert aus dem FileManager der zugehörige Dateipfad zum Rendertheme zurückgegeben. 5.2 MapViewerView Die MapViewerView Komponente ist für die Benutzeroberfläche zuständig. Der Übersicht wegen wurde das in Abbildung 15 dargestellte Verteilungsdiagramm der MapViewerView Komponente, um die Adapter und Listener der Recyclerviews und Dialoge, die Referenz jeder Activity zum MapViewerViewModel sowie den Android Superklassen gekürzt. Ein RecyclerView ist eine Android View, welches dynamische Daten effizient auf der Benutzeroberfläche darstellt [38]. Jede Activity erbt von der Android AppCompatActivity Klasse, das MapViewFragment 33 erbt von der Android Fragment Klasse und jeder Dialog erbt von der Android DialogFragment Klasse. Des Weiteren haben alle Activities, Fragments und DialogFragmente eine Referenz zum MapViewerViewModel, um die Daten aus dem MapViewerModel zu erhalten. Ein Fragment ist ein wiederverwendbares Modul in einer Activity, das an den Lebenszyklus der Activity gebunden ist und dennoch eigenständig gesteuert werden kann [39]. Das DialogFragment ist eine Subklasse des Fragments, das ein Dialog Objekt beinhaltet, das über der Activity schwebt [40]. Abbildung 15: Abhängigkeitsdiagramm der MapViewerView Komponente 5.2.1 Kartenarchiv Die ArchiveActivity stellt eine Bibliothek der gespeicherten Kartendaten im ArchiveScreen bereit. Jeder der im Konzept vorgestellten Bereiche wird mit Hilfe eines RecyclerViews geladen, welcher in den setUp[RecyclerView]() Methoden in der ArchiveActivity mit einem Adapter verbunden wird. Der Adapter gibt mit Hilfe eines Viewholders jeweils ein View mit den derzeitigen Daten der Position aus der Kartenoder Ordnerliste zurück. Für das Anwenden von unterschiedlichen Layouts und Klickmethoden, auf zum Beispiel die Kartenobjekte des AllMapsRecylerView, ermittelt 34 die getViewType(int position) Methode den Darstellungstypen. Wenn die mapFilePath Variable des derzeitigen Kartenobjekts den Wert null hat, wird der VIEW_TYPE_DOWNLOADING angewendet und das festgelegte Downloading Layout für den Karteneintrag verwendet. Im AllMapsViewHolder wird somit kein Klicklistener für das View festgelegt und Nutzer*innen können die Karte nicht öffnen. Durch gleiche Vorgehensweise konnte im AllMaps Bereich über den Darstellungstypen ein Element an die Kartenelemente hinzugefügt werden, das Nutzer*innen eine weitere Karte hinzufügen lässt. Damit Klickevents der Nutzer*innen auf eine Karte oder einen Ordner in den RecyclerViews von der ArchiveActivity erfasst werden können, wird das Observer Pattern verwendet. Für das Erfassen von kurzen Klicks auf einen Ordner oder eine Karte wird im Viewholder für jedes View die setOnClickListener() Methode festgelegt. In den RecyclerViews sind das die onItemClick[Adaptername]() Methoden des ArchiveItemClickListener Interface. In der ArchiveActivity, die ebenfalls den ArchiveItemClickListener implementiert, werden diese Methoden für alle RecyclerViews implementiert und bei Klick ausgeführt. Für das Löschen von Karten und Ordnern öffnet sich auf langem Klick ein Kontextmenü. Android bietet hierfür ebenfalls ein Interface View.OnCreateContextMenuListener, das der Viewholder implementiert. Die setOnCreateContextMenuListener() Methode kann dadurch im Viewholder ebenso an alle Views, die vom Typen VIEW_TYPE_DOWNLOADED sind, gesetzt werden. Die onCreateContextMenu(ContextMenu menu, View v, ContextMenu.ContextMenuInfo menuInfo) Methode erstellt die Auswahloptionen Edit und Delete, die den Nutzer*innen im Kontextmenü zur Verfügung stehen. Wenn Nutzer*innen auf eine Menüoption klicken, wird die onContextItemSelected(@NonNull MenuItem item) Methode ausgelöst, die in der ArchiveActivity implementiert ist. Je nach Auswahl der Nutzer*innen wird dadurch ein Popup zum Editieren des Ordners oder der Karte geöffnet, oder das Objekt gelöscht. In der folgenden Abbildung 16 werden die beschriebenen Verbindungen zwischen den Klassen beispielhaft mit dem AllMapsRecyclerView in einem verkürztem 35 Klassendiagramm dargestellt. Abbildung 16: Gekürztes Klassendiagramm zur Darstellung der ArchiveActivity zu Auf Klick eines Ordners wird in der implementierten onItemClickFolderAdapter(View view, position int) der Name des Ordners der geklickten Position ermittelt und als Extra dem Intent angehangen, um den Ordnernamen dadurch mit an die FolderActivity zu übertragen. In der FolderActivity kann über die getIntent().getStringExtra(key) Methoden auf den Wert zugegriffen werden. Das gleiche Prinzip der Übertragung im Intent gilt für alle Übertragungen von einer Activity zu einer anderen. 5.2.2 Visualisierung der Karten Auf Klicken einer Karte in der ArchiveActivity wird das Kartenobjekt an die MapViewActivity weitergeleitet. In der onCreate() Methode der MapViewActivity wird zunächst geprüft, ob der Intent, ein Kartenobjekt enthält und daher direkt an ein MapViewFragment zum Visualisieren übergeben werden kann oder ob das Kartenobjekt den Wert null hat. Wenn kein Kartenobjekt mit dem Intent übergeben wurde, bedeutet dies, dass die MapViewActivity aus der MenuActivity gestartet wurde und über das MapViewerViewModel geprüft werden muss, ob in den SharedPreferences eine zuletzt 42 MapViewerViewModelImpl alle Methoden, die vor Weiterleitung an eine andere Komponente eine Datenänderung vornehmen. Der Übersicht wegen wurden die lediglich weiterleitenden Methoden an die Komponenten ServerCommunication und MapViewerModel sowie die Fassaden Factory und das Fassaden Interface nicht mit dargestellt. Die saveMap(String title, String date, String folder) und saveMap(String title, String date) Methoden instanziieren neue Kartenobjekte, sobald Nutzer*innen in der AddActivity eine neue Karte hinzufügen und leiten diese anschließend an das MapViewerModel zur Speicherung weiter. Die getAllMapsOrderedAlphabetically(), getAllRemainingMapsOrderedAplahabetically(Map map) und die getAllFoldersOrderedAlphabetically() Methoden sortieren die Daten aus dem MapViewerModel bevor die Ordnerund Kartenlisten zur Darstellung in die RecyclerViews der DialogFragmente und Activities an die MapViewView Komponente weitergeleitet werden. Zusätzlich wird in der getAllRemainingMapsOrderedAlphabetically(Map map), die als Parameter übergebene Karte aussortiert, um im MapPickerDialog der MapViewActivity nur die nicht geöffneten Karteneinträge zum Einfügen anzubieten. Des Weiteren wird in der MapViewerViewModelImpl in der convertMarkerToOHDMMarker(Marker marker) Methode und der convertOHDMMarkerToMarker(OHDMMarker marker) Methode das Überführen der Marker in die jeweils andere Klasse durchgeführt. Wie unter Abschnitt 5.1.3 Datenspeicherung erläutert, muss diese Umformung aus Gründen der Datenspeicherung erfolgen. 5.3.1 Parsen der angefragten Kartendaten Der in der DownloadActivity ausgewählte Bereich liegt als Bounding Box vor und wird über eine Liste mit ihren Eckpunkten als geografische Koordinaten definiert. Das serverseitige Exporttool OHDMConverter benötigt als Parameter hingegen den 43 angefragten Kartenbereich als ein im WKT-Format repräsentiertes Polygon. In der requestData(Map map, ArrayList<GeoPoint> boundingbox) Methode wird daher eine Instanz der WKTConverter Klasse erstellt, um die Geopunkte des ausgewählten Kartenbereichs vor der Serveranfrage in das WKT-Format zu überführen. Die Geopunkte der Bounding Box in der DownloadActivity müssen vorher in Koordinaten umgewandelt werden, die an erster Stelle durch ihre Longitude und nicht wie bei geografischen Koordinaten üblich zuerst durch ihre Latitude definiert werden. Hierzu werden die Geopunkte zunächst in der geoPoint2CoordinateArray (ArrayList<GeoPoint> geoPointsBox) Methode in ein Array aus Koordinaten umgeformt. Gleichzeitig wird die erste Koordinate dupliziert und an das Ende des Arrays eingefügt, damit aus ihnen ein geschlossenes Polygon entsteht. Mittels der JTSBibliothek können Polygone in das WKT-Format umgeschrieben werden. JTS ist eine Open-Source Software, die das Bearbeiten von Vektor Geometrien ermöglicht [42]. Des Weiteren wird das Datum des Kartenobjekts über den DateManager in der mirrorDateString(String date) Methode in das für den OHDMConverter notwendige Datenformat umgeschrieben. Zusammen mit der KartenID des Kartenobjekts werden die Anfragedaten anschließend über die sendFileRequest(String fileName, String date, String wkt) an die ServerCommunication Komponente weitergeleitet. Der beschriebene Ablauf und die Interaktionen der einzelnen Instanzen von der Bestätigung der Kartendatei durch die Nutzer*innen bis zum Übermitteln der Anfrage an die ServerCommunication Komponente ist im folgenden Sequenzdiagramm (siehe Abbildung 20) dargestellt. 44 Abbildung 20: Sequenzdiagramm für die Verarbeitung einer Kartenanfrage im MapViewerViewModel 5.3.2 Lokale Push-Benachrichtigung Nachdem die angefragte Karte an die OHDM MapViewer Anwendung übertragen wurde, werden Nutzer*innen darüber, durch eine Benachrichtigung auf dem Smartphone informiert. Für die Push-Benachrichtigung wird zunächst ein NotificationChannel benötigt. NotificationChannel ist eine Androidklasse, die es ermöglicht Benachrichtigungen zu kategorisieren [43]. Der Benachrichtigungskanal für die Benachrichtigung von Nutzer*innen wird bei Instanziierung der MapViewerViewModel Komponente in der DownloadNotification Subkomponente über die createNotificationChannel() Methode instanziiert. Sobald die Kartendatei heruntergeladen wurde, wird aus der SftpService Klasse der ServerCommunication Komponente, die mapViewerViewModel.showNotification() Methode aufgerufen, welche intern an die DownloadNotification Klasse delegiert wird (siehe Abbildung 19). In der showNotification() Methode wird die Benachrichtigung mit einem Icon und dem 45 anzuzeigenden Text erstellt. Damit Nutzer*innen auf Klick der Benachrichtigung die ArchiveActivity gestartet wird, wird mit der notification.setContentIntent(pendingIntent) Methode ein PendingIntent an die Benachrichtigung geknüpft. PendingIntents können, im Gegensatz zu einem Intent, von außerhalb der Anwendung ausgelöst werden, so wie es bei Benachrichtigung in der Statusleiste des Smartphones erforderlich ist. Erst bei Terminierung des Downloadprozesses resultiert es in einer PushBenachrichtigung, die Nutzer*innen darüber informiert, dass die angefragte Kartendatei in der ArchiveActivity bereitliegt. 5.4 ServerCommunication Damit Kartendaten für Nutzer*innen auf dem Smartphone offline zu Verfügung stehen, müssen die Kartendaten aus der OHDM-Datenbank heruntergeladen werden. Die ServerCommunication Komponente muss dazu die Kartenanfrage an die OHDMDatenbank senden, die Push-Benachrichtigung des Notification Service verarbeiten und die Kartendatei anschließend importieren. Die ServerCommunication Komponente besteht aus dem ConnectionObserver, der überprüft, ob eine Internetverbindung besteht, dem FireBaseMessagingService, der die Push-Benachrichtigungen empfängt, dem HttpService, der die Kartendatei anfragt und dem SftpService, der die Kartendatei herunterlädt. Zusätzlich befindet sich der GeoCoder in der ServerCommunication Komponente, der das Geocoding in der DownloadActivity übernimmt. Die Komponenten sind im folgenden Klassendiagramm in Abbildung 21 dargestellt. Zur Übersichtlichkeit wurde auf die Darstellung der ServerCommunicationFactory und dem ServerCommunication Interface verzichtet. 46 Abbildung 21: Gekürztes Klassendiagramm der ServerCommunication Komponente 5.4.1 Anfrage der Kartendaten über HTTP Die initiale Anfrage einer Kartendatei wird über das HTTP-Protokoll gesendet. Clientseitig wird die OKHttp Bibliothek genutzt. OKHttp ist eine clientseitige Java Bibliothek zum Senden von HTTP-Anfragen [44]. Es wurde OKHttp gewählt, da es gegenüber der HTTP Java Klassen eine bessere Benutzerfreundlichkeit hat und eine bessere Fehlerbehandlung unterstützt. Die ServerCommunication Fassade startet nach Aufruf der sendFileRequest(String fileName, String date, String wkt) Methode durch die MapViewerViewModel Komponente den HttpService und übergibt im Intent alle Anfrageparameter zuzüglich eines Firebase Tokens zur Identifikation der anfragenden Nutzer*innen. Weitere Informationen zum Token folgen in Abschnitt 5.4.2 Downloadbenachrichtigung. 47 Die gesamte HTTP-Anfrage wird in einem Hintergrundthread bearbeitet, da diese langwierig sein kann und der Mainthread, der bei Android für die UI zuständig ist, nicht blockiert werden darf. Der HttpService stellt eine Verbindung über die Klassenvariable URL her und übermittelt die Anfragedaten im Request Body an den Server. OKHttp stellt zwei Callback Methoden zur Verfügung, um das Ergebnis der Anfrage weiterverarbeiten zu können. Wenn die Anfrage an den Server fehlschlägt, wird durch den Fehlercode das onFailure( Call call, IOException e) Callback ausgelöst. In diesem wird die httpRequestFailed() Methode des MapViewerViewModels aufgerufen, die das Kartenobjekt wieder löscht. 5.4.2 Downloadbenachrichtigung Nachdem der OHDMConverter die Kartendatei erstellt hat, soll die OHDM MapViewer Anwendung über eine Push-Benachrichtigung darüber informiert werden. Die Push-Benachrichtigungen vom Server können mit Hilfe von Notification Services wie dem Google Framework Firebase Cloud Messaging (FCM) implementiert werden. Das FCM ist bis zu 10.000 Verarbeitungen pro Monat kostenlos und stellt somit erst einmal keine Kosten für das OHDM-Projekt dar [45]. Um die Firebase Services zu nutzen, wurde ein Firebase Account für OHDM erstellt und ein OHDM-Projekt mit Verweis auf den Paketnamen der Anwendung hinzugefügt. Zur Einbindung der Firebase Services wird in der Plattform eine Google-Service-JSON Konfigurationsdatei zum Download freigegeben, die Informationen zur Authentifizierung und Konfiguration des Projektes enthält. Diese Datei wurde der OHDM MapViewer Anwendung hinzugefügt, damit Firebase eine Verbindung zur Anwendung herstellen kann. Damit die Anwendung Push-Benachrichtigungen entgegennehmen kann, enthält die ServerCommunication Komponente ein FireBaseMessagingService, der von der Firebase Klasse FirebaseMessagingService erbt. Zusätzlich wurde der Service im Manifest deklariert, um auf die von Firebase 48 ausgelösten com.google.firebase.MESSAGING_EVENT Intents reagieren zu können. Zur Identifikation der Nutzer*innen wird bei Instanziierung der ServerCommunicationImpl über die FirebaseMessaging.getInstance().getToken() ein eindeutiger Token generiert, der mit der HTTP-Anfrage an den Server geschickt wird. Der Server muss diesen Token nach Kartenerstellung mit an den Firebase Service schicken, um die Kartendatei zuordnen zu können. Die onMessageReceived(RemoteMessage message) Methode wird ausgeführt wenn der FireBaseMessagingService einen MESSAGING_EVENT Intent erhält und die OHDM MapViewer Anwendung sich momentan im Vordergrund befindet [46]. Der Downloadprozess der Kartendatei wird hierbei sofort über die mapViewerViewModel.downloadFile(messageData.get("mapID") Methode initiiert. Die Karten-ID, der serverseitig erstellen Kartendatei, wird durch den serverseitig gesetzte Schlüssel mapID aus den Daten der Benachrichtigung gelesen und als Parameter mit an die MapViewerViewModel Komponete übergeben. Sobald sich die Anwendung im Hintergrund befindet, wird die Push-Benachrichtigung in der Taskleiste angezeigt. Der Aufruf der onMessageReceived(RemoteMessage message) Methode wird zwar registriert, jedoch durch das Android-Betriebssystem behandelt [46]. Erst auf Klick der Push-Benachrichtigung, werden Nutzer*innen in die OHDM MapViewer Anwendung weitergeleitet. Die Karten-ID wird dabei aus den Extras des Intents herausgelesen und dann ebenfalls in der mapViewerViewModel.downloadFile(mapID) Methode an die MapViewerViewModel Komponente weitergeleitet. Die Szenarien sind in der Abbildung 22 dargestellt. 5.4.3 Download der Kartendatei mittels SFTP Das MapViewerViewModel ruft nach Erhalt der Serverbenachrichtigung die downloadMapFile(String mapID) Methode der ServerCommunication Komponente auf. Intern startet die ServerCommunication den SftpService und übergibt im Intent die KartenID, die zugleich der Dateiname der bereitstehenden Kartendatei auf dem Server ist. Der SftpService stellt anschließend über die in der HOST Variablen deklarierte IP- 49 Adresse in einem Hintergrundthread eine Verbindung zum Server her. Die Verbindung wird über das SSH File Transfer Protocol (SFTP-Protokoll) realisiert. Das SFTP-Protokoll ist ein Datei Transfer Protokoll, welches Dateien schnell verschlüsselt versendet [47]. Das Authentisieren der Clients wird in der OHDM MapViewer Anwendung über ein Benutzernamen und Passwort umgesetzt, die als Klassenvariablen definiert wurden. Diese müssen auf der OHDM-Datenbank hinterlegt werden. Für die Implementierung des SFTP-Clients wurde die JSch Bibliothek verwendet. Jsch ist eine Java Implementation für das Secure Shell Protokoll, auf dem das SFTPProtokoll basiert [48]. Über die Jsch.getSession(USERNAME, HOST, Port) wird eine Session erstellt und über die setPassword(PASSWORD) Methoden das Passwort festgelegt. Anschließend wird für die Session ein SFTP-Kanal eröffnet, der sich mit dem Server verbindet. Bei bestehender Verbindung wird die Kartendatei in den durch die mapViewerViewModel.getStorageLocation(String mapID) Methode festgelegten Speicherort importiert. Im folgenden Sequenzdiagramm wird der beschriebene Ablauf von dem Erhalt der Downloadbenachrichtigung bis zum Herunterladen der Kartendatei dargestellt (siehe Abbildung 22). 50 5.4.4 Geocoding Um die Anforderung umzusetzen, dass ein Ort auf der Karte über die Suchleiste der DownloadActivity gefunden werden kann, bedarf es Geocoding. Geocoding bezeichnet den Prozess aus einem gegebenen Ort die Latitude und Logitude herzustellen. Die Bearbeitung des eingegebenen Suchbegriffs der Nutzer*innen wird intern an die GeoCoder Klasse delegiert. GeoCoder ist dafür verantwortlich eine Verbindung zu Novinatim herzustellen und die Abfrageergebnisse entgegenzunehmen. Novinatim ist ein Geocoding Werkzeug, das die Datenbank von OSM nach Parametern durchsuchen kann [49]. Anstelle die Novinatim API direkt zu nutzen, wurde die angebotene Schnittstelle über das OSMbonusPack verwendet. Dies ermöglicht es Zeit bei der Entwicklung zu sparen, da die Novinatim Querysyntax und ihre Parameter nicht erlernt werden müssen und das Auslesen und Konvertieren des Rückgabeergebnisses aus der JSON-Datei in eine Liste aus Address Objekten von OSMbonuspack übernommen wird. Die implementierende Klasse im OSMBonuspack GeocoderNominatim besitzt die Abbildung 22: Sequenzdiagramm zum Empfangen von Push-Benachrichtigung und Herunterladen einer Kartendatei 51 getFromLocationName(String locationName, int maxResults) Methode, der die Eingabe der Nutzer*innen und die maximal gewünschte Anzahl von Ergebnissen als Parameter übergeben werden. Das Address Objekt ist ein von Android implementiertes Objekt im android.location Package, welches spezifische Eigenschaften für Adressen wie die Longitude und Latitude der geografischen Lage, der Postleitzahl, dem Ort etc. in Objektvariablen bereitstellt [50]. Die Adressen sollen für die Nutzer*innen zur Auswahl gut identifizierbar in den Suchleisten Dialog geladen werden. Der zusammengesetzte Name der Adresse zur Anzeige wie zum Beispiel „Brandenburger Tor, 1, Pariser Platz, Mitte, Berlin, 10117, Deutschland“ wird von OSMbonuspack in der Objektvariablen Bundle interlegt. Mit dem Schlüsselwort display_name wird dieser im SearchViewAdapter des AddressDialogs mit Hilfe der getExtras() Bundle-Methode geladen. Die gesamte Serverabfrage wird in einem Hintergrundthread bearbeitet. Aus dem Hintergrundthread kann jedoch nicht auf die UI zugegriffen werden. Daher wird eine Handler Instanz erzeugt, die den Mainthread referenziert und über die post() Methode, die Adressenliste über das MapViewerViewModel an die DownloadActivity übergibt. 58 7 Fazit Im folgenden Abschnitt wird die vorliegende Arbeit zusammengefasst und kritisch beleuchtet. Anschließend wird ein Ausblick für vorstellbare Weiterentwicklungsmöglichkeiten gegeben. 7.1 Zusammenfassung Das Ziel der Arbeit bestand darin eine mobile Anwendung in Verwendung von Osmdroid für die von der OHDM-Datenbank bereitgestellten Kartendaten zu konzeptionieren und zu implementieren. Zuallererst wurden die Grundlagen um das OHDM-Projekt und die Themen des Kartenrenderings mit Osmdroid und Mapsforge erarbeitet. Anschließend wurden Arten von Geodaten und Dateiformate sowie erprobte Design Patterns vorgestellt. Aufgrund dessen konnten die funktionalen und nicht funktionalen Anforderungen an die Anwendung festgelegt werden. Darauf basierend wurde ein Konzept für den Aufbau der Systemarchitektur erstellt. Da die Benutzeroberfläche ein essenzieller Faktor für die Umsetzung der funktionalen Anforderungen war, wurden Mockups der konzipierten Benutzeroberfläche designt. Darauffolgend wurde die Implementierung der Anwendung unter Verwendung von Osmdroid und Mapsforge zur Visualisierung der Kartendaten implementiert und getestet. Durch die modulare Tile Provider Architektur und vorhandene Schnittstellen zwischen Mapsforge und Osmdroid, konnten die zahlreichen Interaktionsmöglichkeiten die Osmdroid für das MapView anbietet mit dem schnellen, ressourcensparenden offline Kartenrendering durch Mapsforge verbunden werden. Der Einsatz von erprobten Design Patterns für die Softwarearchitektur half besonders bei dem Informationsaustausch zwischen verschiedenen Fragments, Activities, und Dialogen und dabei die Komponenten voneinander abzugrenzen. Die Speicherung der Karten und 59 Karteninformationen wurde nach Betrachtung der Vorund Nachteile möglicher Speicherorte und Speicherverfahren auf den internen und externen Speicher der Anwendung verteilt. Die Verbindung zur OHDM-Datenbank wurde über verschiedene für ihren Use Case optimierte Verfahren implementiert und getestet. 7.2 Bewertung der Ergebnisse Die erarbeiteten funktionalen und nicht funktionalen Anforderungen wurden alle in der OHDM MapViewer Anwendung umgesetzt. Nach umfangreicher Recherche über verschiedene Umsetzungsmöglichkeiten wurde eine gute Lösung für das offline Kartenrendering mittels Osmdroid gefunden, die Karten ressourcensparend anzeigen zu können. Bei der Umsetzung der Benutzeroberfläche wurde besonders auf ein ansprechendes, intuitives Design und Benutzerunterstützungen durch Eingabehilfen geachtet. Für die Benachrichtigung des Servers wurde auf Push-Benachrichtigungen von einem externen Notification Service zurückgegriffen, der ab einer bestimmten Kapazität pro Monat kostenpflichtig wird. Dies ist für das Open-Source Projekt nicht optimal, war jedoch nach Betrachtung anderer Vorgehensweisen die effizienteste Methode den Downloadprozess zu initiieren. Die Informationsbeschaffung gestaltet sich bei einigen Themen als schwierig. Besonders um die Mapsforge Bibliothek ließ die eingeschränkte Dokumentation oftmals keine genauere Recherche zu. Die detaillierte Betrachtung einzelner Teilkomponenten wie der AndroidGraphicFactory war deshalb lediglich auf die Angabe der verfügbaren Methoden beschränkt. Des Weiteren blieben einige Fragen zur Kompatibilität der unterschiedlichen Rendertheme Versionen und Karten unbeantwortet. Bei der Implementierung konnten nicht alle Bugs beseitigt werden. Ein bekannter Bug ist beispielsweise, dass die Markerfarben im MapView in der festgelegten Farbe der Nutzer*innen geladen werden, auf Klick des Icons sich jedoch in die ursprüngliche Farbe zurückfärben. Um alle anderen Funktionen zuverlässig zu testen, müssen ausgiebigere automatische Tests implementiert werden. Dies war aus Zeitgründen nicht mehr umsetzbar. 60 7.3 Ausblick Obwohl die Anwendung bereits viele Funktionen aufweist, kann die Anwendung in Zukunft noch weiterentwickelt werden. Denkbar wäre beispielsweise eine synchronisierte Kartendarstellung von zwei Karten im Sinne des gleichen Geopunktes in der Mitte des MapViews bei Verschiebung der Karte und weitere Renderthemes für mehr Darstellungsmöglichkeiten. Um nicht von einem externen Service wie Firebase Cloud Messaging abhängig zu sein, könnten die Push-Benachrichtigung durch einen eigenen Notification Service ersetzt werden. Zusätzlich sollte das Fehlermanagement für die Serververbindungen optimiert werden. Falls ein Verbindungsaufbau zum Server nicht möglich war, könnte beispielsweise nach einem festgelegten Intervall ein neuer Verbindungsaufbau gestartet werden. i Quellenverzeichnis [1] OHDM contributors. OpenHistoricalDataMap. [Online]. Available: http://www.ohdm.net/v2/index.html?date=2017-01-01. [Zugriff am 08.02.2023]. [2] Geoportal Rheinland-Pfalz. (2020, 10.06). Geodaten.[Online]. Available: https://www.geoportal.rlp.de/mediawiki/index.php/Geodaten [Zugriff am 08.02. 2023]. [3] T. Schwotzer. (2017). Offene Historische Daten und Karten. (Tagungsband UIS) [Online document]. Available: https://ceur-ws.org/Vol1919/paper18.pdf. [Zugriff am 08.02. 2023]. [4] T.Schwotzer. (2016, 6.06). Open Historical Data Map (OHDM) - work in progress. [Online document] Available: [Zugriff am 08.02.2023]. [5] OHDM contributors. OHDMConverter. [Online]. Available: https://github.com/OpenHistoricalDataMap/OHDMConverter/wiki. [Zugriff am 08.02.2023]. [6] Geos. Wkt. [Online]. Available: https://libgeos.org/specifications/wkt/. [Zugriff am 08.02.2023]. [7] Osmdroid contributors. (2019, 27.09). „Hello Osmdroid World“. [Online]. Available: https://osmdroid.github.io/osmdroid/How-to-use-the-osmdroidlibrary.html. [Zugriff am 08.02.2023]. [8] Osmdroid contributors. (2019, 27.09). Modular Tile Provider Architecture. [Online]. Available: https://osmdroid.github.io/osmdroid/Modular-TileProvider-Architecture.html. [Zugriff am 08.02.2023]. [9] Osmdroid contributors. MapTileProviderBase. [Online]. Available: https://osmdroid.github.io/osmdroid/javadocAll/org/osmdroid/tileprovider/ MapTileProviderBase.html. [Zugriff am 08.02.2023]. [10] Osmdoird contributors. MapTileProviderArray. [Online]. Available: https://osmdroid.github.io/osmdroid/javadocAll/org/osmdroid/tileprovider/ MapTileProviderArray.html. [Zugriff am 08.02.2023]. ii [11] Osmdroid contributors. BitmapTileSourceBase. [Online]. Available: https://osmdroid.github.io/osmdroid/javadocAll/org/osmdroid/tileprovider/til esource/BitmapTileSourceBase.html. [Zugriff am 08.02.2023]. [12] Osmdroid contributors. TileSourceFactory. [Online]. Available: https://osmdroid.github.io/osmdroid/javadocAll/org/osmdroid/tileprovider/til esource/TileSourceFactory.html. [Zugriff am 08.02.2023]. [13] Spektrum Akademischer Verlag Heidelberg. (2001) Overlay. [Online] Available: https://www.spektrum.de/lexikon/geographie/overlay/5767. [Zugriff am 08.02.2023]. [14] Osmdroid contributors. TilesOverlay. [Online]. Available: https://osmdroid.github.io/osmdroid/javadocAll/org/osmdroid/views/overlay /TilesOverlay.html. [Zugriff am 08.02.2023]. [15] Osmdroid contributors. (2019, 27.09). Geospatially referenced Icons. [Overlay]. Available: https://osmdroid.github.io/osmdroid/Markers,-Linesand-Polygons.html. [Zugriff am 08.02.2023]. [16] Osmdroid contributors. Overlay. [Online]. Available: https://osmdroid.github.io/osmdroid/javadocAll/org/osmdroid/views/overlay /Overlay.html [Zugriff am 08.02.2023]. [17] Osmbonuspack contributors. Osmbonuspack. [Online]. Available: https://github.com/MKergall/osmbonuspack. [Zugriff am 08.02.2023]. [18] Mapsforge contributors. Mapsforge. [Online]. Available: https://github.com/mapsforge/mapsforge. [Zugriff am 08.02.2023]. [19] Mapsforge contributors. AndroidGraphicFactory. [Online]. Available: https://javadoc.io/doc/org.mapsforge/mapsforge-mapandroid/latest/org/mapsforge/map/android/graphics/AndroidGraphicFactory. html. [Zugriff am 08.02.2023]. [20] Mapsforge contributors. (2014, 27.11). Rendertheme. [Online]. Available: https://github.com/lbarrosop/mapsforgemaster/blob/master/docs/Rendertheme.md. [Zugriff am 08.02.2023]. [21] Mapsforge contributors. (2022, 04.12) Assets directory. [Online]. Available: https://github.com/mapsforge/mapsforge/tree/master/mapsforgethemes/src/main/resources/assets. [Zugriff am 08.02.2023]. iii [22] Mapsforge contributors. Class AssetsRenderTheme. [Online]. Available: https://javadoc.io/doc/org.mapsforge/mapsforge-mapandroid/latest/org/mapsforge/map/android/rendertheme/AssetsRenderTheme .html. [Zugriff am 08.02.2023]. [23] P. LeBeau. AndroidSVG. [Online] Available: http://bigbadaboom.github.io/androidsvg/. [Zugriff am 08.02.2023]. [24] W3C. (2008, 22.12) Introduction. [Online]. Available: https://www.w3.org/TR/SVGTiny12/intro.html. [Zugriff am 08.02.2023]. [25] GISGeography (2023, 14.01). GIS Geography. Vector vs Ratser: What’s the Difference Between GIS Spatial Data Types?. [Online]. Available:https://gisgeography.com/spatial-data-types-vector-raster/. [Zugriff am 08.02.2023]. [26] Geodateninfrastruktur Niedersachsen. (2021, 06.12) Geodaten - Technisches Basisswissen [Online document] Available: https://www.geodaten.niedersachsen.de/startseite/datenangebot/geodaten_m etadaten/geodaten-88487.html. [Zugriff am 08.02.2023]. [27] OSM Community. (2023, 17.01). OSM XML. [Online]. Available: https://wiki.openstreetmap.org/wiki/OSM_XML. [Zugriff am 08.02.2023]. [28] Mapsforge contributors. (2022, 08.12). Specification: Mapsforge Binary Map File Format. [Online]. Available: https://github.com/mapsforge/mapsforge/blob/master/docs/SpecificationBinary-Map-File.md. [Zugriff am 08.02.2023]. [29] E. Gamma, R. Helm, R. Johnson, and J. M. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, 1st ed. Addison-Wesley Professional, 1994. [30] Devinsider. (2022, 22.04). Definition „Model View ViewModel“ - Was bedeutet MVVM?. [Online]. Available: https://www.dev-insider.de/was-bedeutet-mvvm-a-1103448/. [Zugriff am 08.02.2023]. [31] Google developers. (2023, 08.02). Activity. [Online]. Available: https://developer.android.com/reference/android/app/Activity [Zugriff am 08.02.2023]. [32] OSM Community. (2022, 10.01). Osmosis. [Online]. Available: https://wiki.openstreetmap.org/wiki/Osmosis. [Zugriff am 08.02.2023]. iv [33] Mapsforge contributors. (2021, 31.10). Mapsforge Map-Writer. [Online]. Available: https://github.com/mapsforge/mapsforge/blob/master/docs/Getting-StartedMap-Writer.md. [Zugriff am 08.02.2023]. [34] Google developers. (2023, 01.02). Data and file storage overview. [Online]. Available: https://developer.android.com/training/data-storage. [Zugriff am 08.02.2023]. [35] Google developers. (2022, 31.08). Services overview. [Online]. Available: https://developer.android.com/guide/components/services. [Zugriff am 08.02.2023]. [36] Google developers. (2023, 01.02). Permissions on Android. [Online]. Available: https://developer.android.com/guide/topics/permissions/overview. [Zugriff am 08.02.2023]. [37] Google developers. (2023, 01.02). Storage Updates in Android 11. [Online]. Available: https://developer.android.com/about/versions/11/privacy/storage. [Zugriff am 08.02.2023]. [38] Google developers. (2023, 01.02). Create dynamic lists with RecyclerView. [Online]. Available: https://developer.android.com/develop/ui/views/layout/recyclerview [Zugriff am 08.02.2023]. [39] Google developers. (2022, 16.11). Fragments. [Online]. Available: https://developer.android.com/guide/fragments . [Zugriff am 08.02.2023]. [40] Google developers. (2022, 17.06). Displaying Dialogs with Dialogfragments. [Online]. Available: https://developer.android.com/guide/fragments/dialogs. [Zugriff am 08.02.2023]. [41] Google developers. (2023, 23.01). Fragment manager. [Online]. Available: https://developer.android.com/guide/fragments/fragmentmanager. [Zugriff am 08.02.2023]. [42] Jts contributors. (2023, 09.03). JTS Topology Suite. [Online]. Available: https://github.com/locationtech/jts. [Zugriff am 08.02.2023] [43] Google developers. (2022, 08.02). NotificationChannel. [Online]. Available: https://developer.android.com/reference/android/app/NotificationChannel. [Zugriff am 08.02.2023]. v [44] OKhttp contributors. (2022). OKhttp. [Online]. Available: https://square.github.io/okhttp/. [Zugriff am 08.02.2023]. [45] Google Firebase. Pricing Plans. [Online]. Available: https://firebase.google.com/pricing. [Zugriff am 08.02.2023]. [46] Google Firebase. Empfangen Sie Nachrichten in einer Android-App. [Online]. Available: https://firebase.google.com/docs/cloudmessaging/android/receive?hl=de#sample-receive. [Zugriff am 08.02.2023]. [47] SSH. SSH File Transfer Protocol (SFTP): Get SFTP client & server. [Online]. Available: https://www.ssh.com/academy/ssh/sftp-ssh-file-transfer-protocol. [Zugriff am 08.02.2023]. [48] JCraft. JSch - Java Secure Channel. [Online]. Available: http://www.jcraft.com/jsch/. [Zugriff am 08.02.2023]. [49] Novinatim. Open-source geocoding with OpenStreetMap data. [Online]. Available: https://nominatim.org/. [Zugriff am 08.02.2023]. [50] Google developers. (2023, 08.02). Address. [Online]. Available: https://developer.android.com/reference/android/location/Address. [Zugriff am 08.02.2023]. [51] Google developers. (2022, 17.03). Fundamentals of testing Android apps. [Online]. Available: https://developer.android.com/training/testing/fundamentals. [Zugriff am 08.02.2023]. [52] Junit4 developers. (2016, 19.03). Assertions. [Online]. Available: https://github.com/junit-team/junit4/wiki/Assertions. [Zugriff am 08.02.2023]. [53] Mockito developers. How do I drink it?. [Online]. Available: https://site.mockito.org/. [Zugriff am 08.02.2023]. [54] Google developers. (2021, 27.10). Espresso. [Online]. Available: https://developer.android.com/training/testing/espresso/basics. [Zugriff am 08.02.2023]. vi Abkürzungsverzeichnis API Application Programming Interface etc. et cetera JSON JavaScript Object Notation MAP Mapsforge Binary Map File Format OHDM Open Historical Data Map OSM Open Street Map OSM-XML Open Street Map Extensible Markup Language PNG Portable Network Graphics POI Point of Interest SVG Scalable Vector Graphic UI User Interface URL Uniform Resource Locator WKT Well-Known Text XML Extensible Markup Language vii Eidesstaatliche Versicherung Hiermit versichere ich an Eides statt durch meine Unterschrift, dass ich die vorstehende Arbeit selbstständig und ohne fremde Hilfe angefertigt und alle Stellen, die ich wörtlich oder annähernd wörtlich aus Veröffentlichungen entnommen habe, als solche kenntlich gemacht habe, mich auch keiner anderen als der angegebenen Literatur oder sonstiger Hilfsmittel bedient habe. Die Arbeit hat in dieser oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen. Berlin, den 10.02.2023 Antje Stockhaus