Fachhochschule Wedel
Fachbereich Medieninformatik




                           Bachelorthesis



                Vespucc...
Inhaltsverzeichnis

1 Einleitung                                                                                          ...
3.5.1   Standardm¨glichkeiten von Google . . . . . . . . . . . . . . . .
                             o                   ...
Abbildungsverzeichnis       ix

Literaturverzeichnis        xi

Eidesstattliche Erkl¨rung
                    a       xv
1 Einleitung

Zun¨chst wird im Problemkontext aufgezeigt, dass propriet¨re Geodaten und Smart-
   a                       ...
1 Einleitung


Bedeutung. Nach Brunner f¨hrt dies dazu, dass bis in die Gegenwart Kartenmaterial
                         ...
1.2 Zielsetzung dieser Arbeit


er Anwendungen programmieren kann. So hat zum Beispiel Apple erst auf ¨ffentli-
           ...
1 Einleitung


Namensgeber der entstandenen Applikation ist der Kartograf und Entdecker Amerigo
Vespucci7 , der aufgrund s...
2 Das OpenStreetMap-Projekt (OSM)

Wie bereits in der Einleitung (1.2.2) kurz vorgestellt, ist OpenStreetMap ein Projekt
z...
2 Das OpenStreetMap-Projekt (OSM)


    Die Abbildung 2.1 zeigt die kummulierte Anzahl von Wegen, Knoten und Rela-
tionen ...
2.2 Projektstruktur


Wiki-Seite7 , oder ggf. uber Tag-Presets, die der Editor bereitstellt. Die vom Mapper
              ...
2 Das OpenStreetMap-Projekt (OSM)


       Anschließend l¨d er die GPS-Daten auf einen Computer um dort mit Hilfe eines
  ...
2.3 Datenmodell


  Entscheidend ist, dass sich die Lizenz nur auf die Daten selbst bezieht. Ein Software,
die die Daten v...
2 Das OpenStreetMap-Projekt (OSM)


    Knoten

    Ein Knoten ist in erster Linie ein Punkt auf der Erde, beschrieben dur...
2.3 Datenmodell


 5   < !ATTLIST way timestamp C A A #
                               D T   IMPLIED>
 6

 7   < !ELEMENT ...
2 Das OpenStreetMap-Projekt (OSM)


     Jedes Element kann eine beliebig große Anzahl von Tag-Elementen haben. Bestimm-
t...
2.3 Datenmodell


  Die IDs werden bei der Erzeugung vom API-Server vergeben und dort verwaltet22 .
Der Benutzer hat erst ...
2 Das OpenStreetMap-Projekt (OSM)


    Osm

    Das Wurzelelement Osm beinhaltet ein optionales Bounds-Element, sowie ein...
2.4 Programmierschnittstelle ( API“)
                                                                                  ”

...
2 Das OpenStreetMap-Projekt (OSM)


Create   erzeugt uber den Ressourcenpfad ein neues Element. Die Definition erfolgt
    ...
2.4 Programmierschnittstelle ( API“)
                                                                             ”


   S...
2 Das OpenStreetMap-Projekt (OSM)


     Diese Formate sind allerdings nach Angaben der Entwickler ausschließlich f¨r den
...
3 Die Android-Plattform

Android ist eine Plattform des Konsortiums Open Handset Alliance“, zu der 47 Mit-
               ...
3 Die Android-Plattform


                                       Applications
           Home               Contacts      ...
3.2 Modell-View-Controller (MVC)-Muster


3.2.1 Vorteile
Folgende Vorteile ergeben sich aus diesem Muster:

Lesbarkeit Tex...
3 Die Android-Plattform


          ˆ Animationen (Uber XML definierte Animationen)
                         ¨
          ˆ ...
3.3 Interprozesskommunikation durch Intents


3.2.3 View: Views

Alle UI-Komponenten sind von der View-Klasse abgeleitet. ...
3 Die Android-Plattform


3.4 Applikationslebenszyklus
Eine Besonderheit der Android-Plattform ist der Lebenszyklus von Ap...
3.5 Automatisiertes Testen




                         Abbildung 3.1: Activity Lifecycle8


re spezifiziert, bevor er mit ...
3 Die Android-Plattform


ist. Dies f¨hrt dazu, dass im getesteten Code sowie im Testcode selbst keine Android-
          ...
3.5 Automatisiertes Testen


  AndroidAnt ist eine AntLib f¨r Ant, die die Erzeugung uber den Dalvik Cross-
              ...
4 Geodateneditor Vespucci“
                ”
Ziel dieser Arbeit ist die Entwicklung eines Geodateneditors f¨r das OpenStre...
4 Geodateneditor Vespucci“
                ”


     Dar¨ber hinaus ist ein Smartphone aufgrund der geringen Bildschirm- un...
4.1 Analyse


Anzeige der Daten Hat der Benutzer einen Bereich mit OSM-Daten geladen, so
sollen ihm die Geodaten maßstabsg...
4 Geodateneditor Vespucci“
                ”


TagEdit-Modus Der Benutzer kann uber diesen Modus ein Element selektieren. ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
"Vespucci": Entwicklung eines Geodateneditors f" ur das ...
Nächste SlideShare
Wird geladen in …5
×

"Vespucci": Entwicklung eines Geodateneditors f" ur das ...

3.396 Aufrufe

Veröffentlicht am

0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
3.396
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
1
Aktionen
Geteilt
0
Downloads
5
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

"Vespucci": Entwicklung eines Geodateneditors f" ur das ...

  1. 1. Fachhochschule Wedel Fachbereich Medieninformatik Bachelorthesis Vespucci“: ” Entwicklung eines Geodateneditors fur das ¨ OpenStreetMap-Projekt auf der Android-Plattform Eingereicht von: Matthias Brandt Talstraße 15, 20359 Hamburg, Tel: (040) 202 363 76 Abgegeben am: 3. M¨rz 2009 a Erarbeitet im: 7. Semester Referent: Betreuer: Prof. Dr. Andreas H¨uslein a Niels Linnemann Fachhochschule Wedel Blau Mobilfunk GmbH Feldstraße 143 Schulterblatt 124 22880 Wedel 20357 Hamburg Tel: (04103) 804 80-42 Tel: (040) 288 071-17
  2. 2. Inhaltsverzeichnis 1 Einleitung 1 1.1 Problemkontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1.1 Propriet¨re Geodaten . . . . . . . . . a . . . . . . . . . . . . . . 1 1.1.2 Propriet¨re Smartphone-Plattformen . a . . . . . . . . . . . . . . 2 1.1.3 Aufwand beim Erstellen von Geodaten . . . . . . . . . . . . . . 3 1.2 Zielsetzung dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1 Entwicklung eines Geodateneditors. . . . . . . . . . . . . . . . 3 ” 1.2.2 . . . f¨r das OpenStreetMap-Projekt. . . u . . . . . . . . . . . . . . 4 1.2.3 . . . auf der Android-Plattform“ . . . . . . . . . . . . . . . . . . 4 2 Das OpenStreetMap-Projekt (OSM) 5 2.1 Projektstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Projektstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1 Gleichberechtige Benutzer . . . . . . . . . . . . . . . . . . . . . 7 2.2.2 Bisheriges Benutzerverhalten . . . . . . . . . . . . . . . . . . . 7 2.2.3 Unabh¨ngigkeit . . . . . . . . . a . . . . . . . . . . . . . . . . . . 8 2.2.4 Lizenzmodell CC-BY-SA-2.0 . . . . . . . . . . . . . . . . . . . 8 2.3 Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1 Datenelemente . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2 Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.3 Metadaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.4 Aufbau einer OSM-XML-Datei . . . . . . . . . . . . . . . . . . 13 2.4 Programmierschnittstelle ( API“) . . . . . . . . . . . . . . . . . . . . . 14 ” 2.4.1 RESTful Design . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.2 API 0.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.3 OSM-Binary API . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3 Die Android-Plattform 19 3.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2 Modell-View-Controller (MVC)-Muster . . . . . . . . . . . . . . . . . . 20 3.2.1 Vorteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.2 Modell: XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.3 View: Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.4 Controller: Java-Klassen . . . . . . . . . . . . . . . . . . . . . . 23 3.3 Interprozesskommunikation durch Intents . . . . . . . . . . . . . . . . 23 3.4 Applikationslebenszyklus . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5 Automatisiertes Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
  3. 3. 3.5.1 Standardm¨glichkeiten von Google . . . . . . . . . . . . . . . . o 25 3.5.2 Automatisierte Tests mit Positron“ . . . . . . . . . . . . . . . 26 ” 3.5.3 Automatisierte Erzeugung mit AndroidAnt“ . . . . . . . . . . 26 ” 4 Geodateneditor Vespucci“ 29 ” 4.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1.1 Zielgruppendefinition . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1.2 Technische Rahmenbedingungen . . . . . . . . . . . . . . . . . 30 4.1.3 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2 Konzeption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.1 Datenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.2 UI-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2.3 Klassenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2.4 Schutz vor ungewollter Datenmanipulation . . . . . . . . . . . 36 4.2.5 viewBox-System . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.2.6 Parsen der XML-Daten . . . . . . . . . . . . . . . . . . . . . . 39 4.2.7 Vergleich der Datenhaltungsm¨glichkeiten . o . . . . . . . . . . . 40 4.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.3.1 Zahlenrepr¨sentation der Geokoordinaten . a . . . . . . . . . . . 42 4.3.2 Logik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.3.3 User Interface (UI) . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.3.4 Optimierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4 Potential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.4.1 Weiterentwicklung als OpenSource-Projekt . . . . . . . . . . . 56 4.4.2 Verkn¨pfung mit anderen Projekten . . . . u . . . . . . . . . . . 57 4.4.3 Erweiterung des Funktionsumfangs . . . . . . . . . . . . . . . . 57 5 Ausblick 61 5.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.1.1 Erf¨llung der Anforderungen u . . . . . . . . . . . . . . . . . . . 61 5.1.2 Vespucci im Feldversuch . . . . . . . . . . . . . . . . . . . . . . 62 5.2 Perspektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.2.1 OpenStreetMap . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.2.2 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.2.3 Vespucci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Doctype Definition (DTD) i UI-Konzept: Skizze ii Rechtliche Hinweise iii Listings v Tabellenverzeichnis vii
  4. 4. Abbildungsverzeichnis ix Literaturverzeichnis xi Eidesstattliche Erkl¨rung a xv
  5. 5. 1 Einleitung Zun¨chst wird im Problemkontext aufgezeigt, dass propriet¨re Geodaten und Smart- a a phone-Plattformen nicht f¨r das Allgemeinwohl zutr¨glich sind. Danach wird der Auf- u a wand f¨r das Sammeln von Geodaten verdeutlicht. Von dieser Situation ausgehend u wird anschließend die Zielsetzung dieser Arbeit beschrieben. 1.1 Problemkontext 1.1.1 Propriet¨re Geodaten a In der heutigen Wissensgesellschaft gewinnt das Wissen uber ortsbezogene Informatio- ¨ nen stetig an Bedeutung. Durch einen verst¨rkten Mobilisierungsgrad der Bev¨lkerung a o sind Menschen gezwungen, sich in ihnen unbekannten Gebieten zurecht zu finden oder den direkten Weg zu finden. Jedoch ist das Wissen uber ortsbezogene Daten nicht frei verf¨gbar1 . Bisher sind ¨ u Geodaten in signifikanter Menge nur gegen Geb¨hr bei Vermessungs¨mtern und ge- u a winnorientierten Unternehmen erh¨ltlich. Die daraus folgenden Konsequenzen sind: a Verwehrung der Wissensfreiheit: Menschen in strukturschwachen Regionen wird der freie Zugang zu Wissen versperrt. Zwar machen die Lizenzgeb¨hren f¨r Na- u u vigationsger¨te nur einen kleinen Teil des Kaufpreises aus und verhindern damit ober- a fl¨chlich betrachtet nur geringf¨gig den Zugang. Allerdings gibt es f¨r viele Entwick- a u u lungsl¨nder keine genauen Kartendaten, da es sich f¨r die Kartenhersteller aufgrund a u der geringen Kaufkraft nicht rentiert, dort detaillierte Geodaten zu erfassen. Lizenzabgaben: Hersteller von Navigationsger¨ten m¨ssen f¨r jedes Endger¨t Li- a u u a zenzgeb¨hren an die Kartenhersteller bezahlen. u Restriktionen: Privatpersonen ist es nicht gestattet, Kartenmaterial zu kopieren und beispielsweise auf Einladungen oder eigenen Webseiten zu ver¨ffentlichen. o Politische und milit¨rische Zensur: Seit Beginn der Kartografie sind Karten a nicht nur Orientierung f¨r Handel und Reisen, sondern insbesondere von milit¨rischer u a 1 Ausnahme bilden wenige L¨nder wie die USA, in denen alle Daten einer Beh¨rde automatisch a o Allgemeingut ( Public Domain“) werden. ” 1
  6. 6. 1 Einleitung Bedeutung. Nach Brunner f¨hrt dies dazu, dass bis in die Gegenwart Kartenmaterial u entweder zur¨ckgehalten wird, oder zur Desinformation verf¨lscht wird2 . u a Verf¨lschung: Clark belegt, dass Kartenhersteller absichtlich Straßendaten verf¨l- a a schen, um Kopien entlarven zu k¨nnen o 3. Ver¨nderungen, Anpassungen, Zusatzinformationen: Aufgrund propriet¨rer a a Datenformate und Restriktionen durch Lizenzbestimmungen ist es dem Benutzer in der Regel nicht m¨glich, Geodaten zu ver¨ndern oder neue hinzuzuf¨gen. So ist er o a u auf den Hersteller angewiesen, dass eine aktualisierte Version der Karte gegen erneute Geb¨hr angeboten wird. u 1.1.2 Propriet¨re Smartphone-Plattformen a Bisher waren nahzu alle Betriebssysteme und Plattformen f¨r Smartphones nur unter u propriet¨ren Lizenzen verf¨gbar. Dazu z¨hlen Windows Mobile (Microsoft), Black- a u a Berry (RIM), SymbianOS (Nokia) und seit Sommer 2007 Mac OS X in abgewandel- ter Form f¨r das iPhone (Apple). Durch das Geheimhalten des Quellcodes wird das u Betriebssystem f¨r Benutzer und Entwickler zu einer Blackbox: Niemand kann die u genauen Vorg¨nge im System beobachten und auf Sicherheitsl¨cken oder Hintert¨ren a u u hin uberpr¨fen. Auch eine Erweiterung des Systems um eine gew¨nschte Funktion ist ¨ u u ausgeschlossen. Wie bereits im vorigen Abschnitt 1.1.1 gezeigt erm¨glichen propriet¨re Formate o a eine Zensur seitens der Hersteller. Besonders hervorzuheben ist im Bereich der Smart- phones das Software-Vertriebsmodell des App-Store. Apple verbietet es dem Benutzer nicht durch den App-Store bezogene Fremdsoftware zu installieren. Jeder Entwickler, der sein Programm f¨r das iPhone vertreiben m¨chte, kann dies ausschließlich uber u o ¨ den App-Store erreichen. Er muss sich dazu f¨r eine j¨hrliche Geb¨hr von 99 USD u a u (bzw. 299 USD f¨r firmeninterne Anwendungen) registrieren und 30% seines Umsat- u zes an Apple abgeben4 . Matthey berichtet davon, dass, sollte das Programm nicht den Vorstellungen Apples gen¨gen oder in ¨hnlicher Weise bereits vorhanden sein, die u a Applikation abgelehnt wird5 . Wegen der Gefahr von Viren und anderen Schadprogrammen wird dem Entwick- ler von Drittsoftware oftmals nur ein kleiner Bereich im System zugewiesen, f¨r das u 2 Vgl. Brunner, Kurt; Unverhau, Dagmar (Hrsg.): Kap. Kap. 8 In Kartenverf¨lschung als Folge a ubergrosser Geheimhaltung? 2. Auflage. LIT Verlag Berlin-Hamburg-M¨nster, 2002, S. 167ff. ¨ u 3 Clark, Andrew: Copying maps costs AA £20m. URL: http://www.guardian.co.uk/uk/2001/mar/06/andrewclark – Zugriff am 23.02.2009. 4 Vgl. St¨uble, Markus: Ein bisschen Freiheit. iX, 5 2008, Nr. 5, S. 131ff. a 5 Vgl. Matthey, Florian: Funktion zu ¨hnlich wie iTunes: Apple sperrt iPhone-App Podcaster aus. a URL: http://www.macnews.de/news/111124.html – Zugriff am 23.02.2009. 2
  7. 7. 1.2 Zielsetzung dieser Arbeit er Anwendungen programmieren kann. So hat zum Beispiel Apple erst auf ¨ffentli- o chem Druck hin Entwicklern erm¨glicht, nicht nur spezialisierte Webapplikationen zu o schreiben, die uber den internen Browser benutzt werden k¨nnen6 , sondern auch native ¨ o Applikationen zu programmieren. 1.1.3 Aufwand beim Erstellen von Geodaten Sollte eine Privatperson sich dazu entschließen, ihr Wissen uber ihr bekannte Orte zu ¨ sammeln (im folgenden Mapper“ genannt), ben¨tigt diese ein Ger¨t zur Positions- o a ” bestimmung. Durch sinkende Preise und st¨ndige Weiterentwicklung sind heute GPS- a Empf¨nger auch f¨r Privatpersonen erschwinglich. Mit solch einem Ger¨t ausger¨stet a u a u kann ein Mapper die Orte aufsuchen und die gesammelten Koordinaten speichern. An- schließend ubertr¨gt er die Daten auf seinen Computer und verkn¨pft mit Hilfe eines ¨ a u Geodateneditors die gewonnenen Koordinaten mit dessen Wissen uber Straßennamen ¨ oder anderen Informationen. Nun hat der Anwender die M¨glichkeit, die Daten in o Rohform oder als Karte visualisiert f¨r Interessierte zu verbreiten. u Der Umstand, die Daten erst auf einen PC zu laden, sie dort zu bearbeiten und anschließend ins Internet hochzuladen nimmt – neben dem Sammeln der Daten selbst – die meiste Zeit in der Produktionskette in Anspruch. 1.2 Zielsetzung dieser Arbeit Im vorangehenden Abschnitt wurde dargelegt, welche Problematik geschlossene For- mate haben k¨nnen und wie hoch der Aufwand f¨r das Sammeln von Geodaten ist. o u Die Ziele dieser Arbeit werden nun anhand des Titels erl¨utert: a 1.2.1 Entwicklung eines Geodateneditors. . . ” Auf dem Markt f¨r Geoinformationssysteme und -editoren gibt es eine große Auswahl u an Software, die aufgrund der komplexen Thematik nicht intuitiv zu bedienen sind. Im Gegensatz dazu soll die innerhalb dieser Arbeit entwickelte Software selbst f¨r u unge¨bte Nutzer sofort verst¨ndlich sein. Der Benutzer sollte ohne zus¨tzliches GPS- u a a Ger¨t oder Notizblock Daten erstellen und ver¨ndern k¨nnen. Das wichtigste Ziel ist a a o jedoch, dass der Mapper einen Schritt in der Produktionskette spart: Das aufw¨ndige a Hochladen und Editieren am Computer. In Kapitel 4 wird ausf¨hrlich beschrieben, wie im Laufe dieser Arbeit der Geoda- u teneditor Vespucci“ durch Analyse, Konzeption und Implementation entstanden ist. ” 6 Vgl. St¨uble, Markus: Ein bisschen Freiheit. iX, 5 2008, Nr. 5, S. 131ff. a 3
  8. 8. 1 Einleitung Namensgeber der entstandenen Applikation ist der Kartograf und Entdecker Amerigo Vespucci7 , der aufgrund seiner Verdienste in der Kartografie ausgew¨hlt wurde. a 1.2.2 . . . f¨r das OpenStreetMap-Projekt. . . u 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 ver¨ndern und hinzuzuf¨gen, solange er sie unter der gleichen Lizenzbedingung a u weitergibt und auf OSM als Quelle verweist. Dadurch wird beispielsweise dem Groß- stadtbewohner erm¨glicht, neue Abk¨rzungen in die Karte einzutragen oder durch die o u Eintr¨ge anderer zu finden. Ein Inhaber einer KFZ-Werkstatt in Windhoek, Namibia, a kann auf seinen Werbeflyern eine Umgebungskarte kostenlos aufdrucken und verteilen. Auf OpenStreetMap, das benutzte Datenmodell und die Programmierschnittstelle des Projekts wird in Kapitel 2 n¨her eingegangen. a 1.2.3 . . . auf der Android-Plattform“ Android ist eine OpenSource-Handset-Plattform, die es jedem erm¨glicht, den Quell- o code einzusehen, zu ver¨ndern und weiterzugeben. Dar¨ber hinaus ist jede Applikation a u auf dem Ger¨t gleichberechtigt8 : Wenn der Benutzer mit der Adressbuch-Applikation a nicht zufrieden ist, kann er eine neue programmieren (lassen) und die alte ersetzen. Die Endger¨te k¨nnen GPS-Empf¨nger und 3D-Grafik-Chips¨tze beinhalten. Zus¨tz- a o a a a lich sind sie darauf ausgelegt, eine st¨ndige Internetverbindung aufrecht zu halten (je a nach Verf¨gbarkeit GPRS, EDGE, UMTS, WiFi). u Eine Zensur uber verf¨gbare Applikationen findet nicht statt: Das Installieren aus ¨ u anderen Quellen als des Plattform-eigenen Market“ ist gestattet und alleine die Be- ” nutzer entscheiden durch einen Bewertungsmechanismus uber die Qualit¨t der einge- ¨ a stellten Programme9 . In Kapitel 3 werden die Architektur sowie einige wichtige Details f¨r die Software- u entwicklung auf dieser Plattform n¨her beschrieben. a 7 Eigentlich Alberigo Vespucci (1451 – 1512). Der Kartograf Bernd Waldseem¨ller hat nach ihm u den Kontinent Amerika benannt. 8 Vgl. Meier, Reto: Professional Android Application Development. 1. Auflage. Indianapolis, USA: Wiley Publishing, 2009, S. 3. 9 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. 4
  9. 9. 2 Das OpenStreetMap-Projekt (OSM) Wie bereits in der Einleitung (1.2.2) kurz vorgestellt, ist OpenStreetMap ein Projekt zur Verbreitung freier Geoinformationen. Das Ziel dieses Projektes ist es, die erste freie Weltkarte zu erstellen. Jeder kann die Daten ver¨ndern, hinzuf¨gen oder l¨schen. a u o 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 1 OpenStreetMap: OpenStreetMap Statistics. URL: http://www.openstreetmap.org/stats/data_stats.html – Zugriff am 16.02.2009. 2 Vgl. Robinson, Andy: Percent of total user contributing. URL: http://wiki.openstreetmap.org/images/archive/9/99/20090202092626!Osmdbstats8.png – Zugriff am 16.02.2009. 3 Entnommen aus: Robinson, Andy: OpenStreetMap Database Statistics. URL: http://wiki.openstreetmap.org/images/e/e3/Osmdbstats2.png – Zugriff am 16.02.2009 5
  10. 10. 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- tens¨tze kontinuierlich an, so dass am Ende der Skala dreihundert Millionen Knoten a erreicht wurden. Doch nicht nur quantitativ, sondern auch qualitativ erreicht das Pro- jekt immer mehr Fortschritte: So teilte OpenStreetMap im Oktober 2008 mit, dass die Straßenkartierung von Hamburg praktisch abgeschlossen sei4 . Problematisch hingegen sind Regionen mit geringerer Einwohnerdichte. Da sich hier rechnerisch weniger OSM-Interessierte befinden, werden diese Gegenden kaum in der Datenbank von Mappern erfasst. Nach eigenen Angaben sind beispielsweise viele Orte in der Oberpfalz mit weniger als zehn Prozent der Straßen erfasst5 . 2.2 Projektstruktur Server DB (API) OpenStreetMap XML XML JOSM Mapnik Potlatch Editor Renderer Osmarenderer Merkaartor Kosmos Drittanbieter Vektordaten & Tags Kartenbilder Mapper gewöhnlicher Benutzer Anwender Abbildung 2.2: OpenStreetMap Projektstruktur Ein Mapper, der Daten f¨r OpenStreetMap bereitstellen m¨chte, f¨gt diese als Vek- u o u tordaten und Tags6 in einen Editor ein. Das Wissen, f¨r welche Informationen welche u Tags genutzt werden k¨nnen, sucht sich der Mapper entweder uber die entsprechende o ¨ 4 Vgl. K¨nig, Peter: Freier Hamburger Straßenplan praktisch komplett. URL: o http://www.heise.de/newsticker/Freier-Hamburger-Strassenplan-praktisch-komplett--/ meldung/117891 – Zugriff am 16.02.2009. 5 Vgl. o.V.: Oberpfalz. URL: http://wiki.openstreetmap.org/index.php?title=Oberpfalz&oldid=194032 – Zugriff am 16.02.2009. 6 siehe Kapitel 2.3.2 Tags, Seite 11 6
  11. 11. 2.2 Projektstruktur Wiki-Seite7 , oder ggf. uber Tag-Presets, die der Editor bereitstellt. Die vom Mapper ¨ erstellten Daten werden in einem XML-Format8 mittels HTTP an den Server ( API“) ” ubertragen. Dieser verwaltet alle Daten und legt sie in der Datenbank ab. Sowohl ¨ der Editor, als auch ein Renderer k¨nnen die vorhandenen Daten abfragen und nach o eigenen Regeln interpretieren. Ein Renderer hat in der Regel ein Regelset, aufgrund dessen die Tags interpretiert und als Bilder gerendert werden. Diese Bilder kann der gew¨hnliche Benutzer“ beispielsweise uber die Projektseite9 abrufen. o ¨ ” 2.2.1 Gleichberechtige Benutzer ¨ Ahnlich wie bei dem Enzyklop¨die-Projekt Wikipedia“ ist jeder Benutzer gleichbe- a ” rechtigt. Zwar f¨hrt das in wenigen F¨llen zu beabsichtigten oder unbeabsichtigten u a Falschinformationen, die jedoch durch die Masse der Benutzer aufgefangen wird. Da es sich bei den Daten von OpenStreetMap jedoch um objektiv eindeutig uberpr¨fbare In- ¨ u formationen handelt, sind sogenannte Editwars“, bei denen zwei Personen(gruppen) ” ¨ unterschiedlicher Meinung regelm¨ßig die Anderungen der anderen Gruppe wieder a zur¨cksetzen, kaum zu erwarten. u In vereinzelten F¨llen k¨nnen geografische Daten dennoch politische Ansichten wi- a o derspiegeln. Nach Coast war der Streit zwischen griechischen und t¨rkischen Mappern u auf Zypern im November 2007 der erste10 Konflikt dieser Art. Streitpunkt auf beiden Seiten war die Benennung der Orte und Straßen in der jeweiligen Landessprache11 . 2.2.2 Bisheriges Benutzerverhalten Ramm/Topf f¨hren die bislang einzigen zwei M¨glichkeiten zur Geodatenerfassung u o auf:12 1. Der Mapper besucht mit einem GPS-Empf¨nger ausger¨stet die Orte und Stra- a u ßen, die er erfassen m¨chte. Zus¨tzlich zu den GPS-Positionen werden beliebige o a ortsbezogenen Informationen, wie z.B. Straßennamen oder Briefk¨sten, gesam- a melt. 7 F¨r Deutschland: http://wiki.openstreetmap.org/index.php/DE:Map Features u 8 siehe Kapitel 2.3 Datenmodell, Seite 9 9 http://www.openstreetmap.org 10 Vgl. 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. 11 Vgl. 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. 12 Vgl. Ramm, Frederik/Topf, Jochen: OpenStreetMap - Die freie Weltkarte nutzen und mitgestalten. 1. Auflage. Berlin: Lehmanns Media, 2008, S. 31-40. 7
  12. 12. 2 Das OpenStreetMap-Projekt (OSM) Anschließend l¨d er die GPS-Daten auf einen Computer um dort mit Hilfe eines a Editors die Rohdaten als Vektordaten abzuzeichnen. Die gesammelten Informa- tionen werden anhand der Map Features“ eingegeben und mit Koordinaten ” verkn¨pft. Zuletzt werden alle Daten auf den OSM-Server geladen. u 2. Yahoo hat OpenStreetMap gestattet, seine Satellitenfotos zum Abzeichnen zu benutzen. In manchen Editoren l¨sst sich das Kartenmaterial anzeigen, so dass a es 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 die ¨ Kartendaten, sondern nur auf die Satellitenbilder bezieht. 2.2.3 Unabh¨ngigkeit a Der Großteil der Infrastruktur wird in Großbritannien von der OpenStreetMap Foun- ” ¨ dation“ (UK Registered Limited) betrieben. Uber diese Organisation kann sich das Projekt als juristische Person nach außen repr¨sentieren und ist unabh¨ngig von a a großen Konzernen. Jeder in der Gemeinschaft kann sich in Verantwortungspositionen der Foundation w¨hlen lassen und ein Mitbestimmungsrecht innerhalb des Vereins a aus¨ben. Eine Mitgliedschaft ist allerdings keine Vorraussetzung f¨r die Mitarbeit im u u Projekt. Die Foundation finanziert sich haupts¨chlich durch Spenden und Sponsoren, aber a auch durch die Einnahmen von Veranstaltungs- und Mitgliedschaftsgeb¨hren. Nach u eigenen Angaben wird das Geld haupts¨chlich f¨r Infrastruktur, aber auch f¨r An- a u u 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 f¨r Kreative bereitzustellen. Die Lizenzen sollen es den u Urhebern erm¨glichen, nach einem Baukastenprinzip eine gew¨nschte Weiternutzung o u zu gestatten oder zu untersagen. Die Lizenz Attribution-Share Alike 2.0“ sieht vor, dass jeder Benutzer das Recht ” hat, das Werk zu kopieren, zu verbreiten und zu ver¨ndern. Dabei muss darauf geachtet a werden, 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 propriet¨rer Lizenz vertrieben werden k¨nnen. a o 13 OpenStreetMap-Foundation: Finances. URL: http://foundation.openstreetmap.org/finances/ – Zugriff am 19.02.2009. 8
  13. 13. 2.3 Datenmodell Entscheidend ist, dass sich die Lizenz nur auf die Daten selbst bezieht. Ein Software, die die Daten verwendet, darf unter propriet¨rer Lizenz vertrieben werden, solange sie a auf die Quelle der Daten verweist und die aus OSM abgeleiteten Daten wieder unter der selben Lizenz verf¨gbar macht. u Dar¨ber hinaus schließt die Lizenz eine kommerzielle Nutzung nicht aus. Ein An- u bieter darf durchaus die Daten kommerziell verbreiten, solange er die Namensnennung beachtet und die Daten unter der gleichen Lizenz zur Verf¨gung stellt. u 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 an ” kreativ Schaffende und nicht an faktische Datenbankwerke. Nach Ramm/Topf ist nicht eindeutig gekl¨rt, ob sich die Lizenz uberhaupt f¨r OpenStreetMap anwenden ließe, a ¨ u da in vielen L¨ndern faktische Daten nicht schutzw¨rdig sind14 . Derzeit entwickelt die a u OpenStreetMap Foundation ein spezielles Lizenzformat, welches sich insbesondere an die Bed¨rfnisse einer offenen Datenbank richtet15 . u 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 erl¨utert. a Grundlage des Datenmodells ist die DTD-Spezifikation, welche im Anhang auf Seite i zu finden ist. Sollte trotz langer Erprobung ein Fehler im Datenmodell festgestellt werden, weisen die Administratoren darauf hin, dass in diesem Fall die Spezifikation ge¨ndert wird und nicht der Server selbst16 . a 2.3.1 Datenelemente In OpenStreetMap gibt es lediglich drei verschiedene Elemente: Knoten, Wege und Relationen. Jedes dieser Elemente enth¨lt beliebig viele Schl¨ssel-Wert-Paare zur ge- a u naueren Beschreibung der Information (siehe Tags, 2.3.2), sowie weitere Metadaten (2.3.3). 14 Vgl. Ramm, Frederik/Topf, Jochen: OpenStreetMap - Die freie Weltkarte nutzen und mitgestalten. 1. Auflage. Berlin: Lehmanns Media, 2008, 165. 15 Vgl. Collinson, Mike: The OpenStreetMap License. URL: http://foundation.openstreetmap.org/the-openstreetmap-license/ – Zugriff am 16.02.2009. 16 Vgl. Ramm, Frederik et al.: XML Schema. URL: http://www.nabble.com/XML-Schema-td20379824.html#a20379824 – Zugriff am 16.02.2009. 9
  14. 14. 2 Das OpenStreetMap-Projekt (OSM) Knoten Ein Knoten ist in erster Linie ein Punkt auf der Erde, beschrieben durch Breitengrad (Latitude, kurz: lat) und L¨ngengrad (Longitude, kurz: lon). Dieser Punkt kann f¨r a u sich alleine eine Information darstellen oder zusammen mit weiteren Punkten den Verlauf eines Weges beschreiben. 1 < !ELEMENT node ( t a g * )> 2 < !ATTLIST node id C A A# D T REQUIRED > 3 < !ATTLIST node lat C A A# D T REQUIRED > 4 < !ATTLIST node lon C A A# D T REQUIRED > 5 < !ATTLIST node visible C A A# D T IMPLIED> 6 < !ATTLIST node user C A A# D T IMPLIED> 7 < !ATTLIST node timestamp C A A# D T IMPLIED> Listing 2.1: Elementdefinition eines Knotens in der DTD Knoten sind die einzigen Elemente, die Geokoordinaten enthalten. Die Koordinaten werden im Dezimalformat in den Grenzen von ±90, 0 (lat) und ±180, 0 (lon) mit maximal sieben Nachkommastellen angegeben. Die Ungenauigkeit liegt bei maximal 63,5 cm17 . Das derzeit f¨r den Privatgebrauch g¨ngige GPS-System enth¨lt hingegen u a a eine Ungenauigkeit von mehreren Metern18 . Aufgrund der mangelnde Pr¨zision des a GPS-Systems ist die Ungenauigkeit in der Quantisierung vernachl¨ssigbar. a 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 Knoten beschreiben die Richtung des Vektorpfads. Der Begriff Weg ( Way“) ist jedoch ir- ” ref¨hrend, da dieses Element nicht nur Wege oder Straßen beschreibt, sondern alles, u was sich als Linie oder Fl¨che darstellen l¨sst. a a Ein geschlossener Weg (der erste und letzte Knoten haben die gleiche ID) wird dann zu einer Fl¨che, wenn ein Tag f¨r diesen Weg benutzt wird, welches f¨r Fl¨chen a u u a vorgesehen ist. 1 < !ELEMENT way ( t a g * , nd , t a g * , nd , ( t a g | nd ) * )> 2 < !ATTLIST way id C A A# D T REQUIRED > 3 < !ATTLIST way visible C A A# D T IMPLIED > 4 < !ATTLIST way user C A A# D T IMPLIED > 17 ¨ Bei einem angenommenen Erdradius r = 6356752m am Aquator und einem Winkel α = 0, 999E −7 betr¨gt der Kreisbogen b = 0, 635039556m (b = r · α) a 18 Vgl. Petern K¨nig, Holger Bleich: Auf dem GPS-Trip. c’t, 19 2008, S. 99. o 10
  15. 15. 2.3 Datenmodell 5 < !ATTLIST way timestamp C A A # D T IMPLIED> 6 7 < !ELEMENT nd E P Y MT> 8 < !ATTLIST nd r e f C A A# D T 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 k¨nnen z.B. Abschnitte ¨ o von Stadtteilgrenzen in einer ubergeordneten Relation zusammengefasst werden und ¨ somit die gesamte Stadtgrenze definieren. Der Grenzabschnitt einer Stadtteilgrenze wird damit gleichzeitig auch zur Stadtgrenze. Dadurch wird vermieden, die gleichen Geokoordinaten f¨r unterschiedliche Informationen redundant abzuspeichern. u 1 < !ELEMENT relation ( ( t a g | member)+)> 2 < !ATTLIST relation id C A A# D T REQUIRED > 3 < !ATTLIST relation visible C A A# D T IMPLIED> 4 < !ATTLIST relation user C A A# D T IMPLIED> 5 < !ATTLIST relation timestamp C A A # D T IMPLIED> 6 7 < !ELEMENT member E PY MT> 8 < !ATTLIST member type ( way | node | r e l a t i o n ) #REQUIRED> 9 < !ATTLIST member ref C A A # D T REQUIRED > 10 < !ATTLIST member role C A A # D T 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 Schl¨ssel-Wert-Paar zur Beschreibung der Information, welche ein u Element repr¨sentiert. Das Attribut k steht f¨r Key und v f¨r Value. a u u 1 < !ELEMENT t a g E P Y MT> 2 < !ATTLIST t a g k C A A# D T REQUIRED> 3 < !ATTLIST t a g v C A A# D T REQUIRED> Listing 2.4: Elementdefinition eines Tags in der DTD 11
  16. 16. 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 gebr¨uchlich. a ” So kann ein Tag oneway=yes19 nur dann sinnvoll f¨r ein Weg-Element gesetzt werden, u wenn es auch einen highway=*-Tag besitzt. Die Beispieltabelle 2.1 veranschaulicht die Verwendungsm¨glichkeiten von Tags: o Key Value Bedeutung Anwendbar f¨r u highway residential Wohnstraße Wege amenity bank Bank, Geldinstitut Knoten amenity parking Parkplatz Knoten, Fl¨chen a landuse cemetry Friedhof Fl¨chen a Tabelle 2.1: Auszug der Map Features f¨r Tags20 u OpenStreetMap legt sehr viel Wert darauf, den Benutzern nicht vorzuschreiben, auf welche Art und Weise sie ihre Daten einzupflegen haben. So kann ein Benutzer eine Straße beispielsweise als Straße=Autobahn definieren. Jedoch hat dieser keinen Vorteil davon, da h¨chstwahrscheinlich kein Renderer seine Straße als solche, geschweige denn o als Autobahn erkennen wird und somit auch nicht auf einer Karte anzeigen wird. ¨ Im OSM-Wiki gibt es die Seite Map Features“ 21 , welche ein Ubereinkommen f¨r u ” die meisten Tags auflistet. Auch wenn diese Seite keine Vorschrift darstellt, wird je- dem Mapper empfohlen, sich m¨glichst nach dieser zu richten, um eine bestm¨gliche o o Verwendung seiner Daten zu garantieren. 2.3.3 Metadaten ID Jedes Element besitzt eine ID. Diese ist jedoch nicht global eindeutig, sondern nur innerhalb ihres Elementtyps. Das bedeutet, dass zwei Elemente unterschiedlichen Typs die gleiche ID haben k¨nnen. Alle Elemente des gleichen Datentyps haben eindeutige o IDs. Bei einer Referenzierung uber eine ID muss zus¨tzlich gekl¨rt sein, um welchen ¨ a a Elementtyp es sich handelt. Bei der Referenzierung von Wegknoten kann nur die ID eines Knoten angegeben werden. Bei den Member-Referenzen wird uber das Attribut ¨ type festgelegt, auf welchen Elementtyp sich die Referenz bezieht. 19 Zur besseren Lesbarkeit werden Tag-Elemente in der Form key=value angegeben. 20 Auszug aus: o.V.: Map Features. URL: http://wiki.openstreetmap.org/index.php?title=Map_Features&oldid=226512 – Zugriff am 16.02.2009 21 http://wiki.openstreetmap.org/index.php/DE:Map Features 12
  17. 17. 2.3 Datenmodell Die IDs werden bei der Erzeugung vom API-Server vergeben und dort verwaltet22 . Der Benutzer hat erst dann die M¨glichkeit, die zuk¨nftige ID zu bestimmen, nachdem o u das 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 Ver¨nderung a eines referenzierten Elementes wirkt sich nicht auf den Zeitstempel des referenzieren- den Elementes aus. Dies tritt nur bei Ver¨nderungen in der Referenzliste oder der a ¨ Tag-Liste selbst ein. Zeitgebend ist die Ubertragung auf den OSM-Server, nicht die Erstellung in einem Editor. Username Jeder Mapper muss sich mit einem Benutzernamen und Passwort beim Server au- thentifizieren, um Daten bearbeiten zu k¨nnen. In jedem Element wird der Name des o ¨ Benutzers der letzten Anderung festgehalten. Die Anmeldung ist kostenlos und f¨r u jeden verf¨gbar24 . u Visible Visible ist ein Bin¨rattribut, welches die Werte true oder false annehmen kann. a Ausschließlich gel¨schte Elemente, welche uber die History der API abgefragt werden o ¨ k¨nnen, besitzen den Wert false. o 2.3.4 Aufbau einer OSM-XML-Datei Der Austausch von Daten erfolgt uber die in Teilen schon diskutierte DTD. Sie enth¨lt ¨ a noch weitere Felder, die f¨r den Empf¨nger von Bedeutung sein k¨nnen, aber f¨r die u a o u Datenstruktur nicht direkt relevant sind: Osm und Bounds. 22 Siehe Kap. 2.4.2, Create 23 YYYY::=vierstellige Jahreszahl MM::=zweistellige Monatzzahl im Jahr DD::=zweistellige Tageszahl im Monat HH::=zweistellige Stunde im 24h-Format MM::=zweistellige Minute SS::=zweistellige Sekunde o::= + | - (Richtung der Zeitverschiebung) hh::=zweistellige Stunde der Zeitverschiebung im 24h-Format mm=zweistellige Minute der Zeitverschiebung 24 http://www.openstreetmap.org/user/new 13
  18. 18. 2 Das OpenStreetMap-Projekt (OSM) Osm Das Wurzelelement Osm beinhaltet ein optionales Bounds-Element, sowie eine Liste von allen Knoten, Wege und Relationen. Das Attribut version steht f¨r die API- u 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 zum Server gespeichert und ist nicht uber die API zug¨nglich. Sie dient dazu, fehlerhafte ¨ a Eingaben von defekten Editoren besser identifizieren zu k¨nnen. o 1 < !ELEMENT osm ( node | r e l a t i o n | way ) *> 2 < !ATTLIST osm version (0.5) # REQUIRED> 3 < !ATTLIST osm g e n e r a t o r C A A # D T REQUIRED > Listing 2.5: Definition des Wurzelelements in der DTD Bounds Obwohl das Bounds-Element nicht in der DTD erw¨hnt wird, schreibt der Server ein a solches Element in die XML-Datei. 1 <bounds m i n l a t=” 5 3 . 5 5 ” minlon=” 9 . 9 3 7 5 ” 2 maxlat=” 5 3 . 5 7 ” maxlon=” 9 . 9 8 2 ” /> Listing 2.6: Beispiel eines Bounds-Elements Wie die Bezeichner der Attribute schon andeuten, werden dadurch die ¨ußeren Grenzen a eines Bereichs festgelegt. Das ist notwendig, da ein Weg samt der referenzierten Knoten aus diesem Bereich herausragen kann. Liegt ein Knoten außerhalb von Bounds, kann er von anderen Wegen referenziert werden, die sich nicht in Bounds befinden (Abbildung 2.3). Das verarbeitende Programm muss also darauf achten, dass die Knoten außerhalb des Bereichs nicht ver¨ndert werden, da es sonst unbeabsichtigte Folgen f¨r andere a u referenzierende Elemente haben kann. 2.4 Programmierschnittstelle ( API“) ” Eine API ( application programming interface“) ist eine Programmierschnittstelle, die ” es einem Entwickler erm¨glicht, Funktionalit¨ten einer fremden Software oder eines o a Dienstes f¨r sein Programm zu nutzen. OpenStreetMap stellt eine st¨ndig weiterentwi- u a ckelte API zur Verf¨gung, mit deren Hilfe jedes Programm mittels HTTP-Befehle und u Austausch von OSM-XML-Datein aktuelle Daten in die Datenbank speichern lassen kann oder aktuelle wie archivierte Daten herauslesen kann. 14
  19. 19. 2.4 Programmierschnittstelle ( API“) ” Geladener Way Bounds-Fläche Äußere Fläche Nicht-geladener Way / Nodes Abbildung 2.3: Knoten außerhalb der Bounds-Fl¨che a 2.4.1 RESTful Design REST (Representational State Transfer) beschreibt einen Architekturstil f¨r Inter- u netdienste. Es verfolgt ein striktes Client-Server-Modell, in dem der Client uber eine ¨ URL eine Ressource anspricht und uber HTTP-Befehle beschreibt, was mit dieser Res- ¨ source getan werden soll. REST ist wie HTTP zustandslos, so dass jede Transaktion in sich verstanden werden kann und nicht von vorherigen Zust¨nden abh¨ngig ist. a a 2.4.2 API 0.5 Die Version 0.5 ist die derzeit25 aktuelle API-Version von OpenStreetMap. Die Tabelle 2.2 listet die vier m¨glichen CRUD-Operationen (Create, Retrieve, Update, Delete) o auf: CRUD HTTP-Befehl Ressourcenpfad Create PUT /api/0.5/{Elementtyp}/create Retrieve GET /api/0.5/{Elementtyp}/{id} /api/0.5/map?bbox={minlon},{minlat},{maxlon},{maxlat} Update PUT /api/0.5/{Elementtyp}/{id} Delete DELETE /api/0.5/{Elementtyp}/{id} Tabelle 2.2: HTTP-Befehle und Ressourcenpfade f¨r API-0.526 u 25 Oktober 2007 – M¨rz 2009 a 26 Vgl. Ramm, Frederik/Topf, Jochen: OpenStreetMap - Die freie Weltkarte nutzen und mitgestalten. 1. Auflage. Berlin: Lehmanns Media, 2008, S. 176f 15
  20. 20. 2 Das OpenStreetMap-Projekt (OSM) Create erzeugt uber den Ressourcenpfad ein neues Element. Die Definition erfolgt ¨ als Payload von HTTP-PUT in Form einer validen XML-Datei. Als Antwort sendet der Server die generierte ID f¨r das erzeugte Element. u Retrieve holt entweder ein bestimmtes Element uber die ID, oder alle Elemente ¨ innerhalb eines Kartenausschnittes 27 . Eine Payload wird vom Client nicht ben¨tigt. o Die Antwort des Servers enth¨lt eine XML-Datei mit den angefragten Daten. a Update aktualisiert ein bestimmtes Element. Diese muss als Payload mit angegeben werden. Außer eines positiven Statuscodes gibt der Server nichts zur¨ck. u Delete l¨scht das im Resourcenpfad angegebene Element. Sowohl der Client als auch o der 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 Verschl¨sselung ¨ u ¨ darstellt. Die Kodierung ist injektiv, was einer Ubermittlung der Daten in Klartext entspricht. HTTP-Status-Codes Wird eine Anfrage erfolgreich vom Server bearbeitet, gibt dieser eine HTTP 200 (OK) Meldung zur¨ck. Sollte ein Problem bei der Verarbeitung aufgetreten sein, sind fol- u gende Statusmeldungen definiert: 2.4.3 OSM-Binary API Derzeit ist das OSM Binary Protocol“ in der Entwicklung. Es hat das Ziel, die Daten- ” gr¨ße zu reduzieren und durch Vermeidung des Klartext-Parsens die Verarbeitung zu o beschleunigen. Dies wird dadurch erreicht, dass Zahlenwerte direkt in einem Bin¨rfor- a mat abgelegt sind und ggf. h¨ufig auftretende Tags durch Enumerationen ersetzt wer- a den. Auch die Struktur selbst wird nicht mehr uber variable XML-Konstrukte be- ¨ schrieben, sondern direkt festgelegt. 27 Dar¨ber hinaus gibt es eine Reihe weiterer, spezieller Anfrage-Methoden, die f¨r diese Arbeit u u jedoch nicht von Relevanz sind. Siehe: http://wiki.openstreetmap.org/index.php/OSM Protocol Version 0.5 28 Siehe Franks, J. et al.: HTTP Authentication: Basic and Digest Access Authentication. Juni 1999 URL: http://www.faqs.org/rfcs/rfc2617.html . 16
  21. 21. 2.4 Programmierschnittstelle ( API“) ” Status-Code Bedeutung 400 Bad Request Die Payload entspricht nicht der Anfrage. Dies passiert bei- spielsweise, wenn in einer Update-Operation sich die ID in der XML-Datei von der ID im Ressourcenpfad unterscheidet. 401 Unauthorized Eine manipulative Operation wurde ohne (g¨ltige) Authen- u tifizierung versucht 404 Not found Das angefragte Element existiert nicht und hat noch nie exis- tiert. 405 Method not Der Ressourcenpfad f¨r Create wurde angegeben, aber kein u allowed HTTP-PUT Befehl. 410 Gone Das angefragte Element existierte, wurde aber mittlerweile gel¨scht. o 412 Precondition Die Operation w¨rde die referentielle Intigrit¨t zerst¨ren. u a o failed Beispiel: Ein Element soll gel¨scht werden, wird aber noch o von anderen Elementen referenziert. Dieser Status wird auch zur¨ckgegeben, wenn eine Create-Operation mit einer posi- u tiven ID innerhalb der XML-Daten ausgef¨hrt werden soll. u 500 Internal Ein interner Fehler ist aufgetreten. Server Error 503 Service Die Datenbank ist aus Wartungsgr¨nden nicht verf¨gbar. u u Unavailable Tabelle 2.3: HTTP Status-Codes der API 0.529 Ein Vergleich des OSM-Binary Protocols mit der Standard-API bez¨glich der er- u reichten Kompression f¨r einen Beispielbereich ist in Tabelle 2.4 zu finden. Die Kom- u pressionen gz“ und 7z“ beziehen sich auf eine Kompression bereits im HTTP- ” ” Datenstrom. Protokoll Gr¨ße o Kompressionsfaktor zus¨tzlich a OSM XML API 7260292 OSM 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 29 ¨ Ubersetzt 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.2009 29 o.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
  22. 22. 2 Das OpenStreetMap-Projekt (OSM) Diese Formate sind allerdings nach Angaben der Entwickler ausschließlich f¨r den u Lesezugriff gedacht und eignen sich nicht f¨r einen Editor. Sollte ein Editor diese u Bin¨rdaten interpretieren und anschließend uber das Standard-XML-Format wieder a ¨ an eine weitere Instanz weitergeben, so k¨nnen leicht durch unterschiedliche Bezugs- o quellen der Daten sowie durch Formatierungsfehler Inkonsistenzen auftreten. Da es sich bei dem OSM-Binary Protocol um Read-Only Protokoll handelt – also keine Daten auf dem Server manipuliert werden – entspricht es nicht den REST- Kriterien. 18
  23. 23. 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 Ger¨tehersteller angeh¨ren. Das Ziel dieses Zusammenschlusses namhafter Firmen a o wie Google, HTC, Intel oder Telef´nica ist, nach eigenen Angaben, offene Standards o f¨r mobile Endger¨te zu entwickeln1 . u a Android wurde von Google entwickelt, das im November 2007 eine erste Testversion des SDK (Software Development Kit) ver¨ffentlicht hat. Im September 2008 erschien o das erste SDK, welches zur sp¨teren 1.0-Version kompatibel ist. Mit dem Verkaufsstart a des ersten Endger¨ts T-Mobile G1“ (Hersteller: HTC) in den USA wurden die Quellen a ” von Android offengelegt2 und unter der freien Apache-Lizenz ver¨ffentlicht. Seitdem o hat jeder die M¨glichkeit, die Quelltexte zu studieren, zu vervielf¨ltigen, zu ver¨ndern o a a und wieder einzupflegen. 3.1 Architektur Die Android-Plattform l¨sst sich in vier verschiedene Ebenen aufteilen (Tabelle 3.1). a Als Grundlage des Systems liegt ein Linux Kernel (Version 2.6), welcher alle n¨ti- o gen Hardware-Treiber beinhaltet. Darauf setzen diverse Bibliotheken auf sowie die Android-Laufzeitumgebung. Diese beiden unteren Schichten sind komplett in C/C++ implementiert, so dass eine effiziente Verarbeitung gew¨hrleistet ist. Die dar¨ber lie- a u 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 f¨r den u Entwickler sichtbare Schicht darstellt: Die Schnittstellen und Methoden dieser Schicht kann der Programmierer direkt verwenden. Alle Anwendungen sind in der obersten Schicht repr¨sentiert. Wie bereits erw¨hnt a a unterscheidet das System nicht zwischen Android-Anwendungen und solchen von Drit- 1 OpenHandsetAlliance: Industry Leaders Announce Open Platform for Mobile Devices. URL: http://www.openhandsetalliance.com/press_110507.html – Zugriff am 17.02.2009. 2 http://source.android.com/ 19
  24. 24. 3 Die Android-Plattform Applications Home Contacts Phone ... Applikation Framework Activity Manager Window Manager Content Providers View System Package Manger Telephony Manger Resource Manager Location Manager Notification Manager Libraries Android Runtime Surface Manager Media Framework SQLite Core Libraries OpenGL/ES FreeType WebKit Dalvik VM SGL SSL libc Linux Kernel Display Driver Camera Driver Flash Memory Driver Binder (IPC) Driver Keypad Driver WiFi Driver Audio Drivers Power Management Tabelle 3.1: Die Android-Architektur3 tanbietern. So kann der Benutzer neue Programme installieren und vorhandene erset- zen. Die Dalvik Virtual Machine (Dalvik VM) wurde von Google selbst entwickelt und ist im Gegensatz zu Sun’s Java Virtual Machine eine Registermaschine, so dass die Dalvik VM einen effizienteren Zugriff auf die Speicheradressen liefert. Ein weiterer Vorteil dieser Vorgehensweise ist, dass die Hersteller keine Lizenzabgaben an Sun rich- ten m¨ssen. Der Nachteil besteht jedoch darin, dass normale“ Java-Kompilate nicht u ” auf der Dalvik VM ausf¨hrbar sind, und umgekehrt. Eine Plattformunabh¨ngigkeit ist u a somit 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, Pr¨sentation und Steuerung von einander zu kapseln. Das a Modell repr¨sentiert die Datenhaltung und deren Struktur. Die Pr¨sentation stellt die a a Oberfl¨che dar und definiert deren Aussehen. Die Steuerung steht f¨r die Logik einer a u Software und ist daf¨r verantwortlich, die Daten aus dem Modell in angebrachter Weise u der Pr¨sentation zur Verf¨gung zu stellen und Benutzereingaben aus der Pr¨sentation a u a wieder an das Modell weiterzugeben. 3 Google, Inc.: System Architecture. URL: http://developer.android.com/images/system-architecture.jpg – Zugriff am 16.02.2009 20
  25. 25. 3.2 Modell-View-Controller (MVC)-Muster 3.2.1 Vorteile Folgende Vorteile ergeben sich aus diesem Muster: Lesbarkeit Textausgaben oder Datenbankabfragen geh¨ren nach dem MVC-Modell o nicht in die Steuerung, sondern in die Pr¨sentation beziehungsweise in das Modell. a Dadurch wird eine bessere Lesbarkeit des Codes erreicht, da dieser nur noch f¨r die u Logik verantwortlich ist. Wartbarkeit Durch die Trennung der drei Schichten ist es m¨glich, einfacher auf die o gew¨nschten Ressourcen zuzugreifen und sie unabh¨ngig von den anderen Schichten u a zu aktualisieren. Wiederverwendbarkeit Die Daten und Oberfl¨chenrepr¨sentation sind unabh¨ngig a a a vom Logik-Programmcode. Dadurch l¨sst sich jede dieser Schichten in anderen Pro- a jekten wieder verwenden, ohne dass programmspezifische Bindungen beachtet werden m¨ssen. u Arbeitsteilung Ein weiterer Vorteil besteht darin, dass beispielsweise UI-Entwickler die Oberfl¨che gestalten k¨nnen, ohne die Logik des Programms vorliegen oder ver- a o standen zu haben. Internationalisierung Da Texte nun nicht mehr direkt im Quellcode eingebunden sind, k¨nnen diese leicht ausgetauscht werden, um das Programm f¨r andere Sprachen o u zu ver¨ffentlichen. o Umgebungsabh¨ngige Layouts a Es k¨nnen verschieden Layouts f¨r diverse Umge- o u bungen und Endger¨te entworfen werden. Das Programm ist somit nicht mehr an eine a bestimmte Umgebung gebunden. 3.2.2 Modell: XML Folgende Datentypen k¨nnen in XML-Dateien ( Ressourcen“) gespeichert werden und o ” sind somit unabh¨ngig vom Code: a ˆ Einfache Werte – Farben (RGB(A)-Werte) – Arrays (Integer und Strings) – Dimensionen (px, in, pt, mm, dp, sp) – Strings – Styles (Android-Styles f¨r Oberfl¨chen) u a ˆ Bilder (PNG, JPG, GIF) ˆ Layouts (Android-Layouts) 21
  26. 26. 3 Die Android-Plattform ˆ Animationen (Uber XML definierte Animationen) ¨ ˆ Andere Dateien – XML-Dateien (fremd-spezifizierte XML-Daten) – Raw-Dateien (Bin¨rdaten) a Diese Ressourcen werden als XML-Dateien in einer vorgegebenen Ordnerstruktur ab- gelegt und bereits zur Compilezeit eingelesen. Dabei legt ein Compiler die Daten in einem Bin¨rformat ab. Dieser erzeugt eine R-Klasse“ 4 , welche wiederum f¨r jeden a u ” Datentyp eine Subklasse mit Referenz-IDs f¨r die Ressourcen bereitstellt. Diese IDs u zeigen nicht auf die Ressource selbst, sondern auf einen Eintrag in der von Android verwaltete Ressourcen-Tabelle. Mit Hilfe der R-Klasse kann der Entwickler bereits zur Compilezeit die Adressierung der Ressource validieren. Listing 3.1 zeigt eine Beispiel- hafte Ressource f¨r Strings: u 1 <?xml version=” 1 . 0 ” e n c o d i n g=” u t f −8” ?> 2 <r e s o u r c e s> 3 <s t r i n g name=” h e l l o ”>H e l l o , 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 s t a t i c f i n a l c l a s s s t r i n g { 2 public s t a t i c f i n a l int h e l l o =0x 7 f 0 7 0 0 0 0 ; 3 } Listing 3.2: Eintrag in R-Klasse Diese ID kann in vielen von Android bereitgestellten Methoden direkt als Parameter ubergeben werden, oder selbst ausgelesen werden: ¨ 1 S t r i n g h e l l o = g e t S t r i n g (R. s t r i n g . h e l l o ) ; Listing 3.3: Benutzung der Ressource Da die Ressourcen bereits zur Compilezeit geparst werden und in ein internes, opti- miertes Format abgelegt werden, erfolgt der Zugriff auf die Werte bedeutend schneller, als wenn dies erst zur Laufzeit geschehen w¨rde. Ausgenommen davon sind Raw- und u XML-Dateien, welche uberhaupt nicht vorbearbeitet werden. In der aktuelle SDK- ¨ Version sind alle Ressourcen-Dateien auf eine Gr¨ße von 1 MByte beschr¨nkt. o a 4 Pfad: /src/R.java 22
  27. 27. 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 als ¨ auch uber XML-Ressourcen benutzen und anpassen kann. Nach M¨glichkeit sollte die- ¨ o ser Weg gew¨hlt werden, da hierdurch eine weitestgehende Trennung von Benutzero- a berfl¨che und Programmcode sichergestellt wird und die Komponenten vorkompiliert a sind. 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 vollst¨ndig umgesetzt. a 3.3 Interprozesskommunikation durch Intents Nach Meier sind Programme auf anderen Smartphone-Plattformen voneinander ent- koppelt und k¨nnen aufgrund von Sicherheitsrestriktionen nicht miteinander kommu- o nizieren5 . Bei Android hingegen wird sehr viel Wert auf Wiederverwendbarkeit gelegt. Programme k¨nnen durch sogenannte Intents6 miteinander kommunizieren und Funk- o tionalit¨ten f¨r andere Applikationen bereitstellen. Selbst das Starten von Activities a u wird durch Intents umgesetzt. Dieses Vorhaben kann an eine bestimmte Klasse gerich- tet werden (explizites Vorhaben), oder allgemein formuliert (implizites Vorhaben). Bei Letzterem wird anstatt eines konkreten Klassennamens eine abstrakte Handlung an- gefragt (z.B. ACTION DIAL) und Android entscheidet aufgrund der Benutzerpr¨ferenz, a an welches Programm das Intent geleitet wird. Der Entwickler braucht sich nicht dar- um zu k¨mmern, welche Telefonapplikation der Benutzer installiert und als Standard u definiert hat. F¨r ihn ist in diesem Beispiel nur wichtig, dass die Handlung w¨hle“ u a ” ausgef¨hrt wird. u ¨ Uber die Aufforderungen hinaus k¨nnen auch Daten mitgesendet werden. Mit Hilfe o von Bundles k¨nnen die Programme Daten senden und empfangen. o 5 Vgl. Meier, Reto: Professional Android Application Development. 1. Auflage. Indianapolis, USA: Wiley Publishing, 2009, S. 113f. 6 Intent = Intention, Vorhaben 23
  28. 28. 3 Die Android-Plattform 3.4 Applikationslebenszyklus Eine Besonderheit der Android-Plattform ist der Lebenszyklus von Applikationen. Bei Desktop-Betriebssystem oder auch anderen Handset-Plattformen entscheidet der Be- nutzer dar¨ber, wann ein Programm geschlossen oder wieder ge¨ffnet wird. Sollte zu u o einem bestimmten Zeitpunkt der Arbeitsspeicher des Ger¨tes gef¨llt sein, werden vom a u Betriebssystem nicht mehr gebrauchte Speichersegmente in einen Auslagerungsspei- cher gelegt. Dies macht sich f¨r den Benutzer in einer verringerten Geschwindigkeit u der Programme bemerkbar und er muss ggf. unn¨tige Programme schließen. Im bisher o einzigen Endger¨t T-Mobile G1“ stehen 96 MByte Arbeitsspeicher zur Verf¨gung, a u ” wovon ca. 80 MByte f¨r das Betriebssystem ben¨tigt wird und 16 MByte f¨r Benut- u o u zerprogramme7 . Bei Android gibt es keinen Auslagerungsspeicher. Es ubernimmt selbst die Kon- ¨ trolle uber die Laufzeit der installierten Programme. Dabei werden die Programme ¨ und deren Fenster (Activities) in einer Warteschlange verwaltet, so dass immer so vie- le Fenster ge¨ffnet sind, wieviel Speicher zur Verf¨gung steht. Fenster, welche zuerst o u ge¨ffnet wurden, werden wieder als erstes zerst¨rt. Dadurch kann der Benutzer uber o o ¨ den Zur¨ck-Knopf auf seinem Ger¨t ohne Verz¨gerung zur letzten Applikation wech- u a o seln. Da kein Vorw¨rts-Knopf vorgesehen ist, wird die nun verlassende Applikation a sofort zerst¨rt. Die Applikation, die als letzte in der Warteschlange aktiver Fenster o stand und zerst¨rt wurde, wird wieder hergestellt. o F¨r jeden Status, in das ein Fenster vom System gesetzt werden kann, gibt es eine u standardisierte 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 auch das sogenannte Test Driven Development“ immer mehr an Bedeutung9 . Kurz zusam- ” mengefasst besagt diese Methode, dass die Software durch Tests spezifiziert wird. Der Entwickler schreibt als erstes einen Test, der das gew¨nschte Verhalten der Softwa- u 7 Vgl. Guy, Romain: Avoiding Memory Leaks. URL: http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html – Zugriff am 16.02.2009. 8 Entnommen aus: Google, Inc.: Activity Lifecycle. URL: http://developer.android.com/images/activity_lifecycle.png – Zugriff am 16.02.2009 9 Vgl. Benninger, Lukas: Agile Software Development. Februar 2003 URL: http://www.ifi.uzh.ch/richter/Classes/sem_cutting_edge/Summary_agile.pdf , S. 7. 24
  29. 29. 3.5 Automatisiertes Testen Abbildung 3.1: Activity Lifecycle8 re spezifiziert, bevor er mit der Implementierung anf¨ngt. Durch den Einsatz von a funktionalen Tests ist sichergestellt, dass die Spezifikationen in jeder Stufe der Wei- terentwicklung eingehalten wird. 3.5.1 Standardm¨glichkeiten von Google o Trotz der in den letzten Jahren immer wichtiger gewordenen Methode stellt Google bisher nur unzureichende Werkzeuge f¨r funktionales Testing mit Android bereit. Zwar u gibt es im SDK eigene Pakete f¨r JUnit-Tests, sie sind jedoch kaum implementiert u oder gar dokumentiert. Das f¨hrt dazu, dass diese Pakete bisher nicht ausreichend zu u benutzen sind. Zwar ist es m¨glich, die Tests auf dem PC auszuf¨hren, doch wird dann das lokale o u (Sun-) JDK benutzt, da das Android-SDK nur auf der Android-Plattform lauff¨hig a 25
  30. 30. 3 Die Android-Plattform ist. Dies f¨hrt dazu, dass im getesteten Code sowie im Testcode selbst keine Android- u spezifischen Klassen verwendet werden k¨nnen. Jeder Code, der nicht ausschließlich o aus den Standard-Klassen des JDK besteht, bleibt also ungetestet10 . Dar¨ber hinaus u entspricht die Umgebung nicht dem eigentlichen Zielger¨t, was unter Umst¨nden zu a a unterschiedlichen Ergebnissen f¨hren kann. u 3.5.2 Automatisierte Tests mit Positron“ ” Positron11 ist ein Teil des AutoAndroid-Projekts, das nicht von Google selbst initiert wurde. Es hat das Ziel, das automatisierte Testen und Erzeugen von Programmen auf Android zu erm¨glichen. o Positron ist im wesentlichen als Server-Client-Struktur aufgebaut. Der Server wird mit Hilfe der android.app.Instrumentation-Klasse vor Ausf¨hrung des Programmcodes u instanziert, so dass dieser die Kontrolle uber die Applikation ubernehmen kann. Die ¨ ¨ Kommunikation mit dem Client auf dem Desktop-PC l¨uft uber die ADB (Android a ¨ Debugging Bridge), die im SDK enthalten ist. Der Client kann damit Befehle an den Server senden, der mit Statusmeldungen antwortet. Dadurch wird der JUnit-Test auf dem PC gesteuert, aber letztendlich auf dem Ger¨t ausgef¨hrt. a u Durch die PositronAPI kann der Entwickler in den Tests beliebige Eingaben auf der Oberfl¨che ausf¨hren und den Status abfragen. Dadurch legt der Entwickler im a u vorhinein das Verhalten der Software fest. 3.5.3 Automatisierte Erzeugung mit AndroidAnt“ ” Sobald eine Software nicht mehr durch einen einzelnen Entwickler, sondern im Team gefertigt wird, empfiehlt sich der Einsatz von Build-Servern. Dies hat den Vorteil, dass dort eine festgelegte Umgebung installiert ist, die unabh¨ngig von den lokalen a Workstations der Programmierer ist. In der Java-Welt hat sich Apache Ant als das Standard-Werkzeug zur automatischen Erzeugung ( Build“) entwickelt. Mittels Ant ” lassen sich uber XML-Dateien verschiedene Zielprogramme ( Targets“) definieren. Ant ¨ ” ubernimmt die Aufl¨sung von Abh¨ngigkeiten und Bibliotheken und veranlasst die ¨ o a Kompilation mit entsprechenden Parametern. 10 Siehe 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. 11 http://code.google.com/p/autoandroid/wiki/Positron 26
  31. 31. 3.5 Automatisiertes Testen AndroidAnt ist eine AntLib f¨r Ant, die die Erzeugung uber den Dalvik Cross- u ¨ compiler ausf¨hrt und den Android-Emulator steuern kann. Leider ist nach eigenen u Angaben diese Funktionalit¨t noch nicht ausgereift und instabil12 . a 12 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. 27
  32. 32. 4 Geodateneditor Vespucci“ ” Ziel dieser Arbeit ist die Entwicklung eines Geodateneditors f¨r das OpenStreetMap- u ” Projekt auf der Android-Plattform“. In diesem Kapitel wird das Ergebnis vorgestellt und erl¨utert. a Zuerst werden anhand einer Benutzeranalyse eine Zielgruppe definiert und daraus die ben¨tigten Anforderungen abgeleitet. Im Unterkapitel 4.2 ist das grobe Entwurfs- o konzept mit besonderer Aufmerksamkeit auf die Datenstruktur erl¨utert. Anschließend a wird die Implementation vorgestellt, die den Hauptteil dieser Arbeit ausmacht. Zum Schluss wird im Unterkapitel 4.4 darauf eingegangen, welches Potential in Vespucci steckt, um darauf aufbauend im Kapitel 5 Zusammenfassung sowie einen Ausblick f¨r u das Programm zu geben. 4.1 Analyse Bevor ein Konzept f¨r Vespucci erstellt werden kann, ist eine Analyse der Rahmen- u bedingungen erforderlich. Zuerst wird in diesem Kapitel die Zielgruppe festgelegt und kurz auf die technischen Rahmenbedingungen eingegangen. Aus diesen beiden Punkten lassen sich im Abschnitt 4.1.3 die Anforderungen an das Endprodukt erstellen. 4.1.1 Zielgruppendefinition Zielgruppe sind Gelegenheitsmapper, die in unregelm¨ßigen Abst¨nden Orte oder neue a a Wege in ihrer Umgebung eintragen wollen. Der Benutzer braucht daf¨r in der Regel u nur einen kleinen Kartenausschnitt, denn er wird sich voraussichtlich nur zu Fuß oder mit dem Fahrrad fortbewegen. Dar¨ber hinaus ist das Programm interessant f¨r pro- u u fessionelle Mapper, denen unterwegs nicht-verzeichnete Objekte auffallen und diese umgehend in OSM eintragen m¨chten, ohne sich ein weiteres Mal samt Ausr¨stung o u auf den Weg zu machen. Der Anwender sollte sich durchaus vorher mit OSM vertraut gemacht haben und die Zusammenh¨nge von Knoten, Wege und Tags zu kennen. Es ist f¨r ihn von Vorteil, a u wenn er die wichtigsten und g¨ngigen Tags auswendig kennt. Dieses Wissen ist jedoch a ¨ mit ein wenig Ubung schnell eingepr¨gt. a 29
  33. 33. 4 Geodateneditor Vespucci“ ” Dar¨ber hinaus ist ein Smartphone aufgrund der geringen Bildschirm- und Tasten- u gr¨ße f¨r Menschen mit Sehschw¨chen und mangelnder Feinmotorik ungeeignet. o u a Fortgeschrittene Projektmitglieder, die komplexe oder uberregionale Strukturen be- ¨ arbeiten wollen, geh¨ren nicht zur Zielgruppe. o 4.1.2 Technische Rahmenbedingungen Da Android in erster Linie f¨r Smartphones entwickelt wird, ist auch die Softwa- u re an die Begrenzungen der Hardware gebunden. Zwar steigt die Leistungsf¨higkeit a dieser Ger¨te zunehmend an, doch sind sie auch zuk¨nftig aufgrund ihrer geringen a u Gr¨ße nicht einem vollwertigen Computer gleichzustellen. Beispiele hierf¨r sind unter o u anderem die Ausmaße von Displays und Eingabeschnittstellen (Tastatur, Touchpad, Trackball, etc.). Ziel ist es daher, dass sich dem Mapper die wichtigsten Funktionalit¨ten sofort a erschließen und er diese einfach bedienen kann. Ziel ist es jedoch nicht, dem Benutzer eine ansprechende Kartendarstellung oder gar Routingm¨glichkeiten zu geben. o 4.1.3 Anforderungen Einfache Bedienbarkeit Wie bereits im vorherigem Abschnitt erw¨hnt, ist eine leichte, intuitive Bedienung a aufgrund der geringen Ausmaße des Handger¨tes unerl¨sslich. Der Benutzer soll sich a a schnell in die Benutzung einfinden k¨nnen, ohne Anleitungen zu lesen oder unbeab- o sichtigte Fehleingaben revidieren zu m¨ssen. u Funktionsumfang Auswahl des zu bearbeitenden Ausschnittes Der Benutzer soll ausw¨hlen k¨nnen, a o welchen Teil einer Karte er bearbeiten m¨chte. Ihm wird angeboten, bisherige Daten o f¨r diesen Ausschnitt vom OSM-Server zu laden. Die Auswahl kann uber manuell ein- u ¨ gegebene Koordinaten oder uber seine aktuelle Position erfolgen. Da hier eine pr¨zise ¨ a Angabe bei der Positionsbestimmung nicht erforderlich ist und die Ermittlung uber ¨ GPS unter Umst¨nden 15 Minuten dauern kann a 1 , k¨nnen die Daten sowohl uber die o ¨ Mobilfunkzellen-ID2 , als auch uber GPS benutzt werden k¨nnen. Sobald eine pr¨zisere ¨ o a Positionsangabe verf¨gbar ist, soll diese eingesetzt werden. u 1 Ramm, Frederik/Topf, Jochen: OpenStreetMap - Die freie Weltkarte nutzen und mitgestalten. 1. Auflage. Berlin: Lehmanns Media, 2008, Seite 20. 2 Google kann aufgrund der Mobilfunkzellen-ID und die Distanz zum Sendemasten eine ungef¨hre Position bestimmen. Die Daten sind innerhalb weniger Sekunden verf¨gbar a u 30
  34. 34. 4.1 Analyse Anzeige der Daten Hat der Benutzer einen Bereich mit OSM-Daten geladen, so sollen ihm die Geodaten maßstabsgetreu angezeigt werden. Dar¨ber hinaus muss es u f¨r den Mapper erkennbar sein, wie groß sein aktuell g¨ltiger Bereich ist3 . u u Move-Modus Der Benutzer soll den sichtbaren Kartenbereich verschieben k¨nnen. o Aufgrund besserer Handhabung soll dies nicht nur uber den Touchscreen, sondern auch ¨ uber Hardwaretasten m¨glich sein. Eine M¨glichkeit zur Vergr¨ßerung/Verkleinerung ¨ o o o des Ausschnittes soll uber eigene Tasten verf¨gbar sein. ¨ u Edit-Modus Vorhandene Knoten auf der Karte sollen verschoben werden k¨nnen. o Wird ein Knoten an den Bildschirmrand verschoben, so soll sich der Kartenausschnit in diese Richtung mitbewegen. Delete-Modus Der Mapper soll vorhandene Knoten l¨schen k¨nnen. Wenn ein Weg o o zu diesem Knoten geh¨rt hat, soll der Weg automatisch gel¨scht werden, wenn dieser o o Weg nur noch einen weiteren Knoten referenziert. Create-Modus In diesem Modus k¨nnen neue Elemente erstellt werden. Durch erstes o Klicken des Touchscreens wird ein Knoten erstellt. Erfolgt der zweite Klick auf den gleichen Punkt, so ist die Erstellung f¨r diesen Punkt abgeschlossen und das n¨chste u a Element kann angefertigt werden. Klickt der Benutzer jedoch als zweites auf eine andere Fl¨che des Bildschirms, so wird dort ein weitere Knoten erstellt, die mit einem a neuen Weg verbunden sind. Dies wird solange fortgesetzt, bis der Benutzer den letzten Knoten ein weiteres mal anklickt. Wird ein vorhandener Knoten ausgew¨hlt, wird dieser benutzt, anstatt dass ein a neuer Knoten dar¨ber erstellt wird. Wird auf ein Weg-Segment geklickt, so wird an u dieser Stelle ein neuer Knoten eingef¨gt und in dem darunterliegenden Weg zwischen u den beiden bisherigen Knoten eingebunden. Append-Modus Hat der Benutzer im Append-Modus den ersten oder letzten Knoten eines Wege ausgew¨hlt, so werden die anschließend erstellten Weg-Segmente dem Weg a angeh¨ngt, anstatt einen neuen Weg zu erstellen. a F¨hrt der Benutzer eine Bewegung uber den Touchscreen aus, anstatt ihn anzukli- u ¨ cken, so wird diese Bewegung als Verschiebung des Kartenausschnitts interpretiert. Die Modi sind sowohl uber ein Programmmen¨, als auch uber Tastenk¨rzel erreich- ¨ u ¨ u bar. In allen Modi werden ausw¨hlbare Elemente mit einem Toleranzbereich ange- a zeigt, der die Ber¨hrungstoleranz anzeigt. Dies ist erforderlich, da die Auswahl von u Bildschirmelementen mittels Fingerdruck f¨r den Anwender unpr¨ziser zu setzen ist, u a als beispielsweise ein Mausklick am Desktop-PC. 3 siehe Kapitel 2.3.4 Bounds, Seite 14 31
  35. 35. 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 werden ¨ angezeigt und er kann diese l¨schen, ver¨ndern oder beliebig viele neue Schl¨ssel- o a u Wert-Paare hinzuf¨gen. Durch den Zur¨ck-Knopf seines Ger¨tes best¨tigt der Anwen- u u a a der die Angaben und gelangt zur¨ck zur Kartenansicht. Leere Felder im Formular u werden ignoriert. Die Liste von Eingabefeldern f¨r Schl¨ssel-Wert-Paare erweitert sich u u bei 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 nachzeichnen oder einen Knoten an seiner aktuellen Position eintragen kann. Der Mapper soll die M¨glichkeit haben, diesen GPS-Track auch abschalten zu k¨nnen. Bewegt sich der Be- o o 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 laden k¨nnen. o Konfigurationsm¨glichkeiten o Im Konfigurationsfenster kann der Anwender seine OSM-Server Login-Daten eintragen und GPS-Abfrage-Intervalle festlegen. Zus¨tzlich a stehen dort folgende Optionen zur Verf¨gung: Anzeige von Statistiken in der Karten- u ansicht, Anzeige der Toleranzen sowie das Abschalten von AntiAliasing zur Beschleu- nigung der Darstellung. Verst¨ndlichkeit des Quellcodes a Zwar stehen in einem mobilen Endger¨t noch lange nicht so leistungsstarke Ressour- a cen wie in einem Desktop-PC zur Verf¨gung. Steht man bei einem nicht-kritischem u Codefragment vor der Frage, eine effiziente oder eine leicht erschließbare L¨sung zu o implementieren, sollte Letztere gew¨hlt werden. Dieser Herangehensweise ist vor allem a f¨r die geplante Weiterentwicklung im Team n¨tig. u o Software-Design MVC-Modell Soweit es m¨glich ist, soll das in Kapitel 3.2 vorgestellte MVC-Muster o angewendet werden, um eine flexible Weiterentwicklung zu erm¨glichen. Dabei sind o die von Android bereitgestellten Mechanismen auszusch¨pfen. o 32

×