Warenkorb
0 Artikel | US$ 0,00
Daniel Hänßgen
Konzeption und Implementierung eines Orientierungssystems für Menschen mit
Sehbehinderung auf Java ME
ISBN: 978-3-8428-0385-5
Herstellung: Diplomica® Verlag GmbH, Hamburg, 2010
Zugl. Fachhochschule Hannover, Hannover, Deutschland, Bachelorarbeit, 2010
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden und der Verlag, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica Verlag GmbH
http://www.diplomica.de, Hamburg 2010
Inhaltsverzeichnis
1
Einleitung
5
1.1
Gliederung dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.2
Typografische Konventionen . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2
Anforderungsanalyse
7
2.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Zielsetzung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.1
Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.2
Funktionale Anforderungen
. . . . . . . . . . . . . . . . . . . . . .
8
2.2.3
Informationsquellen . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.4
Technische Anforderungen . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.5
Nicht-funktionale Anforderungen
. . . . . . . . . . . . . . . . . . .
10
2.3
OpenStreetMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3.1
Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3.2
Lizenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.3
Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.4
Datenquellen und Quellformate . . . . . . . . . . . . . . . . . . . .
12
2.3.5
Details zum Datenformat . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3.6
Informationsdichte . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.4
GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.4.1
NMEA-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.5
Begriffserkl¨
arung: Kurs, Sollkurs und Peilung . . . . . . . . . . . . . . . . .
19
2.6
Richtungsabh¨
angige Vibration . . . . . . . . . . . . . . . . . . . . . . . . .
20
3
Analyse
21
3.1
Paketstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.2
Klassendiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2.1
View-Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2.2
Main-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.2.3
GPS-Paket
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2.4
OSM-Paket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2.5
Util-Paket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.2.6
Datastore-Paket . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.2.7
Entity-Paket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.3
Sequenzdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.3.1
Starten der Anwendung
. . . . . . . . . . . . . . . . . . . . . . . .
35
3.3.2
GPS-Daten lesen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.3.3
Umgebungssuche . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.3.4
Stichwortsuche
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.3.5
Favoriten speichern . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.3.6
Punkt als Favoriten speichern . . . . . . . . . . . . . . . . . . . . .
40
3.3.7
Einfaches Beispiel f¨
ur die Verwendung von SimpleInputView . . . .
41
2
4
Entwurf
42
4.1
Exkurs: Java ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.1.1
MIDlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.1.2
Erschwerte Bedingungen durch Signierung . . . . . . . . . . . . . .
44
4.1.3
Screenreader-freundlich mit Java ME . . . . . . . . . . . . . . . . .
44
4.2
Beziehungen zwischen den Klassen
. . . . . . . . . . . . . . . . . . . . . .
45
4.3
Zustandsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.3.1
Zustandsdiagramm GPSCheck . . . . . . . . . . . . . . . . . . . .
47
4.3.2
Zustandsdiagramm Favoriten hinzuf¨
ugen . . . . . . . . . . . . . .
49
4.4
Zerlegung in Teilsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5
Implementierung
51
5.1
Bin¨
ares Kartenformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.1.1
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.1.2
Tags-Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.1.3
Erstellung und Benutzung der bin¨
ar-codierten Datei . . . . . . . . .
53
5.2
Implementierungsdetails . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.2.1
Klasse FavoriteStore . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.2.2
Klasse ActualPosition
. . . . . . . . . . . . . . . . . . . . . . . . .
55
5.2.3
Klasse AlertManager . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5.2.4
Klasse NodeManager . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6
Zusammenfassung und Ausblick
60
6.1
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
6.2
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
7
Anhang
63
A Anwendungsf¨
alle
63
A.1 Lizenzbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
A.2 Favoriten-Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
A.3 GPS-Status anzeigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
A.4 Wo bin ich? (N¨
achstgelegene Adresse und Ort) . . . . . . . . . . . . . . . .
69
A.5 Umgebungssuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
A.6 Stichwortsuche
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
A.7 Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
A.8 Sonstiges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
Literaturverzeichnis
80
3
Abbildungsverzeichnis
1
Erkl¨
arung von Heading, Bearing und Course . . . . . . . . . . . . . . . . .
19
2
Paketdiagramm Struktur der Pakete
. . . . . . . . . . . . . . . . . . . .
21
3
Klassendiagramm View-Klassen . . . . . . . . . . . . . . . . . . . . . . .
24
4
Klassendiagramm Main-Klasse . . . . . . . . . . . . . . . . . . . . . . . .
26
5
Klassendiagramm GPS-Paket . . . . . . . . . . . . . . . . . . . . . . . .
27
6
Klassendiagramm OSM-Paket . . . . . . . . . . . . . . . . . . . . . . . .
28
7
Klassendiagramm Util-Paket . . . . . . . . . . . . . . . . . . . . . . . . .
30
8
Klassendiagramm Datastore-Paket
. . . . . . . . . . . . . . . . . . . . .
32
9
Klassendiagramm Entity-Paket . . . . . . . . . . . . . . . . . . . . . . .
33
10
Sequenzdiagramm Starten der Anwendung . . . . . . . . . . . . . . . . .
35
11
Sequenzdiagramm GPS-Daten lesen . . . . . . . . . . . . . . . . . . . . .
36
12
Sequenzdiagramm Umgebungssuche . . . . . . . . . . . . . . . . . . . . .
37
13
Sequenzdiagramm Stichwortsuche . . . . . . . . . . . . . . . . . . . . . .
38
14
Sequenzdiagramm Favoriten speichern
. . . . . . . . . . . . . . . . . . .
39
15
Sequenzdiagramm Punkt als Favoriten speichern . . . . . . . . . . . . . .
40
16
Sequenzdiagramm Beispiel f¨
ur die Verwendung von SimpleInputView . .
41
17
Paketdiagramm Abh¨
angigkeiten der Pakete . . . . . . . . . . . . . . . . .
45
18
Zustandsdiagramm GPSCheck . . . . . . . . . . . . . . . . . . . . . . . .
47
19
Zustandsdiagramm Favoriten hinzuf¨
ugen . . . . . . . . . . . . . . . . . .
49
4
1
EINLEITUNG
1
Einleitung
Am 02.05.2000 wurde die
"
Selective Availability" (SA) des amerikanischen satelliten-
gest¨
utzen Positionierungssystems GPS abgeschaltet.
1
Unter SA versteht man die k¨
unst-
liche Verschlechterung der Satellitenbahndaten, sodass die Positonierungsgenauigkeit bei
zivilen GPS-Empf¨
angern nur bei etwa 100 Metern liegt. Durch das Abschalten wurde die
Positionierung auf etwa zehn Meter genau. Sp¨
atestens seitdem erf¨
ahrt die Verbreitung
von GPS-Navigations-Ger¨
aten einen bedeutenden Anstieg.
Von der Routenf¨
uhrung bis hin zum Finden von so genannten Orten von Interesse ist
f¨
ur die Navigation mit dem Auto nahezu jeder erdenkliche Bereich abgedeckt. Allerdings
vernachl¨
assigen die meisten Hersteller die besonderen Bed¨
urfnisse von Menschen mit Seh-
behinderung, unter anderem, da diese in der Regel zu Fuß unterwegs sind. So sind zum
Beispiel Orte von Interesse, die f¨
ur Menschen mit Sehbehinderung von Bedeutung w¨
aren,
wie etwa Bushaltestellen oder Straßen¨
uberquerungen, h¨
aufig nicht in handels¨
ublichem
Kartenmaterial enthalten. Auch die Routenf¨
uhrung f¨
ur das Auto bezieht nicht s¨
amtliche
Informationen mit ein, die f¨
ur Fußg¨
angerInnen - insbesondere f¨
ur solche mit Sehbehinde-
rung - relevant w¨
aren. So existiert zum Beispiel bei den wenigsten Navigationsger¨
aten eine
Ausgabe der Namen der Straßen, in die man gef¨
uhrt wird, und Straßen¨
uberwege werden
gar nicht ber¨
ucksichtigt.
Es gibt also einen Bedarf an Kartenmaterial und einer Routenf¨
uhrung, die den Bed¨
urf-
nissen von Menschen mit Sehbehinderung gerecht werden. Erst das Abschalten der SA
machte eine solche Routenf¨
uhrung m¨
oglich, doch bisher fehlt es an kosteng¨
unstigen Um-
setzungen. Das OpenStreetMap-Projekt jedoch, welches sein Kartenmaterial unter einer
freien Lizenz ver¨
offentlicht, beinhaltet schon heute Orte von Interesse f¨
ur Menschen mit
Sehbehinderung und erweitert diese fortlaufend.
Diese Bachelorarbeit befasst sich - unter Einbeziehung des erw¨
ahnten Kartenmaterials
- mit der Konzeption und Implementierung einer freien Software, die speziell auf die
Bed¨
urfnisse von Menschen mit Sehbehinderung zugeschnitten ist.
1
Vergleiche:
http://www.ngs.noaa.gov/FGCS/info/sans_SA/
5
1.1
Gliederung dieser Arbeit
1
EINLEITUNG
1.1
Gliederung dieser Arbeit
Die Gliederung dieser Bachelorarbeit orientiert sich gr¨
oßtenteils an den Schritten eines
allgemeinen Software-Entwicklungsprozesses:
Anforderungsanalyse - Analyse - Entwurf - Implementierung - Test
Unterschiede finden sich in den Schritten
"
Anforderungsanalyse" und
"
Test": Die An-
wendungsf¨
alle, die sonst in der Anforderungsanalyse enthalten sind, befinden sich hier im
Anhang, da ihr Inhalt bereits im Kapitel
"
Zielsetzung" ausf¨
uhrlich behandelt wird. Des
Weiteren werden die Ergebnisse des Schrittes
"
Test" bereits im Kapitel
"
Zusammenfas-
sung und Ausblick" thematisiert.
1.2
Typografische Konventionen
In dieser Arbeit gelten folgende typografischen Konventionen:
· Besonders zu betonende Textstellen werden kursiv dargestellt.
· Der Typewriter-Stil gilt f¨
ur Kommandos, Dateinamen, Pakete, Klassen, Attribute
und Quelltexte im Allgemeinen.
· Querverweise werden in
§
¦
¤
¥
K¨
astchen mit abgerundeten Ecken dargestellt.
6
2
ANFORDERUNGSANALYSE
2
Anforderungsanalyse
Bereits im M¨
arz 2009 wurde damit begonnen, die Anforderungen zusammenzutragen. Da-
her sind alle Entscheidungen und Begr¨
undungen, die in diesem Kapitel zur Sprache kom-
men, bereits getroffen worden, bevor ich mich der Entwicklung des Systems im Rahmen
meiner Bachelorarbeit annahm. Eine Bewertung dieser Entscheidungen und Begr¨
undun-
gen erlaube ich mir im Ausblick.
2.1
Motivation
Beim Erfassen von Daten f¨
ur eine Karte ber¨
ucksichtigen die wenigsten KartografInnen
Informationen, die f¨
ur Menschen mit Sehbehinderung von Bedeutung sein k¨
onnten, weil
sie davon ausgehen, dass die Karten optisch dargestellt werden. Daher fehlen handels¨
ubli-
chen Karten Informationen wie Straßen¨
uberquerungen, ob eine Bushaltestelle mit taktiler
Pflasterung ausgestattet ist und ¨
Ahnliches. Zwar gibt es M¨
oglichkeiten der nicht-visuellen
Darstellung, jedoch sind derzeit am Markt verf¨
ugbare Systeme sehr teuer - beispielsweise
kostet der Trekker umgerechnet ungef¨
ahr 2.300
e
1
- und bieten weder blindenspezifische
Punkte in ihren Kartendaten noch die M¨
oglichkeit, diese selbst hinzuzuf¨
ugen.
Daraus folgt auch, dass neue Objekte anderen Nutzenden nicht verf¨
ugbar gemacht werden
k¨
onnen. Die Motivation f¨
ur die Entwicklung eines neuen Systems liegt darin, diese M¨
angel
zu beheben.
Bereits heute gibt es das OpenStreetMap-Projekt, welches sich um eine freie Weltkarte
bem¨
uht. Dort ist es m¨
oglich, Daten zu ¨
andern und neue Daten hinzuzuf¨
ugen. Auch bietet
dieses geodatensammelnde Projekt bereits jetzt einige blindenspezifische Informationen.
Jedoch gibt es kaum M¨
oglichkeiten f¨
ur Menschen mit Sehbehinderung, am Projekt un-
mittelbar mitzuwirken.
2.2
Zielsetzung
Das Ziel ist, ein mobiles System zu entwickeln, das es Menschen mit Sehbehinderung
erm¨
oglicht, die freien Daten aus dem OpenStreetMap-Projekt zu nutzen und diese Daten
sogar selbst zu editieren und zu erweitern. Es soll den Namen LoroDux tragen. Er setzt
sich zusammen aus dem spanischen Wort f¨
ur Papagei (Loro) und aus dem lateinischen
Wort f¨
ur F¨
uhrer (Dux).
2.2.1
Abgrenzung
Die Kernanforderungen wurden in mehrere Ausbaustufen unterteilt. Diese Arbeit befasst
sich ausschließlich mit der ersten Ausbaustufe. Daher findet sich in diesem Kapitel keine
Beschreibung der f¨
ur sp¨
atere Versionen erforderlichen Anforderungen.
2
1
http://www.abacuscity.ch/abashop?p=hierarchyoutline&hi=1290.00&hl=2&i=
0U5KKcFL7h1h2KA0xCWD&s=32
2
http://wiki.openstreetmap.org/wiki/LoroDux/Requirements
7
2.2
Zielsetzung
2
ANFORDERUNGSANALYSE
2.2.2
Funktionale Anforderungen
Beim Starten der Anwendung muss ein Hinweis auf die verwendete Lizenz der Kartenda-
ten angezeigt werden. Diese Funktion darf nicht abschaltbar sein.
Das System soll speziell f¨
ur die Bed¨
urfnisse von Menschen mit Sehbehinderung entwickelt
werden. Daher ist es erforderlich, dass keine Grafiken verwendet werden. Die Ausgabe
darf nur aus Text bestehen, der von einem Screenreader gelesen werden kann.
Ein Screenreader ist eine Anwendung, die im Hintergrund l¨
auft und vorliest, was auf dem
Display eines Ger¨
ates als Text dargestellt wird. F¨
ur eine solche Software ist die Erkennung
von Text in Bildern nicht m¨
oglich. Zum einen ist der rechnerische Aufwand zu groß, als
dass ein mobiles Endger¨
at eine Texterkennung durchf¨
uhren k¨
onnte. Zum anderen ist die
Aufl¨
osung der Grafiken aufgrund des kleinen Displays zu gering, um eine hohe Erken-
nungsrate der Buchstaben zu erzielen. Konkret wird vorausgesetzt, dass mindestens der
Screenreader
"
Talks" der Firma Nuance unterst¨
utzt wird.
Es soll die M¨
oglichkeit bestehen, sich ausgeben zu lassen, wo man sich gerade befindet.
Dies soll mittels Angabe von Straße und Hausnummer sowie Ort bzw. Stadtteil gesche-
hen. Falls keine Hausnummer vorhanden ist, soll die n¨
achste Kreuzung oder Einm¨
undung
angegeben werden.
Mindestens f¨
ur Testzwecke soll es m¨
oglich sein, sich die Koordinaten ansagen zu las-
sen, die gerade vom GPS-Empf¨
anger kommen.
Es soll m¨
oglich sein, pers¨
onliche Favoriten sowohl ¨
uber die direkte Eingabe von Name
und geografischen Koordinaten als auch durch einen vorhanden Punkt aus den Karten-
daten abzulegen.
Es soll m¨
oglich sein, sowohl die Distanz zu einem Punkt aus den Kartendaten als auch
die Richtung, in der er sich befindet, berechnen zu lassen. Dies gilt auch f¨
ur pers¨
onliche
Favoriten. Die Richtung soll dabei in Himmelsrichtungen oder auf der Uhr, also relativ
zur Bewegungsrichtung, ansagbar sein.
Bei Verlust eines g¨
ultigen GPS-Signals soll dies mit einstellbarer Verz¨
ogerung ausgege-
ben werden. Auch das Wiedererlangen eines g¨
ultigen GPS-Signals soll ausgegeben werden.
Die OpenStreetMap-Karte liefert weltweite Daten. Daher ist es erforderlich, dass auch
die Anwendung weltweit agieren kann. Das bedeutet, dass eine Schrift- und Sprachenun-
abh¨
anigkeit zu den Kernanforderungen geh¨
ort.
Obschon das System speziell f¨
ur Menschen mit Sehbehinderung entwickelt wird, soll eine
Bedienung durch sehende Menschen ebenso m¨
oglich sein. So sollen beispielsweise Traine-
rInnen, Familienmitglieder oder FreundInnen in der Lage sein, den Nutzer beziehungsweise
die Nutzerin beim Erlernen der Bedienung des Systems zu unterst¨
utzen.
8
2.2
Zielsetzung
2
ANFORDERUNGSANALYSE
2.2.3
Informationsquellen
Als Informationsquellen standen mir folgende Personen und Dokumente zur Verf¨
ugung:
Die Initiatorin des LoroDux-Projektes, Annette Thurow. Die deutsche Mailingliste Blind-
NaviOSM, die sich speziell mit Navigation f¨
ur Menschen mit Sehbehinderung befasst be-
ziehungsweise deren angemeldete und fleißig Anforderungen aufnehmende NutzerInnen.
3
Durch diese Mailingliste konnte ich viel ¨
uber die besonderen Bed¨
urfnisse von Menschen
mit Sehbehinderung in Erfahrung bringen. Ein Dokument
4
des Deutschen Blinden- und
Sehbehindertenverbandes e.V. (DBSV). In diesem Dokument hat der DBSV im Jahr 2008
umfassende Informationen ¨
uber die Anforderungen, die an ein Orientierungssystem f¨
ur
Menschen mit Sehbehinderung gestellt werden, und die Bed¨
urfnisse, die diese Menschen
haben, sehr detailliert zusammengetragen. Da das Dokument aber von Menschen verfasst
wurde, die ¨
uber keine umfassenden Kenntnisse der technischen M¨
oglichkeiten verf¨
ugen,
finden sich in diesem auch sehr unrealistische Anforderungen. Beispielsweise soll die Posi-
tionierungsbestimmung auf einen Meter genau sein, was mit handels¨
ublichem GPS nicht
realisierbar ist.
Zu diesen Quellen kommt noch das Wiki
5
von LoroDux hinzu. Es war zu großen Teilen
bereits zu Beginn der Bachelorarbeit sehr umfangreich und wurde w¨
ahrend der Entwick-
lung des Systems sogar noch erweitert. Allerdings ist eine weitreichende Fehlerfreiheit
bislang noch nicht vorhanden, sodass die dort gemachten Angaben nur unter Vorbehalt
verwendet werden sollten.
2.2.4
Technische Anforderungen
An das zu entwickelnde mobile System werden folgende technischen Anforderungen ge-
stellt: Die Programmiersprache muss Java ME sein. Die Begr¨
undung hierf¨
ur ist, dass Java
ME plattformunabh¨
angig ist. Das bedeutet, dass theoretisch das gleiche Programm auf
verschiedenen mobilen Plattformen ohne Anpassung an das verwendete Betriebssystem
lauff¨
ahig ist - auch auf ¨
alteren Ger¨
aten. Somit bietet sich Java ME auch f¨
ur die Ver-
wendung in so genannten Dritte-Welt-L¨
andern an. Außerdem existiert f¨
ur Java ME eine
Entwicklungsumgebung (IDE), die f¨
ur Menschen mit Sehbehinderung gut bedienbar ist.
Damit er¨
offnet sich auch f¨
ur die Zielgruppe des Systems die M¨
oglichkeit der Weiterent-
wicklung.
Das zur Verwendung kommende mobile Endger¨
at muss ¨
uber eine Bluetooth-Schnittstelle
verf¨
ugen, um sich mit Bluetooth-GPS-Empf¨
angern verbinden zu k¨
onnen. Die logische
Konsequenz aus dieser Anforderungen ist, dass ein GPS-Empf¨
anger ebenfalls ¨
uber ei-
ne Bluetooth-Schnittstelle verf¨
ugen muss.
Wie bereits erw¨
ahnt, stammen die Begr¨
undungen und Entscheidungen in diesem Kapitel
nicht von mir, sondern sind aus den oben genannten Informationsquellen entnommen.
3
https://lists.openstreetmap.de/mailman/listinfo/blindennavigation
4
(
DBSV u. a.
,
2008
)
5
http://wiki.openstreetmap.org/wiki/LoroDux
9
2.3
OpenStreetMap
2
ANFORDERUNGSANALYSE
2.2.5
Nicht-funktionale Anforderungen
Die Antwortzeit auf jede Eingabe soll weniger als zehn Sekunden betragen. Im besonderen
Fall der Aktualisierung von Distanz und Richtung soll die Antwortzeit weniger als eine
Sekunde betragen.
Eine besondere Anforderung an die Ergonomie stellt die Reihenfolge der Informations-
ausgabe dar. Da ein Screenreader alles von links nach rechts vorliest und der Nutzer oder
die Nutzerin keine M¨
oglichkeit hat, einzelne Worte zu ¨
uberspringen, m¨
ussen die Informa-
tionen so gestaffelt sein, dass immer die wichtigste Information zuerst kommt. So kann
der Nutzer oder die NutzerIn unwichtige Informationen gezielt ¨
uberspringen. Eine gute
Staffelung beginnt mit der Art des Punktes - beispielsweise
"
Kiosk". Es folgen Entfer-
nung und Richtung des Punktes. Konkret k¨
onnte das so aussehen:
"
Kiosk - 50 Meter -
zwei Uhr". So werden eventuell unbrauchbare Informationen gar nicht erst angesagt.
2.3
OpenStreetMap
Die Basis der Kartendaten f¨
ur die Software dieser Bachelorarbeit bildet das
OpenStreetMap-Projekt. Vergleiche: (
Wikipedia
,
2010b
)
2.3.1
Geschichte
OpenStreetMap ist ein Projekt, das sich zum Ziel gesetzt hat, Geodaten frei verf¨
ugbar
bereitzustellen. Im Juli 2004 von Steve Coast in London, England, gegr¨
undet, steigen so-
wohl Mitgliederzahl als auch Informationsdichte der Karte seither exponentiell an. Bereits
im Juli 2006 waren etwa 2.500 BenutzerInnen registriert, die zu diesem Zeitpunkt ¨
uber
neun Millionen Wegpunkte in das System eingetragen hatten. Im April desselben Jah-
res wurde die OpenStreetMap-Foundation gegr¨
undet, welche Spenden sammelt und das
Gremium zur Entscheidungsfindung bildet. Als internationale Non-Profit-Organisation
1
sind die Ziele der Foundation die Erzeugung, Verteilung und Vergr¨
oßerung des geografi-
schen Datenbestands sowie die freie Bereitstellung eben dieses zum allgemeinen Gebrauch.
Im Januar 2008 wurde der Import der TIGER
2
-Datenbank abgeschlossen. Dieser Import
deckte große Teile der USA ab. Zurzeit (Stand Juni 2010) beteiligen sich mehr als 266.000
BenutzerInnen
3
an dem OpenStreetMap-Projekt.
1
Als Non-Profit-Organisation (NPO) bezeichnet man jene Organisationen in frei-gemeinn¨
utziger oder
privat-gewerblicher Tr¨
agerschaft, welche erg¨
anzend zu Staat und Markt bestimmte Zwecke der Bedarfsde-
ckung, F¨
orderung oder Interessenvertretung beziehungsweise Beeinflussung (Sachzieldominanz) f¨
ur ihre
Mitglieder (Selbsthilfe) oder Dritte wahrnehmen (
Wikipedia
,
2010a
).
2
Der Ausdruck
"
TIGER" steht f¨
ur T opologically I ntegrated Geographic E ncoding and Referencing,
das Datenbanksystem, welches vom U.S. Census Bureau entwickelt wurde, um unter anderem dessen
Bedarf an kartografischem Material f¨
ur die alle zehn Jahre stattfindende Volksz¨
ahlung zu decken.
Vergleiche: (
Census Bureau
,
2005
)
3
Vergleiche:
http://www.openstreetmap.org/stats/data_stats.html
10
2.3
OpenStreetMap
2
ANFORDERUNGSANALYSE
2.3.2
Lizenz
Die Daten stehen unter der Creative Commons Attribution-ShareAlike 2.0
4
(CC-BY-
SA) Lizenz. Es bestehen allerdings einige Probleme, die mit dieser Lizenz einhergehen:
Da die CC-BY-SA allein auf dem Urheberrecht basiert, ist es beispielsweise fraglich,
ob - beispielsweise in den USA - die Daten durch sie ¨
uberhaupt gesch¨
utzt werden k¨
onnen.
Der Grundsatz
"
facts are free"
5
k¨
onnte dem im Wege stehen. Daher ist das erkl¨
arte Ziel
der OpenStreetMap-Foundation die Migration auf die Open Database License
6
. Sie be-
zieht sich nicht nur auf das Urheberrecht, sondern auch auf die Datenbankgesetzgebung.
Die Beitragenden m¨
ussten dann den neuen Lizenzbedingungen zustimmen; andernfalls
gehen sie das Risiko ein, dass ihre Daten aus dem Bestand gel¨
oscht werden.
Ferner verlangt die Share-Alike-Klausel der CC-Lizenz, dass abgeleitete Projekte unter
derselben Lizenz stehen m¨
ussen. Dies macht es unm¨
oglich, Daten, die unter anderer Lizenz
stehen, mit Daten aus dem OpenStreetMap-Projekt zu kombinieren, ohne die zus¨
atzlichen
Daten auch unter CC-BY-SA-Lizenz zu stellen.
Es sei noch erw¨
ahnt, dass die meiste Software, die zum Bearbeiten und Konvertieren
der Daten verwendet wird, unter GNU General Public License
7
steht.
2.3.3
Technik
Die OpenStreetMap-Foundation betreut die Kern-Server und -Infrastruktur, die in Lon-
don am UCL
8
betrieben werden. Die Server-Farm besteht aus einem Datenbankserver, ei-
nem Webserver, drei Applikationsservern f¨
ur die APIs sowie einem Tile-Rendering-Server.
Außerdem betreibt ein externer Anbieter im Auftrag der OpenStreetMap-Foundation
einen Wiki-Server sowie eine virtuelle Maschine, in der Mailinglisten und Subversion ge-
hostet werden.
9
Der Datenbank-Server
"
smaug" wird mit einem Ubuntu 8.04 LTS Server amd64 betrieben
und f¨
uhrt eine PostgreSQL 8.3 Datenbank aus. Ihm stehen zwei Intel Xeon Prozessoren
(E5420 Quad Core 2.5Ghz) zur Verf¨
ugung, die sich mit 32GB Arbeitsspeicher und etwa
4.600GB Festplattenspeicher ein Geh¨
ause teilen. Die Webseite und die APIs sind nahezu
vollst¨
andig in Ruby programmiert.
Auf
dem
Tile-Rendering-Server
l¨
auft
das
Programm
Mapnik,
welches
die
Standard-Darstellung
der
OpenStreetMap
rastert
10
.
Diese
Daten
werden
als
PNG (Portable Network Graphics) in einer PostGIS-Datenbank gespeichert. Der Ren-
derer ist so implementiert, dass nur Kacheln gerendert werden, die sich auch ver¨
andert
haben. Abh¨
angig von der aktuellen Last erreicht der Server eine auf bis zu zehn Minuten
aktuelle Darstellung.
4
Vergleiche:
http://creativecommons.org/licenses/by-sa/2.0/de/
5
Sinngem¨
aß: Tatsachen haben keine sch¨
opferische Eigenart
6
Vergleiche:
http://wiki.openstreetmap.org/wiki/Open_Database_License
7
Vergleiche:
http://de.wikipedia.org/wiki/GNU_General_Public_License
8
UCL - University College London -
http://de.wikipedia.org/wiki/University_College_London
9
Vergleiche:
http://wiki.openstreetmap.org/wiki/Server
10
Vergleiche: (
Wikipedia
,
2010c
)
11
2.3
OpenStreetMap
2
ANFORDERUNGSANALYSE
Als bedeutende Alternative zu Mapnik sei noch das Tiles@Home-Projekt genannt. Unter
Zuhilfenahme einer eigens f¨
ur die OpenStreetMap geschriebenen Software namens Osma-
render werden Kacheln verteilt berechnet. Jeder und jede Internetnutzende kann seinen
beziehungsweise ihren Computer zum Berechnen miteinsetzen. Hierf¨
ur muss lediglich ein
Client heruntergeladen werden, der neue Aufgaben vom Osmarender-Server zugeteilt be-
kommt und sp¨
ater die berechneten Kacheln als PNG wieder zur¨
uckschickt.
2.3.4
Datenquellen und Quellformate
Die OpenStreetMap bezieht ihre Daten aus folgenden Quellen:
GPS-Tracks
GPS-Tracks oder Track-Logs
11
sind eine Sammlung von Punkten mit Koordinaten in
einer konkreten Reihenfolge (meist zeitlich aufsteigend geordnet), die eine Strecke be-
schreiben. Solche Logs entstehen mithilfe von GPS-Loggern oder GPS-Empf¨
angern plus
Software, die diese Funktion unterst¨
utzt. Die Strecken, die von solch einem Ger¨
at zum
Beispiel beim Ablaufen oder Abfahren von Straßen und Wegen entstehen, beinhalten aller-
dings noch keine Informationen wie Straßenname oder Hausnummer. Diese m¨
ussen dann
sp¨
ater am Computer nachgetragen werden. Das g¨
angigste Datenformat ist hierbei gpx.
Mittlerweile unterst¨
utzen sogar Navigationsger¨
ate die Funktion, GPS-Tracks zu schreiben.
Luftbilder
Die gemeinfreien Landsat-7-Satellitenaufnahmen lassen sich einblenden und erleichtern
die Orientierung und damit die Bearbeitung. Leider ist die Aufl¨
osung teilweise so gering,
dass die Aufnahmen nicht zum Abzeichnen verwendet werden k¨
onnen.
Yahoo hat unl¨
angst Luftbilder gespendet, von denen abgezeichnet werden darf.
12
Das bayerische Landesamt f¨
ur Vermessung und Geoinformation hat Orthofotos der Ober-
pfalz in Zwei-Meter-Aufl¨
osung zum Abzeichnen bereitgestellt, um im Rahmen eines bis
Ende M¨
arz 2009 gelaufenen Pilotprojektes Erfahrungen in der Zusammenarbeit mit Open-
StreetMap zu sammeln.
13
Lokales NutzerInnen-Wissen
Obschon GPS-Tracks und Luftbilder einen, wenn nicht den grundlegenden Ursprung der
Daten f¨
ur die OpenStreetMap darstellen, sind viele brauchbare Informationen auch ohne
Zugang zu diesen Quellen erfassbar. Sobald das Grundger¨
ust aus Straßen und Wegen steht,
k¨
onnen weitere Informationen wie Hausnummern, Namen und Verkehrsbeschr¨
ankungen
hinzugef¨
ugt werden. Dies gilt auch f¨
ur Einrichtungen wie Kirchen, Gesch¨
afte, Kinderg¨
arten,
Briefk¨
asten, Telefonzellen und ¨
Ahnliches. Falls man sich das Editieren der OpenStreetMap-
Daten nicht zutraut, kann man auch ohne Anmeldung auf der OpenStreetBugs-Website
14
11
Deutsch: Weg-Logbuch, Weg-Protokoll
12
Vergleiche:
http://www.opengeodata.org/?p=120
13
Vergleiche:
http://wiki.openstreetmap.org/wiki/DE:Luftbilder_aus_Bayern
14
http://wiki.openstreetmap.org/wiki/DE:Fehler_melden
12
2.3
OpenStreetMap
2
ANFORDERUNGSANALYSE
Fehler oder Unvollst¨
andigkeiten melden. Dann nehmen sich bei OSM registrierte Benut-
zerInnen dieser Meldungen an und editieren gegebenenfalls die Karte. BenutzerInnen, die
aktiv an der Karte mitarbeiten, werden im OSM-Kontext als Mapper bezeichnet.
2.3.5
Details zum Datenformat
Die OpenStreetMap-Daten bestehen - vereinfacht dargestellt - aus drei Grundelementen.
Der Inhalt dieser Simplifizierung ist ausreichend, um die relevanten Kartendaten, auf die
sich das Programm st¨
utzt, zu verstehen. Die Grundelemente sind:
Node (Punkt)
Eine Node besteht mindestens aus geografischer Breite und L¨
ange (lat, lon), einer ein-
deutigen Identifikationsnummer (id), dem Zeitpunkt der letzten ¨
Anderung (timestamp),
BernutzerInnenkennung und -nummer (user, uid) und dem Changeset, innerhalb dessen
die letzte ¨
Anderung durchgef¨
uhrt wurde. Außerdem darf eine Node noch beliebig viele
Tags (zur Erkl¨
arung s.u.) enthalten. Breite und L¨
ange werden in Grad mit bis zu sieben
Nachkommastellen gespeichert. Im ung¨
unstigsten Fall, am ¨
Aquator, betr¨
agt die Genau-
igkeit etwa 1cm. Dies berechnet sich wie folgt:
1 Seemeile (sm) = 1.852 Meter (m)
1
geografischer L¨
ange = 60sm = 60 1.852m = 111.120m
111.120m 0, 0000001 = 0, 011112m = 1, 1112cm
Da die Abst¨
ande zwischen den L¨
angengraden zum Nord- und S¨
udpol hin kleiner werden,
ist die Genauigkeit in unseren Breitengraden sogar noch h¨
oher. Dieses Maß an Genauigkeit
ist f¨
ur alle derzeit bekannten Einsatzgebiete ausreichend. Vor allem, wenn man bedenkt,
dass GPS im besten Fall gerade einmal eine Genauigkeit von ±5m erlaubt.
Eine Node kann Teil eines Ways (zur Erkl¨
arung s.u.) oder auch einer Relation (zur Er-
kl¨
arung s.u.) sein, um beispielsweise Straßen oder Wege zu st¨
utzen. Außerdem lassen sich
Nodes auch f¨
ur so genannte Points of Interest (POI) verwenden. Hier ein Beispiel einer
Node, die einen POI darstellt:
<node id="267287957" lat="49.4210403" lon="8.6820735"
user="aikon" uid="44329" visible="true" version="4"
changeset="128164" timestamp="2008-08-07T18:58:26Z">
<tag k="amenity" v="hospital"/>
<tag k="building" v="hospital"/>
<tag k="created_by" v="JOSM"/>
<tag k="name" v="St. Elisabeth"/>
</node>
An diesem Beispiel sind die optionalen Bestandteile einer Node gut zu erkennen.
Auch kann eine Node sowohl ein POI als auch Teil eines Ways oder einer Relation sein.
Dies ist zum Beispiel bei Straßenbahnhaltestellen der Fall.
13
2.3
OpenStreetMap
2
ANFORDERUNGSANALYSE
Way (Weg)
Ein Way besteht in der Regel aus einer Menge von geordneten Punkten und kann Teil
einer Relation sein. Bestandteile sind mindestens eine eindeutige Identifikationsnummer
(id), BenutzerInnenkennung und -nummer (user, uid), Zeitpunkt der letzten ¨
Anderung
(timestamp), sowie das Changeset, innerhalb dessen die letzte ¨
Anderung durchgef¨
uhrt
wurde. Außerdem muss mindestens eine Node enthalten sein, damit der Weg g¨
ultig wird.
Hier ein Beispiel einer Straße in einem Wohngebiet:
<way id="24962245" user="loomis" uid="44444" visible="true"
version="3" changeset="299973" timestamp="2008-08-17T12:17:42Z">
<nd ref="271259886"/>
<nd ref="271259921"/>
[...]
<nd ref="271260108"/>
<nd ref="288733253"/>
<tag k="highway" v="residential"/>
<tag k="name" v="Im Hirschmorgen"/>
</way>
Die <nd ref="..." />-Eintr¨
age referenzieren eine existierende Node. Weiter ist anhand
der Tags ersichtlich, dass es sich um eine Wohnstraße (highway=residential) mit dem
Namen
"
Im Hirschmorgen" (name=Im Hirschmorgen) handelt.
Ein Sonderfall von Ways sind so genannte Areas. Dies sind Wege, deren Start- und End-
punkt dieselbe Node sind; sie bilden also ein geschlossenes Wegesystem.
Relation
Eine Relation kann aus beliebig vielen anderen Nodes, Ways und sogar Relations beste-
hen. Ein Beispiel, an dem die Sinnhaftigkeit einer Relation deutlich wird, ist eine Busroute.
Hier ein verk¨
urztes Beispiel:
<relation id="65272" user="mahau" uid="160164" visible="true"
version="10" changeset="4858020" timestamp="2010-05-30T22:08:49Z">
<member type="node" ref="329598535" role="stop_16"/>
<member type="node" ref="329598540" role="stop_3"/>
<member type="node" ref="329598545" role="stop_19"/> // Haltestelle
[...]
<member type="way" ref="4379786" role=""/>
<member type="way" ref="4428616" role=""/>
// Linienf¨
uhrung
<member type="way" ref="4452278" role=""/>
[...]
<tag k="name" v="De_RNV_27"/>
<tag k="operator" v="RNV"/>
// Verkehrsverbund
<tag k="ref" v="27"/>
<tag k="route" v="bus"/>
// Verkehrsmittel
<tag k="type" v="route"/>
// Relationstyp
</relation>
14
2.3
OpenStreetMap
2
ANFORDERUNGSANALYSE
Anhand der member- und tag-Eintr¨
age erschließen sich folgende Informationen:
Diese Busroute (type=route, route=bus) der RNV (operator=RNV) tr¨
agt den Namen
"
De RNV 27" (name=De_RNV_27). Sie besteht aus mehreren Wegen, auf denen
die Route verl¨
auft. Die Nodes, die referenziert werden, beschreiben die Bushaltestellen
(role=stop_x).
Zus¨
atzlich zu Node, Way und Relation existieren noch zwei weitere Elemente, die der
Erw¨
ahnung bed¨
urfen:
Tag
Ein Tag ist ein optionaler Eintrag in einem der drei Grundelemente der OSM. Er be-
steht immer aus einem Schl¨
ussel und einem Wert (Key und Value). Diese Paare k¨
onnen
von beliebigem Text in beliebiger Sprache und beliebiger Schrift sein. Es wird allerdings
empfohlen, Vorgaben bestehender Tags zu verwerden. N¨
ahere Informationen hierzu finden
sich im Wiki
15
.
Changeset
Ein Changeset in der OSM ist vergleichbar mit einer Transaktion eines Datenbankma-
nagementsystems. Es beinhaltet alle ¨
Anderungen an Nodes, Ways und Relations, die ein
Nutzer oder eine Nutzerin auf einmal an den OSM-Server schickt. Auf diese Weise l¨
asst
sich Vandalismus auch ¨
uber gr¨
oßere Bereiche effektiv beheben.
2.3.6
Informationsdichte
Die Informationsdichte kann in Deutschland - vor allem in gr¨
oßeren St¨
adten und insbeson-
dere in Universit¨
atsst¨
adten - als gut bis sehr gut bezeichnet werden. L¨
andliche Gebiete hin-
gegen sind teilweise nur sporadisch erfasst. Jedoch d¨
urften nach eigener Einsch¨
atzung die
Zeiten, in denen f¨
ur kleinere Orte nur die Durchfahrtsstraßen kartografiert sind, gr¨
oßten-
teils vorbei sein. Zur Erweiterung der Informationsdichte werden in wenig erfassten Ge-
genden gerne so genannte Mapping-Parties veranstaltet: ¨
Uber das Wiki auf OpenStreet-
map.org vereinbaren Mapper einen Zeitpunkt, zu dem sie sich an einem Ort mit geringer
Informationsdichte treffen, um dort gemeinsam die Karte zu vervollst¨
andigen. Ein Service
der Firma
"
Logiball" erm¨
oglicht es seit neustem einen Vergleich der Kartenmaterials der
OpenStreetMap mit dem von kommerziellen Anbietern(
Ihlenfeld
,
2010
).
15
http://wiki.openstreetmap.org/wiki/DE:Map_Features
15
2.4
GPS
2
ANFORDERUNGSANALYSE
2.4
GPS
Die Wahl des Systems, das die Positionierung bestimmt, fiel nicht schwer. Zum Zeitpunkt
der Entscheidung (M¨
arz 2010) gab es nur ein satellitengest¨
utztes globales Positionierungs-
system, das gr¨
oßtenteils st¨
orungsfrei und außerdem f¨
ur die zivile Nutzung frei zug¨
anglich
ist: Das amerikanische
"
Global Positioning System", kurz GPS. Es besteht aus mindestens
24 Satelliten, die die Erde in einer H¨
ohe von 20.183 km umkreisen. Immer mindestens vier
Satelliten bewegen sich auf jeweils einer der sechs Bahnebenen, die um 55
gegen die ¨
Aqua-
torebene geneigt und gegeneinander um jeweils 60
verdreht sind. Durch diese Anordnung
wird gew¨
ahrleistet, dass immer mindestens vier Satelliten von jedem Punkt der Erde aus
sichtbar sind. Ein Satellit hat eine erwartete Lebensdauer von siebeneinhalb Jahren. In
der Praxis wird dieser Wert h¨
aufig ¨
uberschritten. Um Ausf¨
allen ohne Probleme standhal-
ten zu k¨
onnen, wurden bis zu 31 Satelliten in den Orbit gebracht. So hat man auch unter
schlechten Bedingungen oft den Empfang von f¨
unf oder mehr Satelliten. (
Roth
,
2002
)
2.4.1
NMEA-Protokoll
Die NMEA (National Marine Electronics Association) ist die nationale Vereinigung f¨
ur
Marineelektronik der Vereinigten Staaten. Sie hat unter anderem das NMEA-0183 Proto-
koll definiert, an den sich praktisch alle positionsbestimmenden Ger¨
ate halten. Der Stan-
dard sieht vor, dass in einem Netz nur ein Sender (in unserem Fall der GPS-Empf¨
ager),
aber beliebig viele Empf¨
anger (in unserem Fall ein mobiles Endger¨
at) vorhanden sein
d¨
urfen. Der Sender stellt seine Daten ¨
uber eine standardm¨
aßige RS-232-Schnittstelle zur
Verf¨
ugung, die mit einer Datenrate von 4.800 baud (Zeichen pro Sekunde) ¨
ubertr¨
agt. Die
Beschr¨
ankung auf einen Sender hat den Vorteil, dass eventuelle ¨
Uberschneidungen mit
anderen Sendern nicht auftreten und dadurch die Zerst¨
orung der Informationen durch
Kollisionen weitestgehend ausgeschlossen werden kann.
Datenformat
Die Daten werden im ASCII-Zeichensatz codiert. Sie werden in S¨
atze gegliedert. Jeder
Satz beginnt mit einem $-Symbol, endet mit einem CR (Carriage-Return, Wagenr¨
ucklauf)
und einem LF (Line-Feed, Zeilenvorschub). Er darf inklusive $ und CR/LF maximal 82
Zeichen lang sein. Getrennt werden die einzelnen Informationen in einem Satz durch ein
Komma. Falls eine Information nicht verf¨
ugbar ist, so wird nur ein Komma in den Satz
geschrieben. So l¨
asst sich durch Z¨
ahlen der Kommas immer die richtige Position in einem
Satz finden. Oft wird eine optionale Pr¨
ufsumme an das Ende eines Satzes geh¨
angt. Diese
wird mit einem * eingeleitet. Sie berechnet sich durch eine bitweise XOR-Verkn¨
upfung
der einzelnen Zeichen zwischen $ und * und wird als Hexadezimalzahl dargestellt.
Die S¨
atze werden mit einem f¨
unf Zeichen langen Codewort eingeleitet. Der Empf¨
anger
kann dann aufgrund des Codewortes darauf schließen, welche Information er an welcher
Stelle des Satzes erwarten darf. Eingegangen wird im Folgenden nur auf die beiden Codes,
die die Anwendung auch verwendet.
16
2.4
GPS
2
ANFORDERUNGSANALYSE
Datens¨
atze
GPRMC
Der erste Datensatz, den ich beschreiben m¨
ochte, nennt sich GPRMC. GP steht f¨
ur die
Verwendung eines GPS-Empf¨
angers und RMC steht f¨
ur
"
Recommended Minimum Sen-
tenc C" ( ¨
Ubersetzt: Empfohlener Mindestdatensatz C). Er wird von praktisch jedem GPS-
Empf¨
anger ¨
ubertragen. Ein Beispieldatensatz k¨
onnte so aussehen:
$GPRMC,191410,A,4735.5634,N,00739.3538,E,0.0,0.0,181102,0.4,E,A*19
Von links nach rechts gelesen beinhaltet dieser Satz folgende Informationen:
· Uhrzeit der Bestimmung: 19:14:10 (UTC)
· Status der Bestimmung: A = Active (g¨
ultig); V = void (ung¨
ultig)
· Breitengrad mit (Vorzeichen)-Richtung (N = Nord, S = S¨
ud): 47
35.5634' Nord
· L¨angengrad mit (Vorzeichen)-Richtung (E = Ost, W = West): 7
39.3538' Ost
· Geschwindigkeit ¨
uber Grund (Knoten)
· Bewegungsrichtung in Grad
· Datum: 18.11.2002
· Missweisung
· Art der Bestimmung: A = autonomous (selbst); D = differential; E = estimated
(gesch¨
atzt); N = not valid (ung¨
ultig); S = simulator
Der L¨
angengrad ben¨
otigt drei Stellen, da er von 0
bis 180
Ost bzw. West reicht. Der
Breitengrad hingegen ben¨
otigt nur zwei Stellen, da er von 0
bis 90
Nord bzw. S¨
ud reicht.
17
Ende der Leseprobe aus 81 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2010, Konzeption und Implementierung eines Orientierungssystems für Menschen mit Sehbehinderung auf Java ME, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/228014
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter +49(0)176-85996762 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare