Seminar: Datenbankunterstützung für mobile GIS Geo-Dienste auf Basis der Android-Plattform

Michael Goj

Datenbanken und Informationssysteme Universität Augsburg

Betreuer: Florian Wenzel

Abstract. Nahezu jedes moderne mobile Endgerät ist heutzutage mit einem GPS-Empfänger ausgestattet, da es unter anderem für viele Käufer ein wichtiger Faktor für den Erwerb eines neuen Geräts ist. Weitreichend sind die möglichen Einsatzzwecke, die das Gerät mit diesem Ausstattungsmerkmal mit sich bringen. Die Bandbreite reicht von einer einfachen Darstellung der aktuellen Position in einer Karte bis hin zu Frühwarnsystemen gegen Naturgefahren. Durch den Ausbau des Mobilfunknetzes und günstigen Internettarifen wird die Verwendung von raumbezogenen Webservices, den sogenannten Geodiensten zur Entwicklung von mobilen Geoanwendungen begünstigt. In dieser Arbeit wird ein Überblick über standortbezogene Dienste und Anwendungen, Geodiensten und der Android-Programmierung gegeben und ein Beispielprojekt vorgestellt.

Keywords: Android, Geo-Dienste, Geoinformationssysteme, LBS

1 Einleitung

Die Ausstattung derzeitiger mobiler Endgeräte macht die Entwicklung komplexer Anwendungen möglich. Leistungsstarke Prozessoren, Kameras oder Sensoren zählen schon fast zum Standardrepertoire. Auch der Ausbau des Mobilfunknetzes sowie immer günstiger werdende Internet Flatrate Tarife tragen dazu bei. Insbesondere standortbezogene Anwendungen und Dienste gewinnen immer mehr an Bedeutung bei mobilen Endnutzern. Somit können Fragen wie beispielsweise „Wo befinde ich mich gerade?“, “Was befindet sich in meiner Umgebung?“ oder „Wo ist die nächste Tankstelle?“ in diesen Anwendungen beantwortet werden. Für die Implementierung einer solchen Anwendung werden auf webbasierte Dienste zurückgegriffen, die die entsprechenden Geodaten liefern. Dabei handelt es sich um die sogenannten Geo-Dienste. In dieser Arbeit wird zunächst ein grober Überblick über standortbezogene Dienste und Anwendungen gegeben. Zudem werden die wichtigsten Geo-Dienste kurz erläutert und abschließend wird das mobile Betriebssystem Android und eine mögliche Beispielapplikation vorgestellt.

2 Standortbezogene Dienste und Anwendungen

Da immer mehr mobile Endgeräte mit einem GPS-Empfänger ausgestattet sind, werden standortbezogene Dienste immer beliebter. Der Standortbezug ermöglicht insbesondere im mobilen Sektor interessante und neue Anwendungsfälle. Ortsabhänigige Werbung, Hilferufesysteme und Touristenführer sind nur einige Beispiele. Jörg Roth definiert einen ortsbezogenen Dienst wie folgt: „Ein ortsbezogener Dienst ist ein Dienst, der den Ort des Dienstnutzers, den Ort eines anderen Benutzers, den Ort eines mobilen Objektes oder beliebige feste Orte bei der Ausführung berücksichtigt oder Informationen über solche Orte zurückgibt.“[1] Bevor in diesem Kapitel auf die Klassifikation und der Architektur von standortbezogenen Diensten und Anwendungen eingegangen wird, werden zunächst die Begriffe aus Abbildung 1 geklärt. Die Abbildung gibt einen Überblick über die möglichen Begriffskombinationen rund um den Ortsbezug.

Abbildung 1. Begriffskombinationen

2.1 Begriffe

Im ersten Teil der möglichen Ausdrücke wird zwischen Position und Ort beziehungsweise Standort unterschieden. Position bezeichnet einen exakten Punkt im Raum, wohingegen (Stand-)Ort einen räumlichen Bereich, ein Areal oder ein Gebiet mit einer Bedeutung, wie beispielsweise Fußballplatz oder Hörsaal beschreibt. Die Wörter „bezogen“, “gebunden“, „abhängig“ und „basiert“ (engl. „based“) im mittleren Teil sagen aus, dass die Anwendung in irgendeiner Form etwas mit einem Ort oder Orten (Position(en)) zu tun hat. Ändert eine Anwendung an einem Ort ihr Verhalten, wird dies mit dem Begriff „bewusst“ (engl. „aware“) ausgedrückt. Eine Anwendung, die nicht nur ein reiner Ortsdienst ist, wie beispielsweise Navigation, sondern durch Berücksichtigung des Ortes aufgewertet wird, wird mit dem Begriff „enabled“ beschrieben. Dienste, die nur an bestimmten Orten verfügbar sind, werden mit „dependent“ bezeichnet (zum Beispiel Eingangskontrolle). Zudem muss man beachten, dass „ortsbezogen“ nicht das Gegenteil von „ortsunabhängig“ ist. „Ortsunabhängig“ bedeutet lediglich, dass ein Dienst von überall aus genutzt werden kann. Ein „ortsbezogener“ Dienst berücksichtigt den Ort, heißt aber nicht, dass dieser Dienst von bestimmten Orten nicht genutzt werden kann. Somit kann ein Dienst ortsunabhängig und zugleich ortsbezogen sein. Im letzten Teil der möglichen Ausdrücke werden als „Dienst“ (engl. Service) mittlerweile auch Dienste bezeichnet, bei denen es sich nicht um einen Netzwerk-Dienst handelt. Prinzipiell verwendet man allerdings hierfür eher den Ausdruck „Anwendung“. Im allgemeinen wird im deutschen oft von ortsbezogenen Diensten und im englischen von location-based services (LBS) gesprochen.

2.2 Klassifikation

Ortsbezogene Dienste werden in sechs Klassen unterteilt [1]. Im folgenden Abschnitt werden diese kurz vorgestellt. Klasse-1-Dienste Klasse-1-Dienste geben Informationen über stationäre Orte. Klassische Ortsbezogene Informationsdienste wie zum Beispiel Wetterbericht und Navigation sowie Points of Interest („Wo ist das nächste Hotel?“) werden in diese Klasse eingeordnet. Klasse-2-Dienste In der zweiten Klasse werden Trackingdienste eingeordnet, wie zum Beispiel die Suche nach gestohlenen Autos oder Suche nach Freunden in der Nähe.

Klasse-3-Dienste Unter dieser Klasse fallen Assistenzdienste, wie zum Beispiel die Übermittlung der aktuellen Position beim Anruf eines Pannendienstes. Klasse-4-Dienste Zur vierten Klasse zählen ortsbezogene Gebühren. Diese werden ausgelöst durch Positionsänderungen. So können beispielsweise günstige Mobilfunkgebühren aktiviert werden, wenn das mobile Endgerät zu Hause genutzt wird (Homezone). Klasse-5-Dienste Nachrichten-und Ankündigungsdienste werden der Klasse 5 zugeordnet. Dies ist zum Beispiel ein Dienst, bei dem eine Nachricht an Freunde in einem bestimmten Umkreis geschickt werden kann. Klasse-6-Dienste Zur sechsten Klasse gehören Trigger-Dienste. Diese Dienste werden durch einen Trigger ausgelöst. So werden beispielsweise gezielte Werbenachrichten beim Betreten eines Kaufhauses an den Benutzer geschickt.

2.3 Architektur von LBS-Systemen

Bei ortsbezogenen Diensten treten drei verschiedene Architekturmodelle auf (siehe Abbildung 2) [2].

Abbildung 2. Drei Modelle eines LBS-Dienstes [2] So unterscheidet man zwischen einem Pull-basierten (a), Poll-basierten(b) und Push-basierten (c) Modell. Beim Pull-basierten Modell befindet sich ein Proxy, der zu einer Anfrage des Benutzers an der Anwendung die lokale Information anhängt. Daraufhin erfolgt die Antwort der LBS-Anwendung. Bei dem Poll-basierten Modell verschickt

die Anwendung regelmäßig eine Anfrage an den Server um Informationen über den Aufenthaltsort des Nutzers zu bekommen. Der Vorteil dieser Variante liegt darin, dass somit Ortsinformationen über einen längeren Zeitraum an die Client-Anwendung übermittelt werden können. Beim Push-basierten Modell werden Nachrichten proaktiv, d.h. ohne vorherige Anfrage des Benutzers, versendet. Das Push-Modell ermöglicht somit genau die richtigen Informationen zum richtigen Zeitpunkt an die richtige Person zu liefern.

2.4 Context-Awareness

Kontextabhängige Anwendungen gehen noch einen Schritt weiter, als nur den Ortsbezug in Betracht zu ziehen. In diesen Anwendungen wird ermittelt, in welcher Umgebung oder Situation sich ein Benutzer im Moment befindet und das System reagiert dementsprechend. Die Umgebung, die Endgeräte, der Benutzer selbst und die physikalischen Bedingungen bilden den Kontext. Spielt in einer Anwendung der Kontext eine zentrale Rolle ist von Context-Awareness die Rede. Generell kann ein Kontext als eine Ansammlung von Variablen bezeichnet werden. Eine Situation hingegen beschreibt eine konkrete Belegung dieser Variablen.

2.5 Adaptive Visualisierung

Bei diesem Ansatz versucht man zusätzlich zum Kontext die Aufgaben eines Nutzers, sowie die verschiedenen Nutzergruppen (zum Beispiel Experten oder Touristen) mit einzubeziehen [3]. Somit versucht man die bestmögliche Darstellung für den Nutzer zu finden, damit er möglichst schnell in seiner Situation seine Aufgabe erfolgreich ausführen kann. Zu den grundlegenden Aufgaben mit räumlichen Bezug eines Nutzers zählen: lokalisieren, navigieren, suchen, identifizieren und Ereignisse abfragen [4].

3 Geo-Dienste

Webbasierte Geo-Dienste verknüpfen die Technologien Internet und geographische Informationssysteme (GIS). Das GIS ist für die Speicherung, Verwaltung und Visualisierung der Daten zuständig, wobei das Internet die Möglichkeit bietet, die Informationen in einer eigenen Anwendung einzubetten. Somit ist es möglich Daten aus unterschiedlichen Institutionen miteinander zu kombinieren und Karten mit geringem Aufwand zu erstellen. Auf diesem Weg können Nutzer je nach Aufgabenstellung oder Interesse eigene Produkte erstellen. Geodaten können sowohl Punkte, Linien und Flächen als auch den Raumbezug sowie weitere raumabhängige Attribute darstellen. Aufgrund der teilweise unterschiedlichen Aufgaben und Anforderungen wurden zahlreiche Geo-Dienste entwickelt und spezifiziert. Das Open Geospatial Consortium

(OGC) versucht hierzu Spezifikationen und Standards für den Austausch und die Bereitstellung von Geodaten zu erstellen. Einige der wichtigsten Vertreter von Geo-Diensten sind der Catalog Service for the Web (CSW), Web Map Service (WMS), Web Feature Service (WFS), Web Gazetteer Service (WFS-G), Web Coordinate Transformation Service (WCTS) und Web Terrain Service (WTS). Im folgenden Abschnitt werden diese jeweils kurz erläutert. Catalog Service for the Web (CSW) In einem CSW werden Informationen über Geoanwendungen, Geodienste und Geodaten in einer Geodateninfrastruktur bereitgestellt. Dabei werden Metadaten im CSW angemeldet, um sie anschließend bei einer Suche auch finden zu können. Web Map Service (WMS) Ein WMS liefert Rasterdaten und Kartenmaterial zur Darstellung der Geodaten. In Kapitel 5.2 wird dieser Geo-Dienst insbesondere im mobilen Kontext beschrieben. Web Feature Service (WFS) Während ein Nutzer in einem WMS Geodaten in Form von Karten oder Bildern erhält, kann man in einem WFS direkt auf die Daten, die ausschließlich aus Vektordaten bestehen, zugreifen. Somit hat der Nutzer selbst die Möglichkeit die Daten zu visualisieren, analysieren oder weiterzuverarbeiten. Grundsätzlich kann man in einem WFS Objekte einfügen, aktualisieren, löschen, abfragen und finden. Aufgrund der unterstützen Operationen werden WFS in basic WFS und transactional WFS unterteilt. In einem basic WFS werden nur Operationen unterstützt, die einen lesenden Zugriff auf die Daten gewähren, wohingegen in einem transactional WFS auch schreibende Operationen zugelassen werden. Web Gazetteer Service (WFS-G) Der an das WFS angelehnte Geo-Dienst WFS-G dient der Suche nach Objekten wie beispielsweise Ortsnamen oder Hausadressen. Der Zugang der Daten wird über geographische Namensverzeichnisse (engl. Gazetteer) ermöglicht. Ein WFS-G kann zudem aber auch zu einem Kartenausschnitt die dazugehörigen geographischen Namen liefern. Web Coordinate Transformation Service (WCTS) Mit Hilfe eines WCTS können Koordinaten zwischen unterschiedlichen Koordinatensystemen transformiert werden. Dies ist nötig für die Kombination von Geodaten aus unterschiedlichen Quellen. Somit bleiben die Daten jedes einzelnen GIS in ihrem Koordinatensystem erhalten, da die Umrechnung jeweils zur Laufzeit der Anfrage geschieht. Web Terrain Service (WTS) Zur dreidimensionalen Darstellung von Geodaten kann auf ein WTS zurückgegriffen werden. Hierbei wird mit einer GetView Anfrage eine statische 3D-Kartenansicht in Form eines Bildes geliefert. Insgesamt kann man Geo-Dienste grob in folgende Kategorien einteilen: Kartendienste, Austauschdienste, Suchdienste und Sonstige Dienste [5].

4 Die Android-Plattform

Im Jahr 2003 wurde das Unternehmen Android Inc. von Andy Rubin gegründet, dass Software für Mobiltelefone entwickelte. Zwei Jahre später wurde dieses Unternehmen von Google gekauft und zusammen mit den Mitgliedern der Open Handset Alliance das Betriebssystem Android für mobile Endgeräte entwickelt. Die Plattform ist offiziell seit dem 21. Oktober 2008 verfügbar. Neben der Tatsache, dass das Betriebssystem bereits weit verbreitet ist, sprechen aus Entwicklersicht folgende Gründe für Android als Betriebssytem:

• freie Software und quelloffen • große Flexibilität • breite Hardwareuntersützung • große Entwicklergemeinde • somit guter Support • große Auswahl an Geräten

Im Folgenden wird ein Überblick über den Systemaufbau von Android gegeben. Es wird unter anderem die Systemarchitektur, Standardbibliotheken sowie einige Android-Komponenten vorgestellt. Anschließend wird darauf eingegangen, wie Google Maps bei der Entwicklung verwendet werden kann und welche Möglichkeiten dem Entwickler zur Verfügung stehen.

4.1 Architekturübersicht

Die Architektur besteht aus der Anwendungsschicht, dem Anwendungsrahmen, Bibliotheken, der Android-Laufzeitumgebung sowie dem Linux-Kernel und ist in Abbildung 3 dargestellt.

Abbildung 3. Android-Architektur [6] Die Bestandteile der Architektur werden im Folgenden genauer vorgestellt. Anwendungsschicht In dieser Schicht befinden sich die von Drittanbietern oder selbst entwickelten sowie die von Google mitgelieferten Anwendungen (zum Beispiel Browser oder Email-Client). Innerhalb dieser Ebene findet die Mensch-Maschine-Interaktion sowie die Kommunikation zwischen den Anwendungen statt. Anwendungsrahmen Im Anwendungsrahmen befinden sich sämtliche Manager-Klassen. Die in Java entwickelten Anwendungen basieren auf diesem Anwendungsrahmen. Zusätzlich zu den allgemeinen Java-Klassen bietet der Rahmen vier zentrale Komponenten, wovon mindestens eine in jeder Android-Anwendung vorhanden ist. Bibliotheken Die in Android verfügbaren Standardbibliotheken bieten die Kernfunktionalität. Einige dieser Bibliotheken sind zum Beispiel SQLite, ein Datenbanksystem, das vor allem im mobilen Bereich häufig eingesetzt wird sowie LibWebCore, eine auf der WebKit basierende Webbrowser-Umgebung. Android-Laufzeitumgebung Die Dalvik Virtual Machine (DVM) wurde speziell für mobile Geräte entwickelt und ist Hauptbestandteil der Android-Plattform. Für jede Anwendung wird ein eigener

Betriebssystemprozess und darin eine eigene DVM gestartet. In dieser virtuellen Registermaschine läuft dann die Anwendung. Linux-Kernel Die Android-Plattform basiert auf Linux 2.6 [6]. Der Linux-Kernel beinhaltet die erforderlichen Gerätetreiber und ist zuständig für Systemdienste, wie beispielsweise die Speicherverwaltung und Prozessverwaltung.

4.2 Android-Komponenten

Ziel der Android-Entwicklung ist es, nicht alles neu schreiben zu müssen, sondern vorhandene Teile wieder zu verwenden. So kann zum Beispiel eine neue Anwendung geschrieben werden, die auf die Telefonnummern der bereits vorinstallierten Anwendung „Kontakte“ zugreifen kann und diese in der Anwendung „Telefon“ wiederum wählen [7]. In diesem Kapitel werden die vier wichtigsten Android-Komponenten vorgestellt. Activity Jede Android-Anwendung, die von einem Nutzer bedient werden soll, braucht zumindest eine Activity. In einer Activity werden beispielsweise Anwendereingaben ausgewertet, Eingabefelder ausgelesen und Oberflächenelemente bestimmt, die angezeigt werden. Eine Activity ist somit zuständig für die Darstellung und Verwaltung von Oberflächen [7]. Service Ein Service läuft ohne eine Oberfläche und im Hintergrund ab. Ein Beispiel hierfür ist der Media Player. Die Bedienung des Players erfolgt in einer Activity. Wird die Anwendung verlassen und/oder eine weitere Anwendung gestartet, kann auch weiterhin Musik aus der Playlist abgespielt werden. Content Provider Der Content Provider ist eine Datenschnittstelle und zuständig für das Austauschen von Daten zwischen Anwendungen. Broadcast Receiver Diese Komponente empfängt die Systemnachrichten, wovon die Android-Plattform starken Gebrauch macht, um vor allem auf Änderungen des Systemzustands zu reagieren. Nähert sich beispielsweise die Akkulaufzeit dem Ende, kann das System dementsprechend reagieren und die Helligkeit des Displays verringern.

4.3 Ermittlung von Positionsdaten und Darstellung von Kartenmaterial

In diesem Kapitel wird erläutert, wie in Android Positionsdaten ermittelt werden können und wie Kartenmaterial mithilfe von Google Maps angezeigt werden kann. Es wird unter anderem gezeigt, welche Vorbereitungen dafür gemacht werden müssen,

welche Funktionen Google Maps mitbringt und welche Anwendungen damit erstellt werden können. Außerdem werden Probleme bei der Verwendung von Google Maps aufgezeigt.

4.3.1 Location Manager

Der Location Manager ist Bestandteil des Anwendungsrahmens und dient als Schnittstelle zum GPS-Empfänger des mobilen Endgeräts. Die Komponente besteht aus drei Hauptfunktionen:

• Übermittlung der zuletzt bekannten Ortsposition • Eine Aktion auslösen, wenn der Radius um einen definierten Ortspunkt

unterschritten wird • Registrierung eines Listeners, der mehr oder weniger periodisch die

Ortsposition liefert Wichtige Parameter sind latitude (Breitengrad), longitude (Längengrad) und altitude (Höheninformation, Höhe in Metern über Normal-Null). Der Location Manager verwendet nur die Dezimalschreibweise. Bsp.: [7°06’54.09’’ Ost, 50°42’23.57’’ Nord] im Dezimalsystem [7.1152637, 50.7066272] In Android und der Google Maps API müssen diese Parameter allerdings in umgekehrter Reihenfolge angegeben werden, da zuerst der Breitengrad und dann der Längengrad verlangt wird.

4.3.2 Location Provider

Der Location Provider bestimmt die Technologie, die die aktuelle Ortsposition ermitteln soll. So gibt es unter anderem einen GPS Provider sowie einen Network Provider. Beide sind als statische Variablen in der LocationManager Klasse definiert:

• LocationManager.GPS_PROVIDER • LocationManager.NETWORK_PROVIDER

Mit der Methode getProviders(boolean enabledOnly) aus der LocationManager Klasse erhält man eine Liste aller Provider. Wenn enabled auf true gesetzt ist, werden nur die aktivierten Provider zurückgegeben. Mit Hilfe der Criteria Klasse kann man Kriterien definieren, die für die Bestimmung des Providers wichtig sind. Anschließend kann man die Kriterien der BestProvider Methode übergeben und bekommt somit den Provider, der diese Kriterien am Besten erfüllt (siehe Abbildung 4). Falls mehr als ein Provider den Kriterien entsprechen, wird der Provider ausgewählt, der die beste Leistung hat. Falls keiner gefunden wird,

werden die Kriterien in folgender Reihenfolge abgearbeitet: Stromverbrauch, Genauigkeit, die Fähigkeit, die Lage zu übermitteln, Geschwindigkeit und Höhe.

Abbildung 4. Kriterien definieren [2]

4.3.3 Reverse/Forward Geocoding

Mit Reverse Geocoding bezeichnet man die Konvertierung von geographischen Koordinaten (Längen- und Breitengrad) in eine Adresse. Hierfür wird die Methode getFromLocation der Klasse Geocoder zur Verfügung gestellt. Forward Geocoding ist genau der andere Weg. Hierbei können aus einer Adresse der Längen- und Breitengrad ermittelt werden. Dafür werden die Methoden getLatitude und getLongitude der Location Klasse verwendet.

4.3.4 Google Maps

Google bietet mit der Google Maps API eine einfache Möglichkeit eine Karte in einer Anwendung anzuzeigen. Die Google Maps API ist allerdings keine freie und quelloffene Software [8]. Damit man das Kartenmaterial nutzen kann, benötigt man einen Google Maps API-Key und hierfür wiederum ein Zertifikat. Im Registrierungsformular [9] kann der MD5-Fingerabdruck des Zertifikats eingegeben werden und erhält anschließend den Google Maps API-Key. Für die Anzeige einer Karte benötigt man eine spezielle View, die sogenannte MapView, die man in ein Layout integrieren kann. Für die Darstellung des Layouts benötigt man eine MapActivity, die für das Laden des Kartenmaterials über das Internet und das Ablegen im Dateisystem zuständig ist. In der MapView gibt es die Möglichkeit die View als Straßenkarte oder als Satellitenbild anzuzeigen (siehe Abbildung 5).

Abbildung 5. Straßenkarte (links) und Satellitenbild (rechts) [7] Die Nutzung der Google Maps API bringt allerdings auch Einschränkungen mit sich. Die API unterstützt nur die Google-Maps spezifische Projektion, eine abgewandelte Mercator Projektion. Diese wird im Unterschied zu WGS84 zu den Polen hin gestreckt. Allerdings wird diese Projektion kaum von einem WMS-Server unterstützt. Somit muss meistens mit einer gewissen Ungenauigkeit gerechnet werden. [8]. Somit ist die Entwicklung einer eigenen Maps-API, die unterschiedliche Projektionen und das Tile Caching (siehe Kapitel 5.2) direkt unterstützen, zur Zeit vielleicht die beste Lösung für dieses Problem.

5 Beispiel eines freien mobilen Geoinformationssystems

In diesem Kapitel wird GeoViewer, ein mobiles Geoinformationssystem in Android vorgestellt, das an der Universität Osnabrück entstanden ist. Hierbei wird auf standardkonforme Dienste gesetzt wie beispielsweise Web Map Service (WMS), Sensor Observation Service (SOS) und Geo-enabling Really Simple Syndication (RSS), die allesamt frei verfügbar und vom Open Geospatial Consortium (OGC) betreut werden. Mit Hilfe von OpenGL ES wurden dreidimensionale geologische Daten dargestellt, mit der Absicht, die Leistungsfähigkeit mobiler Endgeräte zu testen.

Mobile Endgeräte besitzen noch lange nicht die Leistung eines Desktop-PCs oder erst eines Servers mit GIS-Funktionalitäten. Auf dieses Problem wird in diesem Projekt eingegangen, sowie auf das Problem der teilweise noch schlechten Netzabdeckung. Das erste Problem wird dadurch gelöst, dass performancelastige Aufgaben ein Server übernimmt und ein effizientes Client-Server Modell aufgebaut wurde. Das Netzproblem wird dadurch gelöst, dass Daten ständig synchronisiert werden, solange eine Verbindung besteht. Außerdem werden nur relevante Daten von vornherein auf das mobile Endgerät übertragen, da auf die geringe Speicherkapazität zu achten ist.

5.1 Verwendete Komponenten und Bibliotheken des Android Anwendungsrahmens

Neben dem Activity Manager, der den Lebenszyklus einer Applikation verwaltet, dem Resource und Package Manger, die für die Verwaltung von persistenten Daten wie Lokalisierungen und Einstellungen sowie der Quellcodedateien zuständig sind, wurden die Komponenten Window Manager, View System und Location Manager verwendet. Die wichtigsten Bibliotheken waren neben den Java- und Android Standardbibliotheken das Datenbanksystem SQLite und die 3D Computergraphikschnitstelle OpenGL ES für die Darstellung von geologischen Bodenschichten.

5.2 Verwendete Webservices

Folgende Webservices wurden im Projekt GeoViewer eingesetzt: WMS Ein Web Map Service (WMS) bietet eine einfache HTTP Schnittstelle zur Abfrage von geo-referenzierten Bildern aus einer beziehungsweise mehreren verteilten raumbezogenen Datenbanken [10]. Ein WMS besteht grundsätzlich aus den Operationen GetCapabilites und GetMap und besteht aus Layern in einer Baumstruktur. Mit der GetCapabilites-Anfrage an einen WMS-Server erhält man alle Metadaten, die wiederum mithilfe der GetMap-Anfrage Karten in verschiedenen Projektionen und Bildformaten für eine umschließende Bounding Box (BBOX) vom Server zurückgegeben werden können [8]. Zusätzlich zu diesen beiden Operationen findet man in der Spezifikation eine dritte Operation GetFeatureInfo, die allerdings optional für ein WMS ist und bei der Anwendung GeoViewer nicht verwendet wurde [10]. Im Projekt GeoViewer wird die Antwort der GetCapabilites-Anfrage geparsed und die wichtigen Metadaten, wie beispielsweise die Layer-Baumstruktur mit den jeweils

zulässigen Projektionen, in eine SQLite-Datenbank geschrieben. Damit das Kartenmaterial aus verschiedenen WMS-Layern übereinander dargestellt werden kann, werden nur die Layer unterstützt, die in der GetMap-Antwort transparente Karten im PNG-Format zur Verfügung stellen. Die Problematik einer effizienten Abfrage des Kartenmaterials wird in GeoViewer mit TileCaching, gelöst. TileCaching ist ein Verfahren, in dem die Karte nicht als Ganzes abgefragt wird, sondern zerstückelt in sogenannten Tiles (Kacheln), die anschließend wiederum zusammengesetzt werden [8]. SOS Der Webservice Sensor Observation Service (SOS) bietet eine Programmierschnittstelle zur Abfrage von Sensordaten an [11]. Es werden dabei sowohl ortsgebundene als auch dynamische Sensoren berücksichtigt. Eine SOS-Implementierung muss grundsätzlich folgende drei Operationen zur Verfügung stellen: GetCapabilites, GetObservation und DescribeSensor. GetCapabilites liefert sogenannte Offerings, die jeweils eine Ansammlung von Sensoren mit änhlichem Inhalt darstellen [8]. Mit GetObservation können die eigentlichen Messwerte abgefragt werden. Mit Hilfe der DescribeSensor Operation werden konkrete Metainformationen eines einzelnen Sensors ausgegeben.

Abbildung 6. Abfrageschema [11]

Bei dem Versuch der Umsetzung des in der Abbildung 6 ersichtlichen Abfrageschemas eines SOS-Services stellt sich heraus, dass diese Vorlage im mobilen Umfeld zu rechen- und speicherintensiv ist. Somit wurde der Schritt Discover Services, das für die Auswahl eines Services zuständig ist, ausgelassen. Deshalb gilt als Voraussetzung, dass der Nutzer sich für einen Service entschieden hat. Desweiteren wurde der Schritt Get Sensor Metadata nicht unterstützt, da ausreichend Informationen im Schritt Discover Observations mit der Operation GetObservation geliefert werden. Wie bei der Implementierung eines WMS werden auch hier wiederum die erhaltenen Daten in einer eigenen SQLite Datenbank gespeichert, damit mit der Anwendung auch dann gearbeitet werden kann, wenn Störungen beim Netzempfang auftreten. GeoRSS Geo-enabling RSS (GeoRSS) ist eine Erweiterung der RSS-Technologie um den Raumbezug [12]. So können Nachrichten zum Beispiel einen Punkt, eine Linie oder ein Polygon enthalten. Somit lassen sich interessante Anwendungsfälle realisieren, wie zum Beispiel die Darstellung einer Reiseroute, die mit aktuellen Informationen zu den einzelnen Sehenswürdigkeiten versehen sind. Die angeforderten Daten werden in GeoViewer auch hier in einer SQLite Datenbank für die Nutzung ohne Internetverbindung abgelegt. Es wurde festgestellt, dass die Problematik im mobilen Kontext in der Synchronisation des GeoRSS-Feeds besteht [8].

6 Ausblick

Erst wenn von den Netzbetreibern sichergestellt werden kann, dass der Netzempfang ständig verfügbar ist, können mühelos Geo-Dienste im mobilen Kontext verwendet werden. Dann entfällt die Zwischenspeicherung der Geodaten in lokalen Datenbanken auf mobilen Endgeräten. Interessant ist die Entwicklung im 3D-Bereich. Mit Hilfe des Geo-Dienstes Web 3D Services (W3DS) ist es bereits möglich, komplette Kartenszenen zu liefern, die interaktiv vom Nutzer erkundet werden können [5]. Das bedeutet, dass man sich frei in dieser Szene bewegen kann. Nun gilt es herauszufinden, inwiefern die Leistung aktueller mobiler Endgeräte ausreicht, um für ein gewisses Nutzererlebnis zu sorgen. Desweiteren stellt sich die Frage, zu welchem Zeitpunkt und an welchem Ort Nutzer eine solche Anwendung nutzen würden. Welche Anwendungsfälle lassen sich mit Hilfe eines 3D Geo-Dienstes realisieren? Welche sind sinnvoll? Gut vorstellbar ist unter anderem auch, dass noch weitere Sensoren in mobilen Endgeräten eingebaut werden, die relevante Daten für Geoinformationssysteme bereitstellen können, die wiederum mit Hilfe eines Geo-Dienstes von anderen Nutzern verwendet werden können.

References

1. Roth, J.: Ortsbezogene Anwendungen und Dienste, http://www.informatik.fh-nuernberg.de/professors/roth/WS1011/Ortsbezug/OrtsbezogeneAnwendungenUndDienste_WS1011.pdf Besucht: 29.06.2011

2. Kumar, S.; Qadeer, M.A.; Gupta, A.: Location based services using android (LBSOID), Internet Multimedia Services Architecture and Applications (IMSAA), IEEE International Conference on, 2009

3. Reichenbacher, T.: Adaptive concepts for a mobile cartography, Journal of Geographical Sciences, Acta Geographica Sinica, Vol.11 (Supplement), 2001

4. Reichenbacher, T.. Mobile Cartography-Adaptive Visualisation of Geographic Information on Mobile Devices, Verlag Dr Hut München, 2004

5. GDI-DE: Ein Leitfaden: GEODIENSTE im Internet, http://www.gdi-de.de/download/flyer_broschueren/Geodienste_Leitfaden_2Aufl.pdf Besucht: 29.06.2011

6. Android Developers Guide: What is Android?, http://developer.android.com/guide/basics/what-is-android.html Besucht: 29.06.2011

7. Becker, A., Pant, M.: Android 2, Dpunkt Verlag, 2010 8. Menninghaus, M.: Mobile Geodatenvisualisierung mit Android, Mobile und Ubiquitäre

Informationssysteme, Proceedings zur 5. Konferenz Mobile und Ubiquitäre Informationssysteme, 2010

9. Google Maps Api: Registrierungsformular, http://code.google.com/intl/de-DE/android/maps-api-signup.html Besucht: 29.06.2011

10. OpenGIS Web Map Service (WMS) Implementation Specification, http://www.opengeospatial.org/standards/wms Besucht: 29.06.2011

11.OpenGIS Sensor Observation Service, http://www.opengeospatial.org/standards/sos Besucht: 29.06.2011

12.GDI-DE: GeoRSS - Nachrichtenverarbeitung mit Raumbezug, http://www.gdi-de.org/thema2009/georss/ Besucht: 29.06.2011