Fachhochschule Wedel

Fachbereich Medieninformatik

Bachelorthesis

”Vespucci“:

Entwicklung eines Geodateneditors fur dasOpenStreetMap-Projekt auf der

Android-Plattform

Eingereicht von:

Matthias BrandtTalstraße 15, 20359 Hamburg, Tel: (040) 202 363 76

Abgegeben am:

3. Marz 2009

Erarbeitet im:

7. Semester

Referent:Prof. Dr. Andreas HausleinFachhochschule WedelFeldstraße 14322880 WedelTel: (04103) 804 80-42

Betreuer:Niels LinnemannBlau Mobilfunk GmbHSchulterblatt 12420357 HamburgTel: (040) 288 071-17

Inhaltsverzeichnis

1 Einleitung 11.1 Problemkontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Proprietare Geodaten . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Proprietare Smartphone-Plattformen . . . . . . . . . . . . . . . 21.1.3 Aufwand beim Erstellen von Geodaten . . . . . . . . . . . . . . 3

1.2 Zielsetzung dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.1 ”Entwicklung eines Geodateneditors. . . . . . . . . . . . . . . . 31.2.2 . . . fur das OpenStreetMap-Projekt. . . . . . . . . . . . . . . . . 41.2.3 . . . auf der Android-Plattform“ . . . . . . . . . . . . . . . . . . 4

2 Das OpenStreetMap-Projekt (OSM) 52.1 Projektstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Projektstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Gleichberechtige Benutzer . . . . . . . . . . . . . . . . . . . . . 72.2.2 Bisheriges Benutzerverhalten . . . . . . . . . . . . . . . . . . . 72.2.3 Unabhangigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.4 Lizenzmodell CC-BY-SA-2.0 . . . . . . . . . . . . . . . . . . . 8

2.3 Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.1 Datenelemente . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.2 Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.3 Metadaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.4 Aufbau einer OSM-XML-Datei . . . . . . . . . . . . . . . . . . 13

2.4 Programmierschnittstelle (”API“) . . . . . . . . . . . . . . . . . . . . . 142.4.1 RESTful Design . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.2 API 0.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.3 OSM-Binary API . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Die Android-Plattform 193.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Modell-View-Controller (MVC)-Muster . . . . . . . . . . . . . . . . . . 20

3.2.1 Vorteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.2 Modell: XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.3 View: Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.4 Controller: Java-Klassen . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Interprozesskommunikation durch Intents . . . . . . . . . . . . . . . . 233.4 Applikationslebenszyklus . . . . . . . . . . . . . . . . . . . . . . . . . . 243.5 Automatisiertes Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.5.1 Standardmoglichkeiten von Google . . . . . . . . . . . . . . . . 253.5.2 Automatisierte Tests mit ”Positron“ . . . . . . . . . . . . . . . 263.5.3 Automatisierte Erzeugung mit ”AndroidAnt“ . . . . . . . . . . 26

4 Geodateneditor”

Vespucci“ 294.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.1 Zielgruppendefinition . . . . . . . . . . . . . . . . . . . . . . . . 294.1.2 Technische Rahmenbedingungen . . . . . . . . . . . . . . . . . 304.1.3 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Konzeption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2.1 Datenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2.2 UI-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.3 Klassenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.4 Schutz vor ungewollter Datenmanipulation . . . . . . . . . . . 364.2.5 viewBox-System . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2.6 Parsen der XML-Daten . . . . . . . . . . . . . . . . . . . . . . 394.2.7 Vergleich der Datenhaltungsmoglichkeiten . . . . . . . . . . . . 40

4.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3.1 Zahlenreprasentation der Geokoordinaten . . . . . . . . . . . . 424.3.2 Logik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3.3 User Interface (UI) . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.4 Optimierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.4 Potential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.4.1 Weiterentwicklung als OpenSource-Projekt . . . . . . . . . . . 564.4.2 Verknupfung mit anderen Projekten . . . . . . . . . . . . . . . 574.4.3 Erweiterung des Funktionsumfangs . . . . . . . . . . . . . . . . 57

5 Ausblick 615.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.1.1 Erfullung der Anforderungen . . . . . . . . . . . . . . . . . . . 615.1.2 Vespucci im Feldversuch . . . . . . . . . . . . . . . . . . . . . . 62

5.2 Perspektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.2.1 OpenStreetMap . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.2.2 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.2.3 Vespucci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Doctype Definition (DTD) i

UI-Konzept: Skizze ii

Rechtliche Hinweise iii

Listings v

Tabellenverzeichnis vii

Abbildungsverzeichnis ix

Literaturverzeichnis xi

Eidesstattliche Erklarung xv

1 Einleitung

Zunachst wird im Problemkontext aufgezeigt, dass proprietare Geodaten und Smart-phone-Plattformen nicht fur das Allgemeinwohl zutraglich sind. Danach wird der Auf-wand fur das Sammeln von Geodaten verdeutlicht. Von dieser Situation ausgehendwird anschließend die Zielsetzung dieser Arbeit beschrieben.

1.1 Problemkontext

1.1.1 Proprietare Geodaten

In der heutigen Wissensgesellschaft gewinnt das Wissen uber ortsbezogene Informatio-nen stetig an Bedeutung. Durch einen verstarkten Mobilisierungsgrad der Bevolkerungsind Menschen gezwungen, sich in ihnen unbekannten Gebieten zurecht zu finden oderden direkten Weg zu finden.

Jedoch ist das Wissen uber ortsbezogene Daten nicht frei verfugbar1. Bisher sindGeodaten in signifikanter Menge nur gegen Gebuhr bei Vermessungsamtern und ge-winnorientierten Unternehmen erhaltlich. Die daraus folgenden Konsequenzen sind:

Verwehrung der Wissensfreiheit: Menschen in strukturschwachen Regionenwird der freie Zugang zu Wissen versperrt. Zwar machen die Lizenzgebuhren fur Na-vigationsgerate nur einen kleinen Teil des Kaufpreises aus und verhindern damit ober-flachlich betrachtet nur geringfugig den Zugang. Allerdings gibt es fur viele Entwick-lungslander keine genauen Kartendaten, da es sich fur die Kartenhersteller aufgrundder geringen Kaufkraft nicht rentiert, dort detaillierte Geodaten zu erfassen.

Lizenzabgaben: Hersteller von Navigationsgeraten mussen fur jedes Endgerat Li-zenzgebuhren an die Kartenhersteller bezahlen.

Restriktionen: Privatpersonen ist es nicht gestattet, Kartenmaterial zu kopierenund beispielsweise auf Einladungen oder eigenen Webseiten zu veroffentlichen.

Politische und militarische Zensur: Seit Beginn der Kartografie sind Kartennicht nur Orientierung fur Handel und Reisen, sondern insbesondere von militarischer

1Ausnahme bilden wenige Lander wie die USA, in denen alle Daten einer Behorde automatischAllgemeingut (

”Public Domain“) werden.

1

1 Einleitung

Bedeutung. Nach Brunner fuhrt dies dazu, dass bis in die Gegenwart Kartenmaterialentweder zuruckgehalten wird, oder zur Desinformation verfalscht wird2.

Verfalschung: Clark belegt, dass Kartenhersteller absichtlich Straßendaten verfal-schen, um Kopien entlarven zu konnen3.

Veranderungen, Anpassungen, Zusatzinformationen: Aufgrund proprietarerDatenformate und Restriktionen durch Lizenzbestimmungen ist es dem Benutzer inder Regel nicht moglich, Geodaten zu verandern oder neue hinzuzufugen. So ist erauf den Hersteller angewiesen, dass eine aktualisierte Version der Karte gegen erneuteGebuhr angeboten wird.

1.1.2 Proprietare Smartphone-Plattformen

Bisher waren nahzu alle Betriebssysteme und Plattformen fur Smartphones nur unterproprietaren Lizenzen verfugbar. Dazu zahlen Windows Mobile (Microsoft), Black-Berry (RIM), SymbianOS (Nokia) und seit Sommer 2007 Mac OS X in abgewandel-ter Form fur das iPhone (Apple). Durch das Geheimhalten des Quellcodes wird dasBetriebssystem fur Benutzer und Entwickler zu einer Blackbox: Niemand kann diegenauen Vorgange im System beobachten und auf Sicherheitslucken oder Hinterturenhin uberprufen. Auch eine Erweiterung des Systems um eine gewunschte Funktion istausgeschlossen.

Wie bereits im vorigen Abschnitt 1.1.1 gezeigt ermoglichen proprietare Formateeine Zensur seitens der Hersteller. Besonders hervorzuheben ist im Bereich der Smart-phones das Software-Vertriebsmodell des App-Store. Apple verbietet es dem Benutzernicht durch den App-Store bezogene Fremdsoftware zu installieren. Jeder Entwickler,der sein Programm fur das iPhone vertreiben mochte, kann dies ausschließlich uberden App-Store erreichen. Er muss sich dazu fur eine jahrliche Gebuhr von 99 USD(bzw. 299 USD fur firmeninterne Anwendungen) registrieren und 30% seines Umsat-zes an Apple abgeben4. Matthey berichtet davon, dass, sollte das Programm nichtden Vorstellungen Apples genugen oder in ahnlicher Weise bereits vorhanden sein, dieApplikation abgelehnt wird5.

Wegen der Gefahr von Viren und anderen Schadprogrammen wird dem Entwick-ler von Drittsoftware oftmals nur ein kleiner Bereich im System zugewiesen, fur das

2Vgl. Brunner, Kurt; Unverhau, Dagmar (Hrsg.): Kap. Kap. 8 In Kartenverfalschung als Folgeubergrosser Geheimhaltung? 2. Auflage. LIT Verlag Berlin-Hamburg-Munster, 2002, S. 167ff.

3Clark, Andrew: Copying maps costs AA £20m. 〈URL:http://www.guardian.co.uk/uk/2001/mar/06/andrewclark〉 – Zugriff am 23.02.2009.

4Vgl. Stauble, Markus: Ein bisschen Freiheit. iX, 5 2008, Nr. 5, S. 131ff.5Vgl. Matthey, Florian: Funktion zu ahnlich wie iTunes: Apple sperrt iPhone-App Podcaster aus.

〈URL: http://www.macnews.de/news/111124.html〉 – Zugriff am 23.02.2009.

2

1.2 Zielsetzung dieser Arbeit

er Anwendungen programmieren kann. So hat zum Beispiel Apple erst auf offentli-chem Druck hin Entwicklern ermoglicht, nicht nur spezialisierte Webapplikationen zuschreiben, die uber den internen Browser benutzt werden konnen6, sondern auch nativeApplikationen zu programmieren.

1.1.3 Aufwand beim Erstellen von Geodaten

Sollte eine Privatperson sich dazu entschließen, ihr Wissen uber ihr bekannte Orte zusammeln (im folgenden ”Mapper“ genannt), benotigt diese ein Gerat zur Positions-bestimmung. Durch sinkende Preise und standige Weiterentwicklung sind heute GPS-Empfanger auch fur Privatpersonen erschwinglich. Mit solch einem Gerat ausgerustetkann ein Mapper die Orte aufsuchen und die gesammelten Koordinaten speichern. An-schließend ubertragt er die Daten auf seinen Computer und verknupft mit Hilfe einesGeodateneditors die gewonnenen Koordinaten mit dessen Wissen uber Straßennamenoder anderen Informationen. Nun hat der Anwender die Moglichkeit, die Daten inRohform oder als Karte visualisiert fur Interessierte zu verbreiten.

Der Umstand, die Daten erst auf einen PC zu laden, sie dort zu bearbeiten undanschließ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 For-mate haben konnen und wie hoch der Aufwand fur das Sammeln von Geodaten ist.Die Ziele dieser Arbeit werden nun anhand des Titels erlautert:

1.2.1”

Entwicklung eines Geodateneditors. . .

Auf dem Markt fur Geoinformationssysteme und -editoren gibt es eine große Auswahlan Software, die aufgrund der komplexen Thematik nicht intuitiv zu bedienen sind.Im Gegensatz dazu soll die innerhalb dieser Arbeit entwickelte Software selbst furungeubte Nutzer sofort verstandlich sein. Der Benutzer sollte ohne zusatzliches GPS-Gerat oder Notizblock Daten erstellen und verandern konnen. Das wichtigste Ziel istjedoch, dass der Mapper einen Schritt in der Produktionskette spart: Das aufwandigeHochladen und Editieren am Computer.

In Kapitel 4 wird ausfuhrlich beschrieben, wie im Laufe dieser Arbeit der Geoda-teneditor ”Vespucci“ durch Analyse, Konzeption und Implementation entstanden ist.

6Vgl. Stauble, Markus: Ein bisschen Freiheit. iX, 5 2008, Nr. 5, S. 131ff.

3

1 Einleitung

Namensgeber der entstandenen Applikation ist der Kartograf und Entdecker AmerigoVespucci7, der aufgrund seiner Verdienste in der Kartografie ausgewahlt wurde.

1.2.2 . . . fur das OpenStreetMap-Projekt. . .

Das OpenStreetMap-Projekt stellt Geodaten unter der freien CreativeCommons-Li-zenz ”Attribution-Share Alike 2.0“ bereit. Diese erlaubt es jedem, die Daten zu kopie-ren, zu verandern und hinzuzufugen, solange er sie unter der gleichen Lizenzbedingungweitergibt und auf OSM als Quelle verweist. Dadurch wird beispielsweise dem Groß-stadtbewohner ermoglicht, neue Abkurzungen in die Karte einzutragen oder durch dieEintrage 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 Programmierschnittstelledes Projekts wird in Kapitel 2 naher eingegangen.

1.2.3 . . . auf der Android-Plattform“

Android ist eine OpenSource-Handset-Plattform, die es jedem ermoglicht, den Quell-code einzusehen, zu verandern und weiterzugeben. Daruber hinaus ist jede Applikationauf dem Gerat gleichberechtigt8: Wenn der Benutzer mit der Adressbuch-Applikationnicht zufrieden ist, kann er eine neue programmieren (lassen) und die alte ersetzen.Die Endgerate konnen GPS-Empfanger und 3D-Grafik-Chipsatze beinhalten. Zusatz-lich sind sie darauf ausgelegt, eine standige Internetverbindung aufrecht zu halten (jenach Verfugbarkeit GPRS, EDGE, UMTS, WiFi).

Eine Zensur uber verfugbare Applikationen findet nicht statt: Das Installieren ausanderen Quellen als des Plattform-eigenen ”Market“ ist gestattet und alleine die Be-nutzer entscheiden durch einen Bewertungsmechanismus uber die Qualitat der einge-stellten Programme9.

In Kapitel 3 werden die Architektur sowie einige wichtige Details fur die Software-entwicklung auf dieser Plattform naher beschrieben.

7Eigentlich Alberigo Vespucci (1451 – 1512). Der Kartograf Bernd Waldseemuller hat nach ihmden Kontinent Amerika benannt.

8Vgl. Meier, Reto: Professional Android Application Development. 1. Auflage. Indianapolis,USA: Wiley Publishing, 2009, S. 3.

9Chu, 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 25.02.2009.

4

2 Das OpenStreetMap-Projekt (OSM)

Wie bereits in der Einleitung (1.2.2) kurz vorgestellt, ist OpenStreetMap ein Projektzur Verbreitung freier Geoinformationen. Das Ziel dieses Projektes ist es, die erste freieWeltkarte zu erstellen. Jeder kann die Daten verandern, hinzufugen oder loschen.

2.1 Projektstatus

Mittlerweile sind fast 10.000 Menschen bei OpenStreetMap angemeldet1, wovon ca.zehn Prozent sich aktiv am Projekt beteiligen2.

Abbildung 2.1: OpenStreetMap Datenbankstatistik3

1OpenStreetMap: OpenStreetMap Statistics. 〈URL:http://www.openstreetmap.org/stats/data_stats.html〉 – Zugriff am 16.02.2009.

2Vgl. Robinson, Andy: Percent of total user contributing. 〈URL:http://wiki.openstreetmap.org/images/archive/9/99/20090202092626!Osmdbstats8.png〉 –Zugriff am 16.02.2009.

3Entnommen aus: Robinson, Andy: OpenStreetMap Database Statistics. 〈URL:http://wiki.openstreetmap.org/images/e/e3/Osmdbstats2.png〉 – Zugriff am 16.02.2009

5

2 Das OpenStreetMap-Projekt (OSM)

Die Abbildung 2.1 zeigt die kummulierte Anzahl von Wegen, Knoten und Rela-tionen zwischen August 2005 und Februar 2009. Seit Projektbeginn steigen die Da-tensatze kontinuierlich an, so dass am Ende der Skala dreihundert Millionen Knotenerreicht wurden. Doch nicht nur quantitativ, sondern auch qualitativ erreicht das Pro-jekt immer mehr Fortschritte: So teilte OpenStreetMap im Oktober 2008 mit, dass dieStraßenkartierung von Hamburg praktisch abgeschlossen sei4.

Problematisch hingegen sind Regionen mit geringerer Einwohnerdichte. Da sich hierrechnerisch weniger OSM-Interessierte befinden, werden diese Gegenden kaum in derDatenbank von Mappern erfasst. Nach eigenen Angaben sind beispielsweise viele Ortein der Oberpfalz mit weniger als zehn Prozent der Straßen erfasst5.

2.2 Projektstruktur

DBServer(API)

Editor Renderer

XML

Mapper gewöhnlicher Benutzer

KartenbilderVektordaten & Tags

XML

JOSM

Potlatch

Merkaartor

MapnikOsmarendererKosmos

OpenStreetMap

Drittanbieter

Anwender

Abbildung 2.2: OpenStreetMap Projektstruktur

Ein Mapper, der Daten fur OpenStreetMap bereitstellen mochte, fugt diese als Vek-tordaten und Tags6 in einen Editor ein. Das Wissen, fur welche Informationen welcheTags genutzt werden konnen, sucht sich der Mapper entweder uber die entsprechende

4Vgl. Konig, Peter: Freier Hamburger Straßenplan praktisch komplett. 〈URL:http://www.heise.de/newsticker/Freier-Hamburger-Strassenplan-praktisch-komplett--/

meldung/117891〉 – Zugriff am 16.02.2009.5Vgl. o.V.: Oberpfalz. 〈URL:

http://wiki.openstreetmap.org/index.php?title=Oberpfalz&oldid=194032〉 – Zugriff am16.02.2009.

6siehe Kapitel 2.3.2 Tags, Seite 11

6

2.2 Projektstruktur

Wiki-Seite7, oder ggf. uber Tag-Presets, die der Editor bereitstellt. Die vom Mappererstellten Daten werden in einem XML-Format8 mittels HTTP an den Server (”API“)ubertragen. Dieser verwaltet alle Daten und legt sie in der Datenbank ab. Sowohlder Editor, als auch ein Renderer konnen die vorhandenen Daten abfragen und nacheigenen Regeln interpretieren. Ein Renderer hat in der Regel ein Regelset, aufgrunddessen die Tags interpretiert und als Bilder gerendert werden. Diese Bilder kann der

”gewohnliche Benutzer“ beispielsweise uber die Projektseite9 abrufen.

2.2.1 Gleichberechtige Benutzer

Ahnlich wie bei dem Enzyklopadie-Projekt ”Wikipedia“ ist jeder Benutzer gleichbe-rechtigt. Zwar fuhrt das in wenigen Fallen zu beabsichtigten oder unbeabsichtigtenFalschinformationen, die jedoch durch die Masse der Benutzer aufgefangen wird. Da essich bei den Daten von OpenStreetMap jedoch um objektiv eindeutig uberprufbare In-formationen handelt, sind sogenannte ”Editwars“, bei denen zwei Personen(gruppen)unterschiedlicher Meinung regelmaßig die Anderungen der anderen Gruppe wiederzurucksetzen, kaum zu erwarten.

In vereinzelten Fallen konnen geografische Daten dennoch politische Ansichten wi-derspiegeln. Nach Coast war der Streit zwischen griechischen und turkischen Mappernauf Zypern im November 2007 der erste10 Konflikt dieser Art. Streitpunkt auf beidenSeiten war die Benennung der Orte und Straßen in der jeweiligen Landessprache11.

2.2.2 Bisheriges Benutzerverhalten

Ramm/Topf fuhren die bislang einzigen zwei Moglichkeiten zur Geodatenerfassungauf:12

1. Der Mapper besucht mit einem GPS-Empfanger ausgerustet die Orte und Stra-ßen, die er erfassen mochte. Zusatzlich zu den GPS-Positionen werden beliebigeortsbezogenen Informationen, wie z.B. Straßennamen oder Briefkasten, gesam-melt.

7Fur Deutschland: http://wiki.openstreetmap.org/index.php/DE:Map Features8siehe Kapitel 2.3 Datenmodell, Seite 99http://www.openstreetmap.org

10Vgl. Coast, Steve: Advice needed - dispute regarding names in Cyprus. 〈URL:http://lists.openstreetmap.org/pipermail/talk/2007-November/019731.html〉 – Zugriff am16.02.2009.

11Vgl. o.V.: Advice needed - dispute regarding names in Cyprus. 〈URL:http://lists.openstreetmap.org/pipermail/talk/2007-November/019713.html〉 – Zugriff am16.02.2009.

12Vgl. Ramm, Frederik/Topf, Jochen: OpenStreetMap - Die freie Weltkarte nutzen undmitgestalten. 1. Auflage. Berlin: Lehmanns Media, 2008, S. 31-40.

7

2 Das OpenStreetMap-Projekt (OSM)

Anschließend lad er die GPS-Daten auf einen Computer um dort mit Hilfe einesEditors die Rohdaten als Vektordaten abzuzeichnen. Die gesammelten Informa-tionen werden anhand der ”Map Features“ eingegeben und mit Koordinatenverknupft. Zuletzt werden alle Daten auf den OSM-Server geladen.

2. Yahoo hat OpenStreetMap gestattet, seine Satellitenfotos zum Abzeichnen zubenutzen. In manchen Editoren lasst sich das Kartenmaterial anzeigen, so dasses der Mapper als Vektordaten nachzeichnen kann. Sollen allerdings weitere In-formationen uber die Elemente erstellt werden, braucht der Benutzer ein Orts-wissen uber den Kartenausschnitt, da sich die Erlaubnis von Yahoo nicht auf dieKartendaten, sondern nur auf die Satellitenbilder bezieht.

2.2.3 Unabhangigkeit

Der Großteil der Infrastruktur wird in Großbritannien von der ”OpenStreetMap Foun-dation“ (UK Registered Limited) betrieben. Uber diese Organisation kann sich dasProjekt als juristische Person nach außen reprasentieren und ist unabhangig vongroßen Konzernen. Jeder in der Gemeinschaft kann sich in Verantwortungspositionender Foundation wahlen lassen und ein Mitbestimmungsrecht innerhalb des Vereinsausuben. Eine Mitgliedschaft ist allerdings keine Vorraussetzung fur die Mitarbeit imProjekt.

Die Foundation finanziert sich hauptsachlich durch Spenden und Sponsoren, aberauch durch die Einnahmen von Veranstaltungs- und Mitgliedschaftsgebuhren. Nacheigenen Angaben wird das Geld hauptsachlich fur Infrastruktur, aber auch fur An-waltskosten und Promotion ausgegeben13.

2.2.4 Lizenzmodell CC-BY-SA-2.0

”Creative Commons“ ist eine Non-Profit-Organisation, die sich zum Ziel gesetzt hat,einfache Standard-Lizenzen fur Kreative bereitzustellen. Die Lizenzen sollen es denUrhebern ermoglichen, nach einem Baukastenprinzip eine gewunschte Weiternutzungzu gestatten oder zu untersagen.

Die Lizenz ”Attribution-Share Alike 2.0“ sieht vor, dass jeder Benutzer das Rechthat, das Werk zu kopieren, zu verbreiten und zu verandern. Dabei muss darauf geachtetwerden, dass sowohl die vom Autor festgelegte Namensnennung als auch die Weiter-gabe unter der gleichen Lizenz erfolgt. Mit der letzten Klausel soll verhindert werden,dass Kopien oder Derivate unter proprietarer Lizenz vertrieben werden konnen.

13OpenStreetMap-Foundation: Finances. 〈URL:http://foundation.openstreetmap.org/finances/〉 – Zugriff am 19.02.2009.

8

2.3 Datenmodell

Entscheidend ist, dass sich die Lizenz nur auf die Daten selbst bezieht. Ein Software,die die Daten verwendet, darf unter proprietarer Lizenz vertrieben werden, solange sieauf die Quelle der Daten verweist und die aus OSM abgeleiteten Daten wieder unterder selben Lizenz verfugbar macht.

Daruber hinaus schließt die Lizenz eine kommerzielle Nutzung nicht aus. Ein An-bieter darf durchaus die Daten kommerziell verbreiten, solange er die Namensnennungbeachtet und die Daten unter der gleichen Lizenz zur Verfugung stellt.

Die Lizenz CC-BY-SA-2.0 birgt aber auch einige Probleme. Deutlich wird dies be-reits durch die Namensgebung: ”Creative Commons“ richtet sich in erster Linie ankreativ Schaffende und nicht an faktische Datenbankwerke. Nach Ramm/Topf ist nichteindeutig geklart, ob sich die Lizenz uberhaupt fur OpenStreetMap anwenden ließe,da in vielen Landern faktische Daten nicht schutzwurdig sind14. Derzeit entwickelt dieOpenStreetMap Foundation ein spezielles Lizenzformat, welches sich insbesondere andie Bedurfnisse einer offenen Datenbank richtet15.

2.3 Datenmodell

Im folgenden wird auf das Datenmodell von OpenStreetMap eingegangen. Insbeson-dere werden dabei der Aufbau der Daten sowie die Bedeutung der Felder erlautert.Grundlage des Datenmodells ist die DTD-Spezifikation, welche im Anhang auf Seite izu finden ist. Sollte trotz langer Erprobung ein Fehler im Datenmodell festgestelltwerden, weisen die Administratoren darauf hin, dass in diesem Fall die Spezifikationgeandert wird und nicht der Server selbst16.

2.3.1 Datenelemente

In OpenStreetMap gibt es lediglich drei verschiedene Elemente: Knoten, Wege undRelationen. Jedes dieser Elemente enthalt beliebig viele Schlussel-Wert-Paare zur ge-naueren Beschreibung der Information (siehe Tags, 2.3.2), sowie weitere Metadaten(2.3.3).

14Vgl. Ramm, Frederik/Topf, Jochen: OpenStreetMap - Die freie Weltkarte nutzen undmitgestalten. 1. Auflage. Berlin: Lehmanns Media, 2008, 165.

15Vgl. Collinson, Mike: The OpenStreetMap License. 〈URL:http://foundation.openstreetmap.org/the-openstreetmap-license/〉 – Zugriff am 16.02.2009.

16Vgl. Ramm, Frederik et al.: XML Schema. 〈URL:http://www.nabble.com/XML-Schema-td20379824.html#a20379824〉 – Zugriff am 16.02.2009.

9

2 Das OpenStreetMap-Projekt (OSM)

Knoten

Ein Knoten ist in erster Linie ein Punkt auf der Erde, beschrieben durch Breitengrad(Latitude, kurz: lat) und Langengrad (Longitude, kurz: lon). Dieser Punkt kann fursich alleine eine Information darstellen oder zusammen mit weiteren Punkten denVerlauf eines Weges beschreiben.

1 < !ELEMENT node ( tag *)>2 < !ATTLIST node id CDATA #REQUIRED>3 < !ATTLIST node l a t CDATA #REQUIRED>4 < !ATTLIST node lon CDATA #REQUIRED>5 < !ATTLIST node v i s i b l e CDATA #IMPLIED>6 < !ATTLIST node user 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 Koordinatenwerden im Dezimalformat in den Grenzen von ±90, 0 (lat) und ±180, 0 (lon) mitmaximal sieben Nachkommastellen angegeben. Die Ungenauigkeit liegt bei maximal63,5 cm17. Das derzeit fur den Privatgebrauch gangige GPS-System enthalt hingegeneine Ungenauigkeit von mehreren Metern18. Aufgrund der mangelnde Prazision desGPS-Systems ist die Ungenauigkeit in der Quantisierung vernachlassigbar.

Wege

Ein Weg besteht neben den Metadaten und optionalen Tag-Elementen aus ID-Refe-renzen auf mindestens zwei Knoten (XML-Element nd). Die Reihenfolge der Knotenbeschreiben die Richtung des Vektorpfads. Der Begriff Weg (”Way“) ist jedoch ir-refuhrend, da dieses Element nicht nur Wege oder Straßen beschreibt, sondern alles,was sich als Linie oder Flache darstellen lasst.

Ein geschlossener Weg (der erste und letzte Knoten haben die gleiche ID) wirddann zu einer Flache, wenn ein Tag fur diesen Weg benutzt wird, welches fur Flachenvorgesehen ist.

1 < !ELEMENT way ( tag * , nd , tag * , nd , ( tag | nd )* )>2 < !ATTLIST way id CDATA #REQUIRED>3 < !ATTLIST way v i s i b l e CDATA #IMPLIED>4 < !ATTLIST way user CDATA #IMPLIED>

17Bei einem angenommenen Erdradius r = 6356752m am Aquator und einem Winkelα = 0, 999E−7 betragt der Kreisbogen b = 0, 635039556m (b = r · α)

18Vgl. Petern Konig, Holger Bleich: Auf dem GPS-Trip. c’t, 19 2008, S. 99.

10

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 uber 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 Bezie-hung stehender Elemente zu einer ubergeordneten Menge. Es konnen z.B. Abschnittevon Stadtteilgrenzen in einer ubergeordneten Relation zusammengefasst werden undsomit die gesamte Stadtgrenze definieren. Der Grenzabschnitt einer Stadtteilgrenzewird damit gleichzeitig auch zur Stadtgrenze. Dadurch wird vermieden, die gleichenGeokoordinaten fur 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 Rela-tion. Ihre Bedeutung kann frei festgelegt werden.

2.3.2 Tags

Ein Tag ist ein Schlussel-Wert-Paar zur Beschreibung der Information, welche einElement reprasentiert. Das Attribut k steht fur Key und v fur Value.

1 < !ELEMENT tag EMPTY>2 < !ATTLIST tag k CDATA #REQUIRED>3 < !ATTLIST tag v CDATA #REQUIRED>

Listing 2.4: Elementdefinition eines Tags in der DTD

11

2 Das OpenStreetMap-Projekt (OSM)

Jedes Element kann eine beliebig große Anzahl von Tag-Elementen haben. Bestimm-te Tags sind nach ”Map Features“ nur in Verbindung mit anderen Tags gebrauchlich.So kann ein Tag oneway=yes19 nur dann sinnvoll fur ein Weg-Element gesetzt werden,wenn es auch einen highway=*-Tag besitzt.

Die Beispieltabelle 2.1 veranschaulicht die Verwendungsmoglichkeiten von Tags:

Key Value Bedeutung Anwendbar furhighway residential Wohnstraße Wegeamenity bank Bank, Geldinstitut Knotenamenity parking Parkplatz Knoten, Flachenlanduse cemetry Friedhof Flachen

Tabelle 2.1: Auszug der Map Features fur Tags20

OpenStreetMap legt sehr viel Wert darauf, den Benutzern nicht vorzuschreiben, aufwelche Art und Weise sie ihre Daten einzupflegen haben. So kann ein Benutzer eineStraße beispielsweise als Straße=Autobahn definieren. Jedoch hat dieser keinen Vorteildavon, da hochstwahrscheinlich kein Renderer seine Straße als solche, geschweige dennals Autobahn erkennen wird und somit auch nicht auf einer Karte anzeigen wird.

Im OSM-Wiki gibt es die Seite ”Map Features“21, welche ein Ubereinkommen furdie meisten Tags auflistet. Auch wenn diese Seite keine Vorschrift darstellt, wird je-dem Mapper empfohlen, sich moglichst nach dieser zu richten, um eine bestmoglicheVerwendung seiner Daten zu garantieren.

2.3.3 Metadaten

ID

Jedes Element besitzt eine ID. Diese ist jedoch nicht global eindeutig, sondern nurinnerhalb ihres Elementtyps. Das bedeutet, dass zwei Elemente unterschiedlichen Typsdie gleiche ID haben konnen. Alle Elemente des gleichen Datentyps haben eindeutigeIDs. Bei einer Referenzierung uber eine ID muss zusatzlich geklart sein, um welchenElementtyp es sich handelt. Bei der Referenzierung von Wegknoten kann nur die IDeines Knoten angegeben werden. Bei den Member-Referenzen wird uber das Attributtype festgelegt, auf welchen Elementtyp sich die Referenz bezieht.

19Zur besseren Lesbarkeit werden Tag-Elemente in der Form key=value angegeben.20Auszug aus: o.V.: Map Features. 〈URL:

http://wiki.openstreetmap.org/index.php?title=Map_Features&oldid=226512〉 – Zugriff am16.02.2009

21http://wiki.openstreetmap.org/index.php/DE:Map Features

12

2.3 Datenmodell

Die IDs werden bei der Erzeugung vom API-Server vergeben und dort verwaltet22.Der Benutzer hat erst dann die Moglichkeit, die zukunftige ID zu bestimmen, nachdemdas Element auf dem Server erzeugt wurde.

Timestamp

Das Attribut Timestamp beschreibt den Zeitpunkt der letzten Anderung des Ele-ments. Es hat das Format YYYY-MM-DDTHH:MM:SSohh:mm23. Die Veranderungeines referenzierten Elementes wirkt sich nicht auf den Zeitstempel des referenzieren-den Elementes aus. Dies tritt nur bei Veranderungen in der Referenzliste oder derTag-Liste selbst ein. Zeitgebend ist die Ubertragung auf den OSM-Server, nicht dieErstellung in einem Editor.

Username

Jeder Mapper muss sich mit einem Benutzernamen und Passwort beim Server au-thentifizieren, um Daten bearbeiten zu konnen. In jedem Element wird der Name desBenutzers der letzten Anderung festgehalten. Die Anmeldung ist kostenlos und furjeden verfugbar24.

Visible

Visible ist ein Binarattribut, welches die Werte true oder false annehmen kann.Ausschließlich geloschte Elemente, welche uber die History der API abgefragt werdenkonnen, besitzen den Wert false.

2.3.4 Aufbau einer OSM-XML-Datei

Der Austausch von Daten erfolgt uber die in Teilen schon diskutierte DTD. Sie enthaltnoch weitere Felder, die fur den Empfanger von Bedeutung sein konnen, aber fur dieDatenstruktur nicht direkt relevant sind: Osm und Bounds.

22Siehe Kap. 2.4.2, Create23 YYYY::=vierstellige Jahreszahl

MM::=zweistellige Monatzzahl im JahrDD::=zweistellige Tageszahl im MonatHH::=zweistellige Stunde im 24h-FormatMM::=zweistellige MinuteSS::=zweistellige Sekundeo::= + | - (Richtung der Zeitverschiebung)hh::=zweistellige Stunde der Zeitverschiebung im 24h-Formatmm=zweistellige Minute der Zeitverschiebung

24http://www.openstreetmap.org/user/new

13

2 Das OpenStreetMap-Projekt (OSM)

Osm

Das Wurzelelement Osm beinhaltet ein optionales Bounds-Element, sowie eine Listevon allen Knoten, Wege und Relationen. Das Attribut version steht fur die API-Version (siehe ”Auswahl der API-Version“, 2.4.2). Generator bezeichnet das Pro-gramm, welches die XML-Datei erzeugt hat. Dieses Attribut wird beim Transfer zumServer gespeichert und ist nicht uber die API zuganglich. Sie dient dazu, fehlerhafteEingaben von defekten Editoren besser identifizieren zu konnen.

1 < !ELEMENT osm ( node | r e l a t i o n |way)*>2 < !ATTLIST osm version ( 0 . 5 ) #REQUIRED>3 < !ATTLIST osm genera tor CDATA #REQUIRED>

Listing 2.5: Definition des Wurzelelements in der DTD

Bounds

Obwohl das Bounds-Element nicht in der DTD erwahnt wird, schreibt der Server einsolches Element in die XML-Datei.

1 <bounds minlat=” 53 .55 ” minlon=” 9.9375 ”2 maxlat=” 53 .57 ” maxlon=” 9.982 ”/>

Listing 2.6: Beispiel eines Bounds-Elements

Wie die Bezeichner der Attribute schon andeuten, werden dadurch die außeren Grenzeneines Bereichs festgelegt. Das ist notwendig, da ein Weg samt der referenzierten Knotenaus diesem Bereich herausragen kann. Liegt ein Knoten außerhalb von Bounds, kann ervon anderen Wegen referenziert werden, die sich nicht in Bounds befinden (Abbildung2.3). Das verarbeitende Programm muss also darauf achten, dass die Knoten außerhalbdes Bereichs nicht verandert werden, da es sonst unbeabsichtigte Folgen fur anderereferenzierende Elemente haben kann.

2.4 Programmierschnittstelle (”

API“)

Eine API (”application programming interface“) ist eine Programmierschnittstelle, diees einem Entwickler ermoglicht, Funktionalitaten einer fremden Software oder einesDienstes fur sein Programm zu nutzen. OpenStreetMap stellt eine standig weiterentwi-ckelte API zur Verfugung, mit deren Hilfe jedes Programm mittels HTTP-Befehle undAustausch von OSM-XML-Datein aktuelle Daten in die Datenbank speichern lassenkann oder aktuelle wie archivierte Daten herauslesen kann.

14

2.4 Programmierschnittstelle (”API“)

Bounds-Fläche

Äußere Fläche

Nicht-geladener Way / Nodes

Geladener Way

Abbildung 2.3: Knoten außerhalb der Bounds-Flache

2.4.1 RESTful Design

REST (Representational State Transfer) beschreibt einen Architekturstil fur Inter-netdienste. Es verfolgt ein striktes Client-Server-Modell, in dem der Client uber eineURL eine Ressource anspricht und uber HTTP-Befehle beschreibt, was mit dieser Res-source getan werden soll. REST ist wie HTTP zustandslos, so dass jede Transaktionin sich verstanden werden kann und nicht von vorherigen Zustanden abhangig ist.

2.4.2 API 0.5

Die Version 0.5 ist die derzeit25 aktuelle API-Version von OpenStreetMap. Die Tabelle2.2 listet die vier moglichen CRUD-Operationen (Create, Retrieve, Update, Delete)auf:

CRUD HTTP-Befehl RessourcenpfadCreate PUT /api/0.5/{Elementtyp}/createRetrieve 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 fur API-0.526

25Oktober 2007 – Marz 200926Vgl. Ramm, Frederik/Topf, Jochen: OpenStreetMap - Die freie Weltkarte nutzen und

mitgestalten. 1. Auflage. Berlin: Lehmanns Media, 2008, S. 176f

15

2 Das OpenStreetMap-Projekt (OSM)

Create erzeugt uber den Ressourcenpfad ein neues Element. Die Definition erfolgtals Payload von HTTP-PUT in Form einer validen XML-Datei. Als Antwort sendetder Server die generierte ID fur das erzeugte Element.

Retrieve holt entweder ein bestimmtes Element uber die ID, oder alle Elementeinnerhalb eines Kartenausschnittes27. Eine Payload wird vom Client nicht benotigt.Die Antwort des Servers enthalt eine XML-Datei mit den angefragten Daten.

Update aktualisiert ein bestimmtes Element. Diese muss als Payload mit angegebenwerden. Außer eines positiven Statuscodes gibt der Server nichts zuruck.

Delete loscht das im Resourcenpfad angegebene Element. Sowohl der Client als auchder Server brauchen keine Payload zu versenden.

Authentifizierung

Die Authentifizierung erfolgt uber die Basic-Authentification, welche in HTTP spezifi-ziert sind28. Zwar erfolgt eine Kodierung uber Base64, die aber keine Verschlusselungdarstellt. Die Kodierung ist injektiv, was einer Ubermittlung der Daten in Klartextentspricht.

HTTP-Status-Codes

Wird eine Anfrage erfolgreich vom Server bearbeitet, gibt dieser eine HTTP 200 (OK)Meldung zuruck. Sollte ein Problem bei der Verarbeitung aufgetreten sein, sind fol-gende Statusmeldungen definiert:

2.4.3 OSM-Binary API

Derzeit ist das ”OSM Binary Protocol“ in der Entwicklung. Es hat das Ziel, die Daten-große zu reduzieren und durch Vermeidung des Klartext-Parsens die Verarbeitung zubeschleunigen. Dies wird dadurch erreicht, dass Zahlenwerte direkt in einem Binarfor-mat abgelegt sind und ggf. haufig auftretende Tags durch Enumerationen ersetzt wer-den. Auch die Struktur selbst wird nicht mehr uber variable XML-Konstrukte be-schrieben, sondern direkt festgelegt.

27Daruber hinaus gibt es eine Reihe weiterer, spezieller Anfrage-Methoden, die fur diese Arbeitjedoch nicht von Relevanz sind. Siehe:http://wiki.openstreetmap.org/index.php/OSM Protocol Version 0.5

28Siehe Franks, J. et al.: HTTP Authentication: Basic and Digest Access Authentication. Juni1999 〈URL: http://www.faqs.org/rfcs/rfc2617.html〉.

16

2.4 Programmierschnittstelle (”API“)

Status-Code Bedeutung400 Bad Request Die Payload entspricht nicht der Anfrage. Dies passiert bei-

spielsweise, wenn in einer Update-Operation sich die ID inder XML-Datei von der ID im Ressourcenpfad unterscheidet.

401 Unauthorized Eine manipulative Operation wurde ohne (gultige) Authen-tifizierung versucht

404 Not found Das angefragte Element existiert nicht und hat noch nie exis-tiert.

405 Method notallowed

Der Ressourcenpfad fur Create wurde angegeben, aber keinHTTP-PUT Befehl.

410 Gone Das angefragte Element existierte, wurde aber mittlerweilegeloscht.

412 Preconditionfailed

Die Operation wurde die referentielle Intigritat zerstoren.Beispiel: Ein Element soll geloscht werden, wird aber nochvon anderen Elementen referenziert. Dieser Status wird auchzuruckgegeben, wenn eine Create-Operation mit einer posi-tiven ID innerhalb der XML-Daten ausgefuhrt werden soll.

500 InternalServer Error

Ein interner Fehler ist aufgetreten.

503 ServiceUnavailable

Die Datenbank ist aus Wartungsgrunden nicht verfugbar.

Tabelle 2.3: HTTP Status-Codes der API 0.529

Ein Vergleich des OSM-Binary Protocols mit der Standard-API bezuglich der er-reichten Kompression fur einen Beispielbereich ist in Tabelle 2.4 zu finden. Die Kom-pressionen ”gz“ und ”7z“ beziehen sich auf eine Kompression bereits im HTTP-Datenstrom.

Protokoll Große Kompressionsfaktor zusatzlichOSM XML API 7260292OSM XML gz 791627 89%OSM XML 7z 584595 91%Binary API 349571 95%Binary API gz 227218 97% 35%Binary API 7z 180941 98% 20%

Tabelle 2.4: Vergleich verschiedener OSM-Protokolle30

29Ubersetzt aus: o.V.: Basic Methods for Object Access and Manipulation. 〈URL:http://wiki.openstreetmap.org/index.php?title=OSM_Protocol_Version_0.5&oldid=227425#

Basic_Methods_for_Object_Access_and_Manipulation〉 – Zugriff am 25.02.200929o.V.: OSM Mobile Binary Protocol. 〈URL: http:

//wiki.openstreetmap.org/index.php?title=OSM_Mobile_Binary_Protocol&oldid=206528〉 –Zugriff am 16.02.2009

17

2 Das OpenStreetMap-Projekt (OSM)

Diese Formate sind allerdings nach Angaben der Entwickler ausschließlich fur denLesezugriff gedacht und eignen sich nicht fur einen Editor. Sollte ein Editor dieseBinardaten interpretieren und anschließend uber das Standard-XML-Format wiederan eine weitere Instanz weitergeben, so konnen leicht durch unterschiedliche Bezugs-quellen der Daten sowie durch Formatierungsfehler Inkonsistenzen auftreten.

Da es sich bei dem OSM-Binary Protocol um Read-Only Protokoll handelt – alsokeine Daten auf dem Server manipuliert werden – entspricht es nicht den REST-Kriterien.

18

3 Die Android-Plattform

Android ist eine Plattform des Konsortiums ”Open Handset Alliance“, zu der 47 Mit-glieder als Mobilfunkprovider, Software- und Vermarktungsfirmen, sowie Halbleiter-und Geratehersteller angehoren. Das Ziel dieses Zusammenschlusses namhafter Firmenwie Google, HTC, Intel oder Telefonica ist, nach eigenen Angaben, offene Standardsfur mobile Endgerate zu entwickeln1.

Android wurde von Google entwickelt, das im November 2007 eine erste Testversiondes SDK (Software Development Kit) veroffentlicht hat. Im September 2008 erschiendas erste SDK, welches zur spateren 1.0-Version kompatibel ist. Mit dem Verkaufsstartdes ersten Endgerats ”T-Mobile G1“ (Hersteller: HTC) in den USA wurden die Quellenvon Android offengelegt2 und unter der freien Apache-Lizenz veroffentlicht. Seitdemhat jeder die Moglichkeit, die Quelltexte zu studieren, zu vervielfaltigen, zu verandernund wieder einzupflegen.

3.1 Architektur

Die Android-Plattform lasst sich in vier verschiedene Ebenen aufteilen (Tabelle 3.1).Als Grundlage des Systems liegt ein Linux Kernel (Version 2.6), welcher alle noti-gen Hardware-Treiber beinhaltet. Darauf setzen diverse Bibliotheken auf sowie dieAndroid-Laufzeitumgebung. Diese beiden unteren Schichten sind komplett in C/C++implementiert, so dass eine effiziente Verarbeitung gewahrleistet ist. Die daruber lie-genden Schichten sind in Java implementiert und werden durch die Dalvik VM inter-pretiert. Auf der dritten Ebene ist das Framework eingebettet, welche die erste fur denEntwickler sichtbare Schicht darstellt: Die Schnittstellen und Methoden dieser Schichtkann der Programmierer direkt verwenden.

Alle Anwendungen sind in der obersten Schicht reprasentiert. Wie bereits erwahntunterscheidet das System nicht zwischen Android-Anwendungen und solchen von Drit-

1OpenHandsetAlliance: Industry Leaders Announce Open Platform for Mobile Devices. 〈URL:http://www.openhandsetalliance.com/press_110507.html〉 – Zugriff am 17.02.2009.

2http://source.android.com/

19

3 Die Android-Plattform

ApplicationsHome Contacts Phone . . .

Applikation FrameworkActivity Manager Window Manager Content Providers View SystemPackage Manger Telephony Manger Resource Manager Location Manager

Notification ManagerLibraries Android Runtime

Surface Manager Media Framework SQLiteOpenGL/ES FreeType WebKit

SGL SSL libc

Core LibrariesDalvik VM

Linux KernelDisplay Driver Camera Driver Flash Memory Driver Binder (IPC) DriverKeypad Driver WiFi Driver Audio Drivers Power Management

Tabelle 3.1: Die Android-Architektur3

tanbietern. So kann der Benutzer neue Programme installieren und vorhandene erset-zen.

Die Dalvik Virtual Machine (Dalvik VM) wurde von Google selbst entwickelt undist im Gegensatz zu Sun’s Java Virtual Machine eine Registermaschine, so dass dieDalvik VM einen effizienteren Zugriff auf die Speicheradressen liefert. Ein weitererVorteil dieser Vorgehensweise ist, dass die Hersteller keine Lizenzabgaben an Sun rich-ten mussen. Der Nachteil besteht jedoch darin, dass ”normale“ Java-Kompilate nichtauf der Dalvik VM ausfuhrbar sind, und umgekehrt. Eine Plattformunabhangigkeit istsomit nicht mehr gegeben.

3.2 Modell-View-Controller (MVC)-Muster

MVC ist ein Architekturmuster in der Softwareentwicklung. Es sieht vor, die verschie-denen Schichten Modell, Prasentation und Steuerung von einander zu kapseln. DasModell reprasentiert die Datenhaltung und deren Struktur. Die Prasentation stellt dieOberflache dar und definiert deren Aussehen. Die Steuerung steht fur die Logik einerSoftware und ist dafur verantwortlich, die Daten aus dem Modell in angebrachter Weiseder Prasentation zur Verfugung zu stellen und Benutzereingaben aus der Prasentationwieder an das Modell weiterzugeben.

3Google, Inc.: System Architecture. 〈URL:http://developer.android.com/images/system-architecture.jpg〉 – Zugriff am 16.02.2009

20

3.2 Modell-View-Controller (MVC)-Muster

3.2.1 Vorteile

Folgende Vorteile ergeben sich aus diesem Muster:

Lesbarkeit Textausgaben oder Datenbankabfragen gehoren nach dem MVC-Modellnicht in die Steuerung, sondern in die Prasentation beziehungsweise in das Modell.Dadurch wird eine bessere Lesbarkeit des Codes erreicht, da dieser nur noch fur dieLogik verantwortlich ist.

Wartbarkeit Durch die Trennung der drei Schichten ist es moglich, einfacher auf diegewunschten Ressourcen zuzugreifen und sie unabhangig von den anderen Schichtenzu aktualisieren.

Wiederverwendbarkeit Die Daten und Oberflachenreprasentation sind unabhangigvom Logik-Programmcode. Dadurch lasst sich jede dieser Schichten in anderen Pro-jekten wieder verwenden, ohne dass programmspezifische Bindungen beachtet werdenmussen.

Arbeitsteilung Ein weiterer Vorteil besteht darin, dass beispielsweise UI-Entwicklerdie Oberflache gestalten konnen, ohne die Logik des Programms vorliegen oder ver-standen zu haben.

Internationalisierung Da Texte nun nicht mehr direkt im Quellcode eingebundensind, konnen diese leicht ausgetauscht werden, um das Programm fur andere Sprachenzu veroffentlichen.

Umgebungsabhangige Layouts Es konnen verschieden Layouts fur diverse Umge-bungen und Endgerate entworfen werden. Das Programm ist somit nicht mehr an einebestimmte Umgebung gebunden.

3.2.2 Modell: XML

Folgende Datentypen konnen in XML-Dateien (”Ressourcen“) gespeichert werden undsind somit unabhangig vom Code:

� Einfache Werte– Farben (RGB(A)-Werte)– Arrays (Integer und Strings)– Dimensionen (px, in, pt, mm, dp, sp)– Strings– Styles (Android-Styles fur Oberflachen)

� Bilder (PNG, JPG, GIF)� Layouts (Android-Layouts)

21

3 Die Android-Plattform

� Animationen (Uber XML definierte Animationen)� Andere Dateien

– XML-Dateien (fremd-spezifizierte XML-Daten)– Raw-Dateien (Binardaten)

Diese Ressourcen werden als XML-Dateien in einer vorgegebenen Ordnerstruktur ab-gelegt und bereits zur Compilezeit eingelesen. Dabei legt ein Compiler die Daten ineinem Binarformat ab. Dieser erzeugt eine ”R-Klasse“4, welche wiederum fur jedenDatentyp eine Subklasse mit Referenz-IDs fur die Ressourcen bereitstellt. Diese IDszeigen nicht auf die Ressource selbst, sondern auf einen Eintrag in der von Androidverwaltete Ressourcen-Tabelle. Mit Hilfe der R-Klasse kann der Entwickler bereits zurCompilezeit die Adressierung der Ressource validieren. Listing 3.1 zeigt eine Beispiel-hafte Ressource fur 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 ”>Hel lo , 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 stat ic f ina l class s t r i n g {2 public stat ic f ina l int h e l l o=0x7f070000 ;3 }

Listing 3.2: Eintrag in R-Klasse

Diese ID kann in vielen von Android bereitgestellten Methoden direkt als Parameterubergeben werden, oder selbst ausgelesen werden:

1 St r ing 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, opti-miertes Format abgelegt werden, erfolgt der Zugriff auf die Werte bedeutend schneller,als wenn dies erst zur Laufzeit geschehen wurde. Ausgenommen davon sind Raw- undXML-Dateien, welche uberhaupt nicht vorbearbeitet werden. In der aktuelle SDK-Version sind alle Ressourcen-Dateien auf eine Große von 1 MByte beschrankt.

4Pfad: /src/R.java

22

3.3 Interprozesskommunikation durch Intents

3.2.3 View: Views

Alle UI-Komponenten sind von der View-Klasse abgeleitet. Android stellt eine Rei-he von vorgefertigten Komponenten bereit, die der Entwickler uber Java-Klassen alsauch uber XML-Ressourcen benutzen und anpassen kann. Nach Moglichkeit sollte die-ser Weg gewahlt werden, da hierdurch eine weitestgehende Trennung von Benutzero-berflache und Programmcode sichergestellt wird und die Komponenten vorkompiliertsind.

3.2.4 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 vollstandig umgesetzt.

3.3 Interprozesskommunikation durch Intents

Nach Meier sind Programme auf anderen Smartphone-Plattformen voneinander ent-koppelt und konnen aufgrund von Sicherheitsrestriktionen nicht miteinander kommu-nizieren5. Bei Android hingegen wird sehr viel Wert auf Wiederverwendbarkeit gelegt.Programme konnen durch sogenannte Intents6 miteinander kommunizieren und Funk-tionalitaten fur andere Applikationen bereitstellen. Selbst das Starten von Activitieswird durch Intents umgesetzt. Dieses Vorhaben kann an eine bestimmte Klasse gerich-tet werden (explizites Vorhaben), oder allgemein formuliert (implizites Vorhaben). BeiLetzterem wird anstatt eines konkreten Klassennamens eine abstrakte Handlung an-gefragt (z.B. ACTION DIAL) und Android entscheidet aufgrund der Benutzerpraferenz,an welches Programm das Intent geleitet wird. Der Entwickler braucht sich nicht dar-um zu kummern, welche Telefonapplikation der Benutzer installiert und als Standarddefiniert hat. Fur ihn ist in diesem Beispiel nur wichtig, dass die Handlung ”wahle“ausgefuhrt wird.

Uber die Aufforderungen hinaus konnen auch Daten mitgesendet werden. Mit Hilfevon Bundles konnen die Programme Daten senden und empfangen.

5Vgl. Meier, Reto: Professional Android Application Development. 1. Auflage. Indianapolis,USA: Wiley Publishing, 2009, S. 113f.

6Intent = Intention, Vorhaben

23

3 Die Android-Plattform

3.4 Applikationslebenszyklus

Eine Besonderheit der Android-Plattform ist der Lebenszyklus von Applikationen. BeiDesktop-Betriebssystem oder auch anderen Handset-Plattformen entscheidet der Be-nutzer daruber, wann ein Programm geschlossen oder wieder geoffnet wird. Sollte zueinem bestimmten Zeitpunkt der Arbeitsspeicher des Gerates gefullt sein, werden vomBetriebssystem nicht mehr gebrauchte Speichersegmente in einen Auslagerungsspei-cher gelegt. Dies macht sich fur den Benutzer in einer verringerten Geschwindigkeitder Programme bemerkbar und er muss ggf. unnotige Programme schließen. Im bishereinzigen Endgerat ”T-Mobile G1“ stehen 96 MByte Arbeitsspeicher zur Verfugung,wovon ca. 80 MByte fur das Betriebssystem benotigt wird und 16 MByte fur Benut-zerprogramme7.

Bei Android gibt es keinen Auslagerungsspeicher. Es ubernimmt selbst die Kon-trolle uber die Laufzeit der installierten Programme. Dabei werden die Programmeund deren Fenster (Activities) in einer Warteschlange verwaltet, so dass immer so vie-le Fenster geoffnet sind, wieviel Speicher zur Verfugung steht. Fenster, welche zuerstgeoffnet wurden, werden wieder als erstes zerstort. Dadurch kann der Benutzer uberden Zuruck-Knopf auf seinem Gerat ohne Verzogerung zur letzten Applikation wech-seln. Da kein Vorwarts-Knopf vorgesehen ist, wird die nun verlassende Applikationsofort zerstort. Die Applikation, die als letzte in der Warteschlange aktiver Fensterstand und zerstort wurde, wird wieder hergestellt.

Fur jeden Status, in das ein Fenster vom System gesetzt werden kann, gibt es einestandardisierte Schnittstellenmethode, die der Entwickler implementieren kann. So-mit 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 auchdas sogenannte ”Test Driven Development“ immer mehr an Bedeutung9. Kurz zusam-mengefasst besagt diese Methode, dass die Software durch Tests spezifiziert wird. DerEntwickler schreibt als erstes einen Test, der das gewunschte Verhalten der Softwa-

7Vgl. Guy, Romain: Avoiding Memory Leaks. 〈URL:http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html〉 – Zugriff am16.02.2009.

8Entnommen aus: Google, Inc.: Activity Lifecycle. 〈URL:http://developer.android.com/images/activity_lifecycle.png〉 – Zugriff am 16.02.2009

9Vgl. Benninger, Lukas: Agile Software Development. Februar 2003 〈URL:http://www.ifi.uzh.ch/richter/Classes/sem_cutting_edge/Summary_agile.pdf〉, S. 7.

24

3.5 Automatisiertes Testen

Abbildung 3.1: Activity Lifecycle8

re spezifiziert, bevor er mit der Implementierung anfangt. Durch den Einsatz vonfunktionalen Tests ist sichergestellt, dass die Spezifikationen in jeder Stufe der Wei-terentwicklung eingehalten wird.

3.5.1 Standardmoglichkeiten von Google

Trotz der in den letzten Jahren immer wichtiger gewordenen Methode stellt Googlebisher nur unzureichende Werkzeuge fur funktionales Testing mit Android bereit. Zwargibt es im SDK eigene Pakete fur JUnit-Tests, sie sind jedoch kaum implementiertoder gar dokumentiert. Das fuhrt dazu, dass diese Pakete bisher nicht ausreichend zubenutzen sind.

Zwar ist es moglich, die Tests auf dem PC auszufuhren, doch wird dann das lokale(Sun-) JDK benutzt, da das Android-SDK nur auf der Android-Plattform lauffahig

25

3 Die Android-Plattform

ist. Dies fuhrt dazu, dass im getesteten Code sowie im Testcode selbst keine Android-spezifischen Klassen verwendet werden konnen. Jeder Code, der nicht ausschließlichaus den Standard-Klassen des JDK besteht, bleibt also ungetestet10. Daruber hinausentspricht die Umgebung nicht dem eigentlichen Zielgerat, was unter Umstanden zuunterschiedlichen Ergebnissen fuhren kann.

3.5.2 Automatisierte Tests mit”

Positron“

Positron11 ist ein Teil des AutoAndroid-Projekts, das nicht von Google selbst initiertwurde. Es hat das Ziel, das automatisierte Testen und Erzeugen von Programmen aufAndroid zu ermoglichen.

Positron ist im wesentlichen als Server-Client-Struktur aufgebaut. Der Server wirdmit Hilfe der android.app.Instrumentation-Klasse vor Ausfuhrung des Programmcodesinstanziert, so dass dieser die Kontrolle uber die Applikation ubernehmen kann. DieKommunikation mit dem Client auf dem Desktop-PC lauft uber die ADB (AndroidDebugging Bridge), die im SDK enthalten ist. Der Client kann damit Befehle an denServer senden, der mit Statusmeldungen antwortet. Dadurch wird der JUnit-Test aufdem PC gesteuert, aber letztendlich auf dem Gerat ausgefuhrt.

Durch die PositronAPI kann der Entwickler in den Tests beliebige Eingaben aufder Oberflache ausfuhren und den Status abfragen. Dadurch legt der Entwickler imvorhinein das Verhalten der Software fest.

3.5.3 Automatisierte Erzeugung mit”

AndroidAnt“

Sobald eine Software nicht mehr durch einen einzelnen Entwickler, sondern im Teamgefertigt wird, empfiehlt sich der Einsatz von Build-Servern. Dies hat den Vorteil,dass dort eine festgelegte Umgebung installiert ist, die unabhangig von den lokalenWorkstations der Programmierer ist. In der Java-Welt hat sich Apache Ant als dasStandard-Werkzeug zur automatischen Erzeugung (”Build“) entwickelt. Mittels Antlassen sich uber XML-Dateien verschiedene Zielprogramme (”Targets“) definieren. Antubernimmt die Auflosung von Abhangigkeiten und Bibliotheken und veranlasst dieKompilation mit entsprechenden Parametern.

10Siehe Google, Inc.: I can’t run a JUnit test class in Eclipse/ADT. 〈URL:http://code.google.com/intl/de-DE/android/kb/troubleshooting.html#addjunit〉 – Zugriff am16.02.2009.

11http://code.google.com/p/autoandroid/wiki/Positron

26

3.5 Automatisiertes Testen

AndroidAnt ist eine AntLib fur Ant, die die Erzeugung uber den Dalvik Cross-compiler ausfuhrt und den Android-Emulator steuern kann. Leider ist nach eigenenAngaben diese Funktionalitat noch nicht ausgereift und instabil12.

12Smith, Phil: AndroidAnt - Build your Android application with ant.. without exec. 〈URL:http://code.google.com/p/autoandroid/wiki/AndroidAnt〉 – Zugriff am 16.02.2009.

27

4 Geodateneditor”

Vespucci“

Ziel dieser Arbeit ist die ”Entwicklung eines Geodateneditors fur das OpenStreetMap-Projekt auf der Android-Plattform“. In diesem Kapitel wird das Ergebnis vorgestelltund erlautert.

Zuerst werden anhand einer Benutzeranalyse eine Zielgruppe definiert und darausdie benotigten Anforderungen abgeleitet. Im Unterkapitel 4.2 ist das grobe Entwurfs-konzept mit besonderer Aufmerksamkeit auf die Datenstruktur erlautert. Anschließendwird die Implementation vorgestellt, die den Hauptteil dieser Arbeit ausmacht. ZumSchluss wird im Unterkapitel 4.4 darauf eingegangen, welches Potential in Vespuccisteckt, um darauf aufbauend im Kapitel 5 Zusammenfassung sowie einen Ausblick furdas Programm zu geben.

4.1 Analyse

Bevor ein Konzept fur Vespucci erstellt werden kann, ist eine Analyse der Rahmen-bedingungen erforderlich. Zuerst wird in diesem Kapitel die Zielgruppe festgelegt undkurz auf die technischen Rahmenbedingungen eingegangen. Aus diesen beiden Punktenlassen sich im Abschnitt 4.1.3 die Anforderungen an das Endprodukt erstellen.

4.1.1 Zielgruppendefinition

Zielgruppe sind Gelegenheitsmapper, die in unregelmaßigen Abstanden Orte oder neueWege in ihrer Umgebung eintragen wollen. Der Benutzer braucht dafur in der Regelnur einen kleinen Kartenausschnitt, denn er wird sich voraussichtlich nur zu Fuß odermit dem Fahrrad fortbewegen. Daruber hinaus ist das Programm interessant fur pro-fessionelle Mapper, denen unterwegs nicht-verzeichnete Objekte auffallen und dieseumgehend in OSM eintragen mochten, ohne sich ein weiteres Mal samt Ausrustungauf den Weg zu machen.

Der Anwender sollte sich durchaus vorher mit OSM vertraut gemacht haben unddie Zusammenhange von Knoten, Wege und Tags zu kennen. Es ist fur ihn von Vorteil,wenn er die wichtigsten und gangigen Tags auswendig kennt. Dieses Wissen ist jedochmit ein wenig Ubung schnell eingepragt.

29

4 Geodateneditor”Vespucci“

Daruber hinaus ist ein Smartphone aufgrund der geringen Bildschirm- und Tasten-große fur Menschen mit Sehschwachen und mangelnder Feinmotorik ungeeignet.

Fortgeschrittene Projektmitglieder, die komplexe oder uberregionale Strukturen be-arbeiten wollen, gehoren nicht zur Zielgruppe.

4.1.2 Technische Rahmenbedingungen

Da Android in erster Linie fur Smartphones entwickelt wird, ist auch die Softwa-re an die Begrenzungen der Hardware gebunden. Zwar steigt die Leistungsfahigkeitdieser Gerate zunehmend an, doch sind sie auch zukunftig aufgrund ihrer geringenGroße nicht einem vollwertigen Computer gleichzustellen. Beispiele hierfur sind unteranderem die Ausmaße von Displays und Eingabeschnittstellen (Tastatur, Touchpad,Trackball, etc.).

Ziel ist es daher, dass sich dem Mapper die wichtigsten Funktionalitaten soforterschließen und er diese einfach bedienen kann. Ziel ist es jedoch nicht, dem Benutzereine ansprechende Kartendarstellung oder gar Routingmoglichkeiten zu geben.

4.1.3 Anforderungen

Einfache Bedienbarkeit

Wie bereits im vorherigem Abschnitt erwahnt, ist eine leichte, intuitive Bedienungaufgrund der geringen Ausmaße des Handgerates unerlasslich. Der Benutzer soll sichschnell in die Benutzung einfinden konnen, ohne Anleitungen zu lesen oder unbeab-sichtigte Fehleingaben revidieren zu mussen.

Funktionsumfang

Auswahl des zu bearbeitenden Ausschnittes Der Benutzer soll auswahlen konnen,welchen Teil einer Karte er bearbeiten mochte. Ihm wird angeboten, bisherige Datenfur diesen Ausschnitt vom OSM-Server zu laden. Die Auswahl kann uber manuell ein-gegebene Koordinaten oder uber seine aktuelle Position erfolgen. Da hier eine praziseAngabe bei der Positionsbestimmung nicht erforderlich ist und die Ermittlung uberGPS unter Umstanden 15 Minuten dauern kann1, konnen die Daten sowohl uber dieMobilfunkzellen-ID2, als auch uber GPS benutzt werden konnen. Sobald eine praziserePositionsangabe verfugbar ist, soll diese eingesetzt werden.

1Ramm, Frederik/Topf, Jochen: OpenStreetMap - Die freie Weltkarte nutzen und mitgestalten.1. Auflage. Berlin: Lehmanns Media, 2008, Seite 20.

2Google kann aufgrund der Mobilfunkzellen-ID und die Distanz zum Sendemasten eineungefahre Position bestimmen. Die Daten sind innerhalb weniger Sekunden verfugbar

30

4.1 Analyse

Anzeige der Daten Hat der Benutzer einen Bereich mit OSM-Daten geladen, sosollen ihm die Geodaten maßstabsgetreu angezeigt werden. Daruber hinaus muss esfur den Mapper erkennbar sein, wie groß sein aktuell gultiger Bereich ist3.

Move-Modus Der Benutzer soll den sichtbaren Kartenbereich verschieben konnen.Aufgrund besserer Handhabung soll dies nicht nur uber den Touchscreen, sondern auchuber Hardwaretasten moglich sein. Eine Moglichkeit zur Vergroßerung/Verkleinerungdes Ausschnittes soll uber eigene Tasten verfugbar sein.

Edit-Modus Vorhandene Knoten auf der Karte sollen verschoben werden konnen.Wird ein Knoten an den Bildschirmrand verschoben, so soll sich der Kartenausschnitin diese Richtung mitbewegen.

Delete-Modus Der Mapper soll vorhandene Knoten loschen konnen. Wenn ein Wegzu diesem Knoten gehort hat, soll der Weg automatisch geloscht werden, wenn dieserWeg nur noch einen weiteren Knoten referenziert.

Create-Modus In diesem Modus konnen neue Elemente erstellt werden. Durch erstesKlicken des Touchscreens wird ein Knoten erstellt. Erfolgt der zweite Klick auf dengleichen Punkt, so ist die Erstellung fur diesen Punkt abgeschlossen und das nachsteElement kann angefertigt werden. Klickt der Benutzer jedoch als zweites auf eineandere Flache des Bildschirms, so wird dort ein weitere Knoten erstellt, die mit einemneuen Weg verbunden sind. Dies wird solange fortgesetzt, bis der Benutzer den letztenKnoten ein weiteres mal anklickt.

Wird ein vorhandener Knoten ausgewahlt, wird dieser benutzt, anstatt dass einneuer Knoten daruber erstellt wird. Wird auf ein Weg-Segment geklickt, so wird andieser Stelle ein neuer Knoten eingefugt und in dem darunterliegenden Weg zwischenden beiden bisherigen Knoten eingebunden.

Append-Modus Hat der Benutzer im Append-Modus den ersten oder letzten Knoteneines Wege ausgewahlt, so werden die anschließend erstellten Weg-Segmente dem Wegangehangt, anstatt einen neuen Weg zu erstellen.

Fuhrt der Benutzer eine Bewegung uber den Touchscreen aus, anstatt ihn anzukli-cken, so wird diese Bewegung als Verschiebung des Kartenausschnitts interpretiert.

Die Modi sind sowohl uber ein Programmmenu, als auch uber Tastenkurzel erreich-bar. In allen Modi werden auswahlbare Elemente mit einem Toleranzbereich ange-zeigt, der die Beruhrungstoleranz anzeigt. Dies ist erforderlich, da die Auswahl vonBildschirmelementen mittels Fingerdruck fur den Anwender unpraziser zu setzen ist,als beispielsweise ein Mausklick am Desktop-PC.

3siehe Kapitel 2.3.4 Bounds, Seite 14

31

4 Geodateneditor”Vespucci“

TagEdit-Modus Der Benutzer kann uber diesen Modus ein Element selektieren. An-schließend offnet sich ein Editor zur Manipulation der Tags. Bisherige Tags werdenangezeigt und er kann diese loschen, verandern oder beliebig viele neue Schlussel-Wert-Paare hinzufugen. Durch den Zuruck-Knopf seines Gerates bestatigt der Anwen-der die Angaben und gelangt zuruck zur Kartenansicht. Leere Felder im Formularwerden ignoriert. Die Liste von Eingabefeldern fur Schlussel-Wert-Paare erweitert sichbei Bedarf automatisch.

Anzeige des GPS-Track Dem Benutzer wird sein aktueller GPS-Pfad auf dem Dis-play angezeigt, so dass er abgelaufene Wege mittels Create-Modus direkt nachzeichnenoder einen Knoten an seiner aktuellen Position eintragen kann. Der Mapper soll dieMoglichkeit haben, diesen GPS-Track auch abschalten zu konnen. Bewegt sich der Be-nutzer in eine Richtung, wird der Kartenausschnitt auf seine neue Position verschoben.

Datentransfer vom und zum Server Der Anwender muss den aktuellen Kartenaus-schnitt vom OSM-Server neu laden oder erstellte Anderungen auf den Server ladenkonnen.

Konfigurationsmoglichkeiten Im Konfigurationsfenster kann der Anwender seineOSM-Server Login-Daten eintragen und GPS-Abfrage-Intervalle festlegen. Zusatzlichstehen dort folgende Optionen zur Verfugung: Anzeige von Statistiken in der Karten-ansicht, Anzeige der Toleranzen sowie das Abschalten von AntiAliasing zur Beschleu-nigung der Darstellung.

Verstandlichkeit des Quellcodes

Zwar stehen in einem mobilen Endgerat noch lange nicht so leistungsstarke Ressour-cen wie in einem Desktop-PC zur Verfugung. Steht man bei einem nicht-kritischemCodefragment vor der Frage, eine effiziente oder eine leicht erschließbare Losung zuimplementieren, sollte Letztere gewahlt werden. Dieser Herangehensweise ist vor allemfur die geplante Weiterentwicklung im Team notig.

Software-Design

MVC-Modell Soweit es moglich ist, soll das in Kapitel 3.2 vorgestellte MVC-Musterangewendet werden, um eine flexible Weiterentwicklung zu ermoglichen. Dabei sinddie von Android bereitgestellten Mechanismen auszuschopfen.

32

4.2 Konzeption

Aufteilung der Logik-Klassen Soweit es das Application-Framework4 zulasst, soll dieLogik des Programms nach dem Single-Responsibility-Paradigma aufgeteilt werden.Dies sieht vor, dass jede Klasse einen einzigen Zweck besitzt, fur den sie verantwortlichist. Dadurch wird eine erhohte Wiederverwendbarkeit des Codes erreicht.

4.2 Konzeption

Aufgrund der zuvor aufgezeigten Analyse wird nun auf das Konzept von Vespucci ein-gegangen. Grundlegend fur die weitere Vorgehensweise sind zum einen die Datenstruk-tur (4.2.1) sowie das UI-Konzept fur die Benutzerfuhrung (4.2.2). Darauf aufbauendwerden die wichtigsten Klassen in ihrer Struktur erlautert (4.2.3) und in den betreffen-den Klassen auf den Schutz von ungewollter Datenmanipulation eingegangen (4.2.4).Speziell fur diese Arbeit wurde zur Kartenansicht das sogenannte viewBox-System ent-wickelt, welches anschließend erlautert wird. Zum Abschluss der Konzeption werdenverschiedene Moglichkeiten zum XML-Parsen (4.2.6), sowie der persistenten Daten-haltung (4.2.7) erlautert und fur den Gebrauch in Vespucci bewertet.

4.2.1 Datenstruktur

Die Datenstruktur von Vespucci soll der Reprasentation der OSM-Daten5 entsprechen.Abbildung 4.1 dient zur Veranschaulichung der Reprasentation.

Abbildung 4.1: UML-Klassendiagramm der Datenstruktur

Die abstrakte Klasse OsmElement stellt eine Generalisierung der OSM-Elementedar. In ihr liegen alle Felder und Methoden, die fur alle drei Elemente gleich sind: Die

4siehe Architektur, Kap. 3.15Siehe Kap. 2.3, OSM-Datenmodell

33

4 Geodateneditor”Vespucci“

Verwaltung von Metadaten sowie der Tag-Liste. Von ihr abgeleitet sind die KlassenWay, Node und Relation. Diese enthalten nur noch die Element-spezifischen Aufgaben.

Die Klasse Way enthalt eine Liste mit Referenzen auf Nodes, die ihre Wegpunktereprasentieren. Die Nodes bestehen wiederum ausschließlich aus den Lat/Lon-Koor-dinaten6.

Das Konstrukt der Relationen wird durch das Strukturmuster7 Kompositum uberdie Klassen Relation und Member realisiert. So besteht eine Relation aus einer Listevon Members. Jeder Member ist eine Referenz auf ein OsmElement und enthalt dieInformation uber die Rolle des Members.

4.2.2 UI-Konzept

Wird die Anwendung zum ersten Mal gestartet, soll als erstes dem Benutzer dieMoglichkeit gegeben werden, einen Kartenausschnitt zu laden. Sind die Daten an-gezeigt, bekommt der Anwender den Zugriff auf die wichtigsten Modi uber ein Menu.Weitere Optionen sollen erst in einem sekundaren Menu sichtbar werden. Daruberhinaus muss fur den Benutzer zu jedem Zeitpunkt ersichtlich sein, in welchem Moduser sich befindet.

Zum Editieren der Schlussel-Wert-Paare im Tag-Modus muss sich wegen der Uber-sichtlichkeit ein neues Fenster offnen. Dort sollen dem Anwender alle bisherigen Paareangezeigt werden, so dass er diese verandern kann oder neue hinzufugen kann.

Das Vergroßern/Verkleinern des Kartenausschnitts soll ausschließlich uber den schnel-len Zugriff uber Hardwaretasten verfugbar sein. Das Verschieben desselbigen musssowohl uber Touchscreen, als auch uber Tastendruck moglich sein.

Ein Skizze fur die Oberflachengestaltung ist im Anhang auf Seite ii zu finden.

4.2.3 Klassenstruktur

Main

Diese Klasse ist die Default-Activity, welche die Map-View und deren Benutzereinga-ben, Intents, Benutzerkonfiguration und das Hauptmenu verwaltet. Es halt außerdemdie Referenz auf das Logic-Objekt, welches beim Start erzeugt wird.

6Die Wahl der Datentypen sind in Kapitel 4.3.1 (Koordinaten), bzw. 4.3.4 (Listen) erlautert.7Vgl. Gamma, Erich et al.: Kap. 4:

”Strukturmuster“. In Entwurfsmuster: Elemente

wiederverwendbarer objektorientierter Software. Pearson Education, 2004, S. 239ff.

34

4.2 Konzeption

BoxPicker

Diese Activity stellt das Fenster zur Auswahl der zu ladenen Flache8 dar, welches zuvorin der Main-Klasse durch ein Intent gestartet wurde. Es erhalt die aktuelle Position desGerates. Hat der Benutzer seine Auswahl bestatigt, wird das entsprechende Ergebnisan die Main-Klasse zuruckgegeben.

TagEditor

Der TagEditor wird aus der Main-Klasse gestartet und besteht im Wesentlichen auseinem Formular mit Eingabefeldern fur die Schlussel-Wert-Paare. Das Ergebnis wirdwieder an die Main-Klasse ubergeben.

Map

Diese View ist ausschließlich fur das Rendern der OSM-Daten auf den Bildschirmverantwortlich. Es erhalt die OSM-Daten sowie die aktuellen Kartengrenzen von derLogic. Diese werden fur den Benutzer auf dem Display dargestellt.

Logic

Die Logic steuert die komplette Programmlogik. Sie halt die Benutzer-Modi, mana-ged die viewBox, schickt aktualisierte Daten an die Map, verarbeitet Eingabe-Events,startet die Logic-Threads9 und halt das StorageDelegator-Objekt.

osm.StorageDelegator

Der StorageDelegator (Abb. 4.2.3) besteht aus zwei Storage-Objekten. Ein Objektwird benutzt um alle geanderten, erstellten oder geloschten Elemente fur den Transferzum Server zu halten (apiStorage). Das andere Storage-Objekt ist fur die Verwaltungaller Elemente zustandig, die der Benutzer angezeigt bekommt (currentStorage). EineSpeicherredundanz findet nicht statt, da das Server-Objekt nur Referenzen auf bereitsexistierende OsmElement-Objekte halt.

Dazu ein Beispiel zur Loschung eines Knotens:1. Die Logik befiehlt dem StorageDelegator, dass ein bestimmter Knoten geloscht

werden soll.2. Der StorageDelegator uberpruft, ob der Knoten sich bereits in apiStorage fur

geanderte Elemente befindet.8In der Computergrafik werden Auswahlkasten

”Bounding Box“ genannt.

9siehe Kapitel 4.3.2 UI-Threads, Seite 46

35

4 Geodateneditor”Vespucci“

storageDelegator

currentStorage apiStorage

gelöschtes Nodeunverändertes Node

verändertes Node

logic

Abbildung 4.2: Schemenhafte Aufteilung der Storage-Komponenten

3. Ist dies der Fall, wird er nur aus currentStorage entfernt und als geloscht mar-kiert. Ansonsten muss er noch zusatzlich in apiStorage eingefugt werden.

4. Ist der Knoten Teil eines Weges, muss auch die Referenz im Weg auf den Knotengeloscht werden. Der Weg wird als geandert markiert und in apiStorage eingefugt,falls er nicht schon dort aufgrund fruherer Anderungen eingetragen wurde.

5. Enthalt nun der Weg nur noch einen Wegknoten, wird der Weg als geloschtmarkiert und aus currentStorage entfernt.

6. Die letzten beiden Schritte werden solange ausgefuhrt, bis kein Weg auf einenKnoten verweist.

osm.Storage

Ein Storage-Objekt soll alle OsmElement-Objekte halten und verwalten. Die Klassedarf als einzige direkt auf der Datenstruktur Manipulationen ausfuhren.

4.2.4 Schutz vor ungewollter Datenmanipulation

Da nach Google die Objekterzeugung mit zu den aufwendigsten Operationen auf derAndroid-Plattform gehort10, werden die Objekte der Datenstruktur beim Transfer ausder Datenhaltung raus nicht kopiert. Stattdessen arbeiten alle verarbeitenden Klassen

10Vgl. Google, Inc.: Designing for Performance. 〈URL:http://developer.android.com/guide/practices/design/performance.html#object_creation〉 –Zugriff am 17.02.2009.

36

4.2 Konzeption

auf den Original-Objekten. Um wahrend der Entwicklung trotzdem sicherzustellen,dass keine Daten ungewollt manipuliert werden, sind verschiedene Sicherheitsmecha-nismen in den folgenden Klassen vorgesehen:

osm.Storage

Eine Instanz dieser Klasse reprasentiert die Datenhaltung aller OSM-Elemente. DieMethoden zur Datenmanipulation sind mit Hilfe des Standard-Modifizierer nur furKlassen im gleichen Paket (osm.*) sichtbar. Das Storage-Objekt ist das einzige, dasdirekt auf der Datenstruktur arbeitet.

Die Getter der Element-Listen verwenden die statische Methode Collections.un-

modifiableList(Object), um die Listen vor Manipulation außerhalb der Klasse zuschutzen.

osm.StorageDelegator

Die Klasse osm.StorageDelegator ist neben der erzeugenden osm.OsmParser-Klassedie einzige Instanz, die die manipulativen Methoden von Storage benutzt. Daruberhinaus ist sie die einzige Klasse im Paket osm, die ein Storage-Objekt wahrend seinesLebenszyklus halten darf.

osm.OsmElementFactory

Parallel zu den manipulativen Methoden von osm.Storage sind die Modifizierer derOsmElementen-Konstruktoren auf Standard eingestellt. Dies fuhrt dazu, dass sie aus-schließlich innerhalb ihres Pakets aufgerufen und instanziert werden konnen. Mochteder Entwickler ein neues OSM-Element erzeugen, bedient er sich der OsmElement-Factory. So kann er im Entwicklungsprozess leichter den Uberblick behalten, wo neueObjekte erzeugt werden.

Da neu generierte OSM-Elemente noch keine ID von der API zugewiesen bekom-men haben, wird ihnen intern eine eigene, eindeutige ID kleiner Null zugewiesen. DieOsmElementFactory ubernimmt die Verwaltung der IDs und stellt sicher, dass keineID zweimal vergeben wird.

4.2.5 viewBox-System

Bei der Entwicklung des Editors war es wichtig, eine einfache Logik fur die aktuelle An-zeigeposition zu implementieren. Eine oft verwendete Methode ist es, den Mittelpunkt

37

4 Geodateneditor”Vespucci“

N

S

W Olat/lon

h

Abbildung 4.3: Anzeigesystem uber eine Position und Zoomfaktor (h)

der Anzeige zu speichern und alle zu zeichnende Objekte in Relation dazu darzustel-len (Abb. 4.2.5). Allerdings braucht man bei dieser Methode einen weiteren Parameterfur den Abstand (Zoom) des Betrachters der Szene. Jeder Punkt muss beim Zeichnenanhand des Mittelpunkts der Anzeige, der Zoom-Stufe und der Information uber dieBildschirmausmaße berechnet werden. Die Relation zwischen Bildschirmausmaße undAnzeigebereich kann nur mittels aufwendiger trigonometrischer Berechnung errechnetwerden. Besondere Fehlermoglichkeiten aufgrund falscher Relationen und unpraziserBerechnung ergeben sich bei der Umrechnung von Bildschirmkoordinaten zu Geoko-ordinaten.

Aus diesen Grunden wurde im Laufe der Arbeit das ”viewBox-System“ entwickelt(Abb. 4.4). Ahnlich wie der Bounds-Bereich im OSM-Format (Abs. 2.3.4) werden dieaußeren Grenzen einer Bounding Box als Geokoordinaten gespeichert. Diese geben denaktuell sichtbaren Bereich an. Alle Geokoordinaten werden auf die Bildschirmkoordi-naten projiziert.

minLat

maxLat

maxLon

minLon

N

S

W O

Abbildung 4.4: Das viewBox-System

Eine Translation (Verschiebung der viewBox) wird durch einfache, gleichmaßige Ad-dition der entsprechenden Koordinate realisiert. Mochte der Benutzer den Kartenaus-schnitt vergroßern/verkleinern (”zoomen“), werden alle Grenzen mit dem Zoomfaktormultipliziert, so dass sich die viewBox gleichmaßig ausdehnt.

38

4.2 Konzeption

Ein weiterer Vorteil ist, dass durch maximal vier Vergleichs-Operationen festgestelltwerden kann, ob sich ein Punkt innerhalb der viewBox befindet11. Daruber hinauskonnen Knoten dauerhaft als Geokoordinaten gespeichert und manipuliert werden:Wenn der Benutzer eine Position auf dem Display verandert, wird - analog zum Zeich-nen - die relative Position auf dem Bildschirm berechnet und auf die viewBox projiziert.Diese Umrechnung enthalt somit weniger Umrechnungsfehler als die Berechnung uberZoom-Stufen.

4.2.6 Parsen der XML-Daten

Das Android-SDK stellt zwei APIs bereit, wie XML-Daten eingelesen werden konnen.In diesem Abschnitt wird kurz auf die Gemeinsamkeiten und Unterschiede der ereig-nisorientierten und der DOM-basierten Methode eingegangen und anschließend in derEvaluierung die passende Methode fur Vespucci ausgewahlt.

DOM-basiert

Bei der DOM-basierten Methode zum Parsen von XML-Daten wird die kompletteDatei in eine Baumstruktur gelesen. Uber verschiedene Methoden, die die Beziehungender Knoten und Blatter zueinander darstellen, kann jeder Teilbaum bzw. jedes Blattangesprochen werden.

Der Vorteil gegenuber der ereignisorientierten Methode ist, dass dieser Zugriff wahl-frei geschehen kann und eine Manipulation sich direkt zur Laufzeit auf die Strukturauswirkt.

Ein Nachteil ist jedoch der hohe Speicherbedarf, da die komplette XML-Datei ein-gelesen sein muss, um alle Elemente zu verarbeiten.

Ereignisorientiert (SAX)

Die ereignisorientierte Methode wird durch die ”Simple API for XML“ (SAX) bereit-gestellt. Hier wird die XML-Datei sequentiell eingelesen und bei jedem Element wirdein Ereignis generiert. Der Entwickler kann diese Ereignisse anhand von vordefiniertenFunktionen abfangen und die Daten in eine eigene Datenstruktur speichern.

Der Vorteil liegt hier in der schlanken Verarbeitung der Daten. Insbesondere kannder Entwickler selbst entscheiden, welche Daten geparst werden sollen oder welche erverwerfen mochte. Dies kann jedoch gleichzeitig ein Nachteil sein, da dem Entwicklerkeine Informationen uber die Umgebung sowie Tiefe des aktuellen Elements vorliegen.

11siehe Kapitel Listing 4.11, BoundingBox.isIn(int,int), Seite 55

39

4 Geodateneditor”Vespucci“

Soll beispielsweise ein Element aufgrund seiner Eltern- oder Kindknoten differenziertbehandelt werden, muss der Entwickler diese Informationen selbst verwalten.

Evaluierung

Die XML-Daten der derzeitigen OSM-API bestehen ausschließlich aus drei Ebenen12.Aufgrund dieser geringen Tiefe ist der Vorteil der DOM-basierten Methode irrelevant.Zusatzlich ist es bei der ereignisorientierten Methode moglich, nicht genutzte Metada-ten wie Datum oder Benutzername nicht einzulesen, um das Parsen zu beschleunigen.

Deshalb wurde fur Vespucci die ereignisorientierte Methode zum Parsen von OSM-Daten ausgewahlt.

4.2.7 Vergleich der Datenhaltungsmoglichkeiten

Zwar erhalt man die OSM-Daten aus der API im XML-Format, doch fur die interneSpeicherung ist dies nicht zwingend das Optimum. Deshalb werden die drei Moglich-keiten der Datenhaltung vorgestellt und anschließend die beste Losung fur Vespuccievaluiert:

XML

Durch die Speicherung im Klartext ist XML ein sehr vielseitiges Format, das insbeson-dere bei der Schnittstellenkommunikation zwischen verschiedenen Systemen hilfreichist. Da neben den Daten auch die Struktur komplett als Text abgelegt ist, belegenXML-Daten – im Gegensatz zu Binarformaten – sehr viel Speicherplatz. Daruber hin-aus muss jede XML-Datei vor der Verarbeitung geparst werden, was einen zusatzlichenZeitverlust bei der Verarbeitung bedeutet.

SQLite

Nach eigenen Angaben ist ”SQLite eine Software-Bibliothek, die eine unabhangige,Server-lose, konfigurationsfreie, transaktionale SQL Datenbank implementiert“13. DasAndroid-SDK enthalt solch eine Bibliothek fur den leichten Zugriff auf Datenban-ken. SQLite bietet effizienten Zugriff auf verschiedene Datentypen, ohne alle Daten imArbeitsspeicher halten zu mussen. Somit sind Datenbanken gerade fur großere Daten-mengen interessant.

12Ebene 0: Wurzelelement, Ebene 1: OSM-Element, Ebene 2: Tags und Referenzen (sieheDatenmodell, Kapitel 2.3)

13Ubersetzt nach: SQLite: Welcome. 〈URL: http://www.sqlite.org/〉 – Zugriff am 19.02.2009.

40

4.2 Konzeption

Der Nachteil bei SQLite besteht jedoch darin, dass viele typischen Datenbankeigen-schaften beispielsweise wie Foreign-Key-Constraints nicht unterstutzt werden14. Aufeine konsistente Datenhaltung muss deshalb der Datenbankanwender selbst achten.Sie kann nicht per Design sichergestellt werden.

Java-Objekte

Eine weitere Moglichkeit in der Datenhaltung besteht in der Erzeugung von Java-Objekten. Eigentlich ist diese Methode fur die Verwendung zur Laufzeit im Arbeitspei-cher gedacht. Sie kann allerdings mittels Serialisierung auch fur persistente Daten ein-gesetzt werden. Dabei werden die Objekte in einem Binarformat abgespeichert. Dieseskann zu einem spaterem Zeitpunkt wieder direkt in die Objektstruktur gewandeltwerden.

Evaluierung

Der Performanz-Flaschenhals liegt bei Vespucci in jedem Neuzeichnen der Daten. Da-mit fur den Benutzer eine flussige Animation generiert werden kann, mussen nach Ho-ang mindestens 16 bis 24 Bilder pro Sekunde gerendert werden15. Aus diesem Grundsollten alle sichtbaren Elemente im Arbeitsspeicher gehalten werden, da dieser eineum den Faktor 103 niedrigere Zugriffszeit gegenuber dem Festspeicher bietet.16

XML und SQLite kommen somit hochstens fur die Zwischenspeicherung von Ele-menten außerhalb des sichtbaren Bildschirmbereichs in Frage. Diese mussten allerdingsmit den Daten im Arbeitsspeicher synchronisiert werden. Da bei diesem Prozess wie-der auf den Festspeicher zugegriffen wird, ist diese Methode nur dann relevant, wennder Arbeitsspeicher fur die gesamte Datenstruktur nicht ausreichend ist.

Da nach der Zielgruppendefinition17 der Benutzer hauptsachlich kleine Ausschnittekartografiert, muss auch nur eine geringe Datenmenge vorgehalten werden. Das Kri-terium des Speicherplatzverbrauchs ist somit fur Vespucci von geringerer Bedeutungals die Performanz. Daraus folgt, dass vorraussichtlich die komplette Datenstrukturim Arbeitsspeicher gehalten werden kann. Ein weiteres Format zur persistenten Da-

14SQLite: SQL Features That SQLite Does Not Implement. 〈URL:http://www.sqlite.org/omitted.html〉 – Zugriff am 17.02.2006.

15Vgl. Hoang, Youn-Ju Ko: Vermittlung von Visual Literacy durch Computeranimation imKunstunterricht. Dissertation FU Berlin, 2000, 〈URL:http://www.diss.fu-berlin.de/diss/receive/FUDISS_thesis_000000000331〉, Kap. 3, S. 94.

16Fur gewohnlich besteht der Festspeicher bei Handsets aus Flash-Speicher. Bei ferro-magnitischenFestplatten liegt der Faktor der Zugriffszeit durchaus bei 106. (Vgl. Benjamin Benz, Boi Feddern:Festplatte ade. c’t, 21 2007, S. 101ff 〈URL: http://www.heise.de/ct/07/21/100/〉)

17Siehe Kap. 4.1.1 Zielgruppendefinition

41

4 Geodateneditor”Vespucci“

tenhaltung wird nicht benotigt, da die Java-Objekte mittels Serialisierung dauerhaftabgespeichert werden konnen.

4.3 Implementation

Im Folgenden werden die wichtigsten Implementierungsdetails von Vespucci vorgestelltund erlautert. Ziel dieses Kapitels ist es vor allem die Losungen relevanter Problemstel-lungen zu erklaren als den Zusammenhang des kompletten Programms darzustellen.

Nach einer kurzen Abhandlung uber die Zahlenreprasentation der Geodaten, wer-den 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 moglich, da alle Android-Applikatio-nen ausschließlich in Java geschrieben sein durfen18.

4.3.1 Zahlenreprasentation der Geokoordinaten

Wie bereits in Kapitel 2.3.1 aufgefuhrt werden die Geokoordinaten mit sieben Nach-kommastellen in der XML-Datei abgespeichert. Die Android-Entwickler weisen aufdie Moglichkeit hin, dass manche Endgerate keine Fließkommaarithmetik per Hard-ware leisten konnen19. Deshalb sollte nach Moglichkeit in relavanten Methoden aufFließkommaberechnung verzichtet werden.

Somit fiel die Entscheidung darauf, die Koordinaten mit 107 multipliziert als Ganz-zahlen abzulegen. Alle Rechenoperationen mit den Koordinaten konnen nun ohneFließkommaarithmetik umgesetzt werden.

Der Datentyp int kann in Java ganze Zahlen von −2.147.483.648 (−231) bis2.147.483.647 (231 − 1) abspeichern. Da die Breitengrade ±90, 0◦ und Langengrade±180, 0◦ nicht uberschreiten, sind die Hochstwerte in der Reprasentation±1.800.000.000. Der Datentyp int ist somit vollkommen ausreichend.

4.3.2 Logik

Drei Herausforderungen im Logik-Teil der Software werden in diesem Abschnitt be-handelt. 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, aufwandige Prozesse im Hintergrund laufen zu

18siehe Kapitel 3.1 Architektur, Seite 1919Google, Inc.: Avoid Float. 〈URL:

http://developer.android.com/guide/practices/design/performance.html#avoidfloat〉 –Zugriff am 20.02.2009.

42

4.3 Implementation

lassen, dessen Losung im Abschnitt ”UI-Threads“ dargelegt wird. Danach wird die Im-plementierung der DialogFactory erlautert und das Konzept der Intents anhand desTagEditors veranschaulicht. Der letzte Abschnitt dient zur Verdeutlichung, wie An-droid es dem Entwickler auf einfachste Weise ermoglicht, auf Sensordaten des Gerateszuzugreifen.

Projektionsmethode der Geokoordinaten

Seit Jahrhunderten beschaftigen sich Kartografen mit der optimalen Projektionsme-thode fur geografische Koordinaten. Das Problem besteht darin, die Erdkoordinaten,die sich auf einer Kugel befinden, auf eine zweidimensionale Flache abzubilden. DieMercator-Projektion20 ist wie folgt aufgebaut: Um die Kugel wird ein Zylinder gelegt,der die Kugel am Aquator beruhrt. Nun werden, vom Erdmittelpunkt ausgehend, dieKoordinaten der Kugel auf die Zylinderoberflache projeziert. Letztere ergibt ”abge-rollt“ eine zweidimensionale Reprasentation der Geokoordinaten.

Diese Methode hat den Vorteil, dass alle Langengrade den gleichen Abstand besitzen.Allerdings werden die Breitengrade bei steigendem Abstand zum Aquator voneinanderausgedehnt. Dieser Effekt bewirkt, dass beispielsweise Gronland großer erscheint alsAfrika. Da die gangigen Renderer die erzeugten Karten mit der Mercator-Projektionberechnen, wird diese auch in Vespucci eingesetzt. Dadurch werden dem Benutzer dieDaten in gleicher Relation zu dem von ihm bekannten Kartenmaterial angezeigt.

Die Berechnungsformel nach Lev M. Bugayevskiy berechnet die y-Koordinate aufder Zylinderoberflache21. Es sei ϕ der Breitengrad in Radiant und α in Grad.

yrad = ln[tan

(14π +

12ϕ

)](4.1)

ydeg =180◦

π· ln

[tan

(14π +

12· π

180◦α

)](4.2)

=180◦

π· ln

[tan

(14π +

π

360◦α

)](4.3)

Da fur α = n · 90◦ die Funktion nicht definiert ist, und die Projektionswerte ab 85◦

extrem hohe Verzerrungen aufweisen, sollte dieser Bereich ausgeschlossen werden. DieRenderer Mapnik und Osmarenderer22 setzen die Karten aus vielen kleinen, quadrati-schen Kacheln zusammen. Deshalb ist es fur sie von Vorteil, die projizierten Werte von

20nach Gerhard Mercator (richtig Gerhard Kremer)21Lev M. Bugayevskiy, John Parr Snyder: Kap. 2.1.2 In Map Projections. Taylor & Francis, 1995,

S. 50.22ebenso auch Google Maps

43

4 Geodateneditor”Vespucci“

Langen- und Breitengraden auf 180◦ zu begrenzen um ein großes Quadrat zu erhalten.Daraus ergibt sich die folgende Grenze fur α:

180◦ ≥ 180◦

π· ln

[tan

(π

4+

π

360◦α

)](4.4)

α ≤ 360◦

π· arctan(eπ)− 90◦ (4.5)

α ≤ 85, 051129◦ (4.6)

Die gesamte Berechnung der Mercator-Projektion wurde in der Klasse util.GeoMathumgesetzt:

1 public stat ic f ina l double 180 PI = 180 / Math . PI ;2 public stat ic f ina l double PI 360 = Math . PI / 360 ;3 public stat ic f ina l double PI 4 = Math . PI / 4 ;4 public stat ic f ina l double MAX LAT =5 PI 360 * Math . atan (Math . pow(Math .E, Math . PI ) ) − 90 ;6

7 public stat ic 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 og (Math . tan ( l a t * PI 360 + 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 nichteinfach uber dem Weg liegen, sondern in das Wegsegment zwischen den zwei benach-barten Knoten liegen. Zuerst muss das Programm erkennen, dass der Anwender aufeine Linie geklickt hat. Da der Benutzer im Normalfall nicht punktgenau auf die Li-nie klickt, muss zusatzlich eine Toleranz in der Erkennung mitberechnet werden. Istder Abstand des Klickpunktes zu dem Wegsegment kleiner als die Toleranz, wird derKnoten in das Segment eingefugt.

44

4.3 Implementation

α

p

p1

p2

vd

g

x

y

α

Abbildung 4.5: Punktabstandsberechnung

Gegeben seien zwei Punkte p1(p1x, p1y), p2(p2x, p2y), die auf der Geraden g(x) =m · x + b liegen. d sei der gesuchte Abstand zwischen der Gerade g(x) und Punktp(px, py). Der vertikale Abstand zwischen g und p ist v:

v = |g(px)− py| (4.7)

Der Winkel α berechnet sich aus der Steigung der Geraden durch die Punkte p1 undp2:

m =p2y − p1y

p2x − p1x(4.8)

α = arctan(m) (4.9)

Die Distanz d zwischen g(x) und p lasst sich nun wie folgt berechnen:

d = v · cos(α) (4.10)

= v · cos(arctan(m)) (4.11)

=v√

1 +m2(4.12)

In der Methode Logic.createNodeOnWay(Node,Node,float,float) wird diese For-mel 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 ope = ( 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 ope * x + node1Y −5 s l ope * node1X − y ) ;6 double orthoDistance = v e r t i c a l D i s t a n c e /

45

4 Geodateneditor”Vespucci“

7 Math . s q r t (1 + Math . pow( s lope , 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 l on = GeoMath . xToLonE7(map . getWidth ( ) , viewBox , x ) ;11 return OsmElementFactory . createNodeWithNewId ( la t , lon ) ;12 }13 }

Listing 4.2: Logic.createNodeOnWay(Node,Node,float,float)

Zuerst wird die notwendige Bedingung uberpruft, ob sich die Koordinaten x und yinnerhalb des Rechtecks aufgespannt von Node1 und Node2 befinden. Anschließendwerden die Steigung(3), die vertikale Distanz(4), sowie die orthogonale Distanz nachFormel 4.12 berechnet(6). Ist diese Distanz kleiner oder gleich der Toleranz (hinrei-chende Bedingung), wird ein neuer Knoten erzeugt und zuruckgegeben(11).

UI-Threads

Wahrend aufwandiger Berechnungen oder lang andauernden Operationen soll demBenutzer mitgeteilt werden, dass das Programm gerade beschaftigt ist und ggf. keineBenutzereingaben verarbeiten kann. Dies kann beispielsweise durch einen Statusbalkenund eine gesperrte Arbeitsflache fur die Zeit der Berechnung geschehen.

Abbildung 4.6: Klassendiagramm der LogicThreads

In der Android-Architektur kann ausschließlich der Hauptthread (UI-Thread) aufOberflachenkomponenten zugreifen. Dies fuhrt dazu, dass ein vom Hauptthread er-zeugter Statusbalken nicht vom Subthread ausgeblendet werden kann, wenn der Sub-thread seine Berechnung beendet hat. Deswegen wird in der Main-Activity ein Handlererzeugt, dem uber die Methode Handler.post(Runnable) ein Runnable-Objekt uber-

46

4.3 Implementation

geben werden kann. Dieses Objekt wird anschließend im UI-Thread ausgefuhrt. DerHandler dient also dazu, Codefragmente durch ein Runnable-Objekt im UI-Threadausfuhren zu lassen.

Zusatzlich zum Handler-Objekt wird dem Thread die Referenz auf die ausfuhrendeActivity mitgegeben. Uber diese Referenz kann innerhalb des Runnable-Objekts aufdie UI-Methoden der Activity zugegriffen werden.

Die Abbildung 4.7 verdeutlicht den Sachverhalt: Die Main-Activity erzeugt einenHandler, der zusammen mit der Referenz auf die Activity selbst an die BefehlsmethodeLogic.doHeavyOperation(Activity, Handler) ubergeben wird. Diese Methode er-zeugt einen HeavyOperationThread, welcher uber run() unmittelbar ausgefuhrt wird.

Sobald HeavyOperationThread.run() gestartet ist, wird die heavyOperation()

ausgefuhrt. Nach Abschluss von heavyOperation() wird das Runnable-Objekt not-fication an den Handler gepostet und veranlasst das Ausblenden des LadebalkensSTATUSBAR.

DialogFactory

Um den Code der Main-Activity zu verringern, wurde das Dialog-Handling in eineDialogFactory ausgegliedert. Diese ist dafur verantwortlich, die DialogBuilder zu ver-walten und bei einem Aufruf uber DialogFactory.create(int) die DialogBuilder.

create()-Methode der entsprechenden Builder aufzurufen.Der Ablauf einer Dialog-Erzeugung findet in folgender Reihenfolge statt. QUESTION seieine Dialog-ID.

Abbildung 4.7: Sequenzdiagramm fur 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 uberschrieben ist.3. Innerhalb der Main.onCreateDialog(QUESTION) wird DialogFactory.create

(QUESTION) aufgerufen.

47

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 zuruck.6. Dieser Dialog ist auch der Ruckgabewert der DialogFactory.create(QUESTION).7. Auch die Main.onCreateDialog(QUESTION) gibt diesen Dialog als Ruckgabe-

wert zuruck. Anschließend kummert sich das Betriebssystem um die Darstellungdes Dialogs.

Die DialogFactory braucht bei Erzeugung eine Referenz auf die Main-Klasse, da dieButton-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 ina l f loat x , f ina l f loat y ) {2 // catch the element on t h i s x , y−po in t3 OsmElement se l ec tedElement = l o g i c . getElementForTagEdit (x , y ) ;4 i f ( se l ec tedElement != null ) {5 In tent star tTagEditor = new In tent (Main . this , TagEditor . class ) ;6

7 // copy unmodi f ieab le−Tag−L i s t in a new ArrayLis t8 ArrayList<Tag> tags9 = new ArrayList<Tag>( se l ec tedElement . getTags ( ) ) ;

10

11 // i n s e r t Bundles12 s tartTagEditor . putExtra ( TagEditor .TAGS, tags ) ;13 s tartTagEditor . putExtra ( TagEditor .TYPE,14 se l ec tedElement . getName ( ) ) ;15 s tartTagEditor . putExtra ( TagEditor . OSM ID,16 se l ec tedElement . getOsmId ( ) ) ;17

18 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 beruhrten Stelle des Bildschirms abgefragt. InZeile 3 wird ein neuer Intent erzeugt, welcher anschließend mit den wichtigen Daten wiebisheriger Tags (12), Elementtyp (13), sowie der OSM-ID (15) versehen wird. Anschlie-

48

4.3 Implementation

ßend wird der Intent mit der Anfrage REQUEST EDIT TAG gestartet. Diese Anfrage-IDwird spater dazu verwendet, um das Ergebnis dieser Anfrage eindeutig zuordnen zukonnen.

Sobald die neue Activity das Ergebnis zuruckgeliefert hat, wird anhand der Anfrage-ID entschieden, wie das Ergebnis zu interpretieren ist (Listing 4.4)

1 @Override2 protected void onAct iv i tyResu l t ( f ina l int requestCode ,3 f ina l int resultCode , f ina l In tent data ) {4 super . onAct iv i tyResu 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 resu l tCode == RESULT OK && data != null ) {9 handleTagEditorResult ( data ) ;

10 }11 }

Listing 4.4: Main.onActivityResult(int,int,Intent)

1 @SuppressWarnings ( ”unchecked” )2 private void handleTagEditorResult ( f ina l In tent data ) {3 Bundle b = data . getExtras ( ) ;4 //Read data from ex t r a s5 ArrayList<Tag> tags6 = ( ArrayList<Tag>) b . g e t S e r i a l i z a b l e ( TagEditor .TAGS) ;7 St r ing 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 tTags ( 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, dieneuen Tags an die Logic-Klasse ubergeben (10) und ein Neu-Zeichnen der Map ange-stoßen (11). Bei der BoxPicker-Activity wird dazu analog verfahren.

Tracker: Abfrage der Geoposition

Die Android-Plattform hat das Ziel, die Benutzung der Hardwarefunktionalitat so ein-fach wie moglich zu gestalten. Ein Beispiel dafur ist die LocationListener-Schnittstelle.

49

4 Geodateneditor”Vespucci“

Die Implementation der vier vorgegebene Methoden23 sowie das einmalige Registrierenfur dieses Event (Listing 4.6) reichen vollkommen aus, um alle Updates der Geoposi-tion zu erhalten.

1 locat ionManager . requestLocat ionUpdates (2 LocationManager .GPS PROVIDER, //Anfrage an das GPS−Modul3 p r e f s . ge tGpsInterva l ( ) , //Update−Z e i t i n t e r v a l l4 p r e f s . getGpsDistance ( ) , //Update−D i s t a n z i n t e r v a l l5 this //Referenz auf d i e Locat ionLis tener−Implementation6 ) ;

Listing 4.6: Registrierung fur Location Updates in Tracker

4.3.3 User Interface (UI)

Gemaß der Analyse (Kap. 4.1.3) sollte bei der Oberflachengestaltung großen Wertauf Verstandlichkeit, Einfachheit und intuitive Benutzerfuhrung gelegt werden. In denfolgenden Abschnitten wird gezeigt, wie diese Anforderungen umgesetzt wurden:

Zuerst wird die Implementation der Menufuhrung erlautert, so dass anschließendauf die Modi-Anzeige eingegangen werden kann. Zuletzt wird ausfuhrlich erklart, wiedie Daten in der Map-Klasse gezeichnet werden.

Modi-Anzeige

Der geforderte Funktionsumfang24 beinhaltet die Auswahl verschiedener Modi. Diesewerden ihm im Menu durch aussagekraftige Icons und Titel deutlich vermittelt (Abb.4.8) Zusatzlich dazu sieht der Benutzer oben links in der Titelleiste das gleiche Icon

Abbildung 4.8: Icons im geoffneten Menu

als Information uber den aktuell ausgewahlten Modus (Abb. 4.9).

Menufuhrung

Das Hauptmenu in der Map ist in der Ressource /res/menu/main menu.xml definiert.Listing 4.7 zeigt den Eintrag im Menu fur den Move-Modus:

23onLocationChanged(Location), onProviderDisabled(String), onProviderEnabled(String)und onStatusChanged(String,int,Bundle) in android.location.LocationListener

24Siehe Kapitel 4.1.3 Funktionsumfang, Seite 30

50

4.3 Implementation

Abbildung 4.9: Modi-Anzeige in der Titelleiste

1 <item a n d r o i d : i d=”@+id /menu move”2 a n d r o i d : i c o n=”@drawable/menu move”3 a n d r o i d : t i t l e=” @str ing /menu move”4 andro id : a l phabe t i cSho r t cu t=”m”5 />

Listing 4.7: /res/menu/main menu.xml (Auszug)

Zuerst wird eine neue ID fur dieses Menu-Element erzeugt, welche unter dem Be-zeichner R.id.menu move im Code direkt adressierbar ist. In Zeile 2 wird das Icon fest-gelegt, das sich im Pfad /res/drawable/menu move.png befindet. Anschließend wirdder Titel aus der String-Ressource referenziert (3) und ein Shortcut fur die Tasten-kombination Menu+m festgelegt.

Beim Starten einer Activity wird die Methode Activity.onCreateOptionsMenu

(Menu) aufgerufen, die der Entwickler uberschreiben kann, um das Menu einzubinden:

1 @Override2 public boolean onCreateOptionsMenu ( f ina l Menu menu) {3 f ina l MenuInf later i n f l a t e r = getMenuIn f la te r ( ) ;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 Menu aus der Ressource geladen und als aktuelles Menu gesetzt. Ruck-gabewert ist true, da das Event zur Menuerzeugung behandelt wurde.

Map

Die Map-View ist verantwortlich fur das Zeichnen aller Daten. Diese View bekommtregelmaßige Updates von der Logic-Klasse uber die Position der viewBox, den aus-gewahlten Modus, sowie den OSM-Daten selbst.

51

4 Geodateneditor”Vespucci“

Kantenglattung (AntiAliasing) Android kann die Kantenglattung zur weicheren An-zeige von Kanten uber ein einfaches Flag in den Paints25 aktivieren. Wenn der Be-nutzer das AntiAliasing zur Beschleunigung der Anzeige abschalten mochte, werdenalle verwendeten Paints mittels Paint.setAntiAlias(false) fur die Kantenglattungdeaktiviert.

Zeichnen der Daten Das Zeichnen der Daten wird in der View.onDraw()-Methodeaufgerufen. Es wird uber jede Liste von Elementtypen iteriert und eine Element-spezifische Zeichenroutine ausgefuhrt.

Abbildung 4.10: Vespucci im Create-Modus

In der Abbildung 4.10 sind die gezeichneten Wege inklusiver Knoten und Toleranzenim Create-Modus angezeigt.

1 private void paintNode ( f ina l Canvas canvas , f ina l Node node ) {2 int l a t = node . getLat ( ) ;3 int l on = node . getLon ( ) ;4

5 //Paint on ly nodes i n s i d e the viewBox .6 i f ( viewBox . i s I n ( la 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 to l e r anc e c i r c l e .11 drawNodeTolerance ( canvas , node . ge tS ta t e ( ) , l a t , lon , x , y ) ;12

13 i f ( node == se lectedNode && isInEditZoomRange ) {14 canvas . drawPoint (x , y , pa in t s . get ( Paints .SELECTED NODE) ) ;

25siehe android.graphics.Paint,http://developer.android.com/reference/android/graphics/Paint.html

52

4.3 Implementation

15 } else {16 canvas . drawPoint (x , y , pa in t s . get ( Paints .NODE) ) ;17 }18 }19 }

Listing 4.9: Map.paintNode(Canvas,Node)

In Zeile 7f. werden die Geokoordinaten in Bildschirmkoordinaten umgerechnet. Wenndie Bedingungen fur die Toleranzanzeige gegeben sind, wird sie in Zeile 11 auf dieZeichenflache gemalt. Als letztes wird anhand einer Paint-Auswahl fur normale oderselektierte Knoten ein Punkt an der Stelle x,y auf die Zeichenflache (Canvas) gerendert.

4.3.4 Optimierungen

Bei der Entwicklung fur ein Handset muss die Performanz besonders beachtet werden.Aus diesem Grund wurden einige Mechanismen zur Optimierung entwickelt:

Als erstes wird die Wahl des Collection-Typs in der Datenstruktur erklart. Danachwird die Methode zum Zwischenspeichern des Mercator-Faktors aufgeschlusselt. Furdie Ubertragungen von und zum API-Server wird eine GZIP-Kompression verwendet,die im darauffolgenden Abschnitt gezeigt wird. Zuletzt wird dargelegt, warum sowohlbeim Rendern als auch im OSM-Datenmodell auf Elemente verzichtet wird, die furVespucci nicht relevant sind.

Collection-Typ in der Datenstruktur

Bei der Implementation der Datenstruktur musste eine Wahl des Collection-Datentypsfur die Menge von Elementen getroffen werden. Wie bereits bei der Evaluierung furpersistente Datenformate erwahnt (Kapitel 4.2.7), liegt der Performanz-Flaschenhalsbeim Zeichnen der Daten und somit bei der Zugriffszeit auf die Elemente. Nach Nafa-lin bieten die Datentypen ArrayList, HashMap eine konstante Zugriffszeit auf Objekteinnerhalb der Collection26. Da jedoch die Hash-Erzeugung nach Google sehr viel kos-tet27, wurde auf eine HashMap zugunsten der ArrayList verzichtet. Alle offentlichenMethoden haben in der Signatur den Abstrakten Datentyp List, um die Implementa-tion weitestgehend von den anderen Komponenten zu verbergen.

26Vgl. Naftalin, Maurice/Wadler, Philip: Java Generics and Collections. 1. Auflage. Sebastopol,CA: O’Reilly, 10 2006, S. 227,246.

27Vgl. Google, Inc.: Some Sample Performance Numbers. 〈URL:http://developer.android.com/guide/practices/design/performance.html#samples〉 – Zugriffam 17.02.2009.

53

4 Geodateneditor”Vespucci“

Caching des Mercator-Faktors

Der Mercator-Faktor ist der Faktor, der mit einer Breitenkoordinate multipliziert wird,damit sie nach der Mercator-Projektion richtig dargestellt wird. Bei jedem Zeichnender Daten muss er fur jeden Knoten neu berechnet werden.

Aufgrund des Berechnungsaufwands28 wird der Mercator-Faktor einmal fur den Mit-telpunkt einer viewBox berechnet und zwischengespeichert. Alle Koordinaten werdennun mit diesem Faktor multipliziert, anstatt exakt mit der Mercator-Formel 4.3 be-rechnet. Erst wenn die ViewBox verschoben wird, wird der Faktor korrigiert.

Somit haben zwar alle Knoten den gleichen Mercator-Faktor, jedoch ist der Unter-schied innerhalb eines Kartenausschnitts zu vernachlassigen. Die damit verbundeneminimal gestauchte Darstellung wird in Kauf genommen, um die Anzeige zu beschleu-nigen.

GZIP-komprimierte Ubertragung

Der Nachteil der Kommunikation uber XML-Daten ist der große Overhead, den diezeichenbasierte Daten bieten29. Um Zeit und Kosten fur den Anwender durch denendstehenden Datentransfer zu sparen, sollten diese Faktoren so gering wie moglichgehalten werden. In Abschnitt 2.4.3 wurde bereits dargelegt, dass keine andere API-Version fur Vespucci in Frage kommt. Die einzige Moglichkeit zur Datenreduktionbesteht deshalb in der komprimierten Datenubertragung mittels GZIP. Listing 4.10zeigt die Implementation dafur:

1 HttpURLConnection con = ( HttpURLConnection ) u r l . openConnection ( ) ;2 boolean i sServerGzipEnabled = fa l se ;3

4 con . setRequestProperty ( ”Accept−Encoding” , ” gz ip ” ) ;5 i sServerGzipEnabled6 = ” gz ip ” . equa l s ( con . getHeaderFie ld ( ”Content−encoding ” ) ) ;7

8 i f ( i sServerGzipEnabled ) {9 return new GZIPInputStream ( con . getInputStream ( ) ) ;

10 } else {11 return con . getInputStream ( ) ;12 }

Listing 4.10: Ausschnitt: Server.getStreamForBox(BoundingBox)

28siehe Listing 4.1, util.GeoMath.latToMercator(double)29siehe Tabelle 2.4

54

4.3 Implementation

Zuerst wird die HttpURLConnection (Bestandteil des JDK) erzeugt (1), die fur dieDatenverbindung zustandig ist. Anschließend wird eine GZIP-kodierte Ubertragungangefordert(4). Diese Information wird im Kopf des HTTP-Pakets ubertragen. In Zeile5 wird uberpruft, ob der Server diese Kodierung unterstutzt. Ist dies der Fall, wirdder InputStream direkt an ein GZIPInputStream geleitet, welcher zuruckgegeben wird(6). Dieser InputStream stellt somit die unkomprimierten Daten bereit.

Auslassen von Knoten und Weg-Segmenten außerhalb des Kartenausschnitts

Normalerweise werden alle Daten uber die Zeichenroutinen auf das Canvas gemalt.Zwar ist es fur die Grafik-Engine von Android theoretisch moglich, das Rendern vonPunkten außerhalb der Zeichenflache auszulassen. Dennoch musste vorher fur jedenKnoten die Projektion von Geo- auf Bildschirmkoordinate berechnet werden.

Die Entscheidung, ob die Berechnung einer Knoten-Bildschirmposition notwendigist, kann uber vier einfache int-Vergleiche uberpruft werden:

1 public boolean i s I n ( f ina l int l a t , f ina l int l on ) {2 return l on >= l e f t && lon <= r i g h t && l a t >= bottom && l a t <= top ;3 }

Listing 4.11: BoundingBox.isIn(int,int)

Komplexer ist hingegen die Optimierung fur Weg-Segmente. In der Klasseosm.BoundingBox wurde deshalb die Methode intersects(int,int,int,int) (Lis-ting 4.12) implementiert, die die Uberprufung fur ein Segment zwischen zwei Punktenmit den Koordinaten (lat/lon), sowie (lat2/lon2 ) durchfuhrt. Sobald sich einer derPunkte innerhalb der ViewBox befindet, muss das Segment gezeichnet werden (3).Wenn beide Punkte außerhalb einer Grenze liegen, ist ein Schnitt von ViewBox undWeg-Segment nicht moglich (6). Trifft keine dieser Bedingungen zu, ist ein Schnittnicht auszuschließen, weshalb true zuruckgegeben wird (9).

1 public boolean i n t e r s e c t s ( f ina l int l a t , f ina l int lon ,2 f ina l int l a t2 , f ina l int lon2 ) {3 i f ( i s I n ( la t , lon ) | | i s I n ( la t2 , lon2 ) ) {4 return true ;5 }6 i f ( n o I n t e r s e c t i o n P o s s i b l e ( l a t , lon , la t2 , lon2 ) ) {7 return fa l se ;8 }9 return true ;

10 }11

55

4 Geodateneditor”Vespucci“

12 private boolean n o I n t e r s e c t i o n P o s s i b l e ( f ina l int l a t , f ina l int lon ,13 f ina l int l a t2 , f ina l int lon2 ) {14 return15 l a t > top && l a t 2 > top | |16 l a t < bottom && l a t 2 < bottom | |17 l on > r i g h t && lon2 > r i g h t | |18 l on < l e f t && lon2 < l e f t ;19 }

Listing 4.12: BoundingBox.intersects(int,int,int,int)

Auslassungen im OSM-Datenmodell

Relationen Aufgrund der Analyse uber das Nutzungsverhalten und den Anforderun-gen an die Bedienbarkeit musste auf die Anzeige und Manipulation von Relationenverzichtet werden. Zum einen ist das System der Relationen nicht fur jeden Mapperleicht zu verstehen, zum anderen sind die Eingabe- und Ubersichtsmoglichkeiten aufdem mobilen Endgerat zu beschrankt, um auf geeignete Weise Relationen darzustellenoder gar zu verwalten.

”visible“-Flag Da die Abfrage an die API nur fur aktuelle Elemente erfolgt, ist das

visible-Flag nicht relevant. Es werden keine veralteten (und somit evtl. geloschten)Elemente abgerufen.

4.4 Potential

Fur die Entwicklung von Vespucci standen im Rahmen dieser Arbeit nur wenige Wo-chen zur Verfugung. Dieser Umstand fuhrte dazu, dass viele Potentiale aus Zeitgrundennicht genutzt werden konnten. Im folgenden Abschnitt soll das Potential von Vespuccifur die Weiterentwicklung unmittelbar nach Veroffentlichung dieser Arbeit verdeutlichwerden.

4.4.1 Weiterentwicklung als OpenSource-Projekt

Wie bei vielen anderen Programmen in der OpenStreetMap-Community soll auch Ves-pucci als OpenSource-Projekt weitergefuhrt werden. Durch kollaborative Zusammen-arbeit uber das Internet konnen Interessierte den Quellcode studieren und weiterent-wickeln.

56

4.4 Potential

Die Software wird im Anschluss an die Veroffentlichung dieser Arbeit unter derApache-Lizenz veroffentlicht. Alle Inhalte wie auch diese Arbeit selbst werden untereiner CC-Lizenz zuganglich gemacht, um den Benutzern die gleiche Rechte einzuraum-en, die die Entwicklung dieser Arbeit gefordert haben.

4.4.2 Verknupfung mit anderen Projekten

”AndNav“

AndNav ist ein Projekt zur Anzeige und zum Routing von OpenStreetMap-Daten aufder Android-Plattform. Teile des Projektes sind auch unter freien Lizenzen verfugbar,so dass Vespucci darauf zugreifen konnte.

MapView AndNav arbeitet daran, die Android-Klasse MapView von Google Mapszu losen und fur alle Arten von Kachel-basierten Grafiken verfugbar zu machen. Furdie Anwender von Vespucci ware es eine große Hilfe, wenn man die bisher gerendertenDaten als unteren Layer angezeigt bekommen kann. Auch eine Anzeige der Yahoo-Satellitenfotos ware ein wunschenswertes Szenario.

”Mapnik“-Renderer auf Android Desweiteren haben die Entwickler es geschafft, den

Renderer ”Mapnik“ auf Android zu portieren. Sollte die Rechenleistung des Hand-gerates ausreichen, konnte der Benutzer seine neu erstellten Daten innerhalb kurzesterZeit auf dem Gerat rendern lassen. So sieht er sofort, in welcher Weise seine Datendargestellt werden und kann diese ggf. korrigieren.

Daruber hinaus ist die Anzeige fur den Benutzer aussagekraftiger, als die bisherigeneinfachen Punkte und Linien auf dem Bildschirm. Ein zusatzlicher Vorteil ware dieveranderbaren Regelwerke zur Darstellung. Durch Mapnik hat der Benutzer die volleKontrolle, wie die Daten gerendert werden sollen. Dadurch kann er sich leichter aufbestimmte Themen, die er mappen mochte, spezialisieren (zum Beispiel OffentlicherPersonennahverkehr, Supermarkte, Parkanlagen, usw.).

4.4.3 Erweiterung des Funktionsumfangs

History- und Undo-Funktion

Es kommt immer wieder vor, dass Softwareanwender versehentlich falsche Eingabenmachen. Dieses Problem wird durch einen Touchscreen als Zeigegerat verstarkt, dader Benutzer erst nach der Beruhrung des Bildschirms festellen kann, wo genau dieBeruhrung stattgefunden hat. Hingegen kann der Benutzer bei einem Mauszeiger am

57

4 Geodateneditor”Vespucci“

Computer schon vorher sehen, wo sich der Mauszeiger befindet und erst anschließendden Klick ausfuhren.

Dieser Umstand verstarkt die dringende Notwendigkeit einer Undo-Funktion umFehleingaben revidieren zu konnen.

Auswahl bei Ubereinanderliegenden Knoten/Wegen

Wenn der Mapper einen Knoten oder einen Weg auswahlen mochte, der sich im Tole-ranzbereich eines anderen Knoten/Weg befindet, ist nicht definiert, welche der beidenElemente ausgewahlt werden. In Zukunft soll der Benutzer bei uneindeutigen Selek-tionen gefragt werden, welches der Elemente er auswahlen mochte.

Trennen von Wegen

Zwar kann Vespucci vorhandene Knoten loschen, aber eine Moglichkeit zur Trennungvorhandener Wege besteht derzeit noch nicht. Das ist insbesondere dann argerlich,wenn ein langer Weg erstellt wurde, der eigentlich in verschiedene Abschnitte unterteiltwerden musste.

Tag-Presets

Die Eingabe der Tags ist in der bisherigen Version von Vespucci recht aufwendig, dader Benutzer den vollen Namen der Tags ausschreiben muss. Desweiteren hat er keineUbersicht uber die gangigen Tags, welche von den Renderern angezeigt werden.

Um diese Nachteile auszuraumen, konnten zukunftige Versionen von Vespucci Tag-Presets enthalten. Diese werden als XML-Dateien gespeichert und der Benutzer konntesich die gangigen Tags selbst zusammenstellen. Innerhalb der OSM-Community wirdderzeit ein Standard entwickelt, mit dem die aktuellen Presets gespeichert und ausge-tauscht werden konnen30.

Umstellung auf zukunftige API-Version 0.6

Die Administratoren von OSM haben angekundigt, am 21./22. Marz 2009 auf dieneue API-Version 0.6 umzustellen31. Danach wird die aktuell verwendete Version 0.5nicht mehr unterstutzt. Damit Vespucci weiterhin zukunftsfahig bleibt, muss es an diekommende Version angepasst werden.

30Siehe: o.V.: Machine-readable Map Feature list. 〈URL: http://wiki.openstreetmap.org/index.php?title=Machine-readable_Map_Feature_list&oldid=214977〉 – Zugriff am 17.02.2009.

31Vgl. Coast, Steve: 0.6 move and downtime. 〈URL:http://www.mail-archive.com/talk@openstreetmap.org/msg12347.html〉 – Zugriff am 17.02.2009.

58

4.4 Potential

Kompass-Anzeige mit optionalier Auto-Rotation des Kartenausschnitts

Android bietet eine weitere Schnittstelle zur Erfassung eventuell verfugbarer Kompass-Daten. Diese konnten genutzt werden, um dem Mapper die aktuelle Himmelsrichtunganzuzeigen und – sofern der Benutzer dies wunscht – den Kartenausschnitt nach Nor-den rotieren zu lassen.

Canvas als Bitmap zwischenspeichern

Bisher werden bei Bewegungen des Bildausschnittes die Daten neu gezeichnet. Denkbarware es allerdings, die gerenderten Daten als Bitmap zwischenzuspeichern. Verschiebtder Nutzer den Kartenausschnitt, braucht nur das Bitmap verschoben zu werden. EineNeuberechnung der Koordinaten ist erst nach Veranderung der Daten notwendig.

Automatisiertes Nachladen und Synchronisation

In der aktuellen Version von Vespucci muss der Benutzer den gewunschten sichtbarenBereich manuell nachladen. Eine intelligente, permanente Synchronisation der Datensowie das automatische Nachladen bei Verschiebung der Karte ware durchaus einwunschenswertes Feature.

59

5 Ausblick

Am Schluss dieser Arbeit soll eine Zusammenfassung der Ergebnisse stehen. Außer-dem wird ein kleiner Blick in die Zukunft von OpenStreetMap, Android und Vespuccigewagt.

5.1 Zusammenfassung

5.1.1 Erfullung der Anforderungen

Wie bereits im vorigen Kapitel 4.4 ”Potential“ aufgezeigt, gibt es noch viele Funktio-nen und Anforderungen, die im Rahmen der Vorgaben fur diese Arbeit nicht fertig-gestellt werden konnten. Maßgeblich fur die Bewertung dieser Arbeit sind jedoch dieAnforderungen aus Kapitel 4.1.3:

”Einfache Bedienbarkeit“ ist ein Qualitatsmerkmal, welches nur schwer mit objek-tiven Metriken zu evaluieren ist. Der Feldversuch hat gezeigt, dass sich die Softwareauf dem Handset durchaus fur die Erstellung von einfachen Geodaten (Straßen, POI)eignet. Auf diversen Mapper-Treffen konnte daruber hinaus ein umfassendes Meinungs-bild uber Vespucci gesammelt werden. Teilnehmer des Projekts mit unterschiedlichs-tem Computerwissen haben sich fur das Programm ausgesprochen, wenngleich diefortgeschrittenen Benutzer die vielfaltigen Bearbeitungsoptionen an einem Desktop-PC bevorzugen.

Neben dem Aspekt der Bedienbarkeit wurde der Funktionsumfang inklusive allergewunschte Modi vollstandig umgesetzt. Vespucci stellt somit nicht nur einen Proto-typen dar, sondern eine fur den Alltagsgebrauch taugliche, voll einsatzfahige Software.

Da wahrend der Entwicklung Vespuccis die Android-Plattform erforscht und erlerntwerden musste, bestand keine Moglichkeit, Tests zu implementieren. Dafur ware esnotwendig gewesen, die komplette Funktionsweise uberschaut zu haben. Alle Projektefur Test-Driven-Development auf Android sind entweder nicht implementiert oder nochim Anfangsstadium der Entwicklung. Deshalb wurde auf einen Einsatz von TDD inVespucci verzichtet. Daruber hinaus bestand der Hauptfokus der Arbeit darin, ein

61

5 Ausblick

einsatzfahiges Programm zu erstellen. Bei Anwendung von TDD hatte ein Großteilder gewunschten Funktionalitat nicht umgesetzt werden konnen.

5.1.2 Vespucci im Feldversuch

Im Laufe dieser Arbeit wurde das Programm bereits ausfuhrlich auf seine Alltags-tauglichkeit hin getestet. An zwei Nachmittagen wurde die Ortschaft Hille in Ost-westfalen aufgesucht, fur die bis dahin nur sechs Straßen im Ortskern eingezeichnetwaren. Aufgabe war es, moglichst viele Straßen mit Vespucci zu kartografieren und aufOpenStreetMap zu veroffentlichen. Ziel war es auch, Fehler und Verbesserungspoten-tiale in der Software aufzuspuren. Diese sind hauptsachlich in Kapitel 4.4 ausfuhrlichdargestellt worden.

Abbildung 5.1: Feldversuch in Hille: Vorher (links) / nachher (rechts)

In der Abbildung 5.1 ist der erfolgreichen Einsatz von Vespucci sichtbar: Wahrendbis zum 22. Dezember 2008 nur wenige Straßen eingezeichnet waren, konnte innerhalbkurzester Zeit ein Großteil des Dorfkerns kartografiert werden.

62

5.2 Perspektive

5.2 Perspektive

5.2.1 OpenStreetMap

Trotz – oder geraden wegen – der großen Freiheiten die OpenStreetMap den Map-pern einraumt, hat das Projekt bereits erstaunliche Ergebnisse erziehlt. Die steigendenMitglieder- und Knotenzahlen zeigen deutlich, dass die Karte stetig verbessert werdenwird. Ahnlich wie bei Wikipedia werden im Laufe der Entwicklung jedoch vermehrtMechanismen gegen Vandalismus und fur die Qualitatssicherung gebraucht werden.Nur so lassen sich beispielsweise vertrauenswurdige Routing-Anwendungen mit OSM-Daten einsetzen.

5.2.2 Android

Die Android-Plattform ist ein wegweisendes Projekt fur die Smartphone-Hersteller:Es zeigt, dass es mit Hilfe freier Software und offenen Lizenzen moglich ist, in sichgeschlossene Insellosungen zu verringern und eine große Entwicklergemeinschaft zufordern. Das große Potential von Android liegt genau in diesem Fokus auf den Ent-wickler: Wird es ihm ermoglicht, schnell und einfach neue Applikationen zu program-mieren, steigert das direkt die Attraktivitat fur den Endverbraucher. Dank sinkenderGebuhren fur mobile Datendienste entsteht eine Vielzahl von Moglichkeiten, erweiterteDienste auf dem Handset anzubieten.

5.2.3 Vespucci

Unmittelbar nach Veroffentlichung dieser Arbeit wird Vespucci als OpenSource-Projektweitergefuhrt werden. Mit Hilfe anderer Programmierer aus der ganzen Welt ist esmoglich, die Software weiter zuentwickeln und die in Kapitel 4.4 aufgefuhrten Po-tentiale in kurzester Zeit umzusetzen. Aufgrund der freien Apache-Lizenz, sowie derModularisierung, wie sie in Kapitel 4.2 konzipiert wurde, ist es daruber hinaus moglich,die Logik-Komponenten fur andere Plattformen zu portieren.

Jeder Benutzer eines Android-Handsets kann mit diesem Programm seine Umgebungkartografieren. Vespucci ist ein unkompliziertes Werkzeug, mit dem jeder Mapper dieGeodaten direkt von seinem Standpunkt aus in die OpenStreetMap-Datenbank ein-pflegen kann.

Somit hilft Vespucci aktiv das Ziel des OpenStreetMap-Projekts zu erreichen: Eine

Weltkarte zu erstellen, die fur jeden frei zuganglich ist.

63

Doctype Definition (DTD)

1 <?xml version=” 1 .0 ” encoding=”UTF−8” ?>2 < !ELEMENT osm ( node | r e l a t i o n |way)*>3 < !ATTLIST osm version ( 0 . 5 ) #REQUIRED>4 < !ATTLIST osm genera tor CDATA #REQUIRED>5

6 < !ELEMENT node ( tag *)>7 < !ATTLIST node id CDATA #REQUIRED>8 < !ATTLIST node l a t CDATA #REQUIRED>9 < !ATTLIST node lon CDATA #REQUIRED>

10 < !ATTLIST node v i s i b l e CDATA #IMPLIED>11 < !ATTLIST node user CDATA #IMPLIED>12 < !ATTLIST node timestamp CDATA #IMPLIED>13

14 < !ELEMENT way ( tag * , nd , tag * , nd , ( tag | nd )* )>15 < !ATTLIST way id CDATA #REQUIRED>16 < !ATTLIST way v i s i b l e CDATA #IMPLIED>17 < !ATTLIST way user CDATA #IMPLIED>18 < !ATTLIST way timestamp CDATA #IMPLIED>19

20 < !ELEMENT nd EMPTY>21 < !ATTLIST nd r e f CDATA #REQUIRED>22

23 < !ELEMENT r e l a t i o n ( ( tag |member)+)>24 < !ATTLIST r e l a t i o n id CDATA #REQUIRED>25 < !ATTLIST r e l a t i o n v i s i b l e CDATA #IMPLIED>26 < !ATTLIST r e l a t i o n user CDATA #IMPLIED>27 < !ATTLIST r e l a t i o n timestamp CDATA #IMPLIED>28

29 < !ELEMENT member EMPTY>30 < !ATTLIST member type (way | node | r e l a t i o n ) #REQUIRED>31 < !ATTLIST member r e f CDATA #REQUIRED>32 < !ATTLIST member r o l e CDATA #IMPLIED>33

34 < !ELEMENT tag EMPTY>35 < !ATTLIST tag k CDATA #REQUIRED>36 < !ATTLIST tag v CDATA #REQUIRED>

i

UI-Konzept: Skizze

Abbildung .2: Skizze zum Oberflachenkonzept

ii

Rechtliche Hinweise

Markenrecht

Alle Firmen-, Marken- und Produktnamen sind – auch ohne entsprechende Kennzeich-nung – Eigentum der jeweiligen Rechteinhaber.

Copyleft dieses Dokuments

Diese Arbeit steht unter der Lizenz CC-BY-SA 3.0, die unter der Internetadres-se http://creativecommons.org/licenses/by-sa/3.0/de/legalcode vollstandig einsehbarist. Ausgenommen sind davon Bilder und Tabellen, die aus anderen Quellen ubernom-men wurden. Sie sind im Text als solche deklariert.

Softwarelizenz

Wie bereits im Kapitel 4.4.1 beschrieben steht die entstandene Software unter derApache Lizenz, welche unter http://www.apache.org/licenses/LICENSE-2.0 zu findenist. Weiterentwicklungen sind somit ausdrucklich erwunscht!

iii

Listings

2.1 Elementdefinition eines Knotens in der DTD . . . . . . . . . . . . . . 102.2 Elementdefinition eines Weges in der DTD . . . . . . . . . . . . . . . . 102.3 Elementdefinition einer Relation in der DTD . . . . . . . . . . . . . . 112.4 Elementdefinition eines Tags in der DTD . . . . . . . . . . . . . . . . 112.5 Definition des Wurzelelements in der DTD . . . . . . . . . . . . . . . . 142.6 Beispiel eines Bounds-Elements . . . . . . . . . . . . . . . . . . . . . . 143.1 Beispiel-Ressource /res/values/strings.xml . . . . . . . . . . . . . . . . 223.2 Eintrag in R-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3 Benutzung der Ressource . . . . . . . . . . . . . . . . . . . . . . . . . 224.1 util.GeoMath.latToMercator(double) . . . . . . . . . . . . . . . . . . . 444.2 Logic.createNodeOnWay(Node,Node,float,float) . . . . . . . . . . . . . 454.3 Main.MapTouchListener.performTagEdit(float,float) . . . . . . . . . . 484.4 Main.onActivityResult(int,int,Intent) . . . . . . . . . . . . . . . . . . . 494.5 Main.handleTagEditorResult(Intent) . . . . . . . . . . . . . . . . . . . 494.6 Registrierung fur Location Updates in Tracker . . . . . . . . . . . . . 504.7 /res/menu/main menu.xml (Auszug) . . . . . . . . . . . . . . . . . . . 514.8 Main.onCreateOptionsMenu(Menu) . . . . . . . . . . . . . . . . . . . . 514.9 Map.paintNode(Canvas,Node) . . . . . . . . . . . . . . . . . . . . . . . 524.10 Ausschnitt: Server.getStreamForBox(BoundingBox) . . . . . . . . . . . 544.11 BoundingBox.isIn(int,int) . . . . . . . . . . . . . . . . . . . . . . . . . 554.12 BoundingBox.intersects(int,int,int,int) . . . . . . . . . . . . . . . . . . 55

v

Tabellenverzeichnis

2.1 Auszug der Map Features fur Tags . . . . . . . . . . . . . . . . . . . . 122.2 HTTP-Befehle und Ressourcenpfade fur API-0.5 . . . . . . . . . . . . 152.3 HTTP Status-Codes der API 0.5 . . . . . . . . . . . . . . . . . . . . . 172.4 Vergleich verschiedener OSM-Protokolle . . . . . . . . . . . . . . . . . 17

3.1 Die Android-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . 20

vii

Abbildungsverzeichnis

2.1 OpenStreetMap Datenbankstatistik . . . . . . . . . . . . . . . . . . . . 52.2 OpenStreetMap Projektstruktur . . . . . . . . . . . . . . . . . . . . . 62.3 Knoten außerhalb der Bounds-Flache . . . . . . . . . . . . . . . . . . . 15

3.1 Activity Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 UML-Klassendiagramm der Datenstruktur . . . . . . . . . . . . . . . . 334.2 Schemenhafte Aufteilung der Storage-Komponenten . . . . . . . . . . 364.3 Anzeigesystem uber eine Position und Zoomfaktor (h) . . . . . . . . . 384.4 Das viewBox-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.5 Punktabstandsberechnung . . . . . . . . . . . . . . . . . . . . . . . . . 454.6 Klassendiagramm der LogicThreads . . . . . . . . . . . . . . . . . . . 464.7 Sequenzdiagramm fur Dialogerzeugung . . . . . . . . . . . . . . . . . . 474.8 Icons im geoffneten Menu . . . . . . . . . . . . . . . . . . . . . . . . . 504.9 Modi-Anzeige in der Titelleiste . . . . . . . . . . . . . . . . . . . . . . 514.10 Vespucci im Create-Modus . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.1 Feldversuch in Hille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Skizze zum Oberflachenkonzept . . . . . . . . . . . . . . . . . . . . . . ii

ix

Literaturverzeichnis

Benjamin Benz, Boi Feddern: Festplatte ade. c’t, 21 2007, S. 101ff 〈URL:http://www.heise.de/ct/07/21/100/〉

Benninger, Lukas: Agile Software Development. Februar 2003 〈URL: http://www.ifi.uzh.ch/richter/Classes/sem_cutting_edge/Summary_agile.pdf〉

Brunner, Kurt; Unverhau, Dagmar (Hrsg.): Kap. Kap. 8 InKartenverfalschung als Folge ubergrosser Geheimhaltung? 2. Auflage. LITVerlag Berlin-Hamburg-Munster, 2002, S. 167ff

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 25.02.2009

Clark, Andrew: Copying maps costs AA £20m. 〈URL:http://www.guardian.co.uk/uk/2001/mar/06/andrewclark〉 – Zugriff am23.02.2009

Coast, Steve: 0.6 move and downtime. 〈URL:http://www.mail-archive.com/talk@openstreetmap.org/msg12347.html〉 –Zugriff am 17.02.2009

Coast, Steve: Advice needed - dispute regarding names in Cyprus. 〈URL:http://lists.openstreetmap.org/pipermail/talk/2007-November/019731.html〉 – Zugriff am 16.02.2009

Collinson, Mike: The OpenStreetMap License. 〈URL:http://foundation.openstreetmap.org/the-openstreetmap-license/〉 –Zugriff am 16.02.2009

Franks, J. et al.: HTTP Authentication: Basic and Digest Access Authentication.Juni 1999 〈URL: http://www.faqs.org/rfcs/rfc2617.html〉

Gamma, Erich et al.: Kap. 4: ”Strukturmuster“. In Entwurfsmuster: Elementewiederverwendbarer objektorientierter Software. Pearson Education, 2004, S.239ff

Google, Inc.: Activity Lifecycle. 〈URL:http://developer.android.com/images/activity_lifecycle.png〉 –Zugriff am 16.02.2009

xi

Google, Inc.: Avoid Float. 〈URL: http://developer.android.com/guide/practices/design/performance.html#avoidfloat〉 – Zugriff am 20.02.2009

Google, Inc.: Designing for Performance. 〈URL: http://developer.android.com/guide/practices/design/performance.html#object_creation〉 – Zugriffam 17.02.2009

Google, Inc.: I can’t run a JUnit test class in Eclipse/ADT. 〈URL: http://code.google.com/intl/de-DE/android/kb/troubleshooting.html#addjunit〉 –Zugriff am 16.02.2009

Google, Inc.: Some Sample Performance Numbers. 〈URL: http://developer.android.com/guide/practices/design/performance.html#samples〉 –Zugriff am 17.02.2009

Google, Inc.: System Architecture. 〈URL:http://developer.android.com/images/system-architecture.jpg〉 –Zugriff am 16.02.2009

Guy, Romain: Avoiding Memory Leaks. 〈URL: http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html〉 – Zugriff am16.02.2009

Hoang, Youn-Ju Ko: Vermittlung von Visual Literacy durch Computeranimationim Kunstunterricht. Dissertation FU Berlin, 2000, 〈URL: http://www.diss.fu-berlin.de/diss/receive/FUDISS_thesis_000000000331〉

Konig, Peter: Freier Hamburger Straßenplan praktisch komplett. 〈URL:http://www.heise.de/newsticker/Freier-Hamburger-Strassenplan-praktisch-komplett--/meldung/117891〉 – Zugriff am 16.02.2009

Lev M. Bugayevskiy, John Parr Snyder: Kap. 2.1.2 In Map Projections. Taylor& Francis, 1995, S. 50

Matthey, Florian: Funktion zu ahnlich wie iTunes: Apple sperrt iPhone-AppPodcaster aus. 〈URL: http://www.macnews.de/news/111124.html〉 – Zugriffam 23.02.2009

Meier, Reto: Professional Android Application Development. 1. Auflage.Indianapolis, USA: Wiley Publishing, 2009

Naftalin, Maurice/Wadler, Philip: Java Generics and Collections. 1. Auflage.Sebastopol, CA: O’Reilly, 10 2006

OpenHandsetAlliance: Industry Leaders Announce Open Platform for MobileDevices. 〈URL:http://www.openhandsetalliance.com/press_110507.html〉 – Zugriff am17.02.2009

xii

OpenStreetMap: OpenStreetMap Statistics. 〈URL:http://www.openstreetmap.org/stats/data_stats.html〉 – Zugriff am16.02.2009

OpenStreetMap-Foundation: Finances. 〈URL:http://foundation.openstreetmap.org/finances/〉 – Zugriff am 19.02.2009

o.V.: Advice needed - dispute regarding names in Cyprus. 〈URL: http://lists.openstreetmap.org/pipermail/talk/2007-November/019713.html〉 –Zugriff am 16.02.2009

o.V.: Basic Methods for Object Access and Manipulation. 〈URL: http://wiki.openstreetmap.org/index.php?title=OSM_Protocol_Version_0.5&oldid=227425#Basic_Methods_for_Object_Access_and_Manipulation〉 –Zugriff am 25.02.2009

o.V.: Machine-readable Map Feature list. 〈URL:http://wiki.openstreetmap.org/index.php?title=Machine-readable_Map_Feature_list&oldid=214977〉 – Zugriff am 17.02.2009

o.V.: Map Features. 〈URL: http://wiki.openstreetmap.org/index.php?title=Map_Features&oldid=226512〉 – Zugriff am 16.02.2009

o.V.: Oberpfalz. 〈URL: http://wiki.openstreetmap.org/index.php?title=Oberpfalz&oldid=194032〉 –Zugriff am 16.02.2009

o.V.: OSM Mobile Binary Protocol. 〈URL: http://wiki.openstreetmap.org/index.php?title=OSM_Mobile_Binary_Protocol&oldid=206528〉 – Zugriffam 16.02.2009

Petern Konig, Holger Bleich: Auf dem GPS-Trip. c’t, 19 2008, S. 99

Ramm, Frederik et al.: XML Schema. 〈URL:http://www.nabble.com/XML-Schema-td20379824.html#a20379824〉 –Zugriff am 16.02.2009

Ramm, Frederik/Topf, Jochen: OpenStreetMap - Die freie Weltkarte nutzen undmitgestalten. 1. Auflage. Berlin: Lehmanns Media, 2008

Robinson, Andy: OpenStreetMap Database Statistics. 〈URL:http://wiki.openstreetmap.org/images/e/e3/Osmdbstats2.png〉 – Zugriffam 16.02.2009

Robinson, Andy: Percent of total user contributing. 〈URL:http://wiki.openstreetmap.org/images/archive/9/99/20090202092626!Osmdbstats8.png〉 – Zugriff am 16.02.2009

xiii

Smith, Phil: AndroidAnt - Build your Android application with ant.. without exec.〈URL: http://code.google.com/p/autoandroid/wiki/AndroidAnt〉 –Zugriff am 16.02.2009

SQLite: SQL Features That SQLite Does Not Implement. 〈URL:http://www.sqlite.org/omitted.html〉 – Zugriff am 17.02.2006

SQLite: Welcome. 〈URL: http://www.sqlite.org/〉 – Zugriff am 19.02.2009

Stauble, Markus: Ein bisschen Freiheit. iX, 5 2008, Nr. 5, S. 131ff

xiv

Eidesstattliche Erklarung

Ich erklare hiermit an Eides statt, dass ich die vorliegende Arbeit selbststandig undohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe; die ausfremden Quellen direkt oder indirekt ubernommenen Gedanken sind als solche kennt-lich gemacht. Die Arbeit wurde bisher in gleicher oder ahnlicher Form keiner anderenPrufungskommission vorgelegt und auch nicht veroffentlicht.

Ort, Datum Matthias Brandt