Vespucci : Entwicklung eines Geodateneditors für das OpenStreetMap-Projekt auf der Android-Plattform

Transkript

1 Fachhochschule Wedel Fachbereich Medieninformatik Bachelorthesis Vespucci : Entwicklung eines Geodateneditors für das OpenStreetMap-Projekt auf der Android-Plattform Eingereicht von: Matthias Brandt Talstraße 15, Hamburg, Tel: (040) Abgegeben am: 3. März 2009 Erarbeitet im: 7. Semester Referent: Prof. Dr. Andreas Häuslein Fachhochschule Wedel Feldstraße Wedel Tel: (04103) Betreuer: Niels Linnemann Blau Mobilfunk GmbH Schulterblatt Hamburg Tel: (040)

2

3 Inhaltsverzeichnis 1 Einleitung Problemkontext Proprietäre Geodaten Proprietäre Smartphone-Plattformen Aufwand beim Erstellen von Geodaten Zielsetzung dieser Arbeit Entwicklung eines Geodateneditors für das OpenStreetMap-Projekt auf der Android-Plattform Das OpenStreetMap-Projekt (OSM) Projektstatus Projektstruktur Gleichberechtige Benutzer Bisheriges Benutzerverhalten Unabhängigkeit Lizenzmodell CC-BY-SA Datenmodell Datenelemente Tags Metadaten Aufbau einer OSM-XML-Datei Programmierschnittstelle ( API ) RESTful Design API OSM-Binary API Die Android-Plattform Architektur Modell-View-Controller (MVC)-Muster Vorteile Modell: XML View: Views Controller: Java-Klassen Interprozesskommunikation durch Intents Applikationslebenszyklus Automatisiertes Testen

4 3.5.1 Standardmöglichkeiten von Google Automatisierte Tests mit Positron Automatisierte Erzeugung mit AndroidAnt Geodateneditor Vespucci Analyse Zielgruppendefinition Technische Rahmenbedingungen Anforderungen Konzeption Datenstruktur UI-Konzept Klassenstruktur Schutz vor ungewollter Datenmanipulation viewbox-system Parsen der XML-Daten Vergleich der Datenhaltungsmöglichkeiten Implementation Zahlenrepräsentation der Geokoordinaten Logik User Interface (UI) Optimierungen Potential Weiterentwicklung als OpenSource-Projekt Verknüpfung mit anderen Projekten Erweiterung des Funktionsumfangs Ausblick Zusammenfassung Erfüllung der Anforderungen Vespucci im Feldversuch Perspektive OpenStreetMap Android Vespucci Doctype Definition (DTD) UI-Konzept: Skizze Rechtliche Hinweise Listings Tabellenverzeichnis i ii iii v vii

5 Abbildungsverzeichnis Literaturverzeichnis Eidesstattliche Erklärung ix xi xv

6

7 1 Einleitung Zunächst wird im Problemkontext aufgezeigt, dass proprietäre Geodaten und Smartphone-Plattformen nicht für das Allgemeinwohl zuträglich sind. Danach wird der Aufwand für das Sammeln von Geodaten verdeutlicht. Von dieser Situation ausgehend wird anschließend die Zielsetzung dieser Arbeit beschrieben. 1.1 Problemkontext Proprietäre Geodaten In der heutigen Wissensgesellschaft gewinnt das Wissen über ortsbezogene Informationen stetig an Bedeutung. Durch einen verstärkten Mobilisierungsgrad der Bevölkerung sind Menschen gezwungen, sich in ihnen unbekannten Gebieten zurecht zu finden oder den direkten Weg zu finden. Jedoch ist das Wissen über ortsbezogene Daten nicht frei verfügbar 1. Bisher sind Geodaten in signifikanter Menge nur gegen Gebühr bei Vermessungsämtern und gewinnorientierten Unternehmen erhältlich. Die daraus folgenden Konsequenzen sind: Verwehrung der Wissensfreiheit: Menschen in strukturschwachen Regionen wird der freie Zugang zu Wissen versperrt. Zwar machen die Lizenzgebühren für Navigationsgeräte nur einen kleinen Teil des Kaufpreises aus und verhindern damit oberflächlich betrachtet nur geringfügig den Zugang. Allerdings gibt es für viele Entwicklungsländer keine genauen Kartendaten, da es sich für die Kartenhersteller aufgrund der geringen Kaufkraft nicht rentiert, dort detaillierte Geodaten zu erfassen. Lizenzabgaben: Hersteller von Navigationsgeräten müssen für jedes Endgerät Lizenzgebühren an die Kartenhersteller bezahlen. Restriktionen: Privatpersonen ist es nicht gestattet, Kartenmaterial zu kopieren und beispielsweise auf Einladungen oder eigenen Webseiten zu veröffentlichen. Politische und militärische Zensur: Seit Beginn der Kartografie sind Karten nicht nur Orientierung für Handel und Reisen, sondern insbesondere von militärischer 1 Ausnahme bilden wenige Länder wie die USA, in denen alle Daten einer Behörde automatisch Allgemeingut ( Public Domain ) werden. 1

8 1 Einleitung Bedeutung. Nach Brunner führt dies dazu, dass bis in die Gegenwart Kartenmaterial entweder zurückgehalten wird, oder zur Desinformation verfälscht wird 2. Verfälschung: Clark belegt, dass Kartenhersteller absichtlich Straßendaten verfälschen, um Kopien entlarven zu können 3. Veränderungen, Anpassungen, Zusatzinformationen: Aufgrund proprietärer Datenformate und Restriktionen durch Lizenzbestimmungen ist es dem Benutzer in der Regel nicht möglich, Geodaten zu verändern oder neue hinzuzufügen. So ist er auf den Hersteller angewiesen, dass eine aktualisierte Version der Karte gegen erneute Gebühr angeboten wird Proprietäre Smartphone-Plattformen Bisher waren nahzu alle Betriebssysteme und Plattformen für Smartphones nur unter proprietären Lizenzen verfügbar. Dazu zählen Windows Mobile (Microsoft), Black- Berry (RIM), SymbianOS (Nokia) und seit Sommer 2007 Mac OS X in abgewandelter Form für das iphone (Apple). Durch das Geheimhalten des Quellcodes wird das Betriebssystem für Benutzer und Entwickler zu einer Blackbox: Niemand kann die genauen Vorgänge im System beobachten und auf Sicherheitslücken oder Hintertüren hin überprüfen. Auch eine Erweiterung des Systems um eine gewünschte Funktion ist ausgeschlossen. Wie bereits im vorigen Abschnitt gezeigt ermöglichen proprietäre Formate eine Zensur seitens der Hersteller. Besonders hervorzuheben ist im Bereich der Smartphones das Software-Vertriebsmodell des App-Store. Apple verbietet es dem Benutzer nicht durch den App-Store bezogene Fremdsoftware zu installieren. Jeder Entwickler, der sein Programm für das iphone vertreiben möchte, kann dies ausschließlich über den App-Store erreichen. Er muss sich dazu für eine jährliche Gebühr von 99 USD (bzw. 299 USD für firmeninterne Anwendungen) registrieren und 30% seines Umsatzes an Apple abgeben 4. Matthey berichtet davon, dass, sollte das Programm nicht den Vorstellungen Apples genügen oder in ähnlicher Weise bereits vorhanden sein, die Applikation abgelehnt wird 5. Wegen der Gefahr von Viren und anderen Schadprogrammen wird dem Entwickler von Drittsoftware oftmals nur ein kleiner Bereich im System zugewiesen, für das 2 Vgl. Brunner, Kurt; Unverhau, Dagmar (Hrsg.): Kap. Kap. 8 In Kartenverfälschung als Folge übergrosser Geheimhaltung? 2. Auflage. LIT Verlag Berlin-Hamburg-Münster, 2002, S. 167ff. 3 Clark, Andrew: Copying maps costs AA 20m. URL: Zugriff am Vgl. Stäuble, Markus: Ein bisschen Freiheit. ix, , Nr. 5, S. 131ff. 5 Vgl. Matthey, Florian: Funktion zu ähnlich wie itunes: Apple sperrt iphone-app Podcaster aus. URL: Zugriff am

9 1.2 Zielsetzung dieser Arbeit er Anwendungen programmieren kann. So hat zum Beispiel Apple erst auf öffentlichem Druck hin Entwicklern ermöglicht, nicht nur spezialisierte Webapplikationen zu schreiben, die über den internen Browser benutzt werden können 6, sondern auch native Applikationen zu programmieren Aufwand beim Erstellen von Geodaten Sollte eine Privatperson sich dazu entschließen, ihr Wissen über ihr bekannte Orte zu sammeln (im folgenden Mapper genannt), benötigt diese ein Gerät zur Positionsbestimmung. Durch sinkende Preise und ständige Weiterentwicklung sind heute GPS- Empfänger auch für Privatpersonen erschwinglich. Mit solch einem Gerät ausgerüstet kann ein Mapper die Orte aufsuchen und die gesammelten Koordinaten speichern. Anschließend überträgt er die Daten auf seinen Computer und verknüpft mit Hilfe eines Geodateneditors die gewonnenen Koordinaten mit dessen Wissen über Straßennamen oder anderen Informationen. Nun hat der Anwender die Möglichkeit, die Daten in Rohform oder als Karte visualisiert für Interessierte zu verbreiten. Der Umstand, die Daten erst auf einen PC zu laden, sie dort zu bearbeiten und anschließend ins Internet hochzuladen nimmt neben dem Sammeln der Daten selbst die meiste Zeit in der Produktionskette in Anspruch. 1.2 Zielsetzung dieser Arbeit Im vorangehenden Abschnitt wurde dargelegt, welche Problematik geschlossene Formate haben können und wie hoch der Aufwand für das Sammeln von Geodaten ist. Die Ziele dieser Arbeit werden nun anhand des Titels erläutert: Entwicklung eines Geodateneditors... Auf dem Markt für Geoinformationssysteme und -editoren gibt es eine große Auswahl an Software, die aufgrund der komplexen Thematik nicht intuitiv zu bedienen sind. Im Gegensatz dazu soll die innerhalb dieser Arbeit entwickelte Software selbst für ungeübte Nutzer sofort verständlich sein. Der Benutzer sollte ohne zusätzliches GPS- Gerät oder Notizblock Daten erstellen und verändern können. Das wichtigste Ziel ist jedoch, dass der Mapper einen Schritt in der Produktionskette spart: Das aufwändige Hochladen und Editieren am Computer. In Kapitel 4 wird ausführlich beschrieben, wie im Laufe dieser Arbeit der Geodateneditor Vespucci durch Analyse, Konzeption und Implementation entstanden ist. 6 Vgl. Stäuble, Markus: Ein bisschen Freiheit. ix, , Nr. 5, S. 131ff. 3

10 1 Einleitung Namensgeber der entstandenen Applikation ist der Kartograf und Entdecker Amerigo Vespucci 7, der aufgrund seiner Verdienste in der Kartografie ausgewählt wurde für das OpenStreetMap-Projekt... Das OpenStreetMap-Projekt stellt Geodaten unter der freien CreativeCommons-Lizenz Attribution-Share Alike 2.0 bereit. Diese erlaubt es jedem, die Daten zu kopieren, zu verändern und hinzuzufügen, solange er sie unter der gleichen Lizenzbedingung weitergibt und auf OSM als Quelle verweist. Dadurch wird beispielsweise dem Großstadtbewohner ermöglicht, neue Abkürzungen in die Karte einzutragen oder durch die Einträge anderer zu finden. Ein Inhaber einer KFZ-Werkstatt in Windhoek, Namibia, kann auf seinen Werbeflyern eine Umgebungskarte kostenlos aufdrucken und verteilen. Auf OpenStreetMap, das benutzte Datenmodell und die Programmierschnittstelle des Projekts wird in Kapitel 2 näher eingegangen auf der Android-Plattform Android ist eine OpenSource-Handset-Plattform, die es jedem ermöglicht, den Quellcode einzusehen, zu verändern und weiterzugeben. Darüber hinaus ist jede Applikation auf dem Gerät gleichberechtigt 8 : Wenn der Benutzer mit der Adressbuch-Applikation nicht zufrieden ist, kann er eine neue programmieren (lassen) und die alte ersetzen. Die Endgeräte können GPS-Empfänger und 3D-Grafik-Chipsätze beinhalten. Zusätzlich sind sie darauf ausgelegt, eine ständige Internetverbindung aufrecht zu halten (je nach Verfügbarkeit GPRS, EDGE, UMTS, WiFi). Eine Zensur über verfügbare Applikationen findet nicht statt: Das Installieren aus anderen Quellen als des Plattform-eigenen Market ist gestattet und alleine die Benutzer entscheiden durch einen Bewertungsmechanismus über die Qualität der einge- stellten Programme 9. In Kapitel 3 werden die Architektur sowie einige wichtige Details für die Softwareentwicklung auf dieser Plattform näher beschrieben. 7 Eigentlich Alberigo Vespucci ( ). Der Kartograf Bernd Waldseemüller hat nach ihm den Kontinent Amerika benannt. 8 Vgl. Meier, Reto: Professional Android Application Development. 1. Auflage. Indianapolis, USA: Wiley Publishing, 2009, S Chu, Eric: Android Market: a user-driven content distribution system. URL: http: //android-developers.blogspot.com/2008/08/android-market-user-driven-content.html Zugriff am

11 2 Das OpenStreetMap-Projekt (OSM) Wie bereits in der Einleitung (1.2.2) kurz vorgestellt, ist OpenStreetMap ein Projekt zur Verbreitung freier Geoinformationen. Das Ziel dieses Projektes ist es, die erste freie Weltkarte zu erstellen. Jeder kann die Daten verändern, hinzufügen oder löschen. 2.1 Projektstatus Mittlerweile sind fast Menschen bei OpenStreetMap angemeldet 1, wovon ca. zehn Prozent sich aktiv am Projekt beteiligen 2. Abbildung 2.1: OpenStreetMap Datenbankstatistik 3 1 OpenStreetMap: OpenStreetMap Statistics. URL: Zugriff am Vgl. Robinson, Andy: Percent of total user contributing. URL: Zugriff am Entnommen aus: Robinson, Andy: OpenStreetMap Database Statistics. URL: Zugriff am

12 2 Das OpenStreetMap-Projekt (OSM) Die Abbildung 2.1 zeigt die kummulierte Anzahl von Wegen, Knoten und Relationen zwischen August 2005 und Februar Seit Projektbeginn steigen die Datensätze kontinuierlich an, so dass am Ende der Skala dreihundert Millionen Knoten erreicht wurden. Doch nicht nur quantitativ, sondern auch qualitativ erreicht das Projekt immer mehr Fortschritte: So teilte OpenStreetMap im Oktober 2008 mit, dass die Straßenkartierung von Hamburg praktisch abgeschlossen sei 4. Problematisch hingegen sind Regionen mit geringerer Einwohnerdichte. Da sich hier rechnerisch weniger OSM-Interessierte befinden, werden diese Gegenden kaum in der Datenbank von Mappern erfasst. Nach eigenen Angaben sind beispielsweise viele Orte in der Oberpfalz mit weniger als zehn Prozent der Straßen erfasst Projektstruktur DB Server (API) OpenStreetMap XML XML JOSM Potlatch Merkaartor Editor Renderer Mapnik Osmarenderer Kosmos Drittanbieter Vektordaten & Tags Kartenbilder Mapper gewöhnlicher Benutzer Anwender Abbildung 2.2: OpenStreetMap Projektstruktur Ein Mapper, der Daten für OpenStreetMap bereitstellen möchte, fügt diese als Vektordaten und Tags 6 in einen Editor ein. Das Wissen, für welche Informationen welche Tags genutzt werden können, sucht sich der Mapper entweder über die entsprechende 4 Vgl. König, Peter: Freier Hamburger Straßenplan praktisch komplett. URL: meldung/ Zugriff am Vgl. o.v.: Oberpfalz. URL: Zugriff am siehe Kapitel Tags, Seite 11 6

13 2.2 Projektstruktur Wiki-Seite 7, oder ggf. über Tag-Presets, die der Editor bereitstellt. Die vom Mapper erstellten Daten werden in einem XML-Format 8 mittels HTTP an den Server ( API ) übertragen. Dieser verwaltet alle Daten und legt sie in der Datenbank ab. Sowohl der Editor, als auch ein Renderer können die vorhandenen Daten abfragen und nach eigenen Regeln interpretieren. Ein Renderer hat in der Regel ein Regelset, aufgrund dessen die Tags interpretiert und als Bilder gerendert werden. Diese Bilder kann der gewöhnliche Benutzer beispielsweise über die Projektseite9 abrufen Gleichberechtige Benutzer Ähnlich wie bei dem Enzyklopädie-Projekt Wikipedia ist jeder Benutzer gleichberechtigt. Zwar führt das in wenigen Fällen zu beabsichtigten oder unbeabsichtigten Falschinformationen, die jedoch durch die Masse der Benutzer aufgefangen wird. Da es sich bei den Daten von OpenStreetMap jedoch um objektiv eindeutig überprüfbare Informationen handelt, sind sogenannte Editwars, bei denen zwei Personen(gruppen) unterschiedlicher Meinung regelmäßig die Änderungen der anderen Gruppe wieder zurücksetzen, kaum zu erwarten. In vereinzelten Fällen können geografische Daten dennoch politische Ansichten widerspiegeln. Nach Coast war der Streit zwischen griechischen und türkischen Mappern auf Zypern im November 2007 der erste 10 Konflikt dieser Art. Streitpunkt auf beiden Seiten war die Benennung der Orte und Straßen in der jeweiligen Landessprache Bisheriges Benutzerverhalten Ramm/Topf führen die bislang einzigen zwei Möglichkeiten zur Geodatenerfassung auf: Der Mapper besucht mit einem GPS-Empfänger ausgerüstet die Orte und Straßen, die er erfassen möchte. Zusätzlich zu den GPS-Positionen werden beliebige ortsbezogenen Informationen, wie z.b. Straßennamen oder Briefkästen, gesammelt. 7 Für Deutschland: Features 8 siehe Kapitel 2.3 Datenmodell, Seite Vgl. Coast, Steve: Advice needed - dispute regarding names in Cyprus. URL: Zugriff am Vgl. o.v.: Advice needed - dispute regarding names in Cyprus. URL: Zugriff am Vgl. Ramm, Frederik/Topf, Jochen: OpenStreetMap - Die freie Weltkarte nutzen und mitgestalten. 1. Auflage. Berlin: Lehmanns Media, 2008, S

14 2 Das OpenStreetMap-Projekt (OSM) Anschließend läd er die GPS-Daten auf einen Computer um dort mit Hilfe eines Editors die Rohdaten als Vektordaten abzuzeichnen. Die gesammelten Informationen werden anhand der Map Features eingegeben und mit Koordinaten verknüpft. Zuletzt werden alle Daten auf den OSM-Server geladen. 2. Yahoo hat OpenStreetMap gestattet, seine Satellitenfotos zum Abzeichnen zu benutzen. In manchen Editoren lässt sich das Kartenmaterial anzeigen, so dass es der Mapper als Vektordaten nachzeichnen kann. Sollen allerdings weitere Informationen über die Elemente erstellt werden, braucht der Benutzer ein Ortswissen über den Kartenausschnitt, da sich die Erlaubnis von Yahoo nicht auf die Kartendaten, sondern nur auf die Satellitenbilder bezieht Unabhängigkeit Der Großteil der Infrastruktur wird in Großbritannien von der OpenStreetMap Foundation (UK Registered Limited) betrieben. Über diese Organisation kann sich das Projekt als juristische Person nach außen repräsentieren und ist unabhängig von großen Konzernen. Jeder in der Gemeinschaft kann sich in Verantwortungspositionen der Foundation wählen lassen und ein Mitbestimmungsrecht innerhalb des Vereins ausüben. Eine Mitgliedschaft ist allerdings keine Vorraussetzung für die Mitarbeit im Projekt. Die Foundation finanziert sich hauptsächlich durch Spenden und Sponsoren, aber auch durch die Einnahmen von Veranstaltungs- und Mitgliedschaftsgebühren. Nach eigenen Angaben wird das Geld hauptsächlich für Infrastruktur, aber auch für Anwaltskosten und Promotion ausgegeben Lizenzmodell CC-BY-SA-2.0 Creative Commons ist eine Non-Profit-Organisation, die sich zum Ziel gesetzt hat, einfache Standard-Lizenzen für Kreative bereitzustellen. Die Lizenzen sollen es den Urhebern ermöglichen, nach einem Baukastenprinzip eine gewünschte Weiternutzung zu gestatten oder zu untersagen. Die Lizenz Attribution-Share Alike 2.0 sieht vor, dass jeder Benutzer das Recht hat, das Werk zu kopieren, zu verbreiten und zu verändern. Dabei muss darauf geachtet werden, dass sowohl die vom Autor festgelegte Namensnennung als auch die Weitergabe unter der gleichen Lizenz erfolgt. Mit der letzten Klausel soll verhindert werden, dass Kopien oder Derivate unter proprietärer Lizenz vertrieben werden können. 13 OpenStreetMap-Foundation: Finances. URL: Zugriff am

15 2.3 Datenmodell Entscheidend ist, dass sich die Lizenz nur auf die Daten selbst bezieht. Ein Software, die die Daten verwendet, darf unter proprietärer Lizenz vertrieben werden, solange sie auf die Quelle der Daten verweist und die aus OSM abgeleiteten Daten wieder unter der selben Lizenz verfügbar macht. Darüber hinaus schließt die Lizenz eine kommerzielle Nutzung nicht aus. Ein Anbieter darf durchaus die Daten kommerziell verbreiten, solange er die Namensnennung beachtet und die Daten unter der gleichen Lizenz zur Verfügung stellt. Die Lizenz CC-BY-SA-2.0 birgt aber auch einige Probleme. Deutlich wird dies bereits durch die Namensgebung: Creative Commons richtet sich in erster Linie an kreativ Schaffende und nicht an faktische Datenbankwerke. Nach Ramm/Topf ist nicht eindeutig geklärt, ob sich die Lizenz überhaupt für OpenStreetMap anwenden ließe, da in vielen Ländern faktische Daten nicht schutzwürdig sind 14. Derzeit entwickelt die OpenStreetMap Foundation ein spezielles Lizenzformat, welches sich insbesondere an die Bedürfnisse einer offenen Datenbank richtet Datenmodell Im folgenden wird auf das Datenmodell von OpenStreetMap eingegangen. Insbesondere werden dabei der Aufbau der Daten sowie die Bedeutung der Felder erläutert. Grundlage des Datenmodells ist die DTD-Spezifikation, welche im Anhang auf Seite i zu finden ist. Sollte trotz langer Erprobung ein Fehler im Datenmodell festgestellt werden, weisen die Administratoren darauf hin, dass in diesem Fall die Spezifikation geändert wird und nicht der Server selbst Datenelemente In OpenStreetMap gibt es lediglich drei verschiedene Elemente: Knoten, Wege und Relationen. Jedes dieser Elemente enthält beliebig viele Schlüssel-Wert-Paare zur genaueren Beschreibung der Information (siehe Tags, 2.3.2), sowie weitere Metadaten (2.3.3). 14 Vgl. Ramm, Frederik/Topf, Jochen: OpenStreetMap - Die freie Weltkarte nutzen und mitgestalten. 1. Auflage. Berlin: Lehmanns Media, 2008, Vgl. Collinson, Mike: The OpenStreetMap License. URL: Zugriff am Vgl. Ramm, Frederik et al.: XML Schema. URL: Zugriff am

16 2 Das OpenStreetMap-Projekt (OSM) Knoten Ein Knoten ist in erster Linie ein Punkt auf der Erde, beschrieben durch Breitengrad (Latitude, kurz: lat) und Längengrad (Longitude, kurz: lon). Dieser Punkt kann für sich alleine eine Information darstellen oder zusammen mit weiteren Punkten den Verlauf eines Weges beschreiben. 1 <!ELEMENT node ( tag *)> 2 <!ATTLIST node i d CDATA #REQUIRED> 3 <!ATTLIST node l a t CDATA #REQUIRED> 4 <!ATTLIST node l o n CDATA #REQUIRED> 5 <!ATTLIST node v i s i b l e CDATA #IMPLIED> 6 <!ATTLIST node u s e r CDATA #IMPLIED> 7 <!ATTLIST node timestamp CDATA #IMPLIED> Listing 2.1: Elementdefinition eines Knotens in der DTD Knoten sind die einzigen Elemente, die Geokoordinaten enthalten. Die Koordinaten werden im Dezimalformat in den Grenzen von ±90, 0 (lat) und ±180, 0 (lon) mit maximal sieben Nachkommastellen angegeben. Die Ungenauigkeit liegt bei maximal 63,5 cm 17. Das derzeit für den Privatgebrauch gängige GPS-System enthält hingegen eine Ungenauigkeit von mehreren Metern 18. Aufgrund der mangelnde Präzision des GPS-Systems ist die Ungenauigkeit in der Quantisierung vernachlässigbar. Wege Ein Weg besteht neben den Metadaten und optionalen Tag-Elementen aus ID-Referenzen auf mindestens zwei Knoten (XML-Element nd). Die Reihenfolge der Knoten beschreiben die Richtung des Vektorpfads. Der Begriff Weg ( Way ) ist jedoch irreführend, da dieses Element nicht nur Wege oder Straßen beschreibt, sondern alles, was sich als Linie oder Fläche darstellen lässt. Ein geschlossener Weg (der erste und letzte Knoten haben die gleiche ID) wird dann zu einer Fläche, wenn ein Tag für diesen Weg benutzt wird, welches für Flächen vorgesehen ist. 1 <!ELEMENT way ( tag *, nd, tag *, nd, ( tag nd ) * )> 2 <!ATTLIST way i d CDATA #REQUIRED> 3 <!ATTLIST way v i s i b l e CDATA #IMPLIED> 4 <!ATTLIST way u s e r CDATA #IMPLIED> 17 Bei einem angenommenen Erdradius r = m am Äquator und einem Winkel α = 0, 999E 7 beträgt der Kreisbogen b = 0, m (b = r α) 18 Vgl. Petern König, Holger Bleich: Auf dem GPS-Trip. c t, , S

17 2.3 Datenmodell 5 <!ATTLIST way timestamp CDATA #IMPLIED> 6 7 <!ELEMENT nd EMPTY> 8 <!ATTLIST nd r e f CDATA #REQUIRED> Listing 2.2: Elementdefinition eines Weges in der DTD Relationen Eine Relation beinhaltet in der Regel mehrere Member, welche über die type- und ref - Attribute auf ein anderes Element (Knoten, Weg oder wieder eine Relation) verweisen. Es ist demnach ein Konstrukt zur Zusammenfassung einzelner zueinander in Beziehung stehender Elemente zu einer übergeordneten Menge. Es können z.b. Abschnitte von Stadtteilgrenzen in einer übergeordneten Relation zusammengefasst werden und somit die gesamte Stadtgrenze definieren. Der Grenzabschnitt einer Stadtteilgrenze wird damit gleichzeitig auch zur Stadtgrenze. Dadurch wird vermieden, die gleichen Geokoordinaten für unterschiedliche Informationen redundant abzuspeichern. 1 <!ELEMENT r e l a t i o n ( ( tag member)+)> 2 <!ATTLIST r e l a t i o n id CDATA #REQUIRED> 3 <!ATTLIST r e l a t i o n v i s i b l e CDATA #IMPLIED> 4 <!ATTLIST r e l a t i o n user CDATA #IMPLIED> 5 <!ATTLIST r e l a t i o n timestamp CDATA #IMPLIED> 6 7 <!ELEMENT member EMPTY> 8 <!ATTLIST member type (way node r e l a t i o n ) #REQUIRED> 9 <!ATTLIST member r e f CDATA #REQUIRED> 10 <!ATTLIST member r o l e CDATA #IMPLIED> Listing 2.3: Elementdefinition einer Relation in der DTD Das Attribut role spezifiziert eine Rolle des eingebundenen Elementes in dieser Relation. Ihre Bedeutung kann frei festgelegt werden Tags Ein Tag ist ein Schlüssel-Wert-Paar zur Beschreibung der Information, welche ein Element repräsentiert. Das Attribut k steht für Key und v für Value. 1 <!ELEMENT tag EMPTY> 2 <!ATTLIST t a g k CDATA #REQUIRED> 3 <!ATTLIST t a g v CDATA #REQUIRED> Listing 2.4: Elementdefinition eines Tags in der DTD 11

18 2 Das OpenStreetMap-Projekt (OSM) Jedes Element kann eine beliebig große Anzahl von Tag-Elementen haben. Bestimmte Tags sind nach Map Features nur in Verbindung mit anderen Tags gebräuchlich. So kann ein Tag oneway=yes 19 nur dann sinnvoll für ein Weg-Element gesetzt werden, wenn es auch einen highway=*-tag besitzt. Die Beispieltabelle 2.1 veranschaulicht die Verwendungsmöglichkeiten von Tags: Key Value Bedeutung Anwendbar für highway residential Wohnstraße Wege amenity bank Bank, Geldinstitut Knoten amenity parking Parkplatz Knoten, Flächen landuse cemetry Friedhof Flächen Tabelle 2.1: Auszug der Map Features für Tags 20 OpenStreetMap legt sehr viel Wert darauf, den Benutzern nicht vorzuschreiben, auf welche Art und Weise sie ihre Daten einzupflegen haben. So kann ein Benutzer eine Straße beispielsweise als Straße=Autobahn definieren. Jedoch hat dieser keinen Vorteil davon, da höchstwahrscheinlich kein Renderer seine Straße als solche, geschweige denn als Autobahn erkennen wird und somit auch nicht auf einer Karte anzeigen wird. Im OSM-Wiki gibt es die Seite Map Features 21, welche ein Übereinkommen für die meisten Tags auflistet. Auch wenn diese Seite keine Vorschrift darstellt, wird jedem Mapper empfohlen, sich möglichst nach dieser zu richten, um eine bestmögliche Verwendung seiner Daten zu garantieren Metadaten ID Jedes Element besitzt eine ID. Diese ist jedoch nicht global eindeutig, sondern nur innerhalb ihres Elementtyps. Das bedeutet, dass zwei Elemente unterschiedlichen Typs die gleiche ID haben können. Alle Elemente des gleichen Datentyps haben eindeutige IDs. Bei einer Referenzierung über eine ID muss zusätzlich geklärt sein, um welchen Elementtyp es sich handelt. Bei der Referenzierung von Wegknoten kann nur die ID eines Knoten angegeben werden. Bei den Member-Referenzen wird über das Attribut type festgelegt, auf welchen Elementtyp sich die Referenz bezieht. 19 Zur besseren Lesbarkeit werden Tag-Elemente in der Form key=value angegeben. 20 Auszug aus: o.v.: Map Features. URL: Zugriff am Features 12

19 2.3 Datenmodell Die IDs werden bei der Erzeugung vom API-Server vergeben und dort verwaltet 22. Der Benutzer hat erst dann die Möglichkeit, die zukünftige ID zu bestimmen, nachdem das Element auf dem Server erzeugt wurde. Timestamp Das Attribut Timestamp beschreibt den Zeitpunkt der letzten Änderung des Elements. Es hat das Format YYYY-MM-DDTHH:MM:SSohh:mm 23. Die Veränderung eines referenzierten Elementes wirkt sich nicht auf den Zeitstempel des referenzierenden Elementes aus. Dies tritt nur bei Veränderungen in der Referenzliste oder der Tag-Liste selbst ein. Zeitgebend ist die Übertragung auf den OSM-Server, nicht die Erstellung in einem Editor. Username Jeder Mapper muss sich mit einem Benutzernamen und Passwort beim Server authentifizieren, um Daten bearbeiten zu können. In jedem Element wird der Name des Benutzers der letzten Änderung festgehalten. Die Anmeldung ist kostenlos und für jeden verfügbar 24. Visible Visible ist ein Binärattribut, welches die Werte true oder false annehmen kann. Ausschließlich gelöschte Elemente, welche über die History der API abgefragt werden können, besitzen den Wert false Aufbau einer OSM-XML-Datei Der Austausch von Daten erfolgt über die in Teilen schon diskutierte DTD. Sie enthält noch weitere Felder, die für den Empfänger von Bedeutung sein können, aber für die Datenstruktur nicht direkt relevant sind: Osm und Bounds. 22 Siehe Kap , Create 23 YYYY::=vierstellige Jahreszahl MM::=zweistellige Monatzzahl im Jahr DD::=zweistellige Tageszahl im Monat HH::=zweistellige Stunde im 24h-Format MM::=zweistellige Minute SS::=zweistellige Sekunde o::= + - (Richtung der Zeitverschiebung) hh::=zweistellige Stunde der Zeitverschiebung im 24h-Format mm=zweistellige Minute der Zeitverschiebung

20 2 Das OpenStreetMap-Projekt (OSM) Osm Das Wurzelelement Osm beinhaltet ein optionales Bounds-Element, sowie eine Liste von allen Knoten, Wege und Relationen. Das Attribut version steht für die API- Version (siehe Auswahl der API-Version, 2.4.2). Generator bezeichnet das Programm, welches die XML-Datei erzeugt hat. Dieses Attribut wird beim Transfer zum Server gespeichert und ist nicht über die API zugänglich. Sie dient dazu, fehlerhafte Eingaben von defekten Editoren besser identifizieren zu können. 1 <!ELEMENT osm ( node r e l a t i o n way)*> 2 <!ATTLIST osm version ( 0. 5 ) #REQUIRED> 3 <!ATTLIST osm g e n e r a t o r CDATA #REQUIRED> Listing 2.5: Definition des Wurzelelements in der DTD Bounds Obwohl das Bounds-Element nicht in der DTD erwähnt wird, schreibt der Server ein solches Element in die XML-Datei. 1 <bounds minlat= minlon= maxlat= maxlon= /> Listing 2.6: Beispiel eines Bounds-Elements Wie die Bezeichner der Attribute schon andeuten, werden dadurch die äußeren Grenzen eines Bereichs festgelegt. Das ist notwendig, da ein Weg samt der referenzierten Knoten aus diesem Bereich herausragen kann. Liegt ein Knoten außerhalb von Bounds, kann er von anderen Wegen referenziert werden, die sich nicht in Bounds befinden (Abbildung 2.3). Das verarbeitende Programm muss also darauf achten, dass die Knoten außerhalb des Bereichs nicht verändert werden, da es sonst unbeabsichtigte Folgen für andere referenzierende Elemente haben kann. 2.4 Programmierschnittstelle ( API ) Eine API ( application programming interface ) ist eine Programmierschnittstelle, die es einem Entwickler ermöglicht, Funktionalitäten einer fremden Software oder eines Dienstes für sein Programm zu nutzen. OpenStreetMap stellt eine ständig weiterentwickelte API zur Verfügung, mit deren Hilfe jedes Programm mittels HTTP-Befehle und Austausch von OSM-XML-Datein aktuelle Daten in die Datenbank speichern lassen kann oder aktuelle wie archivierte Daten herauslesen kann. 14

21 2.4 Programmierschnittstelle ( API ) Geladener Way Bounds-Fläche Äußere Fläche Nicht-geladener Way / Nodes Abbildung 2.3: Knoten außerhalb der Bounds-Fläche RESTful Design REST (Representational State Transfer) beschreibt einen Architekturstil für Internetdienste. Es verfolgt ein striktes Client-Server-Modell, in dem der Client über eine URL eine Ressource anspricht und über HTTP-Befehle beschreibt, was mit dieser Ressource getan werden soll. REST ist wie HTTP zustandslos, so dass jede Transaktion in sich verstanden werden kann und nicht von vorherigen Zuständen abhängig ist API 0.5 Die Version 0.5 ist die derzeit 25 aktuelle API-Version von OpenStreetMap. Die Tabelle 2.2 listet die vier möglichen CRUD-Operationen (Create, Retrieve, Update, Delete) auf: CRUD HTTP-Befehl Ressourcenpfad Create PUT /api/0.5/{elementtyp}/create Retrieve GET /api/0.5/{elementtyp}/{id} /api/0.5/map?bbox={minlon},{minlat},{maxlon},{maxlat} Update PUT /api/0.5/{elementtyp}/{id} Delete DELETE /api/0.5/{elementtyp}/{id} Tabelle 2.2: HTTP-Befehle und Ressourcenpfade für API Oktober 2007 März Vgl. Ramm, Frederik/Topf, Jochen: OpenStreetMap - Die freie Weltkarte nutzen und mitgestalten. 1. Auflage. Berlin: Lehmanns Media, 2008, S. 176f 15

22 2 Das OpenStreetMap-Projekt (OSM) Create erzeugt über den Ressourcenpfad ein neues Element. Die Definition erfolgt als Payload von HTTP-PUT in Form einer validen XML-Datei. Als Antwort sendet der Server die generierte ID für das erzeugte Element. Retrieve holt entweder ein bestimmtes Element über die ID, oder alle Elemente innerhalb eines Kartenausschnittes 27. Eine Payload wird vom Client nicht benötigt. Die Antwort des Servers enthält eine XML-Datei mit den angefragten Daten. Update aktualisiert ein bestimmtes Element. Diese muss als Payload mit angegeben werden. Außer eines positiven Statuscodes gibt der Server nichts zurück. Delete löscht das im Resourcenpfad angegebene Element. Sowohl der Client als auch der Server brauchen keine Payload zu versenden. Authentifizierung Die Authentifizierung erfolgt über die Basic-Authentification, welche in HTTP spezifiziert sind 28. Zwar erfolgt eine Kodierung über Base64, die aber keine Verschlüsselung darstellt. Die Kodierung ist injektiv, was einer Übermittlung der Daten in Klartext entspricht. HTTP-Status-Codes Wird eine Anfrage erfolgreich vom Server bearbeitet, gibt dieser eine HTTP 200 (OK) Meldung zurück. Sollte ein Problem bei der Verarbeitung aufgetreten sein, sind folgende Statusmeldungen definiert: OSM-Binary API Derzeit ist das OSM Binary Protocol in der Entwicklung. Es hat das Ziel, die Datengröße zu reduzieren und durch Vermeidung des Klartext-Parsens die Verarbeitung zu beschleunigen. Dies wird dadurch erreicht, dass Zahlenwerte direkt in einem Binärformat abgelegt sind und ggf. häufig auftretende Tags durch Enumerationen ersetzt werden. Auch die Struktur selbst wird nicht mehr über variable XML-Konstrukte beschrieben, sondern direkt festgelegt. 27 Darüber hinaus gibt es eine Reihe weiterer, spezieller Anfrage-Methoden, die für diese Arbeit jedoch nicht von Relevanz sind. Siehe: Protocol Version Siehe Franks, J. et al.: HTTP Authentication: Basic and Digest Access Authentication. Juni 1999 URL: 16

23 2.4 Programmierschnittstelle ( API ) Status-Code Bedeutung 400 Bad Request Die Payload entspricht nicht der Anfrage. Dies passiert beispielsweise, wenn in einer Update-Operation sich die ID in der XML-Datei von der ID im Ressourcenpfad unterscheidet. 401 Unauthorized Eine manipulative Operation wurde ohne (gültige) Authentifizierung versucht 404 Not found Das angefragte Element existiert nicht und hat noch nie existiert. 405 Method not Der Ressourcenpfad für Create wurde angegeben, aber kein allowed HTTP-PUT Befehl. 410 Gone Das angefragte Element existierte, wurde aber mittlerweile gelöscht. 412 Precondition failed Die Operation würde die referentielle Intigrität zerstören. Beispiel: Ein Element soll gelöscht werden, wird aber noch von anderen Elementen referenziert. Dieser Status wird auch zurückgegeben, wenn eine Create-Operation mit einer positiven ID innerhalb der XML-Daten ausgeführt werden soll. 500 Internal Ein interner Fehler ist aufgetreten. Server Error 503 Service Die Datenbank ist aus Wartungsgründen nicht verfügbar. Unavailable Tabelle 2.3: HTTP Status-Codes der API Ein Vergleich des OSM-Binary Protocols mit der Standard-API bezüglich der erreichten Kompression für einen Beispielbereich ist in Tabelle 2.4 zu finden. Die Kompressionen gz und 7z beziehen sich auf eine Kompression bereits im HTTP- Datenstrom. Protokoll Größe Kompressionsfaktor zusätzlich OSM XML API OSM XML gz % OSM XML 7z % Binary API % Binary API gz % 35% Binary API 7z % 20% Tabelle 2.4: Vergleich verschiedener OSM-Protokolle Übersetzt aus: o.v.: Basic Methods for Object Access and Manipulation. URL: Basic_Methods_for_Object_Access_and_Manipulation Zugriff am o.v.: OSM Mobile Binary Protocol. URL: http: //wiki.openstreetmap.org/index.php?title=osm_mobile_binary_protocol&oldid= Zugriff am

24 2 Das OpenStreetMap-Projekt (OSM) Diese Formate sind allerdings nach Angaben der Entwickler ausschließlich für den Lesezugriff gedacht und eignen sich nicht für einen Editor. Sollte ein Editor diese Binärdaten interpretieren und anschließend über das Standard-XML-Format wieder an eine weitere Instanz weitergeben, so können leicht durch unterschiedliche Bezugsquellen der Daten sowie durch Formatierungsfehler Inkonsistenzen auftreten. Da es sich bei dem OSM-Binary Protocol um Read-Only Protokoll handelt also keine Daten auf dem Server manipuliert werden entspricht es nicht den REST- Kriterien. 18

25 3 Die Android-Plattform Android ist eine Plattform des Konsortiums Open Handset Alliance, zu der 47 Mitglieder als Mobilfunkprovider, Software- und Vermarktungsfirmen, sowie Halbleiter- und Gerätehersteller angehören. Das Ziel dieses Zusammenschlusses namhafter Firmen wie Google, HTC, Intel oder Telefónica ist, nach eigenen Angaben, offene Standards für mobile Endgeräte zu entwickeln 1. Android wurde von Google entwickelt, das im November 2007 eine erste Testversion des SDK (Software Development Kit) veröffentlicht hat. Im September 2008 erschien das erste SDK, welches zur späteren 1.0-Version kompatibel ist. Mit dem Verkaufsstart des ersten Endgeräts T-Mobile G1 (Hersteller: HTC) in den USA wurden die Quellen von Android offengelegt 2 und unter der freien Apache-Lizenz veröffentlicht. Seitdem hat jeder die Möglichkeit, die Quelltexte zu studieren, zu vervielfältigen, zu verändern und wieder einzupflegen. 3.1 Architektur Die Android-Plattform lässt sich in vier verschiedene Ebenen aufteilen (Tabelle 3.1). Als Grundlage des Systems liegt ein Linux Kernel (Version 2.6), welcher alle nötigen Hardware-Treiber beinhaltet. Darauf setzen diverse Bibliotheken auf sowie die Android-Laufzeitumgebung. Diese beiden unteren Schichten sind komplett in C/C++ implementiert, so dass eine effiziente Verarbeitung gewährleistet ist. Die darüber liegenden Schichten sind in Java implementiert und werden durch die Dalvik VM interpretiert. Auf der dritten Ebene ist das Framework eingebettet, welche die erste für den Entwickler sichtbare Schicht darstellt: Die Schnittstellen und Methoden dieser Schicht kann der Programmierer direkt verwenden. Alle Anwendungen sind in der obersten Schicht repräsentiert. Wie bereits erwähnt unterscheidet das System nicht zwischen Android-Anwendungen und solchen von Drit- 1 OpenHandsetAlliance: Industry Leaders Announce Open Platform for Mobile Devices. URL: Zugriff am

26 3 Die Android-Plattform Applications Home Contacts Phone... Applikation Framework Activity Manager Window Manager Content Providers View System Package Manger Telephony Manger Resource Manager Location Manager Notification Manager Libraries Android Runtime Surface Manager Media Framework SQLite Core Libraries OpenGL/ES FreeType WebKit Dalvik VM SGL SSL libc Linux Kernel Display Driver Camera Driver Flash Memory Driver Binder (IPC) Driver Keypad Driver WiFi Driver Audio Drivers Power Management Tabelle 3.1: Die Android-Architektur 3 tanbietern. So kann der Benutzer neue Programme installieren und vorhandene ersetzen. Die Dalvik Virtual Machine (Dalvik VM) wurde von Google selbst entwickelt und ist im Gegensatz zu Sun s Java Virtual Machine eine Registermaschine, so dass die Dalvik VM einen effizienteren Zugriff auf die Speicheradressen liefert. Ein weiterer Vorteil dieser Vorgehensweise ist, dass die Hersteller keine Lizenzabgaben an Sun richten müssen. Der Nachteil besteht jedoch darin, dass normale Java-Kompilate nicht auf der Dalvik VM ausführbar sind, und umgekehrt. Eine Plattformunabhängigkeit ist somit nicht mehr gegeben. 3.2 Modell-View-Controller (MVC)-Muster MVC ist ein Architekturmuster in der Softwareentwicklung. Es sieht vor, die verschiedenen Schichten Modell, Präsentation und Steuerung von einander zu kapseln. Das Modell repräsentiert die Datenhaltung und deren Struktur. Die Präsentation stellt die Oberfläche dar und definiert deren Aussehen. Die Steuerung steht für die Logik einer Software und ist dafür verantwortlich, die Daten aus dem Modell in angebrachter Weise der Präsentation zur Verfügung zu stellen und Benutzereingaben aus der Präsentation wieder an das Modell weiterzugeben. 3 Google, Inc.: System Architecture. URL: Zugriff am

27 3.2 Modell-View-Controller (MVC)-Muster Vorteile Folgende Vorteile ergeben sich aus diesem Muster: Lesbarkeit Textausgaben oder Datenbankabfragen gehören nach dem MVC-Modell nicht in die Steuerung, sondern in die Präsentation beziehungsweise in das Modell. Dadurch wird eine bessere Lesbarkeit des Codes erreicht, da dieser nur noch für die Logik verantwortlich ist. Wartbarkeit Durch die Trennung der drei Schichten ist es möglich, einfacher auf die gewünschten Ressourcen zuzugreifen und sie unabhängig von den anderen Schichten zu aktualisieren. Wiederverwendbarkeit Die Daten und Oberflächenrepräsentation sind unabhängig vom Logik-Programmcode. Dadurch lässt sich jede dieser Schichten in anderen Projekten wieder verwenden, ohne dass programmspezifische Bindungen beachtet werden müssen. Arbeitsteilung Ein weiterer Vorteil besteht darin, dass beispielsweise UI-Entwickler die Oberfläche gestalten können, ohne die Logik des Programms vorliegen oder verstanden zu haben. Internationalisierung Da Texte nun nicht mehr direkt im Quellcode eingebunden sind, können diese leicht ausgetauscht werden, um das Programm für andere Sprachen zu veröffentlichen. Umgebungsabhängige Layouts Es können verschieden Layouts für diverse Umgebungen und Endgeräte entworfen werden. Das Programm ist somit nicht mehr an eine bestimmte Umgebung gebunden Modell: XML Folgende Datentypen können in XML-Dateien ( Ressourcen ) gespeichert werden und sind somit unabhängig vom Code: ˆ Einfache Werte Farben (RGB(A)-Werte) Arrays (Integer und Strings) Dimensionen (px, in, pt, mm, dp, sp) Strings Styles (Android-Styles für Oberflächen) ˆ Bilder (PNG, JPG, GIF) ˆ Layouts (Android-Layouts) 21

28 3 Die Android-Plattform ˆ Animationen (Über XML definierte Animationen) ˆ Andere Dateien XML-Dateien (fremd-spezifizierte XML-Daten) Raw-Dateien (Binärdaten) Diese Ressourcen werden als XML-Dateien in einer vorgegebenen Ordnerstruktur abgelegt und bereits zur Compilezeit eingelesen. Dabei legt ein Compiler die Daten in einem Binärformat ab. Dieser erzeugt eine R-Klasse 4, welche wiederum für jeden Datentyp eine Subklasse mit Referenz-IDs für die Ressourcen bereitstellt. Diese IDs zeigen nicht auf die Ressource selbst, sondern auf einen Eintrag in der von Android verwaltete Ressourcen-Tabelle. Mit Hilfe der R-Klasse kann der Entwickler bereits zur Compilezeit die Adressierung der Ressource validieren. Listing 3.1 zeigt eine Beispielhafte Ressource für Strings: 1 <?xml version= 1. 0 encoding= utf 8?> 2 <r e s o u r c e s> 3 <s t r i n g name= h e l l o >Hello, Android!</ s t r i n g> 4 </ r e s o u r c e s> Listing 3.1: Beispiel-Ressource /res/values/strings.xml In der R-Klasse wird automatisch folgender Eintrag erzeugt: 1 public static f i n a l class s t r i n g { 2 public static f i n a l int h e l l o =0x7f ; 3 } Listing 3.2: Eintrag in R-Klasse Diese ID kann in vielen von Android bereitgestellten Methoden direkt als Parameter übergeben werden, oder selbst ausgelesen werden: 1 S t r i n g h e l l o = g e t S t r i n g (R. s t r i n g. h e l l o ) ; Listing 3.3: Benutzung der Ressource Da die Ressourcen bereits zur Compilezeit geparst werden und in ein internes, optimiertes Format abgelegt werden, erfolgt der Zugriff auf die Werte bedeutend schneller, als wenn dies erst zur Laufzeit geschehen würde. Ausgenommen davon sind Raw- und XML-Dateien, welche überhaupt nicht vorbearbeitet werden. In der aktuelle SDK- Version sind alle Ressourcen-Dateien auf eine Größe von 1 MByte beschränkt. 4 Pfad: /src/r.java 22

29 3.3 Interprozesskommunikation durch Intents View: Views Alle UI-Komponenten sind von der View-Klasse abgeleitet. Android stellt eine Reihe von vorgefertigten Komponenten bereit, die der Entwickler über Java-Klassen als auch über XML-Ressourcen benutzen und anpassen kann. Nach Möglichkeit sollte dieser Weg gewählt werden, da hierdurch eine weitestgehende Trennung von Benutzeroberfläche und Programmcode sichergestellt wird und die Komponenten vorkompiliert sind Controller: Java-Klassen Die restlichen Java-Klassen sollten nach Beachtung der vorherigen Kapitel auschließlich die Logik sowie die Kontrolle des Datenfluß beinhalten. Dadurch wird das MVC- Muster vollständig umgesetzt. 3.3 Interprozesskommunikation durch Intents Nach Meier sind Programme auf anderen Smartphone-Plattformen voneinander entkoppelt und können aufgrund von Sicherheitsrestriktionen nicht miteinander kommunizieren 5. Bei Android hingegen wird sehr viel Wert auf Wiederverwendbarkeit gelegt. Programme können durch sogenannte Intents 6 miteinander kommunizieren und Funktionalitäten für andere Applikationen bereitstellen. Selbst das Starten von Activities wird durch Intents umgesetzt. Dieses Vorhaben kann an eine bestimmte Klasse gerichtet werden (explizites Vorhaben), oder allgemein formuliert (implizites Vorhaben). Bei Letzterem wird anstatt eines konkreten Klassennamens eine abstrakte Handlung angefragt (z.b. ACTION DIAL) und Android entscheidet aufgrund der Benutzerpräferenz, an welches Programm das Intent geleitet wird. Der Entwickler braucht sich nicht darum zu kümmern, welche Telefonapplikation der Benutzer installiert und als Standard definiert hat. Für ihn ist in diesem Beispiel nur wichtig, dass die Handlung wähle ausgeführt wird. Über die Aufforderungen hinaus können auch Daten mitgesendet werden. Mit Hilfe von Bundles können die Programme Daten senden und empfangen. 5 Vgl. Meier, Reto: Professional Android Application Development. 1. Auflage. Indianapolis, USA: Wiley Publishing, 2009, S. 113f. 6 Intent = Intention, Vorhaben 23

30 3 Die Android-Plattform 3.4 Applikationslebenszyklus Eine Besonderheit der Android-Plattform ist der Lebenszyklus von Applikationen. Bei Desktop-Betriebssystem oder auch anderen Handset-Plattformen entscheidet der Benutzer darüber, wann ein Programm geschlossen oder wieder geöffnet wird. Sollte zu einem bestimmten Zeitpunkt der Arbeitsspeicher des Gerätes gefüllt sein, werden vom Betriebssystem nicht mehr gebrauchte Speichersegmente in einen Auslagerungsspeicher gelegt. Dies macht sich für den Benutzer in einer verringerten Geschwindigkeit der Programme bemerkbar und er muss ggf. unnötige Programme schließen. Im bisher einzigen Endgerät T-Mobile G1 stehen 96 MByte Arbeitsspeicher zur Verfügung, wovon ca. 80 MByte für das Betriebssystem benötigt wird und 16 MByte für Benutzerprogramme 7. Bei Android gibt es keinen Auslagerungsspeicher. Es übernimmt selbst die Kontrolle über die Laufzeit der installierten Programme. Dabei werden die Programme und deren Fenster (Activities) in einer Warteschlange verwaltet, so dass immer so viele Fenster geöffnet sind, wieviel Speicher zur Verfügung steht. Fenster, welche zuerst geöffnet wurden, werden wieder als erstes zerstört. Dadurch kann der Benutzer über den Zurück-Knopf auf seinem Gerät ohne Verzögerung zur letzten Applikation wechseln. Da kein Vorwärts-Knopf vorgesehen ist, wird die nun verlassende Applikation sofort zerstört. Die Applikation, die als letzte in der Warteschlange aktiver Fenster stand und zerstört wurde, wird wieder hergestellt. Für jeden Status, in das ein Fenster vom System gesetzt werden kann, gibt es eine standardisierte Schnittstellenmethode, die der Entwickler implementieren kann. Somit liegt bei ihm die Verantwortung, auf den Statuswechsel angemessen zu reagieren (Abbildung 3.1). 3.5 Automatisiertes Testen Mit dem Erfolg der agilen Softwareentwicklungsmethoden bekam nach Benninger auch das sogenannte Test Driven Development immer mehr an Bedeutung 9. Kurz zusammengefasst besagt diese Methode, dass die Software durch Tests spezifiziert wird. Der Entwickler schreibt als erstes einen Test, der das gewünschte Verhalten der Softwa- 7 Vgl. Guy, Romain: Avoiding Memory Leaks. URL: Zugriff am Entnommen aus: Google, Inc.: Activity Lifecycle. URL: Zugriff am Vgl. Benninger, Lukas: Agile Software Development. Februar 2003 URL: S

31 3.5 Automatisiertes Testen Abbildung 3.1: Activity Lifecycle 8 re spezifiziert, bevor er mit der Implementierung anfängt. Durch den Einsatz von funktionalen Tests ist sichergestellt, dass die Spezifikationen in jeder Stufe der Weiterentwicklung eingehalten wird Standardmöglichkeiten von Google Trotz der in den letzten Jahren immer wichtiger gewordenen Methode stellt Google bisher nur unzureichende Werkzeuge für funktionales Testing mit Android bereit. Zwar gibt es im SDK eigene Pakete für JUnit-Tests, sie sind jedoch kaum implementiert oder gar dokumentiert. Das führt dazu, dass diese Pakete bisher nicht ausreichend zu benutzen sind. Zwar ist es möglich, die Tests auf dem PC auszuführen, doch wird dann das lokale (Sun-) JDK benutzt, da das Android-SDK nur auf der Android-Plattform lauffähig 25

32 3 Die Android-Plattform ist. Dies führt dazu, dass im getesteten Code sowie im Testcode selbst keine Androidspezifischen Klassen verwendet werden können. Jeder Code, der nicht ausschließlich aus den Standard-Klassen des JDK besteht, bleibt also ungetestet 10. Darüber hinaus entspricht die Umgebung nicht dem eigentlichen Zielgerät, was unter Umständen zu unterschiedlichen Ergebnissen führen kann Automatisierte Tests mit Positron Positron 11 ist ein Teil des AutoAndroid-Projekts, das nicht von Google selbst initiert wurde. Es hat das Ziel, das automatisierte Testen und Erzeugen von Programmen auf Android zu ermöglichen. Positron ist im wesentlichen als Server-Client-Struktur aufgebaut. Der Server wird mit Hilfe der android.app.instrumentation-klasse vor Ausführung des Programmcodes instanziert, so dass dieser die Kontrolle über die Applikation übernehmen kann. Die Kommunikation mit dem Client auf dem Desktop-PC läuft über die ADB (Android Debugging Bridge), die im SDK enthalten ist. Der Client kann damit Befehle an den Server senden, der mit Statusmeldungen antwortet. Dadurch wird der JUnit-Test auf dem PC gesteuert, aber letztendlich auf dem Gerät ausgeführt. Durch die PositronAPI kann der Entwickler in den Tests beliebige Eingaben auf der Oberfläche ausführen und den Status abfragen. Dadurch legt der Entwickler im vorhinein das Verhalten der Software fest Automatisierte Erzeugung mit AndroidAnt Sobald eine Software nicht mehr durch einen einzelnen Entwickler, sondern im Team gefertigt wird, empfiehlt sich der Einsatz von Build-Servern. Dies hat den Vorteil, dass dort eine festgelegte Umgebung installiert ist, die unabhängig von den lokalen Workstations der Programmierer ist. In der Java-Welt hat sich Apache Ant als das Standard-Werkzeug zur automatischen Erzeugung ( Build ) entwickelt. Mittels Ant lassen sich über XML-Dateien verschiedene Zielprogramme ( Targets ) definieren. Ant übernimmt die Auflösung von Abhängigkeiten und Bibliotheken und veranlasst die Kompilation mit entsprechenden Parametern. 10 Siehe Google, Inc.: I can t run a JUnit test class in Eclipse/ADT. URL: Zugriff am

33 3.5 Automatisiertes Testen AndroidAnt ist eine AntLib für Ant, die die Erzeugung über den Dalvik Crosscompiler ausführt und den Android-Emulator steuern kann. Leider ist nach eigenen Angaben diese Funktionalität noch nicht ausgereift und instabil Smith, Phil: AndroidAnt - Build your Android application with ant.. without exec. URL: Zugriff am

34

35 4 Geodateneditor Vespucci Ziel dieser Arbeit ist die Entwicklung eines Geodateneditors für das OpenStreetMap- Projekt auf der Android-Plattform. In diesem Kapitel wird das Ergebnis vorgestellt und erläutert. Zuerst werden anhand einer Benutzeranalyse eine Zielgruppe definiert und daraus die benötigten Anforderungen abgeleitet. Im Unterkapitel 4.2 ist das grobe Entwurfskonzept mit besonderer Aufmerksamkeit auf die Datenstruktur erläutert. Anschließend wird die Implementation vorgestellt, die den Hauptteil dieser Arbeit ausmacht. Zum Schluss wird im Unterkapitel 4.4 darauf eingegangen, welches Potential in Vespucci steckt, um darauf aufbauend im Kapitel 5 Zusammenfassung sowie einen Ausblick für das Programm zu geben. 4.1 Analyse Bevor ein Konzept für Vespucci erstellt werden kann, ist eine Analyse der Rahmenbedingungen erforderlich. Zuerst wird in diesem Kapitel die Zielgruppe festgelegt und kurz auf die technischen Rahmenbedingungen eingegangen. Aus diesen beiden Punkten lassen sich im Abschnitt die Anforderungen an das Endprodukt erstellen Zielgruppendefinition Zielgruppe sind Gelegenheitsmapper, die in unregelmäßigen Abständen Orte oder neue Wege in ihrer Umgebung eintragen wollen. Der Benutzer braucht dafür in der Regel nur einen kleinen Kartenausschnitt, denn er wird sich voraussichtlich nur zu Fuß oder mit dem Fahrrad fortbewegen. Darüber hinaus ist das Programm interessant für professionelle Mapper, denen unterwegs nicht-verzeichnete Objekte auffallen und diese umgehend in OSM eintragen möchten, ohne sich ein weiteres Mal samt Ausrüstung auf den Weg zu machen. Der Anwender sollte sich durchaus vorher mit OSM vertraut gemacht haben und die Zusammenhänge von Knoten, Wege und Tags zu kennen. Es ist für ihn von Vorteil, wenn er die wichtigsten und gängigen Tags auswendig kennt. Dieses Wissen ist jedoch mit ein wenig Übung schnell eingeprägt. 29

36 4 Geodateneditor Vespucci Darüber hinaus ist ein Smartphone aufgrund der geringen Bildschirm- und Tastengröße für Menschen mit Sehschwächen und mangelnder Feinmotorik ungeeignet. Fortgeschrittene Projektmitglieder, die komplexe oder überregionale Strukturen bearbeiten wollen, gehören nicht zur Zielgruppe Technische Rahmenbedingungen Da Android in erster Linie für Smartphones entwickelt wird, ist auch die Software an die Begrenzungen der Hardware gebunden. Zwar steigt die Leistungsfähigkeit dieser Geräte zunehmend an, doch sind sie auch zukünftig aufgrund ihrer geringen Größe nicht einem vollwertigen Computer gleichzustellen. Beispiele hierfür sind unter anderem die Ausmaße von Displays und Eingabeschnittstellen (Tastatur, Touchpad, Trackball, etc.). Ziel ist es daher, dass sich dem Mapper die wichtigsten Funktionalitäten sofort erschließen und er diese einfach bedienen kann. Ziel ist es jedoch nicht, dem Benutzer eine ansprechende Kartendarstellung oder gar Routingmöglichkeiten zu geben Anforderungen Einfache Bedienbarkeit Wie bereits im vorherigem Abschnitt erwähnt, ist eine leichte, intuitive Bedienung aufgrund der geringen Ausmaße des Handgerätes unerlässlich. Der Benutzer soll sich schnell in die Benutzung einfinden können, ohne Anleitungen zu lesen oder unbeabsichtigte Fehleingaben revidieren zu müssen. Funktionsumfang Auswahl des zu bearbeitenden Ausschnittes Der Benutzer soll auswählen können, welchen Teil einer Karte er bearbeiten möchte. Ihm wird angeboten, bisherige Daten für diesen Ausschnitt vom OSM-Server zu laden. Die Auswahl kann über manuell eingegebene Koordinaten oder über seine aktuelle Position erfolgen. Da hier eine präzise Angabe bei der Positionsbestimmung nicht erforderlich ist und die Ermittlung über GPS unter Umständen 15 Minuten dauern kann 1, können die Daten sowohl über die Mobilfunkzellen-ID 2, als auch über GPS benutzt werden können. Sobald eine präzisere Positionsangabe verfügbar ist, soll diese eingesetzt werden. 1 Ramm, Frederik/Topf, Jochen: OpenStreetMap - Die freie Weltkarte nutzen und mitgestalten. 1. Auflage. Berlin: Lehmanns Media, 2008, Seite Google kann aufgrund der Mobilfunkzellen-ID und die Distanz zum Sendemasten eine ungefähre Position bestimmen. Die Daten sind innerhalb weniger Sekunden verfügbar 30

37 4.1 Analyse Anzeige der Daten Hat der Benutzer einen Bereich mit OSM-Daten geladen, so sollen ihm die Geodaten maßstabsgetreu angezeigt werden. Darüber hinaus muss es für den Mapper erkennbar sein, wie groß sein aktuell gültiger Bereich ist 3. Move-Modus Der Benutzer soll den sichtbaren Kartenbereich verschieben können. Aufgrund besserer Handhabung soll dies nicht nur über den Touchscreen, sondern auch über Hardwaretasten möglich sein. Eine Möglichkeit zur Vergrößerung/Verkleinerung des Ausschnittes soll über eigene Tasten verfügbar sein. Edit-Modus Vorhandene Knoten auf der Karte sollen verschoben werden können. Wird ein Knoten an den Bildschirmrand verschoben, so soll sich der Kartenausschnit in diese Richtung mitbewegen. Delete-Modus Der Mapper soll vorhandene Knoten löschen können. Wenn ein Weg zu diesem Knoten gehört hat, soll der Weg automatisch gelöscht werden, wenn dieser Weg nur noch einen weiteren Knoten referenziert. Create-Modus In diesem Modus können neue Elemente erstellt werden. Durch erstes Klicken des Touchscreens wird ein Knoten erstellt. Erfolgt der zweite Klick auf den gleichen Punkt, so ist die Erstellung für diesen Punkt abgeschlossen und das nächste Element kann angefertigt werden. Klickt der Benutzer jedoch als zweites auf eine andere Fläche des Bildschirms, so wird dort ein weitere Knoten erstellt, die mit einem neuen Weg verbunden sind. Dies wird solange fortgesetzt, bis der Benutzer den letzten Knoten ein weiteres mal anklickt. Wird ein vorhandener Knoten ausgewählt, wird dieser benutzt, anstatt dass ein neuer Knoten darüber erstellt wird. Wird auf ein Weg-Segment geklickt, so wird an dieser Stelle ein neuer Knoten eingefügt und in dem darunterliegenden Weg zwischen den beiden bisherigen Knoten eingebunden. Append-Modus Hat der Benutzer im Append-Modus den ersten oder letzten Knoten eines Wege ausgewählt, so werden die anschließend erstellten Weg-Segmente dem Weg angehängt, anstatt einen neuen Weg zu erstellen. Führt der Benutzer eine Bewegung über den Touchscreen aus, anstatt ihn anzuklicken, so wird diese Bewegung als Verschiebung des Kartenausschnitts interpretiert. Die Modi sind sowohl über ein Programmmenü, als auch über Tastenkürzel erreichbar. In allen Modi werden auswählbare Elemente mit einem Toleranzbereich angezeigt, der die Berührungstoleranz anzeigt. Dies ist erforderlich, da die Auswahl von Bildschirmelementen mittels Fingerdruck für den Anwender unpräziser zu setzen ist, als beispielsweise ein Mausklick am Desktop-PC. 3 siehe Kapitel Bounds, Seite 14 31

38 4 Geodateneditor Vespucci TagEdit-Modus Der Benutzer kann über diesen Modus ein Element selektieren. Anschließend öffnet sich ein Editor zur Manipulation der Tags. Bisherige Tags werden angezeigt und er kann diese löschen, verändern oder beliebig viele neue Schlüssel- Wert-Paare hinzufügen. Durch den Zurück-Knopf seines Gerätes bestätigt der Anwender die Angaben und gelangt zurück zur Kartenansicht. Leere Felder im Formular werden ignoriert. Die Liste von Eingabefeldern für Schlüssel-Wert-Paare erweitert sich bei Bedarf automatisch. Anzeige des GPS-Track Dem Benutzer wird sein aktueller GPS-Pfad auf dem Display angezeigt, so dass er abgelaufene Wege mittels Create-Modus direkt nachzeichnen oder einen Knoten an seiner aktuellen Position eintragen kann. Der Mapper soll die Möglichkeit haben, diesen GPS-Track auch abschalten zu können. Bewegt sich der Benutzer in eine Richtung, wird der Kartenausschnitt auf seine neue Position verschoben. Datentransfer vom und zum Server Der Anwender muss den aktuellen Kartenausschnitt vom OSM-Server neu laden oder erstellte Änderungen auf den Server laden können. Konfigurationsmöglichkeiten Im Konfigurationsfenster kann der Anwender seine OSM-Server Login-Daten eintragen und GPS-Abfrage-Intervalle festlegen. Zusätzlich stehen dort folgende Optionen zur Verfügung: Anzeige von Statistiken in der Kartenansicht, Anzeige der Toleranzen sowie das Abschalten von AntiAliasing zur Beschleunigung der Darstellung. Verständlichkeit des Quellcodes Zwar stehen in einem mobilen Endgerät noch lange nicht so leistungsstarke Ressourcen wie in einem Desktop-PC zur Verfügung. Steht man bei einem nicht-kritischem Codefragment vor der Frage, eine effiziente oder eine leicht erschließbare Lösung zu implementieren, sollte Letztere gewählt werden. Dieser Herangehensweise ist vor allem für die geplante Weiterentwicklung im Team nötig. Software-Design MVC-Modell Soweit es möglich ist, soll das in Kapitel 3.2 vorgestellte MVC-Muster angewendet werden, um eine flexible Weiterentwicklung zu ermöglichen. Dabei sind die von Android bereitgestellten Mechanismen auszuschöpfen. 32

39 4.2 Konzeption Aufteilung der Logik-Klassen Soweit es das Application-Framework 4 zulässt, soll die Logik des Programms nach dem Single-Responsibility-Paradigma aufgeteilt werden. Dies sieht vor, dass jede Klasse einen einzigen Zweck besitzt, für den sie verantwortlich ist. Dadurch wird eine erhöhte Wiederverwendbarkeit des Codes erreicht. 4.2 Konzeption Aufgrund der zuvor aufgezeigten Analyse wird nun auf das Konzept von Vespucci eingegangen. Grundlegend für die weitere Vorgehensweise sind zum einen die Datenstruktur (4.2.1) sowie das UI-Konzept für die Benutzerführung (4.2.2). Darauf aufbauend werden die wichtigsten Klassen in ihrer Struktur erläutert (4.2.3) und in den betreffenden Klassen auf den Schutz von ungewollter Datenmanipulation eingegangen (4.2.4). Speziell für diese Arbeit wurde zur Kartenansicht das sogenannte viewbox-system entwickelt, welches anschließend erläutert wird. Zum Abschluss der Konzeption werden verschiedene Möglichkeiten zum XML-Parsen (4.2.6), sowie der persistenten Datenhaltung (4.2.7) erläutert und für den Gebrauch in Vespucci bewertet Datenstruktur Die Datenstruktur von Vespucci soll der Repräsentation der OSM-Daten 5 entsprechen. Abbildung 4.1 dient zur Veranschaulichung der Repräsentation. Abbildung 4.1: UML-Klassendiagramm der Datenstruktur Die abstrakte Klasse OsmElement stellt eine Generalisierung der OSM-Elemente dar. In ihr liegen alle Felder und Methoden, die für alle drei Elemente gleich sind: Die 4 siehe Architektur, Kap Siehe Kap. 2.3, OSM-Datenmodell 33

40 4 Geodateneditor Vespucci Verwaltung von Metadaten sowie der Tag-Liste. Von ihr abgeleitet sind die Klassen Way, Node und Relation. Diese enthalten nur noch die Element-spezifischen Aufgaben. Die Klasse Way enthält eine Liste mit Referenzen auf Nodes, die ihre Wegpunkte repräsentieren. Die Nodes bestehen wiederum ausschließlich aus den Lat/Lon-Koordinaten 6. Das Konstrukt der Relationen wird durch das Strukturmuster 7 Kompositum über die Klassen Relation und Member realisiert. So besteht eine Relation aus einer Liste von Members. Jeder Member ist eine Referenz auf ein OsmElement und enthält die Information über die Rolle des Members UI-Konzept Wird die Anwendung zum ersten Mal gestartet, soll als erstes dem Benutzer die Möglichkeit gegeben werden, einen Kartenausschnitt zu laden. Sind die Daten angezeigt, bekommt der Anwender den Zugriff auf die wichtigsten Modi über ein Menü. Weitere Optionen sollen erst in einem sekundären Menü sichtbar werden. Darüber hinaus muss für den Benutzer zu jedem Zeitpunkt ersichtlich sein, in welchem Modus er sich befindet. Zum Editieren der Schlüssel-Wert-Paare im Tag-Modus muss sich wegen der Übersichtlichkeit ein neues Fenster öffnen. Dort sollen dem Anwender alle bisherigen Paare angezeigt werden, so dass er diese verändern kann oder neue hinzufügen kann. Das Vergrößern/Verkleinern des Kartenausschnitts soll ausschließlich über den schnellen Zugriff über Hardwaretasten verfügbar sein. Das Verschieben desselbigen muss sowohl über Touchscreen, als auch über Tastendruck möglich sein. Ein Skizze für die Oberflächengestaltung ist im Anhang auf Seite ii zu finden Klassenstruktur Main Diese Klasse ist die Default-Activity, welche die Map-View und deren Benutzereingaben, Intents, Benutzerkonfiguration und das Hauptmenü verwaltet. Es hält außerdem die Referenz auf das Logic-Objekt, welches beim Start erzeugt wird. 6 Die Wahl der Datentypen sind in Kapitel (Koordinaten), bzw (Listen) erläutert. 7 Vgl. Gamma, Erich et al.: Kap. 4: Strukturmuster. In Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software. Pearson Education, 2004, S. 239ff. 34

41 4.2 Konzeption BoxPicker Diese Activity stellt das Fenster zur Auswahl der zu ladenen Fläche 8 dar, welches zuvor in der Main-Klasse durch ein Intent gestartet wurde. Es erhält die aktuelle Position des Gerätes. Hat der Benutzer seine Auswahl bestätigt, wird das entsprechende Ergebnis an die Main-Klasse zurückgegeben. TagEditor Der TagEditor wird aus der Main-Klasse gestartet und besteht im Wesentlichen aus einem Formular mit Eingabefeldern für die Schlüssel-Wert-Paare. Das Ergebnis wird wieder an die Main-Klasse übergeben. Map Diese View ist ausschließlich für das Rendern der OSM-Daten auf den Bildschirm verantwortlich. Es erhält die OSM-Daten sowie die aktuellen Kartengrenzen von der Logic. Diese werden für den Benutzer auf dem Display dargestellt. Logic Die Logic steuert die komplette Programmlogik. Sie hält die Benutzer-Modi, managed die viewbox, schickt aktualisierte Daten an die Map, verarbeitet Eingabe-Events, startet die Logic-Threads 9 und hält das StorageDelegator-Objekt. osm.storagedelegator Der StorageDelegator (Abb ) besteht aus zwei Storage-Objekten. Ein Objekt wird benutzt um alle geänderten, erstellten oder gelöschten Elemente für den Transfer zum Server zu halten (apistorage). Das andere Storage-Objekt ist für die Verwaltung aller Elemente zuständig, die der Benutzer angezeigt bekommt (currentstorage). Eine Speicherredundanz findet nicht statt, da das Server-Objekt nur Referenzen auf bereits existierende OsmElement-Objekte hält. Dazu ein Beispiel zur Löschung eines Knotens: 1. Die Logik befiehlt dem StorageDelegator, dass ein bestimmter Knoten gelöscht werden soll. 2. Der StorageDelegator überprüft, ob der Knoten sich bereits in apistorage für geänderte Elemente befindet. 8 In der Computergrafik werden Auswahlkästen Bounding Box genannt. 9 siehe Kapitel UI-Threads, Seite 46 35

42 4 Geodateneditor Vespucci logic storagedelegator currentstorage apistorage verändertes Node unverändertes Node gelöschtes Node Abbildung 4.2: Schemenhafte Aufteilung der Storage-Komponenten 3. Ist dies der Fall, wird er nur aus currentstorage entfernt und als gelöscht markiert. Ansonsten muss er noch zusätzlich in apistorage eingefügt werden. 4. Ist der Knoten Teil eines Weges, muss auch die Referenz im Weg auf den Knoten gelöscht werden. Der Weg wird als geändert markiert und in apistorage eingefügt, falls er nicht schon dort aufgrund früherer Änderungen eingetragen wurde. 5. Enthält nun der Weg nur noch einen Wegknoten, wird der Weg als gelöscht markiert und aus currentstorage entfernt. 6. Die letzten beiden Schritte werden solange ausgeführt, bis kein Weg auf einen Knoten verweist. osm.storage Ein Storage-Objekt soll alle OsmElement-Objekte halten und verwalten. Die Klasse darf als einzige direkt auf der Datenstruktur Manipulationen ausführen Schutz vor ungewollter Datenmanipulation Da nach Google die Objekterzeugung mit zu den aufwendigsten Operationen auf der Android-Plattform gehört 10, werden die Objekte der Datenstruktur beim Transfer aus der Datenhaltung raus nicht kopiert. Stattdessen arbeiten alle verarbeitenden Klassen 10 Vgl. Google, Inc.: Designing for Performance. URL: Zugriff am

43 4.2 Konzeption auf den Original-Objekten. Um während der Entwicklung trotzdem sicherzustellen, dass keine Daten ungewollt manipuliert werden, sind verschiedene Sicherheitsmechanismen in den folgenden Klassen vorgesehen: osm.storage Eine Instanz dieser Klasse repräsentiert die Datenhaltung aller OSM-Elemente. Die Methoden zur Datenmanipulation sind mit Hilfe des Standard-Modifizierer nur für Klassen im gleichen Paket (osm.*) sichtbar. Das Storage-Objekt ist das einzige, das direkt auf der Datenstruktur arbeitet. Die Getter der Element-Listen verwenden die statische Methode Collections.unmodifiableList(Object), um die Listen vor Manipulation außerhalb der Klasse zu schützen. osm.storagedelegator Die Klasse osm.storagedelegator ist neben der erzeugenden osm.osmparser-klasse die einzige Instanz, die die manipulativen Methoden von Storage benutzt. Darüber hinaus ist sie die einzige Klasse im Paket osm, die ein Storage-Objekt während seines Lebenszyklus halten darf. osm.osmelementfactory Parallel zu den manipulativen Methoden von osm.storage sind die Modifizierer der OsmElementen-Konstruktoren auf Standard eingestellt. Dies führt dazu, dass sie ausschließlich innerhalb ihres Pakets aufgerufen und instanziert werden können. Möchte der Entwickler ein neues OSM-Element erzeugen, bedient er sich der OsmElement- Factory. So kann er im Entwicklungsprozess leichter den Überblick behalten, wo neue Objekte erzeugt werden. Da neu generierte OSM-Elemente noch keine ID von der API zugewiesen bekommen haben, wird ihnen intern eine eigene, eindeutige ID kleiner Null zugewiesen. Die OsmElementFactory übernimmt die Verwaltung der IDs und stellt sicher, dass keine ID zweimal vergeben wird viewbox-system Bei der Entwicklung des Editors war es wichtig, eine einfache Logik für die aktuelle Anzeigeposition zu implementieren. Eine oft verwendete Methode ist es, den Mittelpunkt 37

44 4 Geodateneditor Vespucci W S N O h lat/lon Abbildung 4.3: Anzeigesystem über eine Position und Zoomfaktor (h) der Anzeige zu speichern und alle zu zeichnende Objekte in Relation dazu darzustellen (Abb ). Allerdings braucht man bei dieser Methode einen weiteren Parameter für den Abstand (Zoom) des Betrachters der Szene. Jeder Punkt muss beim Zeichnen anhand des Mittelpunkts der Anzeige, der Zoom-Stufe und der Information über die Bildschirmausmaße berechnet werden. Die Relation zwischen Bildschirmausmaße und Anzeigebereich kann nur mittels aufwendiger trigonometrischer Berechnung errechnet werden. Besondere Fehlermöglichkeiten aufgrund falscher Relationen und unpräziser Berechnung ergeben sich bei der Umrechnung von Bildschirmkoordinaten zu Geokoordinaten. Aus diesen Gründen wurde im Laufe der Arbeit das viewbox-system entwickelt (Abb. 4.4). Ähnlich wie der Bounds-Bereich im OSM-Format (Abs ) werden die äußeren Grenzen einer Bounding Box als Geokoordinaten gespeichert. Diese geben den aktuell sichtbaren Bereich an. Alle Geokoordinaten werden auf die Bildschirmkoordinaten projiziert. W S N O minlon minlat maxlat maxlon Abbildung 4.4: Das viewbox-system Eine Translation (Verschiebung der viewbox) wird durch einfache, gleichmäßige Addition der entsprechenden Koordinate realisiert. Möchte der Benutzer den Kartenausschnitt vergrößern/verkleinern ( zoomen ), werden alle Grenzen mit dem Zoomfaktor multipliziert, so dass sich die viewbox gleichmäßig ausdehnt. 38

45 4.2 Konzeption Ein weiterer Vorteil ist, dass durch maximal vier Vergleichs-Operationen festgestellt werden kann, ob sich ein Punkt innerhalb der viewbox befindet 11. Darüber hinaus können Knoten dauerhaft als Geokoordinaten gespeichert und manipuliert werden: Wenn der Benutzer eine Position auf dem Display verändert, wird - analog zum Zeichnen - die relative Position auf dem Bildschirm berechnet und auf die viewbox projiziert. Diese Umrechnung enthält somit weniger Umrechnungsfehler als die Berechnung über Zoom-Stufen Parsen der XML-Daten Das Android-SDK stellt zwei APIs bereit, wie XML-Daten eingelesen werden können. In diesem Abschnitt wird kurz auf die Gemeinsamkeiten und Unterschiede der ereignisorientierten und der DOM-basierten Methode eingegangen und anschließend in der Evaluierung die passende Methode für Vespucci ausgewählt. DOM-basiert Bei der DOM-basierten Methode zum Parsen von XML-Daten wird die komplette Datei in eine Baumstruktur gelesen. Über verschiedene Methoden, die die Beziehungen der Knoten und Blätter zueinander darstellen, kann jeder Teilbaum bzw. jedes Blatt angesprochen werden. Der Vorteil gegenüber der ereignisorientierten Methode ist, dass dieser Zugriff wahlfrei geschehen kann und eine Manipulation sich direkt zur Laufzeit auf die Struktur auswirkt. Ein Nachteil ist jedoch der hohe Speicherbedarf, da die komplette XML-Datei eingelesen sein muss, um alle Elemente zu verarbeiten. Ereignisorientiert (SAX) Die ereignisorientierte Methode wird durch die Simple API for XML (SAX) bereitgestellt. Hier wird die XML-Datei sequentiell eingelesen und bei jedem Element wird ein Ereignis generiert. Der Entwickler kann diese Ereignisse anhand von vordefinierten Funktionen abfangen und die Daten in eine eigene Datenstruktur speichern. Der Vorteil liegt hier in der schlanken Verarbeitung der Daten. Insbesondere kann der Entwickler selbst entscheiden, welche Daten geparst werden sollen oder welche er verwerfen möchte. Dies kann jedoch gleichzeitig ein Nachteil sein, da dem Entwickler keine Informationen über die Umgebung sowie Tiefe des aktuellen Elements vorliegen. 11 siehe Kapitel Listing 4.11, BoundingBox.isIn(int,int), Seite 55 39

46 4 Geodateneditor Vespucci Soll beispielsweise ein Element aufgrund seiner Eltern- oder Kindknoten differenziert behandelt werden, muss der Entwickler diese Informationen selbst verwalten. Evaluierung Die XML-Daten der derzeitigen OSM-API bestehen ausschließlich aus drei Ebenen 12. Aufgrund dieser geringen Tiefe ist der Vorteil der DOM-basierten Methode irrelevant. Zusätzlich ist es bei der ereignisorientierten Methode möglich, nicht genutzte Metadaten wie Datum oder Benutzername nicht einzulesen, um das Parsen zu beschleunigen. Deshalb wurde für Vespucci die ereignisorientierte Methode zum Parsen von OSM- Daten ausgewählt Vergleich der Datenhaltungsmöglichkeiten Zwar erhält man die OSM-Daten aus der API im XML-Format, doch für die interne Speicherung ist dies nicht zwingend das Optimum. Deshalb werden die drei Möglichkeiten der Datenhaltung vorgestellt und anschließend die beste Lösung für Vespucci evaluiert: XML Durch die Speicherung im Klartext ist XML ein sehr vielseitiges Format, das insbesondere bei der Schnittstellenkommunikation zwischen verschiedenen Systemen hilfreich ist. Da neben den Daten auch die Struktur komplett als Text abgelegt ist, belegen XML-Daten im Gegensatz zu Binärformaten sehr viel Speicherplatz. Darüber hinaus muss jede XML-Datei vor der Verarbeitung geparst werden, was einen zusätzlichen Zeitverlust bei der Verarbeitung bedeutet. SQLite Nach eigenen Angaben ist SQLite eine Software-Bibliothek, die eine unabhängige, Server-lose, konfigurationsfreie, transaktionale SQL Datenbank implementiert 13. Das Android-SDK enthält solch eine Bibliothek für den leichten Zugriff auf Datenbanken. SQLite bietet effizienten Zugriff auf verschiedene Datentypen, ohne alle Daten im Arbeitsspeicher halten zu müssen. Somit sind Datenbanken gerade für größere Datenmengen interessant. 12 Ebene 0: Wurzelelement, Ebene 1: OSM-Element, Ebene 2: Tags und Referenzen (siehe Datenmodell, Kapitel 2.3) 13 Übersetzt nach: SQLite: Welcome. URL: Zugriff am

47 4.2 Konzeption Der Nachteil bei SQLite besteht jedoch darin, dass viele typischen Datenbankeigenschaften beispielsweise wie Foreign-Key-Constraints nicht unterstützt werden 14. Auf eine konsistente Datenhaltung muss deshalb der Datenbankanwender selbst achten. Sie kann nicht per Design sichergestellt werden. Java-Objekte Eine weitere Möglichkeit in der Datenhaltung besteht in der Erzeugung von Java- Objekten. Eigentlich ist diese Methode für die Verwendung zur Laufzeit im Arbeitspeicher gedacht. Sie kann allerdings mittels Serialisierung auch für persistente Daten eingesetzt werden. Dabei werden die Objekte in einem Binärformat abgespeichert. Dieses kann zu einem späterem Zeitpunkt wieder direkt in die Objektstruktur gewandelt werden. Evaluierung Der Performanz-Flaschenhals liegt bei Vespucci in jedem Neuzeichnen der Daten. Damit für den Benutzer eine flüssige Animation generiert werden kann, müssen nach Hoang mindestens 16 bis 24 Bilder pro Sekunde gerendert werden 15. Aus diesem Grund sollten alle sichtbaren Elemente im Arbeitsspeicher gehalten werden, da dieser eine um den Faktor 10 3 niedrigere Zugriffszeit gegenüber dem Festspeicher bietet. 16 XML und SQLite kommen somit höchstens für die Zwischenspeicherung von Elementen außerhalb des sichtbaren Bildschirmbereichs in Frage. Diese müssten allerdings mit den Daten im Arbeitsspeicher synchronisiert werden. Da bei diesem Prozess wieder auf den Festspeicher zugegriffen wird, ist diese Methode nur dann relevant, wenn der Arbeitsspeicher für die gesamte Datenstruktur nicht ausreichend ist. Da nach der Zielgruppendefinition 17 der Benutzer hauptsächlich kleine Ausschnitte kartografiert, muss auch nur eine geringe Datenmenge vorgehalten werden. Das Kriterium des Speicherplatzverbrauchs ist somit für Vespucci von geringerer Bedeutung als die Performanz. Daraus folgt, dass vorraussichtlich die komplette Datenstruktur im Arbeitsspeicher gehalten werden kann. Ein weiteres Format zur persistenten Da- 14 SQLite: SQL Features That SQLite Does Not Implement. URL: Zugriff am Vgl. Hoang, Youn-Ju Ko: Vermittlung von Visual Literacy durch Computeranimation im Kunstunterricht. Dissertation FU Berlin, 2000, URL: Kap. 3, S Für gewöhnlich besteht der Festspeicher bei Handsets aus Flash-Speicher. Bei ferro-magnitischen Festplatten liegt der Faktor der Zugriffszeit durchaus bei (Vgl. Benjamin Benz, Boi Feddern: Festplatte ade. c t, , S. 101ff URL: ) 17 Siehe Kap Zielgruppendefinition 41

48 4 Geodateneditor Vespucci tenhaltung wird nicht benötigt, da die Java-Objekte mittels Serialisierung dauerhaft abgespeichert werden können. 4.3 Implementation Im Folgenden werden die wichtigsten Implementierungsdetails von Vespucci vorgestellt und erläutert. Ziel dieses Kapitels ist es vor allem die Lösungen relevanter Problemstellungen zu erklären als den Zusammenhang des kompletten Programms darzustellen. Nach einer kurzen Abhandlung über die Zahlenrepräsentation der Geodaten, werden Details aus der Logik (4.3.2), sowie der UI-Implementation (4.3.3) vorgestellt. Abschließend werden verschiedene Mechanismen zur Optimierung vermittelt (4.3.4). Eine Wahl der Programmiersprache war nicht möglich, da alle Android-Applikationen ausschließlich in Java geschrieben sein dürfen Zahlenrepräsentation der Geokoordinaten Wie bereits in Kapitel aufgeführt werden die Geokoordinaten mit sieben Nachkommastellen in der XML-Datei abgespeichert. Die Android-Entwickler weisen auf die Möglichkeit hin, dass manche Endgeräte keine Fließkommaarithmetik per Hardware leisten können 19. Deshalb sollte nach Möglichkeit in relavanten Methoden auf Fließkommaberechnung verzichtet werden. Somit fiel die Entscheidung darauf, die Koordinaten mit 10 7 multipliziert als Ganzzahlen abzulegen. Alle Rechenoperationen mit den Koordinaten können nun ohne Fließkommaarithmetik umgesetzt werden. Der Datentyp int kann in Java ganze Zahlen von ( 2 31 ) bis (2 31 1) abspeichern. Da die Breitengrade ±90, 0 und Längengrade ±180, 0 nicht überschreiten, sind die Höchstwerte in der Repräsentation ± Der Datentyp int ist somit vollkommen ausreichend Logik Drei Herausforderungen im Logik-Teil der Software werden in diesem Abschnitt behandelt. Zuerst wird die Projektionsmethode der Geokoordinaten hergeleitet. Anschließend wird gezeigt, wie der Klick auf einen Weg mit Toleranzen erkannt werden kann. Ein weiteres Problem bestand darin, aufwändige Prozesse im Hintergrund laufen zu 18 siehe Kapitel 3.1 Architektur, Seite Google, Inc.: Avoid Float. URL: Zugriff am

49 4.3 Implementation lassen, dessen Lösung im Abschnitt UI-Threads dargelegt wird. Danach wird die Implementierung der DialogFactory erläutert und das Konzept der Intents anhand des TagEditors veranschaulicht. Der letzte Abschnitt dient zur Verdeutlichung, wie Android es dem Entwickler auf einfachste Weise ermöglicht, auf Sensordaten des Gerätes zuzugreifen. Projektionsmethode der Geokoordinaten Seit Jahrhunderten beschäftigen sich Kartografen mit der optimalen Projektionsmethode für geografische Koordinaten. Das Problem besteht darin, die Erdkoordinaten, die sich auf einer Kugel befinden, auf eine zweidimensionale Fläche abzubilden. Die Mercator-Projektion 20 ist wie folgt aufgebaut: Um die Kugel wird ein Zylinder gelegt, der die Kugel am Äquator berührt. Nun werden, vom Erdmittelpunkt ausgehend, die Koordinaten der Kugel auf die Zylinderoberfläche projeziert. Letztere ergibt abgerollt eine zweidimensionale Repräsentation der Geokoordinaten. Diese Methode hat den Vorteil, dass alle Längengrade den gleichen Abstand besitzen. Allerdings werden die Breitengrade bei steigendem Abstand zum Äquator voneinander ausgedehnt. Dieser Effekt bewirkt, dass beispielsweise Grönland größer erscheint als Afrika. Da die gängigen Renderer die erzeugten Karten mit der Mercator-Projektion berechnen, wird diese auch in Vespucci eingesetzt. Dadurch werden dem Benutzer die Daten in gleicher Relation zu dem von ihm bekannten Kartenmaterial angezeigt. Die Berechnungsformel nach Lev M. Bugayevskiy berechnet die y-koordinate auf der Zylinderoberfläche 21. Es sei ϕ der Breitengrad in Radiant und α in Grad. [ ( 1 y rad = ln tan 4 π + 1 )] 2 ϕ [ y deg = 180 π ln = 180 π ln [ tan ( 1 tan 4 π + 1 )] 2 π 180 α ( 1 4 π + π )] 360 α (4.1) (4.2) (4.3) Da für α = n 90 die Funktion nicht definiert ist, und die Projektionswerte ab 85 extrem hohe Verzerrungen aufweisen, sollte dieser Bereich ausgeschlossen werden. Die Renderer Mapnik und Osmarenderer 22 setzen die Karten aus vielen kleinen, quadratischen Kacheln zusammen. Deshalb ist es für sie von Vorteil, die projizierten Werte von 20 nach Gerhard Mercator (richtig Gerhard Kremer) 21 Lev M. Bugayevskiy, John Parr Snyder: Kap In Map Projections. Taylor & Francis, 1995, S ebenso auch Google Maps 43

50 4 Geodateneditor Vespucci Längen- und Breitengraden auf 180 zu begrenzen um ein großes Quadrat zu erhalten. Daraus ergibt sich die folgende Grenze für α: [ ( π π ln tan 4 + π )] 360 α (4.4) α 360 π arctan(eπ ) 90 (4.5) α 85, (4.6) Die gesamte Berechnung der Mercator-Projektion wurde in der Klasse util.geomath umgesetzt: 1 public static f i n a l double 180 PI = 180 / Math. PI ; 2 public static f i n a l double PI 360 = Math. PI / 360; 3 public static f i n a l double PI 4 = Math. PI / 4 ; 4 public static f i n a l double MAX LAT = 5 PI 360 * Math. atan (Math. pow(math. E, Math. PI ) ) 9 0 ; 6 7 public static double lattomercator ( double l a t ) { 8 l a t = Math. min (MAX LAT, l a t ) ; 9 l a t = Math. max( MAX LAT, l a t ) ; 10 return 180 PI * Math. l o g (Math. tan ( l a t * PI PI 4 ) ) ; 11 } Listing 4.1: util.geomath.lattomercator(double) Die Methode legt zuerst den Breitengrad lat in den Grenzen von ±MAX LAT fest. Anschließend wird die Projektionsformel 4.3 angewendet. Erstellen neuer Knoten auf einem Weg Wenn der Benutzer einen neuen Knoten auf einem Weg erstellt, soll der Knoten nicht einfach über dem Weg liegen, sondern in das Wegsegment zwischen den zwei benachbarten Knoten liegen. Zuerst muss das Programm erkennen, dass der Anwender auf eine Linie geklickt hat. Da der Benutzer im Normalfall nicht punktgenau auf die Linie klickt, muss zusätzlich eine Toleranz in der Erkennung mitberechnet werden. Ist der Abstand des Klickpunktes zu dem Wegsegment kleiner als die Toleranz, wird der Knoten in das Segment eingefügt. 44

51 4.3 Implementation y p2 g d p v α p1 α x Abbildung 4.5: Punktabstandsberechnung Gegeben seien zwei Punkte p 1 (p 1x, p 1y ), p 2 (p 2x, p 2y ), die auf der Geraden g(x) = m x + b liegen. d sei der gesuchte Abstand zwischen der Gerade g(x) und Punkt p(p x, p y ). Der vertikale Abstand zwischen g und p ist v: v = g(p x ) p y (4.7) Der Winkel α berechnet sich aus der Steigung der Geraden durch die Punkte p 1 und p 2 : m = p 2y p 1y p 2x p 1x (4.8) α = arctan(m) (4.9) Die Distanz d zwischen g(x) und p lässt sich nun wie folgt berechnen: d = v cos(α) (4.10) = v cos(arctan(m)) (4.11) = v 1 + m 2 (4.12) In der Methode Logic.createNodeOnWay(Node,Node,float,float) wird diese Formel angewendet: 1 i f (GeoMath. isbetween ( x, node1x, node2x, t o l e r a n c e ) 2 && GeoMath. isbetween ( y, node1y, node2y, t o l e r a n c e ) ) { 3 double s l o p e = ( node2y node1y ) / ( node2x node1x ) ; 4 double v e r t i c a l D i s t a n c e = Math. abs ( s l o p e * x + node1y 5 s l o p e * node1x y ) ; 6 double orthodistance = v e r t i c a l D i s t a n c e / 45

52 4 Geodateneditor Vespucci 7 Math. s q r t (1 + Math. pow( slope, 2 ) ) ; 8 i f ( orthodistance <= t o l e r a n c e ) { 9 int l a t = GeoMath. ytolate7 (map. getheight ( ), viewbox, y ) ; 10 int lon = GeoMath. xtolone7 (map. getwidth ( ), viewbox, x ) ; 11 return OsmElementFactory. createnodewithnewid ( l a t, lon ) ; 12 } 13 } Listing 4.2: Logic.createNodeOnWay(Node,Node,float,float) Zuerst wird die notwendige Bedingung überprüft, ob sich die Koordinaten x und y innerhalb des Rechtecks aufgespannt von Node1 und Node2 befinden. Anschließend werden die Steigung(3), die vertikale Distanz(4), sowie die orthogonale Distanz nach Formel 4.12 berechnet(6). Ist diese Distanz kleiner oder gleich der Toleranz (hinreichende Bedingung), wird ein neuer Knoten erzeugt und zurückgegeben(11). UI-Threads Während aufwändiger Berechnungen oder lang andauernden Operationen soll dem Benutzer mitgeteilt werden, dass das Programm gerade beschäftigt ist und ggf. keine Benutzereingaben verarbeiten kann. Dies kann beispielsweise durch einen Statusbalken und eine gesperrte Arbeitsfläche für die Zeit der Berechnung geschehen. Abbildung 4.6: Klassendiagramm der LogicThreads In der Android-Architektur kann ausschließlich der Hauptthread (UI-Thread) auf Oberflächenkomponenten zugreifen. Dies führt dazu, dass ein vom Hauptthread erzeugter Statusbalken nicht vom Subthread ausgeblendet werden kann, wenn der Subthread seine Berechnung beendet hat. Deswegen wird in der Main-Activity ein Handler erzeugt, dem über die Methode Handler.post(Runnable) ein Runnable-Objekt über- 46

53 4.3 Implementation geben werden kann. Dieses Objekt wird anschließend im UI-Thread ausgeführt. Der Handler dient also dazu, Codefragmente durch ein Runnable-Objekt im UI-Thread ausführen zu lassen. Zusätzlich zum Handler-Objekt wird dem Thread die Referenz auf die ausführende Activity mitgegeben. Über diese Referenz kann innerhalb des Runnable-Objekts auf die UI-Methoden der Activity zugegriffen werden. Die Abbildung 4.7 verdeutlicht den Sachverhalt: Die Main-Activity erzeugt einen Handler, der zusammen mit der Referenz auf die Activity selbst an die Befehlsmethode Logic.doHeavyOperation(Activity, Handler) übergeben wird. Diese Methode erzeugt einen HeavyOperationThread, welcher über run() unmittelbar ausgeführt wird. Sobald HeavyOperationThread.run() gestartet ist, wird die heavyoperation() ausgeführt. Nach Abschluss von heavyoperation() wird das Runnable-Objekt notfication an den Handler gepostet und veranlasst das Ausblenden des Ladebalkens STATUSBAR. DialogFactory Um den Code der Main-Activity zu verringern, wurde das Dialog-Handling in eine DialogFactory ausgegliedert. Diese ist dafür verantwortlich, die DialogBuilder zu verwalten und bei einem Aufruf über DialogFactory.create(int) die DialogBuilder. create()-methode der entsprechenden Builder aufzurufen. Der Ablauf einer Dialog-Erzeugung findet in folgender Reihenfolge statt. QUESTION sei eine Dialog-ID. Abbildung 4.7: Sequenzdiagramm für Dialogerzeugung 1. Aufruf von Activity.showDialog(QUESTION) innerhalb der Main-Activity. 2. Diese erzeugt wiederum einen Aufruf von Activity.onCreateDialog(QUESTION), die in der Main überschrieben ist. 3. Innerhalb der Main.onCreateDialog(QUESTION) wird DialogFactory.create (QUESTION) aufgerufen. 47

54 4 Geodateneditor Vespucci 4. Die DialogFactory.create(QUESTION) ruft anhand der ID die Builder. create()-methode des entsprechenden Dialog-Builders auf. 5. Der Builder erzeugt den Dialog und gibt ihn an die DialogFactory zurück. 6. Dieser Dialog ist auch der Rückgabewert der DialogFactory.create(QUESTION). 7. Auch die Main.onCreateDialog(QUESTION) gibt diesen Dialog als Rückgabewert zurück. Anschließend kümmert sich das Betriebssystem um die Darstellung des Dialogs. Die DialogFactory braucht bei Erzeugung eine Referenz auf die Main-Klasse, da die Button-Listener der Dialoge wiederum Methoden aus der Main aufrufen sollen. TagEditor Der TagEditor ist eine neue Activity, welche durch ein Touch-Event in der Main- Activity aufgerufen wird: 1 private void performtagedit ( f i n a l float x, f i n a l float y ) { 2 // catch t he element on t h i s x, y p o i n t 3 OsmElement selectedelement = l o g i c. getelementfortagedit ( x, y ) ; 4 i f ( selectedelement!= null ) { 5 I n t e n t starttageditor = new I n t e n t ( Main. this, TagEditor. class ) ; 6 7 // copy unmodifieable Tag L i s t in a new ArrayList 8 ArrayList<Tag> tags 9 = new ArrayList<Tag>( selectedelement. gettags ( ) ) ; // i n s e r t Bundles 12 starttageditor. putextra ( TagEditor.TAGS, tags ) ; 13 starttageditor. putextra ( TagEditor.TYPE, 14 selectedelement. getname ( ) ) ; 15 starttageditor. putextra ( TagEditor. OSM ID, 16 selectedelement. getosmid ( ) ) ; Main. this. s t a r t A c t i v i t y F o r R e s u l t ( starttageditor, 19 Main.REQUEST EDIT TAG ) ; 20 } 21 } Listing 4.3: Main.MapTouchListener.performTagEdit(float,float) Zuerst wird das OSM-Element an der berührten Stelle des Bildschirms abgefragt. In Zeile 3 wird ein neuer Intent erzeugt, welcher anschließend mit den wichtigen Daten wie bisheriger Tags (12), Elementtyp (13), sowie der OSM-ID (15) versehen wird. Anschlie- 48

55 4.3 Implementation ßend wird der Intent mit der Anfrage REQUEST EDIT TAG gestartet. Diese Anfrage-ID wird später dazu verwendet, um das Ergebnis dieser Anfrage eindeutig zuordnen zu können. Sobald die neue Activity das Ergebnis zurückgeliefert hat, wird anhand der Anfrage- ID entschieden, wie das Ergebnis zu interpretieren ist (Listing 4.4) 2 protected void o n A c t i v i t y R e s u l t ( f i n a l int requestcode, 3 f i n a l int resultcode, f i n a l I n t e n t data ) { 4 super. o n A c t i v i t y R e s u l t ( requestcode, resultcode, data ) ; 5 i f ( requestcode == REQUEST BOUNDINGBOX && data!= null ) { 6 handleareapickerresult ( resultcode, data ) ; 7 } else i f ( requestcode == REQUEST EDIT TAG && 8 resultcode == RESULT OK && data!= null ) { 9 handletageditorresult ( data ) ; 10 } 11 } Listing 4.4: Main.onActivityResult(int,int,Intent) ( unchecked ) 2 private void handletageditorresult ( f i n a l I n t e n t data ) { 3 Bundle b = data. getextras ( ) ; 4 //Read data from e x t r a s 5 ArrayList<Tag> tags 6 = ( ArrayList<Tag>) b. g e t S e r i a l i z a b l e ( TagEditor.TAGS) ; 7 S t r i n g type = b. g e t S t r i n g ( TagEditor.TYPE) ; 8 long osmid = b. getlong ( TagEditor. OSM ID ) ; 9 10 l o g i c. i n s e r t T a g s ( type, osmid, tags ) ; 11 map. i n v a l i d a t e ( ) ; 12 } Listing 4.5: Main.handleTagEditorResult(Intent) Anschließend wird das Ergebnis in handletageditorresult(intent) verarbeitet, die neuen Tags an die Logic-Klasse übergeben (10) und ein Neu-Zeichnen der Map angestoßen (11). Bei der BoxPicker-Activity wird dazu analog verfahren. Tracker: Abfrage der Geoposition Die Android-Plattform hat das Ziel, die Benutzung der Hardwarefunktionalität so einfach wie möglich zu gestalten. Ein Beispiel dafür ist die LocationListener-Schnittstelle. 49

56 4 Geodateneditor Vespucci Die Implementation der vier vorgegebene Methoden 23 sowie das einmalige Registrieren für dieses Event (Listing 4.6) reichen vollkommen aus, um alle Updates der Geoposition zu erhalten. 1 locationmanager. requestlocationupdates ( 2 LocationManager.GPS PROVIDER, // Anfrage an das GPS Modul 3 p r e f s. g e t G p s I n t e r v a l ( ), // Update Z e i t i n t e r v a l l 4 p r e f s. getgpsdistance ( ), // Update D i s t a n z i n t e r v a l l 5 this // Referenz auf d i e LocationListener Implementation 6 ) ; Listing 4.6: Registrierung für Location Updates in Tracker User Interface (UI) Gemäß der Analyse (Kap ) sollte bei der Oberflächengestaltung großen Wert auf Verständlichkeit, Einfachheit und intuitive Benutzerführung gelegt werden. In den folgenden Abschnitten wird gezeigt, wie diese Anforderungen umgesetzt wurden: Zuerst wird die Implementation der Menüführung erläutert, so dass anschließend auf die Modi-Anzeige eingegangen werden kann. Zuletzt wird ausführlich erklärt, wie die Daten in der Map-Klasse gezeichnet werden. Modi-Anzeige Der geforderte Funktionsumfang 24 beinhaltet die Auswahl verschiedener Modi. Diese werden ihm im Menü durch aussagekräftige Icons und Titel deutlich vermittelt (Abb. 4.8) Zusätzlich dazu sieht der Benutzer oben links in der Titelleiste das gleiche Icon Abbildung 4.8: Icons im geöffneten Menü als Information über den aktuell ausgewählten Modus (Abb. 4.9). Menüführung Das Hauptmenü in der Map ist in der Ressource /res/menu/main menu.xml definiert. Listing 4.7 zeigt den Eintrag im Menü für den Move-Modus: 23 onlocationchanged(location), onproviderdisabled(string), onproviderenabled(string) und onstatuschanged(string,int,bundle) in android.location.locationlistener 24 Siehe Kapitel Funktionsumfang, Seite 30 50

57 4.3 Implementation Abbildung 4.9: Modi-Anzeige in der Titelleiste 1 <item a n d r o i d : i /menu move 2 a n d r o i d : i c o move 3 a n d r o i d : t i t l /menu move 4 a n d r o i d : a l p h a b e t i c S h o r t c u t= m 5 /> Listing 4.7: /res/menu/main menu.xml (Auszug) Zuerst wird eine neue ID für dieses Menü-Element erzeugt, welche unter dem Bezeichner R.id.menu move im Code direkt adressierbar ist. In Zeile 2 wird das Icon festgelegt, das sich im Pfad /res/drawable/menu move.png befindet. Anschließend wird der Titel aus der String-Ressource referenziert (3) und ein Shortcut für die Tastenkombination Menu+m festgelegt. Beim Starten einer Activity wird die Methode Activity.onCreateOptionsMenu (Menu) aufgerufen, die der Entwickler überschreiben kann, um das Menü einzubinden: 2 public boolean oncreateoptionsmenu ( f i n a l Menu menu) { 3 f i n a l MenuInflater i n f l a t e r = getmenuinflater ( ) ; 4 i n f l a t e r. i n f l a t e (R. menu. main menu, menu ) ; 5 return true ; 6 } Listing 4.8: Main.onCreateOptionsMenu(Menu) Hier wird das Menü aus der Ressource geladen und als aktuelles Menü gesetzt. Rückgabewert ist true, da das Event zur Menüerzeugung behandelt wurde. Map Die Map-View ist verantwortlich für das Zeichnen aller Daten. Diese View bekommt regelmäßige Updates von der Logic-Klasse über die Position der viewbox, den ausgewählten Modus, sowie den OSM-Daten selbst. 51

58 4 Geodateneditor Vespucci Kantenglättung (AntiAliasing) Android kann die Kantenglättung zur weicheren Anzeige von Kanten über ein einfaches Flag in den Paints 25 aktivieren. Wenn der Benutzer das AntiAliasing zur Beschleunigung der Anzeige abschalten möchte, werden alle verwendeten Paints mittels Paint.setAntiAlias(false) für die Kantenglättung deaktiviert. Zeichnen der Daten Das Zeichnen der Daten wird in der View.onDraw()-Methode aufgerufen. Es wird über jede Liste von Elementtypen iteriert und eine Elementspezifische Zeichenroutine ausgeführt. Abbildung 4.10: Vespucci im Create-Modus In der Abbildung 4.10 sind die gezeichneten Wege inklusiver Knoten und Toleranzen im Create-Modus angezeigt. 1 private void paintnode ( f i n a l Canvas canvas, f i n a l Node node ) { 2 int l a t = node. getlat ( ) ; 3 int lon = node. getlon ( ) ; 4 5 // Paint only nodes i n s i d e the viewbox. 6 i f ( viewbox. i s I n ( l a t, lon ) ) { 7 f loat x = GeoMath. lone7tox ( getwidth ( ), viewbox, lon ) ; 8 f loat y = GeoMath. late7toy ( getheight ( ), viewbox, l a t ) ; 9 10 //Draw t o l e r a n c e c i r c l e. 11 drawnodetolerance ( canvas, node. g e t S t a t e ( ), l a t, lon, x, y ) ; i f ( node == selectednode && isineditzoomrange ) { 14 canvas. drawpoint ( x, y, p a i n t s. get ( Paints.SELECTED NODE) ) ; 25 siehe android.graphics.paint, 52