diplomarbeit am ikg - Institut für Kartographie und Geoinformatik

Transcrição

diplomarbeit am ikg
Andreas Adam
Entwicklung eines
Fahrradtouren-Navigationssystems
für Pocket PCs
Betreuer:
Dipl.-Ing. Birgit Elias
Prüfer:
Prof. Dr.-Ing. habil. Monika Sester
Erklärung
I
Erklärung
Ich versichere, dass ich die vorstehende Arbeit selbstständig und ohne fremde Hilfe
angefertigt und mich anderer als der im beigefügten Verzeichnis angegebenen Hilfsmittel
nicht bedient habe. Alle Stellen, die wörtlich oder sinngemäß aus Veröffentlichungen
entnommen wurden, sind als solche kenntlich gemacht.
....................................…….
Andreas Adam
Hannover, 25. April 2004
Vorwort
II
Vorwort
Die vorliegende Arbeit entstand während meines Studiums der Geodäsie und
Geoinformatik am Institut für Kartographie und Geoinformatik der Universität Hannover.
Infolge der komplexen zu behandelnden Thematik - der Umsetzung eines
computergestützten Navigationssystems für Fahrradtouren - ist der Inhalt breit über viele
Themen gefächert. Die aufgestellten Konzepte und Implementierungen wurden so
gestaltet, dass sie sich problemlos auf andere ähnlich ausgerichtete Systeme übertragen
lassen und als Ausgangspunkt für weiterführende Arbeiten in den einzelnen Teilbereichen
herangezogen werden können.
Danken möchte ich besonders Dipl.-Ing. Birgit Elias für die wissenschaftliche Betreuung
der Arbeit und der Bereitstellung leistungsfähiger Hard- und Software-Elemente sowie
eines umfassenden ATKIS-Basisdatenbestands.
Prof. Dr.-Ing. habil. Monika Sester danke ich für die Evaluierung meiner Arbeit.
Dank gebührt auch der LGN, die sämtliche, zur anwendungsspezifischen Implementierung
erforderliche POI-Daten zur Verfügung gestellt hat.
Für das Durchlesen dieser Arbeit und für die fachlichen und stilistischen Korrekturen gilt
mein Dank Dipl.-Ing. Olga Gitlein und Studienassessor Markus Lentz.
Des Weiteren bedanke ich mich bei meinen Eltern und meiner Familie, die mich auf all
meinen bisherigen Wegen vorbehaltlos unterstützt haben.
Abschließend möchte ich mich bei allen Personen bedanken, die durch konstruktive Kritik
oder Beisteuerung guter Ideen zum Gelingen dieses Projekts beigetragen haben.
III
Inhaltsverzeichnis
Inhaltsverzeichnis
Erklärung................................................................................................................................I
Vorwort ..................................................................................................................................II
Inhaltsverzeichnis ................................................................................................................ III
Abkürzungsverzeichnis ........................................................................................................ VI
Darstellungsverzeichnis.....................................................................................................VIII
1
Einleitung.......................................................................................... 1
2
Fahrradtouren-Navigationssystem................................................... 3
2.1 Funktionalität..................................................................................................3
2.2 Anforderungen................................................................................................6
2.2.1
2.2.2
Hardware -Anforderungen................................................................... 6
Software -Anforderungen..................................................................... 7
2.3 Entwicklungsstand.........................................................................................7
2.4 Aktuelle Probleme und Forschungsbedarf.............................................10
3
Standardformate............................................................................. 11
3.1 HTML .............................................................................................................11
3.2 XML ................................................................................................................14
3.3 SVG .................................................................................................................17
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7
3.3.8
Allgemein ............................................................................................. 17
Koordinatensystem............................................................................. 17
Syntax .................................................................................................. 17
Formen, Texte und Rastergraphiken ............................................... 18
Styling und graphische Effekte ......................................................... 19
Animation und Interaktivität ............................................................ 19
Bearbeitungssoftware ......................................................................... 20
Viewer.................................................................................................. 21
3.4 CSS ..................................................................................................................21
4
Ausrüstung...................................................................................... 24
4.1 HP iPAQ H5450............................................................................................24
4.1.1
4.1.2
4.1.3
Merkmale ............................................................................................ 24
Bedienung ............................................................................................ 26
Softwareprogrammierung ................................................................. 27
4.2 Holux GM-270 CF........................................................................................27
4.2.1
4.2.2
Grundlagen von GPS ......................................................................... 27
Merkmale ............................................................................................ 29
Inhaltsverzeichnis
5
IV
Entwicklungsumgebung.................................................................. 31
5.1 ArcView 3.2....................................................................................................31
5.1.1
5.1.2
5.1.3
5.1.4
Einführung in GIS .............................................................................. 31
Struktureller Aufbau.......................................................................... 32
Bedienung ............................................................................................ 32
Avenue ................................................................................................. 35
5.2 EditPlus2 ........................................................................................................35
5.3 eMbedded Visual Basic...............................................................................36
5.3.1
5.3.2
5.3.3
Einführung .......................................................................................... 36
Bedienung ............................................................................................ 37
Erstellung von Programmen............................................................. 38
5.4 JavaScript ......................................................................................................39
6
Konzeption des Fahrradtouren-Navigationssystems ...................... 43
6.1 Allgemeine Konzeption...............................................................................43
6.2 Konzeption der Daten-Komponente ........................................................45
6.2.1
6.2.2
6.2.3
6.2.4
6.2.5
6.2.6
Geometriedaten................................................................................... 45
Sachdaten ............................................................................................ 47
Graphikdaten...................................................................................... 49
Integration der Tour- und der Standort-Daten............................... 50
Optimierung ........................................................................................ 51
Entwicklung ........................................................................................ 54
6.3 Konzeption der User-Interface-Komponente ........................................56
6.4 Konzeption der Visualisierungs-Komponente.......................................58
6.5 Konzeption der Positions-Komponente...................................................58
7
Anwendungsspezifische Implementierung...................................... 60
7.1 Ausgangsszenario.........................................................................................60
7.2 Entwicklung der Daten-Komponente ......................................................60
7.2.1
7.2.2
7.2.3
7.2.4
7.2.5
7.2.6
7.2.7
Generalisierung der ATKIS-Daten................................................... 61
7.2.1.1 Auswahl ................................................................................. 61
7.2.1.2 Klassifizierung....................................................................... 62
7.2.1.3 Zusammenfassung ................................................................. 63
7.2.1.4 Vereinfachung ....................................................................... 64
7.2.1.5 Symbolisierung...................................................................... 65
Graphische Gestaltung der ATKIS-Daten....................................... 66
Integration von Objektbeschriftung ................................................. 67
Integration der Tour-und der POI-Daten........................................ 69
Entwicklung der hybriden Kartengraphik ...................................... 71
7.2.5.1 Allgemein .............................................................................. 71
7.2.5.2 Geometriedaten...................................................................... 72
7.2.5.3 Graphikdaten ......................................................................... 73
Entwicklung der rasterbasierten Kartengraphik ............................ 76
Integration der Positionsangabe ....................................................... 77
Inhaltsverzeichnis
V
7.3 Entwicklung der User-Interface-Komponente ......................................81
7.3.1
7.3.2
Benutzeroberfläche ............................................................................. 81
Interaktionen....................................................................................... 82
7.4 Entwicklung der Positions-Komponente ................................................83
8
Systemtest....................................................................................... 86
9
Bewertung....................................................................................... 89
10 Zusammenfassung und Ausblick.................................................... 92
Anhang................................................................................................................................. 94
Quellenverzeichnis............................................................................................................... 96
Abkürzungsverzeichnis
AdV
Akku
AOI
API
ATKIS
Baud
Bit
BMP
C/A-Code
CF
CSS
PC
DIN
DKM
DLM
DOM
DSK
DTD
ECMA
eSVG
eVB
eVT
GGA
GIF
GIS
G-K
GML
GPS
GSA
GSV
GUI
HTML
Internet
ISO
JPEG
LBS
LCD
LED
LGN
MB
MHz
NMEA
Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der BRD
Akkumulator
Area of Interest
Application Programming Interface
Amtliches Topographisch-Kartographisches Informationssystem
Bit/Sekunde
Binary digit
Bitmap
Clear/Acquisition-Code
Compact Flash
Cascading Style Sheets
Personal Computer
Deutsche Industrie Norm
Digitales Kartographisches Modell
Digitales Landschaftsmodell
Document Object Modell
Digitale Straßenkarte
Document Type Definition
European Computer Manufacturers Association
embedded Scalable Vector Graphics
eMbedded Visual Basic
eMbedded Visual Tools
GPS Fix Data
Graphics Interchange Format
Geographisches Informationssystem
Gauß-Krüger
Geography Markup Language
Global Positioning System
GPS Dilution of Precision and Active Satellites
GPS-Satellites in View
Graphical User Interface
Hypertext Markup Language
International Network
International Standardisation Organisation
Joint Photographers Expert Group
Location Based Services
Liquid Cristal Display
Light Emitting Diode
Landesvermessung und Geobasisinformation Niedersachsen
Megabyte
Megahertz
National Marine Electronics Association
VI
OK
OOP
P-Code
PDA
PERL
PHP
Pixel
PNG
POI
px
RAM
RMC
ROM
SD
SGML
SK
SMIL
SVG
TK
TXT
UMTS
URL
USB
VB
W3C
WGS-84
WWW
WYSIWYG
XML
Objektartenkatalog
Objektorientierte Programmierung
Precision- oder Protected-Code
Personal Digital Assistant
Practical Extraction and Report Language
PHP: Hypertext Preprocessor
Picture Element
Portable Network Graphics
Points of Interest
Pixel
Random Access Memory
Recommended Minimum Specific GPS Data
Read Only Memory
Secure Digital
Standard Generalized Markup Language
Signaturenkatalog
Synchronized Multimedia Integration Language
Scalable Vector Graphics
Topographische Karte
Text
Universal Mobile Telecommunications System
Uniform Resource Locator
Universal Serial Bus
Visual Basic
World Wide Web Consortium
World Geodetic System 1984
World Wide Web
What You See Is What You Get
eXtensible Markup Language
VII
Darstellungsverzeichnis
VIII
Darstellung 2-1: Skalierung von Vektor- und Rastergraphik. ............................................... 5
Darstellung 2-2: Benutzeroberfläche des Fahrradroutenplaners Fahrradies. ........................ 8
Darstellung 2-3: Fahrradcomputer naviiON. ......................................................................... 9
Darstellung 2-4: Mobiles Navigationssystem Thales Navigation Magellan SporTrak. ........ 9
Darstellung 3-1: SGML als Basis von HTML..................................................................... 11
Darstellung 3-2: XML als Teilmenge von SGML. .............................................................. 14
Darstellung 3-3: XML-Baumstruktur. ................................................................................. 16
Darstellung 3-4: SVG- Rendering mit eSVG-Viewer 1.6 und 2.0 auf iPAQ H5450. .......... 21
Darstellung 4-1: Technische Daten HP iPAQ H5450. ........................................................ 25
Darstellung 4-2: HP iPAQ H 5450. ..................................................................................... 26
Darstellung 4-3: GPS-Raumsegment................................................................................... 28
Darstellung 4-4: GPS-Positionsbestimmung. ...................................................................... 29
Darstellung 4-5: GPS-Empfänger Holux GM-270 CF. ....................................................... 29
Darstellung 4-6: Technische Daten Holux GM-270 CF...................................................... 30
Darstellung 5-1: ArcView 3.2 Projekt-Fenster. ................................................................... 33
Darstellung 5-2: ArcView 3.2 Oberfläche. .......................................................................... 33
Darstellung 5-3: ArcView 3.2 Script-, Diagramm-, Tabellen- und Layoutfenster.............. 34
Darstellung 5-4: EditPlus2-Benutzeroberfläche. ................................................................. 36
Darstellung 5-5: eVB 3.0-Entwicklungsoberfläche............................................................. 38
Darstellung 6-1: Aufbau des Fahrradtouren-Navigationssystems. ...................................... 43
Darstellung 6-2: Drei-Komponentenmodell für Objektarten. ............................................. 44
Darstellung 6-3: Spaghetti- Datenmodell ............................................................................. 45
Darstellung 6-4: Verbindungen zwischen Geometrie-, Graphik- und Sachdaten. .............. 46
Darstellung 6-5: Layerkonzept in SVG. .............................................................................. 47
Darstellung 6-6: Semantisches Modell. ............................................................................... 48
Darstellung 6-7: Graphische Gestaltung von Geometrie-Daten. ......................................... 49
Darstellung 6-8: Integration von Tour und Position in die Daten-Komponente. ................ 50
Darstellung 6-9: Hybride Kartengraphik mit sich überlagernde Teilgraphiken. ................. 52
Darstellung 6-10: Hybride Kartengraphik mit benachbarten Teilgraphiken. ...................... 53
Darstellung 6-11: Graphiken im Fahrradtouren-Navigationssystem................................... 54
Darstellung 6-12: Generierung der Datenkomponente. ....................................................... 54
Darstellung 6-13: Generalisierung des Datenbestands. ....................................................... 56
Darstellung 6-14: Benutzeroberfläche der User-Interface-Komponente............................. 57
Darstellung 6-15: Datenmodifikation der Positions-Komponente. ..................................... 59
Darstellung 7-1: Originärer Datenbestand ohne Beschriftung mit Interessengebiet. .......... 61
Darstellung 7-2: Datenbestand ohne Beschriftung nach der Datenauswahl........................ 62
Darstellung 7-3: Klassifizierung von Objekten. .................................................................. 63
Darstellung 7-4: Zusammenfassung von Flächenobjekten einer Objektklasse. .................. 64
Darstellung 7-5: Linienglättung mit Douglas-Peuker-Algorithmus. ................................... 65
Darstellung 7-6: Symbolisierung von Flächenobjekten. ..................................................... 65
Darstellung 7-7: Graphische Gestaltung der generalisierten ATKIS-Daten. ...................... 66
Darstellung 7-8: Behandlung von Objektbeschriftung. ....................................................... 67
IX
Darstellung 7-9: Beschriftung von Gemeindestraßen. ......................................................... 69
Darstellung 7-10: Kartenausschnitt mit Tour- und POI-Daten. ........................................... 70
Darstellung 7-11: HTML-Datei mit POI-Sachinformationen. ............................................ 70
Darstellung 7-12: Eingabemaske des ArcView-Scripts Theme to SVG. ............................ 71
Darstellung 7-13: Aufbau der hybriden Kartengraphik für die Tour 149 ........................... 72
Darstellung 7-14: Legende der hybriden Kartengraphik. .................................................... 75
Darstellung 7-15: Hybride Kartengraphik der Daten-Komponente. ................................... 76
Darstellung 7-16: Rastergraphik der Daten-Komponente. .................................................. 77
Darstellung 7-17: SVG und ϕ,λ-Koordinatensystem. ......................................................... 78
Darstellung 7-18: Benutzeroberfläche von KSDTrans. ....................................................... 79
Darstellung 7-19: Wiedergabe der Standortangabe in der Kartengraphik........................... 80
Darstellung 7-20: Benutzeroberfläche des Fahrradtouren-Navigationssystems.................. 81
Darstellung 7-21: Programmlayout der Positions-Komponente GPSLog. .......................... 83
Darstellung 7-22: Benutzeroberfläche der Positions-Komponente GPSLog. ..................... 84
Darstellung 8-1: Zoomstufen des Fahrradtouren-Navigationssystems................................ 87
Darstellung 8-2: Startpunkt des GeoLife Fahrradtourenvorschlags 149. ............................ 88
Darstellung 9-1: Wiedergabe von Flächenobjekten mit Umrandung auf Gridgrenze. ........ 89
Darstellung 9-2: Wiedergabe von Beschriftungs-Objekten nahe Gridgrenze. .................... 90
1 Einleitung
1
1 Einleitung
Computergestützte Navigationssysteme haben sich längst in der Fahrzeugführung, der
Schiffsführung sowie in anderen Bereichen bewährt und erfüllen eine Vielzahl an
Aufgaben. Standortbestimmung, Streckenplanung und Streckenverfolgung sind hierfür nur
einige Beispiele. Bisher wurden entsprechende Systeme aufgrund ihres relativ hohen Platzund Energiebedarfs überwiegend fest in eine Plattform, exemplarisch ein Kraftfahrzeug,
eingebaut. Heute ergeben sich mit der Entwicklung transportabler, leistungsfähiger
Endgeräte und Module neue Möglichkeiten, einem breiten Publikum mobile, komprimierte
sowie kostengünstige Navigationslösungen zur Verfügung zu stellen. Neue Nutzergruppen
sind beispielsweise Fahrradfahrer oder Fußgänger. Die Akzeptanz in der jeweiligen
Zielgruppe wird durch eine individuelle Systemanpassung hinsichtlich Informationsgehalt
und Informationswiedergabe erhöht.
Der aktuelle Trend auf dem Gebiet der mobilen Navigation geht zur Verwendung von
standortbezogenen Diensten, sogenannten Location Based Services (LBS) hin. Diese
nutzen Informationen über die aktuelle Position eines mobilen Endgeräts (PDA, Handy,
etc.), um dem Anwender, basierend auf den Standortkenntnissen, individuelle
Dienstleistungen und Geo-Daten anzubieten [VOLKMER & WALDENMAIER, 2003]. Dazu
muss die transportable Einheit über eine Ortungs-Komponente, zum Beispiel einen GPSReceiver, und über eine Datenübertragungs-Komponente, zum Beispiel ein UMTS-Modul,
verfügen. Mit einer anwendungsspezifischen Realisierung entsprechender Systeme
beschäftigen sich unter anderem die europäischen Projekte „Geospatial info-mobility
service by real-time data-integration and generalisation“, kurz GiMoDig [GIMODIG,
2004], „Public Safety &Commercial Info Mobility Applications & Services in the
Mountains“, kurz PARAMOUNT [PARAMOUNT, 2004], und WebPark [WEBPARK,
2004]. Einen Nachteil von LBS stellt die erforderliche kostenverursachende
Datenverbindung dar, wodurch die Technologie für einige Zielgruppen mobiler
Navigationssysteme wenig attraktiv erscheint.
Ziel der vorliegenden Arbeit ist die konzeptionelle und prototypische Entwicklung eines
transportablen, effizienten sowie zuverlässigen Navigationssystems für Fahrradtouren. Das
Konzept geht grundsätzlich von der Tourplanung beziehungsweise Tourauswahl an einem
stationären Personalcomputer aus. Dadurch wird, im Gegensatz zu LBS-Systemen, keine
mobile Verbindung zu einem Server benötigt. Die für die ausgewählte Tour benötigten
raumbezogenen Informationen werden mit anderen Systemdaten auf einen GPS-gestützten
PDA übertragen. Der PDA, als primäre Systemeinheit, wird während der Fahrradtour
mitgeführt und liefert eine standortabhängige visuelle Situationsbeschreibung. Sämtliche
vorgestellte Methoden und Implementierungen lassen sich auch auf andere, ähnlich
ausgelegte Projekte übertragen.
Für die zweckmäßige Konzeption und Entwicklung des Navigationssystems sind als erstes
die Funktionalitäten, die Anforderungen und der momentane Entwicklungsstand in Kapitel
2 formuliert. Davon ausgehend werden die gewählten Datenformate (Kapitel 3), Hardware-
1 Einleitung
2
Komponenten (Kapitel 4) sowie Entwicklungsumgebungen (Kapitel 5) vorgestellt. Den
konzeptionellen Aufbau des Systems und einzelner Systembestandteile beschreibt Kapitel
6. Anschließend erfolgt die anwendungsspezifische Implementierung der entworfenen
Strategien anhand des GeoLife Fahrradtouren-Vorschlags 149 „Maschsee-Route zur Expo“
[GEOLIFE, 2004] (Kapitel 7). Durch einen Systemtest wird geprüft, inwiefern das erstellte
Navigationssystem den Nutzeransprüchen entspricht (Kapitel 8). In Kapitel 9 findet die
Bewertung der verwendeten Konzepte und System-Komponenten statt. Zuletzt gibt Kapitel
10 eine kurze Zusammenfassung und einen Ausblick für die behandelte Thematik.
2 Fahrradtouren-Navigation
3
2 Fahrradtouren-Navigationssystem
Die traditionelle analoge Karte kann den individuellen Ansprüchen des Anwenders nur
noch teilweise entsprechen. Besonders der touristische Bereich des Radwanderns macht
diese Position deutlich. Analoge Produkte finden hier überwiegend mobile Verwendung
und erweisen sich oft als unhandlich und unkomfortabel. Zum Beispiel erschweren
Witterungsbedingungen (Regen, Wind, etc.) den Gebrauch. Darüber hinaus ist die
Karteninterpretation für den Nutzer, in der Regel ein Tourist, keine triviale Angelegenheit.
So treten unter anderem Probleme bei der aktuellen Standortbestimmung innerhalb der
Karte auf. Aufgrund des mangelnden Platzangebots repräsentieren Analogkarten lediglich
grundlegende
Informationen.
Detaillierte
Auskünfte
(Adressen,
Ansichten,
Beschreibungen, etc.) über Touristenattraktionen, Hotels oder Gaststätten sind, sofern
vorhanden, in einer externen Kartenbeilage aufgeführt. Als Beispiel ist hier die
Freizeitkarte der LGN 1 zu nennen. Möchte also der Nutzer mehr Informationen über
bestimmte Kartenobjekte erhalten, muss er ein sekundäres Produkt heranziehen.
Konkurrenzfähige
Alternativen
zur
herkömmlichen
Radwanderkarte
stellen
computerbasierte Navigationssysteme dar. Primäres Anliegen dieser Systeme ist die
Standortbestimmung sowie das „Routing“ (Wegführung). Daneben können sie
Entscheidungsfindungen des Anwenders durch weitere raumbezogene Informationen
unterstützen. Denkbar sind exemplarisch Auskünfte über Position, Art und Öffnungszeit
einer standortnahen Gaststätte. Der Vorteil dieser Lösungen liegt folglich in der
Möglichkeit, zusätzliche Funktionalitäten zu integrieren und dem Nutzer eine individuell
angepasste Komplettlösung anzubieten. Während sich Fahrzeug-Navigationssysteme
bereits etabliert haben, ist das Angebot an speziell auf Fahrradtouren angepassten
Systemen begrenzt. Tendenzen weisen aber darauf hin, dass sich die Situation in den
nächsten Jahren, nicht zuletzt wegen des großen Marktpotentials von FahrradtourenNavigationssystemen sowie der technischen Weiterentwicklung im Hard- und
Softwarebereich, deutlich verbessern wird.
Das
Kapitel
stellt
zunächst
die
erforderlichen
Funktionalitäten
eines
Fahrradnavigationssystems zusammen und beschreibt darauf aufbauend die Anforderungen
an einzelne Systemkomponenten. Danach wird der momentane Entwicklungsstand auf dem
Gebiet der Fahrradnavigation analysiert und der sich daraus ergebende Forschungs- und
Entwicklungsbedarf formuliert.
2.1 Funktionalität
Voraussetzung für das Betreiben eines Navigationssystems auf dem Fahrrad sind kompakt
konstruierte, leistungsfähige Hardware-Bestandteile. Als mobiles Endgerät empfiehlt sich
1
Landesvermessung und Geobasisinformation Niedersachsen.
4
ein PDA2 mit Hardware-Schnittstelle, der durch spezielle im Fachhandel erhältliche
Adapter am Fahrrad-Lenker befestigt wird. Die Schnittstelle dient dem Anschluss der
Positionierungskomponente, in der Regel ein GPS-Receiver. Dieser liefert geographische
Standortkoordinaten, die auf das Bezugssystem WGS-84 bezogen sind.
Das System erfordert einen umfangreichen, detaillierten Datenbestand. Einerseits begrenzt
sich die Nutzung von Fahrrädern nicht allein auf Straßen, so dass auch andere befahrbare
Objekte (Wege, Plätze, Wohngebiete, etc.) von Interesse sind. Andererseits liegt der
Verwendungsschwerpunkt von Navigationssystemen, neben der Wegbeschreibung, auf der
Übermittlung von Objektcharakteristiken. Ein Tourist benötigt beispielsweise zusätzliche
Objektinformationen, um sich ein präzises Bild von der Streckenattraktivität machen zu
können. Ausführliche Geo-Informationen haben zudem den positiven Nebeneffekt, die
Orientierung für den Nutzer zu erleichtern und steigern somit die Anwenderfreundlichkeit.
In Anlehnung an die digitale Straßenkarte 1:10000 (DSK10) der LGN mit ausführlichem
Wegenetz und sehr gut lesbaren Straßennamen ist es zweckmäßig, auch für die
Fahrradnavigation Karten im Maßstab 1:10000 einzusetzen und auf diese Weise dem
geforderten hohen Detaillierungsgrad angemessen zu entsprechen.
Zur Präsentation von Geo-Informationen hat sich die Verwendung kartographischer
Gestaltungsmittel in analogen Produkten als sehr sinnvoll erwiesen und spielt auch im
mobilen Sektor eine bedeutende Rolle [BUZIEK, 2002]. Digitale Karten sind für ein
niveauvolles Navigationssystem obligatorisch. Neben den gespeicherten Geo-Daten zeigen
sie zudem den aktuellen Standort an. Da prinzipiell das GPS-Bezugssystem WGS-84 vom
Karten-Bezugssystem, wie zum Beispiel Potsdam Datum/Rauenberg, abweicht, setzt die
Integration der Position eine Koordinatentransformation voraus.
Der große Nachteil mobiler Endgeräte ist das kleine Display mit einer exemplarischen
Auflösung von 240 x 320 Pixel. Dieses kann den räumlichen Überblick und die großen
Orientierungszusammenhänge nur teilweise und unter Einbeziehung dynamischer
Vorgänge (Zoomen, Verschieben, etc.) sicherstellen [KELNHOFER, 2002]. Aufgrund der
notwendigen Dynamik eignen sich für Darstellungszwecke in erster Linie vektorbasierte
Graphiken, die Objekte mit Hilfe von Grundstrukturen (Punkt, Linie, Polygon)
wiedergeben. Gegenüber den aus gleichförmigen Grundelementen (Pixel) aufgebauten
Rastergraphiken besitzen sie den Vorteil auf Skalierungen ohne optische
Qualitätsveränderungen zu reagieren (Darstellung 2-1).
2
PDA ist die Abkürzung für Personal Digital Assistant.
Vektor- bzw.
Rastergraphik im
Original
5
Rastergraphik im
Maßstab 2:1
Vektorgraphik im
Maßstab 2:1
Darstellung 2-1: Skalierung von Vektor- und Rastergraphik.
Damit ein Anwender die Dynamik steuern beziehungsweise mit der Kartengraphik
kommunizieren kann, bedarf es kartographischer Interaktionen. Diese erlauben das
Auswählen verschiedener Kartenausschnitte und unterschiedlicher Maßstäbe (Pan und
Zoom) sowie die Gewinnung von Zusatzinformationen [GARTNER, 2000]. Vorstellbar ist
zum Beispiel das Aufrufen einer Adresse durch Anklicken des entsprechenden Gebäudes.
Eine spezielle Form der Interaktion, das adaptive Zoomen, ermöglicht die Anpassung des
kartographischen Datensatzes (Informationsgehalt, Informationsdichte, etc.) an den
Kartenmaßstab [BRÜHLMEIER, 2000]. Insbesondere auf mobilen Displays wird diese
Methode notwendig, um dem Nutzer eine nahezu gleichbleibende Kartenqualität
bereitzustellen.
Da der Anwender generell keine Hand für die Eingabe von Befehlen frei hat (Hände am
Fahrrad-Lenker), muss die notwendige manuelle Systembedienung während des
Fahrradfahrens durch geeignete Funktionalitäten minimiert werden. Zum Beispiel kann die
automatische Zentrierung der Kartengraphik mit Bezug auf den aktuellen Standpunkt eine
manuelle Nachführung des Kartenausschnitts vermeiden.
Visuelle Schnittstelle für Interaktionen ist die graphische Benutzeroberfläche, kurz GUI3 .
Wegen des mangelnden Flächenangebotes auf Kleindisplays konkurriert die graphische
GUI-Gestaltung mit der Darstellung von Kartengraphik [BUZIEK, 2002]. GUIs sollten
daher platzsparend angelegt sein, ohne die Bedienung zu erschweren. Des Weiteren
steigert eine einfach gehaltene, möglichst selbsterklärende Benutzerführung die Akzeptanz
des Navigationssystems.
Zusammenfassend sind in einem Fahrradtouren-Navigationssystem folgende wesentliche
Funktionalitäten inbegriffen:
1. Bestimmung der GPS-Standortkoordinaten und Transformation dieser in das
Kartenbezugssystem,
3
GUI steht für Graphical User Interface.
6
2. Integration und Visualisierung der Position innerhalb der Kartengraphik in
Echtzeit,
3. Generierung von Routen unter differierenden Aspekten (kürzester Weg, schnellster
Weg, Streckenattraktivität, etc.),
4. Visualisierung der Tour,
5. Effiziente, vektorbasierte Darstellung detaillierter Geo-Daten im Maßstab 1:10000,
6. Standortbezogene touristische Anfragen
(Sehenswürdigkeiten, Hotels, etc.),
an Points
Of
Interest, kurz POI
7. Integration einer kompakten, anwenderfreundlichen Benutzeroberfläche,
8. Integration grundlegender Interaktionen: Zoom, Pan, GPS ON/OFF,
9. Adaptive Zoomfunktionalität,
10. Möglichst wenig Bedienung des Systems durch den Anwender während einer
Fahrradtour.
Auf die komplexe Thematik der Routenplanung und -berechnung wird im Rahmen dieser
Arbeit nicht eingegangen. Eingehende Charakteristiken der Problematik veranschaulicht
exemplarisch BÄR (2002).
2.2 Anforderungen
Wie bereits erwähnt, soll ein Fahrradtouren-Navigationssystem eine Vielzahl an Aufgaben
erfüllen. Die Anforderungen an die Hard- und Software lassen sich aus den im vorherigen
Abschnitt beschriebenen Funktionalitäten ableiten.
2.2.1 Hardware-Anforderungen
Mobile Navigationssysteme stellen hohe Ansprüche an die einzelnen, kompakt gehaltenen
Hardwarebestandteile. Angesichts des Einsatzes im Außenbereich unterliegen sie
unterschiedlichsten Witterungsbedingungen und Belastungen. Aus diesem Grund ist eine
Resistenz gegenüber Regen, Temperaturveränderungen oder Erschütterungen für alle
Komponenten verbindlich.
Für den reibungslosen Systemablauf (Datenverwaltung, Systemsteuerung, etc.) wird eine
leistungsfähige Zentraleinheit (z.B. PDA) vorausgesetzt. Je größer die Prozessor- und
Speicherkapazität ist, desto niveauvoller präsentiert sich das Navigationssystem.
Damit ein Anwender die diversen graphischen Objekte auf dem Display jederzeit eindeutig
identifizieren kann, muss dieses eine Farbtiefe von mindestens 8 Bit (256 Farben)
unterstützen und nahezu unempfindlich gegenüber Veränderungen der Lichtverhältnisse
oder des Blickwinkels sein.
7
Bei der Auswahl der GPS-Systemkomponente hat die Kompatibilität zur Zentraleinheit
und der darauf installierten Software höchste Priorität. Darüber hinaus erfordert die genaue
Standortbestimmung in Echtzeit eine hohe Aktualisierungsrate (ca. 1 Hz) und eine
Positionsgenauigkeit im Meter-Bereich.
Das größte Problem einer mobilen Einheit ist die Energieversorgung. Fahrradtouren dauern
generell mehrere Stunden, so dass eine Betriebsdauer von mindestens 5 Stunden
abzusichern ist. Da dem komplexen Navigationssystem ein hoher Energieverbrauch
zugrunde liegt, kommen nur hochwertige Akkumulatoren (Akku) als Energiequelle in
Betracht.
Nachfolgend werden die elementaren Anforderungen an die Hardware aufgelistet:
1. Resistenz der Komponenten gegenüber Umwelteinflüssen,
2. Leistungsfähige Zentraleinheit mit Schnittstelle für GPS-Receiver,
3. Resistenz des Farb-Displays gegenüber Betrachtungswinkel und Lichteinfall,
4. Hohe Aktualisierungsrate und ausreichende Positionierungsgenauigkeit des GPSEmpfängers,
5. Gewährleistung einer Betriebsdauer von mindestens 5 Stunden durch Verwendung
eines hochwertigen Akkus.
2.2.2 Software-Anforderungen
Anforderungen an die Software basieren auf der Implementierungsart des FahrradtourenNavigationssystems.
Durch
Festlegung
der
Programmierumgebung,
die
Programmiersprachen und Standardformate beinhaltet, definiert der Entwickler alle für den
fehlerfreien Programmablauf notwendigen Software-Bedingungen.
Das in dieser Arbeit vorgestellte Navigationssystem ist für die Nutzung auf einem mobilen
Endgerät, vorzugsweise dem PDA, ausgerichtet und beansprucht folgende SoftwareKomponenten:
1. Betriebssystem Microsoft Windows CE,
2. SVG-Viewer, zum Beispiel Intesis eSVG-Viewer,
3.
HTML-Viewer, zum Beispiel Microsoft Pocket Internet Explorer.
2.3 Entwicklungsstand
Dieser Abschnitt soll einen Eindruck über den Entwicklungsstand von FahrradtourenNavigationssystemen vermitteln sowie die Stärken und Schwächen einzelner
Lösungsstrategien der derzeitig auf dem Markt erhältlichen Produkte für die
Fahrradnavigation aufzeigen.
8
Internet-basierte, GIS-gestützte Fahrradroutenplaner wie das in Darstellung 2-2
abgebildete Fahrradies [FAHRRADIES , 2001] ermöglichen die Tourplanung und -gestaltung
über das World Wide Web (WWW). Der Anwender kann aus vorgegebenen
Routenvorschlägen wählen oder mit Hilfe der vielfältigen Werkzeuge eine individuelle
Tour zusammenstellen. Druck- und Speicheroptionen gewähren die Mitnahme der
Ergebniskarte in analoger oder digitaler rasterbasierter Form. Für die Nutzung reicht ein
Internet-Browser aus, so dass theoretisch ein Zugriff über mobile internetfähige
Plattformen erfolgen kann. Entscheidender Nachteil dieser Methode ist die fehlende
Positionierungskomponente, wodurch der Anwender auch weiterhin die Aufgabe der
Standortbestimmung und Kartenorientierung übernehmen muss.
Darstellung 2-2: Benutzeroberfläche des Fahrradroutenplaners Fahrradies.
Hochentwickelte Fahrradcomputer, wie zum Beispiel der naviiON [NAVIION, 2003], bieten
eine einfache tourspezifische Punkt zu Punkt Navigation an (Darstellung 2-3). Nach dem
Herunterladen vorgegebener Routen oder der Erstellung individueller Touren auf einem
PC werden die Daten auf das mobile Gerät übertragen. Am Anfangspunkt der Route teilt
der Anwender dem Gerät den Tourstart mit. Daraufhin berechnet der Computer, unter
Auswertung von Fahrtrichtung, zurückgelegter Strecke und Höhenänderung, den aktuellen
Standpunkt. Leider bedingt das Verfahren, dass sich das Fahrrad permanent auf der
berechneten Strecke befinden muss. Zwar teilt der Fahrradcomputer mit, wenn die Ist- von
der Soll-Strecke abweicht, jedoch fehlt die Möglichkeit den Anwender auf die Route
zurückzuführen.
9
Darstellung 2-3: Fahrradcomputer naviiON.
GPS-gestützte mobile Fahrradtouren-Navigationssysteme bilden Geo-Informationen im
Allgemeinen durch sogenannte Topogramme, einer stark schematisierten kartographischen
Präsentationsform, ab. Die einfache Kartengraphik basiert überwiegend auf Rasterdaten, in
wenigen Fällen auf Vektordaten und begrenzt sowohl die Anzahl als auch die Qualität
darstellbarer Thematiken. Das System bestimmt über einen GPS-Receiver den Standpunkt
und visualisiert diesen. Weitere Funktionalitäten unterstützen zudem die Tourplanung und
-anzeige. Exemplarisch ist hier die Thales Navigation Magellan SporTrak-Serie [THALES
NAVIGATION, 2004] zu nennen (Darstellung 2-4).
Darstellung 2-4: Mobiles Navigationssystem Thales Navigation Magellan SporTrak.
Aus Darstellung 2-4 werden die Schwächen des Magellan-Navigationssystems leicht
ersichtlich. Die vektorbasierte Kartengraphik beschränkt sich auf die Wiedergabe von
Verkehrswegen sowie einer begrenzten Anzahl an POIs. Für einen Anwender, der lediglich
von einem Punkt A zu einem Punkt B gelangen will, ist diese Information ausreichend. Da
10
aber ein Fahrradtouren-Navigationssystem neben der Wegeführung auch die Aufgabe einer
detaillierten Situationsbeschreibung übernehmen soll [vgl. Kapitel 2.1], wird das System
den Nutzeransprüchen nicht gerecht.
Alle aufgeführten Technologien bieten lediglich einen Teil der in Kapitel 2.1 aufgestellten
Funktionalitäten. Dementsprechend müssen Lösungen für die Realisierung eines
umfassenden Fahrradtouren-Navigationssystems gefunden werden.
2.4 Aktuelle Probleme und Forschungsbedarf
Aus dem vorherigen Abschnitt wird ersichtlich, dass auf dem komplexen Gebiet der
mobilen Fahrradtouren-Navigation noch immer ein beträchtlicher Forschungs- und
Entwicklungsbedarf existiert. Als besonders problematisch erweist sich die Organisation
der großen Datenmenge, die Einbeziehung von Interaktionen und die Integration von
Zusatzinformationen.
Eine detaillierte, für Fahrradtouren entworfene Situationsdarstellung verlangt die
Speicherung, Verwaltung und Verarbeitung großer Datensätze. Infolge der begrenzten
Rechen- und Speicherkapazität mobiler Endgeräte kann es dabei zu Systemüberlastungen
oder zu inakzeptablen Laufzeiten kommen. Ziel ist somit die Entwicklung und Nutzung
effizienter Methoden für die Informationsablage, -abfrage und -wiedergabe.
Gegenwärtige, GPS-gestützte, mobile Produkte, wie zum Beispiel die Fugawi GPS Karten
Software [FUGAWI, 2004], setzen zu detaillierten Präsentationszwecken vornehmlich
Rastergraphiken ein. Diese lassen sich zwar einfach anfertigen, sind aber gegenüber
Vektorformaten für Interaktionen eher ungeeignet [vgl. Kapitel 2.1]. Es gilt demnach zu
prüfen, inwiefern Vektorgraphiken visuelle Aufgaben in einem zweckgerechten
Fahrradtouren-Navigationssystem übernehmen können.
Obgleich POIs und deren Merkmale eine hohe Bedeutung für den Touristen haben, werden
sie oft in mobilen Navigationssystemen nicht mit einbezogen. Während einfache Symbole
die POI-Standorte markieren, erfordert die Darbietung beschreibender Informationen
zusätzliche Funktionalitäten. Denkbar ist beispielsweise die Datenwiedergabe durch den
Aufruf eines Datenfensters oder einer externen Datei über das POI-Symbol.
3 Standardformate
11
3 Standardformate
Hinsichtlich der Entwicklung von Anwendersoftware ist eine möglichst flexible,
zukunftssichere Gestaltung besonders wichtig. Die Optimierung im Hinblick auf Plattformund Software-Unabhängigkeit hat höchste Priorität [BILL, 1999A ]. Demnach empfiehlt es
sich, bei der Erstellung von Programmen auf einheitliche, konventionelle und klar
definierte Standardformate zurückzugreifen. Kennzeichnend für Standardformate sind ihre
übergreifende Akzeptanz und Verwendung. Unterschieden wird zwischen de-jure und defacto Standards. De-jure Standards, auch als Normen bezeichnet, besitzen offizielle
Gültigkeit. Dagegen stellen de-facto Standards Empfehlungen dar und weisen lediglich auf
die weite praktische Verbreitung hin [WINTER, 2000]. Spezifikationen von Standards
werden von nationalen und internationalen Standardisierungsorganisationen (z.B. DIN und
ISO) herausgegeben [HELD, 2003].
Da das im Rahmen dieser Arbeit entwickelte Fahrradtouren-Navigationssystem
ausdrücklich auf Kompatibilität und Anpassungsfähigkeit ausgelegt ist, bilden
Standardformate die Systemgrundlage. Dieses Kapitel beschreibt die in der
Implementierung der Anwendung [s. Kapitel 7] integrierten Datenstandards HTML, XML,
SVG und CSS. Die jeweilige Charakterisierung entspricht den Empfehlungen des World
Wide Web Consortiums, kurz W3C.
3.1 HTML
HyperText Markup Language (HTML) ist als Publikationssprache die grundlegende und
demzufolge wichtigste Technologie im WWW. Darüber hinaus wächst ihre Bedeutung in
anderen Bereichen. So können heute viele Programme Dokumente im HTML-Format
erstellen, und auch in Betriebssystemen und Anwendungen ist HTML fester Bestandteil
[STEYER, 2001]. Entwickelt wurde HTML von Tim Berners-Lee am Europäischen
Kernforschungszentrum CERN im Jahre 1991 [LAGERSTROM , 2003].
Grundlage der HTML, wie in Darstellung 3-1 abgebildet, ist die normierte Standard
Generalized Markup Language (SGML) [vgl. KAHLISCH & VOGEL, 1997] mit der
entsprechenden Document Type Definition (DTD).
SGML
DTD von
SGML
HTML
Darstellung 3-1: SGML als Basis von HTML [NOACK, 2002A].
3 Standardformate
12
SGML, als ein generalisiertes System, dient der Erstellung von speziellen
Auszeichnungssprachen (Markup Languages). Typisch für eine Markup Language ist die
interne Datenstrukturierung mit Hilfe von Auszeichnungen (Markups). Formatierungen,
wie Lage oder Größe, haben keinen Einfluss. Die relative Positionierung bei der
Datenwiedergabe wird lediglich anhand des inhaltlichen Aufbaus festgelegt [WOLF, 2001].
Gültige Sprachelemente und -attribute sowie deren Definition in einem Dokument legt die
DTD4 zentral und verbindlich fest. In Anlehnung an SGML geht das Konzept von HTML
von einer Trennung der inneren, logischen Dokumentstruktur und der physischen
Repräsentation aus [WEINGÄRTNER, 1999]. Die Umsetzung erfolgt durch die Erstellung der
HTML-Datei in reiner Textform. Durch das Vermeiden von Formatierungen bleibt das
Dokument plattformneutral. Zur Präsentation wird eine spezielle, plattformabhängige
Software (Browser) benötigt, welche den Text interpretiert und darstellt [STEYER, 2001].
Bekannte Browser sind der Microsoft Internet Explorer oder der Netscape Navigator.
In den vergangenen Jahren wurden von dem W3C mehrere HTML-Standards
veröffentlicht. Die wichtigsten Spezifikationen sind HTML 3.2, HTML 4.0 und XHTML
2.0. HTML 3.2 bietet ein für heutige Ansprüche geringes Maß an Funktionalität und ist als
Minimalstandard anzusehen. Bei HTML 4.0 sind zusätzliche Komponenten, wie zum
Beispiel die Einbettung von Objekten (Frame-Technik), integriert. Der große Nachteil des
HTML-Standards ist die hohe Komplexität und Rechenintensität bei der Interpretation.
Diese geringe Effizienz hat zwar keinen signifikanten Einfluss bei der Wiedergabe durch
stationäre High-End-Computer, kann aber auf mobilen Geräten (PDA’s, etc.), aufgrund der
geringen Rechen- und Speicherleistung, Probleme verursachen [LAGERSTROM , 2003]. Aus
diesem Grund hat das W3C 1999 entschieden, HTML nicht weiterzuentwickeln und den
neuen Standard Extensible Hypertext Markup Language (XHTML) einzuführen. XHTML
basiert explizit auf XML [s. Kapitel 3.2], enthält aber in der aktuellen Version XHTML 2.0
ebenfalls Grundstrukturen des HTML-Standards [W3C, HYPERTEXT MARKUP LANGUAGE,
2004]. Die erneuerte Spezifikation hat das Bestreben, dem Anspruch der
Plattformunabhängigkeit auch in der Praxis gerecht zu werden.
Wie bereits erwähnt, speichert HTML seine Daten im blanken Textformat ab. Folglich
kommen für die Programmierung einfache Texteditoren oder so genannte WYSIWYGEditoren in Frage [WEINGÄRTNER, 1999]. Texteditoren wie der EditPlus2-Editor von ESComputing [s. Kapitel 5.3] haben den Vorteil, dass die Eingabe der einzelnen Befehle und
Strukturen direkt stattfindet, wodurch der Inhalt des Dokuments uneingeschränkt vom
Entwickler kontrolliert wird. Allerdings ist die Durchführung einer solchen
Programmierung sehr arbeitsintensiv und nicht ohne Vorkenntnisse in HTML möglich.
Dagegen bieten die „What You See Is What You Get“-Editoren (WYSIWYG) die
Alternative, auch ohne eingehende Kenntnisse im Umgang mit HTML komplexe
Dokumente zu erstellen. So verfügen die heute am weitesten verbreiteten HTML-Tools
(z.B. Microsoft FrontPage, Adobe GoLive oder NetObjects Fusion) über multifunktionale,
graphische Oberflächen und Werkzeuge. Die Übersetzung der mit diesen Tools erstellten
Dokumente in das HTML-Format verläuft anschließend automatisch. Hier zeigt sich der
4
Die DTD eines Standardformats wird von dem zuständigen Standardisierungsgremium veröffentlicht.
3 Standardformate
13
große Nachteil dieser Editoren, weil der Autor keinen Einfluss mehr auf die Erstellung der
HTML-Datei hat und sich auf die Umsetzung durch die Software verlassen muss. Daher
empfiehlt es sich, bei der Generierung und Optimierung von HTML-Seiten auf beide Arten
von Editoren zurückzugreifen.
Zur Verfassung und Organisation eines Dokuments stellt HTML vordefinierte Bestandteile
bereit. Fundamentale Sprachkomponenten sind Elemente und Attribute. Elemente legen
die logische Struktur der Daten fest. Während Blockelemente (z.B. Tabellen) den
Datenbestand in einzelne Absätze unterteilen, werden Inline-Elemente, wie zum Beispiel
Styleeigenschaften, in den Kontext mit eingefügt. Des Weiteren gibt es unsichtbare
Elemente (z.B. interne Kommentare), welche der Browser nicht anzeigt [WEINGÄRTNER,
1999]. Attribute legen die Eigenschaften der einzelnen Bestandteile fest. Die
Auszeichnung von Elementen und Attributen geschieht immer mittels einer Start- und
einer End-Marke (Tags). Der Name eines Tags ist in spitzen Klammern eingebettet, wobei
das End-Tag zusätzlich mit einem Schrägstrich gekennzeichnet ist:
<name> inhalt </name>
Der prinzipielle, strukturelle Aufbau eines HTML-Dokuments stellt sich wie folgt dar:
<html>
<head>
<title>...</title>
</head>
<body>
…
</body>
</html>
Das html-Element weist die Datei als HTML-Dokument aus. Im Dokumentkopf, dem headElement, werden Titel (title-Element) sowie zusätzliche Informationen hinterlegt. Dabei ist
das Deklarieren des title-Elements obligatorisch. Hauptteil des Dokuments ist das bodyElement. Hier wird der wesentliche Inhalt der Datei gespeichert. Neben den bereits
beschriebenen gibt es noch eine Vielzahl anderer Elemente, auf die aber an dieser Stelle
nicht weiter eingegangen werden soll.
Eine ausführliche Beschreibung von HTML und den dazugehörigen Elementen ist der
entsprechenden Fachliteratur, zum Beispiel POWELL (2003), zu entnehmen.
3 Standardformate
14
3.2 XML
Angesichts der Definition von HTML als reine Anwendung von SGML [vgl. Kapitel 3.1]
ist der HTML-Standard sehr statisch und unflexibel gegenüber anwendungsspezifischen
Erweiterungen. Darum hat das W3C im Jahre 1998 den neuen Standard eXtensible Markup
Language (XML) veröffentlicht. XML steht für ein sehr anpassungsfähiges und einfaches
Format, das für mehr Interaktivität in Bereichen wie Datenmanagement und
Datenaufbereitung sorgt [WEINGÄRTNER, 1999]. Schon heute spielt XML eine
herausragende Rolle beim Informationsaustausch im WWW und in anderen Medien.
Der XML-Standard zeigt sich nach Darstellung 3-2 als Teilmenge von SGML und besitzt
damit alle grundlegenden SGML-Funktionalitäten.
XHTML
SGML
XML
DTD von
XML
MathML
GML
Darstellung 3-2: XML als Teilmenge von SGML [NOACK, 2002A].
Wie SGML stellt XML ausschließlich Vorschriften zur Festlegung von Typdefinitionen
zur Verfügung und umfasst keinen verbindlichen, strukturellen Aufbau in Form einer DTD
[NOACK, 2002A ]. Folglich gibt es die Möglichkeit, basierend auf XML,
anwendungsabhängige Sprachelemente zu deklarieren. So abgeleitete Anwendungen,
welche sich mittlerweile als de-facto Standards durchgesetzt haben, sind unter anderem
XHTML, MathML (Mathematical Markup Language) und GML (Geography Markup
Language).
Im Februar 2004 publizierte das W3C die dritte Edition der XML 1.0. Die aktualisierte
Version löste das Original von 1998 ab [W3C, EXTENSIBLE MARKUP LANGUAGE, 2003].
Überdies wurde mit XML 1.1 gleichzeitig ein neuer Standard herausgegeben, der die
Funktionalität, Integrität und Kontrolle von XML-Dokumenten steigert. Eine detaillierte
Beschreibung der Spezifikationen ist in W3C, EXTENSIBLE MARKUP LANGUAGE (2003)
einzusehen.
Eine XML-Datei beruht, übereinstimmend mit anderen Auszeichnungssprachen, auf
reinem Textformat und kann sowohl mit einem Texteditor als auch mit entsprechender
Tool-Software erstellt werden. XML-Tools (z.B. Microsoft XML Notepad) sind in der
Regel frei im Internet, zum Beispiel unter [SELFAKTUELL, 2004], zu finden und beinhalten
neben Werkzeugen zur Entwicklung auch Hilfsmittel für die Kontrolle der Struktur. Zur
Interpretation der XML-Daten kommt ein sogenannter XML-Parser, wie er zum Beispiel in
allen gängigen Web-Browsern integriert ist, zum Einsatz. Aufgrund der Auszeichnung von
XML-Daten in Klartext ist das Speichervolumen im Verhältnis zu einem Binärcode relativ
3 Standardformate
15
groß. Abhilfe schafft hier die Datenkomprimierung durch geeignete Packprogramme, wie
GNU ZIP (gzip) [GAILLY, 2003].
Im Gegensatz zu HTML, das Daten formatiert, strukturiert reines XML die Informationen
einer Datei und beachtet allein deren Bedeutung, nicht deren Aussehen [SALATHE, 2001].
Ohne zusätzliche Stylesheets, wie CSS [s. Kapitel 3.4], oder speziellen Programmen ist die
Formatierung von XML-Daten nicht realisierbar. Der Inhalt eines XML-Dokuments
erscheint in einer Art Baumstruktur, die mittels des Parsers aufgebaut wird [NOACK,
2002A ]. Dadurch können entsprechende Anwendungen auf einzelne Baumknoten
(Elemente) zugreifen. Die Art und die Anzahl von Elementen sind in XML nicht begrenzt
und können frei gewählt werden [WOLF, 2001].
Für XML gilt die strenge Grundregel der Wohlgeformtheit. Sie dient der eindeutigen
Standardisierung und verhindert die differierende Umsetzung des Standards durch
konkurrierende Firmen oder Institutionen. Wohlgeformtheit ist die Syntax eines
Instanzdokuments und eine Abweichung führt unweigerlich zu einer Fehlermeldung
[FIBINGER, 2002]. Jedes Element muss des Syntax entsprechend in Tags eingebettet sein
[vgl. Kapitel 3.1]. Des Weiteren gibt es ein Root-Element, welches alle anderen Elemente
umschließt. XML-Auszeichnungen sind „case-sensitive“, so dass auf Groß- und
Kleinschreibung zu achten ist.
Grundsätzlich besteht eine XML-Datei aus dem Prolog, der DTD-Definition und den
eigentlichen Informationen [HELD, 2003]. Zunächst signalisiert der Prolog dem Browser,
dass es sich um ein XML-Dokument handelt und informiert über zusätzliche Attribute, wie
der zugrunde liegenden Version:
<?xml version=“wert“ encoding”wert“ ...?>
Anschließend folgt die DTD-Definition zur Festlegung der Struktur. Die DTD-Deklaration
enthält das Root-Element, einen Verweis auf die Zugänglichkeit (PUBLIC oder SYSTEM),
den Namen der DTD und die URL der DTD-Datei:
<!DOCTYPE rootelement zugang ”name“ “url” >
Aus Sicht der Wohlgeformtheit ist die Deklaration einer DTD nicht erforderlich. Jedoch
kontrolliert der Parser, nach Prüfung des XML-Dokuments unter dem Aspekt der
Wohlgeformtheit, auch die Identität des Inhalts bezüglich der DTD. Dieser Vorgang, auch
Validierung genannt, setzt eine Dokumenttyp-Definition voraus. Nach der DTD wird der
primäre Datenteil in Form einer Baumstruktur hinterlegt. Jedes Element (Knoten) kann
eine beliebige Anzahl an Unterelementen (Child) innehaben, darf aber nur einem
übergeordneten Element (Parent) zugewiesen werden. Eine Ausnahme bildet das RootElement, welches lediglich Child-Elemente aufweist. Ein einfaches Beispiel spiegelt
Darstellung 3-3 wieder.
3 Standardformate
16
Europa
Frankreich
Deutschland
Einwohner
Flaeche
...
...
Darstellung 3-3: XML-Baumstruktur.
Europa ist hier das Root-Element und hat als Child-Elemente Frankreich und Deutschland.
Deutschland seinerseits sind die Elemente Einwohner und Flaeche nebst Werten
zugeordnet. In einem XML-Dokument stellt sich die Situation wie folgt dar:
<Europa>
<Frankreich> </Frankreich>
<Deutschland>
<Einwohner> ... </Einwohner>
<Flaeche> ... </Flaeche>
</Deutschland>
</Europa>
Neben den Elementen enthält die XML-Struktur noch Attribute und Kommentare.
Attribute bestimmen zusätzliche Charakteristiken und werden innerhalb des Starttags eines
Elements deklariert:
<element attribut1=“wert“ ...> ... </element>
Kommentare, die nur im Quellcode sichtbar sind, aber bei der Interpretation ignoriert
werden, erhalten den Ausdruck:

Für weiterführende Instruktionen zur Verwendung und Implementierung von XML wird
auf adäquate Literatur, zum Beispiel AMMELBURGER (2004), verwiesen.
3 Standardformate
17
3.3 SVG
Dieser Abschnitt stellt die prinzipiellen Eigenschaften und Funktionalitäten von Scalable
Vector Graphics (SVG) vor.
3.3.1 Allgemein
SVG ist ein neuer, offizieller Standard der W3C zur Wiedergabe zweidimensionaler
Vektordaten. Der Vorteil dieses offenen Formats liegt in der Multifunktionalität. So
werden Vektor- sowie Rastergraphiken mit hoher Qualität verarbeitet und Möglichkeiten
der Animation und Interaktion angeboten. Durch diese Flexibilität und Leistungsfähigkeit
besitzt SVG schon heute eine bedeutende Stellung im Bereich Webdesign. Daneben ist zu
erwarten, dass sich das Format auch in anderen Bereichen, in denen graphische Gestaltung
im Vordergrund steht, durchsetzt. SVG ist eine XML-Instanz und hat deshalb alle Vorzüge
und Merkmale von XML [vgl. Kapitel 3.2].
Eine erste SVG-Empfehlung, SVG 1.0, erschien 2001. Im Jahre 2003 ersetzte SVG 1.1 die
alte Version und beseitigte Schwachstellen. Parallel dazu kam es zur Veröffentlichung der
mobilen Versionen SVG Basic und SVG Tiny. Die Empfehlungen für mobile
Anwendungen konkretisieren nur einen Teil der SVG-Spezifikationen und tragen somit der
geringen Speicher- und Prozessorleistung mobiler Endgeräte Rechnung. Derzeit arbeitet
die W3C an der neuen Version SVG 1.2 und an weiteren Empfehlungen für bestimmte
Endgeräte, wie beispielsweise Drucker. Charakteristiken aktueller Versionen können unter
W3C, SCALABLE VECTOR GRAPHICS (2004) nachgelesen werden.
Langfristig gesehen soll SVG gegenwärtige Graphikformate, wie zum Beispiel GIF, JPEG
oder PNG, ersetzen [MEINIKE, 2002] und den hohen Ansprüchen von Entwicklern als auch
Anwendern entsprechen.
Eine weitreichende Übersicht der Gestaltungsmöglichkeiten von SVG liefern ADAM (2002)
und LAUCHARDT (2003).
3.3.2 Koordinatensystem
Dem SVG-Format liegt ein Koordinatensystem zugrunde, welches die Aufgabe der
genauen Positionierung graphischer Elemente übernimmt. Das System ist durch die obere
linke Ecke (Ursprung), die horizontale, nach rechts gerichtete X-Achse und die vertikale,
nach unten gerichtete Y-Achse eindeutig festgelegt. Als Werteinheit stehen relative (z.B.
Pixel) und absolute Angaben (z.B. Zentimeter) zur Auswahl. Werden Koordinaten ohne
Einheit deklariert, weist SVG diesen Größen automatisch den Default-Wert px (Pixel) zu.
3.3.3 Syntax
Wegen der festen Beziehung zu XML entspricht auch die SVG-Datei dem XML-Syntax
[vgl. Kapitel 3.2] mit der generellen Untergliederung in Prolog, DTD und Inhalt. Während
sich der Prolog gegenüber dem des reinen XML-Formats nicht ändert, weist die DTD auf
eine Strukturierung nach dem SVG-Format hin:
3 Standardformate
18
<!DOCTYPE svg PUBLIC “-//W3C//DTD SVG 1.0//EN”
“http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd“>
Den Hauptteil bettet das Root-Element svg ein. Diesem sind weitere Elemente,
einschließlich der entsprechenden Attribute, untergeordnet. Generell beinhaltet das RootElement eigene Zusätze, welche die Ansicht des SVG-Bildes beschreiben. Die Attribute
width und heigth bestimmen den maximal sichtbaren Bereich (Bildgröße) und das Attribut
viewbox steuert, welcher Ausschnitt der SVG-Graphik im Bild sichtbar ist:
<svg width=“...“ height=“...“ viewbox=”… … … …”>
In SVG wird zwischen strukturierenden und graphischen Elementen differenziert.
Strukturierende Elemente dienen der Organisation und verringern die Größe einer Datei.
Dabei fasst zum Beispiel das Container-Element <g> eine beliebige Anzahl von Elementen
als Gruppe zusammen. Modifikationen des <g>-Elements wirken sich dann auf alle
Gruppenmitglieder aus und müssen nicht in jedem Element enthalten sein. Graphische
Elemente, wie geometrische Grundformen oder Texte, repräsentieren den eigentlichen
Zeicheninhalt einer SVG-Datei. Position und Aussehen werden durch Hinzufügen
spezieller Attribute festgelegt. Die Wiedergabe graphischer Objekte ist kontinuierlich. Das
heißt, dass ein am Ende des Quellcodes stehendes Element zuletzt gezeichnet wird und alle
überlappenden Flächen überdeckt, beziehungsweise abdunkelt5 . Dadurch ist SVG befähigt,
unterschiedliche Ebenen auszuzeichnen.
3.3.4 Formen, Texte und Rastergraphiken
Die DTD präzisiert vordefinierte graphische Standardgeometrien, die sehr einfach und
schnell darzustellen sind. In der Version SVG 1.1 gibt es unter anderem Rechtecke, Kreise
und Linien. Entsprechende Tags lauten <rect>, <circle> und <line>. Jedem Tag gehören
Pflichtattribute an, ohne die das Element, nach der DTD, nicht gültig ist. Zum Beispiel
erfordert <circle> das Attribut r (Radius). Der Kreismittelpunkt (cx , cy ) ist dagegen
optional anzugeben:
<circle cx=“...“ cy=“…“ r=”...“/>
Für komplexere Objekte existiert das Tag <path> , mit dem sich beliebige Pfade beschreiben
lassen. Das Pflichtattribut ist d und umfasst eine Liste der benötigten Punktinformationen:
<path d=“M x1 y 1 L x2 y 2 … Z “/>
Buchstaben innerhalb des Pfades kennzeichnen die geometrische Wiedergabe des Pfades.
M (moveto) legt den Startpunkt fest und Z (closepath) schließt den Pfad zu einer Fläche.
Absolute, auf den Nullpunkt bezogene oder relative, auf den Vorgänger bezogene
5
Der Grad der Abdeckung ist abhängig von der Eigenschaft der Opazität (Durchlässigkeit) des jeweiligen
Elements.
3 Standardformate
19
Koordinaten (x i, y i) speichern die Positionen der einzelnen Punkte. Dabei entsprechen
Großbuchstaben einer absoluten, Kleinbuchstaben einer relativen Positionierung.
Segmentlinien sind als Geraden (L), aber auch als Bezier- oder elliptische Kurven
ausgeprägt.
Zur Textauszeichnung stellt SVG das Element <text> bereit. Dementsprechend lassen sich
nahezu alle Formatierungen, Effekte und Funktionalitäten auf Texte übertragen, so dass
sich für die Gestaltung unzählige Möglichkeiten ergeben. Eine einfache Textdeklaration
sieht folgendermaßen aus:
<text x=“...“ y=“...“>inhalt</text>
Den Startpunkt der Text-Grundlinie beschreiben die Attribute x und y .
Neben den Graphikobjekten Form und Text können auch Bilder (Bitmap oder SVG)
integriert werden. Das notwendige Element heißt <image> und unterstützt in SVG 1.1 die
Formate PNG, GIF, JPEG und SVG. Beim Laden eines SVG-Bildes wird dieses nur
statisch repräsentiert, womit jede Dynamik und Interaktion verloren geht. Notwendiges
Attribut von <image> ist xlink:href, das den Pfad der Bilddatei angibt. Die Position und
Größe markieren die Attribute x , y , width und height . Der gesamte Ausdruck lautet dann
exemplarisch:
<image xlink:href=“bild.png“ x=“...“ y=“...“ width=“…” height=”…”/>
3.3.5 Styling und graphische Effekte
Stylingeigenschaften beeinflussen die Wiedergabe graphischer Elemente. Sie sind für die
eigentliche Formatierung, wie Füllfarbe, Durchlässigkeit oder Strichstärke, verantwortlich
und werden mit Hilfe von Präsentationsattributen oder CSS deklariert. Jedes
Präsentationsattribut gehört zu einer gleichnamigen Eigenschaft. Beispielsweise erklärt das
Attribut fill die Füllfarbe eines Kreises:
<circle ... fill=“farbe“/>
Auf die Erläuterung von CSS wird an dieser Stelle verzichtet und auf das Kapitel 3.4
verwiesen.
Spezielle graphische Effekte komplettieren die Gestaltungsmittel. So präsentiert SVG
Elemente und Attribute für Verläufe, Füllmuster, Masken und Filtereffekte. Diese können
einzeln und in Kombination auf alle graphischen Elemente eingesetzt werden.
3.3.6 Animation und Interaktivität
Ein großer Vorteil von SVG gegenüber herkömmlichen Graphik-Formaten ist die
Möglichkeit, Animationen und Interaktivitäten auf einfachstem Weg zu implementieren.
3 Standardformate
20
Für die Animation liefert die Syntax unterschiedliche Elemente und Attribute. Diese
entstammen dem XML-Multimediastandard Synchronized Multimedia Integration
Language (SMIL) [FIBINGER, 2002]. Es werden Funktionalitäten für schlagartige oder
interpolierte Veränderungen von Geometrie, Position oder Farbe angeboten. Optionale
Attribute kontrollieren Beginn, Dauer und Ende der Animation.
Interaktivität verleiht SVG-Anwendungen die Fähigkeit auf benutzergesteuerte Ereignisse
(Events) dynamisch zu reagieren. Auslösende Events können Mausoperationen,
Tastatureingaben oder auch Statusänderungen einzelner Elemente sein. Die Aktivierung
eines Events startet einen dem Ereignis zugewiesenen Prozess, wie das Schließen des
Dokuments. Instrumente zum Erzielen von Interaktivität sind Hyperlinks und Scripte. Der
Hyperlink ist lediglich imstande ein Objekt, prinzipiell eine externe Datei, aufzurufen.
Anspruchsvollere, individuelle Interaktionen liefert die Implementierung interner oder
externer Scripte. Sie werden in der Programmiersprache ECMAScript, einem JavascriptDialekt formuliert. Die Charakteristiken dieser Sprache stellt Kapitel 5.4 vor.
3.3.7 Bearbeitungssoftware
Begründet in der wachsenden Bedeutung von SVG, steigt stetig die Anzahl publizierter
SVG-Software. Nachstehend wird die Funktionalität und das Potential aktueller SVGEditoren und -Konverter vorgeführt.
Für die Erstellung einfacher, statischer SVG-Graphiken liefern die aktuellen
Graphikprogramme Corel Draw 11.0 [COREL, 2004] und Adobe Illustrator 10.0 [ADOBE,
2004] ausreichend Funktionalität. Der Vorteil dieser Programme liegt in der automatischen
Konvertierung von Graphiken in das SVG-Format. Zugleich handelt es sich um reine
WYSIWYG-Tools, so dass keine Vorkenntnisse über die Syntax notwendig sind. Leider
unterstützen die aktuellen Versionen weder Animationen noch Interaktivitäten.
Im professionellen Bereich finden komplexe, explizit auf den Export von SVG-Graphiken
optimierte Tools Verwendung. Zum Beispiel zeigt Jasc WebDraw [JASC SOFTWARE, 2004]
Graphiken wahlweise in der Zeichenebene, als Quellcode oder als Viewer-Vorschau an.
Weiterhin überprüft die Software den Quellcode auf Gültigkeit und verfügt über multiple
Zeichen- und Animations-Werkzeuge.
Erweiterungen zu vektorbasierten Graphik-Programmen ermöglichen die Konvertierung
aus einem, meist firmeninternen Format in den SVG-Standard. So kann die Software
MapViewSVG [UISMEDIA , 2004] der Firma UISMedia Karteninformationen aus Arcview
GIS 3.x (s. Kapitel 5.1) in SVG-Daten umwandeln.
Durch eine neue Strategie auf dem Markt bietet dieser komplette Lösungen für die
Konstruktion, Nutzung und Aktualisierung stationärer und mobiler SVG-Anwendungen an.
Die Firma Intesis präsentiert mit dem Projekt eSVG [INTESIS, 2004] eine solche
Komplettlösung
an.
Das
eSVG-Paket6
wartet
unter
anderem
mit einer
6
Die aktuelle Version eSVG 2.0 ist seit Januar 2004 erhältlich.
3 Standardformate
21
Entwicklungsumgebung und einem sehr schnellen und leistungsfähigen SVG-Viewer auf.
Ob sich das System auf lange Sicht durchsetzen wird, bleibt abzuwarten.
In W3C, SVG IMPLEMENTATIONS (2004) sind Programme mit SVG-Unterstützung
aufgelistet.
3.3.8 Viewer
SVG-Viewer interpretieren und präsentieren die Informationen in SVG-Dateien. Sie sind
als eigenständige Programme oder als Plugin, das als eine Art Zusatzprogramm dient, für
vorhandene Software erhältlich. Beispielsweise gibt es mit dem Adobe SVG Viewer 3.0 ein
kostenloses Plugin zur Darstellung von SVG-Graphiken im Microsoft Internet Explorer.
Nicht jeder Parser unterstützt derzeit alle Eigenschaften des SVG-Standards. Demnach
müssen SVG-Anwendungen individuell an den jeweiligen Viewer angepasst werden.
Außerdem differiert, in Abhängigkeit von implementierten Algorithmen, die
Wiedergabegeschwindigkeit. Darstellung 3-4 vergleicht die SVG-Ladezeiten des eSVGViewers 1.6 und die des eSVG-Viewers 2.0 auf einem PDA der Marke Compaq iPAQ
H5450. Die neue Version 2.0 gibt dank einer neuen Rendering-Technik die SVGs mit einer
bis zu 30% höheren Geschwindigkeit wieder. Schlussfolgernd sind langsame RenderingAlgorithmen besonders bei der Anzeige umfangreicher SVG-Graphiken auf mobilen
Endgeräten (PDA, etc.) kritisch zu betrachten. Es zeigt sich weiterhin, dass das graphische
Datenvolumen in mobilen Applikationen möglichst kleingehalten werden muss, damit die
Ladezeiten für den Anwender akzeptabel sind.
Dateigröße (in kb)
10
20
50
100
200
400
eSVG-Viewer 1.6
eSVG-Viewer 2.0
Ladezeit (in s)
3
5
9
15
33
74
Ladezeit (in s)
2
4
6
10
22
74
Darstellung 3-4: SVG-Rendering mit eSVG-Viewer 1.6 und 2.0 auf iPAQ H5450.
3.4 CSS
Cascading Style Sheets (CSS) ist ein weit verbreitetes Format zur Präsentation von
Elementen im WWW. So empfiehlt das W3C, HTML lediglich für die struktur-relevanten
Informationen zu verwenden und deklarierte CSS im Jahre 1996 als de-facto Standard der
graphischen Gestaltung [vgl. Kapitel 3.1]. CSS bietet die Möglichkeit der flexiblen
Aufbereitung und Manipulation strukturierter Daten, wodurch sich die Funktionalität und
Effizienz der HTML erhöht. Neben HTML nutzen auch andere Auszeichnungssprachen,
wie XML oder SVG, die Vorteile von CSS.
3 Standardformate
22
Theoretisch präsentiert sich CSS als plattformneutral und von jedem Browser
interpretierbar. In der Praxis wurde dieser Anspruch jedoch nur eingeschränkt realisiert.
Besonders die komplexeren Stylesheet-Definitionen sind von den momentan führenden
Browserherstellern (u.a. Microsoft und Netscape) nur teilweise implementiert [DILTHEY,
2003]. Die Tendenzen weisen aber auf eine deutliche Verbesserung der Situation in den
nächsten Jahren hin. Eine Übersicht aktueller CSS-Browser und -Software ist in W3C,
CASCADING STYLE SHEETS (2004) aufgeführt.
Das W3C gibt kontinuierlich neue Sprachversionen von CSS heraus. Der aktuell gültige
Standard heißt CSS2 und ist seit 1998 gültig. Daneben gibt es die ältere Version CSS1 und
spezielle Varianten für andere Geräte (z.B. PDA, Telefon, Drucker). An einer CSS3
Empfehlung wird derzeit intensiv gearbeitet.
Generierung und Speicherung der CSS-Syntax können durch einfache Texteditoren oder
spezielle CSS-Hilfsmittel erfolgen. In HEINICKE (2003) sind einige kostenlose,
leistungsstarke CSS-Programme erläutert.
Die wesentliche Verwendung von CSS soll am Beispiel von SVG [vgl. Kapitel 3.3] gezeigt
werden. Prinzipiell besteht eine CSS-Deklaration aus einem zu formatierenden Element
und einer zugehörigen Stylesheet-Anweisung. Eine Anweisung unterteilt sich in
Eigenschaften und den dazugehörigen Werten. Als Elemente kommen einzelne Objekte
(z.B. ein bestimmtes Objekt der Klasse line), Objektklassen (z.B. alle Objekte der Klasse
line) und Objektgruppen, das heißt alle Objekte innerhalb einer allgemeinen Klasse, in
Frage. Für die Verknüpfung der Elemente mit dem jeweiligen Layout gibt es
unterschiedliche Möglichkeiten. Am Gebräuchlichsten sind die direkte Einbindung, die
Referenzierung mittels Entities und die Verbindung zu externen CSS-Dokumenten. Bei der
direkten Auszeichnung werden, unter Verwendung des Attributs style, die
Formateigenschaften nebst Werten nacheinander in das Element-Tag geschrieben und per
Semikolon voneinander getrennt:
<element style=“eigenschaft:wert; ...“/>
identifiziert die zugewiesenen Zeichendaten als CSS-Syntax und beschränkt die
Formatierung auf das jeweilige Objekt. Im Gegensatz dazu bietet die Variante der
Referenzierung die Chance, CSS-Formate oder auch Attribute einmalig zu beschreiben und
an anderer Stelle auf diese zurückzugreifen. Voraussetzung dieser Methode ist die DTDErweiterung der XML-Applikation [vgl. Kapitel 3.2]. Hierfür werden die benötigten
Entities in rechteckige Klammern eingebettet und am Ende der DOCTYPE-Deklaration
eingefügt:
style
<?xml?>
<!DOCTYPE svg PUBLIC “-//W3C/DTD SVG 1.0//EN” [
<!ENTITY name “eigenschaft:wert; …“>
]>
3 Standardformate
23
Der Zugriff verläuft innerhalb des SVGs über einen so genannten „Pointer” (”&name“),
wobei mehrere Pointer auf ein Entity zeigen können:
<element style=“&name;“/>
Infolge der Beseitigung redundanter Layout-Daten innerhalb einer Datei unterstützt die
Entity-Methode eine optimale Strukturierung von Dokumenten.
Externe CSS-Stylesheets haben dort Priorität, wo mehrere Dokumente die gleichen
Formatierungen verwenden. Eigenschaften werden nur einmal definiert und der Abruf ist
durch mehrere Dokumente möglich. Auf diese Weise minimiert sich die Datenmenge der
CSS und ein Anwender kann mit geringem Aufwand den Inhalt kontrollieren und
modifizieren. Die Stylesheets sind in einer mit dem Suffix .css benannten Datei abgelegt:
.name {eigenschaft: wert; ...}
...
Am Anfang einer jeden Layout-Festlegung steht der Style-Name, dem ein Punkt
vorangestellt ist. Anschließend sind die entsprechenden Stylesheet-Anweisungen in
geschweiften Klammern deklariert. Im SVG-Dokument referenziert der Stylesheet-Prolog
die CSS-Datei mit dem Ausdruck:
<?xml-stylesheet href=“dateiname.css“ type=“text/css“?>
SVG-Elemente sind durch das Attribut class an die jeweilige Formatierung gebunden:
<element class=“name“/>
Ausgelagerte CSS-Anweisungen haben sich durch ihre Flexibilität und Effektivität als
Grundform der Dokumentgestaltung etabliert. Sie ermöglichen eine klare und eindeutige
Trennung von Struktur und Layout, wie es vom W3C für Auszeichnungssprachen
gefordert ist.
Weitergehende Erläuterungen und Spezifikationen sind unter W3C, CASCADING STYLE
SHEETS HOME PAGE (2004) zu finden.
4 Ausrüstung
24
4 Ausrüstung
Beim Entwerfen eines Navigationssystems sind die Hardwarekomponenten von großer
Bedeutung. Insbesondere der mobile Sektor stellt hohe Anforderungen hinsichtlich
Kompaktheit und Leistungsfähigkeit. Darüber hinaus müssen Softwarepakete mit den zur
Verfügung stehenden Geräten abgestimmt werden. Nur die uneingeschränkte
Kompatibilität zwischen Hard- und Software garantiert optimale Performance. Um den in
Kapitel 2.2.1 formulierten Hardware-Anforderungen zu entsprechen, wird für die
Fahrradnavigation eine hochwertige Zentraleinheit mit Farbdisplay sowie ein GPSEmpfänger benötigt.
Das Kapitel beschreibt die Hardwarebestandteile des in dieser Arbeit vorgestellten
Fahrradtouren-Navigationssystems. Haupteinheit ist der PDA HP iPAQ H5450. Das
System komplettiert ein GPS-Receiver des Typs Holux GM-270 CF.
4.1 HP iPAQ H5450
Nicht zuletzt wegen der expliziten Entwicklung für den mobilen Markt avanciert der
„Personal Digital Assistant“7 (PDA) zur weltweit bedeutendsten Plattform im HandheldBereich. PDAs sind multimediale Geräte und können eine Vielzahl an Aufgaben
übernehmen. Unter anderem ist eine Nutzung als Terminplaner, Diktier- oder
Navigationsgerät denkbar. Trotz ihrer geringen Größe liefern aktuelle Modelle ein relativ
hohes Maß an Rechenleistung und Speicherkapazität. Als Betriebssystem hat sich
Microsoft Windows CE 3.0 durchgesetzt, das speziell auf die Bedürfnisse mobiler
Endgeräte angepasst wurde. Mit dem iPAQ H5450 offeriert die Firma Hewlett Packard
[HEWLETT PACKARD, 2004] einen ausgereiften PDA der neuesten Generation.
4.1.1 Merkmale
Um den multimedialen Ansprüchen gerecht zu werden, integriert der iPAQ H5450 diverse
Elemente. Der eingebaute Prozessor des Typs Intel PX250 arbeitet mit einer Taktrate von
400 MHz und repräsentiert den derzeit schnellsten Chipsatz im Mobilcomputer-Sektor. Als
Arbeitsspeicher stehen 48 MB ROM und 64 MB RAM zur Verfügung. Da die im RAM
gespeicherten Daten bei Verlust der Spannungsversorgung verloren gehen, sollten wichtige
Informationen, wenn möglich, im ROM abgelegt werden. Das Display ist ein transflektives
3,8 Zoll Touchscreen-LCD mit der Auflösung von 240 x 320 Pixel. Es kann eine Farbtiefe
von 16 Bit (65536 Farben) wiedergeben und besticht, mit Hilfe der Transflektiv-Methode,
durch eine hohe Wiedergabequalität. Bei der Transflektiv-Technologie realisiert die
Displaybeleuchtung von hinten hohe Kontrastwerte. Gleichzeitig verhindert eine
Reflektion der von vorne eintreffenden Lichtstrahlen die Überstrahlung. Für die nötige
Spannung sorgt ein Lithium-Polymer-Akku, welches nach GIEVERS (2003) eine
7
In der Literatur auch als Organizer oder Pocket PC bezeichnet.
4 Ausrüstung
25
Betriebsdauer von ungefähr 10 Stunden garantiert. Allerdings verbraucht der PDA auch im
ausgeschalteten Modus Strom und erfordert so ein Aufladen in regelmäßigen Abständen.
Weitere Komponenten sind unter anderem Mono-Lautsprecher, Mikrophon und
Kopfhöreranschluss. Darstellung 4-1 liefert eine Übersicht der wichtigsten Spezifikationen.
Merkmal
Prozessor
RAM
ROM
Display
Betriebsdauer
Gewicht
Betriebssystem
Preis (Stand: März 2004)
Daten
Intel PXA250 Taktrate: 400 MHz
64 MB
48 MB Flash-ROM
Typ: Transflektives TFT-Touchscreen LCD;
Größe: 3,8 Zoll; Auflösung 240 x 320 Pixel;
Farben: 65536
ca. 10 Stunden
206 g
Windows CE 3.0
ca. 500 €
Darstellung 4-1: Technische Daten HP iPAQ H5450 [HEWLETT P ACKARD, 2003].
Mit Hilfe eines Synchronisationskabels kann das Gerät über den seriellen Eingang oder
den USB-Port mit einem stationären PC kommunizieren. Eine Dockingstation erleichtert
die Verbindungsherstellung. Infrarot- und Bluetooth-Schnittstelle befähigen zum
kabellosen Datenabgleich mit anderen Geräten. Hardware-Erweiterungen, wie zum
Beispiel Speicherkarte, Modem, GPS-Receiver, steigern das Leistungspotential. Zur
Integration existiert ein Erweiterungssteckplatz für CF- und SD-Karten. Der iPAQ nutzt
zusätzlich das Jacket-Konzept, nach dem ein Aufsteckmodul (Jacket) dem PDA
übergestreift wird und so die Funktionalität erweitert [REINELT, 2002].
Auf das mobile Gerät sind Anwendungsprogramme für stationäre Computer nicht
übertragbar. Darum gibt es speziell auf den PDA zugeschnittene Software. Zum
Lieferumfang des iPAQs gehören obligatorisch mehrere praktische Programme. Das
Betriebssystem Windows CE 3.0 enthält beispielsweise eine verkleinerte Version des auf
Desktop-Computern weit verbreiteten Microsoft Office Pakets (Word, Excel, Internet
Explorer, Media Player, etc.). Weitere freie und kommerzielle Applikationen decken
nahezu jeden erdenklichen Anwendungsbereich (z.B. Utilities, Multimedia, Spiele) ab. Ein
breit gefächertes Angebot ist im WWW, zum Beispiel unter [MOBILE2DAY, 2004], oder im
Handel zu finden.
Die Programminstallation und -deinstallation verläuft prinzipiell über die Verbindung zu
einem stationären PC. Als Verwaltungsassistent fungiert die Synchronisationssoftware
Microsoft ActiveSync, die mit jedem iPAQ mitgeliefert wird. In der Regel liegen
Anwendungen in Form einer ausführbaren Datei (*.exe) auf dem Desktop-PC vor. Nach
dem Start der Datei werden Teile des Programms in einem bestimmten Ordner des
Desktops eingerichtet. Danach prüft das mobile Gerät die Daten auf Integrität und
Kompatibilität. Wenn hier keine Probleme auftreten, wird das Programm übertragen.
Neben den Programmen koordiniert ActiveSync auch den Datenabgleich zwischen
stationärem und mobilem Gerät. Exemplarisch kann eine Synchronisation von Organizer-
4 Ausrüstung
26
Informationen in Microsoft Outlook (Termine, Kontakte, etc.) automatisch ablaufen.
Darüber hinaus konvertiert ActiveSync, bei der Übertragung von Dokumenten auf den
PDA und vice versa, die Dateien in ein auf der Zielplattform lesbares Format [GRIESER,
2002].
4.1.2 Bedienung
Im Gegensatz zu einem Desktop-PC wird der PDA über einen Touchscreen sowie mit den
am Gehäuse befindlichen Schalttasten bedient. Die wesentlichen Bestandteile konkretisiert
Darstellung 4-2. Ein Stift ersetzt die PC-Maus und unterstützt die präzise Ansteuerung
einzelner Elemente. Dabei entspricht das Berühren des Displays dem Klicken einer
Maustaste. Per On/Off-Schalter lässt sich das Gerät ein- beziehungsweise ausschalten.
Nach dem Einschalten des PDAs erscheint die zuletzt genutzte Anwendung. Soll ein
System-Neustart stattfinden, ist ein auf der unteren Seite liegender Reset-Schalter mit Hilfe
des Stifts zu betätigen. Die Navigationstaste auf der Front-Seite ersetzt die Cursor-Tasten
einer PC-Tastatur. Sie hat eine 5-Wege-Funktionalität und spricht, abgesehen von den vier
Richtungen Oben, Unten, Links und Rechts auch auf Drücken an. Durch die vier KombiTasten, die sich individuell programmieren lassen, können oft genutzte Programme direkt
gestartet werden. Zur vereinfachten Nutzung des Mobilcomputers als Diktiergerät existiert
auf der linken Seite eine Record-Taste für das unmittelbare Starten und Beenden
akustischer Aufnahmen.
Stift
Record-Taste
Display
On/Off-Schalter
Navigations-Taste
Kombi-Tasten
Reset-Schalter
Darstellung 4-2: HP iPAQ H 5450.
Angesichts des kleinen Displays weicht die Windows CE Benutzeroberfläche leicht von
der Ansicht stationärer Versionen ab. So sind zum Beispiel die Startmenüleiste am oberen
und Menüs am unteren Displayrand positioniert. Für die Zeicheneingabe wird über ein
4 Ausrüstung
27
Symbol in der unteren rechten Ecke eine visuelle Tastatur aktiviert, die im unteren Teil des
Displays erscheint. Dynamische Vorgänge, wie das Öffnen eines Fensters, wirken in
Relation zu Desktop-Systemen leicht verlangsamt. Als eher ungewöhnlich erweist sich die
Funktionalität der X-Schaltfläche in der rechten oberen Ecke eines Menü- oder
Programmfensters. Das Aktivieren des Symbols führt lediglich zu einem Minimieren des
Fensters und gibt keinen Arbeitsspeicher frei. Da eine Beenden-Anweisung in mehreren
Programmen fehlt, bedarf es zum Schließen eines Menü- oder Programmfensters einer
anderen Methode. Am Unkompliziertesten ist die Verwendung eines Zusatztools.
Beispielsweise stattet Hewlett Packard den iPAQ mit dem iTask-Tool aus, das gezielt
Anwendungen beenden kann.
4.1.3 Softwareprogrammierung
Wie bereits erwähnt, sind Desktop-Anwendungen auf dem PDA nicht oder nur
eingeschränkt lauffähig. Microsoft bietet mit eMbedded Visual Tools 3.0 (eVT 3.0)
[MICROSOFT, EMBEDDED VISUAL TOOLS 3.0-2002 EDITION, 2002] ein kostenloses
Desktop-Entwicklungspaket für die individuelle Erstellung mobiler Programme an. eVT
unterstützt die Sprachen Visual Basic [s. Kapitel 5.3] und Visual C++. Voraussetzung für
die Nutzung Java-basierter Applikationen ist die Installation einer Java Virtual Machine
(z.B. Insignia Jeode [INSIGNIA , 2004]), die als Plug-In in den Pocket Internet Explorer
integriert wird. Somit lassen sich beispielsweise Java-Applets problemlos ausführen.
Neben der Programmentwicklung unter Verwendung stationärer PCs gibt es mit PocketC
[ORBWORKS, 2003] eine umfangreiche Programmierlösung für mobile Plattformen. Die
Software umfasst unter anderem einen prozessorunabhängigen Compiler und mehrere
Bibliotheken, in denen nützliche Funktionen abgelegt sind [REINELT, 2002]. Bei der
Entwicklung von HTML-Dokumenten muss beachtet werden, dass der Pocket Internet
Explorer derzeit ausschließlich das HTML 3.2 Format [vgl. Kapitel 3.1] unterstützt.
Infolgedessen sind mobile HTML-Editoren speziell auf diese Version ausgerichtet.
4.2 Holux GM-270 CF
Die Bestimmung des aktuellen Standorts ist die Grundlage der Navigation.
Dementsprechend wird eine geeignete Hardwarekomponente für das Navigationssystem
benötigt. Als einfache Lösung erweist sich die Integration eines GPS-Geräts, das die
Position durch Satellitenunterstützung genau ermittelt. GPS-Receiver haben, je nach
Anwendungsbereich, sehr unterschiedliche Bauweisen. Zur mobilen Nutzung auf einem
Fahrrad kommen, aus praktischer Sicht, nur sehr kompakte Geräte in Frage. Ein mögliches
Produkt präsentiert Holux [HOLUX, 2004]mit dem GM-270 CF. Dieser Empfänger arbeitet
sehr zuverlässig und kann universell eingesetzt werden.
4.2.1 Grundlagen von GPS
Die Darlegungen dieses Abschnitts gehen, sofern nicht anders erwähnt, aus SEEBER (2003)
hervor.
4 Ausrüstung
28
Das Global Positioning System
(GPS) steht für ein satellitengestütztes
Radionavigationssystem, das genaue 3D-Positions-, Navigations- und Zeitinformationen
liefert. Es hat den Vorteil, nahezu weltweit und zu jedem Zeitpunkt nutzbar zu sein.
Prinzipiell unterteilt sich der Aufbau in Raum-, Kontroll- und Nutzersegment, die im
Folgenden näher erläutert werden.
Zum Raumsegment zählen 24 Satelliten, die mit einer Bahnhöhe von 20200 Kilometern
und einer Umlaufzeit von 12 Stunden, in 6 Bahnebenen platziert sind (Darstellung 4-3).
Diese Konstellation befähigt zu einer ortsunabhängigen Verwendung von mindestens 4
Satelliten. Jeder Satellit sendet kontinuierlich zwei Trägerfrequenzen, L1 mit 1600 MHz
und L2 mit 1200 MHz aus. Den Trägerfrequenzen sind Navigationssignale (Codes) und
Systemdaten aufmoduliert. Während L1 den genauen P-Code (10 MHz) und den weniger
genauen C/A-Code (1 MHz) enthält, umfasst L2 ausschließlich den P-Code. In der
Auswertung wird durch Kombination der unterschiedlichen Signale die Messgenauigkeit
gesteigert.
Darstellung 4-3: GPS-Raumsegment [GARMIN, 2004].
Aufgabe des Kontrollsegments ist die Beobachtung und Anpassung des Systems. Weltweit
verbreitete Monitorstationen, die permanent alle Satellitensignale aufzeichnen, übertragen
die empfangenen Informationen zu einer Hauptkontrollstation. Diese wertet die Daten aus
und sendet Korrekturen mit anderen Informationen über Bodenantennen zu den einzelnen
Satelliten.
GPS-Receiver bilden das Nutzersegment (Darstellung 4-4). Sie erkennen die GPS-Signale
und wandeln diese in brauchbare Messwerte, wie Position, Geschwindigkeit oder Zeit, um.
Zunächst leitet das Empfangsgerät aus den eingegangenen, codierten Signalen PseudoStrecken zu den Satelliten ab. Mit Hilfe der Satellitenpositionen werden dann die
Standortkoordinaten berechnet. Aus geometrischer Sicht sind für die Positionsbestimmung
drei Pseudo-Strecken ausreichend. Eine weitere Beobachtung ist jedoch notwendig, da die
Receiver-Uhr nicht mit der Satellitenuhr übereinstimmt. Der sich so ergebende
Synchronisationsfehler ist der Grund für die Bezeichnung Pseudo-Strecke.
4 Ausrüstung
29
Die Positionen beziehen sich auf das räumliche Bezugssystem WGS-84 mit den
geographischen Koordinaten Länge (λ), Breite (ϕ) und Höhe (h). Je nach Instrumentarium,
Messmethode und Messbedingung variiert die Positionsgenauigkeit zwischen einem
Zentimeter und einigen Metern. Beispielsweise erhöht sich die Qualität mit steigender
Anzahl sichtbarer Satelliten.
GPS-Satellit
GPS-Receiver
Darstellung 4-4: GPS-Positionsbestimmung.
4.2.2 Merkmale
Der GPS-Receiver GM-270 CF der Firma Holux, abgebildet in Darstellung 4-5, ist als
Steckkarte konzipiert und zeichnet sich durch eine platzsparende Bauweise sowie dem
geringen Gewicht von unter 50 g aus. Seine Leistungsmerkmale stellen die einfache
Verwendung und Integration sicher [HOLUX, 2003].
LED
Schnittstelle für externe Antenne
Darstellung 4-5: GPS-Empfänger Holux GM-270 CF.
Für die schnelle Standortbestimmung wird neben dem P-Code der Trägerfrequenz L1 auch
der C/A-Code analysiert. Zudem besitzt das Gerät eine hohe Aufnahmekapazität, die eine
gleichzeitige Verfolgung von bis zu 12 Satelliten garantiert. Die Aktualisierung der
Ausgabedaten findet im Sekundentakt (1 Hz) statt. Bezogen auf die durchschnittliche
Geschwindigkeit eines Fahrrads von 25 km/h entspricht das einer Standortveränderung von
7 Metern und erfüllt bei weitem die Aufdatierungs-Anforderungen im Bereich der
4 Ausrüstung
30
Fahrradnavigation. Dank der implementierten Algorithmen ist selbst in abgeschatteten
Gebieten, wie Städten oder Waldrändern, eine absolute Genauigkeit von 5 bis 25 Metern
[HOLUX, 2003] erreichbar.
Das Produkt unterstützt den CF-Kartenanschluss Typ I zur Integration in andere Systeme
(z.B. PDA oder PC). Sollte die Sicht zum Himmel stark eingeschränkt sein, kann der
Anschluss einer, optional erhältlichen, externen Antenne Abhilfe schaffen. Eine LED gibt
den Gerätestatus wieder. Wenn sie leuchtet, sucht der GPS-Receiver nach verwertbaren
Signalen; blinkt sie, werden Satellitensignale erfasst.
Das Ausgabeprotokoll basiert auf der NMEA 0183 Spezifikation und setzt sich aus den
Datenformaten
GGA,
GSA,
GSV
und
RMC
zusammen.
StandardKommunikationsparameter sind 4800 Baud, 8 Datenbits, 1 Stopbit und kein Paritätsbit 8 .
Die Formate GGA und RMC konkretisieren die für Navigationszwecke erforderlichen
Positionsdaten. Die GSA- und GSV-Datensätze treffen zusätzliche Aussagen bezüglich der
Situation und Konstellation der Satelliten.
Entscheidende Spezifikationen des Holux GPS-Empfängers resümiert Darstellung 4-6.
Merkmal
Satellitenverfolgungskanäle
Signale
Aktuallisierungsrate
Positionsgenauigkeit (ohne SA)
Ausgabeprotokoll
Ausgabeformat
Schnittstelle
Gewicht
Preis (Stand: März 2004)
Daten
12
P-Code auf L1, C/A-Code
1 Hz
5 - 25 m
NMEA 0183 ( Baud rate: 4800 bps,
Data bit: 8, Parity: N, Stop bit: 1)
GGA, GSA, GSV, RMC
CF Typ I
< 50 g
180 €
Darstellung 4-6: Technische Daten Holux GM-270 CF [HOLUX, 2003].
8
Die Bedeutung einzelner Parameter erklärt exemplarisch KIRSCH (2004).
5 Entwicklungsumgebung
31
Eine
effiziente
Software-Entwicklung
setzt
die
Verwendung
geeigneter
Programmierwerkzeuge voraus. Angesichts der Komplexität mobiler Systeme kommen bei
der Erstellung des Fahrradtouren-Navigationssystems unterschiedliche EntwicklungsPakete und Programmiersprachen zum Einsatz. Auswahlkriterien sind unter anderem die
Verfügbarkeit, die Funktionalität, die Unterstützung der implementierten Datenformate
[vgl. Kapitel 3] sowie die Kompatibilität zu den Hardwarekomponenten.
Innerhalb dieses Kapitels werden die Merkmale der zur prototypischen Implementierung
[s. Kapitel 7] verwendeten Entwicklungsumgebungen ArcView 3.2, EditPlus2, eVB und
Javascript zusammengestellt.
5.1 ArcView 3.2
Eine der weltweit am weitesten verbreiteten Desktop-Anwendungen im Bereich
Geographic Information Systems (GIS) ist ArcView [ESRI, 2004]. Das Programm kommt
aus dem Hause ESRI und umfasst zahlreiche Funktionen zur Integration, Präsentation,
Verwaltung und Analyse raumbezogener und situationsbeschreibender Informationen
(Geometrie- und Sachdaten). Im Rahmen dieser Arbeit wurde ausschließlich die Version
ArcView 3.2 genutzt.
5.1.1 Einführung in GIS
Da es sich bei ArcView um ein GIS-Produkt handelt, folgt zunächst eine generelle
Betrachtung. ARONOFF (1991) charakterisiert GIS als computergestütztes System, dessen
vier Potentiale die Eingabe, Verwaltung, Verarbeitung und Ausgabe geo-refenzierter Daten
sind. Der Begriff „geo-referenziert“ weist darauf hin, dass GIS-Daten Objekte reflektieren,
die mit einem erdbasierten Koordinatensystem verknüpft sind. Als mögliche Datenquellen
bieten sich Karten, Luftbilder oder Tabellen an. Die Eingabe der Informationen verläuft
durch Import beziehungsweise Anbindung digitaler Daten (z.B. Informationen aus
externen Datenbanken) und Digitalisierung analoger Daten (z.B. Informationen aus
analogen Karten). Dateisysteme und/oder Datenbanken kommen für die Verwaltung in
Frage. In der Regel findet eine Trennung von Geometrie- und Sachdaten statt [LIEBIG &
SCHALLER, 2000], wobei bei der Verarbeitung zwischen der Datenmanipulation und der
Datenanalyse zu differenzieren ist. Während die Manipulation lediglich einer Änderung
vorhandener
Daten
entspricht,
tragen
Analysen,
wie
beispielsweise
die
Objektverschneidung, zur Gewinnung neuer Informationen auf Basis des vorliegenden
Datenbestands bei. Ausgabemedien wie Karten, Tabellen und Diagramme repräsentieren
alle, sowie einzelne Informationen in digitaler oder analoger Form.
32
5.1.2 Struktureller Aufbau
Das ArcView GIS umschließt die Grundbestandteile Thema (Theme), Tabelle (Table),
Ansicht (View), Diagramm (Chart), Layout, Script und Projekt (Project).
•
Anhand der Geometrie (Punkt, Linie, Polygon) und der einzelnen
Objekteigenschaften separieren Themen die räumlichen Objekte. Dabei fasst ein
Thema zweckmäßig Daten eines bestimmten Typs zusammen (z.B. Straßen oder
Gewässer).
•
Tabellen listen Objekte und deren Attribute auf. Jede Zeile steht für ein Objekt und
jede Spalte für ein Attribut, das einen räumlichen oder sachlichen Bezug haben
kann.
•
Die Ansichten kontrollieren die Datenzusammenstellung und -darstellung. Darüber
hinaus sind sie mit diversen Werkzeugen zur Analyse und Bearbeitung von Daten
verbunden. ArcView ordnet Themen nach dem Layerprinzip. Demnach überlagern
sich einzelne, voneinander unabhängige Themen (Layer), wodurch ein Gesamtbild
entsteht.
•
Diagramme zeigen in graphischer Form die zahlenmäßige Abhängigkeit zwischen
zwei oder mehr Attributen einer Tabelle. Dabei werden Attribute innerhalb eines
Diagramms dynamisch aktualisiert, so dass sich Änderungen in der entsprechenden
Tabelle unmittelbar auf die Graphik auswirken.
•
Der Schwerpunkt von Layouts liegt in der Datenausgabe. Layouts definieren
Karten, die Ansichten, Diagramme, Tabellen und andere Elemente miteinander
kombinieren und wiedergeben. Modifikationen im Datenbestand wirken sich
unmittelbar auch auf Layouts aus.
•
Um den individuellen Nutzeransprüchen zu entsprechen, integriert ArcView eine
Script-Komponente. Scripte enthalten Quellcodes in Avenue, der systeminternen
Programmierumgebung [s. Kapitel 5.1.5]. Sie befähigen den Anwender Prozesse zu
automatisieren, neue Funktionen hinzuzufügen und spezifische Applikationen oder
Erweiterungen zu entwickeln [ESRI, 1998].
•
Das Projekt ist ein Verwaltungsinstrument in ArcView. Es verweist auf alle
Themen, Tabellen, Ansichten, Layouts, Scripte und andere Objekte, die einem
bestimmten Projekt angehören. Das gleichzeitige Öffnen mehrerer Projekte wird in
ArcView nicht unterstützt.
5.1.3 Bedienung
Die Benutzeroberfläche von ArcView ist menügesteuert und trotz einer Vielzahl an
Funktionalitäten relativ leicht zu bedienen. Überdies können Anwender individuelle
Anpassungen vornehmen. Die Komponenten gliedern sich originär in Projekt-Fenster,
33
Menüleiste, Buttonleiste, Toolleiste, Ansichten-, Tabellen-, Diagramm-, Layout- und
Script-Fenster.
Darstellung 5-1: ArcView 3.2 Projekt-Fenster.
Nach dem Start des Programms oder Laden eines vorhandenen Projekts erscheint das in
Darstellung 5-1 gezeigte Projekt-Fenster. Es listet alle Dokumente (Ansichten, Tabellen,
etc.), die dem Projekt zugeordnet sind, nach deren Art auf und dient primär der
Projektorganisation. Jedes Dokument wird beim Öffnen oder Erstellen in einem eigenen
Fenster angezeigt.
Inhaltsverzeichnis
Ansichten-Fenster
Menüleiste
Toolleiste
Darstellung 5-2: ArcView 3.2 Oberfläche.
Buttonleiste
34
Darstellung 5-2 illustriert die Kontrollleisten inklusive dem Ansichten-Fenster. Der Inhalt
der Kontrollleisten passt sich dem aktiven Fenster, also der Art des geöffneten Dokuments
an. Systematisierte Befehlslisten in der Menüleiste gewähren Zugriff auf fundamentale
Funktionen und Hilfsmittel (z.B. Speicheroptionen). Die Buttonleiste verfügt über
mannigfaltige Kontrollen für den schnellen und direkten Zugriff auf Prozesse (z.B.
Hinzufügen eines Themas). Werkzeuge aus der Toolleiste (z.B. Verschiebehand) sind
speziell auf die Arbeit mit dem Datenbestand abgestimmt, wobei ein markiertes Tool
solange aktiviert bleibt, bis ein anderes ausgewählt wird.
Das Ansichten-Fenster stellt eine Art interaktive Karte dar und erfüllt die Aufgabe der
Präsentation und Modifikation von Themen. Wichtigstes Detail ist das Inhaltsverzeichnis,
welches die Darstellung innerhalb der Ansicht steuert und alle Themen auflistet. Zur
Manipulation der Themenwiedergabe kann über das Verzeichnis ein Legendeneditor
aufgerufen werden.
Einen Eindruck über die Erscheinung weiterer Fenster vermittelt Darstellung 5-3.
Innerhalb des Tabellenfensters gibt es die Möglichkeit, einzelne oder mehrere Objekte zu
selektieren, zu bearbeiten und zu analysieren. Die zweckmäßige und formgerechte
Informationsausgabe koordinieren Diagramm- und Layoutfenster. Hinter dem ScriptFenster verbirgt sich ein einfacher Text-Editor für die Programmierung in Avenue.
Script-Fenster
Diagramm-Fenster
Tabellen-Fenster
Layout-Fenster
Darstellung 5-3: ArcView 3.2 Script-, Diagramm-, Tabellen- und Layoutfenster.
35
5.1.4 Avenue
Avenue ist eine speziell auf ArcView abgestimmte, objektorientierte Programmiersprache
und gestattet die Bearbeitung vorhandener sowie die Entwicklung neuer Funktionalitäten.
Der Vorteil einer objektorientierten Programmierung (OOP) liegt in der Syntax, die
konsequent aus Klassen, Objekten und Anfragen gebildet wird. Eine Klasse bestimmt die
konzeptuellen Eigenschaften der ihr zugeordneten Objekte. Diese sind Programmteile, die
Funktionen und Daten zu einer Einheit zusammenpacken. Dadurch lassen sich komplexe
Aufgaben durch einfache Anfragen an das jeweilige Objekt durchführen. In Avenue gibt es
vordefinierte Klassen für den Zugriff auf sämtliche Komponenten, Daten und Funktionen.
Der Benutzer kann dadurch ArcView nahezu beliebig anpassen und erweitern.
Leider beinhaltet das Programm lediglich einen sehr einfachen Quelltext-Editor, das
Script-Fenster. Besonders bei der Entwicklung vielschichtiger Scripte wirken die
integrierten Werkzeuge recht simpel, im Vergleich zu anderen Editoren. So wird weder der
Funktionsaufruf über die rechte Maustaste, noch die Scroll-Funktion der Maus unterstützt.
Im WWW sind kostenlose oder kommerzielle ArcView-Scripte und -Erweiterungen in
großer Anzahl verfügbar. Beispielsweise offeriert ESRI freie Anwendungen unter
http://arcscripts.esri.com.
5.2 EditPlus2
Mit EditPlus2 [ES-COMPUTING, 2003] bietet die Firma ES-Computing eine sehr
komfortable Software für die Erstellung textbasierter Dateien an. Es kann als einfacher
Text- und als Programmier-Editor verwendet werden. Das Programm unterstützt die
Formate HTML, CSS, XML, PHP, PERL, C/C++, Java, JavaScript und VBScript, wobei
auch die Möglichkeit besteht, eigene Syntaxen zu erstellen.
Die Benutzeroberfläche ist nach Darstellung 5-4 sehr übersichtlich angeordnet und enthält,
abgesehen von dem eigentlichen Text, diverse Werkzeuge und Funktionalitäten.
Innerhalb des Textes sind Syntaxelemente durch differenzierte Farbgebung hervorgehoben,
die optional eine individuelle Anpassung ermöglich. Für die Entwicklung und Bearbeitung
von Dokumenten stehen Hilfsmittel wie die automatische Vervollständigung, das Einfügen
spezifischer Textausschnitte oder die leistungsfähigen Suchoptionen zur Verfügung.
Darüber hinaus unterstützt EditPlus2 die Integration eigener Tools.
Entsprechend der hohen Flexibilität und Anwenderkontrolle wird das Programm auch
professionellen Ansprüchen gerecht und eignet sich sehr gut für den effizienten Aufbau
von Dokumenten.
Eine funktionsfähige Trial-Version von EditPlus2 ist unter ES-COMPUTING (2003)
abrufbar.
36
Darstellung 5-4: EditPlus2-Benutzeroberfläche.
5.3 eMbedded Visual Basic
Microsoft hat mit eMbedded Visual Basic9 (eVB) eine kostenlose Umgebung zur
Entwicklung von Programmen für mobile, auf Windows CE basierende Endgeräte
bereitgestellt. Die hier aufgeführten Erläuterungen und Aspekte beziehen sich auf die
aktuelle Version eVB 3.0 und sind, sofern nicht anders angegeben, MICROSOFT,
EMBEDDED VISUAL BASIC 3.0 (2000) entnommen.
5.3.1 Einführung
Wegen der weiten Verbreitung im stationären und mobilen Bereich sowie der einheitlichen
Darstellung und Bedienung, gelten Windows-Programme als sehr anwenderfreundlich.
eVB stattet Programmentwickler mit einem leistungsfähigen Instrument für die
Konstruktion mobiler Anwendungen aus. Das Entwicklungssystem besteht aus einem
Emulator, einem Quellcode-Editor, einem Form-Editor und diversen Werkzeugen. Der
Emulator simuliert ein mobiles Gerät und gestattet das Testen von Windows CE
Programmen auf stationären Plattformen. Um das Auftreten von Fehlern zu minimieren,
gibt es einen Debugger, der zur Entwurfszeit den Quelltext hinsichtlich Syntax und
Variablen überprüft. eVB erzeugt keine Stand-Alone-Anwendungen, so dass zur
9
Die Vollversion von eVB 3.0 ist im WWW unter http://msdn.microsoft.com erhältlich.
37
Programmausführung immer ein Interpreter10 benötigt wird. Dieser übersetzt das
Programm zur Laufzeit in Maschinensprache. Besondere Funktionalität bieten die RemoteTools. Sie ermöglichen die Kommunikation zwischen stationärem PC und mobilem Gerät.
Exemplarisch ist die Abbildung der mobilen Ansicht auf dem Desktop-Computer denkbar.
Generell setzt sich die eVB-Syntax aus Eigenschaften, Methoden, Objekten und
Anweisungen zusammen. Eigenschaften legen bestimmte Charakteristiken von Objekten
fest und können kreiert oder abgefragt werden. Methoden sind innerhalb eines Objekts
deklarierte Prozeduren und beschreiben die dynamische Reaktion von Objekten auf
Ereignisse. Schlussfolgernd erscheinen Objekte als Kombination von Eigenschaften und
Methoden. Der innere Programmablauf wird unter Verwendung von Anweisungen, wie
Kontroll- oder Schleifenstrukturen, organisiert.
Vertiefende Informationen über eVB stellt unter anderem Grattan (2002) dar.
5.3.2 Bedienung
Die originäre Entwicklungsoberfläche von eVB ist aus Darstellung 5-5 ersichtlich und
kann individuell angepasst und erweitert werden. Als Hauptkomponenten dienen
Menüleiste, Standard-Toolleiste, Projekt-Explorer, Toolbox, Form-Fenster, Code-Fenster
und Eigenschaften-Fenster.
In der Menüleiste befinden sich mehrere Befehlslisten, die generelle Funktionen zur
Steuerung und Erscheinung von eVB einschließen.
Um dem Anwender einen optimierten Zugriff auf häufig benutzte Befehle zu gewähren,
umfasst die Standard-Toolleiste Symbole, die bei Aktivierung den entsprechenden Prozess
starten, zum Beispiel das Öffnen oder Schließen eines Projekts. Neben der StandardSymbolleiste gibt es Toolleisten für die Fehlerbehandlung, der Quelltext- und der
Formbearbeitung.
Für die Gestaltung der Form stellt die Toolbox verfügbare Elemente (Controls) wie Linien,
Schaltflächen oder Textfelder bereit. Nach der Markierung des betreffenden Symbols kann
das Objekt im Form-Editor gezeichnet werden.
Der Projekt-Explorer verwaltet alle, einem Projekt zugeordneten Dateien und listet diese in
Form einer Baumstruktur auf. Er ermöglicht dem Entwickler einzelne Dateien
anzusprechen und zwischen Code- und Formansicht zu wechseln.
Das Layout des Form-Fensters entspricht der Benutzeroberfläche des eVB-Programms.
Danach kommt die Form einer visuellen Schnittstelle zwischen Anwender und Programm
gleich und beinhaltet sämtliche Dialog-, Eingabe- und Ausgabeelemente. Objekte, die
Prozesse im Hintergrund der Anwendung steuern (z.B. Timer Control oder File Control),
sind für den Anwender unsichtbar.
10
Dem eVB-Packet ist bereits ein Interpreter beigefügt.
38
Ein Quelltexteditor steht in Form des Code-Fensters bereit. Er dient explizit der Eingabe
und Bearbeitung von Ereignisprozeduren, die mit Objekten einer Form verknüpft sind. Zur
Erleichterung der Code-Eingabe sind zwei Listenfelder in das Fenster integriert. Im
Objekt-Listenfeld wird eine Übersicht der vorhandenen Objekte gegeben und das
Prozedur-Listenfeld reflektiert die möglichen Ereignisse eines bestimmten Objekts.
Standardmäßig ist die farbige Darstellung des Quelltextes unterschiedlich. Unter anderem
erhalten Schlüsselwörter das Farbattribut Blau, Anweisungen das Farbattribut Schwarz.
Jedes Objekt in eVB hat spezielle Charakteristiken wie Name, Farbe oder Position. Die
Merkmale eines im Form-Fenster markierten Elements registriert das EigenschaftenFenster. Innerhalb des Fensters können die den Eigenschaften zugewiesenen Werte
verändert werden.
Menüleiste
Toolbox
Standard-Toolleiste
Form-Fenster
Code-Fenster
Projekt-Explorer
Eigenschaften-Fenster
Darstellung 5-5: eVB 3.0-Entwicklungsoberfläche.
5.3.3 Erstellung von Programmen
eVB ist eine ereignisorientierte Programmiersprache und dementsprechend vor allem für
die Entwicklung interaktiver Anwendungen geeignet. Aufgrund der notwendigen relativ
zeitaufwendigen Interpretation des eVB-Codes wird bei rechenintensiven Programmen
39
eine Implementierung in C oder C++ favorisiert. Der Vorteil dieser Sprachen liegt in der
Integration eines Compilers, der die Programme optimiert und vollständig in
Maschinensprache übersetzt. Anwendungen können so direkt vom Prozessor gelesen und
ausgeführt werden.
Die Programmentwicklung in eVB erfolgt nach LEHMANN (1999) in sechs Arbeitsschritten:
Schritt 1: Analyse der Aufgabenstellung
Vor der eigentlichen Programmierung ist der graphische und funktionale Inhalt einer
Anwendung klar zu definieren. Dann empfiehlt sich die Zusammenstellung wichtiger
Objekte und die grobe Strukturierung des Programmablaufs.
Schritt 2: Gestaltung der Benutzeroberfläche
Im Form-Fenster entsteht das geometrische Programmlayout durch Positionierung aller
notwendigen Elemente.
Schritt 3: Festlegung der Eigenschaften
Für jedes Objekt sind, unter Verwendung des Eigenschaften-Fensters, die Attribute zu
fixieren.
Schritt 4: Programmierung der Ereignisprozeduren
Reaktionen einzelner Elemente auf bestimmte Ereignisse beschreiben Ereignisprozeduren.
Diese werden in Form von Anweisungen innerhalb des Code-Fensters entworfen.
Schritt 5: Prüfung der Anwendung
Umfangreiche Tests der Anwendung dienen der Kontrolle und dem Erkennen von Fehlern.
Zusätzlich decken sie konzeptionelle und programmiertechnische Schwachstellen auf, die
der Entwickler dann beseitigen kann.
Schritt 6: Erstellung einer ausführbaren Programmdatei
Zuletzt wird ein Programmordner mit Hilfe des Application Install Wizards, einem eVBTool, erstellt. Der Ordner enthält als Hauptbestandteil eine Setup-Datei, die automatisch
das Programm und alle zur Ausführung erforderlichen Dateien auf der Anwenderplattform
installiert.
5.4 JavaScript
In Anlehnung an Java11 haben die Kooperationspartner Sun und Netscape mit Javascript
eine neue, sehr einfache Programmiersprache entwickelt und 1995 veröffentlicht [ROTTER,
2002]. Motivation war es, dem Anwender neben den komplizierten Sprachen C, C++ und
Java eine leicht zu erlernende und für einfache Aufgaben ausreichende Version anzubieten.
Im Wesentlichen ergänzt JavaScript Auszeichnungssprachen wie HTML oder SVG um
11
Einzelheiten zu der Programmiersprache Java finden sich unter anderem in PEARSON (2004).
40
zusätzliche Funktionalität und Interaktion. Deshalb bildet die Sprache einen sehr wichtigen
Baustein bei der Erstellung anspruchsvoller Webseiten und anderen, dynamischen
Dokumenten.
Javascript ist eine Interpretationssprache und wird daher ausschließlich in reinem
Textformat deklariert. Ein Browser (Viewer) übernimmt dann die Interpretation des
Dokuments zur Laufzeit der Anwendung. Da nicht alle Browser den gesamten JavaScriptUmfang unterstützen, empfiehlt es sich, die Anwendungen in mehreren bekannten Viewern
zu testen.
2001 gab Sun mit Javascript 1.3 die letzte aktualisierte Version heraus. Daneben
veröffentlicht das Gremium ECMA 12 kontinuierlich allgemeingültige Standards für
Internet-Scriptsprachen. Der ECMA-Standard für Javascript heißt ECMAScript und gilt als
Muster für Hersteller von Sprachinterpretern.
Die Integration einer Javascript-Anwendung in ein SVG-Dokument soll nachstehend
dargelegt werden.
Eine SVG-Datei kann beliebig viele interne und externe Scripte aufweisen. Diese sind
unter Verwendung des Container-Elements <script> an beliebiger Stelle innerhalb des
Root-Elemets <svg> deklariert. Der Ausdruck für interne Scripte lautet:
<script type=“text/javascript“>
<!CDATA[ script-anweisungen ]]>
</script>
ist ein Pflichtattribut von <script> und informiert den Parser über den Scripttyp. Durch
die Einbettung in CDATA (Character Data) erkennt der Interpreter, dass es sich nicht um
SVG-Daten handelt. Auf externe Scripte wird mit Hilfe des Attributs xlink:href verwiesen:
type
<script type=“text/javascript“ xlink:href=“dateiname.js”/>
Ein Javascript-Code besteht grundsätzlich aus Variablen, Operatoren, Anweisungen
(Statements), Funktionen und Objekten.
Variablen entsprechen einem reservierten Speicherplatz, der anhand des Namens
kontrolliert wird. Beispielsweise kann die Variable zahl den Wert 10 zugewiesen
bekommen:
var zahl=10;
12
ECMA gehören mehrere Softwarehersteller, wie Microsoft oder Netscape, an.
41
leitet die Deklaration der Variablen ein. Als Datentypen kommen Zahlen, Strings,
boolesche Werte und Objekte in Betracht. Ein Semikolon schließt die Anweisung ab.
var
Die Operatoren stellen Verknüpfungen und Vergleiche zwischen Variablen her. Es gibt
unter anderem Vergleichsoperatoren (z.B. <, >, ==), Berechnungsoperatoren (z.B. +, -, *, /)
und logische Operatoren (z.B. &&, ||).
Die Anweisungen entsprechen der Kombination von Variablen und Operatoren. Sie
steuern den Programmablauf und können mit Bedingungen oder Schleifen verknüpft sein.
Anweisungsblöcke in geschweiften Klammern fassen einzelne Statements zu einer Einheit
zusammen.
Funktionen umfassen eine unbegrenzte Anzahl an Anweisungen, die eine gewisse
Dynamik bewirken. Optional können sie eingehende Parameter und einen Rückgabewert
einschließen:
function name (parameter) {
anweisung;
...
return variable;
}
identifiziert das Element name als Funktion. Soll ein Wert erzeugt werden, ist
dieser mit der return-Anweisung zu deklarieren.
function
Objekte setzen sich aus Attributen und Methoden zusammen. Attribute beschreiben das
Objekt und Methoden sind spezielle, dem Objekt zugeordnete Funktionen. Exemplarisch
legt das Schlüsselwort this die Attribute Einwohner und Flaeche für die Objektdefinition
Land fest:
function Land(EW, FL) {
this.Einwohner=EW;
this.Flaeche=FL;
}
Objekte werden dann per new-Anweisung instantiiert:
var Deutschland=new Land(79000000, 357000);
Die neue Variable Deutschland bezieht als Datentyp ein Objekt der Objektdefinition Land
mit den Attributen Einwohner=79000000 und Flaeche=357000.
Javascript verfügt über eigene, vordefinierte Objekte, die dem Entwickler einfachen
Zugriff auf sonst komplexe Variablen und Methoden verschaffen. Math-, Date-, und
Window-Objekt sind hier nur einige Beispiele. Besondere Bedeutung kommt den EventObjekten zu, die die wichtigste Schnittstelle für Interaktionen bilden. SVG unterstützt
42
sowohl Maus-, Tastatur- als auch Dokument-Events. Sogenannte Event-Handler, welche
prinzipiell mit anwenderspezifischen Funktionen verknüpft sind, werden beim Eintreten
des Ereignisses vom Browser aufgerufen. Der Ausdruck
<circle … onclick=“name()”/>
entspricht zum Beispiel dem Auslösen einer Funktion name nach dem Klicken mit der
Maus (Event: click; Event-Handler: onclick) auf das Element circle.
Javascript kann einzelne SVG-Elemente über das Document Object Model13 (DOM),
einem API (Application Programming Interface), ansprechen und manipulieren, was in der
hierarchischen Baumstruktur von XML begründet ist [vgl. Kapitel 3.2]. Das DOM ist ein
neutrales Modell zur Repräsentation der Objektzusammenhänge in Form einer
Baumstruktur [FIBINGER, 2002]. Es legt weiterhin die Art und Weise der dynamischen
Veränderung des Baums fest [SALATHE, 2002].
Die in diesem Abschnitt beschriebenen Charakteristiken sollen einen kleinen Eindruck
über die Funktionsweise und Leistungsfähigkeit der Programmiersprache JavaScript
vermitteln. Detailliertere Informationen sind in FLANAGAN (2003) oder alternativer
Literatur nachzulesen.
13
DOM-Spezifikationen werden vom W3C herausgegeben.
6 Konzeption
43
6 Konzeption des Fahrradtouren-Navigationssystems
In Kapitel 2 wurde eine Einführung in die Thematik der Fahrradtouren-Navigation
gegeben und die Funktionalitäten sowie Anforderungen eines entsprechenden mobilen
Systems spezifiziert. Darauf aufbauend beschreibt dieses Kapitel das Konzept für ein
solches Fahrradtouren-Navigationssystem und geht dabei detailliert auf einzelne
Komponenten ein.
6.1 Allgemeine Konzeption
Die Systemarchitektur kann, basierend auf den unterschiedlichen Funktionalitäten, in
mehrere Komponenten gruppiert werden. Eine Komponente, auch als Modul bezeichnet,
ist ein Software-Teil, der eine sinnvoll einsetzbare Funktionalität kapselt und über eine
Schnittstelle mit anderen Komponenten kommunizieren kann [BÄR, 2002].
Daten-Komponente
Visualisierungs-Komponente
Positions-Komponente
Querverbindung
User-Interface-Komponente
Routing-Komponente
Darstellung 6-1: Aufbau des Fahrradtouren-Navigationssystems.
Mit Bezug auf das mobile Fahrradtouren-Navigationssystem kann, wie aus Darstellung 6-1
ersichtlich ist, eine Aufteilung der Systemarchitektur in 5 Komponenten erfolgen:
1. Daten-Komponente,
2. User-Interface-Komponente,
3. Visualisierungs-Komponente,
4. Positions-Komponente,
5. Routing-Komponente.
6 Konzeption
44
Die Funktion der Daten-Komponente ist die effiziente Speicherung, Verwaltung und
Anfragebearbeitung raumbezogener Informationen. Hierzu gehören unter anderem die
Organisation und Modifikation von Geo-Objekten sowie die Integration der
Standortinformationen. Nach dem Drei-Komponentenmodell für Objektarten, in
Darstellung 6-2 verdeutlicht, besteht ein räumliches Objekt aus Geometrie-, Sach- und
Graphikdaten [BILL, 1999A ]. Geometriedaten definieren die Form und Lage des Objekts.
Um die in Kapitel 2.1 aufgestellten Funktionalitäten zu erfüllen, wird für die Geometrie ein
vektorbasiertes
Datenmodell
angelegt.
Sachdaten
beschreiben
nichtgeometrische
Charakteristiken (Eigenschaften, Bezeichnungen, Zahlenwerte, etc.) des Objekts und
besitzen Verknüpfungen zu den entsprechenden Objekt-Geometrien. Graphikdaten treffen
Aussagen über die Objekt-Darstellung und müssen demnach für Geometriedaten
zugänglich sein. Das Speichern und Organisieren der unterschiedlichen Daten geschieht in
separaten, miteinander verlinkten Dateien.
Räumliche Objekte
Geometriedaten
Sachdaten
Graphikdaten
Darstellung 6-2: Drei-Komponentenmodell für Objektarten [BILL, 1999A].
Zur Realisierung von Anwender-Interaktionen liefert die User-Interface-Komponente
umfassende Möglichkeiten. Das Hauptaugenmerk liegt auf dem Zugriff und der Steuerung
aller Systemkomponenten. Neben den herkömmlichen Zoom- und Pan-Funktionen besitzt
die Komponente beispielsweise Positionierungs- und Datenabfrage-Funktionalitäten.
Wichtiger Bestandteil ist die Benutzeroberfläche, die unter Verwendung eines
vektorbasierten Graphikformats entwickelt wird. Als visuelle Schnittstelle zwischen
Anwender und Navigationssystem dient sie dem Starten und Beenden von Prozessen. Zu
diesem Zweck werden einzelne Graphikobjekte mit geeigneten Eventhandlern ausgestattet.
Bei der Visualisierungs-Komponente handelt es sich um ein Programmpaket, das die
diversen Systeminformationen, welche in den verschiedensten Datenformaten vorliegen,
graphisch verarbeiten und repräsentieren kann. Zusätzlich erfordert die dynamische
Datenwiedergabe innerhalb des Navigationssystems eine Unterstützung von Interaktionen.
Angaben über den Standort liefert die Positions-Komponente. Sie analysiert die vom GPSReceiver ausgegebenen Informationen und identifiziert die obligatorischen Daten. Damit
andere Komponenten auf die Standortangaben zugreifen können, müssen die
Informationen in einem leicht zugänglichen, standardisierten Format abgespeichert
werden. Eine Echtzeit-Navigation setzt die Datenaktualisierung in konstanten
Zeitintervallen von wenigen Sekunden voraus.
6 Konzeption
45
Routengenerierungsund
Routenverfolgungs-Funktionalitäten
bietet
die
RoutingKomponente unter Auswertung der Geo-Daten sowie der Standortangaben an. Um den
Rechenprozess zu minimieren, muss die Komponente über einen schnellen
Generierungsalgorithmus verfügen. In Hinsicht auf die Routenverfolgung ist eine
Wegbeschreibung in Form von reinen Strecken- und Richtungsangaben nur mit Vorbehalt
zufrieden stellend. Fahrradfahrer favorisieren die Einbeziehung von Orientierungspunkten
(z.B. Kirche, Hochhaus, Tankstelle), sogenannten Landmarken, die eine wichtige Hilfe bei
der menschlichen Navigation darstellen [ELIAS & HAMPE, 2003]. Angesichts der
komplexen und umfangreichen Problematik der Wegführung wird auf die Konzeption
einer Routing-Komponente im Rahmen dieser Arbeit verzichtet.
6.2 Konzeption der Daten-Komponente
In diesem Abschnitt wird zunächst ein Überblick über die grundlegenden Konzepte
einzelner Datentypen der Daten-Komponente gegeben. Anschließend erfolgt die
konzeptuelle Anpassung der Systemkomponente an die Charakteristiken des mobilen
Endgeräts.
Abschließend
beschreibt
der
Abschnitt
die
Integration
von
Standortinformationen sowie den Generierungsprozess der Komponente.
6.2.1 Geometriedaten
Der Forderung nach einem vektororientierten Graphenmodell zur Speicherung und
Wiedergabe von Geo-Objekten wird mit einem Spaghetti-Datenmodell (Darstellung 6-3)
entsprochen. Nach diesem Modell lassen sich Form und Position der Objekte mit Hilfe der
durch Koordinaten beschriebenen Grundelemente Punkt, Linie und Polygon definieren.
Datenmodell
Datenstruktur
Objekt
1
3
2
ID
Geometrie
Punkt
1
x,y-Koordinaten
Linie
2
x1 ,y1 ... xn ,yn
Polygon
3
x1 ,y1 ... xn ,yn
ID – Objekt-Identifikator
Darstellung 6-3: Spaghetti-Datenmodell [HAKE ET AL., 2002].
Das
Spaghetti-Datenmodell
ermöglicht
eine
einfache
Datenstrukturierung
und
Datenerfassung. Typisches Generierungsbeispiel ist die linienweise Digitalisierung einer
analogen Karte. Innerhalb der Datenstruktur können Objekte mühelos hinzugefügt oder
entfernt werden. Nachteil des Konzepts ist die Datenredundanz sowie die fehlende
explizite Topologie. Datenredundanz ergibt sich aus der notwendigen, wiederholten
Abspeicherung von Punkten, die mehreren Objekten angehören. Topologie zeigt
6 Konzeption
46
Nachbarschaftsbeziehungen zwischen den Geo-Objekten auf und ist damit ein wichtiges
Kriterium für raumbezogene Analysen. Topologische Beziehungen leiten sich im
Spaghetti-Datenmodell lediglich aus den redundanten Geometriedaten ab. Demzufolge
genügt das Modell nur bedingt den Anforderungen analytischer Funktionalitäten, wie zum
Beispiel der Routensuche. Es eignet sich aber sehr gut zur effizienten Entwicklung
digitaler Kartengraphiken.
Die Spaghetti-Datenstruktur der Geometriedaten wird unter Verwendung des
Standardformats SVG umgesetzt. SVG ist als eine XML-Applikation auf die Speicherung
und Präsentation von Vektorgraphiken explizit ausgerichtet. Als weiterer Vorteil erweist
sich die Unterstützung dynamischer Zugriffe auf einzelne Elemente und die einfache
Möglichkeit der Datenmodifikation [vgl. Kapitel 3.2].
Einen Bezug zu den Graphik- und Sachdaten bilden die im geometrischen Datenmodell
erstellten Elemente über speziell definierte Verweise (Darstellung 6-4).
Individuelle
Sachdaten
Attribute 2
Attribute 3
Geometriedaten Geometrie 1 Geometrie 2
Geometrie
Graphikdaten
Attribute 1
Gestaltung 1
Gestaltung 2
Darstellung 6-4: Verbindungen zwischen Geometrie -, Graphik- und Sachdaten.
Da die Darstellungsart für Objekte einer Objektart gleich ist und redundante Daten
möglichst vermieden werden sollen, sind Objekt-Geometrien nach dem Layerkonzept
zusammengefasst. Das Layerkonzept ordnet die Geometriedaten anhand ihrer
unterschiedlichen Thematik in verschiedene Ebenen (Layer) ein [BARTELME, 2000]. Jede
Ebene besitzt so nur eine Verknüpfung zu den entsprechenden Graphikdaten. Durch
Übereinanderlegen einzelner Layer ergibt sich eine Gesamtdarstellung der Situation. SVG
simuliert das Ebenenprinzip durch thematische Einteilung der Objekte in Gruppen.
Während der graphischen Datenpräsentation überlagern Gruppen, die in der SVG-Datei am
Ende positioniert sind, alle zuvor definierten Datensätze (Darstellung 6-5). Im Gegensatz
zu den graphischen Beschreibungen gibt es unter den Sachinformationen auch Attribute,
die sich auf individuelle Objekte beziehen. Dadurch müssen betroffene Objekt-Geometrien
direkt auf diese spezifischen Sachinformationen verweisen.
6 Konzeption
47
Datenstruktur in SVG
Datenpräsentation
...
Gruppe 3
Gruppe 1
Gruppe 2
Gruppe 2
Gruppe 1
Gruppe 3
...
Darstellung 6-5: Layerkonzept in SVG.
6.2.2 Sachdaten
Sachdaten beschreiben semantische Kennzeichen raumbezogener Objekte. Mit Semantik
werden die inhaltlichen Objektinformationen bezeichnet. Demnach erfordert die sinnvolle
Abstraktion realer Objekte, neben einer Festlegung der Geometriedaten, auch die
Definition signifikanter Sachdaten. Einfaches Beispiel ist die Modellierung einer Straße.
Deren Objekt-Geometrie, prinzipiell eine Linie, gibt nicht eindeutig zu erkennen, ob es
sich um eine Straße, eine Bahnlinie oder einen Fluss handelt. Erst durch die Zuweisung des
semantischen Kennzeichens STRASSE wird eine Abgrenzung der Straße zu anderen
Objekten erreicht. Als Sachdaten kommen exemplarisch Namen, Texte und Zahlen in
Betracht.
Das semantische Datenmodell des Fahrradtouren-Navigationssystems abstrahiert, nach
Methode der Klassifikation, Objekte mit gemeinsamen Attributen durch eine Gruppe.
Dadurch entstehen Objektklassen, deren Strukturierung dem im vorherigen Abschnitt
geschilderten Layerprinzip entspricht. In Abhängigkeit von der Priorität einer Klasse wird
diese in das Layermodell eingeordnet. Wichtige Klassen sind weiter oben, unwichtige
weiter unten situiert. Grundlage der Entwicklung des semantischen Modells bildet der
ATKIS-Objektartenkatalog [s. Kapitel 6.2.6], da die verwendeten Geo-Daten den ATKISDatenbeständen entstammen. Begründet in der umfangreichen Themenaufschlüsselung und
dem objektklassenbasierten hierarchischen Aufbau des Objektartenkataloges müssen die
vorgegebenen Objektklassen für die Verwendung im Fahrradtouren-Navigationssystem
selektiert, generalisiert, aggregiert und komplettiert werden [s. Kapitel 6.2.6]. Darstellung
6-6 führt das semantische Modell des Fahrradtouren-Navigationssystems vor. Demnach
abstrahieren 24 in unterschiedlichen Layern abgelegte Objektbereiche die reale Welt.
Dieses ausführliche Datenmodell kommt der auf dem Gebiet der Fahrradnavigation
geforderten detaillierten Situationsbeschreibung nach.
Eine weitere geforderte Funktionalität des Systems ist die Bereitstellung von
Zusatzinformationen
über
bestimmte
POIs.
Infolge
der
begrenzten
Darstellungsmöglichkeiten auf dem PDA-Displays erweist sich eine Integration der Daten
in die Kartengraphik als wenig sinnvoll. Darum wird für jedes POI-Objekt eine HTMLDatei angelegt, die alle benötigten Informationen enthält [vgl. Kapitel 3.1]. Die HTML-
6 Konzeption
48
Datei ist mit der Objekt-Geometrie verknüpft und lässt sich über diese optional aufrufen.
Im Rahmen des konzipierten Navigationssystems sind Objekte der Layer Rastinfo und
Kulturinfo mit zusätzlichen Sachdaten, wie zum Beispiel einer eingehenden
Objektbeschreibung ausgestattet.
Rastinfo
Kulturinfo
Stadion
Schwimmbad
Zoo
Camping
Bahn
Autobahn
Bundesstraße
Straße
Weg
Abstrahierte,
reale Welt
Fließgewässer
Wasserfläche
Moor, Heide
Parkplatz
Sportanlage
Grünanlage
Wald
Grünland
Bahnhof
Friedhof
Punkt-Geometrie
Wohngebiet
Linien-Geometrie
Industriegebiet
Flächen-Geometrie
Acker
Darstellung 6-6: Semantisches Modell.
6 Konzeption
49
6.2.3 Graphikdaten
Aufgabe der graphikbeschreibenden Daten ist die Festlegung, wie raumbezogene Objekte
(Geometrie- und Sachdaten) graphisch repräsentiert werden sollen. Darstellung 6-7 zeigt,
dass die Kombination von Geometriedaten mit Daten der graphischen Ausgestaltung zur
Präsentationsgraphik führt [BILL, 1999A ]. Als kartographische Gestaltungsmittel kommen
exemplarisch Farbe, Füllung, Strichstärke oder Text in Betracht. Die Auswahl
objektspezifischer Graphikdaten geschieht unter Beachtung des Prägnanzprinzips (Prinzip
der guten Gestalt). Demzufolge setzen sich Objekte bevorzugt aus graphischen Elementen
zusammen, die eine möglichst geschlossene, stabile, in sich folgerichtige und einfache
Gestalt ergeben [HAKE ET AL., 2002]. Gewöhnlich stellt eine Einhaltung dieses
Grundsatzes die eindeutige Identifizierung von Objekten sicher, auch unter variierenden
Gegebenheiten, wie beispielsweise Maßstabs-, Kontrast- oder Farbänderung.
Geometriedaten
1
1
3
+
2
Graphik
Graphikdaten
Objektart 1
Objektart 2
Objektart 3
3
=
2
Darstellung 6-7: Graphische Gestaltung von Geometrie -Daten.
Da die Geo-Daten im Fahrradtouren-Navigationssystem, wie bereits erwähnt, aus ATKISDatenbeständen abgeleitet sind und im Bereich der Fahrradnavigation ein maximaler
Kartenmaßstab von 1:10000 ausreicht, liegt dem graphischen Modell der ATKISSignaturenkatalog 1:10000 (ATKIS-SK10) zugrunde [s. Kapitel 6.2.6]. Die Vorgaben des
Kataloges wurden, sofern erforderlich, an die Eigenarten des mobilen Systems angepasst.
Unter anderem bedingen die begrenzten Rechen- und Speicherkapazitäten die
Vereinfachung komplexer Objektsignaturen.
Innerhalb der Kartengraphik entfällt die Darstellung der Kartenrandangaben, des
Kartenrandes und anderen traditionellen Kartenbestandteilen. Dies begründet sich durch
das begrenzte Platzangebot auf dem PDA-Display. Um dennoch eine korrekte
Interpretation von einzelnen Kartenobjekten zu gewährleisten, wird eine externe
Zeichenerklärung (Legende) unter Nutzung von SVG erstellt und in einer HTML-Datei
eingebettet. Somit kann der Anwender bei Bedarf auf erläuternde Informationen durch
Aufruf der Legende zurückgreifen.
Generell befinden sich sämtliche Graphikdaten der Datenkomponente in einer CSS-Datei.
CSS ist ein Standardformat für die Präsentation strukturierter Informationen und verfügt
über umfangreiche graphische Elemente [vgl. Kapitel 3.3]. Durch die Kompatibilität zu
6 Konzeption
50
SVG und den unkomplizierten Zugriffs- und Modifikationsfunktionalitäten stellt CSS die
ideale Lösung für die Speicherung graphischer Beschreibungen dar. Graphikdaten einer
Thematik werden gemeinsam unter einem Identifikator abgelegt und lassen sich über
diesen abfragen und bearbeiten.
6.2.4 Integration der Tour- und der Standort-Daten
Die fundamentale Aufgabe des Fahrradtouren-Navigationssystems besteht in der
Navigation des Anwenders. Darum muss die Daten-Komponente neben den modellierten
Objekten der realen Welt auch die eigentlichen Tourdaten sowie die Standortangabe mit
einbeziehen (Darstellung 6-8). Es ist wichtig, dass die entsprechenden Informationen nicht
nur gespeichert und präsentiert, sondern auch mit den räumlichen Objekten eindeutig in
Beziehung gesetzt werden. Erst dann kann sich der Bediener in seiner aktuellen Umgebung
orientieren. Eine einfache Möglichkeit der Visualisierung bietet die Datenintegration in die
Kartengraphik. Topologische Eigenschaften lassen sich so direkt ableiten.
Kartengraphik
Layer der Tour
Layer der Position
Andere Layer
Transformation
Positionskoordinaten
in XML-Datei
Darstellung 6-8: Integration von Tour und Position in die Daten-Komponente.
Routeninformationen beschreiben den nach bestimmten Aspekten festgelegten Weg von
einem Start- zu einem Zielpunkt. Sie entstehen demzufolge durch die Kombination linearer
Geo-Objekte (Straßen, Wege, etc.) unterschiedlicher Objektklassen (Ebenen). Da das
Layerkonzept keine individuelle graphische Gestaltung von Objekten innerhalb einer
Ebene zulässt [vgl. Kapitel 6.2.3], wird für die Tourdaten ein zusätzlicher Layer angelegt,
der die anderen Graphikebenen, mit Ausnahme des Positions-Layers, überdeckt. Diese
Abgrenzung der routenbasierten Informationen von anderen Geo-Objekten gestattet die
unabhängige Erstellung, Gestaltung und Bearbeitung der Tourdaten. Konzepte für die
Generierung und Modifikation der Tourdaten sind nicht Inhalt dieser Arbeit.
Informationen über die Standortposition werden ebenfalls durch Darstellung in einem
übergeordneten unabhängigen Layer in die Kartengraphik mit eingebunden. Geometrisch
präsentiert sich der Standort als Punkt, dessen Kartenposition durch ein Koordinatenpaar
bestimmt ist. Eine separate XML-Datei enthält die von der Positions-Komponente
ausgegebenen Standortkoordinaten Breite und Länge [vgl. Kapitel 4.2.1]. Vorteil des
XML-Formats ist das strukturierte Ablegen von Daten und die Unterstützung des direkten
Zugriffs auf bestimmte Elemente [vgl. Kapitel 3.2]. Somit kann die Kartengraphik
geometrische Standortinformationen explizit abfragen. Die graphische Wiedergabe der
6 Konzeption
51
Position setzt eine Transformation der abgespeicherten geographischen Koordinaten, die
sich auf das räumliche WGS-84 Bezugssystem beziehen, in das zweidimensionale
Graphikkoordinatensystem voraus. Gelingt die ausreichend genaue Transformation bei
kleineren Gebieten noch mit einem affinen Ansatz über in beiden Systemen bekannte
Punkte, bedarf es bei weitläufigen Gebieten einer vollständigen komplexen
Koordinatenumwandlung. Letztere beansprucht eine hohe Rechenkapazität, so dass,
insofern möglich, eine Affintransformation vorzuziehen ist. Für eine Übertragung der
Standortinformation an den Systembediener in Echtzeit muss die Daten-Komponente über
Funktionen verfügen, welche in bestimmten Zeitintervallen alle notwendigen
Informationen abfragen und die Kartengraphik dementsprechend aktualisieren.
6.2.5 Optimierung
Das Konzept der Daten-Komponente des Fahrradtouren-Navigationssystems geht
grundsätzlich von der Datenpräsentation in Form einer Vektorgraphik aus. Wie in Kapitel
2.1 gefordert, muss die Kartengraphik detaillierte Geo-Informationen im Maßstab 1:10000
darstellen. Aufgrund des umfassenden Informationsgehaltes und der begrenzten Rechenund Speicherkapazitäten auf mobilen Endgeräten kann es während der dynamischen
Graphikanzeige auf dem PDA zu extremen Laufzeitverzögerungen oder sogar zu
Systemüberlastungen kommen. Demzufolge werden Lösungen gesucht, die ohne
graphische Qualitäts- und Quantitätsänderung das Auftreten solcher nachteiligen
Systemerscheinungen verhindern.
Durch die Präsentation der Situation im Maßstab 1:10000 wird auf dem 3,8 Zoll
Kleindisplay des PDAs nur ein geringer Teil der Kartengraphik wiedergegeben.
Exemplarisch abstrahiert die Displaybreite von 5,8 Zentimetern eine reale Entfernung von
580 Metern. Unter der Annahme einer Ost-West-Ausdehnung der Gesamtsituation von 10
Kilometern sind auf der Geräteanzeige weniger als 20 Prozent der Kartengraphik sichtbar.
Trotzdem bedingt die vektorbasierte Daten-Komponente eine vollständige, rechenintensive
Generierung der Kartengraphik. Abhilfe schafft die Umwandlung der einfachen
Vektorgraphik in eine hybride Graphik, welche Raster- und Vektortechniken miteinander
kombiniert. Die vektororientierte Kartengraphik wird in separate Grids (Rechtecke)
unterteilt, die in einer übergeordneten Rasterstruktur positioniert sind. Jedes Grid enthält
eine eigenständige Vektorgraphik, deren Größe mindestens dem Ausmaß des sichtbaren
Ausschnitts entspricht. Während der Kartenpräsentation erstellt das Navigationssystem
allein die auf dem Display sichtbaren Elemente und minimiert damit die Systemauslastung.
Prinzipiell gibt es zwei Möglichkeiten die Hybridgraphik aufzubauen:
Methode 1: Unterteilung der Kartengraphik in sich überlagernde Grids,
Methode 2: Unterteilung der Kartengraphik in benachbarte Grids.
Nach Methode 1, illustriert in Darstellung 6-9, zeigt das System ausschließlich ein
Kartensegment an. Gelangt der sichtbare Ausschnitt an die Grenze des geladenen Grids,
wird dieses aus der Kartengraphik entfernt und das nächstliegende Segment geladen.
Entscheidender Faktor für das Auswählen und Wechseln des aktiven Grids ist die Position
6 Konzeption
52
des Displaymittelpunktes innerhalb der Rasterstruktur. Das Datensystem bildet immer das
Grid ab, dessen Zentrum den kleinsten Abstand zum Displaymittelpunkt besitzt. Um eine
lückenlose Situationswiedergabe zu gewährleisten, müssen sich die einzelnen
Kartensegmente überdecken. Dies führt zu einer Redundanz der Daten und einer großen
Anzahl an Teilgraphiken. Zum Beispiel werden für die Unterteilung einer Kartengraphik in
Segmente mit einem Überdeckungsgrad von 50 Prozent und einem Viertel des
ursprünglichen Kartenausmaßes 9 Teilgraphiken benötigt (Darstellung 6-9). Ein erhöhter
Speicherbedarf der Daten-Komponente ist die Folge.
Hybride Kartengraphik
mit sich überlagernde
Teilgraphiken
Anzahl n der Teilgraphiken
(Überdeckung: 50%)
n = (2x1 -1) (2x2 -1)
mit x1 , x2 ∈ N
x1 =
Breite der Kartengraphik
Breite der Teilgraphik
x2 =
Höhe der Kartengraphik
Höhe der Teilgraphik
Kartengraphik
Teilgraphik
Darstellung 6-9: Hybride Kartengraphik mit sich überlagernde Teilgraphiken.
Methode 2 geht von einer Unterteilung der Kartengraphik in benachbarte Elemente aus
(Darstellung 6-10). Da sich die einzelnen Teilgraphiken nicht überdecken, bleibt die
Segmentanzahl relativ klein und der Umfang der Daten-Komponente nahezu gleich.
Exemplarisch besteht die Kartengraphik in Darstellung 6-10 aus 9 Teilgraphen mit einer
jeweiligen Größe von 1 /9 der Gesamtgraphik. Allerdings müssen im ungünstigsten Fall vier
Segmente gleichzeitig geladen und dargestellt werden. Darum ist eine Nutzung des
Konzeptes erst sinnvoll, wenn die hybride Kartengraphik aus mehr als vier Grids besteht.
Ähnlich der ersten Methode bestimmt das Datensystem über den Abstand des
Gridzentrums vom Displaymittelpunkt die zu aktivierenden Teilgraphiken. Als Nachteil
der Segmentierung in benachbarte Grids erweist sich die Behandlung von
Objektbeschriftungen, wie Bezeichnungen von Straßen, Stadtteilen oder Gebäuden. Eine
vollständige Wiedergabe von Textelementen ist nur dann möglich, wenn diese nicht die
Grenzen einer Teilgraphik schneiden. Infolgedessen können Informationsverluste
auftreten.
Die Beschreibung der beiden Methoden macht deutlich, dass in Abhängigkeit von den
individuellen Charakteristiken einer Anwendung das eine oder das andere Konzept zu
favorisieren ist. Im Rahmen der Entwicklung des anwendungsspezifischen FahrradtourenNavigationssystems findet wegen des geringeren Speicherbedarfs der zweiten Methode ein
Aufbau der hybriden Kartengraphik unter Nutzung benachbarter Teilgraphiken statt. Zu
diesem Zweck werden die geometrischen Informationen der Daten-Komponente in
6 Konzeption
53
regelmäßige Teilgraphiken eingeordnet. In der für Geometrie-Daten zuständigen SVGDatei wird ein Graphiksegment durch die Einteilung der entsprechenden Informationen in
eine übergeordnete Gruppe gebildet. Den eindeutigen Aufruf eines Grids ermöglicht ein
dem Grid zugeteilter Identifikator.
Hybride Kartengraphik
mit benachbarten
Teilgraphiken
Anzahl n der Teilgraphiken
n = x1 x2
mit x1 , x2 ∈ N
x1 =
Breite der Kartengraphik
Breite der Teilgraphik
x2 =
Höhe der Kartengraphik
Höhe der Teilgraphik
Kartengraphik
Teilgraphik
Darstellung 6-10: Hybride Kartengraphik mit benachbarten Teilgraphiken.
Das Konzept der Hybridgraphik nutzt den Umstand, dass auf einem Kleindisplay nur ein
geringer Teil der Kartengraphik sichtbar ist. Bei der Anzeige größerer Kartenausschnitte
gehen die Vorteile des Modells durch die hohe Anzahl darzustellender Grids verloren.
Folglich eignet sich das hybride Datenmodell, mit Hinblick auf das Navigationssystem,
lediglich für großmaßstäbige Darstellungen. Weil aber die Erfassung der
Orientierungszusammenhänge und der räumlichen Übersicht innerhalb der Kartengraphik
eine
dynamische
Kartenskalierung
erfordert,
die
neben
der
detaillierten
Informationswiedergabe auch eine überblickende Situationsbeschreibung unterstützt [vgl.
Kapitel 2.1], muss ein komplettierendes Graphikformat gefunden werden. Eine einfache
Möglichkeit bietet die Überlagerung der Hybrid-Graphik mit einer Rastergraphik. Diese
hat exakt die Ausmaße der hybriden Graphik und ist, im Bezug auf die Auflösung, den
Informationsgehalt sowie der Informationsdichte, an die kleinmaßstäbige Wiedergabe der
Situation angepasst. Gegenüber einer Vektorgraphik hat die Rastergraphik den Vorteil,
jedem Bildpunkt direkt einen Wert zuzuweisen, wodurch ein schneller Kartenaufbau
erreicht wird. Die Speicherung der Rastergraphik sollte vorzugsweise im Format JPG oder
PNG erfolgen. Im Gegensatz zum herkömmlichen BMP-Format, welches jeden Bildpunkt
einzeln abspeichert, nutzen diese Formate spezielle Bildkomprimierungstechniken und
verringern somit den Datenumfang der Bilddatei. In Abhängigkeit vom aktuellen Maßstab
bildet das Fahrradtouren-Navigationssystem entweder die detaillierte hybride Graphik oder
die schematisierte Rastergraphik ab (Darstellung 6-11).
Zusammenfassend reduzieren die in der Daten-Komponente enthaltenen komplexen
Graphikmodelle die Systemauslastung und fördern damit den störungsfreien Ablauf des
Fahrradtouren-Navigationssystems. Zusätzlich erfüllen sie die Forderung nach einer
adaptiven Skalierung der Kartengraphik [vgl. Kapitel 2.1].
6 Konzeption
54
Hybride Graphik
Rastergraphik
mit detaillierten
räumlichen
Informationen
mit schematisierten
räumlichen
Informationen
Maßstab
Detailansicht
Maßstab 1:10000
Übersicht
Maßstab <1:100000
Darstellung 6-11: Graphiken im Fahrradtouren-Navigationssystem.
6.2.6 Entwicklung
Nachdem in den vorherigen Abschnitten der konzeptionelle Aufbau der DatenKomponente ausführlich beschrieben wurde, schildert dieser Abschnitt die notwendigen
Entwicklungsschritte. Die Vorgehensweise bei der Erstellung der Systemkomponente ist
mit der Darstellung 6-12 gegeben. Grundlage bildet ein umfassender Datenbestand
raumbezogener Informationen, der sich generell in einem GIS befindet. Für die
Verwendung im Fahrradtouren-Navigationssystem wird zunächst der gesamte Dateninhalt
generalisiert und, insofern erforderlich, vervollständigt. Aus der Datenmodifikation
resultiert ein reduzierter, auf das Navigationssystem abgestimmter Datensatz. Dieser liegt
in unterschiedlichen GIS-spezifischen Datenformaten vor und muss in die
systemspezifischen Datenformate transformiert werden. Ergebnis der Umformung ist die
Daten-Komponente.
Datenbestand raumbezogener Informationen
GIS
Generalisierung
Reduzierter, angepasster Datenbestand
Umformung
Daten-Komponente
Darstellung 6-12: Generierung der Datenkomponente.
6 Konzeption
55
Als Hauptdatenquelle des Fahrradtouren-Navigationssystems dient der Datenbestand des
Amtlichen Topographisch-Kartographischen Informationssystems (ATKIS) [ATKIS,
2004]. ATKIS ist ein Projekt der Arbeitsgemeinschaft der Vermessungsverwaltungen der
Länder der Bundesrepublik Deutschland (AdV) und hat zum Ziel, bundeseinheitliche
digitale topographische Informationen über Objekte, Erscheinungsformen und Relief der
Erdoberfläche bereitzustellen. Für die Modellierung und Erfassung raumbezogener Daten
in digitalen Landschaftsmodellen (DLM) wird ein objektstrukturiertes Datenmodell
verwendet. Dieses gliedert sich hierarchisch in Objektbereiche, -gruppen und –arten. Die
entsprechende semantische Objektklassifizierung und -verschlüsselung erfolgt nach dem
ATKIS Objektartenkatalog (ATKIS-OK). Neben einem an der analogen topographischen
Karte 1:25000 (TK25) angelehnten Basis-DLM (DLM25) bietet die AdV derzeit das
DLM250 und das DLM1000 an. In etwa entspricht die numerische Angabe der durch 1000
dividierten Kartenmaßstabszahl. Die Bildung digitaler kartographischer Modelle (DKM)
aus einem DLM regeln maßstabsabhängige Signaturenkataloge (SK). Sie enthalten unter
anderem Gestaltungsvorschriften für die Objektarten sowie Kriterien für das
Erscheinungsbild des DKMs (Kartenrand, Kartenrahmen, etc.). Exemplarisch führt die
kartographische Modellierung des Basis-DLMs nach dem ATKIS-SK10 zum DKM10.
Aufgrund
des
im
Fahrradtouren-Navigationssystem
maximal
darzustellenden
Kartenmaßstabs von 1:10000 basiert die Daten-Komponente auf Informationen aus dem
Basis-DLM sowie dem ATKIS-SK10. Ergänzt werden die ATKIS-Daten durch Geometrieund Sachinformationen von touristischen Objekten (POI), welche durch die
Landesvermessung und Geobasisinformation Niedersachsen (LGN) bereitgestellt wurden.
Sämtliche relevante Daten sind in ArcView GIS 3.2 organisiert [vgl. Kapitel 5.1]. ArcView
erlaubt die Integration, Verwaltung und Modifikation von Geo-Informationen und besitzt
umfassende Funktionalitäten zur Generierung der Daten-Komponente.
Das
Anpassen
und
Reduzieren
der
Geo-Daten erfolgt mit Hilfe der
Generalisierungsvorgänge Auswählen, Klassifizieren, Zusammenfassen, Vereinfachen und
Symbolisieren (Darstellung 6-13). Beim Auswählen werden Geo-Objekte, die außerhalb
des für die Fahrradtour relevanten Gebiets liegen oder für die Fahrradnavigation keine
Bedeutung haben, entfernt. Die Methode der Klassifizierung vereinigt Objekte
unterschiedlicher Objektarten zu einer Objektgruppe, wodurch sich die Anzahl der zu
integrierenden Klassen vermindert. Eine weitere Verallgemeinerung des Datenbestands
erreicht die Zusammenfassung von mindestens zwei Objekten einer Klasse zu einem
Objekt. Dieser Vorgang ist anzuwenden, wenn Klassenobjekte dicht beieinander liegen.
Bei der Vereinfachung werden unwesentliche Punkte der Objekt-Geometrien eliminiert
und damit das Datenvolumen reduziert. Zuletzt ersetzt das Verfahren der Symbolisierung
flächenhafte Objekte (Polygone) durch individuelle graphische Elemente.
Zur Erstellung der Daten-Komponente aus dem angepassten GIS-Datenbestand, mit den
fundamentalen Datenformaten SVG und CSS [vgl. Kapitel 3], wird eine geeignete
Prozedur benötigt. Da vorhandene ArcView-Scripte, wie beispielsweise Shp2svg [ROGERS,
2002], lediglich generelle Lösungen anbieten, ist ein anwendungsspezifisches in Avenue
entwickeltes Script zu nutzen. Dieses ermöglicht eine weitestgehend automatische
Generierung der Bestandteile der Daten-Komponente.
6 Konzeption
56
Original
Auswahl
Ergebnis
Klassifizierung
Symbolisierung
Zusammenfassung
Vereinfachung
Darstellung 6-13: Generalisierung des Datenbestands.
6.3 Konzeption der User-Interface-Komponente
Eigenschaften und Operationen einzelner Systembestandteile des FahrradtourenNavigationssystems modifiziert beziehungsweise steuert der Anwender über die UserInterface-Komponente. Diese gliedert sich in die für dynamische Vorgänge notwendigen
Prozeduren und der sichtbaren Benutzeroberfläche (GUI). Letztere dient der Wiedergabe
von Informationen der Daten-Komponente sowie dem Starten und Beenden einzelner
Prozeduren.
Der wesentliche Aufbau der Benutzeroberfläche geht aus Darstellung 6-14 hervor.
Angesichts der beschränkten Anzeigemöglichkeiten auf einem Kleindisplay sollte die GUI
aus einem maximierten Kartenfeld und einer kompakten, am unteren oder oberen Rand des
Bildschirms positionierten Symbolleiste bestehen. Das Kartenfeld hat den Zweck, die von
der Daten-Komponente definierte Kartengraphik dynamisch in die Benutzeroberfläche
einzubetten. Bei der Graphik handelt es sich dabei, in Abhängigkeit vom Maßstab, um eine
rasterorientierte oder um eine hybride Darstellung [vgl. Kapitel 6.2.5]. Die Regelung der
Art und Weise der Datenpräsentation erfolgt über graphische Objekte in der Symbolleiste.
Wegen des Platzmangels auf dem Bildschirm sieht das Konzept des FahrradtourenNavigationssystems lediglich Kontrollen für das Zoomen, das Verschieben, die
Standortangabe, die Zeichenerklärung sowie die Routensuche und -wiedergabe vor. Der
Zugriff auf Routing-Funktionalitäten ist hier aus Gründen der Vollständigkeit mit
aufgelistet, wird aber im Rahmen der anwendungsspezifischen Implementierung in Kapitel
7 nicht weiter berücksichtigt [vgl. Kapitel 2.1].
Während das Ausführen von Zoom-, Pan-, Ortungs- oder Routing-Prozessen direkt eine
Veränderung der Kartenansicht beziehungsweise des Karteninhalts im Kartenfeld bewirkt,
6 Konzeption
57
startet das Navigationssystem beim Aufruf der Legende einen externen HTML-Viewer, der
die in einer HTML-Datei integrierte Zeichenerklärung [vgl. Kapitel 6.2.3] abbildet. Neben
den über die Symbolleiste kontrollierbaren Vorgängen, kann der Bediener durch
Ansprechen von Objektsymbolen in der Kartengraphik auf Sachinformationen
entsprechender POIs zugreifen. Da diese objektbeschreibenden Daten ebenfalls im Format
HTML gespeichert sind [vgl. Kapitel 6.2.2], übernimmt der HTML-Viewer die
Präsentation.
Um die vom Navigationssystem geforderte Dynamik der User-Interface-Komponente zu
verwirklichen,
findet
die
graphische
Gestaltung
der
Benutzeroberfläche
im
vektororientierten Format SVG, welches speziell auf Interaktionen ausgerichtete
Funktionalitäten umfasst [vgl. Kapitel 3.3], statt. Graphische Objekte der Symbolleiste
werden mit Eventhandlern versehen, die beim Eintreten des festgelegten Ereignisses, in der
Regel ein Mausklick, einen vordefinierten Prozess auslösen. Sämtliche Prozeduren sind in
der Programmiersprache Javascript [vgl. Kapitel 5.4] formuliert und in einer externen
Datei abgelegt. Durch die explizite Ausweisung von Javascript als Ergänzung zu SVG
können die Bestandteile der GUI über einfache Verknüpfungen auf die JavascriptProzeduren zugreifen.
Benutzeroberfläche
Symbolleiste
Routing
Kartenfeld
Route
Karte kleinsten Maßstabs
Ortung
Standort
Pan
Verschiebung
Karte größten Maßstabs
Zoom
Skalierung
In Abhängigkeit vom Maßstab
Darstellung der Raster- oder
Legende
Externer HTML-Viewer
Zeichenerklärung
Sachinformation
der hybriden Kartengraphik
Points Of Interest
Darstellung 6-14: Benutzeroberfläche der User-Interface-Komponente.
6 Konzeption
58
6.4 Konzeption der Visualisierungs-Komponente
Die wesentliche Aufgabe der Visualisierungs-Komponente besteht in der Übertragung von
Geo-Informationen der Daten-Komponente zum Anwender. So müssen die Geometrie-,
Sach- und Graphikdaten richtig interpretiert und sinngemäß dargestellt werden. Weiterhin
erfordert die in Kapitel 2.1 aufgestellte Funktionalität der dynamischen Datenwiedergabe
eine Unterstützung interaktiver Prozesse. Infolge der begrenzten Eingabemöglichkeiten des
PDAs nimmt die Visualisierungs-Komponente auch eine herausragende Position bei der
Bedienung des Navigationssystems durch den Anwender ein. Sie präsentiert die graphische
System-Benutzeroberfläche und leitet Befehle des Anwenders an die entsprechenden
Prozeduren der User-Interface-Komponente weiter.
Begründet in der standardisierten Entwicklung der Daten- und der User-InterfaceKomponente [vgl. Kapitel 6.2 und Kapitel 6.3] kann die Visualisierungs-Komponente aus
unterschiedlichen Softwarepaketen bestehen. Es werden leistungsfähige Viewer für die
Wiedergabe von HTML- und SVG-Dateien benötigt. Als HTML-Viewer bietet sich der im
Betriebssystem Microsoft Windows CE bereits integrierte Pocket Internet Explorer an.
Dieser dient dem Anzeigen der zusätzlichen Sachinformationen von POIs und der
zeichenerklärenden Legende. Alle weiteren Elemente visualisiert ein SVG-Viewer, der die
Standardformate SVG und CSS sowie die in der Programmiersprache Javascript
geschriebenen dynamischen Vorgänge unterstützt. Das in dieser Arbeit vorgestellte
Navigationssystem verwendet als SVG-Viewer den Intesis eSVG-Viewer, wobei ein
Einsatz alternativer Programme denkbar ist.
6.5 Konzeption der Positions-Komponente
Das Konzept des Fahrradtouren-Navigationssystems geht von der Entwicklung einer vom
System unabhängigen Positions-Komponente in Form einer Standalone-Applikation aus.
Dadurch lässt sich diese leicht in andere Systeme integrieren und kann vielseitig eingesetzt
werden.
Aufgabe der Positionskomponente ist es, die vom GPS-Receiver ausgegebenen Daten zu
lesen und die Standortinformationen in ein vom System unterstütztes Datenformat
abzulegen. Die dafür notwendigen Arbeitsschritte zeigt Darstellung 6-15. Zunächst wird
das standardisierte GPS-Datenprotokoll NMEA 0183 der Empfängerausgabe vollständig
gelesen. Da sich die für Navigationszwecke erforderliche Information der
Positionskoordinaten des Standortes ausschließlich in den Datensätzen GGA und RMC
befindet [vgl. Kapitel 4.2.2], muss die Systemkomponente aus dem empfangenen
Datenprotokoll eines der beiden Ausgabeformate herausfiltern. Anschließend erfolgt die
Analyse der GGA- beziehungsweise RMC-Daten, wobei die Information der
geographischen Länge λ und Breite ϕ vom restlichen Teil des Datensatzes separiert wird.
Die Speicherung der aus der Datensatzanalyse resultierenden Standortinformation erfolgt
unter der Verwendung des Formats XML. Andere Systembestandteile können so über die
XML-Datei die Positionskoordinaten abfragen. Damit das Navigationssystem in Echtzeit
arbeiten kann, sind die beschriebenen Prozesse in kurzen Zeitintervallen (wenige
Sekunden) zu wiederholen.
6 Konzeption
59
Dateneingang
GPS-Datenprotokoll NMEA 0183
Datenfilterung
GGA- oder RMC-Datensatz
Datenanalyse
Position im WGS-84-Bezugssystem mit
geographischer Länge λ und Breite ϕ
Datenausgang
Positionskoordinaten in XML-Datei
Darstellung 6-15: Datenmodifikation der Positions-Komponente.
Für die Programmierung der Positions-Komponente wird, im Rahmen der prototypischen
Implementierung in Kapitel 7, die Entwicklungsumgebung Microsoft eMbedded Visual
Basic Tools (eVB-Tools) genutzt [vgl. Kapitel 5.3]. Mit eVB-Tools lassen sich auf
Windows CE basierte Anwendungen erstellen. Die Umgebung verfügt über umfangreiche
Werkzeuge für die Programmentwicklung und die Generierung einer Benutzeroberfläche.
Weiterhin stellt sie Funktionen bereit, über die ein erstelltes Programm mit einer
Hardwarekomponente, wie dem GPS-Empfänger, kommunizieren kann.
Das Programm für die Standortbestimmung sollte dem Nutzer die Möglichkeit geben, über
graphische Elemente der Benutzeroberfläche die Hardwareschnittstelle (z.B. Com-Port),
die Datenübertragungsrate (Baudrate), das Ausgabeintervall sowie den Namen der
Ausgabe-Datei auszuwählen. Durch diese Funktionalität ist die Positions-Komponente mit
diversen GPS-Empfängern kompatibel und kann unterschiedlichen Systemansprüchen
angepasst werden.
7 Anwendungsspezifische Implementierung
60
Nachdem im vorangehenden Kapitel die Konzepte für ein FahrradtourenNavigationssystem aufgestellt wurden, veranschaulicht dieses Kapitel die prototypische
Systemimplementierung anhand eines exemplarischen Anwendungsbeispiels.
Basierend auf der Charakterisierung des Ausgangsszenarios werden die erforderlichen
Entwicklungsschritte für den Aufbau der einzelnen Systemkomponenten vorgestellt.
7.1 Ausgangsszenario
Das über das Internet zugängliche Freizeitportal GeoLife [GEOLIFE, 2004] der LGN bietet
Fahrradfahrern diverse detailliert beschriebene attraktive Fahrradtouren-Vorschläge an.
Die entsprechende Wegbeschreibung kann ausgedruckt und während der Tourbefahrung
mitgeführt werden. Leider gibt es bislang keine Möglichkeit die Nutzer, in Abhängigkeit
von der ausgewählten Tour, unterwegs mit einer dynamischen standortbezogenen
Situationsdarstellung zu unterstützen. Da aber der Anwender, in der Regel ein Tourist,
gerade diese Art der Orientierungshilfe favorisiert, stellt sich die Aufgabe der
Bereitstellung eines zweckmäßigen Fahrradtouren-Navigationssystems. Denkbar ist
beispielsweise, dass die für eine bestimmte Tour notwendigen System-Dateien über das
Internet abrufbar sind. Somit könnte ein Nutzer, durch Kombination der System-Dateien
mit einem kompatiblen, GPS-gestützten PDA auf ein vollwertiges Navigationssystem
zurückgreifen.
Für die exemplarische Systemrealisierung wurde der GeoLife Fahrradtouren-Vorschlag
149 „Maschsee-Route zur Expo“ ausgesucht. Dieser beginnt auf dem Hauptbahnhof
Hannover und endet am Eingang des Expo- und Messegeländes Hannover. Die
Systementwicklung erfolgt unter Verwendung der in Kapitel 6 aufgestellten Konzepte. Als
Datenquellen dienen der in ArcView vorliegende ATKIS-Basisdatenbestand der Region
Hannover sowie die tourrelevanten POI-Daten der LGN.
7.2 Entwicklung der Daten-Komponente
Für die Generierung der Daten-Komponente aus dem originären Datenbestand sind
umfangreiche Entwicklungsvorgänge notwendig. Die in ArcView bereits in Themen
(Layern) organisierten Daten müssen generalisiert, graphisch gestaltet und in das SVGFormat transformiert werden [vgl. Kapitel 6.2.6]. Weiterhin ist zur Vervollständigung der
Systemkomponente eine für die kleinmaßstäbige Situationswiedergabe zuständige PNGoder JPG-Rastergraphik aus ArcView zu exportieren. Die folgenden Abschnitte
beschreiben alle zur Erstellung der Daten-Komponente wichtigen Prozesse.
61
7.2.1 Generalisierung der ATKIS-Daten
Die Reduktion und Anpassung des ATKIS-Datenbestands an die Anforderungen des
Fahrradtouren-Navigationssystems
beinhaltet
nach
Kapitel
6.2.6
die
Generalisierungsschritte Auswählen, Klassifizieren, Zusammenfassen, Vereinfachen und
Symbolisieren. Alle Maßnahmen werden in ArcView 3.2 unter Verwendung zusätzlicher
Werkzeuge durchgeführt. Darstellung 7-1 zeigt die Situation in ArcView vor der
Generalisierung und kennzeichnet das Interessengebiet, auch AOI14 genannt, der Tour 149.
Interessengebiet
Darstellung 7-1: Originärer Datenbestand ohne Beschriftung mit Interessengebiet.
7.2.1.1
Auswahl
Unter der Auswahl versteht sich die Selektion systemrelevanter Informationen aus dem
Datengesamtbestand. Dabei gilt es raumbezogene Objekte, welche sich außerhalb des
Interessengebiets befinden oder für die Fahrradnavigation unbedeutend sind, zu
eliminieren.
Zunächst muss die AOI festgelegt und die enthaltenen Objekte von den restlichen Daten
getrennt werden. Dazu ist in ArcView ein neues Thema des Typs Polygon zu erstellen. In
diesem befindet sich ein mit Hilfe der Graphikwerkzeuge in der Toolleiste gezeichnetes,
das Gebiet abstrahierendes Rechteck. Über die „Clip“-Funktion des Assistent für
14
AOI steht für Area Of Interest.
62
Geoverarbeitung, verfügbar durch die Aktivierung der ArcView-Standarderweiterung
Geoprocessing, sind dann alle Themen mit Bezug auf das Polygon-Thema auszuschneiden.
Anschließend erfolgt die Bewertung der einzelnen Objektarten hinsichtlich ihres
Vorkommens in der AOI und ihrer Bedeutung im semantischen Datenmodell des
Fahrradtouren-Navigationssystems aus Kapitel 6.2.2. Objektarten, die bei der Abstraktion
der realen Welt innerhalb der AOI keine Rolle spielen, werden entfernt.
Das Generalisierungsverfahren der Auswahl verringert die Anzahl der ursprünglich über
100 Objektarten auf ungefähr 70. Das vorläufige Ergebnis ist aus Darstellung 7-2
ersichtlich.
Darstellung 7-2: Datenbestand ohne Beschriftung nach der Datenauswahl.
7.2.1.2
Klassifizierung
Der aus der Datenauswahl hervorgehende Objektartenbestand ist für eine zweckmäßige
graphische Informationswiedergabe immer noch zu detailliert. Darum werden nach der
Methode der Klassifizierung Objektarten in vordefinierte Objektgruppen eingeteilt, so dass
sich das Datenmodell vereinfacht. Die Gruppierung der Objektarten verläuft nach dem
semantischen Modell des Navigationssystems [vgl. Kapitel 6.2.2]. Demnach klassifizieren
22 Objektklassen die diversen Objektarten.
In ArcView bietet der Assistent für Geoverarbeitung auch Prozeduren zur
Objektklassifizierung an. Mit Hilfe der „Merge“-Funktion lassen sich in unterschiedlichen
Themen organisierte Objektarten zu einem Thema verbinden. Somit kann durch
wiederholtes Durchführen der thematischen Zusammenführung das semantische Modell
63
aufgebaut werden. Ein Beispiel für die Klassifizierung von Objekten liefert Darstellung
7-3. Die Elemente der Objektarten Fluss, Kanal und Teich bilden die neue Objektklasse
Gewässer.
Original
Klassifizierung
Fluss
Kanal
Teich
Gewässer
Darstellung 7-3: Klassifizierung von Objekten.
7.2.1.3
Zusammenfassung
Für die graphische Situationsdarstellung im Fahrradtouren-Navigationssystem liefert die
Generalisierungsmethode der Klassifizierung ein zufrieden stellendes Ergebnis. Dennoch
bleibt das Problem des großen Datenvolumens bestehen, da die Reorganisation der Daten
lediglich
den
strukturellen
Datenaufbau
vereinfacht.
Abhilfe
schafft
eine
Zusammenfassung von benachbarten Objekten. Dieser Vorgang entfernt Informationen,
welche auf das Erscheinungsbild der Kartengraphik keinen Einfluss haben.
Der Assistent für Geoinformation von ArcView besitzt für die strukturelle
Zusammenfassung von Flächen-Geometrien (Polygone) die Funktion „Dissolve“, die aus
Objekten eines Polygon-Themas sogenannte Multipart-Objekte bildet. In den MultipartObjekten
sind
weiterhin
alle
Geometrie-Daten
enthalten.
Zur
eigentlichen
Datenreduzierung wird die ArcView-Erweiterung XTools [DELAUNE, 2003] genutzt. Diese
umfasst die Prozedur „Convert Multipart Shapes to Single Part“, mit der eine
Umwandlung der Multipart-Objekte in isolierte Einzelobjekte möglich ist. Im Rahmen der
Transformation werden überschüssige Geometrie-Daten gelöscht. Ein typisches Beispiel
der Zusammenfassung von Flächen-Geometrien legt Darstellung 7-4 dar, wobei die
Objektumrandung nur der Verdeutlichung dient. Es ist leicht zu erkennen, dass der
Generalisierungsprozess den Datenumfang und somit das Speichervolumen der GeoInformationen erheblich reduziert.
Eine Zusammenfassung von aneinander liegenden Linien-Objekten gestattet die Funktion
„Polyline Consolidator“ der ArcView-Erweiterung Point & Polyline Tools [ALSLEBEN,
2002]. Die Prozedur erstellt aus Objekt-Geometrien mit gleichem Endpunkt Einzelobjekte
und entfernt die redundanten Geometrie-Daten.
Original
64
Zusammenfassung
Darstellung 7-4: Zusammenfassung von Flächenobjekten einer Objektklasse.
7.2.1.4
Vereinfachung
Der Informationsgehalt der Daten-Komponente wird durch die Vereinfachung von ObjektGeometrien weiter reduziert. Das Verfahren geht davon aus, dass der Detaillierungsgrad
des originären Datenbestands höher ist, als es die Situationswiedergabe erfordert.
Demzufolge können Linien- und Polygon-Geometrien ohne Auswirkung auf die
Objektformen in der Kartengraphik ausgedünnt werden. Unbedeutende Geometrie-Punkte
sind bei der Objektbildung auszulassen und aus dem Datenbestand zu entfernen. Die
Beurteilung der Signifikanz eines Punktes findet unter Berücksichtigung der Auflösung des
Ausgabebildschirms sowie des maximalen Kartenmaßstabs statt. Aufgrund der Pixelgröße
auf dem PDA-Display von 0,24 Millimeter und einem maximalen Maßstab von 1:10000
abstrahiert die Pixelgröße einen realen Wert von 2,4 Meter. Da eine optimale Performance
des Fahrradtouren-Navigationssystem einen möglichst geringen Datenumfang voraussetzt,
wird ein Geometrie-Punkt als unwesentlich eingestuft, wenn sich die Objekt-Geometrie
beim Auslassen dieses Punktes um höchstens einen Pixel in der Kartengraphik
beziehungsweise um circa 2,5 Meter in der realen Welt verschiebt.
Die ArcView-Erweiterung Point & Polyline Tools stellt mit der Funktion „Generalize
Features“ eine leistungsfähige Linienglättungs-Methode bereit. Diese arbeitet nach dem
globalen Verfahren von Douglas und Peuker, welches die Darstellung 7-5 abbildet und
BILL (1999) wie folgt charakterisiert:
Zunächst werden Anfangs- und Endpunkt eines Linienstücks durch die Sehne AB
miteinander verbunden. Befinden sich alle weiteren Linienpunkte innerhalb eines
festgelegten Buffers um AB, ist die Generalisierung abgeschlossen. Bei Nichterfüllung
wird der am weitesten von der Sehne AB entfernte Punkt als neuer Linienpunkt C
festgelegt. Anschließend erfolgt die rekursive Anwendung des Algorithmus auf die zwei
entstandenen Linienelemente AC und CB. Durch Wiederholung der Vorgänge entwickelt
sich dann die geglättete Linie.
Das Douglas und Peuker Verfahren ist mit der „Generalize Features“-Funktion auf
sämtliche Linien- und Polygon-Themen des Datenbestands durchzuführen. Begründet in
der aufgestellten Forderung nach einer maximalen Veränderung der Objektform von einem
65
Pixel, wird ein Buffer von 2,5 Metern deklariert. Alternativ zu der hier vorgestellten Art
der Linienglättung sind natürlich auch andere Methoden zur Datenvereinfachung, zum
Beispiel das Ersetzen der Linie durch eine ausgleichende Funktion, anwendbar.
C
Originäre Linie
D
(7 Stützpunkte)
Geglättete Linie
(4 Stützpunkte)
Sehne
Buffer
A
B
Darstellung 7-5: Linienglättung mit Douglas-Peuker-Algorithmus.
7.2.1.5
Symbolisierung
Damit Anwender touristisch interessante Objekte, wie beispielsweise Schwimmbäder,
Stadien oder Zoologische Gärten, auf der Kartengraphik schnell erkennen können, werden
die entsprechenden Flächenobjekte durch möglichst selbsterklärende Symbole ersetzt
(Darstellung 7-6). Der positive Nebeneffekt dieses Vorgehens ist eine Datenreduktion
aufgrund des Wechsels der originären Polygon-Geometrien in Punkt-Geometrien.
Original
Schwimmbad
Symbolisierung
Stadion
Zoo
Darstellung 7-6: Symbolisierung von Flächenobjekten.
Zur Realisierung der Symbolisierung bedarf es zunächst einer Umwandlung der
betroffenen Polygon-Themen in Punkt-Themen. Dabei kommt die Funktion „Convert
Shapes To Centroids“ der ArcView-Erweiterung XTools zum Einsatz. Diese berechnet für
jedes Flächenobjekt den Mittelpunkt und bildet aus den so gewonnenen Punkt-Geometrien
ein neues Thema. Den Objektpunkten sind nachfolgend geeignete graphische Elemente,
66
vorzugsweise kleine Symbolgraphiken, für die Präsentation zuzuordnen. Für die DatenKomponente des Navigationssystems werden die Objektarten Schwimmbad, Stadion, Zoo
und Campingplatz symbolisiert.
7.2.2 Graphische Gestaltung der ATKIS-Daten
Nach dem in Kapitel 6.2.3 aufgestelltem Konzept für die Graphikdaten der DatenKomponente basiert die graphische Darstellung der generalisierten ATKIS-Daten auf dem
ATKIS-Signaturenkatalog 1:10000. Die darin enthaltenen Gestaltungsvorschriften können
aber, infolge der Eigenarten des Fahrradtouren-Navigationssystems, nicht direkt
übernommen werden und sind dementsprechend anzupassen.
Punkt-Geometrie
Linien-Geometrie
Flächen-Geometrie
Darstellung 7-7: Graphische Gestaltung der generalisierten ATKIS-Daten.
Der entscheidende Faktor bei der Auswahl einer Objektsignatur ist die effiziente
Umsetzung dieser in der SVG-basierten Kartengraphik. Während sich uniforme oder
punktbezogenen Signaturen leicht durch die Kombination von SVG mit CSS realisieren
lassen, gibt es bisher keine unmittelbare Möglichkeit Objekten eine gemusterte Struktur
zuzuweisen. Demnach sind gestrichelte Linien- oder gepunktete Flächensignaturen für die
Datenpräsentation ungeeignet, so dass die betroffenen Themen der Daten-Komponente
durch Signaturen dargestellt werden müssen, die von der Zeichenvorschrift abweichen.
Zur Symbolisierung von Objekt-Geometrien [vgl. Kapitel 7.2.1.5] sind die im SK10
enthaltenen Zeichen zwar inhaltlich korrekt, wirken aber eher unattraktiv und dem
touristischen Gebrauch nicht angemessen. Darum ersetzen Graphiken im PNG-Format die
festgelegten Symbole. Sämtliche im Navigationssystem gebrauchte Symbole wurden mit
Hilfe des Bildverarbeitungsprogramms Corel Photo-Paint 11 [C OREL, 2003] erstellt.
Das für die graphische Gestaltung der Themen zuständige Werkzeug in ArcView ist der
über das Inhaltsverzeichnis aufrufbare Legenden Editor [vgl. Kapitel 5.1.3]. Dieser erlaubt
67
eine einfache Generierung und Bearbeitung der Graphikdaten. Eine Übersicht der im
Fahrradtouren-Navigationssystem genutzten Signaturen zeigt Darstellung 7-7.
7.2.3 Integration von Objektbeschriftung
Ein wichtiges Hilfsmittel bei der Interpretation beziehungsweise der eindeutigen
Identifizierung von Objekten in der Kartengraphik ist die Objektbeschriftung, die unter
anderem Namen von Stadtteilen, Straßen sowie markanten Freiflächen wiedergibt. Die in
ArcView vorliegenden ATKIS-Daten beinhalten bereits einen umfassenden Bestand an
Beschriftungen unterschiedlicher Objektarten. Dieser muss, infolge des begrenzten
Platzangebots auf der Kartengraphik, zunächst ausgedünnt und anschließend an den
Kartenmaßstab angepasst werden. Das Navigationssystem sieht die Einbeziehung von
Beschriftungen für Stadtteile, Siedlungsfreiflächen, Bahnhöfe, Wasserflächen und Straßen
vor, wobei sich die graphische Gestaltung an dem ATKIS-SK10 orientiert.
Nach dem Prägnanzprinzip [vgl. Kapitel 6.2.3] dürfen sich Beschriftungen in der
Kartengraphik nicht überlagern. Diese Bedingung setzt ein kontinuierliches Entfernen
beziehungsweise Verschieben von Schriftelementen voraus, bis sich keine Bezeichnungen
mehr schneiden (Darstellung 7-8). Dabei wird das Element entfernt oder verschoben,
welches die niedrigere Priorität hat. Mit Ausnahme der Namen für Gemeindestraßen kann,
wegen der geringen Anzahl auftretender Fälle im Interessengebiet, eine manuelle
Objektfreistellung
erfolgen.
Hinsichtlich
der
untergeordneten
Gemeindestraßenbeschriftung mit über 1500 Objekten innerhalb der AOI und unzähligen
Überlagerungen ist die Nutzung automatisierter Methoden unumgänglich.
Original
Auswahl von Kartenschrift
Darstellung 7-8: Behandlung von Objektbeschriftung.
Zum Ausdünnen der Bezeichnungen für Gemeindestraßen gilt der Grundsatz, dass die
Objektpriorität linear mit der Objektlänge steigt. Demnach stellt sich zunächst die
Aufgabe, den Straßennamen die jeweilige Straßenlänge zuzuordnen. Dafür wurde das
Avenue-Script Polyline Total Length (totleng) entwickelt, das innerhalb eines LinienThemas die Gesamtlänge von Objekten mit gleichem Wert für ein gewähltes Attribut
berechnet und das Ergebnis unter einem neuen Attribut „Totlength“ ablegt. Aus der
68
Anwendung des Scripts auf das Thema der Straßen-Geometriedaten mit dem gewählten
Identifikationsattribut „Obj“ resultieren die Straßenlängen. Diese lassen sich jetzt über
„Obj“ auf die Objekte in dem Beschriftungs-Thema übertragen. Jede Straßenbezeichnung
erhält so eine Objektpriorität.
Nächster Schritt ist die eigentliche Objektselektion. Bezeichnungen von Straßen mit einer
Länge von unter 400 Metern werden von vornherein für die Darstellung in der
Kartengraphik ausgeschlossen. Die tabellarische Objektansicht in ArcView bietet hierfür
ausreichende Funktionalitäten. Eine Möglichkeit ist zum Beispiel die Sortierung der
Objekte im Bezug auf das Längenattribut und anschließendem manuellen Löschen der
Objektelemente mit einer zu kleinen Gesamtlänge. Über die Verwendung der
verbleibenden Objekte im Thema entscheidet ein Beschriftungstest, der mit dem ebenfalls
neu entwickelten Script Polyline Label Test (linelab) durchgeführt wird. Das Script nutzt
den Umstand, dass der Ort, die Orientierung als auch das Ausmaß einer Beschriftung durch
eine Linien-Geometrie definiert ist. Demzufolge kann durch die Berechnung des Abstands
zwischen zwei Beschriftungs-Geometrien und der Festlegung eines Schwellwerts (Buffer)
eine gegenseitige Überlagerung auf einfachem Wege festgestellt werden. Als erstes erstellt
das Script für ein gewähltes Linien-Thema das neue Attribut „Label“ und legt die Objekte
des Themas in einer temporären Liste ab. Alle Listenelemente werden über ein selektiertes
Prüfattribut, hier „Totlength“, absteigend sortiert. Von oben beginnend folgt dann für jedes
Element (Prüfling) die Berechnung des geometrischen Abstands zu den in der Liste
darüber angeordneten Elementen. Wenn der Abstand zu einem Element kleiner als der
gewählte Schwellwert (Buffer) ist und dieses den „Label“-Wert „True“ besitzt, erhält der
Prüfling den „Label“-Wert „False“. Andernfalls wird der „Label“-Wert des Prüfelements
als „True“ deklariert. Somit ergeben sich nach der Scriptausführung auf das BeschriftungsThema die objektspezifischen Werte des Attributs „Label“. Objekte mit dem Attributwert
„False“ überdecken andere Objekte mit einer höheren Priorität und sind zu entfernen. Die
restlichen Elemente bilden den endgültigen Datenbestand an GemeindestraßenBeschriftungen
im
Fahrradtouren-Navigationssystem.
Einen
zusammenfassenden
Überblick der einzelnen Entwicklungsstufen liefert das Schema in Darstellung 7-9.
In ArcView können aus dem ausgedünnten Datenbestand der Beschriftungs-Geometrien
leicht individuelle Objektbeschriftungen generiert werden. Die „Auto-Label“-Funktion
bildet unter Auswertung der Geometriedaten freie Textelemente, welche die Inhalte eines
festgelegten Objektattributs wiedergeben. Allerdings sind die so entstandenen
Beschriftungen für den Export in SVG unbrauchbar, da ArcView in der Version 3.2 ein
Ansprechen beziehungsweise Abfragen von Informationen freier Graphiken nicht
unterstützt. Eine Lösung dieses Problems beschreibt Kapitel 7.2.6.
69
Geometriedaten der Gemeindestraßen
Script Polyline Total Length
Straßenlängen
Beschriftungsdaten von Gemeindestraßen
Datenauswahl
Reduzierte Beschriftungsdaten
Script Polyline Label Test
Datenauswahl
Beschriftungsdaten von Gemeindestraßen
in Daten-Komponente
Darstellung 7-9: Beschriftung von Gemeindestraßen.
7.2.4 Integration der Tour-und der POI-Daten
Neben den ATKIS-basierten Geo-Informationen muss die Kartengraphik des
Navigationssystems auch Angaben über die Route sowie die Position von
Interessenpunkten mit einschließen. Deshalb wird der in ArcView vorhandene Datensatz
um die notwendigen Informationen erweitert. Des Weiteren besteht die Aufgabe, alle
zusätzlichen POI-Sachdaten in HTML-Dateien abzulegen [vgl. Kapitel 6.2.2].
Aufgrund des bereits feststehenden Routenverlaufs der Tour 149 und der grundlegenden
Systemaufgabe der Wegführung können Tourinformationen fest in die Kartengraphik
integriert werden. Für die Realisierung sind die nach der LGN-Tourbeschreibung
erforderlichen Straßen-Objekte in den entsprechenden ArcView-Themen zu selektieren
und in ein neues Thema zu kopieren. Aus der graphischen Gestaltung der so erstellten
Tourdaten unter Einhaltung des Prägnanzprinzips ergibt sich eine zweckmäßige Abbildung
der Route (Darstellung 7-10).
Nach dem Konzept der Daten-Komponente soll der Zugriff auf objektspezifische
Sachinformationen von POIs, zu denen Rast- und Kulturstätten gehören, über die
Objektgeometrie verlaufen [vgl. Kapitel 6.2.2]. Folglich sind die betreffenden
Interessenpunkte in die Kartengraphik mit einzubeziehen. Die dafür notwendigen
Positionsangaben der verfügbaren POIs befinden sich mit anderen Sachinformationen in
einer Tabelle, die in ArcView eingeladen wird. Anschließend ermöglicht die ArcviewFunktion „Ereignisthema hinzufügen“ die Entwicklung eines Punkt-Themas, das die aus
70
der Tabelle stammenden Geometrie- und Sachdaten der POIs beinhaltet. Zur graphischen
Situationswiedergabe werden POIs, welche sich außerhalb des Interessengebiets befinden,
aussortiert und die Geometrien der restlichen Objekte durch geeignete Symbole im PNGFormat wiedergegeben (Darstellung 7-10).
Kulturinfo
Rastinfo
Tour
Darstellung 7-10: Kartenausschnitt mit Tour- und POI-Daten.
Zu den bereitgestellten POI-Daten gehören außer den in der Tabelle enthaltenen
Informationen auch Objektbilder im JPG-Format sowie detaillierte Objektbeschreibungen
im TXT-Format. Das Konzept der Daten-Komponente sieht für diese Daten eine
Speicherung in objektspezifischen HTML-Dateien vor [vgl. Kapitel 6.2.2].
Darstellung 7-11: HTML-Datei mit POI-Sachinformationen.
Aufgrund der hohen Anzahl an Interessenpunkten und der zeitaufwendigen manuellen
Generierung von HTML-Seiten ist das in Kapitel 7.2.5 vorgestellte Avenue-Script th2SVG
zur Entwicklung der hybriden Kartengraphik mit einer optionalen Funktion zur Erstellung
der HTML-Dateien ausgestattet. Das Script erkennt ein POI-Thema anhand der am Anfang
71
eines Themennamens stehenden Kennung „link“ und stellt die HTML-Seiten nach Eingabe
des Quellordners der Bild- und Text-Dateien unter Auswertung der individuellen
Objektattribute automatisch her. Die Verknüpfung der POI-Geometrien mit den
entsprechenden HTML-Seiten realisieren individuelle Hyperlinks. Ein Beispiel der so
entstandenen HTML-Dateien präsentiert Darstellung 7-11.
7.2.5 Entwicklung der hybriden Kartengraphik
Im Anschluss an die Reduzierung und Anpassung des originären Datenbestands an die
Anforderungen des Fahrradtouren-Navigationssystems behandelt dieser Abschnitt die
Transformation der in ArcView vorliegenden Informationen in die systemspezifischen
Datenformate SVG und CSS. Da vorhandene ArcView-Erweiterungen, wie beispielsweise
Shp2svg [ROGERS, 2002] oder MapViewSVG, nur unzureichende Funktionalitäten bieten,
wurde zur automatischen Entwicklung der hybriden Kartengraphik mit Theme to SVG
(th2SVG) ein neues Avenue-Script implementiert, welches über umfangreiche Optionen
für den Datenexport in SVG verfügt. Die fundamentalen, im Script realisierten
Entwicklungsstrategien sind im Folgenden erklärt.
7.2.5.1
Allgemein
Das Script th2SVG geht von einer flexiblen Festlegung der Ein- und Ausgabegraphik aus.
Damit ein Anwender den zu transformierenden Kartenbereich explizit und einfach
bestimmen kann, werden ausschließlich Informationen exportiert, die sich innerhalb der
frei definierbaren AOI einer ArcView-Ansicht befinden. Weiterhin sind alle
einzubeziehenden Themen im Inhaltsverzeichnis zu markieren. Eine Eingabemaske,
abgebildet in Darstellung 7-12, gestattet die Auswahl diverser Parameter für die SVGGraphik.
Darstellung 7-12: Eingabemaske des ArcView-Scripts Theme to SVG.
„Width“ und „Height“ beschreiben die maximale Bildgröße, welche beim Display des
iPAQs 240 x 320 Pixel beträgt. Die Kartengraphik wird in diese mit konstantem
Seitenverhältnis, also mit gleichem Vergrößerungsfaktor in Breite und Höhe, eingepasst.
Der Maßstab ergibt sich dabei durch Abrunden der maximal darstellbaren Skalierung auf
einen für die Karteninterpretation zweckmäßigen Wert. Sämtliche graphische
Gestaltungsmittel der Themen, wie Linienstärke, Umrisslinienstärke oder Symbolgröße,
wandelt das Script im Hinblick auf die „Output Scale“ um. Dadurch ist es möglich,
72
Signaturen auf einen spezifischen Kartenmaßstab anzupassen, der von dem sichtbaren
Wiedergabeverhältnis abweicht. Über das Feld „Resolution“ bestimmt der Nutzer unter
Eingabe des größten mit Zoom-Funktionen aufrufbaren Kartenmaßstabs die Genauigkeit
von Objektkoordinaten. Besonders bei den begrenzten Speicher- und Rechenkapazitäten
auf mobilen Endgeräten ist diese Funktionalität sehr sinnvoll, da eine übermäßige
geometrische Genauigkeit das Datenvolumen unnötig erhöht. Zum Beispiel bewirkt das
Weglassen einer Dezimalstelle bei den Koordinaten der über 150000 tourrelevanten
Objektpunkte eine Verringerung der SVG-Dateigröße um 20 Prozent. Gemäß den in
Kapitel 2.1 aufgestellten Anforderungen an das Navigationssystem wurde für die
Kartengenerierung der Tour 149 ein Ausgabemaßstab von 1:10000 und eine Auflösung mit
gleichem Wert deklariert.
Die Verwirklichung der hybriden Kartengraphik mit benachbarten Teilgraphen [vgl.
Kapitel 6.2.5] erfolgt durch die Unterteilung der AOI in einzelne Segmente, der
entsprechenden Zerlegung der Objektthemen sowie der anschließenden Transformation
jedes einzelnen Segments in SVG. Dabei werden alle Themen beziehungsweise
Objektgruppen eines Segments in einer übergeordneten SVG-Gruppe zusammengefasst,
die über einen einzigartigen Identifikator ansprechbar ist. th2SVG fragt mit Hilfe eines
Eingabefelds die Anzahl zu erstellender Teilgraphen ab und führt alle notwendigen
Entwicklungsschritte automatisch durch. Für die Präsentation des Interessengebiets der
Tour 149 wird die hybride SVG-Graphik aus 36 Kartensegmenten mit numerischen
Identifikatoren aufgebaut (Darstellung 7-13).
11
21
31
41
51
61
12
22
32
42
52
62
13
23
33
43
53
63
14
24
34
44
54
64
15
25
35
45
55
65
16
26
36
46
56
66
Darstellung 7-13: Aufbau der hybriden Kartengraphik für die Tour 149
7.2.5.2
Geometriedaten
Die in ArcView organisierten Geometriedaten der Geo-Objekte beziehen sich auf die
ebenen rechtwinkligen Koordinaten Hoch- und Rechtswert im winkeltreuen Gauss-KrügerMeridianstreifensystem (G-K-System). Das G-K-System ist über einen längentreu
abgebildeten Bezugsmeridian als Abszissenachse, einer dazu senkrecht liegenden, auf der
Äquatorlinie
verlaufenden
Ordinatenachse
sowie
dem
Schnittpunkt
zwischen
Bezugsmeridian und Äquatorlinie als Ursprung festgelegt. Der Hochwert beschreibt den
Abstand zur Äquatorlinie entlang des Meridians in Meter und ist auf der Nordhalbkugel
73
nach Norden gerichtet. Abzüglich der Kennzahl und einem Wert von 500000 Meter gibt
der Rechtswert den Abstand zur Abszisse in Meter an [GRUBER, 1998]. Im Gegensatz dazu
besteht das Koordinatensystem der SVG-Graphik, wie in Kapitel 3.3.2 bereits erwähnt, aus
einer nach rechts gerichteten Abszissenachse, einer nach unten gerichteten Ordinatenachse
und der oberen linken Kartenecke als Ursprung. Darum sind sämtliche Koordinaten aus
ArcView in das SVG-Koordinatensystem zu transformieren. Zunächst wird die obere linke
Ecke der AOI als Ursprung der Kartengraphik deklariert. Jetzt lassen sich die SVGKoordinaten durch einfaches Berechnen von G-K-Koordinatendifferenzen bezüglich des
Ursprungs in der Maßeinheit Meter berechnen:
XSVG [m] = RechtswertPunkt [m] − RechtswertUrsprung[m],
YSVG [m] = HochwertUrsprung [m] − HochwertPunkt [m].
Als Einheit des Zielkoordinatensystems wird der Default-Wert Pixel gewählt, wodurch das
Anfügen einer Werteinheit zu den SVG-Koordinaten entfällt und sich schlussfolgernd das
Speichervolumen verringert [vgl. Kapitel 3.3.2]. Der zur Umrechnung von Meter in Pixel
notwendige Skalierungsfaktor ergibt sich aus der Auswertung der AOI-Größe im G-KSystem, der in Kapitel 7.2.5.1 festgelegten Parameter SVG-Bildgröße (240 x 320 Pixel)
und maximaler Kartenmaßstab (1:10000) sowie der Annahme einer Pixelgröße von 0,24
Millimeter.
Eine weitere signifikante Reduzierung des SVG-Datenvolumens erzielt die Ablage der
Punktketten von Polylinien oder Polygonen anhand relativer Koordinaten. Das heißt, dass
einzig die Absolutkoordinaten des Startpunkts gespeichert werden und sich alle
nachfolgenden Stützpunktkoordinaten jeweils auf den Vorgänger beziehen. Bei der
Berechnung der relativen Positionsangaben muss immer der Bezug zum Anfangspunkt
hergestellt werden, da sich ansonsten die durch Rundung von Koordinatenwerten
entstandenen
kleinen
Abweichungen
aufaddieren
und
zu
ungewollten
Koordinatenverschiebungen führen. Die Berechnung der relativen Koordinaten erfolgt
demnach mit:
i −1
dX i = X i − X1 − ∑ dX j
j =1
mit
i,j ∈ N; X – absoluter Koordinatenvektor;
dX – relativer Koordinatenvektor.
Der hier vorgestellte Transformationsprozess von Geometriedaten aus ArcView in SVG ist
vollständig in dem Script th2SVG implementiert.
7.2.5.3
Graphikdaten
Nach dem in Kapitel 6.2.3 formulierten Konzept werden Graphikdaten in einer CSS-Datei
gespeichert und während der Datenwiedergabe von den einzelnen Objektgeometrien
abgefragt. Dies ist besonders für die Realisierung der hybriden Kartengraphik praktisch,
weil die in unterschiedlichen Kartensegmenten eingeordneten Objekte eines Kartenthemas
auf die gleichen Graphikdaten zugreifen. Somit verringert sich der Anteil redundanter
Daten und die einheitliche Themenwiedergabe ist sichergestellt.
74
Um die Kartengenerierung beziehungsweise das Karten-Rendering während der Nutzung
des Fahrradtouren-Navigationssystems zu beschleunigen, sind zunächst einige allgemeine
Eigenschaften des style-Attributs der verschiedenen Graphikobjekte festzulegen. Hauptziel
ist das Abschalten von Anti-Aliasing-Algorithmen, die in SVG standardmäßig
angewendeten werden. Diese dienen der Kantenglättung und erhöhen durch Farbübergänge
zwischen verschiedenfarbigen Kanten die Qualität der Kartendarstellung. Allerdings
verursachen die dafür notwendigen Prozesse einen zusätzlichen Rechenaufwand, unter
dem die Systemperformance auf dem PDA leidet. Deshalb findet eine Deaktivierung der
Algorithmen über folgende vom jeweiligen Graphikobjekt abhängige style-Eigenschaften
statt:
•
Rasterbilder:
image-rendering=”optimizeSpeed”,
•
Text:
text-rendering=”optimizeSpeed”,
•
Linie, Polygon, Pfad, etc.:
color-rendering=”optimizeSpeed”
shape-rendering=“optimizeSpeed“.
Für die Generierung der CSS-Datei entnimmt das Script th2SVG dem ArcView
Inhaltsverzeichnis die erforderlichen Informationen, wie beispielsweise Linienstärke,
Füllfarbe oder Umrissfarbe, und wandelt diese in CSS-Ausdrücke um. Während die
Datentransformation für einfache Linien- und Polygon-Themen leicht durchführbar ist,
bedingen Punkt- und Beschriftungsthemen den Gebrauch zusätzlicher Informationen und
Vorgänge.
In
der
tourspezifischen
Kartengraphik
symbolisieren
kleine
in
einem
Bildverarbeitungsprogramm erstellte PNG-Graphiken die Geometriedaten von Punkten
[vgl. Kapitel 7.2.1.5]. Da ArcView den direkten Export von Symbolen nicht unterstützt,
werden die externen PNG-Bilder als SVG-Symbole mit eindeutigem Identifikator
deklariert, wobei der Dateiname der Themenbezeichnung entspricht:
<symbol id="identifikator">
<image x="0" y="0" width="10" height="10" xlink:href="name.png"/>
</symbol>
Demnach sind lediglich die Symbolgraphik-Dateien namentlich anzupassen und in das
Verzeichnis der SVG-Graphik zu kopieren. Den Zugriff einer Punkt-Geometrie auf ein
SVG-Symbol ermöglicht der Ausdruck:
<use x="100" y="100" xlink:href="#identifikator"/>
Bei der Transformation von Beschriftungen stellt sich das Problem, dass diese in ArcView
als freie Graphiken vorliegen und nicht direkt abrufbar sind. Deswegen muss die
Generierung von Textelementen ausschließlich über die Themen der BeschriftungsGeometrien geschehen. th2SVG erkennt die entsprechenden Linien-Themen mit Hilfe der
dem Themennamen vorangestellten Kennung „txt“. Für die textliche Gestaltung kann über
75
Auswahlfelder die Schriftgröße, die Schriftdicke sowie der Schriftstil bestimmt werden.
Eine Selektion von Schriftarten ist für den mobilen Bereich wenig sinnvoll, da hier
generell nur wenige Schriftarten zur Verfügung stehen. Den eigentlichen Text entnimmt
th2SVG dem Objektattribut „Text“ und schreibt diesen mit Verweis auf die BeschriftungsGeometrie in die SVG-Datei:
<textPath xlink:href="#pfadname">beschriftung</textPath>
Für die richtige Interpretation der Kartenobjekte sieht das für die Graphikdaten entwickelte
Konzept eine externe Zeichenerklärung in Form einer SVG-Datei vor [vgl. Kapitel 6.2.3].
Zur Realisierung bildet das Script th2SVG eine weitere SVG-Graphik mit standardisierten
Objektgeometrien und den dazugehörigen Themenbezeichnungen. Dabei sind die
Geometriedaten mit den jeweiligen in der CSS-Datei abgelegten Style-Eigenschaften der
einzelnen Objektklassen verknüpft. Zusätzlich beinhaltet die Graphik einen Hinweis auf
den Übersichtsmaßstab sowie den gewählten maximalen Kartenmaßstab. Die aus den GeoDaten des Interessengebiets der Tour 149 resultierende Legende präsentiert Darstellung
7-14.
Darstellung 7-14: Legende der Kartengraphik.
Mit den erweiterten Funktionalitäten für den Export von Graphikdaten stellt das ArcViewScript th2SVG für alle Themen des in ArcView angepassten Datensatzes Möglichkeiten
zur Transformation in die systemspezifischen Formate SVG und CSS bereit. Dadurch ist
ein Anwender in der Lage, mit wenigen Interaktionen aus einem Datenbestand in ArcView
die hybride Kartengraphik der Daten-Komponente zu entwickeln. Das Ergebnis der
Umwandlung der tourspezifischen AOI ist in Darstellung 7-15 abgebildet.
76
Darstellung 7-15: Hybride Kartengraphik der Daten-Komponente.
7.2.6 Entwicklung der rasterbasierten Kartengraphik
Als
kleinmaßstäbige,
schematisierte
Situationsbeschreibung
im
FahrradtourenNavigationssystem dient eine rasterbasierte Kartengraphik [vgl. Kapitel 6.2.5], die aus
ArcView exportiert wird. Da eine Gesamtansicht des Interessengebiets der Tour 149 auf
dem PDA-Display einen Kartenmaßstab von 1:140000 erfordert, sind aus den
modifizierten Geo-Informationen in ArcView lediglich die für eine Darstellung in diesem
Maßstab relevanten Daten zu selektieren und graphisch anzupassen. Zur Ausgabe der
daraus resultierenden Graphik in diverse Raster-Formate stellt ArcView die Funktion
„Exportieren“ bereit. Leider wird ausschließlich der gesamte im Ansichten-Fenster
enthaltene Kartenteil transformiert, so dass die exakte Anpassung der Rastergraphik an die
AOI eine Nachbearbeitung in einem entsprechenden Bildverarbeitungsprogramm, wie zum
Beispiel Corel Photo Paint 11, notwendig macht. Die endgültige Speicherung der
Rasterdaten findet im komprimierten Bildformat PNG statt. Das Ergebnis der
Rastergraphik-Generierung zeigt Darstellung 7-16.
77
Darstellung 7-16: Rastergraphik der Daten-Komponente.
7.2.7 Integration der Positionsangabe
Die zur Integration der Standortangabe in die Kartengraphik des FahrradtourenNavigationssystems notwendigen Schritte werden im Rahmen der prototypischen
Systemimplementierung manuell, unter Verwendung des Texteditors EditPLus2 [vgl.
Kapitel 5.2] durchgeführt und setzen eine mit dem ArcView-Script th2SVG erstellte SVGDatei voraus.
Als erstes stellt sich die Aufgabe einen effizienten Algorithmus für die Transformation der
von der Positions-Komponente in einer XML-Datei abgelegten ellipsoidischen
geographischen Koordinaten ϕ und λ in das ebene Koordinatensystem der SVGKartengraphik mit XSVG und YSVG zu finden. Da eine exakte Koordinatenumwandlung
nicht ohne aufwändige Berechnungen möglich ist, wird ein zweidimensionaler affiner
Ansatz gewählt. Dieser ist zwar aus mathematischer Sicht ungeeignet, liefert aber für das
relativ kleine Interessengebiet der Tour 149, unter Annahme eines ebenen dϕ,dλKoordinatensystems, ausreichend genaue Ergebnisse. Als Ursprung des dϕ,dλ-Systems
wird der Ursprung der Kartengraphik deklariert, wodurch sich dϕ,dλ-Koordinaten aus der
Differenz zwischen den geographischen Koordinaten eines beliebigen Punkts und dem
oberen linken AOI-Eckpunkt ergeben. Darstellung 7-17 zeigt die Ausgangssituation.
78
ϕ
λ
XSVG
YSVG
Darstellung 7-17: SVG und ϕ,λ-Koordinatensystem.
Eine Affin-Transformation beinhaltet die 6 geometrischen Parameter Skalierung in dϕRichtung mdϕ, Skalierung in dλ-Richtung mdλ, Rotationswinkel der dϕ-Achse α,
Rotationswinkel der dλ-Achse β, Verschiebung in X-Richtung X0 sowie Verschiebung in
Y-Richtung Y0 [NIEMEIER, 2002]. Mathematisch ausgedrückt stellt sich die Situation wie
folgt dar:
XSVG [px] = X0 + mdϕ (cos α) dϕ [°] – mdλ (sin β) dλ [°],
YSVG [px] = Y0 + mdϕ (sin α) dϕ [°] + mdλ (cos β) dλ [°].
Durch den Einsatz von Koeffizienten lassen sich die Gleichungen vereinfachen zu:
XSVG [px]= a1 + a2 dϕ [°]+ a3 dλ [°],
YSVG [px]= a4 + a5 dϕ [°]+ a6 dλ [°].
Somit werden für die effiziente affine Koordinatentransformation die Koeffizienten a1 bis
a6 benötigt. Diese lassen sich über in beiden Koordinatensystemen bekannte Punkte mittels
einer Ausgleichung nach vermittelnden Beobachtungen berechnen. Als Punkte bieten sich
die vier bereits im SVG- und G-K-System bekannten Karten- beziehungsweise AOIEckpunkte an. Vier zusätzlich gewählte, gleichmäßig im Kartenbereich verteilte Punkte
erhöhen die Qualität der Parameterbestimmung und werden unter Nutzung der für die
Umwandlung der Geometriedaten aus dem G-K-System in das SVG-System aufgestellten
Formeln und Konstanten [vgl. Kapitel 7.2.5.2] in das G-K-System transformiert. Durch die
Verwendung eines im Internet frei verfügbaren Programmwerkzeugs zur Umrechnung von
Koordinaten zwischen verschiedenen Systemen, wie zum Beispiel das in Darstellung 7-18
abgebildete KSDTrans [SINGER, 2003], können die G-K-Koordinaten der 8 Punkte in
geographische Koordinaten umgerechnet werden.
Damit sind alle für die Ausgleichung erforderlichen Daten bekannt, so dass sich die 6
Koeffizienten der affinen Transformation bestimmen lassen. Eine höheren Gewichtung der
Randpunkte im Ausgleichungsalgorithmus bewirkt das gleichmäßige Einpassen des dϕ,dλSystems in das SVG-System, wodurch die Abweichung zwischen einem Soll-Wert und
einem über die Koeffizienten errechneten Ist-Wert im gesamten Interessengebiet nahezu
gleich bleibt. Auf die umfangreichen Kalkulationen der vermittelnden Ausgleichung soll
79
an dieser Stelle nicht eingegangen werden. Eine detaillierte Beschreibung ist aber dem
Anhang beigefügt.
Darstellung 7-18: Benutzeroberfläche von KSDTrans.
Aus den Ergebnissen der Ausgleichung ergeben sich die Formeln der kartenspezifischen
Koordinatentransformation zu:
XSVG [px] = -2,1 + 40562,44 dϕ [°] − 709,87 dλ [°],
YSVG [px] = 0,1 – 434,53 dϕ [°] − 66231,85 dλ [°].
Dabei ist die Genauigkeit der affinen Transformation mit einer maximalen Abweichung
zwischen Soll- und Ist-Wert von zwei Pixeln beziehungsweise 0,5 Millimetern in der
Kartengraphik für den Gebrauch im Fahrradtouren-Navigationssystem absolut ausreichend.
Die Abfrage der im XML-Format gespeicherten Standortkoordinaten und die
anschließende Transformation dieser in das SVG-Koordinatensystem erfolgt über die, in
Javascript [vgl. Kapitel 5.4] formulierte und in einem externen Script abgelegte Funktion
load(obj).
Dabei
liegen
die
Positionsdaten
mit
dem
Ausdruck
<pos>52.374360,9.740327</pos> in einer XML-Datei obj vor [s.Kapitel 7.4]. Für die Abfrage
der Daten besitzt load(obj) die Befehlszeilen:
frag = parseXML(obj.content, svgDocument);
theString=frag.firstChild.firstChild.getData();
s=theString.split(",");
breite=s[0];
laenge=s[1];
parseXML(...)
zerlegt den Inhalt der Datei in seine XML-Bestandteile, wodurch mit
die Daten des XML-Elements <pos> abfragbar sind. Aus der
firstChild.firstChild.getData()
80
Anwendung der Funktion split() im Bezug auf das Trennzeichen „,“ergeben sich die
separaten geographischen Koordinaten breite und laenge. Nach Bildung der
Koordinatendifferenzen zum Ursprung des dϕ,dλ-Systems werden die SVG-Koordinaten
über die Gleichungen der Affin-Transformation berechnet. Durch den Javascript-Befehl
getURL("name.xml",load) lässt sich die Funktion load(obj) auf eine beliebige XML-Datei
anwenden. Infolge der für Navigationszwecke notwendigen permanenten Aktualisierung
des Standpunkts wird load(obj) in regelmäßigen Zeitintervallen von 10 Sekunden
ausgeführt. Dieser Wert entspricht unter Annahme einer Fahrgeschwindigkeit von 25 km/h
einer Positionsveränderung von 7 Millimeter in der Kartengraphik 1:10000 und reicht
demzufolge für die Fahrradnavigation aus.
Bei der Integration der Positionsangabe können verschiedene Systemfehler auftreten, die
mit geeigneten Methoden zu vermeiden sind. Der Datenzugriff scheitert beispielsweise,
wenn die Positions-Komponente gleichzeitig die XML-Datei modifiziert, so dass während
der anschließenden Koordinatenberechnung ein Fehler entsteht, der den Systemablauf
unterbricht. Dieser Effekt tritt auch bei fehlerhaften Informationen in der XML-Datei auf.
Ein in der Funktion load(obj) deklarierter Test der Variablen breite und laenge auf ihren
numerischen Inhalt und einem vom Testergebnis abhängigen Funktionsabbruch schafft in
beiden Fällen Abhilfe:
if (isNaN(breite)||isNaN(laenge)) return;
Des Weiteren erreicht die Eingrenzung der, aus der Transformation resultierenden SVGKoordinaten auf das Gebiet der Kartengraphik ein Herausfiltern großer numerischer
Koordinatenfehler.
Zur graphischen Darstellung des Standorts wird die SVG-Datei der Kartengraphik um ein
einfaches Kreisobjekt erweitert, das die über load(obj) berechneten Koordinaten zugewiesen
bekommt. Die visuellen Ausmaße des Objekts sind zweckmäßig über alle
Kartenskalierungen hinweg konstant. Eine exemplarische Positionswiedergabe in der
Kartengraphik demonstriert Darstellung 7-19.
Standort
Darstellung 7-19: Wiedergabe der Standortangabe in der Kartengraphik.
81
7.3 Entwicklung der User-Interface-Komponente
Wie in Kapitel 6.3 erläutert, dient die User-Interface-Komponente der Steuerung des
Fahrradtouren-Navigationssystems. Sie gliedert sich in die graphische Benutzeroberfläche
und den für dynamische Vorgänge notwendigen Javascript-Prozeduren. Das Starten
beziehungsweise Beenden der einzelnen Funktionen verläuft über die jeweiligen
Kontrollsegmente der GUI. Als Entwicklungsumgebung der Systemkomponente dient der
Texteditor EditPlus2 [vgl. Kapitel 5.2].
7.3.1 Benutzeroberfläche
Da Interaktionen das Ansprechen einzelner GUI-Objekte durch den Anwender
voraussetzen, wird zur Generierung der Benutzeroberfläche eine übergeordnete SVGGraphik (äußeres SVG) implementiert, die unter anderem die hybride Kartengraphik
(inneres SVG) sowie mehrere Steuerelemente einschließt. Das äußere SVG erhält als
Ausmaß den maximal zur Verfügung stehenden Ansichtsbereich des PDA-Displays, der
unter Nutzung des eSVG-Viewers [vgl. Kapitel 3.3.8] 240 x 270 Pixel beträgt. Um eine
Verschiebung oder Skalierung der GUI-Graphik über, vom Viewer bereitgestellte
Funktionalitäten zu verhindern, ist dem äußeren SVG das Attribut zoomAndPan=“Disable“
zugeordnet, welches die entsprechenden Prozesse deaktiviert. Die innere SVG-Graphik
wird aufgrund ihrer herausragenden Bedeutung als Informationsträger ohne Skalierung in
die GUI eingepasst und mit einem Identifikator ausgestattet, der ein direktes Ansprechen
von Objekten der SVG-Kartengraphik erlaubt. In dem verbleibenden Bereich der GUIGraphik sind Steuerelemente in Form von einfachen PNG-Bildern positioniert, mit denen
sich in Anlehnung an das aufgestellte Konzept der User-Interface-Komponente aus Kapitel
6.3 Zoom-, Pan- sowie Ortungs-Prozeduren bedienen lassen. Ein weiteres Symbol
ermöglicht den Aufruf der externen zeichenerklärenden SVG-Graphik. Grundsätzlich
werden deaktivierte beziehungsweise nicht verfügbare Schaltflächen durch eine
abgedunkelte Abbildung kenntlich gemacht. Das Resultat der anwendungsspezifischen
Entwicklung der Benutzeroberfläche ist der Darstellung 7-20 zu entnehmen.
Kartengraphik
Zusatzinfo
ZoomOut
GPS On/Off
ZoomIn
Zentrierung On/Off
Pan
Legende
Darstellung 7-20: Benutzeroberfläche des Fahrradtouren-Navigationssystems.
82
7.3.2 Interaktionen
Zu den vom Anwender steuerbaren, dynamischen Vorgängen gehören das Skalieren
(Zoom), das Verschieben (Pan), das Anzeigen des Standorts, die automatische Zentrierung
auf den Standort sowie das Anzeigen von erklärenden und beschreibenden
Zusatzinformationen (Darstellung 7-20). Zur Entwicklung der dafür erforderlichen
Prozeduren sind zunächst einige fundamentale Festlegungen zu treffen.
Das Konzept des Fahrradtouren-Navigationssystems sieht in Abhängigkeit vom aktuellen
Kartenmaßstab eine Wiedergabe der rasterorientierten oder der hybriden Kartengraphik
vor [vgl. Kapitel 6.3]. Darum wird die Rastergraphik als neues Objekt in die
Hybridgraphik, dem inneren SVG, integriert und exakt über die gesamte Graphik gelegt.
Jetzt erreicht eine Zuweisung des Ausdrucks display="none" an alle die Grids
präsentierenden SVG-Gruppen ein vollständiges Auslassen der hybriden Graphik während
der Kartenzeichnung, so dass lediglich die Rastergraphik sichtbar ist. Dieser Zustand
entspricht der Ausgangssituation der Kartengraphik nach dem Start des
Navigationssystems, das zweckmäßig zunächst eine Gesamtübersicht des Interessengebiets
wiedergibt.
Für die dynamische Situationswiedergabe im Maßstab 1:140000 bis 1:10000 stehen 4
Zoomstufen mit konstantem Skalierungsfaktor zur Verfügung, wobei in Stufe 1 und 2 die
rasterbasierte, in Stufe 3 und 4 die hybride Kartengraphik dargestellt wird. Der Anwender
wählt durch Anklicken der Zoom-Symbole auf der GUI den gewünschten Maßstab aus.
Den mit der ZoomIn-Kontrolle zu skalierenden Bereich definiert ein in der Kartengraphik
angeklickter Punkt. Bezüglich des konzeptionellen Aufbaus der Daten-Komponente sind
für das Anzeigen der Hybridgraphik lediglich die vier im Display sichtbaren Grids zu
aktivieren [vgl. Kapitel 6.2.5]. Deshalb bedingt ein Wechsel von der rasterbasierten in die
hybride Graphik eine Bestimmung der um den selektierten Kartenpunkt liegenden Grids.
Diese können aufgrund der Deklaration numerischer Grid-Identifikatoren [vgl. Kapitel
7.2.5.1] und der bekannten Gridgröße über mathematische Formeln berechnet werden. Mit
dem Setzen des Attributs display der sich so ergebenden SVG-Gruppen auf „inline“ und dem
gleichzeitigen Ausschalten der Rastergraphik entsteht die geforderte Kartengraphik. In
umgekehrter Richtung vollzieht sich der Übergang von Zoomstufe 3 in Zoomstufe 2 unter
der Deaktivierung der vier Grids und dem Einschalten der Rastergraphik.
Eine weitere Möglichkeit der Gebietsauswahl bieten die Pan-Kontrollen Oben, Unten,
Links und Rechts, welche die Kartengraphik in die entsprechende Richtung verschieben.
Hierbei wird in den Zoomstufen 3 und 4 mit Hilfe mathematischer Gleichungen überprüft,
ob die aktivierten Grids der hybriden Graphik den sichtbaren Kartenteil vollständig
überdecken. Bei Bedarf sind über das Attribut display die nicht mehr in der Kartenansicht
enthaltenen Grids auszuschalten und die notwendigen Kartenteile anzuzeigen.
Die Integration der Standortangabe kontrolliert der Anwender über die GUI-Elemente GPS
On/Off und Zentrierung On/Off. Ein Anklicken des GPS On/Off-Symbols startet
beziehungsweise beendet den Prozess der Koordinatenabfrage und –umwandlung [vgl.
Kapitel 7.2.7] sowie die Darstellung der Position in der Kartengraphik. Aus dem
Anklicken der Schaltfläche Zentrierung On/Off resultiert ein automatisches Ausrichten der
83
Karte auf den aktuellen Standort, der sich somit immer im Mittelpunkt der Kartenansicht
befindet. Zur Realisierung werden die bereits beschriebenen Zoom- und PanFunktionalitäten mit Bezugnahme auf die Standortkoordinaten angewendet.
Durch die Einbindung der zeichenerklärenden SVG-Datei in eine HTML-Datei ist das
Aufrufen dieser über einen mit dem Legenden-Symbol verbundenen einfachen Hyperlink
möglich. Somit erfolgt neben der Wiedergabe von Zusatzinformationen der POIs [vgl.
Kapitel 7.2.4] auch die Anzeige der Legende über einen externen HTML-Viewer.
Sämtliche, für die interaktiven Vorgänge notwendigen Prozeduren sind in Javascript [vgl.
Kapitel 5.4] implementiert und in einem externen Script abgelegt. Eventhandler, die den
GUI-Objekten zugeordnet werden, starten beim Eintritt eines vordefinierten Ereignisses, in
der Regel ein Klick, die ihr zugewiesenen Funktionen. Somit ist ein Anwender befähigt,
über die Benutzeroberfläche der User-Interface-Komponente den Systemablauf individuell
zu steuern.
7.4 Entwicklung der Positions-Komponente
Nach der Fertigstellung der Daten- sowie der User-Interface-Komponente des
Navigationssystems ist schließlich eine Stand-Alone-Applikation zu entwickeln, welche
die XML-Datei mit den Positionskoordinaten in bestimmten Zeitintervallen und unter
Auswertung der vom GPS-Empfänger ausgegebenen Daten aktualisiert. Dazu wird eine
eVB-Anwendung GPSLog unter Nutzung der Programmierumgebung eVB-Tools 3.0 [vgl.
Kapitel 5.3.3] implementiert.
Shape
Label
Command
ComboBox
Button
TextBox
FileSystemControl
Comm-Control
File-Control
Timer-Control
sichtbar
unsichtbar
Darstellung 7-21: Programmlayout der Positions-Komponente GPSLog.
84
Die Erstellung von GPSLog erfordert zunächst eine Gestaltung des geometrischen
Programmlayouts im Form-Fenster von eVB-Tools. Dieses setzt sich, wie die Darstellung
7-21 zeigt, aus diversen für den Anwender sichtbaren und unsichtbaren Steuerelementen
zusammen. Dabei bilden die sichtbaren Objekte die Benutzeroberfläche der Applikation.
In der Form sind Eingabefelder, wie zum Beispiel Textboxen oder ComboBoxen, so zu
positionieren, dass sie von der zur Zeicheneingabe erforderlichen visuellen PDA-Tastatur
nicht überdeckt werden. Mit Hilfe der unsichtbaren Elemente lassen sich Zugriffe auf
Schnittstellen, Dateien und Verzeichnisse oder Zeitgeber einfach realisieren. Durch
Kombination der einzelnen graphischen Steuerelemente mit zweckmäßigen im CodeFenster deklarierten Ereignisprozeduren entstehen die Programmfunktionalitäten.
Für die individuelle Konfiguration der Applikation stehen die verschiedensten
Eingabefelder zur Verfügung. Der Anwender kann den seriellen Anschluss und die
Datenübertragungsrate des GPS-Empfängers, das Zeitintervall der Datenaktualisierung in
Sekunden sowie das Verzeichnis und den Namen der Ausgabedatei wählen. Das
eigentliche Starten und Beenden der Prozeduren für den Datenempfang und der
Datenausgabe findet über die Schaltflächen Start und Stop statt (Darstellung 7-22).
Darstellung 7-22: Benutzeroberfläche der Positions-Komponente GPSLog.
Unter Verwendung der selektierten Konfigurationsparameter stellt sich der eigentliche
Programmablauf wie folgt dar:
Zum Registrieren der GPS-Datensätze mit den Formaten GGA, GSA, GSV und RMC [vgl.
Kapitel 4.2.2] öffnet die Comm-Control den seriellen Anschluss und legt die vom GPSEmpfänger ausgegebenen Daten in einer Variablen str ab. Die Verbindung wird wieder
getrennt, sofern str mehr als 325 Zeichen und somit mindestens eines der beiden Positionsbeschreibenden Formate GGA und RMC vollständig beinhaltet. Östlich des Nullmeridians
(Meridian von Greenwich) kann die Position der geographischen Koordinaten Länge und
Breite innerhalb von str eindeutig über den Identifikator „,E,“ festgestellt werden, wobei
die 23 davor stehenden Zeichen die Positionskoordinaten wiedergeben. Nach Selektion
85
und Separation der Daten sind die in einem Sexagesimalsystem (Grad und Minute)
vorliegenden Koordinaten in ein Dezimalsystem (Grad) umzuwandeln. Das Resultat
speichert die File-Control mit den notwendigen XML-Deklarationen in der ausgewählten
XML-Datei ab. Dabei informiert ein kurzes Anzeigen des ansonsten unsichtbaren Shapes
auf der Benutzeroberfläche den Anwender über die Aktualisierung der Standortangabe.
Der gesamte hier erläuterte Vorgang wird mittels der Timer-Control in den vorgegebenen
Zeitabständen wiederholt.
Nachdem die zum Programmablauf erforderlichen Ereignisprozeduren der jeweiligen
Kontrollelemente komplett in eVB-Tools deklariert sind, wird mit Hilfe des Tools
Application Install Wizard eine Setup-Anwendung generiert. Dieses ermöglicht die
automatisierte Programminstallation auf der Zielplattform, dem PDA, so dass die
entwickelte Applikation als Positions-Komponente des Fahrradtouren-Navigationssystems
eingesetzt werden kann.
8 Systemtest
86
8 Systemtest
Dieses Kapitel überprüft das in Kapitel 7 implementierte Fahrradtouren-Navigationssystem
für den Geolife Fahrradtourenvorschlag 149 hinsichtlich der Systemperformance, der
Anwenderfreundlichkeit sowie der Zuverlässigkeit. Dafür werden die entwickelten
beziehungsweise vorausgesetzten Software-basierten Systemkomponenten mit den in
Kapitel 4 vorgestellten Hardwarebestandteilen PDA HP iPAQ H5450 und GPS-Empfänger
Holux GM-270 CF kombiniert. Angesichts des fehlenden Adapters für die Befestigung des
PDAs an einem Fahrradlenker findet der Systemtest im Rahmen einer Feldbegehung statt.
Dadurch können keine Aussagen betreffend der Systemperformance während einer
Tourbefahrung getroffen werden.
Das Programmpaket erweist sich mit einem Datenvolumen von ungefähr 5 Megabyte als
äußerst kompakt und lässt sich problemlos über die Synchronisationssoftware Microsoft
ActiveSync [vgl. Kapitel 4.1.1] von einem stationären PC auf den PDA übertragen.
Nach Erreichen des Interessengebiets der Tour 149 ist zunächst die Positions-Komponente
GPSLog aufzurufen und über die Eingabefelder zu konfigurieren. Dabei wird für den
Systemtest eine Aktualisierungsrate der Standortdaten von 2 Sekunden festgelegt, die eine
zeitnahe Anzeige der ermittelten Position sicherstellt. Im Anschluss erfolgt der eigentliche
Programmstart von GPSLog, wobei das während der Datenspeicherung aufleuchtende
Punkt-Shape Gewissheit gibt, dass bei den im Hintergrund ablaufenden Prozessen kein
Fehler auftritt. Abgeschlossen wird die Einrichtung des Navigationssystems durch Aufruf
der tourspezifischen SVG-Datei unter Nutzung des eSVG-Viewers.
Dank des transflektiven PDA-Displays [vgl. Kapitel 4.1] erscheint
Datenwiedergabe auch bei wechselnden Lichtverhältnissen klar und eindeutig.
die
visuelle
Als sehr sinnvoll ist die einfache, nahezu selbsterklärende Gestaltung der
Benutzeroberfläche
des
Navigationssystems
und
das
Abdunkeln
deaktivierter
Schaltflächen zu betrachten, da somit auch der ungeübte Anwender die Handhabung sehr
schnell erlernen kann. Die für eine dynamische Informationswiedergabe bereitgestellten
Zoom-, Pan-, Ortungs- und Beschreibungs-Funktionalitäten wirken für den allgemeinen
touristischen Gebrauch zufrieden stellend. Allerdings laufen ausgeführte Prozesse, wie
zum Beispiel das Kartenzoomen, trotz der expliziten Ausrichtung des Systems auf eine
beschleunigte Performance leicht verzögert ab.
Durch die verschiedenen adaptiven Zoomstufen, abgebildet in Darstellung 8-1, wird die
räumliche Situation maßstabsgerecht im Kartenbereich wiedergegeben. Demgemäss ist ein
Nutzer in der Lage, sich zu jedem Zeitpunkt mit Hilfe der Zoom- und Pan-Schaltflächen
umfassend zu orientieren. Der Zugriff auf die HTML-Seiten der POIs gelingt über das
Anklicken der entsprechenden Symbole in der Kartengraphik ohne Komplikationen.
Automatisch öffnet sich der Pocket Internet Explorer und zeigt die objektspezifischen
Informationen an.
8 Systemtest
87
Zoom 1
Zoom 2
Zoom 3
Zoom 4
Darstellung 8-1: Zoomstufen des Fahrradtouren-Navigationssystems.
Mit der Einbeziehung des aktuellen Standorts in die Kartengraphik erfüllt das System die
fundamentale Aufgabe der positionsabhängigen Situationsbeschreibung. Aufgrund der
markanten Form- und Farbgebung für die bedeutenden Kartenobjekte der Standort- als
auch der Tourangabe sind diese leicht zu identifizieren. Dies gestattet einem ortsfremden
Nutzer seine Fahrradtour individuell zu gestalten, ohne dass die Orientierung bezüglich der
originären Wegführung verloren geht.
Aus subjektiver Sicht stimmte die angezeigte Position während der gesamten
Feldbegehung mit dem Standort in der realen Welt überein. Lediglich in stark
abgeschatteten Bereichen, wie beispielsweise dicht bebauten Wohngebieten, konnten
geringe Abweichungen von 1 bis 2 Millimetern in der Kartengraphik festgestellt werden.
Schlussfolgernd liefert der Holux GM-270 CF auch bei eingeschränkter Sicht zum Himmel
gute Messwerte. Des Weiteren zeigt das Ergebnis, dass zur Umwandlung der
geographischen Koordinaten in kartenbasierte Koordinaten ein affiner Ansatz absolut
ausreichend ist. Exemplarisch gibt Darstellung 8-2 die reale und die abstrahierte Situation
am Startpunkt der Tour wieder.
Kritischer Punkt des Navigationssystems ist die maximale Systemlaufzeit. Der
Energiespeicher der eingesetzten Hardware erlaubt lediglich eine kontinuierliche
Betriebsdauer von 4 ½ Stunden. Dieser Wert genügt zwar den Anforderungen einer
Befahrung der Tour 149, kann aber auf längeren Strecken problematisch werden.
8 Systemtest
88
Darstellung 8-2: Startpunkt des GeoLife Fahrradtourenvorschlags 149.
Insgesamt betrachtet präsentiert sich das Fahrradtouren-Navigationssystem als sehr
komfortable Unterstützung bei der Lösung raumbezogener Fragen. Der Anwender hat
jederzeit die Möglichkeit, Informationen über seinen Standort, den Tourweg oder andere
interessante Aspekte abzufragen.
8 Systemtest
89
9 Bewertung
Auf Basis der aus der Implementierung und dem Test des FahrradtourenNavigationssystems gewonnenen Erkenntnisse wird in diesem Kapitel die Zweckmäßigkeit
der entwickelten Konzepte beurteilt.
Insgesamt zeigen die erzielten Ergebnisse, dass trotz der begrenzten Rechen- und
Speicherkapazitäten eines PDAs und den hohen Systemanforderungen [vgl. Kapitel 2] eine
zufrieden stellende mobile Lösung auf dem Gebiet der Fahrradtourennavigation
realisierbar ist. Die verschiedenen Bestandteile sind optimal aufeinander abgestimmt und
gewährleisten den komplikationsfreien Systemablauf. Als kritisch erweist sich lediglich die
leicht verzögerte Ausführung rechenintensiver Abläufe, wie zum Beispiel das Zoomen,
wobei mit der Weiterentwicklung mobiler Endgeräte eine deutliche Abschwächung dieses
Effekts zu erwarten ist.
Zur Anpassung des originären Geo-Datenbestands an den mobilen Gebrauch bietet die
GIS-Software ArcView 3.2 in Kombination mit zusätzlichen Erweiterungen umfangreiche
Optionen. Unter der Verwendung von Generalisierungsverfahren, wie beispielsweise
Klassifizierung, Vereinfachung oder Zusammenfassung, reduziert sich der bei der
Generierung der Daten-Komponente zu berücksichtigende Informationsgehalt auf die
tourrelevanten Daten. Im Rahmen der anwendungsspezifischen Implementierung wurden
sämtliche Generalisierungsvorgänge manuell durchgeführt beziehungsweise gesteuert [vgl.
Kapitel 7.2]. Demnach könnte die Entwicklung automatisierender Scripte den
Erstellungsprozess
des
angepassten
Datenbestands
deutlich
vereinfachen
und
beschleunigen.
Darstellung 9-1: Wiedergabe von Flächenobjekten mit Umrandung.
Die Bildung der digitalen Karte in Abhängigkeit vom Kartenmaßstab aus einer hybriden
SVG- oder einer rasterbasierten PNG-Graphik hat sich als sehr effizient erwiesen. Da
maximal 4 Grids der aus 36 Kartenteilen bestehenden anwendungsspezifischen
8 Systemtest
90
Hybridgraphik gleichzeitig angezeigt werden, verringert sich das auszuwertende
Datenvolumen im Vergleich zu einer herkömmlichen SVG-Vektorgraphik um 89 Prozent.
Somit ist die großmaßstäbige Situationswiedergabe trotz des hohen Detaillierungsgrads mit
akzeptablen Berechnungszeiten möglich. Allerdings treten bei der Umsetzung der hybriden
Strategie in SVG auch einige Probleme auf. Wie aus Darstellung 9-1 ersichtlich, werden
graphische Flächenobjekte, die sich über zwei oder mehr Grids erstrecken und eine
Umrandung beinhalten, aufgrund der Trennung in separate Teilobjekte mit einem Umriss
entlang der Gridgrenze präsentiert. Abhilfe schafft ausschließlich die Vermeidung solcher
Umrandungssignaturen oder eine Überzeichnung des betroffenen Objekt-Grenzabschnitts
mit einer Linie in Objektfüllfarbe.
Einen weiteren Konflikt zeigt Darstellung 9-2. Bei der Wiedergabe von Textsignaturen
grenznaher Beschriftungslinien wird der über das Grid hinaus gehende Objektteil durch
das
nachfolgende
Grid
überzeichnet.
Die
Folge
ist
eine
unvollständige
Informationsdarstellung.
Zur
Vermeidung
des
Effekts
müssen
entsprechende
Beschriftungslinien während der Generierung der Hybridgraphik ausgelassen oder
verschoben werden, wobei ein einfacher, automatisierter Abstandstest zwischen den
Beschriftungsobjekten und der Gridgrenze das Auffinden der zu berücksichtigenden
Elemente übernehmen kann.
Darstellung 9-2: Wiedergabe von Beschriftungsobjekten nahe der Gridgrenze.
Der Einsatz von SVG als fundamentales Graphikformat im FahrradtourenNavigationssystem hat sich wegen der unzähligen unkomplizierten Gestaltungs- und
Interaktionsmöglichkeiten bewährt. Den einzigen signifikanten Schwachpunkt stellt die
ungenügende Unterstützung von Mustersignaturen dar, wodurch die kartographische
Objektgestaltung eingeschränkt wird. Hinsichtlich der Speicherung und Verwaltung von
raumbezogenen, in der Beschaffung sehr teuren Daten besitzt SVG derzeit den Nachteil,
dass sämtliche, in textbasiertem Quellcode abgelegte Informationen frei zugänglich und
weiterverwendbar sind. Die Situation wird sich aber mit der neuen SVG-Version 1.2
deutlich verbessern, da diese, nach Aussagen des W3Cs, über einen expliziten Datenschutz
verfügen soll.
8 Systemtest
91
Zur kompakten Speicherung rasterbasierter Informationen, wie die kleinmaßstäbige
Kartengraphik oder die diversen Kartensymbole, eignet sich besonders das PNGGraphikformat. Dieses besitzt gegenüber JPEG den Vorteil, Daten ohne Qualitäts- und
Informationsverlust zu komprimieren. Darüber hinaus ergab sich im Rahmen der
Systementwicklung bei der Speicherung von Graphiken mit geringer Farbtiefe ein um bis
zu 35 Prozent niedrigeres Datenvolumen. Im Vergleich zum ebenfalls verlustfrei
komprimierenden GIF-Graphikformat werden mit PNG, infolge des komplexeren
Kompressionsverfahrens, deutlich bessere Resultate erzielt [NOACK, 2002B].
Als sehr sinnvoll stellt sich die Speicherung der erläuternden POI-Informationen in
unabhängigen HTML-Seiten und das Aufrufen dieser über graphische Symbole in der
Kartengraphik heraus. Zum einen belasten die Daten das Kartenbild nicht zusätzlich, zum
anderen erlaubt das HTML-Format eine Integration umfassender Daten unterschiedlichen
Typs. Damit sind der Einbeziehung von POI-Sachinformationen nahezu keine Grenzen
gesetzt.
Im Hinblick auf eine Integration der Standortangabe in die Kartengraphik zeigt die
tourspezifische Implementierung, dass in kleineren Interessengebieten zur Transformation
geographischer Koordinaten in ebene SVG-Koordinaten ein affiner Ansatz ausreichend
genaue Ergebnisse liefert. Demzufolge kann bei Navigationssystemen für Fahrradtouren
im Allgemeinen auf einen vollständigen, rechenintensiven Transformationsansatz
verzichtet werden.
Die aus SVG-Graphikelementen und Javascript-Prozeduren aufgebaute User-InterfaceKomponente wird der Aufgabe der interaktiven Informationsübertragung zwischen Nutzer
und Navigationssystem gerecht. Über die visuelle Benutzeroberfläche lassen sich alle
dynamischen Vorgänge des Systems mit Hilfe geeigneter Schaltflächen und Symbole
leicht steuern. Um die Anwenderfreundlichkeit des Navigationssystems weiter zu steigern,
könnten die wenigen Eingabetasten des PDAs [vgl. Kapitel 4.1.2] mit den wichtigsten
Funktionen, wie Zoom und Pan, verknüpft werden. Der Nutzer wäre so in der Lage, auch
ohne Eingabestift grundlegende Vorgänge zu kontrollieren.
Das als unabhängige Positions-Komponente entwickelte eVB-Programm GPSLog ist durch
die flexible Applikationsgestaltung mit diversen GPS-Empfängern kombinierbar. Während
des gesamten Systemtests liefen die softwareinternen Prozesse sehr zuverlässig und
störungsfrei ab. Demgemäß präsentiert GPSLog eine optimale Lösung zur Umwandlung
der vom GPS-Receiver ausgegebenen Standortangabe in das erforderliche Datenformat
XML.
Zusammenfassend zeigen die im Rahmen dieser Arbeit konzipierten und entwickelten
System-Komponenten, dass ungeachtet der begrenzten Kapazitäten mobiler Endgeräte
kompakte, leistungsfähige, komfortable Systeme für die Fahrradtouren-Navigation
realisierbar sind. Allerdings bleibt abzuwarten, inwiefern sich vergleichbare Anwendungen
auf dem freien Markt durchsetzen werden.
10
Zusammenfassung und Ausblick
92
10 Zusammenfassung und Ausblick
Bisher nutzten Fahrradtouristen für die Routenführung überwiegend analoge
Radwanderkarten, die den Bedarf an situationsbeschreibenden Informationen nur
eingeschränkt decken und in der Handhabung relativ unkomfortabel wirken. Heute bieten
sich infolge der Weiterentwicklung mobiler Endgeräte neue Möglichkeiten,
computergestützte anwenderfreundliche Navigationssysteme, die sich exemplarisch schon
in der Fahrzeugführung bewährt haben, auch für Fahrradtouren bereitzustellen.
Diese Arbeit beschäftigt sich mit der Konzeption und Entwicklung eines umfassenden
Fahrradtouren-Navigationssystems für GPS-gestützte PDA-Geräte mit dem Betriebssystem
Microsoft Windows CE. Ausgangspunkt der Untersuchungen ist eine vordefinierte Route,
die zum Beispiel über einen stationären Desktop ausgewählt werden kann. Besondere
Berücksichtigung gilt der Behandlung von raumbezogenen Daten, der Einbeziehung von
Standortangaben sowie der Integration von Informationen touristischer Interessenpunkte.
Anhand einer tourspezifischen Implementierung wird die Leistungsfähigkeit der
aufgestellten Strategien überprüft.
Der Konzeptionsteil geht zunächst auf die allgemeine Systemarchitektur und die
Aufteilung des Systems in einzelne Bestandteile ein. In der Daten-Komponente sind
sämtliche Geo-Informationen unter Verwendung der Standardformate SVG, CSS, HTML,
XML und PNG organisiert. Zur effizienten adaptiven Situationswiedergabe werden eine
detaillierte hybride und eine schematische rasterorientierte Datenstruktur generiert. Da im
Allgemeinen der verfügbare originäre Geo-Datenbestand in einem GIS vorliegt und nicht
den Anforderungen des Navigationssystems entspricht, ist dieser zweckmäßig anzupassen
und anschließend in die Formate der Daten-Komponente umzuwandeln. Die entworfene
User-Interface-Komponente steuert Interaktionen zwischen Navigationssystem und
Anwender und enthält eine graphische Benutzeroberfläche in SVG sowie diverse, zur
Ausführung dynamischer Vorgänge zuständige Javascript-Prozeduren. Für die
Verarbeitung des Standortkontextes erfolgt die Aufstellung einer Positions-Komponente in
Form einer unabhängigen eVB-Applikation.
Bei der anwendungsspezifischen Implementierung wird die Systemarchitektur mit den
konzeptionellen System-Komponenten in den festgelegten Datenformaten und
Programmiersprachen
umgesetzt.
Exemplarische
Tour
ist
der
GeoLife
Fahrradtourenvorschlag 149 „Maschsee-Route zur Expo“. Dabei bilden die in der GISSoftware ArcView organisierten ATKIS- und POI-Daten der Region Hannover die
Grundlage der im Navigationssystem enthaltenen Geo-Informationen.
Das erstellte Gesamtkonzept zur Entwicklung eines anspruchsvollen Navigationssystems
für Fahrradtouren hat sich in einem Systemtest bewährt. Die implementierten
Funktionalitäten liefen sehr zuverlässig ab und gewährleisteten jederzeit eine sehr schnelle
und eindeutige Orientierung in der realen Welt.
10
Zusammenfassung und Ausblick
93
Mit Hinblick auf weiterführende Arbeiten können die vorgestellten Methoden unter den
folgenden Aspekten noch weiter optimiert und erweitert werden.
Denkbar ist eine separate Speicherung der geometrischen Weg-Informationen unter
Verwendung einer externen XML-Datei. Dies hat den Vorteil, dass die Tourdaten leicht zu
modifizieren sind und die Verwendung einer weiteren Route innerhalb des Kartengebiets
lediglich die Bearbeitung beziehungsweise den Austausch der Weg-Datei voraussetzt.
Somit wird eine vollständige, rechenintensive Neubildung der Geometrie-Daten bei einer
Routenänderung vermieden. Ebenfalls realisierbar sind dann Systemfunktionalitäten, die es
dem Nutzer gestatten, die vorgegebene Route unterwegs im begrenzten Maß zu
manipulieren.
Eine Integration zusätzlicher Funktionen zum Ein- und Ausblenden bestimmter
Objektklassen befähigen den Anwender, die Kartengraphik individuell thematisch
anzupassen. Besonders bei der Einbeziehung vielfältiger POI-Themen erweist sich diese
Option als sinnvoll.
Bisher nicht berücksichtigt ist eine tiefere Auseinandersetzung mit der Problematik der
Routenplanung über einen stationären PC. Zwar erlaubt das entwickelte Konzept die
Bereitstellung von Daten für ausgesuchte Touren beispielsweise im Internet, Ziel muss es
aber sein, dem Nutzer eine Möglichkeit anzubieten, eine Fahrradtour individuell zu
gestalten und alle, für die tourspezifische Navigation erforderlichen Daten annähernd in
Echtzeit abzufragen.
Abschließend folgt aus den Untersuchungen dieser Arbeit, dass der heutige
Entwicklungsstand im Bereich Hard- und Software einen Einsatz kompakter, funktioneller
Navigationssysteme im Bereich des Radwanderns zulässt. Es ist demnach nur noch eine
Frage der Zeit, wann die ersten komplexen Fahrradtouren-Navigationssysteme auf dem
Markt erscheinen werden.
94
Anhang
Anhang
Auf der beiliegenden CD sind folgende Daten enthalten:
Ordner ArcView
•
Ordner daten
•
Ordner Scripte
•
Dateien der ArcView-Themen.
o
linelab.ave
ArcView-Script linelab.
o
PPL_Tools12.avx
ArcView-Tool P/PL-Tools V1.2.
o
th2SVG.ave
ArcView-Script th2SVG.
o
totleng.ave
ArcView-Script totleng.
o
xtools.avx
ArcView-Tool Xtools.
tour149.apr
ArcView-Projekt
Scripten.
mit
allen
Themen
und
Ordner Ausarbeitung
•
Affintransformation.xls
Excel-Dokument für die
Parameter
für
Koordinatentransformation
vermittelnde Ausgleichung.
•
Diplomarbeit.doc
Diplomarbeit als Word-Dokument.
•
Diplomarbeit.pdf
Diplomarbeit als PDF-Dokument.
Bestimmung der
die
affine
über
eine
Ordner GPS
•
Ordner Application
Ordner mit Setup-Dateien zur automatischen
Installation von GPSLog auf PDA; Start über
Setup.exe.
•
Ordner eVB-Dateien
Ordner mit eVT-Dateien von GPSLog.
Ordner Software
•
Crux_View.exe
PDA-Programm Crux_View (GPS-Tool).
95
Anhang
•
epsetup.exe
PC-Programm EditPlus2 (Editor).
•
eSVG V2.0 for PPC.exe
PDA-Programm
SVG-Viewer).
•
eSVG V2.0.zip
PC-Programm eSVG V2.0 (Shareware, SVGViewer).
•
evt2002.zip
PC-Programm eMbedded Visual Tools
(Entwicklungsumgebung
für
VisualBasicProgramme auf Windows CE-Basis).
•
GpsViewer.exe
PDA-Programm GPSViewer (GPS-Tool).
•
ksdtrans.zip
PC-Programm
KSDTrans
Koordinatentransformationen).
•
VisualGPSce.exe
PDA-Programm
Tool).
eSVG
V2.0
(Shareware,
(Tool
VisualGPSScene
für
(GPS-
Ordner SVG
•
Ordner Tour149(PC)
149 auf PC-Basis.
für
Tour
•
Ordner Tour149(PDA)
149 auf PDA-Basis.
für
Tour
à System-Start über tour.svg.
Quellenverzeichnis
96
Quellenverzeichnis
ADAM, A., 2002: SVG-Scalable Vector Graphics, Franzis, Poing.
ADOBE,
2004:
Illustrator
10.0,
Stand:
November
http://hallgraphic.com/store/software_B00005QVPY_Adobe-Illustrator10.0.html.
2001,
ALSLEBEN, S., 2002: Point & Polyline Tools v1.2, Stand: November 2003,
http://arcscripts.esri.com/details.asp?dbid=11694.
AMMELBURGER, D., 2004: XML: Grundlagen der Sprache und Anwendungen in der
Praxis, Hanser, München.
ARONOFF, S., 1991: Geographic Information Systems: A Management Perspective, WDL
Publications, Ottawa (Kanada).
ATKIS, 2004: Amtliches Topographisch-Kartographisches Informationssystem, Stand:
Januar 2004, http://www.atkis.de.
BACK, W., 2003: CE – Programmierung, Stand: Januar 2004, http://www.wolfgangback.com/PDF/gps_ein_fall_fuer_den_pda.pdf.
BÄR, W., 2002: Konzeption und Entwicklung von Software-Komponenten für ein
Routenplanungssystem
mit
mobilen
Endgeräten,
Institut
für
Umweltwissenschaften der Hochschule Vechta, Stand: November 2003,
http://www.mapserver.uni-vechta.de/~wbaer/resources/diplomathesis.pdf.
BARTELME, N., 2000: Geoinformatik, 3.Auflage, Springer, Berlin.
BENNET,
R., 2002: GPS Tracking using SVG, Stand: November 2003,
http://www.svgopen.org/2002/papers/bennet_gps_tracking_with_svg/index.html.
BILL, R., 1999: Grundlagen der Geo-Informationssysteme Band1, 4.Auflage, Wichmann,
Heidelberg.
BRÜHLMEIER, T., 2000: Interaktive Karten – adaptives Zoomen mit Scalable Vector
Graphics, Geographisches Institut der Universität Zürich, Stand: November 2003,
http://www.carto.net/papers/tobias_bruehlmeier/2000_10_tobias_bruehlmeier_di
plomarbeit_adaptives_zoomen.pdf.
BUZIEK, G., 2002: Geoinformationen im mobilen Internet – Aspekte der Kommunikation
und Wahrnehmung, In: Institut für Kartographie und Geo-Medientechnik (Hrsg.):
Telekartographie
und
Location
Based
Services,
Wien,
61-76
(Geowissenschaftliche Mitteilungen, 58).
COREL,
2002A :
Photopaint
11.0,
Stand:
http://www.corel.de/product_details.asp?id=29&cat=1.
Dezember
2003,
Quellenverzeichnis
COREL,
97
2002B:
CorelDraw
11.0,
Stand:
http://www.corel.de/product_details.asp?id=29&cat=1.
Dezember
DELAUNE,
M.,
2003:
XTools,
Stand:
http://arcscripts.esri.com/details.asp?dbid=11526.
November
2003,
2003,
DILTHEY, A., 2003: Die Webdesign-Referenz, Stand: Januar 2004, http://www.webdesignreferenz.de.
ELIAS, B. & HAMPE, M., 2003: Integrating topographic information and landmarks for
mobile navigation, In: Institut für Kartographie und Geo-Medientechnik (Hrsg.):
Location
Based
Services
&
Telecartography,
Wien,
147-156
(Geowissenschaftliche Mitteilungen, 66).
ES- COMPUTING, 2003: EditPlus2-Editor, Stand: Oktober 2003, http://www.editplus.com.
ESRI, 1998: What's new in ArcView GIS 3.2, ArcView GIS 3.2 Help.
ESRI, 2004: ArcView 3.x, Stand: Oktober 2003, http://www.esri.com/software/arcview.
FAHRRADIES ,
2001,
Stand:
November
vechta.de/Fahrradies/Routenplaner.html.
2003,
http://www.fahrradies.uni-
FIBINGER, I., 2002: SVG - Scalable vector graphics : Praxiswegweiser und Referenz für
den neuen Vektorgrafikstandard, Markt+Technik, München.
FLANAGAN, D., 2003: JavaScript - kurz und gut, 2.Auflage, O’Reilly, Köln.
FUGAWI,
2004:
GPS
Karten
http://www.fugawi.de/index.html.
Software,
Stand:
März
2004,
GAILLY, J. L., 2003: the gzip homepage, Stand: Februar 2004, http://www.gzip.org.
GARTNER, G., 2000: Karten im Internet, In: Deutsche Gesellschaft für Kartographie
(Hrsg.): Neue Wege für die Kartographie, Bonn, 43-51 (Kartographische
Schriften, 4).
GEOLIFE,
2004:
Der
Geolife.de-Tourenservice,
http://www.geolife.de.
Stand:
Februar
2004,
GIEVERS, R., 2003: Pocket PC und Windows CE 3.0 für Einsteiger, 2.Auflage, Schmidt,
Neustadt an der Aisch.
GIMODIG, 2004: Geospatial info-mobility service by real-time data-integration and
generalisation, Stand: März 2004, http://gimodig.fgi.fi.
GRATTAN, N., 2002: Pocket PC, Handheld PC Developer’s Guide with Microsoft
eMbedded Visual Basic, Prentice-Hall, New Jersey (USA).
GRIESER, F., 2002: Das PocketPC 2002 Buch, Markt+Technik, München.
Quellenverzeichnis
98
GRUBER, F. J., 1998: Formelsammlung für das Vermessungswesen, Dümmler, Bonn.
HAKE, G.; GRÜNREICH, D.; MENG, L., 2002: Kartographie, 8.Auflage, de Gruyter, Berlin.
HEINICKE, J., 2003: CSS Werkzeuge
css.fractatulum.net/tools.htm.
Hilfsmittel Editor, Stand: Februar 2004,
HELD, G., 2003: Anforderungen an einen kartographischen Viewer für Business
Intelligence Systeme, Fachbereich Geoinformationswesen der Fachhochschule
Karlsruhe,
Stand:
November
2003,
http://www.carto.net/papers/georg_held/diplomarbeit_georg.pdf.
HEWLETT PACKARD, 2003: HP iPAQ Pocket-PC h5450 - Übersicht & Merkmale, Stand:
Oktober
2003,
http://h10010.www1.hp.com/wwpc/de/de/ho/WF05a/2125921265-21265-21265-21265-1180777.html.
HEWLETT PACKARD, 2004, Stand: November 2003, http://www.hewlett-packard.de.
HOLUX, 2003: Holux GM-270 CF GPS Empfänger – Bedienungsanleitung, Stand: Oktober
2003, http://www.holux-gps.de/downloads/gm270_anleitung.pdf.
HOLUX, 2004: GM-270 (CF), Stand: März 2004, http://www.holux-gps.de/gm270.php.
INSIGNIA ,
2004:
Insignia
Jeode,
Stand:
http://www.insignia.com/content/about/releases/011203.shtml.
März
INTESIS,
2004:
eSVG
evaluation
package
V2.0, Stand:
http://www.embedding.net/eSVG/english/get_it/get_it_frame.html.
JASC
SOFTWARE,
2004:
WebDraw,
http://www.jasc.com/products/webdraw.
Stand:
Januar
Februar
2004,
2004,
2004,
KAHLISCH, T. & VOGEL, G., 1997: SGML Tutorial, Stand: Januar 2004, http://www.ib.huberlin.de/~mschul/sgmltut.htm.
KELNHOFER, F., 2002: Kartographie und Tele-Kommunikation, In: Institut für
Kartographie und Geo-Medientechnik (Hrsg.): Telekartographie und Location
Based Services, Wien, 3-26 (Geowissenschaftliche Mitteilungen, 58).
LAGERSTROM , L. R., 2003: Programming the Web using XHTML and JavaScript,
McGraw-Hill, New York (USA).
LAUCHARDT, T., 2003: SVG Tutorial, Stand: November 2003, http://www.fhwedel.de/~si/praktika/MultimediaProjekte/SVG/SVG_Tutorial_mi3794/3_4.htm.
LEHMANN, C., 1999: Visual Basic 6.0, 7.Auflage, Herdt, Nackenheim.
LIEBIG, W. & SCHALLER, J. (Hrsg.), 2000: ArcView GIS, Wichmann, Heidelberg.
Quellenverzeichnis
99
MEINIKE, T., 2002: Scalable Vector Graphics (SVG) – ein XML-basierter Grafikstandard
für 2D-Vektorgrafiken. Vortrag beim Tag der Forschung 2002 – XMLGrafikstandard Scalable Vector Graphics (SVG) im Mai 2002 in Merseburg.
MICROSOFT, EMBEDDED VISUAL BASIC 3.0, 2000, Stand: Dezember
http://www.microsoft.com/downloads/details.aspx?FamilyID=aeaa7f4c-133146f1-bc4f-cc909333261a&DisplayLang=en.
2003,
MICROSOFT, EMBEDDED VISUAL TOOLS 3.0 - 2002 EDITION, 2002, Stand: Januar 2004,
http://www.microsoft.com/downloads/details.aspx?FamilyID=f663bf48-31ee4cbe-aac5-0affd5fb27dd&displaylang=en.
MOBILE2DAY,
2004:
Software
PocketPC,
http://www.mobile2day.de/platform_wince/software.
Stand:
März
2004,
NÄF, M., 2002: Einführung in XML, DTD und XSL, Stand: November 2003,
http://www.internet-kompetenz.ch/xml/einfuehrung.
NAVIION, 2003: NaviiON – RIDE WITH A NEW DIMENSION, Stand: Februar 2004,
http://www.naviion.de/de.
NIEMEIER, W., 2002: Ausgleichungsrechnung, de Gruyter, Berlin.
NOACK, W., 2002A : XML 1.0, 2.Auflage, Regionales Rechenzentrum Niedersachsen,
Hannover.
NOACK, W., 2002B: Illustrator 10, Regionales Rechenzentrum Niedersachsen, Hannover.
ORBWORKS,
2003:
PocketC
for
Windows
http://www.orbworks.com/pcce/index.html.
CE,
Stand:
März
2004,
PARAMOUNT, 2004, Stand: Februar 2004, http://www.paramount-tours.com.
POWELL, T. A., 2003: HTML & XHTML: the complete reference, 4.Auflage, McGraw-Hill,
New York (USA).
REINELT, A., 2002: Das Pocket PC Power-Buch, X.Media, München.
ROGERS,
N.,
2002:
Shp2SVG,
http://www.carto.net/projects/shp2svg.
Stand:
November
2003,
ROTTER, R., 2002: Javascript: Grundlagen, CSS, Schleifen&Funktionen, Objekte, DOM,
DHTML, Dialoge, Behaviors, Franzis, Poing.
SALATHE, M., 2001: SVG, Markt+Technik, München.
SEEBER, G., 2003: Satellite Geodesy, 2.Auflage, de Gruyter, Berlin.
SELFHTML, 2004: XML-Software für MS Windows,
http://selfaktuell.teamone.de/links/xml_software.htm.
Stand:
Februar
2004,
Quellenverzeichnis
100
SINGER, C., 2003: KSDTrans, Stand: Februar 2004, http://www.icsinger.de/ksdtrans-htm.
STEYER, R., 2001: Jetzt lerne ich JavaScript und HTML, Markt+Technik, München.
THALES
NAVIGATION,
2004:
http://www.magellangps.com.
Magellan,
Stand:
Februar
2004,
UISMEDIA , 2004: MapView SVG, Stand: Januar 2004, http://www.mapview.de.
VOLKMER, P. & WALDENMAIER, S., 2003: Navigation per Handy. Funkschau 2003 (8): 1416.
W3C,
CASCADING STYLE SHEETS HOME PAGE,
http://www.w3.org/Style/CSS.
W3C,
EXTENSIBLE MARKUP
http://www.w3.org/XML.
W3C,
HYPERTEXT
MARKUP
LANGUAGE,
http://www.w3.org/MarkUp.
W3C,
SCALABLE
VECTOR
GRAPHICS,
http://www.w3.org/MarkUp.
W3C,
SVG
IMPLEMENTATIONS,
2004,
Stand:
http://www.w3.org/Graphics/SVG/SVG-Implementations.htm8.
LANGUAGE,
2004,
2003,
2004,
2004,
Stand:
Stand:
Februar
2004,
November
2003,
Stand:
Februar
2004,
Stand:
Februar
2004,
Februar
2004,
WEBPARK, 2004, Stand: Februar 2004, http://www.webparkservices.info/welcome.html.
WEINGÄRTNER, M., 1999: Publizieren im World Wide Web, 3.Auflage, Regionales
Rechenzentrum Niedersachsen, Hannover.
WINTER, A. M., 2000: Internetkartographie mit SVG, Fakultät der Human- und
Sozialwissenschaften der Universität Wien, Stand: November 2003,
http://www.carto.net/andre.mw/projects/atlas/internetkarto_svg_atlas_001206.pdf.
WINTGES, T., 2002: Geo-Data Visualization on Personal Digital Assistants (PDA), In:
Institut für Kartographie und Geo-Medientechnik (Hrsg.): Maps and the Internet
2002, Wien, 177-183 (Geowissenschaftliche Mitteilungen, 60).
WOLF, I., 2001: Untersuchungen zur web-basierten Präsentation von Geo-Daten unter
Anwendung von XML und SVG, Institut für Kartographie und Geoinformatik der
Universität
Hannover,
Stand:
November
2003,
http://www.ikg.unihannover.de/publikationen/diplomarbeiten/2001/Wolf/da_wolf_2001.pdf.

diplomarbeit am ikg - Institut für Kartographie und Geoinformatik

Transcrição

Documentos relacionados

Region Stade

Gesuch für ein Duplikat eines Fahrzeugausweises

Aidsgalanter Chef - SVG Sylter Verkehrsgesellschaft

Sportverein 1919 eV Mainz-Gonsenheim

E-Folien - Institut für Deutsche Sprache

Aktuelle Webtechniken und deren Anwendung in der

Transportprofis gesucht?! | Fachkräftesicherung konkret

Nutzung von ArcView 3.x für geologische Kartierungen

netcomp 3b deutsch.indd - Movis Mobile Vision GmbH

Skripte