CombINe. Ein mobiler Webservice zum community-basierten Administrieren von Informations- und Navigationsdiensten

Inhaltsverzeichnis

1 EINLEITUNG
1.1 MOTIVATION
1.2 ZIELSETZUNG
1.3 VORGEHENSWEISE

2 GRUNDLAGEN
2.1 EINORDNUNG
2.2 PERVASIVE / UBIQUITOUS COMPUTING
2.3 MOBILE COMPUTING
2.3.1 Definition
2.3.2 Symbian OS
2.3.3 Smartphones
2.3.4 Series
2.3.5 Mobilfunknetze
2.4 ORTSSENSITIVE DIENSTE
2.4.1 Definition
2.4.2 Positionierungstechniken
2.5 WEB SERVICES
2.6 MIXED REALITY
2.7 OPENGL
2.8 3D-COMPUTERGRAFIK
2.9 DATENSCHUTZ, PRIVATSPHÄRE UND SICHERHEIT
2.10 EXISTIERENDE PROJEKTE
2.10.1 Google Maps
2.10.2 Windows Live Local
2.10.3 Virtual Graffiti / Lobba

3 DER COMBINE PROTOTYP
3.1 ZWECK DES PROTOTYPS
3.2 ARCHITEKTUR
3.2.1 Endgerät
3.2.2 Positionsfinder
3.2.3 CombINe-Renderer
3.2.4 Streaming Server
3.2.5 CombINe-Server
3.2.6 Datenbank
3.2.7 Kommunikationsprotokoll in CombINe
3.2.8 Schnittstellen
3.3 AUFBAU DES SZENARIOS
3.3.1 Vorgehensweise
3.3.2 Auslesen der Kartendaten
3.3.3 Initialisieren des Szenarios
3.3.4 Zeichnen des Szenarios
3.3.5 Billboard-Objekte im Szenario
3.3.6 Texturierung
3.3.7 Bewegen im Szenario
3.3.8 Interaktion mit dem Szenario
3.4 TEXTURIERUNG AM MOBILEN ENDGERÄT
3.5 VIRTUELLE GRAFFITIS
3.5.1 Was sind virtuelle Graffitis?
3.5.2 Freie virtuelle Graffitis
3.5.3 Implementierung der freien virtuellen Graffitis
3.5.4 Objekt-Graffitis
3.5.5 Implementierung der Objekt-Graffitis
3.6 MIXED-REALITY-FEATURES
3.6.1 Einleitung
3.6.2 Look around-Funktion - Rundflug um die eigene Position
3.6.3 Picked Item - Objekt rotieren lassen
3.6.4 Overview - Überblick
3.6.5 Helligkeit
3.6.6 Demonstrationsfunktionen
3.7 COMMUNITY-DIENSTE
3.8 FILTER
3.8.1 Filter in CombINe
3.8.2 Benutzerprofil
3.8.3 Position
3.8.4 Zeit
3.9 NAVIGATIONSDIENSTE
3.9.1 Grunds ätzliches zu Navigationsm öglichkeiten in CombINe
3.9.2 Walk
3.9.3 Informationen durch Objekte im Szenario

4 ANWENDUNGSBEISPIEL

5 GPS UND DGPS
5.1 GPS
5.2 GPS-GRUNDLAGEN
5.3 AUFBAU DES GPS
5.4 VERMESSUNG DER ERDOBERFLÄCHE
5.5 BESTIMMUNG DER POSITION
5.6 DAS SIGNAL
5.7 FEHLERQUELLEN
5.8 DGPS
5.9 VERFÜGBARE ECHTZEIT-POSITIONIERUNGSDIENSTE
5.9.1 SBAS
5.9.2 SAPOS
5.9.3 Ntrip
5.10 ENTWICKLUNG EINES DGPS-SYSTEMS
5.11 FUNKTIONSWEISE
5.12 IMPLEMENTIERUNG
5.12.1 Aufbau
5.12.2 Parser
5.12.3 Nachrichten-Parser
5.12.4 Nachrichten-Boxen
5.12.5 Durchf ü hrung der GPS-Korrektur
5.13 ERGEBNISSE DER POSITIONSVERBESSERUNG

6 ZUSAMMENFASSUNG

7 AUSBLICK

Abbildungsverzeichnis

ABBILDUNG 1: THEMATISCHE EINORDNUNG DIESER ARBEIT

ABBILDUNG 2: WELLEN DES COMPUTING

ABBILDUNG 3: MARKTANTEILE DER SMARTPHONE-BETRIEBSSYSTEME

ABBILDUNG 4: VERFÜGBARE EDITIONEN DER SERIES

ABBILDUNG 5: ARCHITEKTUR EINES WEB SERVICES

ABBILDUNG 6: 3-TIER-ARCHITEKTUR

ABBILDUNG 7: REALITY-VIRTUALITY CONTINUUM

ABBILDUNG 8: SCHEMATISCHE DARSTELLUNG DER ZENTRALPROJEKTION

ABBILDUNG 9: 3D-OBJEKTE IN WINDOWS LIVE LOCAL

ABBILDUNG 10: STREET-SIDE ANSICHT

ABBILDUNG 11: VIRTUAL GRAFFITI / LOBBA

ABBILDUNG 12: ARCHITEKTUR VON COMBINE

ABBILDUNG 13: ELEMENTE DER CLIENT-SOFTWARE

ABBILDUNG 14: SCHEMATISCHE DARSTELLUNG DES INTERAKTIONSMENÜS IN COMBINE

ABBILDUNG 15: GPS-RECEIVER SYSONCHIP

ABBILDUNG 16: AUFBAU EINER SDP-DATEI VON COMBINE

ABBILDUNG 17: SCHNITTSTELLEN IN COMBINE

ABBILDUNG 18: AUSSCHNITT AUS DER KLASSENSTRUKTUR DER SZENARIODARSTELLUNG

ABBILDUNG 19: UNTEXTURIERTE GEBÄUDE

ABBILDUNG 20: PRINZIPSKIZZE DER BILLBOARDS

ABBILDUNG 21: DIMENSIONEN IN OPENGL

ABBILDUNG 22: ROTATIONEN IN OPENGL

ABBILDUNG 23: TRANSLATIONEN IN OPENGL

ABBILDUNG 24: TASTENBELEGUNG ZUM MANUELLEN POSITIONIEREN

ABBILDUNG 25: SCHEMATISCHE DARSTELLUNG DES ABLAUFS DER TEXTURIERUNG

ABBILDUNG 26: SZENARIO MIT ZU TEXTURIERENDER FLÄCHE

ABBILDUNG 27: KAMERAANSICHT

ABBILDUNG 28: COMBINE IM TEXTURIERUNGSMODUS

ABBILDUNG 29: FERTIG AUSGERICHTETER UMRISS

ABBILDUNG 30: ILLUSTRATION DER HÖHENANPASSUNG

ABBILDUNG 31: BOUNDING-BOX UND ECKPUNKTE

ABBILDUNG 32: FERTIGE TEXTUR

ABBILDUNG 33: SZENARIO NACH DER TEXTURIERUNG

ABBILDUNG 34: KATEGORIEAUSWAHL

ABBILDUNG 35: GRUPPENAUSWAHL

ABBILDUNG 36: FORMULAR ZUR GRAFFITI-EINGABE

ABBILDUNG 37: DARSTELLUNG VON FREIEN VIRTUELLEN GRAFFITIS

ABBILDUNG 38: DARSTELLUNG VON MEHREREN GRAFFITIS AN DER GLEICHEN POSITION

ABBILDUNG 39: ANZEIGE EINES GRAFFITIS

ABBILDUNG 40: ANZEIGE VON ZUSÄTZLICHEN GRAFFITI-DATEN

ABBILDUNG 41: ERZEUGUNG VON GRAFFITIS AUS DEN DATENBANKEINTRÄGEN

ABBILDUNG 42: BILLBOARDS DER OBJEKT-GRAFFITIS

ABBILDUNG 43: POSITIONIERUNG EINES OBJEKT-GRAFFITIS AUF EINER HÄUSERFRONT

ABBILDUNG 44: SZENARIO MIT OBJEKT-GRAFFITI

ABBILDUNG 45: FLUGBAHN UND BLICKRICHTUNG

ABBILDUNG 46: ILLUSTRATION EINES RUNDFLUGES MIT DER LOOK AROUND-FUNKTION

ABBILDUNG 47: REALISIERUNG DER KREISBAHN DER LOOK AROUND-FUNKTION

ABBILDUNG 48: AUSSCHNITT DER ROTATION EINES GEBÄUDES

ABBILDUNG 49: ANZEIGE EINES OVERVIEWS MIT HINTERLEGTEM LUFTBILD

ABBILDUNG 50: DEMONSTRATION VERSCHIEDENER HELLIGKEITSSTUFEN DES HORIZONTES

ABBILDUNG 51: VISUALISIERUNG ANDERER BENUTZER

ABBILDUNG 52: ILLUSTRATION DER DEMONSTRATIONSFUNKTION BUS

ABBILDUNG 53: VERKNÜPFEN UND DYNAMISCHES MITFÜHREN VON OBJEKTEN

ABBILDUNG 54: GRUPPEN-AUSWAHLMENÜ

ABBILDUNG 55: SZENARIENANSICHTEN IN VERSCHIEDENEN GRUPPEN

ABBILDUNG 56: WECHSELN EINER EINZELNEN TEXTUR

ABBILDUNG 57: SETZEN DES ZEIT-FILTERS

ABBILDUNG 58: BERECHNUNG DES DREHUNGSWINKELS IN DER WALK-FUNKTION

ABBILDUNG 59: KONTROLL-SEGEMENT DES GPS

ABBILDUNG 60: ABBILDUNG EINES BLOCK II-GPS-SATELLITEN

ABBILDUNG 61: UMLAUFBAHNEN DER SATELLITEN

ABBILDUNG 62: IDEALE KUGEL, GEOID UND ELLIPSOID

ABBILDUNG 63: POSITIONSBESTIMMUNG MIT 3 SATELLITEN

ABBILDUNG 64: BRECHUNG DES GPS-SIGNALS DURCH IONOSPHÄRE UND TROPOSSPHÄRE

ABBILDUNG 65: AUFBAU EINES DGPS-SYSTEMS

ABBILDUNG 66: ARCHITEKTUR VON NTRIP

ABBILDUNG 67: TRIMBLE GPS-RECEIVER MIT NTRIP-NUTZUNG ÜBER GPRS

ABBILDUNG 68: SCHEMATISCHER AUFBAU DES ENTWICKELTEN DGPS-SYSTEMS

ABBILDUNG 69: AUSLESEN UND BEREITSTELLEN DER SERVERDATEN

ABBILDUNG 70: AUFBAU DES TLM UND DES HOW

ABBILDUNG 71: AUFBAU UND DATENFORMAT DES SUBFRAMES

ABBILDUNG 72: ABWEICHUNG IN LONGITUDINALRICHTUNG IN METERN

ABBILDUNG 73: ABWEICHUNG IN LATITUDINALRICHTUNG IN METERN

ABBILDUNG 74: ABSOLUTABWEICHUNG IN METERN

Tabellenverzeichnis

TABELLE 1: NOTWENDIGE POSITIONIERUNGSGENAUIGKEITEN EINIGER ANWENDUNGEN

TABELLE 2: TABELLEN IN DER COMBINE-DATENBANK

TABELLE 3: FORMELN ZUM MANUELLEN BEWEGEN

TABELLE 4: FEHLERURSACHEN (TYPISCHE WERTE)

TABELLE 5: BINARY NACHRICHT

TABELLE 6: BINARY NACHRICHT

TABELLE 7: BINARY NACHRICHT

TABELLE 8: AUFBAU DER ICD-DATEN-MASKEN

TABELLE 9: AUSSCHNITT AUS DEN VERWENDETETEN KONSTANTEN

TABELLE 10: ZUSAMMENFASSUNG DER BOX-DATEN

1 Einleitung

1.1 Motivation

Tragbare Navigationssysteme werden immer beliebter. So stiegen im vergangenen Jahr die Absatzzahlen in Westeuropa stark an. Dem Marktforschungsinstitut GfK zufolge wurden im Jahre 2005 auf diesem Markt 2 Millionen mobile Navigationsgeräte verkauft. Zwar liegen die Zahlen für 2006 noch nicht vor, laut GfK wird sich diese Zahl mit prognostizierten 5 Millionen verkauften Exemplaren jedoch mehr als verdoppeln. Der Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. (BITKOM) schätzt, dass allein in Deutschland 2006 mehr als eine Million Geräte verkauft wurden (2005: 407.000 Exemplare).

Aktuelle Navigationssysteme sind jedoch primär für die Navigation in Automobilen ausgelegt. Sie sind entsprechend für hohe Geschwindigkeiten geeignet und so konzipiert, dass sie den Benutzer möglichst wenig vom Straßenverkehr ablenken. Das heißt auch, dass Navigationssysteme kaum Interaktion zulassen und keine Mixed Reality Funktionalitäten aufweisen. Entsprechend spärlich ist der Nutzen, den Fußgänger von Navigationssystemen haben, obwohl diese durchaus die Möglichkeit zur Interaktion mit diesem System hätten.

Parallel zu Navigationssystemen erfhrt auch die Mobilfunkbranche ein starkes Wachstum. Für fast jeden ist das Handy zu einem alltäglichen Gebrauchsgegenstand geworden, den er ständig mit sich trägt. 2005 gab es in Deutschland über 82 Millionen Mobiltelefone und die Tendenz ist weiter steigend[1]. Sowohl der Funktionsumfang als auch die Leistung moderner Mobiltelefone nimmt dabei ständig zu. Auch die Bandbreite, mit der Daten übertragen werden können, hat durch Technologien wie GPRS, HSCSD, EDGE und UMTS^[1] eine enorme Steigerung erlebt. Deshalb ist es nahe liegend, diese Geräte weit über Telefonie hinaus in unseren Alltag einzubinden.

Besonders vielfältige Einsatzmöglichkeiten bieten sogenannte Smartphones. Sie ermöglichen den Zugriff auf den kompletten Funktionsumfang eines Mobiltelefons in Verbindung mit adäquatem Speicher und entsprechender Rechenleistung. Des Weiteren erlauben sie es, zusätzliche Anwendungen zu installieren.

Nutzt man die Konnektivität des Smartphones aus, so ist mithilfe eines mobilen Webservices ein Navigationsdienst für Fußgänger denkbar, der über die Möglichkeiten der Autonavigation hinaus einen ortssensitiven Informationsdienst mit Mixed Reality Charakter realisiert. Dennoch unterliegt ein solcher Dienst für Mobiltelefone vielen Beschränkungen. Insbesondere die begrenzte Displaygröße und Rechenleistung erschweren die Visualisierung und die Interaktionsfähigkeit. Auch Fußgänger-adäquate Karten, etwa von Innenstädten, sind kaum verfügbar.

Ortssensitive Dienste erfordern ein Ortungssystem. Ein Dienst hierzu ist das NAVSTAR Global Positioning System (GPS). Dieses System hat im Außenbereich weltweite Abdeckung und ist frei verfügbar. Durch hohe Stückzahlen ist auch die erforderliche Hardware kostengünstig. Doch das GPS ist für die Dimensionen, in denen sich Fußgänger bewegen, recht ungenau. Deshalb ist eine Verbesserung der Positionierung mittels Differential GPS (DGPS) unter der Verwendung von Standard-Hardware wünschenswert.

1.2 Zielsetzung

Ziel dieser Arbeit ist es, die Realisierbarkeit eines mobilen Webservices zu zeigen, der das community-basierte Administrieren von Informations- und Navigationsdiensten durch ein (D)GPS-basiertes Visualisierungstool für Smartphones ermöglicht.

Der mobile Webservice soll aus Client- und Serverapplikationen bestehen. Die Clientapplikation soll auf einem gängigen Smartphone realisiert werden und über ein (D)GPS-System Informations- und Navigationsdienste ermöglichen. Um eine hohe Realitätsnähe zu erreichen, soll trotz der begrenzten Ressourcen auf dem Endgerät die Visualisierung in 3D erfolgen. Hierbei sollen die Informations- und Navigationsdienste sowie das Szenario interaktiv und vom Endgerät aus administrierbar sein.

Das System soll community-basiert implementiert werden. Das heißt, das System muss mehrere Benutzergruppen erlauben und diesen ermöglichen, Informationen in einen gemeinsamen gruppenspezifischen Datenpool einpflegen und auslesen zu können. Zusätzlich soll der Datenpool über Filterfunktionen einschränkbar sein, damit das System auch bei großen Benutzerzahlen überschaubar bleibt.

Da eine Positionierung über GPS in urbanem Gebiet mit großen Ungenauigkeiten behaftet ist, soll die Machbarkeit eines DGPS-Systems, das für Smartphones nutzbar ist, gezeigt werden.

Die Umsetzung der entwickelten Lösungen soll mit Standard-Hardware möglich sein.

1.3 Vorgehensweise

Nach der Einführung in Kapitel 1 sollen in Kapitel 2 zunächst eine Einordnung der Thematik sowie eine Beschreibung der Grundlagen und der verwendeten Technologien erfolgen. Am Ende dieses Kapitels wird eine Übersicht über bestehende Projekte gegeben und aufgezeigt, warum diese den gestellten Anforderungen nicht entsprechen.

Kapitel 3 beschreibt die Realisierung der Aufgabenstellung. Hier wird zuerst die entwickelte Gesamt-Architektur beschrieben und daraufhin werden einzelne Teillösungen aufgeführt. Danach werden die integrierten Funktionalitäten und deren Implementierung dargestellt.

In Kapitel 4 folgt ein Anwendungsbeispiel, das exemplarische Einsatzmöglichkeiten für die integrierten Funktionen schildert.

Kapitel 5 zeigt zuerst die Funktionsweise des GPS-Systems auf und erläutert dessen Schwächen. Daraufhin werden bestehende DGPS-Systeme beschrieben und es wird dargelegt, dass zurzeit kein geeignetes System zur Verfügung steht. Schließlich wird die prototypische Implementierung eines DGPS-Systems, das für Mobiltelefone geeignet ist, entwickelt.

Kapitel 6 fasst die Ergebnisse dieser Arbeit zusammen und vergleicht die Ergebnisse aus Kapitel 3 und 5 mit der Zielsetzung in Kapitel 1.

Zuletzt gibt Kapitel 7 einen Ausblick und Anregungen für zukünftige Projekte.

2 Grundlagen

2.1 Einordnung

In der IT-Branche erfahren derzeit speziell drei Technologien besonders schnelle Fortschritte: Ubiquitous oder Pervasive Computing, Mobile Computing und Ortssensitive Technologien ². Architektur, Technologien und Software, die in dieser Arbeit entwickelt und betrachtet werden sollen, finden sich in der Schnittmenge CombINe[2] (vgl. Abbildung 1).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Thematische Einordnung dieser Arbeit

Gemäß dem in der Informatik verbreiteten Grundsatz „divide and conquer“³ werden im Folgenden zuerst die einzelnen Teil-Technologien erörtert, die für die Bearbeitung der Aufgabenstellung relevant sind ( ➝„divide“). Nach den oben aufgeführten Teiltechnologien, werden ab Kapitel 2.5 weitere relevante Technologien diskutiert. Diese Ausführungen der Teilgebiete sollen die Basis zur Lösung der Aufgabenstellung bilden ( ➝„conquer“).

2.2 Pervasive / Ubiquitous Computing

Die Computer-Geschichte wird in der Literatur oftmals in drei Wellen unterteil (vgl. Abbildung 2). Die erste Welle zeichnete sich dadurch aus, dass viele Personen einen einzigen Computer bedienten, die zweite wird von Personal Computern dominiert und die dritte, derzeit am stärksten ansteigende Welle zeigt die Tendenz, dass eine Person viele Computer nutzt. Hält dieser Trend an, wird es auf lange Sicht überall Zugang zu Rechenkapazitäten geben. Er kann jedoch durch die Tatsache abgeschwächt werden, dass mit der dritten Welle die Portabilität der Geräte zunimmt, was auch zu einer besseren Ausnutzung der vorhandenen Ressourcen führt, aber nicht unbedingt die Anzahl der Geräte erhöht. Im Zusammenhang mit der dritten Welle werden oft die Begriffe Ubiquitous und Pervasives Computing verwendet, die diesen Umstand beschreiben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Wellen des Computing

“ A few years ago I found myself on a stage at the MIT Media Lab, arguing with Nicholas Negroponte in front of 700 people. Nick was rhapsodizing about a world in which computerized "intelligent agents" will answer our every need. To illustrate Nick's idea, an actor dressed as a butler introduced speakers and entertained the audience with snide remarks. The butler was fun, up to a point, but also distracting and intrusive. Fortunately, Nick was wrong about what to expect from the third wave in computing. The defining words will not be "intelligent" or "agent", but rather "invisible" and "calm" and "connection". ”

Mark Weiser

Principal Scientist Xerox PARC März 1996

Pervasives Computing und Ubiquitous Computing sind synonyme Begriffe, wobei der Begriff Pervasive Computing eher im industriellen Umfeld gebräuchlich ist. Der Ausdruck Ubiquitous Computing wurde von oben zitiertem Mark Weiser geprägt. Ubiquitous Computing beschreibt die Interaktion von Nutzern mit Umgebungen, die über Rechen- und Kommunikationsleistungen verfügen. Dabei sollen Computer in die Umwelt integriert sein und nicht als eigenes Objekt gesehen werden. Ubiquitous Computing ist jedoch keine Virtual Reality und kein persönlicher intelligenter Agent[4].

Die große Herausforderung liegt in der Integration von Ubiquitous Computing in die tagtägliche reale Welt. Ziel ist die Erweiterung der realen Welt. Dies sollte unmerklich und im Hintergrund geschehen[4], sodass der Benutzer seine Zeit mit der aktuellen Aufgabenstellung an sich und nicht mit der Bedienung des Computers verbringt.

Das Smartphone gibt dieser abstrakten Idee eine Gestalt[5]. Es unterstützt das oft für Ubiquitous Computing geforderte, kostengünstige Wireless Networking[4] und verkörpert das personifizierte abstrakte Handheld, das oft in den Visionen des Pervasive Computing gefordert wird[5]. Die Smartphone Technologie wird als Resultat der Konvergenz von Mobiltelefonen und PDAs angesehen und ist nach Ravi et al.[5]im Begriff „ubiquitous“, also allgegenwärtig zu werden.

Parallel bewegt sich auch die Software von Desktop Computern in neue unbekannte Territorien[6]. Dies beinhaltet viele neue Herausforderungen. Im Vergleich zu Desktop PCs unterscheidet sich das Erstellen und Verwalten von Software für Ubiquitous Computing[6]. Auch eine schlanke Integration von Diensten ist notwendig, da die Geräte, die typischerweise bei Ubiquitous Computing zu finden sind, eine, im Vergleich zu Desktop-PCs, geringere Leistungsfähigkeit besitzen.

2.3 Mobile Computing

2.3.1 Definition

Unter Mobile Computing⁴ versteht man die computerunterstützte Ausübung von Tätigkeiten, die an einem beliebigen variablen oder festen Einsatzort stattfinden[7]

2.3.2 Symbian OS

Im Jahre 1998 gründete der Softwareentwickler Psion das Unternehmen Symbian zusammen mit vier führenden Mobiltelefonherstellern: Nokia, Ericsson, Motorola und Panasonic. Dieses Unternehmen entwickelte das Betriebssystem Symbian OS, basierend auf Psion’s EPOC⁵. Symbian OS ist ein robustes Multi-Tasking Betriebssystem und wurde für die besonderen Aspekte von Mobiltelefonen, wie z.B. die limitierte Speichergröße und die begrenzte Geschwindigkeit der CPU entwickelt. Es weist zahlreiche Charakteristika auf, die speziell für ein Mobile Computing Betriebssystem wichtig sind. Einige dieser Charakteristika sind:

- Stabilität und Sicherheit: Ein Systemabsturz kann fatal für den Benutzer und somit für die Akzeptanz des Mobiltelefons sein. Daher muss das Betriebssystem sehr stabil sein[8]. Energieverbrauch: Da einem mobilen Gerät nur begrenzte Energie zur Verfügung steht, muss das Betriebssystem Ressourcen sparen[8].
- Echtzeit-Betriebssystem: Die Telefoneigenschaften des Gerätes brauchen definierte und möglichst kurze Reaktionszeiten, die denen eines Echtzeitbetriebssystem ähnlich sind [8][9].
- Integrierte Multi-Mode Mobiltelefonie: Symbian OS integriert Rechenleistung mit Mobiltelefonie, unterstützt komplexe Rechenoperationen, moderne Daten- und Telefonieservices auf einem mobilen Endgerät[10].
- Offene Anwendungsumgebung: Anwendungen, die in unterschiedlichen Programmiersprachen wie z.B. C++ (für Symbian OS), Java oder Python implementiert wurden, können in Symbian OS eingesetzt werden[10].
- Offene Standards und Interoperabilität: Symbian OS bietet Kern-APIs, die in allen Symbian OS Mobiltelefonen verfügbar sind. Dies ermöglicht es, Programme, die unter Verwendung dieses Kernsets geschrieben wurden, auf vielen Telefonen zu verwenden, ohne dass eine Neu-Kompilierung notwendig ist[10].
- Multi-Tasking: Symbian OS unterstützt Multi-Tasking. Die Verwendung sog. active objects erlaubt es, Programme die Multi-Threading erfordern, mit nur einem Thread verschiedene aktive Objekte zu erzeugen[10].
- Vollständig objektorientiert: Symbian OS wurde unter Verwendung objektorientierter Techniken entwickelt und erlaubt objektorientierte Programme[10].
- Flexibles User-Interface: Die graphische Benutzeroberfläche in Symbian OS ist flexibel. So entwickelte Nokia für seine Mobiltelefone eine eigene graphische Benutzeroberfläche mit dem Namen „ Avkon “.[10]

2.3.3 Smartphones

Da Software auf Mobiltelefonen, genau wie auf PCs, installiert werden kann, bietet sich aufgrund der Portabilität und Kommunikationsmöglichkeiten dieser Geräte eine Vielzahl neuer Einsatzmöglichkeiten. Mobiltelefone, auf denen Software installiert werden kann, waren schon 2001 mit Java MIDlets⁶ verfügbar. Java läuft jedoch immer auf einer virtuellen Maschine, was Hardware-nahe Funktionen wie SIM-Kartenzugriff oder den Zugriff auf das Adressbuch erschwert. Insbesondere die Kommunikationsschnittstellen wie z.B. das Bluetooth-Interface sind bei Java MIDlets stark eingeschränkt.⁷

Aus diesem Grund fanden die ersten Symbian-Telefone Nokia 7650 und Sony Ericsson P800, die 2002 erschienen sind, große Beachtung. Diese Telefone gelten als die ersten erhältlichen Smartphones[11].

Es ist jedoch schwierig zu spezifizieren, welche Charakteristika aus einem Mobiltelefon ein Smartphone machen. Im Allgemeinen besitzen Smartphones ein Farbdisplay, Applikationen wie Email-Funktionalität, Kalender, Adressbuch etc.[11]. Außerdem ist der Funktionsumfang durch die Installation von zusätzlichen Programmen durch den Benutzer erweiterbar. Smartphones besitzen also nicht wie andere Mobiltelefone einen vordefinierten Umfang an Anwendungen, der nur begrenzt z. B. durch Java-Anwendungen erweitert werden kann.

Smartphones verfügen meist über ein Betriebssystem eines Drittanbieters. Neben Symbian OS gibt es das Microsoft Windows Powered Smartphone (WPS), Palm OS und andere mehr. Dem britischen Marktforschungsinstitut Canalys zu Folge liegt der Marktanteil von Smartphones mit Symbian OS im Jahre 2005 bei über 60% (vgl. Abbildung 3).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Marktanteile der Smartphone-Betriebssysteme 2005[12]

2.3.4 Series 60

Series 60 ist eine von Nokia entwickelte Software-Plattform für Smartphones, die auf

Symbian OS aufsetzt. Es ist momentan das am weitesten verbreitete Referenz-Design mit Symbian OS[13]. Die Plattform ist für die Einhandbedienung gedacht und kommt mit dem Ziffernblock, einer Navigationstaste und Sondertasten zur Zeicheneingabe aus[13]. Derzeit sind drei Editionen verfügbar. Die erste Edition erschien im Jahre 2002 und war zugleich die erste Symbian OS-Version.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Verfügbare Editionen der Series 60[14]

Die zweite Edition der Series 60 Plattform war erstmal mit dem 2003 erschienenen Nokia 6600 verfügbar. Sie wurde seither um drei Feature-Packs erweitert, die neue Funktionalitäten ermöglichten ohne die Kompatibilität der Edition einzuschränken (vgl. Abbildung 4). Die zurzeit neueste dritte Edition verfügt, neben den Funktionen der zweiten, über verbesserte Funktionalitäten für Firmen und für Multimedia. Eine neue Plattformarchitektur soll hierbei zu mehr Flexibilität und höherer Sicherheit führen (vgl. Abbildung 4).

2.3.5 Mobilfunknetze

Der Begriff Mobilfunknetz bezeichnet die technische Infrastruktur, um Sprache und Daten bidirektional zwischen einem Sender und einem Empfänger zu übertragen. Dies geschieht durch ein wabenartiges Netz von Basisstationen, die über die sogenannte Luftschnittstelle (i.e. Mobilfunk) Kontakt zu Mobiltelefonen (Handys) herstellt. Die Basisstationen sind kabelgebunden mit Funkvermittlungsstellen verbunden, die diese Daten weiter vermitteln.

Die Mobilfunknetze in Deutschland werden in drei Generationen unterteilt:

- Erste Generation (1G): Die erste Generation umfasst das A-Netz (1958/59-1977), B- Netz (1972-1994) und C-Netz (1985-2000)[15]. Diese Netze sind analog, wodurch sie eine geringe Bandbreitenausnutzung und dadurch eine beschränkte Teilnehmerkapazität besitzen.
- Zweite Generation (2G): Mithilfe des digitalen Global System of Mobile Communication (GSM) wird seit 1992 das D-Netz und seit 1993 das E-Netz in Deutschland betrieben. Diese Netze erlauben Neuerungen wie Verbindungsübergaben (Handover) und eine Datenrate von bis zu 9,6 kbit/s. Mithilfe von weiterentwickelten Techniken (oft auch als 2,5G bezeichnet) wie High Speed Circuit Switched Data (HSCSD) oder General Packet Radio Service (GPRS) ist es auf GSM-Basis möglich, höhere Bandbreiten bei der Datenübertragung zu erreichen. Das Enhanced Data Rates for GSM Evolution (EDGE) ist eine Weiterentwicklung von GPRS und HSCSD. Es erlaubt Bandbreiten bis zu 384 kbit/s und wird als Vorstufe / Ergänzung zur dritten Generation des Mobilfunks gesehen[15]. Dritte Generation (3G): Der seit 2003 schrittweise eingeführte Standard für 3G ist in Europa das Universal Mobile Telecommunication System (UMTS). Es ist datenoptimiert und ermöglicht Übertragungsraten bis 2 Mbits/s[7]. Auch Kapazitätsprobleme bei der Sprachübertragung sollen durch UMTS vermindert werden.

In Deutschland werden zurzeit Mobilfunknetze der zweiten und dritten Generation betrieben. Das C-Netz wurde als letztes der ersten Generation 2000 abgeschaltet.

2.4 Ortssensitive Dienste

2.4.1 Definition

Der stetige Fortschritt in der kabellosen Kommunikation und in den Positionierungstechnologien machen Ortssensitive Dienste möglich. Viele neue Anwendungen für diese Technik stehen kurz vor dem Durchbruch. Zur Begriffsklärung ist im Folgenden die Definition der International Standardization Organisation (ISO) angeführt:

Ein Ortssensitiver Dienst ist ein “… service, query or process whose return or other property is dependent on the location of the client requesting the service and / or of some other thing, object or person ” (ISO TC 211).

Der Begriff Ortssensitive Dienste beschreibt also Anwendungen, die geographische Positionen mit Diensten und Informationen verbinden[16]. Nach einer Studie von Vodaphone kann man bei Ortssensitiven Diensten zwei Typen unterscheiden:

- Aktive Dienste: Der Benutzer initiiert die Positionierung (z.B. finde n ä chstes … - Anwendungen)
- Passive Dienste: Eine dritte Partei lokalisiert die Position des Ortssensitiven Dienstteilnehmers (z.B. Find-a-Friend Funktionalität)

Als dritte Dimension ergänzen Ortssensitive Dienste die beiden Dimensionen Benutzerprofil und Zeit für kundenspezifische Dienste[17].

2.4.2 Positionierungstechniken

Im Laufe der letzten Jahre wurden viele Systeme zur Positionierung entwickelt[18]. Hierzu existieren mehrere Ansätze mit unterschiedlichen Problemstellungen. Die eigene Position ist eine sehr persönliche und signifikante Information. Deshalb ist sie ein sehr gutes Attribut zur Personalisierung[9]und ein wichtiger Kontextparameter[19]. Beinahe jede Information ist mit einer Position verknüpfbar. Um diese jedoch zu bestimmen, ist ein Positionierungsdienst notwendig. Nach Hightower et al.[18] kann man drei Haupttechniken der Positionierung unterscheiden:

- Triangulierung: Triangulierung benutzt die geometrischen Eigenschaften von Dreiecken, um die aktuelle Position zu berechnen. Dabei kann man zwischen Lateration und Angulation unterscheiden. Die Lateration berechnet die Position durch das Messen der Distanz von verschiedenen Referenzpositionen. Angulation ist ähnlich der Lateration, benutzt aber statt der Distanzen die Winkel zu Referenzpositionen[20]. Proximation: Eine Proximations-Positionierungstechnik bestimmt die „Nähe“ eines Objektes zu einer bekannten Position[20].
- Szenenanalyse: Die Ortsbestimmungstechnik der Szenenanalyse bestimmt die Position durch Beobachtung des Szenarios von einem Betrachtungspunkt. Um die charakteristischen Eigenschaften einer Szene erkennen zu können, muss diese für gewöhnlich vereinfacht werden[20].

Keine dieser Ortsbestimmungstechniken erfüllt die Anforderungen aller Situationen perfekt[21]. Um eine genauere Positionierung durchzuführen, muss ein höherer technischer Aufwand betrieben werden. Deshalb ist es wichtig, die richtige Positionierungstechnik zu wählen und diese so akkurat wie nötig und einfach wie möglich zu halten. Ericsson erforschte diesen Umstand und entwickelte ein Schema für die notwendige Genauigkeit (vgl. Tabelle 1). Einen Überblick über den Stand der Technik der Positionierung wird in Anhang A gegeben.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Notwendige Positionierungsgenauigkeiten einiger Anwendungen[16]

2.5 Web Services

Nach Eberhart et al.[22] ist ein Web Service eine Schnittstelle für den netzbasierten Zugriff auf eine Anwendungsfunktionalität, die vollständig auf Standard-Internet-Technologien basiert. Dies verdeutlichen die oben genannten Autoren anhand der in Abbildung 5 gezeigten Architektur und definieren: „Ein Web Service unterstützt die direkte Interaktion mit anderen Softwareagenten durch XML-basierte Nachrichten, die über Internetprotokolle ausgetauscht werden.“[22].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Architektur eines Web Services[22]

Web Services werden oft als „N-Tier-Anwendungen“ mit N = 2, 3, 4 entwickelt[22]. Jedes „Tier“, d.h. jede Ebene hat eine Aufgabe, wie in Abbildung 6 beispielhaft visualisiert wird. Die Vorteile dieser Architektur liegen in der geringeren Komplexität der einzelnen Teile, in der Verteilung von Implementierungsaufgaben, in der erhöhten Flexibilität bei der Verteilung der einzelnen Aufgaben und in der erleichterten Wartbarkeit und Skalierbarkeit[22].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: 3-Tier-Architektur[22]

2.6 Mixed Reality

Der Begriff Mixed Reality bezeichnet Umgebungen, die die reelle, physikalische Welt mit einer virtuellen Welt vermischen[23][24]. Um das gesamte Spektrum an möglichen Konstellationen zwischen Realität und Virtualität zeigen zu können, stellen Milgram et al. [25]eine Skala vor, die sie Reality-Virtuality Continuum nennen (vgl. Abbildung 7). Dabei werden die Begriffe Augmented Reality und Augmented Virtuality anhand des Anteils an realen und virtuellen Daten unterschieden. In diesem Zusammenhang stellt sich in Bezug zu Virtualität ausgegangen werden soll. Um die Problematik differierender Interpretationen zu vermeiden, wird im Folgenden der allgemeine Begriff Mixed-Reality verwendet, der die gegebene Thematik sehr gut umschreibt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Reality-Virtuality Continuum[25]

2.7 OpenGL

Die Open Graphics Library OpenGL beschreibt eine Spezifikation für 2D und 3D- Computergrafik[26]. OpenGL ist ein „software interface to graphics hardware“[27]. Die eigentliche Implementierung des OpenGL-APIs erfolgt jedoch in den Grafikkartentreibern, die dann die entsprechenden Befehle auf der Grafikkarte ausführen. Das Standard-API von OpenGL enthält etwa 250 Befehle zur Darstellung von 3D-Szenen in Echtzeit.

Entstanden ist OpenGL 1992 aus dem von Silicon Graphics (SGI) entwickelten IRIS GL[7] das nur auf spezieller Hardware lauffähig ist.

Eine Alternative zu OpenGL ist DirectX von Microsoft[28] DirectX unterstützt ab der Version 3.0 die 3D-Funktionalität. Es ermöglicht genau wie OpenGL einen Direktzugriff auf die Hardware der Grafikkarte[28].

Ein zusätzlicher Bestandteil von DirectX ist DirectSound, das Soundeffekte wie Raumklang ermöglicht. Die zum Zeitpunkt der Entstehung dieser Arbeit aktuelle Version ist DirectX 9.0c.

DirectX benötigt jedoch anders als OpenGL einen Rechner mit einem Microsoft WindowsBetriebssystem.

2.8 3D-Computergrafik

Ein Raum wird in der Elementargeometrie als „ein sich in drei Dimensionen (Länge, Breite, Höhe) ohne feste Grenzen ausdehnendes Gebiet“[7] definiert, wobei die Länge auch als Tiefe bezeichnet wird. Um einen Bezug im Raum zu haben, definiert man ein Koordinatensystem und ordnet jeder Dimension eine Achse zu. Bei einem Kartesischen Koordinatensystem stehen diese Achsen senkrecht zueinander. Den Schnittpunkt der Achsen bezeichnet man als Nullpunkt oder Ursprung. Objekte im Raum werden durch Knoten mit drei Koordinaten bestimmt, die die Lage des Knoten im Koordinatensystem eindeutig festlegen.

Um dreidimensionale Objekte auf einem zweidimensionalen Bildschirm (z.B. eines Mobiltelefons) darstellen zu können, müssen sie von 3D auf 2D projiziert werden. Zwei Grundtypen der Projektion werden unterschieden, die Parallelprojektion (orthografische Projektion) und die Zentralprojektion (perspektivische Projektion)[27].

Bei der Zentralprojektion laufen alle Projektionsstrahlen zu einem gemeinsamen Projektionszentrum O (vgl. Abbildung 8). Dabei schneiden sie auf dem Weg vom abzubildenden Objekt die Bildebene B und geben es dort wieder.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Schematische Darstellung der Zentralprojektion

Die Parallelprojektion nimmt ein unendlich weit entferntes Projektionszentrum an, wodurch die Projektionsstrahlen senkrecht zur Bildebene verlaufen.

2.9 Datenschutz, Privatsphäre und Sicherheit

Obwohl Datenschutz nicht Thema dieser Arbeit ist, soll erwähnt werden, dass die vorgestellten Technologien wie Mobile Computing und insbesondere Ortssensitive Dienste datenschutzrechtliche Bedenken hervorrufen. Die Übermittlung der eigenen Position ist in Verbindung mit Benutzer-Profilen ein Risiko für die Privatsphäre.

Auch Spam-Problematiken und Probleme mit unerwünschter Werbung können in diesem Zusammenhang auftreten.

Als Reaktion auf diese potentiellen Risiken behandelt das Europa-Parlament diese Themen in seiner Directive on Privacy and Electronic Communications[9]

2.10 Existierende Projekte

2.10.1 Google Maps

Google Maps ist ein im Februar 2005 gestarteter Dienst von Google[29]. Er ermöglicht es, geografische Orte, Straßen und Objekte zu suchen, um deren Position dann auf einer Karte oder auf einem Satelliten-/ Luftbild anzuzeigen.

Zur Integration dieser Funktionalitäten in eigene Anwendungen bietet Google Maps ein kostenloses API an, das eine breite Palette an Funktionen bietet. Man benötigt hierzu einen API Key, der nach einer Registrierung bei Google kostenlos erhältlich ist. Google Maps bietet zwar eine Handy-Version für mobile Webbrowser an, es besitzt jedoch keine dreidimensionale Darstellung des Szenarios. Es ist nur möglich, eine Position in der Kartenansicht (ggf. mit hinterlegtem Luftbild) zu zeigen. Google Maps ist auch nicht community-basiert und bietet keine direkte Schnittstelle zu Positionierungsdiensten wie GPS.

2.10.2 Windows Live Local

Windows Live Local ist Teil der Windows Live Produkt-Gruppe[30]. Es ist ein Web-basierter Karten-Service, der ähnlich wie Google Maps Landkarten und Satellitenbilder/Luftbilder anbietet. Zudem sind Gebäude von ausgewählten Städten texturiert und in 3D verfügbar. Diese Technologie demonstriert Live Local anhand einiger, in der Karte ausmodellierter, 3D- Objekte (vgl. Abbildung 9). Die Anzahl an modellierten Objekten ist jedoch sehr beschränkt und der Aufwand, diese zu erstellen, ist sehr hoch. Zu Live Local existiert eine Version für den Browser von Mobiltelefonen. Dieser erlaubt jedoch keine 3D-Darstellung. Das System ist auch nicht community-basiert und hat keine integrierte Positionierungsschnittstelle.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: 3D-Objekte in Windows Live Local[30]

Die Street-side Ansicht bietet einen noch detaillierteren und realistischeren Einblick und ist derzeit als Technologie-Vorschau verfügbar[31]. Hierbei kann ein Automodell auf der Stadtkarte bewegt werden (vgl. Abbildung 10, unten). Ausgehend von dessen Position wird die entsprechende Ansicht (geradeaus, links und rechts) visualisiert (vgl. Abbildung 10, oben).

Die Ansichten bei dieser Technologie-Vorschau basieren auf Video-Sequenzen, aus denen Bilder je nach Position angezeigt werden. Diese Technik bedeutet jedoch, dass die gezeigten Bilder in ihrer Perspektive fest sind und somit nur von der Position, von der sie aufgenommen wurden, mit der realen Ansicht übereinstimmen; es ist keine perspektivische Anpassung möglich. Eine mobile Version dieser Technologie gibt es derzeit nicht. Zudem untersagt Microsoft ausdrücklich die Daten außerhalb von Live Local zu verwenden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Street-side Ansicht[31]

2.10.3 Virtual Graffiti / Lobba

Virtual Graffiti / Lobba ist ein Anwendungskonzept des UMTS-Doit Projektes, das von T- Systems International GmbH und dem Deutschen Forschungszentrum für Künstliche Intelligenz DFKI GmbH durchgeführt wurde[32]. Es stellt eine mobil zugängliche, öffentliche Datenbank-Struktur dar, die ortsbezogen Informationen speichern und wieder ausgeben kann. Mithilfe von GPS kann der Benutzer die zu seinem jeweiligen Aufenthaltsort gespeicherten textuellen Informationen abrufen und auch selbst textuelle Informationen und Kommentare zum betreffenden Ort ablegen (vgl. Abbildung 11)[32].

Das Virtual Graffiti / Lobba-Konzept ermöglicht ausschließlich 2D-Navigation. Es bietet zwar die Möglichkeit virtuelle Graffitis zum Szenario hinzuzufügen, erlaubt es dem Benutzer jedoch nicht, auf die Szenario-Daten Einfluss zu nehmen. Eine Community-Unterstützung bietet Virtual Graffit / Lobba nicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Virtual Graffiti / Lobba[32]

3 Der CombINe Prototyp

3.1 Zweck des Prototyps

Um die gestellte Aufgabe umzusetzen, werden Vorgehensweisen ausgewählt und entworfen, die zu dem in dieser Arbeit entwickelten Prototyp führen. Durch ihn soll verdeutlicht werden, dass und wie ein Service zum community-basierten Administrieren von Informations- und Navigationsdiensten durch ein (D)GPS-basiertes Visualisierungstool für Smartphones realisiert werden kann. Der Prototyp wird CombINe (Community-based Information and Navigation Service) genannt.

3.2 Architektur

Für den im Rahmen dieser Diplomarbeit entstandenen Prototyp wurde die in Abbildung 12 beschriebene Architektur entwickelt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Architektur von CombINe

Die einzelnen Teile dieser Architektur können über viele verschiedene Techniken und Wege umgesetzt werden. Deshalb werden im Folgenden die im Rahmen dieser Arbeit ausgewählten, entwickelten und implementierten Komponenten erklärt. Zudem wird begründet, warum sie auf diese Weise umgesetzt werden.

Die einzelnen Komponenten der Architektur sind modular aufgebaut. So können die Teile CombINe-Server, CombINe-Renderer, Streaming-Server und CombINe-Database sowohl auf einem Rechner, als auch in einem Netzwerk verteilt, auf verschiedenen Systemen betrieben werden und unter Beachtung der entsprechenden Schnittstellen ausgetauscht und weiterentwickelt werden.

Die oben genannten Komponenten sollen als zentrale Server-Einheit realisiert werden und für eine Vielzahl von Benutzern mit mobilen Endgeräten zugänglich sein.

3.2.1 Endgerät

Als Endgerät wurde ein Nokia 6630 mit Symbian OS der Series 60 Plattform ausgewählt. Dieses Endgerät verfügt mit einem mit 220 MHz getaktetem ARM-926 32-bit RISC- Prozessor⁸ über ausreichend Rechenleistung. Der interne 10 MB Speicher lässt sich durch einen Reduced Size MultiMediaCard-Slot erweitern. Außerdem verfügt es über ein 176 x 208 Pixel großes Farbdisplay mit 65.536 Farben. Weitere Gründe für die Wahl dieses Mobiltelefons sind essentielle Eigenschaften für CombINe wie eine integrierte 1,3 Megapixel-Kamera, die UMTS-Fähigkeit und die Bluetooth-Schnittstelle. Das Navikey-User- Interface von Nokia ermöglicht eine Einhandbedienung und erlaubt auch eine Nutzung bei Eigenbewegungen und in bewegten Umgebungen. Des Weiteren ist die Anschaffung dieses sowie kompatibeler Handys der Series 60 kostengünstig; sie erfreuen sich dementsprechend einer weiten Verbreitung und großen Beliebtheit. Eine detaillierte Beschreibung der technischen Daten findet sich in Anhang B.

Die Software des Endgerätes basiert, wie auch der in Kapitel 3.2.4 beschriebene Streaming- Server, auf dem am DFKI im Rahmen des Projektes UMTS-Doit entwickelten, interaktiven adaptiven Streaming[32]. Bei diesem Verfahren wird die Rechenleistung grafischer Darstellungen von einem externen Streaming-Server erbracht. Lediglich die reine Bildschirmausgabe wird per Breitband-Stream auf das mobile Endgerät übertragen und dort dargestellt. Die Möglichkeit zur Interaktion besteht beim interaktiven adaptiven Streaming dadurch, dass der Benutzer gleichzeitig beim Betrachten des Streams über verschiedene Eingaben auf dem mobilen Gerät den Streaming-Server beeinflussen kann[32].

Darauf aufbauend wurde für das CombINe-System auf Clientseite eine Software entwickelt, die das realitätsnahe 3D-Szenario von CombINe auf dem Endgerät anzeigt und darüber hinaus über die Tasten des Mobiltelefons, über das Interaktionsmenü oder über GPS manipulierbar gemacht (vgl. Abbildung 13).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Elemente der Client-Software

Beim Starten der CombINe-Applikation auf dem Mobiltelefon verbindet diese den integrierten Videoplayer mit dem CombINe-Streaming-Server und gibt den benutzerspezifischen Stream wieder. Eingaben werden über HTTP-Befehle (Spezifizierung siehe Kapitel 3.2.7) an den CombINe-Server weitergegeben. Über ein Interaktionsmenü kann der Benutzer aus der Streaming-Ansicht heraus auf die Funktionen von CombINe zugreifen. Die Menüführung ist schematisch in Abbildung 14 als Übersicht dargestellt; auf die Funktionen wird im Einzelnen in den folgenden Kapiteln näher eingegangen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Schematische Darstellung des Interaktionsmenüs in CombINe

Entwickelt wird die Endgeräte-Software mithilfe der S60-Plattform SDK für Microsoft Visual Studio.net. Die Applikation ist entwickelt für Symbian OS, Version 8.0a für Series 60 2nd Edition mit Feature Pack 2.

3.2.2 Positionsfinder

Aufgrund der beinahe weltweiten, kostenlosen Verfügbarkeit des GPS wird dieses als Positionsfinder in CombINe genutzt. Als Empfangsmodul wurde ein Bluetooth-GPS-Receiver mit SiRF III-Chipsatz der Firma SysOnChip gewählt (vgl. Abbildung 15).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 15: GPS-Receiver SysOnChip

GPS-Receiver mit SiRF-Chipsatz sind weit verbreitet und kostengünstig. Auf die Positionierung in CombINe wird in Kapitel 5 näher eingegangen. Das Datenblatt des Receivers ist im Anhang C einzusehen.

3.2.3 CombINe-Renderer

Die virtuelle Welt von CombINe ist in C++ implementiert. C++ bietet eine schnelle, speichereffiziente und objektorientierte Umgebung, was für die Darstellung der virtuellen Welt von CombINe sehr wichtig ist. Als Entwicklungsumgebung für C++ wurde Dev-C++ von Bloodsheet verwendet. Es unterstützt im Gegensatz zu z.B. Visual Studio.net GCC- basierte Compiler.

Um die in C++ implementierte virtuelle Welt in den in Kapitel 3.2.5 beschriebenen Python- Server zu integrieren, wird der Code zu einer Dynamic Link Library (DLL)⁹ kompiliert. Die DLL wurde mithilfe der Minimalist GNU für Windows minGW¹⁰ Version 3.4.2 erzeugt. Diese DLL lässt sich durch den Simplified Wrapper Interface Generator (SWIG) in Python einbinden. SWIG ist ein Werkzeug zum automatischen Generieren von Wrapper-Code. Es dient der Erstellung von Schnittstellen für C/C++ Programme und Bibliotheken zu Skriptsprachen. Der CombINe-Renderer muss neben der Erzeugung des Szenarios auch Interaktionen mit diesem zulassen. Deshalb muss das Interface zwischen Python und C++ zahlreiche Funktionen beinhalten. Definiert wird die Schnittstelle in der Datei combineogl.i. Dort sind z.B. Konstruktor, Destruktor, Funktionen für Bewegungen, Hinzufügen/Ändern von Texturen, Hinzufügen/Ändern von virtuellen Graffitis etc. definiert. Eine detaillierte Beschreibung aller Funktionen der Schnittstelle gibt Anhang D. Eine Besonderheit stellt jedoch die Implementierung der Übergabe des gerenderten Bildes dar. Die Bilddaten werden vom CombINe-Renderer in einem unsigned char*-Feld erzeugt. Unsigned char ist hier ein 8- bit großer Datentyp, der die Zahlen 0-255 darstellen kann. Der Export dieses Datentyps zu Python stellte sich als kompliziert heraus, da es in Python kein Pendant hierzu gibt. Es gibt jedoch in SWIG sogenannte Typemaps, um dieses Problem zu lösen. Die für die Übertragung des unsigned char*-Feldes geschriebene Typemap in der Interface-Datei combine.ogl wird im Folgenden dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Die Funktion PyString_FromStringAndSize transformiert einen String (i.e. char*-Feld) data mit der Länge size zu einem Python-String. Es ist noch erwähnenswert, dass die Funktion PyString_FromStringAndSize eine Kopie des char*-Feldes anlegt; man benötigt also keinen zusätzlichen Puffer, um die Pointer-Daten „einzufrieren“.

Das Konstrukt binary_data muss nun anstatt des unsigned char*-Feldes als Datentyp in C++ ausgegeben werden. Das geschieht mit folgender Typedef:

Abbildung in dieser Leseprobe nicht enthalten

Mithilfe dieses Interfaces kann nun die Bilddatei als String von C++ zu Python exportiert werden.

Erzeugt wird das Szenario durch OpenGL. Das Szenario wird hierbei nicht zwingend auf der Rechner-CPU gerendert, es kann auch die Graphics Processing Unit (GPU) der Grafikkarte verwendet werden. Die GPU ist speziell zum schnellen und effizienten Erzeugen dreidimensionaler Objekte entwickelt worden. Zum Rendern des Szenarios in C++ wird die OpenGL Utility Library GLU verwendet, die aufsetzend auf OpenGL Grafikfunktionen höherer Ebene bietet. Des Weiteren wird das OpenGL Utility Toolkit (GLUT) verwendet. GLUT ermöglicht z.B. die Erstellung von Fenstern oder eröffnet Funktionen zum Zeichnen geometrischer Objekte.

3.2.4 Streaming Server

Das verwendete Streaming-Prinzip basiert auf der Streaming-Technologie des DFKI aus dem Projekt UMTS-Doit. Der eigentliche Stream wird dabei vom Darwin Streaming Server der Firma Apple erzeugt. Der Darwin Streaming Server ist eine Open Source Version des Quick Time Streaming Servers von Apple. Er erlaubt es, Streaming-Medien über das Internet zu Clients zu schicken und benutzt hierfür die Standard-Protokolle RTP und RTSP.

Der Streaming-Server erhält einen Videostream vom Combine-Server in einem mittels XVID komprimierten Format. Außerdem erhält er für jeden Stream eine Datei zur Beschreibung des Streams, d.h. Videogröße, Framerate etc., das sogenannte Session Description Protocol (SDP) Datei (vgl. Abbildung 16). Für jeden Stream wird ein eigener Port {PORT} und die QuellenIP-Adresse {IP} eingetragen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 16: Aufbau einer SDP-Datei von CombINe vor dem Eintragen der IP und des Ports

Auf diese Weise ist es auch möglich, Streams an Endgeräte mit verschiedenen Eigenschaften zu senden, was jedoch in der aktuellen Version von CombINe nicht realisiert wurde.

3.2.5 CombINe-Server

Zur Steuerung der einzelnen Komponenten und als Schnittstelle zwischen Server und Endgerät dient ein in Python realisierter Server, der CombINe-Server. Python ist eine sehr übersichtliche Programmiersprache, besitzt aber dennoch einen sehr breiten Funktionsumfang. Für CombINe wurde die Version 2.4.2 verwendet.

Beim Starten des CombINe-Servers wird eine Instanz des CombINe-Renderers angelegt. Diese erzeugt eine dreidimensionale Darstellung des Szenarios an der Startposition.

Gleichzeitig wird eine Instanz des XVID-Encoders gestartet, der das gerenderte Bild über den Streaming-Server zum Endgerät sendet. Zentrale Schaltstelle des CombINe-Servers ist der integrierte Webserver. Nachdem der Webserver gestartet wurde, wartet dieser auf dem angegebenen Port auf einkommende HTTP/1.1-konforme¹¹ POST- oder GET-Requests. Hat der Server ein Request empfangen und den Befehl identifiziert, ruft er die entsprechende Event-Handling-Methode auf. Das Protokoll wird ausführlich in Kapitel 3.2.7 beschrieben. Der CombINe-Server unterstützt verschiedene Modi und steuert entsprechend dem gewählten Modus die übrigen Komponenten von CombINe an. Implementiert sind folgende Modi:

Normalmodus

Texturierungsmodus texturemode

Graffitimodus graffitimode

3.2.6 Datenbank

Als Datenbank-System wird eine MySQL-Datenbank verwendet. MySQL ist ein SQLDatenbankverwaltungssystem der schwedischen Firma MySQL AB¹². Es steht unter der GNU General Public License ¹³ (GPL) zur Verfügung und kann so kostenlos in CombINe integriert werden. MySQL ist für viele Unix-Varianten, Linux und Windows implementiert und bietet die für CombINe erforderlichen Schnittstellen zu C++ und Python.

Die CombINe-Datenbank beinhaltet insgesamt sieben Tabellen. Folgende Tabelle 2 bietet eine Übersicht über die Namen, den Zweck und die Kapitel, in denen die Verwendung der Tabellen deutlich wird:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Tabellen in der CombINe-Datenbank

Detaillierte Design-Beschreibungen der einzelnen Tabellen können in Anhang E eingesehen werden.

Die Schnittstelle von Python zu MySQL wird über Python for MySQL 1.2.0 hergestellt. Diese erlaubt das Verbinden mit einem MySQL-Server und den Zugriff auf die Datenbanken und Tabellen.

In C++ wurde eine Klasse mysqlconnection implementiert, die den Zugriff auf die MySQLDatenbank organisiert. Die Klasse mysqlconnection nutzt die von MySQL bereit gestellte libmysql Version 5.0.5. Mit dieser kann mysqlconnection SQL-Queries an die CombINeDatenbank senden und die Resultate verarbeiten.

3.2.7 Kommunikationsprotokoll in CombINe

Um alle Belange der Kommunikation zwischen Endgerät und Benutzer in CombINe abzudecken, wurde das in diesem Kapitel erläuterte Protokoll entwickelt. Anfragen haben immer die folgende Form:

Abbildung in dieser Leseprobe nicht enthalten

Die einzelnen Teile haben folgende Bedeutung:

<server>

Enthält die Adresse des Servers

3 Der CombINe Prototyp

<apptype>

Der Typ der Anwendung ist im CombINe-Prototyp auf einen Typ beschränkt. Dieses Feld wurde eingefügt, um bei einer eventuellen Erweiterung von CombINe verschiedene Anwendungen, beispielsweise für zusätzliche Endgeräte, auf dem CombINe-Server einfach identifizieren zu können.

<userid>

Um eine schnelle und unkomplizierte Identifizierung des Benutzers zu realisieren, wird der Benutzer direkt in den Request einkodiert. Um die Datensicherheit zu gewährleisten, ist hier auch die Verwendung eines verschlüsselten Benutzernamens, ggf. mit temporärer Gültigkeit ähnlich einer PHP-Session denkbar, der dem Client beim Einloggen mitgeteilt wird.

<command>

Dieser Teil des Requests enthält den eigentlichen GET- oder POST-Befehl mit eventuell notwendigen Parametern. In CombINe sind folgende Befehle implementiert und mit entsprechenden Event-Handling-Methoden hinterlegt:

GET-Befehle:

stream

Erzeugt für den anfragenden Benutzer einen neuen Stream

stopstream

Stoppt den Stream des zugehörigen Benutzers

movel, mover, movef, moveb

Bewirken manuelles Bewegen nach links, rechts vorwärts oder rückwärts

rotycw, rotyccw

Bewirken Drehungen nach links, bzw rechts

rotxback, rotxfront

rotxback lässt den Benutzer nach oben sehen, rotxfront entsprechend nach unten

movefaster, moveslower

Setzen den Bewegungsgeschwindigkeitsfaktor höher bzw. niedriger

higher, lower

Setzen die Position des Benutzers höher bzw. tiefer

lookaround

Lässt den Benutzer um die eigene Position in einer Kreisbahn mit Blick ins Zentrum rotieren

lookaroundpickeditem?x=<x>&y=<y>

Lässt den Benutzer um den Mittelpunkt des Objektes, das auf der Anzeige in Pixel (x,y) angezeigt wird, rotieren

otherside?x=<x>&y=<y>

Zeigt das Objekt, das auf der Anzeige in Pixel (x,y) dargestellt wird, von der anderen Seite an

overview

Zeigt einen Überblick über das Szenario an

changeGroup?g=<groupid>

Zeichnet das Szenario für die ausgewählte Gruppe neu

changeTexture? x=<x>&y=<y>&g=<groupid>

Wechselt das Objekt, das sich auf der Anzeige in Pixel (x,y) befindet, zur Gruppe mit der Gruppen-ID groupid

changeTime?e=<time>

Zeichnet das Szenario für den ausgewählten Zeitpunkt neu

changeTextureTime? x=<x>&y=<y>&e=<time>

Wechselt das Objekt, das sich auf der Anzeige in Pixel (x,y) befindet zum Zeitpunkt e

walk? w=<walk>

Stellt einen virtuellen Gang über die Wegstrecke dar, die in der CombINe-Datenbank mit der ID walk versehen ist pick

Dient als Bestätigung nach der Angabe/dem Anzeigen verschiedener Objekte

pick?x=<x>&y=<y>

Dient zur Interaktion mit dem Objekt, das auf der Anzeige in Pixel (x,y) dargestellt wird

showAddData

Sucht nach zusätzlichen Daten zum derzeit aktiven Objekt und zeigt diese ggf. an

pickWall x=<x>&y=<y>

Wählt die Fläche, die sich auf der Anzeige in Pixel (x,y) befindet, zur Texturierung aus

objects

Blendet Objektgraffitis ein bzw. aus

POST-Befehle:

AddG

Befehl zum Hinzufügen von neuen freien Graffitis

AddO

Befehl zum Hinzufügen von neuen Objektgraffitis

AddT

Befehl zum Hinzufügen von Texturen

3.2.8 Schnittstellen

Die Schnittstellen der einzelnen Komponenten der Architektur werden in Abbildung 17 noch einmal verdeutlicht und ergänzt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 17: Schnittstellen in CombINe

3.3 Aufbau des Szenarios

3.3.1 Vorgehensweise

Die für CombINe zur Verfügung stehenden Karten beruhen auf 2D-Kartenmaterial des Landesamtes für Kataster-, Vermessungs- und Kartenwesen (LKVK) des Saarlandes. Um eine höhere Adaption an die reale Umwelt zu schaffen, ist es ein Ziel von CombINe, ein dreidimensionales Szenario zu schaffen. Zunächst wird hierzu für jedes Gebäude eine konstante Höhe angenommen. Zusammen mit der bekannten Grundfläche ergeben sich hierdurch Körper für jedes Gebäude und somit ein 2½ D-Modell. Die Wände dieses Körpers können nun mit Texturen, z.B. Fotografien der realen Gebäude versehen werden. Dies erzeugt den Eindruck zusätzlicher Geometrien, ein aus der Spieleindustrie bekanntes Prinzip.

Des Weiteren ist aufgrund der Dimensionen der Fotografie und der durch die Grundflächenkarte bekannte Wandlänge die Höhe des texturierten Gebäudes ableitbar. Durch diese Informationen lässt sich aus dem 2½ D-Modell ein echtes dreidimensionales Modell erzeugen.

[...]

---

¹ Auf diese Technologien wird in Kapitel 2 näher eingegangen.

² CombINe ist der Name des in dieser Arbeit entwickelten Prototyps (vgl. Kapitel 3).

³ Der Ausspruch „teile und herrsche“ oder englisch „divide and conquer“ geht vermutlich auf den französischen König Ludwigs XI. (1461-1483) zurück. Er beschreibt das Prinzip, Uneinigigkeit bei Gegnern zu fördern oder sogar zu verursachen, um so einzelne, kleinere Gruppen leichter besiegen zu können[7].

⁴ engl: mobiles Arbeiten mit einem Computer[7]

⁵ Das Betriebssystem EPOC wurde von der Firma Psion von 1989 bis 1998 auf PDAs verwendet.

⁶ Ein Java MIDlet ist ein Java-Programm, das mit der Java 2 Platform, Micro Edition (J2ME) erstellt worden ist und dem Mobile Information Device Profile (MIDP) entspricht.

⁷ Die Integrated Raster Imaging System Graphics Library (IRIS GL) war ein API von Silicon Graphics, das für die Erzeugung von 2D und 3D-Grafiken auf IRIX Workstations entwickelt wurde.

⁸ Näheres zur ARM9-Prozessor-Familie unter http://www.arm.com/products/CPUs/families/ARM9Family.html 21

⁹ Die Dynamic Link Library DLL ist eine von Microsoft Windows verwendete Programm-Bibliothek, die Programmcode (Maschinencode), Daten, und Ressourcen enthalten kann.

¹⁰ Für weitere Informationen siehe http://mingw.org

¹¹ Spezifikation siehe http://www.w3.org/protocols/rfc2616/rfc2616.html

¹² MySQL ist unter http://www.mysql.com zum Download verfügbar.

¹³ Eine deutsche Übersetzung der GPL ist unter http://www.gnu.de/gpl-ger.html einsehbar.