Konzeption und Entwicklung eines mobilen Stadtführers

Halbach, Christian

Konzeption und Entwicklung eines mobilen Stadtführers

Medien / Kommunikation - Technische Kommunikation

Zusammenfassung

Inhaltsangabe:Einleitung:
Der andauernde Wettbewerb in der Tourismusbranche verlangt nach neuen Ideen für die Präsentation touristischer Regionen. Mobile Endgeräte werden immer leistungsfähiger, und Unternehmen aus der Telekommunikationsbranche unterstützen massiv die Verflechtung von mobilen Endgeräten mit dem Alltag der Menschen. Große Erwartungen sind mit der Einführung und flächenmäßigen Verbreitung von drahtlosen Netzwerktechnologien wie dem UMTS, 802.11 WLAN oder Bluetooth verbunden.
Dank der hohen Datenübertragungsraten sind neue Multimedianwendungen für mobile Endgeräte möglich. Sie könnten den Unternehmen der Telekommunikationsbranche helfen, ihre hohen Investitionskosten zu amortisieren und so eine federführende Rolle bei der weiteren Entwicklung der Telekommunikations- und der Tourismusbranche spielen. Gerade positionsabhängige Multimediaanwendungen, die in ihrer Bedienung nicht schwierig sind und einen informativen Mehrwert darstellen, scheinen bei der touristischen Zielgruppe auf Akzeptanz zu stoßen, wie Befragungen und erste Anwendungen in diesem Bereich gezeigt haben.
Deswegen befasst sich diese Diplomarbeit mit der Konzeption eines mobilen Stadtführers. Ziel ist es, ein Informationssystem für mobile Endgeräte zu entwerfen und prototypisch umzusetzen, das Stadttouristen positions- und kontextabhängige Informationen multimedial zur Verfügung stellt. Durch solch ein System könnten gedruckte Reiseführer eingespart und Besichtigungen einer Stadt erleichtert werden.
In der Diplomarbeit werden verschiedene Schwerpunkte gesetzt. Zum einen sollen die Multimediafähigkeiten der aktuellen mobilen Endgeräte untersucht werden und passende Programmiersprachen und Technologien für die Erstellung von Multimediaanwendungen auf mobilen Endgeräten analysiert und bewertet werden. Ein zweiter Schwerpunkt wird auf eine Positionsermittlung über GPS gelegt.
Außerdem soll eine synchrone Kommunikation zwischen den Benutzern für den Austausch von Positionsdaten und Nachrichten realisiert werden. Weitere wichtige Aspekte dieser Arbeit sind die dynamische Generierung von adaptiven Kartenausschnitten für mobile Endgeräte und die Positionsdarstellung von Menschen, Objekten und Ereignissen auf diesen Karten. Hier sind noch einige Forschungsfragen offen. Zusätzlich wird ermittelt wie räumliche Informationen mit generellen Stadtinformationen für Touristen kombiniert werden können. Weitere Schwerpunkte sind Informationsdarstellung und Strukturierung der […]

Leseprobe

Inhaltsverzeichnis

ID 9291

Halbach, Christian: Konzeption und Entwicklung eines mobilen Stadtführers

Druck Diplomica GmbH, Hamburg, 2006

Zugl.: Fachhochschule für Technik und Wirtschaft Berlin, Diplomarbeit, 2004

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,

insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von

Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der

Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,

bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung

dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen

der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik

Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in

diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,

dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei

zu betrachten wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können

Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die

Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine

Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.

Diplomica GmbH

http://www.diplom.de, Hamburg 2006

Printed in Germany

Inhaltsverzeichnis

Inhaltsverzeichnis

1. Einleitung ... 1

1.1 Ziel ... 1

1.2 Struktur der Diplomarbeit... 2

2. Stand der Technik... 4

2.1 Bewertungsgrundlage... 4

2.2 Analyse ähnlicher Systeme...6

2.2.1 Falk City Guide ... 6

2.2.2 3Geo ... 8

2.2.3 Navitime ... 10

2.2.4 LoVEUS... 12

2.2.5 Mobile Deep Map ... 13

2.2.6 Weitere Systeme und Anwendungen ... 15

2.3 Vergleich und Zusammenfassung... 15

3. Grundlagen ... 18

3.1 Mobile Endgeräte ... 18

3.1.1 Benutzerschnittstellen ... 20

3.1.2 Informationsdarstellung... 21

3.1.3 Kontextbasierte Parameter und Personalisierung ... 22

3.1.4 Umwelteinflüße... 22

3.1.5 Betriebssysteme ... 22

3.1.6 J2ME ... 24

3.1.7 SVG... 25

3.1.8 Flash ... 26

3.1.8.1 Flash Player 6 für den Pocket PC... 28

3.1.8.2 Flash Lite 1.1 ... 29

3.1.8.2.1 Spezielle Anforderungen ... 31

3.2 Drahtlose Netzwerke ... 32

3.2.1 Mobilfunknetze ... 32

3.2.2 Lokale Netze ... 33

3.3 GPS ... 33

3.3.1 NMEA-0183 ... 36

3.3.2 GPS und mobile Endgeräte ... 36

3.4 WebGIS ... 38

4. Anforderungsanalyse ... 40

4.1 Benutzergruppen ... 40

4.2 Anwendungsszenarien ... 42

4.3 Kontextanalysen... 43

Inhaltsverzeichnis

4.4 Schlussfolgerung... 45

4.5 Zieldefinition... 46

5. Pflichtenheft... 47

5.1 Sprachauswahl... 47

5.2 Personalisierung... 47

5.3 Mehrbenutzerkomponente ... 47

5.4 Persönliche Einstellungen... 48

5.6 Reiseführer... 48

5.7 Weitere Informationsangebote ... 49

5.8 Multimedia... 49

5.9 Kartenausschnitte ... 50

5.9.1 Basisfunktionalitäten ... 50

5.9.2 Adressen... 50

5.9.3 Points of Interest ... 51

5.9.4 Ereignisse ... 51

5.9.5 Positionsermittlung ... 51

5.9.6 Routen... 52

5.9.7 Treffpunkte ... 53

5.9.8 Touren... 53

5.10 Hilfe ... 54

6. Analyse verschiedener Lösungsansätze... 55

6.1 Systemarchitektur ... 55

6.1.1 Verschiedene Systemarchitekturen ... 56

6.1.2 Auswahl der Systemarchitektur ... 58

6.1.3 Systemkomponenten... 59

6.1.4 Standardplattform... 59

6.1.5 Vereinfachte Systemarchitektur... 60

6.2 Anwendungsarchitektur ... 61

6.3 Datenmodell ... 62

6.4 Datenbank... 64

6.5 Präsentationsschicht... 64

6.6 Komponenten der Mittelschicht... 67

6.6.1 Mapserver... 67

6.6.2 Routeserver ... 68

6.6.3 Applikationsserver... 68

6.7 Lokalisierung ... 68

6.8 Zusammenfassung und Schlussfolgerung ... 69

7. Systementwurf ... 70

8. Implementierung... 71

Inhaltsverzeichnis

iii

8.1 Datenmodell ... 71

8.1.1 Geodaten ... 71

8.1.2 Applikationsdaten ... 73

8.1.2.1 MySQL... 73

8.1.2.2 XML ... 75

8.2 Server-Komponenten... 76

8.2.1 Applikationsserver... 76

8.2.1.1 Relevante Entwurfsmuster... 77

8.2.1.2 Services... 78

8.2.1.2.1 Flash Lite 1.1 und J2ME... 79

8.2.1.2.2 Flash Player 6 ... 79

8.2.1.3 Value Objects... 80

8.2.1.4 Data Access Objects ... 80

8.2.1.5 EJB Services... 81

8.2.1.6 Sicherheitsaspekte... 82

8.2.1.7 Zusammenfassung und Schlussfolgerung... 83

8.2.2 Mapserver... 83

8.2.2.1 CGI-Applikation ... 85

8.2.2.2 Mapfiles... 85

8.2.2.3 PHP MapScript ... 87

8.2.2.4 Flash Clients ... 87

8.2.2.5 Map Service ... 96

8.2.3 Routeserver ... 97

8.2.3.1 Route-, Address- und Tourservice ... 98

8.3 Client-Komponenten... 99

8.3.1 Pocket PC ... 100

8.3.1.1 HP IPAQ 4150 ... 100

8.3.1.2 Architektur... 100

8.3.1.3 Lokalisierung... 102

8.3.2

Smartphone ... 105

8.3.2.1 Nokia 6600 und Series 60... 105

8.3.2.2 Architektur... 106

9. Demonstration und Test... 108

9.1 Layout... 109

9.2 Startmenü ... 109

9.3 Karte... 110

9.3.1 Adresssuche... 112

9.3.2 Routensuche ... 113

9.3.3 Points of Interest ... 116

Inhaltsverzeichnis

9.3.4 Touren... 119

9.3.5 GPS ... 120

9.4 Kontakte und Nachrichten... 124

9.5 Reiseführer... 127

9.6 Test und Installation... 129

10. Schlussbemerkungen und Ausblick ... 131

Anhang ... 133

Kriterienkatalog ... 133

Analyse der einzelnen Systeme / Anwendungen ... 134

Abgrenzung des Prototypen... 139

Services ... 141

Quellcodebeispiele ... 145

Java... 145

Mapfile... 153

PHP ... 154

Flash... 162

Literaturverzeichnis... 164

Glossar ... 172

Abbildungsverzeichnis ... 175

Tabellenverzeichnis... 177

Eigenständigkeitserklärung ... 178

Einleitung

1. Einleitung

1.1 Ziel

Der andauernde Wettbewerb in der Tourismusbranche verlangt nach neuen Ideen für die Präsentation

touristischer Regionen. Mobile Endgeräte werden immer leistungsfähiger, und Unternehmen aus der

Telekommunikationsbranche unterstützen massiv die Verflechtung von mobilen Endgeräten mit dem

Alltag der Menschen. Grosse Erwartungen sind mit der Einführung und flächenmäßigen Verbreitung

von drahtlosen Netzwerktechnologien wie dem UMTS, 802.11 WLAN oder Bluetooth verbunden. Dank

der hohen Datenübertragungsraten sind neue Multimedianwendungen für mobile Endgeräte möglich.

Sie könnten den Unternehmen der Telekommunikationsbranche helfen, ihre hohen Investitionskosten

zu amortisieren und so eine federführende Rolle bei der weiteren Entwicklung der

Telekommunikations- und der Tourismusbranche spielen. Gerade positionsabhängige

Multimediaanwendungen, die in ihrer Bedienung nicht schwierig sind und einen informativen Mehrwert

darstellen, scheinen bei der touristischen Zielgruppe auf Akzeptanz zu stoßen, wie Befragungen und

erste Anwendungen in diesem Bereich gezeigt haben.

Deswegen befasst sich diese Diplomarbeit mit der Konzeption eines mobilen Stadtführers. Ziel ist es,

ein Informationssystem für mobile Endgeräte zu entwerfen und prototypisch umzusetzen, das

Stadttouristen positions- und kontextabhängige Informationen multimedial zur Verfügung stellt. Durch

solch ein System könnten gedruckte Reiseführer eingespart und Besichtigungen einer Stadt erleichtert

werden.

In der Diplomarbeit werden verschiedene Schwerpunkte gesetzt. Zum einen sollen die

Multimediafähigkeiten der aktuellen mobilen Endgeräte untersucht werden und passende

Programmiersprachen und Technologien für die Erstellung von Multimediaanwendungen auf mobilen

Endgeräten analysiert und bewertet werden. Ein zweiter Schwerpunkt wird auf eine

Positionsermittlung über GPS gelegt. Außerdem soll eine synchrone Kommunikation zwischen den

Benutzern für den Austausch von Positionsdaten und Nachrichten realisiert werden. Weitere wichtige

Aspekte dieser Arbeit sind die dynamische Generierung von adaptiven Kartenausschnitten für mobile

Endgeräte und die Positionsdarstellung von Menschen, Objekten und Ereignissen auf diesen Karten.

Hier sind noch einige Forschungsfragen offen. Zusätzlich wird ermittelt wie räumliche Informationen

mit generellen Stadtinformationen für Touristen kombiniert werden können. Weitere Schwerpunkte

sind Informationsdarstellung und Strukturierung der Informationsangebote für mobile Endgeräte.

Die Diplomarbeit wurde größtenteils in Prag angefertigt. Auslandsaufenthalte sind im Studiengang

,,Internationale Medieninformatik" an der FHTW Berlin ausdrücklich erwünscht. Während eines

vorherigen Praktikums in einem europäischen Forschungsprojekt an der CVUT (TU Prag) konnten

Einleitung

Kontakte geknüpft werden, die sich für die Anfertigung der Arbeit als außerordentlich hilfreich

herausgestellt haben.

1.2 Struktur der Diplomarbeit

Im Laufe der Diplomarbeit soll ermittelt werden, wie die inhaltliche, gestalterische und

programmiertechnische Lösung für die Visualisierung eines touristischen, positionsabhängigen

Stadtinformationsangebotes für mobile Endgeräte aussehen könnte. Der folgende Abschnitt gibt einen

kurzen Überblick über die Gliederung der Diplomarbeit.

Im Kapitel ,,Stand der Technik" werden zunächst vorhandene Systeme vorgestellt und analysiert, die

dem zu erstellenden System ähneln. Hieraus lassen sich wichtige Schlüsse für das eigene Konzept

ziehen.

Im Kapitel ,,Grundlagen" werden anschließend mobile Endgeräte klassifiziert. Es wird auf

Benutzerschnittstellen, kontextbasierte Parameter und Personalisierung, Informationsdarstellung und

Umwelteinflüsse eingegangen. Wichtige Programmiersprachen und Formate für die Erstellung von

Multimediaanwendungen für mobile Endgeräte werden aufgezeigt. Es werden verschiedene

Lokalisierungsverfahren vorgestellt, wobei ein besonderer Schwerpunkt auf GPS gelegt wird.

Abgeschlossen wird dieses Kapitel mit einer Betrachtung von WebGIS.

Zu Beginn des Kapitels ,,Anforderungsanalyse" werden relevante Benutzergruppen für den Prototypen

beschrieben. Für ausgewählte Benutzergruppen werden in einem nächsten Schritt konkrete

Anwendungsszenarien aufgestellt. Anschließend wird der Kontext der Anwendungsszenarien

untersucht. Das Kapitel schließt mit einer Zieldefinition für den Prototypen.

Im Kapitel ,,Pflichtenheft" werden die Funktionalitäten des mobilen Stadtführers ermittelt. Der

Funktionsumfang des Prototypen wird von einer erweiterten Version abgegrenzt.

Das Kapitel ,,Analyse verschiedener Lösungsansätze" dient einem Vergleich möglicher technischer

Lösungsansätze. Geeignete Lösungsansätze werden für die Erstellung des Prototypen ausgewählt.

In dem Kapitel ,,Systementwurf" wird die Systemarchitektur beschrieben.

Das darauf folgende Kapitel ,,Implementierung" erläutert die Vorgehensweise bei der Realisierung des

Prototypen. Hier wird zum einen die Architektur der eingesetzten Web Applikation beschrieben. Es

wird außerdem auf die Implementierung der Karten- und Routenkomponenten des Systems

eingegangen. Zusätzlich wird die Realisierung der Clientanwendungen für Pocket PCs und

Smartphones beschrieben, wobei besonders auf die Positionsbestimmung über GPS eingegangen wird.

Einleitung

Anschließend werden die Funktionalitäten des entwickelten Prototypen in dem Kapitel ,,Demonstration

und Test" aufgezeigt.

Am Ende der Arbeit wird in dem Kapitel ,,Schlussbemerkungen und Ausblick" das erreichte Ziel

dargestellt und ein Ausblick in die Zukunft gegeben.

Stand der Technik

2. Stand der Technik

In diesem Kapitel werden Anwendungen vorgestellt, die eine ähnliche Funktionalität wie das zu

erstellende System bieten. Durch eine Analyse von bestehenden Systemen können Schlussfolgerungen

für den späteren Systementwurf gezogen werden.

Für die passende Auswahl ähnlicher Anwendungen ist eine nähere Einordnung des zu erstellenden

Informationssystems notwendig. Grundsätzlich soll es über zwei fundamentale Funktionalitäten

verfügen. Erstens, soll es eine persönliche Navigation im Freien (Stadt oder Kulturstätte) für

Fußgänger ermöglichen. Zweitens, soll es generelle Stadtinformationen und positionsabhängige

Informationen zu Points of Interest (also interessante Objekte, wie Sehenswürdigkeiten,

Gastronomiebetriebe, Hotels, usw.) darstellen.

2.1 Bewertungsgrundlage

Für eine Analyse und den Vergleich ähnlicher Systeme werden Vergleichskriterien benötigt. Dies

könnten zum einen generelle Eigenschaften sein, die ein erfolgreicher mobiler Dienst vorweisen sollte.

Dazu gehören gut recherchierte Informationen, die aktuell und zuverlässig sind und das

Informationsbedürfnis befriedigen [vgl. Eni02 und Zipf03a]. Mobile Dienste sollten auch besonders

benutzerfreundlich sein. Eine schlechte Darstellung und Strukturierung der Inhalte oder eine

umständliche Navigation könnten zu einer negativen Benutzererfahrung führen.

Damit aber ein direkter Vergleich möglich ist, wurde zuvor ein genauer Kriterienkatalog festgelegt, der

aus vier unterschiedlichen Teilen besteht (siehe Anhang):

Im allgemeinen

Teil

werden die Merkmale:

Anwendungsbereich,

Zielgruppe,

Sprachangebot und

Personalisierung des Systems untersucht.

Im technischen

Teil

werden:

unterstützte mobile Endgeräte,

unterstützte Betriebssysteme,

verwendete Programmiersprachen (soweit feststellbar),

Art der Anwendung (Standalone oder Browser),

Anbindung an drahtlose Netzwerktechnologien und

Lokalisierungsverfahren festgestellt und analysiert.

Stand der Technik

Im Design- und Navigationsteil wird auf:

Bildschirmgliederung

Design,

Navigationskonzept und

Hilfefunktionalitäten genauer eingegangen.

Im inhaltlichen Teil spielen:

- situations- und positionsabhängige Dienste,

Informationsangebot und Strukturierung,

Kartenfunktionalität,

Routenfunktionalität,

Tourenfunktionalität,

Einsatz von Multimedia und

zusätzliche Funktionalitäten eine Rolle.

Stand der Technik

2.2 Analyse ähnlicher Systeme

Den Kriterienkatalog und die Auswertungen für die einzelnen Systeme findet der interessierte Leser im

Anhang.

2.2.1 Falk City Guide

Allgemeiner Teil

Der Falk City Guide wurde von Gate5 erstellt, einem deutschen Softwareunternehmen aus Berlin, das

auf positionsabhängige Software für mobile Endgeräte spezialisiert ist. Die Anwendung ist für die

persönliche Navigation und als mobiler Stadtführer gedacht. In der Arbeit wurde ein näherer Blick auf

die deutschsprachige Version für Berlin geworfen. Allerdings werden weitere englischsprachige

Versionen für europäische Städte angeboten. Die Zielgruppe wurde vom Hersteller nicht näher

definiert. Für Touristen ist die Anwendung nur bedingt tauglich, wie später erklärt wird. Eine

Personalisierung der Anwendung ist nicht möglich.

Abbildung 1: Falk City Guide auf dem IPAQ 4150

Technischer Teil

Es werden Versionen für mobile Endgeräte mit den Betriebssystemen Pocket PC, Palm OS und

Symbian vertrieben. Für die Diplomarbeit wurde die Pocket PC 2003-Testversion für Berlin auf einem

IPAQ 4150 in Kombination mit einem Bluetooth-GPS-Empfänger getestet. Es handelt sich um eine in

C++ programmierte Smart Client-Anwendung. Sie nutzt die lokalen Ressourcen des mobilen

Stand der Technik

Endgeräts, ist ohne Netzwerkanbindung voll lauffähig und kann installiert und geupdatet werden.

Zusätzliches Kartenmaterial kann auf Speichererweiterungen wie SD-Karten abgelegt werden. Über

den Menüpunkt ,,Extra" ist es möglich einen an den PDA angeschlossener GPS-Empfänger zu

aktivieren, mit der die Position bei einer Genauigkeit von ca.10-30 m bestimmt werden kann.

Problematisch bei einer GPS-Positionsbestimmung in der Stadt sind allerdings Abschattungseffekte

durch Gebäude, wodurch die Anzahl der für die Positionsbestimmung zur Verfügung stehenden

Satelliten reduziert werden kann. Der Standort des Benutzers wird bei der Software über ein

Fadenkreuz auf der Karte visualisiert.

Design- und Navigationsteil

Die Gestaltung der Benutzeroberfläche erfolgte durch Julia Dietsch von der Agentur pReview. Vor der

Programmierung wurden Layoutstudien für alle Handlungsabläufe erstellt [Vgl. Page02]. Die

Benutzeroberfläche wird im Vollbildmodus (240 x 320 Pixel) angezeigt und ist in drei Abschnitte

aufgeteilt: Obere Statusleiste (Höhe 20 Pixel), mittleres Informationsangebot (Karte,

Routeninformationen, Kurzinformationen zu Points of Interest, Höhe 200 Pixel) und untere Menüleiste

(Höhe 20 Pixel). Der Name der Anwendung ist ständig in der oberen Statusleiste sichtbar. Für das

Informationsangebot steht eine ausreichend große Fläche zu Verfügung. Die untere Menüleiste ist im

,,Windows-Style". Es gibt ein strenges Farbschema für die Navigationselemente: Hellblau - Dunkelblau

(1C1F52, 7280A5, DFDFDD). Icons haben die einheitliche Größe von 16x16 Pixel. Für Texte wurde

eine sans-serife Schrift eingesetzt, die gut lesbar ist. Insgesamt ist die Benutzeroberfläche sehr

sinnvoll aufgeteilt und die Menüführung konsequent. Der einzige Minuspunkt ist die fehlende Hilfe.

Inhaltlicher Teil

Die Anwendung implementiert Funktionen zur Navigation, Routenfindung und für den Abruf von

weiterführenden Informationen zu Points Of Interest. Dabei arbeitet der Falk City Guide stark

kartenbasiert und ist sehr interaktiv. Hervorzuheben ist die Zoom-Funktion. Sie erlaubt eine stufenlose

Vergrößerung und Verkleinerung der Kartenausschnitte ohne bemerkenswerte Ladezeiten. Der

Betrachter schaut in der Vogelperspektive auf die Kartenausschnitte, die er durch Drag & Drop mit

dem Stift verschieben kann. Es werden zahlreiche Points Of Interest über Piktogramme auf der Karte

dargestellt. Die Gestaltung der Piktogramme lässt leicht auf die Kategorie der Points Of Interest

schließen. Zu den Points Of Interest stehen weiterführende Texte zur Verfügung, die Adress- und

Kontaktinformationen oder eine Kurzbeschreibung beinhalten. Auf die Integration von

Multimediaelementen wurde aber verzichtet. Die Schwerpunkte der Anwendung sind klar die

Funktionalitäten für die Navigation und Routenfindung. Start- und Endpunkte einer Route können zum

einen in einem Dialogfenster definiert werden. Die Strassen- oder Objektnamen werden hierbei über

die Software-Tastatur von Windows eingegeben und mit den verfügbaren Daten verglichen. Alternativ

können die Start- und Endpunkte der Route auch innerhalb der Karte mit einem Klick auf einen Points

Of Interest, festgelegt werden. Routen werden entweder über Markierungen auf der Karte, mit

schriftlichen Angaben über die zu befahrenden Strassen und den nächsten Richtungswechsel, oder in

Stand der Technik

einer Liste angezeigt. Es werden auch Einbahnstrassen erkannt, somit sind die Routenvorschläge

allerdings nur für Fahrrad-, Motorrad- oder Autofahrer interessant und nicht für Fußgänger. Touren für

Touristen wurden nicht integriert.

Fazit

Insgesamt ist die Anwendung benutzerfreundlich, auch wenn es einer kurzen Einarbeitungszeit bedarf.

Vorbildlich sind die sinnvolle Aufteilung der Benutzeroberfläche, die konsequente Menüführung und

Gestaltung sowie die hohe Interaktivität der Kartenfunktion. Kontextbasierte Parameter werden in

Form von Positionsanzeige des Benutzers und den Navigations- und Routenfunktionalitäten integriert.

Die Karte ist für diese Zwecke generalisiert worden, indem Straßen und Straßentypen (Hauptstrassen,

Nebenstrassen,...) hervorgehoben werden. Auf Gebäudeumrisse oder Wege des ÖPNV wurde

verzichtet. Allerdings ist die Anwendung für Stadttouristen nur bedingt einsetzbar. Der Falk City Guide

bietet keine Tourenvorschläge und die Routenfunktion ist nicht für Fußgänger gedacht. Die

weiterführenden Informationen zu Points Of Interest fallen zu knapp aus und verzichten auf die

Integration von Multimedia. Ferner sind keine generellen Informationen über Berlin oder Ereignisse in

Berlin verfügbar. Die Anwendung kann außerdem nicht personalisiert werden und bietet dem benutzer

keine Hilfefunktion.

2.2.2 3Geo

Allgemeiner Teil

,,Now you can" Mit diesem Slogan wurde im Mai 2003 das erste UMTS-Netz Österreichs von dem

Anbieter 3 (Hutchison 3G) eingeführt. Das von Siemens (Node B´s Basisstationen) und Nokia (Core &

Richtfunk) errichtete Netz bot schon zum Start eine landesweite Netzabdeckung von etwa 30% und

Downloadraten von 384 Kbit/sec.

Das Herzstück von 3´s "mobiler Multimedia Welt" ist die "3Zone".

Sie beinhaltet mehrere mobile Dienste, wie Nachrichten, Spiele und Multimediainhalte. Seit Januar

2004 steht auch der neue Dienst 3Geo zur Verfügung. Der deutschsprachige Dienst wurde für Wien

getestet, wird aber auch für andere österreichische Städte angeboten. Eine Personalisierung von 3Geo

ist nicht möglich.

Technischer Teil

Für die Positionsbestimmung stehen eine ,,exakte" und eine ,,grobe" Positionierung zur Verfügung. Die

,,exakte Positionierung" erfolgt über Assisted GPS (A-GPS) und liefert mit einer Genauigkeit von ca. 10

-30 m präzisiere Ergebnisse als eine "Grobe Positionierung" über die nächste UMTS/GPRS Funkzelle. 3

bietet mit den Modellen Motorola A920, A925 und A 835 und NEC e616 vier AGPS-fähige mobile

Endgeräte an. Hier wurde die 3GEO-Version für das Motorola A920 getestet. Das mobile Endgerät

Stand der Technik

Abbildung 2: 3Geo auf dem Motorola A925

Design- und Navigationsteil

Die Anwendung läuft im vorinstallierten Browser (Opera) des Smartphones. Dadurch ist eine

Auflösung von 208 x 220 Pixeln möglich, weitere 60 Pixel (Höhe) der Bildschirmoberfläche werden

allerdings nicht genutzt. Die Benutzeroberfläche wurde (wie beim Falk City Guide) in drei Teile

aufgeteilt: Obere Menüleiste, Informationsangebot (Karte, Routeninformationen, Kurzinformationen zu

Points of Interest) mittig, untere Statusleiste. Zusätzlich steht ein Scrollbalken auf der rechten Seite

bereit. Das Design für Menüpunkte und Überschriften folgt einem einheitlichen Farbschema: Hellgrün -

Dunkelgrün (00910C, 7CFF88), Buttons einheitlich in Dunkelgrün (7CFF88). Die Navigation innerhalb

der Anwendung erfolgt über ein Drop-Down-Menü in der oberen Menüleiste. Alternativ kann über eine

Liste der Menüpunkte auf der Startseite navigiert werden. Eine Hilfe steht nicht zur Verfügung.

Inhaltlicher Teil

Das ,,mobile Navigationssystem" bietet, wie der Falk City Guide, Funktionalitäten für die Navigation

und Routenfindung und Kurzinformationen zu Points Of Interest an. Darüber hinaus werden auch

Kultur- und Sportevents sowie Verkehrsinformationen für Autofahrer bereitgehalten. Die Inhalte

werden von Content-Providern erstellt. Der Standort des Benutzers wird grafisch über einen Kreis mit

rotem Punkt auf dem passenden Kartenausschnitt angezeigt. Start- und Zielpunkt einer Route müssen

über die Tastatur in Textfelder eingegeben werden. Für den Startpunkt kann alternativ die

automatisch bestimmte Position genutzt werden. Eine Route wird über farbige Pfeile auf der Karte

basiert auf dem Symbian v7.0 (UIQ)

Betriebssystem. Eine exakte Positionierung

hat im Test 18 Sekunde gedauert und war

auf 20 m genau. Der GPS-Server von 3

ermittelt eine ,,grobe" Position des Benutzers

über das Mobilfunknetz und wertet über

NASA- Referenz-Daten aus, welche Satelliten

des GPS-Systems für eine Positions-

bestimmung des

Benutzers momentan

genutzt werden können. Die genaue Position

wird dann anhand der Daten ermittelt, die

von den ausgewählten Satelliten empfangen

werden.

Stand der Technik

visualisiert. Die Routenfunktion ist für Fußgänger gedacht, Wege des ÖPNV werden nicht

berücksichtigt. Kartenausschnitte lassen sich über 4 Buttons, die mit den Anfangsbuchstaben der

Himmelsrichtung versehen sind, bewegen. Zwei weitere Buttons erlauben die Vergrößerung und

Verkleinerung der Kartenausschnitte. Die Generalisierung der Karteninhalte ist an die Zoom-Stufen

gekoppelt. Bei einer Verkleinerung fallen z.B. die Gebäudeumrisse weg und Hauptstrassen werden

farblich in den Vordergrund gesetzt. Für Touristen stehen keine Touren oder weiterführende

Multimediainformationen zu der Stadt (in diesem Fall Wien) zur Verfügung.

Fazit

Insgesamt ist die Anwendung leicht zu bedienen, allerdings ist sie nicht so interaktiv wie der Falk City

Guide. Die Navigations- und Routenfunktionalität haben aber im Test den Anforderungen genügt.

Durch eine Client-Server-Architektur kann immer auf aktuelles Kartenmaterial und neueste Inhalte

zugegriffen werden. Durch die hohe Bandbreite des UMTS-Netzes ist die Ladezeit sehr kurz (1-2

Sekunden). Sehr interessant ist die Positionsermittlung über A-GPS, womit eine genaue und schnelle

Lokalisierung auch für Smartphones möglich ist. Automatische Positionsermittlungen sind immer

kostenpflichtig, die Abrechnung erfolgt über ein Bezahlsystem mit der monatlichen Telefonrechnung.

Für Touristen ist die Anwendung leider nur begrenzt einsetzbar, denn es gibt keine touristischen

Tourenvorschläge und die Informationen zu Points Of Interest fallen noch knapper als beim Falk City

Guide aus. Auf weiterführende Multimediaelemente wurde gänzlich verzichtet, es ist keine Hilfe

vorhanden und die Anwendung kann leider auch nicht personalisiert werden.

2.2.3 Navitime

Allgemeiner Teil

Navitime ist eine junge, japanische Firma, die im Jahre 2000 gegründet wurde. Sie produziert

Software für die persönliche Navigation und die Darstellung von digitalen Karten auf unterschiedlichen

mobilen Endgeräten für verschiedene Betriebssysteme (Pocket PC, Symbian, weitere). Für den Test

musste auf Informationen des Herstellers (www.navitime.co.jp) und von weiteren Quellen

zurückgegriffen werden [vgl. Qual03 und Tosh03]. Die Software ist ausschließlich für den japanischen

Markt gedacht und entsprechend in japanischer Sprache. Zielgruppe sind Verkehrsteilnehmer aller Art.

Navitime hat zum einen sehr effiziente Kompressionsalgorithmen für Fahrpläne, Verkehrsnetze und die

Darstellung von Kartenausschnitten entwickelt. Außerdem bietet Navitime umfangreiche Dienste für

die Routenfindung an, die alle Verkehrswege unterstützen soll. Die Firma nutzt zwei Geschäftsmodelle

für die Lizenzierung der Software. Erstens, werden Lizenzen an andere Firmen vergeben, die ihren

Kunden kartenbasierte Dienste anbieten möchte. Zweitens, hat Navitime eine Allianz mit Herstellern

von mobilen Endgeräten gegründet. Das mobile Endgerät verfügt dann über einen speziellen Knopf,

mit dem Positionsdaten sofort an den Kartendienst von Navitime gesendet werden können. Für diese

Vereinbarung werden auch Lizenzkosten verlangt.

Stand der Technik

Abbildung 3: Navitime auf dem Toshiba A5304T, Quelle Navitime Japan Co.Ltd

Technischer Teil

Hervorzuheben ist die BREW-Version von Navitime, die auf mobilen Endgeräten wie dem Toshiba

A5304T oder dem Panasonic C3003P vorinstalliert ist. BREW ist eine von QUALCOM erstellte

Laufzeitumgebung für mobile Anwendungen auf Firmware-Ebene (CMDA Chipsatz). Die

Laufzeitumgebung ist der Virtuellen Maschine in Java sehr ähnlich, allerdings schneller da sie direkt

über der Software des Chipsystems sitzt. Somit lassen sich native Anwendungen in C/C++ erstellen.

Es können aber auch andere Laufzeitumgebungen, wie Java, XML oder Flash integriert werden. BREW

ist also auch sehr offen. Mit dem ,,BREW Distribution System" können Telefongesellschaften die

Downloads von BREW-Anwendungen in ihren Mobilfunknetzwerken steuern und auf ein Bezahlsystem

zurückgreifen. Beide oben genannten mobilen Endgeräte sind mit QUALCOMMs gpsOne-Chips

ausgestattet, die eine Positionsbestimmung über A-GPS ermöglichen.

Design- und Navigationsteil

Über das Design und die Navigation lassen sich nur sehr wenige Aussagen machen, da die

Anwendung (wie geschrieben) nicht direkt getestet werden konnte. Feststellbar war, dass der

Anwendung auf den neuen japanischen Smartphones eine Auflösung von 240 x 320 Pixeln zur

Verfügung steht, die auch weitesgehend von der Anwendung genutzt wird. Auf den veröffentlichten

Screenshots der Anwendung erscheint das Informationsangebot ein wenig überladen und zu bunt,

was von Europäern aber nur bedingt beurteilt werden kann.

Stand der Technik

Inhaltlicher Teil

NAVITIME berücksichtigt bei der Routensuche verschiedene Transportmittel, wie Flugzeug, Eisenbahn

und PKW. Die optimale Route wird über Markierungen auf der Karte angezeigt und es wird die

ungefähre Reisezeit berechnet. Zusätzlich können Informationen über Beförderungskosten und Staus

ausgegeben werden. Der von NAVITIME entwickelte Mviewer für die Kartendarstellung ist

vektorbasiert und zeichnet sich durch die kleine Dateigröße des zu übertragenden Kartenmaterials

aus. Falls das verwendete mobile Endgerät auch über einen Kompass-Chip verfügt, wird die Nord-Süd-

Ausrichtung der angezeigten Karten an die Fortbewegungsrichtung des Benutzers angepasst, was die

Benutzerfreundlichkeit der Anwendung erhöht. NAVITIME ist ausschließlich für die persönliche

Navigation gedacht und stellt keine weiteren Informationen zu Points Of Interest bereit.

Fazit

Bei der Routenberechnung kann bei Navitime auf Zeitpläne unterschiedlichster Verkehrsmittel

zurückgegriffen werden. Bemerkenswert ist das verwendete Vektorformat für die Darstellung der

Karten. Laut Herstellerangaben lässt sich die Dateigröße einer angezeigten Karte von 16 90 KB bei

Rasterformaten, wie GIF, JPEG oder PNG, auf 2KB reduzieren. Sehr interessant ist die Brew-Version

von Navitime, die eine höhere Performance als eine Java-Version bieten soll. Navitime ist nicht für

Touristen geeignet, denn es werden keine weiteren Informationen zu Points of Interest oder generelle

Stadtinformationen angeboten. Die Anwendung ist außerdem nur in japanischer Sprache vorgesehen.

2.2.4 LoVEUS

Allgemeiner Teil

Das Ziel des europäischen IST-Projekts LoVEUS ist die Konzeption, Implementierung und Beurteilung

eines Systems, das die Darstellung von personalisierten, positionsabhängigen und

tourismusorientierten Multimediainformationen für Kulturstätten erlaubt [vgl. Love02]. Zielgruppe sind

eindeutig Touristen, die Anwendung soll personalisierbar sein. Es kommt insofern dem zu erstellenden

System sehr nahe. Während des Projektes wurden mehrere Dokumentationen publiziert, wodurch ein

näherer Blick auf die Konzeption der Systemarchitektur und die zu verwendenden Technologien

geworfen werden kann.

Technischer Teil

Die Lokalisierung des Benutzers erfolgt über die Cell-ID der nächsten BTA im Mobilfunknetz , was in

diesem Fall lediglich eine Lokalisierungsgenauigkeit von 550 m ergibt. Der Server des Systems verfügt

über eine Reihe von Komponenten, unter anderem eine Komponente für die Userverwaltung, eine

Komponente zur Personalisierung der Inhalte und eine Multimedia GIS- Komponente in der alle

Inhalte gespeichert werden und mit der Geodaten mit Multimediaobjekten verknüpft werden können.

Um eine hohe Portabilität des Systems und die Integration von neuen Standards zu gewährleisten,

Stand der Technik

beruht das gesamte System auf der J2EE-Architektur und dessen Applikationsmodell. Die

Clientanwendungen für GSM- und UMTS-Netzwerke werden mit J2ME entwickelt. Hier liegt der Fokus

auf Geräten, die den Anforderungen der CLDC und des MIDP genügen.

Design- und Navigationsteil

Aussagen über das Design und die Navigation können nicht gemacht werden, da keine näheren

Informationen über die tatsächliche Implementierung des Systems vorlagen.

Inhaltlicher Teil

Auch über die Inhalte können nur wenig Aussagen getroffen werden. Laut Dokumentation soll der

Benutzer in der Lage sein den Schwerpunkt der Inhalte (z.B. Sport) und das bevorzugte Format (z.B.

Audio oder Video) selber zu bestimmen. Eine Streaming-Komponente soll die Bereitstellung von

Videosequenzen im MPEG-4 BIFS-Format (BIFS = Binary Format for Scenes) und synchronisierten

Audiostreams ermöglichen. Außerdem war ein mehrsprachiges Informationsangebot angedacht.

Welche Funktionalitäten letztendlich integriert wurden und wie hoch die Qualität des

Informationsangebotes ist konnte leider nicht ermittelt werden.

Fazit

Ein Test des Prototypen war leider nicht möglich, es musste auf die Publikationen des

Forschungsprojekts zurückgegriffen werden. Wichtig ist, dass die Anwendung ausschließlich für

Touristen konzipiert wurde und hierfür tourismusorientierte Multimediainformationen für Kulturstätten

angeboten werden sollen. Den Inhalt (3D-Modelle, Video und Audio) soll der Anwender selber

bestimmen können, eine Personalisierung ist also vorgesehen. Sehr interessant ist die J2EE-

Architektur des Systems und der J2ME-Ansatz für die Clientanwendung, wodurch eine hohe

Portabilität gewährleistet wird.

2.2.5 Mobile Deep Map

Allgemeiner Teil

Eines der ersten mobilen Touristeninformationssysteme war das Mobile Deep Map System für das

Heidelberger Schloss, das im Rahmen eines Forschungsprojektes am European Media Laboratory

entwickelt wurde. Ein erster Prototyp wurde schon im Sommer 1999 der Öffentlichkeit präsentiert.

Mobile Deep Map ist Teil eines Gesamtsystems für stationäre und mobile Touristeninformationen.

Deep Map soll es dem Benutzer sowohl erleichtern, sich in einer ihm fremden Stadt zu orientieren,

zurechtzufinden und zu bewegen, als auch durch virtuelle Datenwelten in Raum und Zeit zu reisen

[Zipf99]. Mobile Deep Map ist in erster Linie für Touristen gedacht, die Personalisierung des

Informationsangebots ist ein wichtiger Wesenszug des Systems. Der Prototyp wurde in deutscher

Sprache realisiert, weitere Sprachen (Englisch und Japanisch) waren vorgesehen.

Stand der Technik

Abbildung 4: Mobile

Deep Map, Quelle

[Wann00]

gestellt werden. Die Positionsbestimmung erfolgte über GPS. Das Gesamtsystem ist

komponentenweise aufgebaut und wurde als Java-basierte Agenten-Plattform erstellt. So können die

Agenten leicht ausgetauscht werden. Die Kommunikation der Agenten untereinander wurde durch die

Verwendung der Agentenkommunikationssprache Agent Communication Language (ACL) der

Foundation For Physical Agents (FIPA) realisiert. Alle Daten wurden im XML-Format gespeichert, ,,da

das Ändern der Document Type Definition (DTD) eines XML-Dokuments einfacher ist als die Änderung

eines Datenbankschemas" [Zipf99].

Design- und Navigationsteil

Keine Aussagen möglich.

Inhaltlicher Teil

Der für den mobilen Prototypen realisierte MapAgent beinhaltet eine RenderEngine, die Karten als

Rastergrafiken aus Vektordaten serverseitig erzeugen kann. Für eine in Java realisierte

Übersichtskarte wurde auch ein clientseitiges Rendern implementiert. Hier werden die vektoriellen

Geometrierohdaten an den Client übergeben. Das System implementiert grundlegende

Tourenplanungs- und Wegverfolgungsfunktionalitäten und stellt in der kognitiven Schicht des Systems

auch personalisierte Tourenvorschläge bereit. Wichtige Parameter bei der Anpassung der Touren an

den Benutzer sind z.B. das benutzte ,,Fahrzeug" (Auto, zu Fuß, Fahrrad, Rollstuhl), so genannte ,,hard

restrictions", also physikalisch gegebene Bedingungen wie Höhe, Steigung oder Abbiegungsregeln und

,,soft restrictions", die vom Benutzer definierte Wünsche (z.B. Vermeidung von Verkehrsstrassen,

hohes Interesse an architektonischen Bauten) beinhalten.

Das System konnte leider nicht getestet werden, somit können die Qualität des

Informationsangebotes und die Karten-, Routen- und Tourenfunktionalitäten nicht direkt bewertet

Technischer Teil

Kern des gesamten Systems war ein GIS in Kombination mit einer Datenbank.

Als Plattform für das GIS wurden ESRI ArcView und in neueren Varianten die

Spatial Database Engine (SDE) für Oracle verwendet. Es konnte auf Geodaten

der Stadt Heidelberg zurückgegriffen werden, inhaltliche Daten wurden in

Zusammenarbeit mit dem Geographischen Institut der Universität Heidelberg

recherchiert. Ein Xybernaut Mobile Assistant MA IV diente als

Experimentierplattform. Bei dem Gerät handelt es sich um einen so

genannten ,,wearable computer", der am Körper getragen werden kann, so

dass beide Hände frei bleiben. Besonders an dem Prototypen ist die

verwendete Sprachsteuerung mittels einer Mikrophon/Kopfhörer-Kombination.

Es wurde argumentiert, dass es für Touristen sehr wichtig ist die Hände frei

zu haben [vgl. Wann00]. Funkverkehr konnte mittels GSM Cardphone und

Stand der Technik

werden. Allerdings wurden die Inhalte von Fachwissenschaftlern wie Geographen, Kunsthistorikern

und Historikern erstellt, von einer hohen Qualität kann also ausgegangen werden.

Fazit

Bemerkenswert ist die zeitlich frühe Entwicklung des Systems. Mobile Deep Map war der Wegbereiter

für weitere interessante Forschungsprojekte (z.B. Deep Map 2, Integrated Map, Talking Map, Virtual

Map). Beachtenswert ist außerdem der Einsatz eines ,,wearable computer", die Java-basierte Agenten-

Plattform, die Konzentration auf Touristen als Zielgruppe, die Sprachsteuerung und die starke

Personalisierung des Informationsangebots mit Tourenvorschlägen. Es ist auch das einzige System,

das ein clientseitiges Rendern von Geodaten realisierte. Dadurch wird sicherlich eine deutliche

Reduktion der Datengröße von Kartenausschnitten erreicht, allerdings sind Performanceeinbußen

wahrscheinlich.

2.2.6 Weitere Systeme und Anwendungen

Weitere interessante Systeme und Anwendungen sind vorhanden, allerdings würde eine nähere

Betrachtung den Rahmen der Diplomarbeit sprengen. Wenigstens erwähnt werden sollen das vom

Fraunhofer IGD entwickelte daMobile System für Darmstadt, das TellMaris Mobile 3D Projekt, das

CRUMPET Projekt, das GEIST Outdoor Augumented Reality Projekt und das im Rahmen einer

Diplomarbeit an der FH Joanneum entwickelte Mobile Information System für Nationalparks in

Österreich.

2.3 Vergleich und Zusammenfassung

Die Entwicklung von mobilen Stadtführern für Touristen steckt noch in den Kinderschuhen.

Schwerpunkt der ersten drei vorgestellten Systeme (Falk City Guides, 3Geo und Navitime) ist klar die

persönliche Navigation. Alle drei Systeme bieten gute Funktionen für die Navigation und

Routenfindung. Allerdings ist der Falk City Guide nur bedingt für Touristen geeignet, 3Geo und

Navitime eignen sich nicht für Touristen. LoVEUS und Mobile Deep Map sind speziell für Touristen

konzipiert worden, die Systeme erlauben Personalisierung, Tourenvorschläge und setzen Multimedia

ein. Es ist schwierig die Systeme direkt zu vergleichen oder gar zu benoten, denn dazu sind die

Anwendungsbereiche zu unterschiedlich, teilweise konnten auch nicht alle Funktionalitäten getestet

werden. Anstatt die Systeme zu benoten und so einen ,,Testsieger" zu ermitteln, sollen einzelne

besonders gute Eigenschaften stichpunktartig erwähnt werden:

Falk City Guide

Sinnvolle Aufteilung der Benutzeroberfläche

Konsequente Menüführung und Gestaltung

Hohe Interaktivität der Kartenfunktion

Stand der Technik

,,Schnelle" Anwendung durch native Programmierung in C++

Ausreichende Positionsbestimmung mit GPS

3Geo

Client-Server-Architektur im UMTS-Netzwerk

Gute Aufteilung der Benutzeroberfläche

Unterstützung von A-GPS-fähigen Smartphones

Einbettung in ein Bezahlsystem

Navitime

Sehr gute Routenfunktion durch Unterstützung aller Verkehrwege

,,Schnelle" Smartphone-Anwendung, weil Brew-basiert

Kleine Dateigröße der Kartenausschnitte durch die Verwendung von Vektorformaten

Einbettung in ein Bezahlsystem

LoVEUS

Touristen sind die klare Zielgruppe

Personalisierung des Informationsangebots mit Tourenvorschlägen

Multimediainformationen zu Points Of Interest

Client-Sever-Architektur im GSM- und UMTS-Netzwerk

Portabilität der Client-Anwendung durch den Einsatz von J2ME

Moderner und standardgemäßer Einsatz von J2EE

Mobile Deep Map

Java-basierte Agenten-Plattform

Touristen als Zielgruppe

Sprachsteuerung

Personalisierung des Informationsangebots mit Tourenvorschlägen

Dynamische Generierung von Kartenausschnitten,

Clientseitiges Rendern von Geodaten im Vektorformat (Übersichtskarte)

Multimediaeinsatz

Mehrsprachigkeit

Die oben genannten positiven Eigenschaften der einzelnen Systeme können zusammengefasst

werden. Somit erhält man eine gute Grundlage für das eigene Konzept.

Gute Ansätze können aufgegriffen und Schwachstellen ggf. verbessert werden. Für einen besseren

Überblick lässt sich die Liste mit den Referenzen nach technischen, gestalterischen und inhaltlichen

Aspekten unterteilen.

Stand der Technik

Ein mobiler Stadtführer zeichnet sich technisch durch

eine Client-Server-Architektur des Systems aus, denn durch sie können die Ressourcen des

mobilen Endgerätes optimal genutzt und rechenintensive Operationen auf den Server

verlagert werden,

eine modulare und service-orientierte Anwendungsarchitektur, die eine Bereitstellung der

Inhalte in einem für die Clients optimalen Format erlaubt,

eine portable Client-Anwendung, die auf unterschiedlichen Geräten lauffähig ist,

eine Positionsbestimmung, welche den Anforderungen (Genauigkeit von ca. 30 Metern)

entspricht,

den Einsatz von breitbandigen, drahtlosen Netzwerktechnologien (z.B. UMTS), damit

Multimediadaten von dem Server zu den Clients transportiert werden können,

die dynamische Generierung von adaptiven Kartenausschnitten im Vektorformat, das eine

kleinere Dateigröße und ein bessere Qualität als Rasterformate verspricht,

die Integration einer Routenkomponente für die Unterstützung unterschiedlichster

Verkehrswege,

die Einbettung in ein Bezahlsystem, worüber einzelne Dienste abgerechnet werden können

und die Verwendung von technischen Standards aus.

Wichtige gestalterische Anforderungen sind

eine sinnvolle Aufteilung der Benutzeroberfläche und eine konsequente Menüführung und

Gestaltung, was die Benutzerfreundlichkeit der Anwendung erhöht,

eine geeignete Visualisierung, Generalisierung und Perspektive der Kartenausschnitte,

die Berücksichtigung von multimodalen Benutzerschnittstellen, wodurch die Interaktion

zwischen Mensch und Maschine erleichtert werden kann,

die Integration von Hilfefunktionen

und die Skalierbarkeit der Benutzeroberfläche für unterschiedliche mobile Endgeräte.

Inhaltlich sollte das zu konzipierende System

Touristen als Zielgruppe anvisieren,

befriedigende, aktuelle und personalisierte Informationen anbieten,

generelle Stadtinformationen und Informationen über Ereignisse in der Stadt bereithalten,

Points of Interest, Ereignissen und Menschen auf den Karten anzeigen und

Zusatzinformationen bereithalten,

offen für die Integration von fremden Diensten sein,

Tourenvorschläge machen und eine leicht zu bedienende Routenfunktionalität integrieren,

kontextbasierte Parameter berücksichtigen,

den Einsatz von Multimedia ermöglichen,

Mehrsprachigkeit vorsehen und eine hohe Interaktivität der Kartenfunktion gewährleisten

Grundlagen

3. Grundlagen

Gemäß der Aufgabenstellung soll ein touristisches Stadtinformationsangebot für mobile Endgeräte

entwickelt werden, das positionsabhängige Inhalte multimedial darstellen kann. In diesem Kapitel wird

auf die für die Erstellung einer solchen Anwendung wichtigen Grundlagen eingegangen.

3.1 Mobile Endgeräte

Unter mobilen Endgeräten versteht man all diejenigen Endgeräte, die für den mobilen Einsatz gedacht

sind. Das beginnt bei kleinen eingebetteten Elementen für Alltagsgeräte und führt über verschiedene

Arten von Mobiltelefonen zu Handheld-Geräten und Tablet-PC. Viele mobile Endgeräte bieten ständige

Erreichbarkeit und ständigen Informationszugriff und sind schon heute aus unserem Alltag nicht mehr

wegzudenken. Der Einzug der Computertechnik in alle Lebensbereiche wird mit dem Begriff

Ubiquitous Computing (UC) beschrieben. Von Max Weiser, einem Pionier des UC, stammt die

Überlegung, dass die tiefgreifendsten Auswirkungen von Technologien ausgehen, die mit

Alltagsgegenständen verschmelzen und aus unserer Wahrnehmung verschwinden.

Alltagsgegenstände werden somit zu Smart Objects und können sicht kontextsensitiv verhalten.

Mobile Endgeräte lassen sich nach Art, Leistungsfähigkeit, Verbreitung und Einsatzzweck

unterscheiden. Sie können stationäre Computer ersetzen, erweitern oder über Funktionen verfügen,

die nicht von stationären Computern angeboten werden.

In der Diplomarbeit wird auf mobile Endgeräte, die stationäre Computer ersetzen, nicht näher

eingegangen. Hierzu können Notebooks und Subnotebooks gezählt werden. Sie sind zwar für den

Einsatz an unterschiedlichen Orten konzipiert und verfügen auch über eine eigene Stromversorgung

und evtl. drahtlose Netzwerkanbindung. Allerdings sind es ihrem Wesen nach Arbeitsplatzrechner, die

zwar verbracht werden können, aber normalerweise nicht unterwegs genutzt werden.

Typische Vertreter der Geräte, die stationäre Computer erweitern, sind Personal Digital Assistants

(PDAs). Ein PDA ist ein Handheld-Computer, der in erster Linie als Organizer genutzt wird. Er stellt

Büro-Standardsoftware, wie Adressbuch, Kalender, Internetbrowser und Mailclient zur Verfügung.

Über eine Docking-Station oder drahtlose Netzwerktechnologien kann eine Synchronisation der Daten

mit einem PC vorgenommen werden. Für die Lokalisierung des Benutzers können GPS-Empfänger per

Kabel oder kabellos (Bluetooth) and das Gerät angeschlossen werden. Einige wenige PDAs verfügen

über eingebaute GPS-Chips. In dieser Gruppe befinden sich die leistungsstärksten mobilen Endgeräte,

die für einen Prototypen in Frage kommen.

Zu der letzten Gruppe können Mobiltelefone gerechnet werden. Ein Mobiltelefon ist ein mobiles

Endgerät, das primär für die Nutzung der Telefonfunktionalität bestimmt ist. 2G-Geräte sind meistens

um Funktionalitäten für den Versand oder Empfang von Kurznachrichten (Short Message Service,

Grundlagen

SMS), erweitert. Viele heutige Mobiltelfone erlauben die Darstellung von Informationen und Diensten

(Wireless Application Protocol, WAP) und verfügen über eine J2ME Virtual Machine (VM) für die

Nutzung von weitgehend plattformunabhängigen Java-Anwendungen.

Ein in Europa noch zahlenmäßiger kleiner Teil der Mobiltelefone erlaubt auch die Darstellung von

cHTML-Seiten (Compact HTML) in einem Microbrowser. Mit dem HTML-Dialekt können farbige Inhalte

dargestellt werden, die für die geringe Bandbreite und Auflösung der Geräte optimiert wurden.

NTTCoCoMo hat mit i-mode einen proprietären Standard für die Nutzung von Internet-Seiten und

Diensten entwickelt, der auf cHTML basiert. In Japan ist i-mode sehr populär und besitzt eine

monopolähnliche Stellung.

In Europa ist dagegen der Anteil von i-mode-fähigen mobilen Endgeräten eher gering. Bessere

Chancen scheint hier der Multimedia Messaging Standard (MMS) zu haben. Der neue Standard für

multimediale Kurzmitteilungen erlaubt die Einbindung von Text, AMR 16-kodierter Sprache (MP3, Midi

und Wav sind geplant) und Bildern als JPEG, GIF (89a oder 87a) oder WBMP (Jpeg 2000 geplant).

Geplant sind auch Videosequenzen als MPEG 4 (Simple Profile), Quicktime, ITU-T H.263 und MMS-

Streaming.

Das 3rd Generation Partnership Project (3GPP), ein Partnerschaftsprojekt für die dritte

Mobilfunkgeneration, hat außerdem kürzlich Scalable Vector Graphics (SVG) als Standard für MMS

angenommen. SVG eignet sich sehr gut für Entertainment-Angebote und Location Based Services. Ein

Teil der Mobiltelefone kann auch Flash-Inhalte darstellen.

Im weiteren Verlauf der Diplomarbeit wird besonders auf J2ME, SVG und Flash eingegangen. Alle drei

Technologien könnten für die Entwicklung einer portablen und interaktiven Clientanwendung, die

multimediale und räumliche Inhalte darstellen kann, geeignet sein. WAP und cHTML eignen sich sehr

gut für die Darstellung von statischen und textuellen Informationen, sind für einen späteren

Prototypenentwurf aber eher uninteressant.

PDAs oder Mobiltelefone lassen sich leicht in eine Kategorie einordnen. Anders verhält es sich mit den

Smartphones. Smartphones vereinen die Funktionen von Mobiltelefon und PDA in einem Gerät. Das

können verschiedene Arten von Mobilen Endgeräten sein, vom 2G-Mobiltelefon mit Farbdisplay bis hin

zum PDA mit Mobiltelefonfunktionalität. Sie werden in erster Linie als Mobiltelefon verwendet, sind

aber mit einem PDA-ähnlichen Betriebssystem ausgestattet.

Nach Marktforschungen von Gartner, IDC und Ovum stellen Smartphones eine echte Konkurrenz für

PDAs dar. Ihr Markanteil wird bis zum Jahre 2006 um bis zu 76 Prozent steigen. In der gleichen Zeit

soll der Markt für traditionelle PDAs lediglich um 8 Prozent wachsen [Maur03]. Eine jüngste

Konsequenz war der Ausstieg von Sony aus dem PDA-Markt [Spie04]. Mittlerweile hat der Kunde die

Grundlagen

Möglichkeit zwischen verschiedenen Modellen und Konzepten zu wählen. Die bevorzugten

Betriebssysteme sind Symbian OS, Palm OS und Windows Mobile 2003 for Smartphone, das auf

Windows CE.Net basiert. Smartphone-Käufer in den USA bevorzugen Palm OS. 46 Prozent aller dort

im Jahre 2003 verkauften PDA-Handys liefen unter dem Betriebssystem von PalmSource. In der

EMEA-Region (Europer, Mittlerer Osten, Afrika) dominiert dagegen das Symbian-OS den Smartphone-

Markt. 93 Prozent aller Smartphones laufen unter diesem Betriebssystem. Ovum prognostiziert, daß

bis 2007 weltweit 100 Millionen Smartphones mit Symbian OS verkauft werden. Im selben Zeitraum

sollen lediglich 22 Millionen Smartphones, die mit Windows Mobile 2003 ausgestattet sind, verkauft

werden [Heis04 und Maur03].

3.1.1 Benutzerschnittstellen

Bei der Gestaltung von Benutzerschnittstellen für mobile Endgeräte spielen die Eingabemöglichkeiten

eine wichtige Rolle. Generell sind hier Einschränkungen und Besonderheiten im Vergleich zu Desktop-

Anwendungen zu beachten. Die Eingabemöglichkeiten sind nicht standardisiert und hängen stark vom

Gerät ab. Das bedeutet Mehraufwand für Softwareentwickler und Benutzer bei dem Umstieg von

einem zum anderen Gerät. Es stehen keine echte Tastatur oder Maus zur Verfügung.

Abbildung 5: Stift- und Tastaturbasierte Eingabe, Quelle Palm

Im wesendlichen wird zwischen den folgenden Eingabemöglichkeiten unterschieden:

Für die

stiftbasierte Eingabe

werden Kunststoffstifte und druckempfindliche Displays genutzt.

Hier dient der Stift als Mauszeiger und erlaubt die Eingabe von kurzen Texten mittels

Schrifterkennung auf dem Display.

Bei den

tastaturbasierten

Geräten erfolgt die Eingabe über Tastatur, Tastenfeld oder externe

Tastatur. Viele Mobiltelefone verfügen im Übrigen über Worterkennungssoftware, mit der ein

geübter Benutzer kurze Texte relativ flüssig eingeben kann.

Grundlagen

Die

Spracherkennung

zur Steuerung, Befehlseingabe und Texterkennung wurde auch von

manchen Softwareherstellern für mobile Endgeräte adaptiert. Spracherkennungssoftware für

PDAs erlaubt die Steuerung von Programmen durch gesprochene Befehle und das Vorlesen

von Terminen, Aufgaben, E-Mails, Telefonnummern, Adressen und anderen Informationen.

Sprachbasierte Schnittstellen für Mobiltelefone lassen sich mit Voice XML realisieren.

Es werden weitere spezielle Interaktionstechniken für mobile Endgeräte erprobt, z.B. kamerabasierte

Blickrichtungsbestimmungen über gyroskopische Sensoren [Vgl. Kret01]. Allerdings sind die

Erfahrungen mit diesen Eingabemöglichkeiten noch sehr gering.

3.1.2 Informationsdarstellung

Ähnlich wie bei den Eingabegeräten sind auch wichtige Einschränkungen hinsichtlich der visuellen

Wiedergabe von Informationen zu beachten. Die eingeschränkte Auflösung der Displays ist eine der

größten Einschränkungen. Sie variiert zwischen 80 x 100 bei Mobiltelefonen und 240x320 Pixeln bei

PDAs und manchen Smartphones. Eine weitere Einschränkung stellt die geringe Displaygröße dar.

Dies betrifft vor allem Menschen mit Sehschwäche. Während die Auflösung kontinuierlich steigt, ist die

absolute Größe des Displays aber aus bautechnischen Gründen beschränkt und wird sich nicht

wesentlich ändern. Die Farbdarstellung von mobilen Endgeräten schwankt zwischen 2 und 220 000

Farben, wobei 220 000 Farben nur von sehr leistungsstarken japanischen Smartphones dargestellt

werden können.

Das Informationsangebot und die Navigation einer mobilen Anwendung müssen auf engstem Raum

dargestellt werden und gleichzeitig benutzbar und erkennbar bleiben. Navigationselemente dürfen

nicht zu viel Platz auf dem Display einnehmen, sollten aber trotzdem groß genug sein, damit z.B. eine

stiftbasierte Eingabe auf einem PDA erfolgen kann. Gleichzeitig muss für Texte eine geeignete

Schriftgröße gefunden werden, um die Lesbarkeit sicherzustellen. Hieraus ergibt sich schon ein

genereller Konflikt zwischen der darstellbaren Größe des Informationsangebotes und der Größe der

Navigationselemente.

Texte sollten für mobile Endgeräte besonders aufgearbeitet werden und sich auf nötige

Kurzinformationen beschränken. Durch die Nutzung von speziellen Visualisierungstechniken für mobile

Endgeräte können lange Texte vermieden werden. Vorstellbar sind interaktive Animationen, Videos

oder gesprochene Präsentationen mit grafischen Elementen. Intelligente Menus sollten im Hintergrund

liegen und so den Blick auf das Informationsangebot frei machen. Für Icons und Sprungmarken lassen

sich besonders aussagefähige Grafiken und Beschreibungen einsetzen. Es muß außerdem zu jeder

Zeit sichergestellt werden, dass der Benutzer weis, wo er sich innerhalb der Anwendung befindet. Für

die visuelle Darstellung der Informationen ist es möglich, spezielle Skalierungstechniken einzusetzen,

damit das Informationsangebot auf Geräten unterschiedlicher Auflösung darstellbar ist.

Grundlagen

3.1.3 Kontextbasierte Parameter und Personalisierung

Die Einbeziehung von Kontext- und Benutzerinformationen ist für den Erfolg eines mobilen Dienstes

sehr wichtig. Individuelle und kulturelle Unterschiede werden schon heute bei der Entwicklung neuer

Smartphones berücksichtigt. Europäer bevorzugen z.B. ein reduzierteres und kühleres Design als

Japaner.

Benutzerbasierte Parameter, wie Alter, Kulturkreis, Bildung, körperliche Einschränkungen, kognitive

Fähigkeiten, die Kenntnis der Region oder persönliche Interessen haben direkte Auswirkungen auf die

Gestaltung eines Grafischen User Interfaces (GUI) und die Inhalte. Für ältere Personen müssen

Anwendungen mit größeren Schaltflächen und Schriftgrößen konzipiert werden. Kulturelle Parameter

haben einen direkten Einfluss auf die verwendete Sprache, die Informationsstruktur und die

Farbgebung. Kinder haben andere kognitive Fähigkeiten als Erwachsene. Für sie sollten verspielte

Gestaltungen und kindergerechte Inhalte angedacht werden. Kontextbezogene Parameter

berücksichtigen vor allem die Aufgabe der Anwendung oder des Informationsangebotes. Hierzu

müssen zuerst die relevanten Informationen für die Beantwortung der Kommunikationsziele

identifiziert werden. Dann können die Auswirkungen des situativen Kontextes auf den Inhalt und

dessen Darstellung beurteilt werden. Benutzer- und kontextbasierte Parameter spielen auch eine

wichtige Rolle bei der Gestaltung von digitalen Karten für den mobilen Einsatz. Beim späteren

Prototypenentwurf werden benutzer- und kontextbasierte Parameter durch Benutzerprofile und den

damit verbundenen Anforderungen näher berücksichtigt.

3.1.4 Umwelteinflüße

Bei der Erstellung von Anwendungen für mobile Endgeräte sind außerdem noch andere

Einschränkungen zu beachten. Umweltgeräusche können die Soundwiedergabe (z.B. in stark

befahrenen Strassen) stark beinträchtigen. Umgekehrt kann die sprachbasierte Eingabe durch

Umweltgeräusche erschwert werden oder an manchen Orten (z.B. Museum, Kirche) unerwünscht sein.

Die wechselnde Beleuchtung der Umgebung kann außerdem starken Einfluß auf die Lesbarkeit des

Displays haben. Generell muss beachtet werden, dass die Aufmerksamkeit des Benutzers stark

schwanken kann, denn er ist (anders als bei der Arbeit am Desktop-PC) vor allem mit der realen Welt

beschäftigt.

3.1.5 Betriebssysteme

Windows Mobile 2003

ist ein multitaskingfähiges Betriebssystem für mobile Endgeräte. Es sind zwei

Versionen des Betriebssystems erhältlich, Windows Mobile 2003 for Pocket PC und Windows Mobile

2003 for Smartphone. Schwerpunkt des Betriebssystems ist die Unterstützung von drahtlosen

Verbindungen, Messaging und Multimedia. Mit Windows Mobile 2003 können IntelXScale-Prozessoren,

die mittlerweile Standard bei Pocket PC's sind, ihr Leistungspotential voll ausschöpfen. Bei dem älteren

Grundlagen

Betriebssystem Pocket PC 2002 kamen XScale-PDAs nur auf 70% ihres Leistungspotentials, da das

Betriebssystem nicht für den mit bis zu 400 MHz getakteten Prozessor und dessen ARM5-Kern

optimiert war. Windows Mobile 2003 basiert auf dem Kernel von Windows CE.NET, einer Variante des

.NET Frameworks speziell für mobile Endgeräte. Das .NET Compact Framework beinhaltet PDA-

spezifische Klassenbibliotheken und Funktionen. Der Code des .NET-Programmiermodells kann aber

auch für andere Geräte angepasst und erweitert werden. Anwendungen für CE.NET werden in Visual

Basic.NET oder C# programmiert. Für Multimedia-Anwendungen auf mobilen Endgeräten ist Windows

Mobile 2003 bis dato das am besten geeignete Betriebssystem.

Palm OS

von der Firma Palm ist ein stabiles Betriebssystem für PDAs. Palm OS 5.x ist grundsätzlich

multitasking-fähig, das parallele Ausführen von aufwändigen Anwendungen kann aber in der Praxis zu

ungewollten Abstürzen führen. Das 32-Bit-Betriebssystem unterstützt erstmals ARM-Chips, womit

generell Multimedia-Anwendungen möglich sind. Bisher lief das Betriebssystem nur auf PDAs mit

Dragonball-Prozessor, der eine maximale Taktrate von 66 MHz besaß. Lizenznehmer, wie Sony,

konnten somit Multimedia PDAs unter PALM OS 5 auf den Markt bringen, die Video-, Musik- und Flash-

Player bieten. Palm OS 6 wird seit Dezember vergangenen Jahres an Gerätehersteller ausgeliefert,

bisher ist allerdings noch kein Gerät mit dem neuen Betriebssystem käuflich zu erwerben. Palm OS 6

soll voll multitasking-fähig sein und drahtlose Netzwerkverbindungen unterstützen. Außerdem, sollen

Display-Auflösungen bis zu 32.000 x 32.000 Pixeln, Grafiktechniken wie Anti-Aliasing, Transparency,

Gradient Fills, Rotation und Musik- und Video-Formate wie MP3, Ogg Vorbis, MPEG1 und MPEG4

unterstützt werden.

Symbian OS

basiert auf dem Kernel des Betriebssystems EPOC, das von Beginn an für mobile

Endgeräte mit beschränkten Resourcen konzipiert wurde. Das Symbian-Konsortium besteht aus den

Firmen Ericsson, Panasonic, Nokia, Psion, Samsung, Siemens und SonyEricsson. Symbian OS wird

ständig weiterentwickelt, z. Z. ist die Version 8.0 erhältlich. Durch die Unterstützung von Standards,

wie MMS, Java, SynchML (XML) und Bluetooth, soll eine große Marktverbreitung erreicht werden.

Symbian 7.0 ist multitaskingfähig und verfügt über ein Multimedia-Framework, das Videos im MPEG4-

Format und Audioformate, wie WAV, AU, oder PCM, unterstützt. Mit der Image Conversion Library

(ICL) können die Bildformate JPEG, GIF, BMP, MBM, SMS, WBMP, PNG, TIFF, WMF und ICO

verarbeitet werden. Über eine 2D Hardware Abstraction Layer (HAL) ist es möglich 2D-

Graphikperationen auszuführen. Symbian besteht grundsätzlich aus den drei Hauptkomponenten

Basis, Middleware und GUI. Durch den modularen Aufbau des Betriebssystems ist es nicht nötig die

GUI oder Middleware groß zu verändern, wenn eine Anwendung auf ein anderes Gerät portiert

werden soll. Bevorzugte Programmiersprachen sind C++ und zunehmend Java.

Grundlagen

3.1.6 J2ME

Bei mobilen Anwendungen spielt die Portabilität zwischen den verschiedenen Systemen und Typen

von Endgeräten eine entscheidende Rolle. Als portable Plattformen für mobile Endgeräte bieten sich

das Symbian Betriebssystem, die Java 2 Micro Edition (J2ME), der Flash Player und BREW an. BREW

wird bislang nur im asiatischen Raum unterstützt. Der Funktionsumfang der anderen drei

Technologien ist recht unterschiedlich. Den größten Funktionsumfang bietet die Programmierung in

C++ unter Symbian OS, allerdings ohne den Komfort und die abgesicherte Umgebung von J2ME.

J2ME ist in unterschiedliche Konfigurationen und Profile eingeteilt. Eine umfangreiche Einführung und

weiterführende Literatur zu J2ME findet man unter [Micro04, Moto04, Sun04, Yuan04].

Auf Mobiltelefonen und Smartphones kommt das Mobile Information Device Profile (MIDP) zum

Einsatz. MIDP ist Teil der Connected Limited Device Configuration (CLDC). Die Konfiguration und das

Profil greifen auf die K Virtual Machine (KVM) zu, die im Prinzip eine optimierte Java Virtual Machine

(JVM) mit den Features der Version JDK 1.3. ist. MIDP stellt Minimalanforderungen an die mobilen

Endgeräte wie 168 KB Speicher, ein monochromes Display von mindestens 96 x 54 Pixeln, eine

Telefontastatur und eine Netzwerkanbindung in beide Richtungen. MIDP 1.0 bietet folgende Klassen:

javax.microedition.lcdui

- javax.microedition.rms

javax.microedition.midlet

javax.microedition.io

java.io

java.lang

java.util

CLDC 1.0 stellt keine Unterstützung für Gleitkommazahlen zur Verfügung. HTTP ist als Standard-

Protokoll vorgeschrieben. Die User Interface API (LCDU) erlaubt nur sehr einfache Grafische User

Interfaces und bietet keinen direkten Zugriff auf den tatsächlichen ,,Feel&Look" der späteren

Anwendung. Remote Method Invocation (RMI) kann nicht genutzt werden, da die ,,Reflection"-API

nicht unterstützt wird.

Die Spezifikationen für MIDP 2.0 wurden Ende 2002 abgeschlossen. MIDP 2.0 erweitert den

Funktionsumfang von MIDP 1.0 deutlich. Es werden sichere Verbindungstypen, wie HTTPS und Secure

Sockets unterstützt (javax.microedition.io).

Die Klasse

javax.microedition.io

wird um eine Graphics-Klasse erweitert, mit der die Programmierung

einfacher zweidimensionaler Objekte vereinfacht wird. Für die Programmierung von Spielen können

mit der neuen Klasse

javax.microedition.lcdui.games

Hintergründe und Sprites in mehreren

überlagerten Schichten dargestellt werden. Mit der Klasse

javax.microedition.media

besteht die

Grundlagen

Möglichkeit monophones Audio zu integrieren. Die Klasse ist ein Subset der Mobile Media API (JSR-

135) für unterschiedliche Audio- und Videoformate. Die Mobile Media API ist eine der Kandidaten für

eine zukünftige Erweiterung von MIDP 2.0. Gute Chancen haben auch die Bluetooth API (JSR-182)

und weitere Erweiterungen der Mobile Game API für die Unterstützung von Sound, 3D-Grafik und den

Anschluss von externen Spielcontrollern.

Für die Erstellung von Location Based Services unter Java sollte ein Augenmerk auf die weitere

Entwicklung der Location API (JSR-179) geworfen werden [vgl. JCP04] . Mit ihr stehen Methoden und

Listenerobjekte für die Ermittlung der eigenen Position über GPS, Mobilfunkzellen oder im lokalen

Netzwerk zur Verfügung. JSR-179 setzt allerdings für die nötige Unterstützung von Gleitkommazahlen

bei der Berechnung von Koordinaten die Connected Device Configuration (CDC) oder CLDC 1.1

voraus. Mit der Motorola GPS-API können schon heute A-GPS-Positionsdaten in J2ME-Anwendungen

ausgewertet werden [Moto03], wobei auf die Motorola-Geräte i730 und A920/925 zurückgegriffen

werden kann [vgl. Moto03, Mahm04, Spiel04].

3.1.7 SVG

Im Abschnitt 3.1.1 wurde erwähnt, dass SVG gut für den mobilen Entertainment-Bereich geeignet ist

und als neuer Standard für MMS angenommen wurde. Auch für die Visualisierung von

Kartenausschnitten eignet sich SVG neben Rasterformaten, wie JPEG oder GIF. Das Vektorformat

bietet einige Vorteile, wie die kleinen Dateigrößen, die Flexibilität und die mögliche Interaktivität, die

für mobile Dienste vorteilhaft sind. Das offene und XML-basierte SVG-Format kann auf mobilen

Endgeräten in zwei Profilen eingesetzt werden [vgl. W3C03, W3C04]:

SVG Tiny

(SVG-T) für Smartphones

SVG Basic

(SVG-B) für PDAs

[Kuko04] gibt einen guten Überblick über die vorhandenen SVG-Viewer für mobile Endgeräte. Es

werden auch einige Entwicklungswerkzeuge für die Erstellung von SVG-T und SVG-B vorgestellt. Ein

Teil der Software ermöglicht den gleichzeitigen Export von SVG- und SWF-Dateien.

Für die Generierung von mobilen Karten im SVG-Format gibt es unterschiedliche Möglichkeiten. Die

wichtigsten Ansätze sind:

die Generierung von SVG mit dem

Java Batik Toolkit

und die Transformation von

Geography Markup Language

(GML) nach SVG über

Extensible

Stylesheet Language Transformation

(XSLT)

Grundlagen

GML ist ein XML-Format für die Beschreibung von Geodaten. Das Objektmodell von GML basiert auf

dem

simple feature model

des

Open GIS Consortium

(OGC). Vordefinierte Eigenschaften beschreiben

in GML die Beziehungen zwischen Features und deren Geometrien. Mit GML können Geodaten

strukturiert werden, es eignet sich aber nicht für die Visualisierung, da es keine grafischen Elemente

enthält. Hier kommt SVG ins Spiel. Eine Transformation von XML-Dokumenten ist über XSL-

Stylesheets möglich. Das kann server- oder clientseitig geschehen. In [Brin03] wird ein clientseitiges

Parsen von GML unter PersonalJava und J2ME beschrieben. Die geparste Karte kann dann in einem

SVG-Viewer dargestellt werden [vgl. Reic02, Reic03, Meng03].

3.1.8 Flash

Macromedia Flash hat sich als aktueller Standard für die Erstellung von Multimediaanwendungen für

das Internet etabliert. Das kann zum einen auf die große Verbreitung des PlugIns zurückgeführt

werden. Bei 97% der Onlineuser ist es installiert [Mac03]. Andere Vorteile sind die kleinen

Dateigrößen des SWF-Vektorformats, (SWF, Shockwave Flash) die progressive Übertragungsweise, die

einfache Integration von anderen Multimediaformaten und die Scripting-Fähigkeiten mit Action Script

1.0 und 2.0.

Dynamische Inhalte lassen sich über Variablen-Paare oder XML aus Datenbanken, Dateisystemen

oder durch andere serverseitige Technologien einbinden. Seit einiger Zeit kann auch das serverseitige

Flash Remoting Gateway eingesetzt werden. Durch eine binäre Übertragung der Daten (ActionScript

Message Format (AMF)) wird die Packetgröße erheblich reduziert. Das Flash Remoting Gateway

erlaubt direkte Verbindungen zwischen einem Flash Movie und ColdFusion, J2EE, ASP.NET, PHP oder

SOAP-basierten Webservices. Komplexe Objekte, wie Arrays, Strukturen und Recordsets können ohne

Serialisierung/ Deserialisierung übertragen werden. So ist es möglich auf Recordsets und auch auf

serverseitige Methoden direkt zuzugreifen. [ Vgl. Muck03]

Macromedia veröffentlichte die Spezifikationen des SWF-Formats 1998, was zu einer weit verbreiteten

Integration des SWF-Formats in gängige Multimediaprogramme geführt hat und zu einer Vielzahl von

neuen Programmen für die Erstellung von Flash Movies. Meistens konzentrieren sich diese Programme

auf Funktionalitäten, die mit der Entwicklungsumgebung gar nicht oder nur eingeschränkt zu

implementieren sind, z.B. 3D-Modellierung, Texteffekte oder Multiuser-Anwendungen. Mit ASP, PHP,

Java, C, C++, Python und Ruby können SWF-Dateien auch serverseitig generiert werden. Einen

neuen Weg beschreitet Macromedia mit dem Macromedia Flex Presentation Server. User Interfaces

lassen sich mit der Macromedia Flex Markup Language (MXML) beschreiben, die von Programmieren

mit ASP.NET- oder JSP-Erfahrung schnell gelernt werden kann. Das Applikationsframework generiert

bei einer Anfrage automatisch eine SWF-Datei. Für mobile Endgeräte kann die Technologie (noch)

nicht genutzt werden, da sie den FlashPlayer 7 auf der Client-Seite voraussetzt, der von einem keinem

mobilen Endgerät unterstützt wird.

Grundlagen

Die benutzerfreundliche Entwicklungsumgebung von Flash erweist sich als außerordentlich

komfortabel und intelligent, denn sie geht adaptiv auf den Kontext der Nutzung ein. Es werden

unterschiedliche Layouts der Benutzeroberfläche zur Verfügung gestellt, wodurch auf die speziellen

Bedürfnisse von Designern oder Programmierern eingegangen werden kann. Designer mit wenig

Programmierkenntnissen können für die Erstellung von Animationen oder Grafiken zeitleistenbasiert

animieren und intuitive Zeichenwerkzeuge benutzen. Interaktivität lässt sich durch einfaches Action

Script oder durch die Nutzung von vorprogrammierten Komponenten mit variablen Parametern

hinzufügen.

Entwickler können dagegen mit Hilfe von Action Script und den oben beschriebenen Technologien zur

Integration von dynamischen Inhalten und zur Generierung von SWF-Dateien Rich Internet

Application (RIA) entwickeln. RIA kombinieren die Reaktions- und Interaktionfähigkeit von Desktop-

Applikationen mit der großen Reichweite und Einfachheit von Web-Applikationen. Action Script 1 ist

JavaScript sehr ähnlich, denn es basiert auf den ECMA-262 Spezifikationen. Action Script 2.0 basiert

auf ECMAScript 4 und ist an Java angelehnt, indem es dessen objektorientiertes Programmiermodel

übernimmt.

Über die Flash JavaScript API (JSAPI) können für die Entwicklungsumgebung Skripte geschrieben

werden mit denen sich Entwicklungsprozesse automatisieren lassen. Die JSAPI basiert auf einem

Document Object Model (DOM) und beinhaltet alle Elemente der Netscape JavaScript API und des

Flash DOM. Somit lassen sich Skripte programmieren, die sich wie Befehle verhalten und Werkzeuge

zu der Werkzeugpalette der Entwicklungsumgebung hinzufügen.

Der Flash Player steht in unterschiedlichen Profilen für verschiedene mobile Endgeräte zur Verfügung.

Für PDAs mit den Betriebssystemen Windows Mobile for Pocket PC 2002, 2003 und Phone Edition ist

der Flash Player 6 frei verfügbar. Für die Smartphones Motorola A 920 und 925, das Nokia

Communicator 9200 und die PDAs der Sony CLIÉ NZ-Serie kann auf den Flash Player 5

zurückgegriffen werden. Die Player sind für mobile Endgeräte optimiert worden und können über AS

auf Systemeigenschaften zugreifen. Einige der Player laufen als Standalone-Player auf dem mobilen

Endgerät, andere werden als ActiveX Component in HTML-Seiten eingebettet.

Flash Lite ist eine neue Version des Flash Players für Smartphones, die von Geräteherstellern und

Mobilfunkunternehmen lizenziert werden kann. Flash Lite 1.0 wurde letztes Jahr von NTTDoCoMo mit

den Modellen der Serie 505i in Japan eingeführt. 35% aller japanischen i-mode-Seiten setzen

heutzutage Flash-Lite Inhalte ein [vgl. Eva04]. Flash Lite 1.0 basiert auf der Flash 4-Syntax und wurde

für Smartphones mit schwacher CPU und geringem Arbeitsspeicher erstellt. Vor allem für Animationen

und Spiele war das Profil gut geeignet. Anspruchsvollere Anwendungen konnten allerdings nicht

Grundlagen

programmiert werden. Die zur Verfügung stehenden Methoden waren hierfür unzureichend,

dynamische Inhalte konnten nicht nachgeladen werden.

Abbildung 6: Flash Lite 1.1., Quelle Macromedia

Das hat sich mit Flash Lite 1.1 geändert. Das Content Development Kit (CDK) ist seit Juli 2004

verfügbar. Im August wurde mit NewsExpress (ein Nachrichtendienst für T-Mobile-Kunden in

Deutschland, Österreich und England) der erste auf dem neuen Profil basierende Dienst für mobile

Endgeräte (Symbian Series 60 und UIQ) vorgestellt. In Japan hat der Mobilfunkbetreiber KDDI Flash

Lite 1.1 für seine neuen Datendienste lizenziert. Wesentliche Neuerungen sind der Netzwerkzugriff

über HTTP, die Möglichkeit auf Daten im Speicher des mobilen Endgeräts zuzugreifen, eine SVG-T-

Unterstützung und erweiterte Zugriffsmöglichkeiten auf Systemeigenschaften. So können über Action

Script Angaben zum Netzwerkstatus sowie Datum und Uhrzeit ausgelesen werden. Andere Befehle

ermöglichen den Zugriff auf die Vibrationsfunktion oder erlauben das Versenden von SMS, MMS und

e-mail aus einem Flash Movie.

3.1.8.1 Flash Player 6 für den Pocket PC

Die Besonderheiten bei der Programmierung von Flash Anwendung für den Pocket PC werden

ausführlich in Macromedias ,,Flash Content Development Kit for Pocket PC " beschrieben. Eine weitere

Grundlagen

gute Informationsquelle ist das ,,Flash Handhelds Forum" auf Macromedias Internetseiten. Hier

werden Fragen rund um Flash auf mobilen Endgeräten diskutiert.

Flash Applikationen für den Pocket PC sollten ausschließlich in Action Script 1.0. programmiert

werden. Action Script 2.0 kann auf Pocket PCs zu schwer nachvollziehbaren Fehlern führen und die

Performanz negativ beeinflussen. Komponenten, die auf der Basis von Action Script 2.0 programmiert

wurden, sind zu vermeiden, weil sie sehr langsam bzw. nicht lauffähig sind. Aufwändige

Vektoranimationen und viele Transparenzen sollten auch nicht eingesetzt werden, da dies wiederum

zu starken Geschwindigkeitseinbußen führen kann. Mit dem CDK werden einige Beispiele und UI

Komponenten für den Pocket PC ausgeliefert, die einem bei der Erstellung erster Flash Anwendungen

für den Pocket PC helfen. Der Flash Player 6 für den Pocket PC erlaubt es, auf Systemeigenschaften

des mobilen Endgeräts über den

System.Capabilities

Befehl zuzugreifen. So können Informationen

zu dem Speicher, dem Betriebssystem, dem Benutzernamen oder dem Netzwerk ausgelesen werden.

Für eine Entwicklung von swf-Dateien mit Flash Remoting-Unterstützung müssen die Flash Remoting

Komponenten für die Entwicklungsumgebung installiert werden. Sie bestehen aus wichtigen Klassen

für Flash Remoting wie

NetServices.as

RecordSet.as

DataGlue.as

und

NetDebugger.as

Außerdem sind ein Browser für Zusatzinformationen zu den Remote Diensten und ein sehr hilfreiches

NetConnection Debuggingfenster enthalten.

3.1.8.2 Flash Lite 1.1

Eine Einschränkung bei der Entwicklung von Flash Lite 1.1 Anwendungen ist die Tatsache, dass der

Player, im Gegensatz zu anderen Flash Playern, nicht frei verfügbar ist. Macromedia hat ein

Lizenzierungsmodell entwickelt, über das der Player von Mobilfunkunternehmen lizenziert und dann

mit den Inhalten an den Benutzer ausgeliefert werden kann. Europa ist z.Z. die einzige Region

weltweit, in der Flash Lite 1.1 Player für Series 60 Smartphones bereitstehen. Für die Diplomarbeit

wird auf den Flash Player 1.1 zurückgegriffen, der mit dem mobilen Nachrichtendienst NewsExpress

gekoppelt wurde. Es scheint sich hierbei um eine beschränkte Version zu handeln, da keine SVG-

Unterstützung integriert wurde. Sobald sich das Lizenzierungsmodell von Macromdia in der Praxis

durchsetzt und mehr geeignete Smartphones auf dem Markt sind, kann davon ausgegangen werden,

dass sich die Anzahl der installierten Player stark erhöhen wird.

In den ,,Macromedia Flash Lite 1.1 Authoring Guidelines" werden Hinweise zu der Erstellung von Flash

Lite 1.1 Anwendungen gegeben. Außerdem wird auf Artikel von Macromedias Internetseiten und

wichtige Informationen von Entwicklern zurückgegriffen.

Action Script basiert bei Flash Lite 1.1 auf der Flash 4-Syntax, die keine Möglichkeiten zur

Klassenbildung oder der Definition von eigenen Methoden zulässt. Es müssen hier kreative Lösungen

gefunden werden, um das Potential von Flash Lite 1.1 auszureizen. Damit überhaupt Flash Lite 1.1

Grundlagen

Filme aus der Entwicklungsumgebung exportiert werden können, muss diese um Bibliotheken

erweitert werden, die auf Macromedias Internetseiten heruntergeladen werden können. Über eine

optionale Konfigurationsdatei

DecicesMsg.cfg

können die vom Flash Lite 1.1 Player unterstützten

Merkmale gesteuert werden:

...

//Sound related flags

AddSound=off

ADPCM="model xxxx phones"

PCM="model xxxx phones"

MIDI="model xxxx phones"

MFI="model xxxx phones"

MFI_Fujitsu="non Fujitsu platforms"

...

// URL Request related flags

LoadVarsOnePerKeyOrFrame=on

...

//Key related flags

KeySetFull=on

MouseRollOverRollOut=on

...

//Capabilities Flag

Navi4Way=on

Navi4WayWrapAround=off

Email=on

SMS=on

MMS=on

loaddata=on

...

//Extra FSCommand2

<get,getVars,set,setVars,send,getKeyPressDuration,setPersistentData,getPersistentDat

a,clearAutoFocus>

...

Flash Lite 1.1 unterstützt die Audioformate MIDI, MFi, SMAF, PCM, WAV, ADPCM und Mp3. Meistens

werden die Audioformate Wav, AIFF und MP3, die in Flash Movies normalerweise eingebunden

werden können, nicht von Mobiltelefonen unterstützt. Die unterstützten Audioformate hängen vom

jeweiligen Gerät ab, allerdings kommen alle Geräte mit MIDI zurecht. MIDI-Dateien sind sehr klein, da

sie nur Anweisungen für die Wiedergaben von Instrumenten enthalten, die sich auf dem Gerät

befinden. Komprimierte Audiodateien sollten auf Smartphones vorsichtig eingesetzt werden, da die

Dekodierung Rechenleistung beansprucht und eine Wiedergabe langsam sein kann. Audioformate für

mobile Endgeräte werden in der Entwicklungsumgebung von Flash nicht direkt unterstützt, für sie

müssen Proxies im MP3- oder WAV-Format in ein Projekt eingefügt werden. Diese Proxies dienen als

Pointer zu externen Audiodateien für das mobile Endgerät wie MIDI oder sogenannte Sound Bundles.

Sound Bundles lassen sich über die mit den Flash Lite 1.1 Komponenten mitgelieferte Anwendung

SoundBundler.exe erstellen und erlauben es, dieselbe Audiodatei für unterschiedliche Geräte

Grundlagen

einzufügen. Bei dem Export eines Flash Lite 1.1 Movies werden die temporären Proxies durch die

telefonspezifischen Audiodateien oder Sound Bundles ersetzt.

FSCommands werden in Flash benutzt, um Nachrichten von einer swf-Datei an den Container, z.B.

den Web-Browser oder den Standalone-Player, zu senden. Es sind so kommerzielle Produkte

entstanden, welche die Interaktionsfähigkeit von SWF-Dateien mit anderen Programmen stark

erhöhen. In Visual Basic (VB), Visual C++ und weiteren Programmen, die Active X Controls einbinden

können, löst der FSCommand ein VB Ereignis aus, das in dem Container weiterverarbeitet werden

kann.

In Flash Lite 1.1 kann auf spezielle FSCommands2 zurückgegriffen werden, mit denen wichtige

Eigenschaften des mobilen Endgeräts ausgelesen und Methoden ausgeführt werden können. Über die

Funktion

FullScreen()

kann beispielsweise die Größe des Anzeigefensters bestimmt werden.

GetFreePlayerMemory()

ermittelt den freien Speicherplatz, und über

launch()

können andere

Programme gestartet werden. Äußerst wichtig für den Aufbau eines geeigneten Naviagtionskonzeptes

und die Steuerung der Anwendung sind die FSCommand2-Befehle

SetSoftkeys()

und

ResetSoftKeys()

. Über sie kann die Anzeige der Softkeys überschrieben werden. Nachdem die

Funktion

SetSoftkeys()

ausgeführt wurde, wird durch das Drücken der Softkeys ein PageDown-

bzw. PageUp-Ereignis ausgeführt. Innerhalb der entsprechenden Eventhandler lässt sich nun Action

Script für die Steuerung der Anwendung definieren.

3.1.8.2.1 Spezielle Anforderungen

Generell werden ganz spezielle Anforderungen an Smartphoneanwendungen gestellt. So sollten sie

über ein Distributionssystem auf die Clients verteilt werden können. Über ein Bezahlsystem muss es

möglich sein, die Inanspruchnahme von einzelnen Diensten abzurechnen. Ständig benötigte

Programmkomponenten sollten fest installiert werden können, und Inhalte müssen sich dynamisch

nachladen lassen. Allerdings sollten gleichzeitig gewisse Inhalte zwischengespeichert werden, damit

auch eine Zugriffsmöglichkeit gegeben ist, wenn kein Netzempfang besteht. Es lässt sich zwischen

Inhalten unterscheiden, die nie aktualisiert werden müssen und Inhalten, die gelegentlich (z.B.

1xtäglich) bzw. immer aktualisiert werden müssen.

Macromedia ist momentan dabei, diese Anforderungen an Software für Smartphones durch ein neues

Produkt abzudecken. FlashCast ist ein System, mit dem ein Mobilfunkanbieter den Download von

Flash-basierten Anwendungen steuern und auf ein Content Management System (CMS) zurückgreifen

kann. Wie bei dem Produkt Macromedia Central sollen vom Benutzer neue Informationskanäle über

ein vorinstalliertes Interface ausgewählt und installiert werden können. Die Inhalte werden dann in

Form von swf-Dateien serverseitig generiert und an den Benutzer ausgeliefert. Wenn die Inhalte

einmal installiert sind, dann lassen sie sich immer wieder aufrufen, auch ohne Netzwerkanbindung.

Grundlagen

Ähnliche Funktionalitäten werden durch Browser oder J2ME abgedeckt, allerdings sind Flash-Inhalte

interaktiver und multimedialer. FlashCast ließe sich so als e-commerce-Mechanismus einsetzen. Das

Flash Format hat eine kleine Dateigröße und einen kleinen Footprint auf dem Gerät. Natürlich

unterliegt das Format gewissen Einschränkungen, allerdings könnte es sich im Vergleich zu den

anderen gegenwärtigen Technologien im Bereich von interaktiven Multimediainhalten behaupten.

FlashCast wird offiziell im November dieses Jahres auf der MAX-Konferenz in New Orleans vorgestellt.

Für die Diplomarbeit kann allerdings kein Blick auf die Umsetzung des geplanten Produkts geworfen

werden.

3.2 Drahtlose Netzwerke

Die spätere Anwendung setzt eine drahtlose Übertragung der Daten vorraus. Deswegen soll an dieser

Stelle kurz auf die wesendlichen mobilen Kommunikationstechnologien eingegangen werden.

3.2.1 Mobilfunknetze

In Europa ist das

GSM-Netz

(

Global System for Mobile Communication

) immer noch der Standard. Im

GSM-Netz stehen verschiedene Trägerdienste zur Verfügung.

Cirsuit Switched Data

(CSD) erlaubt eine

Datenübertragungsrate von 9,6 14,4 KBit/s. Die Einwahl erfolgt ähnlich wie bei einem Modem im

Festnetz. Die Kosten werden über die Verbindungsdauer abgerechnet.

High Speed Circuit

Switched

Data

(

HSCSD

) fasst vier Übertragungskanäle zusammen und erzielt somit eine maximale

Übertragungsgeschwindigkeit bis zu 57, 6 KBit/s. Problematisch ist die hohe Netzbelastung durch

HSCSD, denn alle Kanäle sind für eine offene Verbindung belegt.

General Packet Radio Service

(GPRS)

bündelt zwar auch die Kanäle, allerdings werden die Daten auf Basis des IP-Protokolls in einzelne

Datenpakete unterteilt und nach Bedarf gesendet. Die maximale Datenrate entspricht mit 57, 6/s KBit

der von HSCSD, die Verbindung ist allerdings jederzeit aktiv und somit immer verfügbar. Die

Abrechnung erfolgt über das tatsächliche Datenvolumen und nicht über die Verbindungsdauer.

Vorteilhafterweise kann der Dienstanbieter die Kapazitäten auf die aktiven Nutzer verteilen.

Enhanced

Data Rates for GSM Evolution

(

EDGE

) erweitert GSM durch spezielle Modulationstechniken, wodurch

maximale Datenübertragungsraten von 384 KBit/s möglich sind. Die nächste Generation des

Mobilfunks

UMTS

(

Universal Mobile Telecommunication System

) wird momentan in Europa eingeführt

und erreicht maximale Übertragungsraten von 2 MBit/s. Während bei GSM Zeitmultiplexing für die

Übertragung der Daten eingesetzt wird, arbeitet UMTS nach dem

WCDMA

Wideband Code Devision

Multiple Access

) Verfahren, bei dem alle Daten zur selben Zeit auf der gleichen Frequenz übertragen

werden. Die Frequenz entspricht dem 25-fachen von GSM, wodurch die hohen Übertragungsraten erst

möglich sind.

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 2004
ISBN (eBook): 9783832492915
ISBN (Paperback): 9783838692913
DOI: 10.3239/9783832492915
Dateigröße: 3.6 MB
Sprache: Deutsch
Institution / Hochschule: Hochschule für Technik und Wirtschaft Berlin – 4 Wirtschaftswissenschaften II, Studiengang Internationale Medieninformatik
Erscheinungsdatum: 2006 (Januar)
Note: 1,0
Schlagworte: umts smartphone prag tourismus flash

Autor

Christian Halbach (Autor:in)

Konzeption und Entwicklung eines mobilen Stadtführers

Zusammenfassung

Leseprobe

Inhaltsverzeichnis

Details

Autor

Christian Halbach (Autor:in)