Ansätze zur präziseren Positionsbestimmung mit GPS

Transcription

Hochschule Darmstadt
- Fachbereich Informatik -
Ansätze zur präziseren Positionsbestimmung mit GPS-Empfängern aus dem
Niedrigpreissegment und deren prototypische Anwendung in einem automatisierten,
mobilen Kartographie-Szenario
Abschlussarbeit zur Erlangung des akademischen Grades
Master of Science (M.Sc.)
vorgelegt von
Tobias Eckerth
29.03.2010
Referent: Prof. Dr. Joachim Wietzke
Korreferentin: Prof. Dr. Uta Störl
Erklärung
Ich versichere hiermit, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die im
Literaturverzeichnis angegebenen Quellen benutzt habe. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten
oder noch nicht veröffentlichten Quellen entnommen sind, sind als solche kenntlich gemacht. Die Zeichnungen oder
Abbildungen in dieser Arbeit sind von mir selbst erstellt worden oder mit einem entsprechenden Quellennachweis
versehen. Diese Arbeit ist in gleicher oder ähnlicher Form noch bei keiner anderen Prüfungsbehörde eingereicht
worden.
Darmstadt, den 29.03.2010
ii
Abstrakt
Navigationssysteme sind aus unserem täglichen Umfeld nicht mehr wegzudenken. Nicht nur Autofahrer profitieren von
den elektronischen Beifahrern - mittlerweile wissen auch Fußgänger die Vorzüge der Geräte zu schätzen. Damit ein
solches System erfolgreich arbeiten kann müssen zwei Voraussetzungen erfüllt sein: aktuelles Kartenmaterial und eine
möglichst genaue Position – meist bestimmt durch in den Geräten eingebaute GPS-Empfänger. Beide Thematiken
werden in der vorliegenden Arbeit näher beleuchtet und untersucht.
Die Tatsache, dass ein mobiler Internetzugang mit einer entsprechenden Daten-Flatrate heute keine Seltenheit mehr
darstellt, ermöglicht es, Kartenmaterial und andere Informationen direkt aus dem Internet zu laden. Bei Smartphones
und Mobiltelefonen ist dies heute bereits Stand der Technik. Bei dedizierten Navigationsgeräten sind jedoch erst in
sehr geringem Maße die dafür notwendigen GSM-Modems verbaut. Der besondere Vorteil an diesem Vorgehen ist die
hohe Aktualität der Daten. Dieser Vorsprung kann insbesondere bei Verwendung einer offenen Plattform, wie
OpenStreetMap, noch weiter ausgebaut werden, wenn ein Navigationssystem in der Lage ist, seine Datenquelle mit
neuen Karteninformationen selbständig zu aktualisieren. Etwa in dem im Datenmaterial nicht vorhandene Straßen
ergänzt werden. Um dies jedoch zu ermöglichen, wird eine ausreichend hohe Genauigkeit der GPS-Position
vorausgesetzt. Davon kann jedoch im Allgemeinen nicht ausgegangen werden, da handelsübliche Empfänger meist
nur mit Genauigkeiten im 10m-Bereich aufwarten können.
Im Rahmen der vorliegenden Arbeit soll ein Konzept erarbeitet und evaluiert werden, das sowohl die Integration von
online verfügbarem Kartenmaterial, als auch darauf aufbauend ein automatisiertes Mapping beinhaltet. Es wird
untersucht, welche Kartendaten überhaupt erfasst werden können und welche Fehlerquellen berücksichtigt werden
sollten. Vor allem aber werden verschiedene gängige Verfahren zur hierfür notwendigen Genauigkeitssteigerung von
GPS beleuchtet und bewertet, sowie ein selbst entwickelter Ansatz vorgestellt, evaluiert und prototypisch umgesetzt.
iii
Abstract
We can hardly imagine our daily life without Navigation systems. Not only car drivers profit by the electronic
passengers, meanwhile also pedestrians appreciate the advantages of such devices. To make such a system work
correctly, two requirements have to be fulfilled. First of all an up-to-date map material is necessary. In the second
Place a system needs the best possible accuracy in position. This is mostly provided by GPS-receivers, installed in the
devices. Both subjects – map data and position accuracy – are targeted and examined more closely in this thesis.
Mobile internet access with an appropriate data flatrate is nowadays no more a curiosity. This enables downloading
map data and other information straight from the Internet. For smartphones and mobile phones this approach is state
of the art. For dedicated navigation devices this is not the usual strategy, as necessary GSM-Modems are installed
only in a minor degree. The special advantage of getting the map data directly from the web is the highest possible
actuality of the data. This winning behalf will be increased by usage of an open platform like OpenStreetMap, when a
navigation device is able to update its data sources with map data independently. For example when a device adds
missing roads. To make this possible, an adequate accuracy of the GPS-Position is required. Usually this can’t be
assumed, as commercial receivers only have an accuracy in a range of 10 meters.
In the context of the present thesis, a concept, including integration of online available map data as well as
autonomous mapping based on this, shall be developed and evaluated. It is determined, which types of map data can
be captured and which sources of errors have to be considered. Especially different common procedures to increase
accuracy of GPS are examined, as well as a self developed approach will be introduced, evaluated and prototypically
implemented.
iv
Danksagung
Im Rahmen meiner Arbeit mussten viele Hindernisse aus dem Weg geräumt oder umschifft werden. Daher möchte ich
an dieser Stelle die Möglichkeit nutzen, ein kleines Dankeschön an all jene zurück zu geben, die mich in den
vergangenen Monaten unterstützt haben. Zunächst Frau Prof. Dr. Uta Störl und Herrn Prof. Dr. Joachim Wietzke für die
Übernahme der Betreuung dieser Arbeit. Außerdem dem gesamten Team des Labors InCarMultimedia, welches mir
mit hilfreichen Tipps oft zur Seite stand und mich bei der Beschaffung von Geräten unterstützt hat.
Großen Dank muss ich auch den zahlreichen externen Unterstützern zollen, die die Arbeit auf die unterschiedlichsten
Arten begleiteten. Allen voran Herr Gerhard Hamel vom hessischen Landesamt für Bodenmanagement und
Geoinformation, sowie dem Bundesamt für Kartographie und Geodäsie für die Zurverfügungstellung der GPSKorrekturdaten und für ein offenes Ohr bei Fragen aller Art. Weiterhin Oliver Lauer und Dietmar Bönning vom
Fachbereich Bauingenieurwesen, der Gemeindeverwaltung Laufach und dem Architekturbüro Franz für sachdienliche
Hinweise auf der Suche nach geeigneten Lagefestpunkten.
Auch möchte ich meinen Korrektoren Andreas, Michael und Tobias danken, die geholfen haben den ein oder anderen
groben Schnitzer in der Arbeit auszubügeln.
Zu guter Letzt darf ich Sandra nicht vergessen, die mich immer wieder zur Disziplin angehalten und bis zur letzten
Sekunde das Projekt mitgetragen hat.
„Auch die längste Reise beginnt mit dem ersten Schritt.“
(Laotse, ca. 6. Jhd. v. Chr.)
v
Inhaltsverzeichnis
KAPITEL 1 EINFÜHRUNG ................................................................................................................................................................................................................1
1.1 Motivation ................................................................................................................................................................................................................1
1.2 Problemstellung ......................................................................................................................................................................................................2
1.3 Systemumgebung ...................................................................................................................................................................................................3
1.4 Überblick .................................................................................................................................................................................................................3
TEIL I GRUNDLAGEN ....................................................................................................................................................................................................................4
KAPITEL 2 GEODÄSIE ....................................................................................................................................................................................................................5
2.1 Definition .................................................................................................................................................................................................................5
2.2 Koordinatensysteme ...............................................................................................................................................................................................7
2.3 Geodätisches Datum ..............................................................................................................................................................................................8
2.4 Wichtige Berechnungen .......................................................................................................................................................................................16
2.5 Lagefestpunkte .....................................................................................................................................................................................................19
KAPITEL 3 SATELLITENGESTÜTZTE POSITIONSBESTIMMUNG MIT GPS ..............................................................................................................................................20
3.1 Entwicklung ...........................................................................................................................................................................................................20
3.2 Systemaufbau .......................................................................................................................................................................................................21
3.3 GPS-Signal ............................................................................................................................................................................................................24
3.4 Positionsbestimmung ............................................................................................................................................................................................28
3.5 Alternative Systeme ..............................................................................................................................................................................................31
3.6 Genauigkeit ...........................................................................................................................................................................................................33
3.7 Methoden zur Verbesserung von GPS ................................................................................................................................................................42
3.8 NMEA Standard ....................................................................................................................................................................................................50
3.9 Praktische Untersuchungen .................................................................................................................................................................................52
KAPITEL 4 OPENSTREETMAP .......................................................................................................................................................................................................62
4.1 Geodaten ..............................................................................................................................................................................................................62
4.2 Projektüberblick ....................................................................................................................................................................................................63
4.3 Datenmodell ..........................................................................................................................................................................................................66
4.4 Visualisierung ........................................................................................................................................................................................................69
4.5 Schnittstellen .........................................................................................................................................................................................................71
4.6 Mapping ................................................................................................................................................................................................................73
4.7 Mobile Karten-Nutzung .........................................................................................................................................................................................75
TEIL II KONZEPT UND DURCHFÜHRUNG ................................................................................................................................................................................78
KAPITEL 5 KONZEPT....................................................................................................................................................................................................................79
5.1 Vorüberlegung ......................................................................................................................................................................................................79
5.2 Architektur .............................................................................................................................................................................................................80
5.3 Positionsverbesserung ..........................................................................................................................................................................................80
5.4 Kartendaten...........................................................................................................................................................................................................82
5.5 Automatisiertes Mapping ......................................................................................................................................................................................83
5.6 Kommunikationsmodell .........................................................................................................................................................................................86
5.7 Zusammenfassung................................................................................................................................................................................................87
KAPITEL 6 IMPLEMENTIERUNG ......................................................................................................................................................................................................89
6.1 Entwicklungsumgebung .......................................................................................................................................................................................89
vi
Inhaltsverzeichnis
6.2
6.3
6.4
6.5
6.6
6.7
Hardwareanbindung .............................................................................................................................................................................................89
Bibliotheken...........................................................................................................................................................................................................90
Komponentenstruktur ............................................................................................................................................................................................91
Geodatenverarbeitung ..........................................................................................................................................................................................93
Positionsbestimmung ............................................................................................................................................................................................96
Mapping ................................................................................................................................................................................................................97
KAPITEL 7 ZUSAMMENFASSUNG UND AUSBLICK ..........................................................................................................................................................................100
7.1 Bewertung der Ergebnisse .................................................................................................................................................................................100
7.2 Zusammenfassung..............................................................................................................................................................................................103
7.3 Ausblick ...............................................................................................................................................................................................................104
TEIL III ANHANG ........................................................................................................................................................................................................................106
ANHANG A STICHWORTVERZEICHNIS ..........................................................................................................................................................................................107
ANHANG B ABKÜRZUNGSVERZEICHNIS .......................................................................................................................................................................................110
ANHANG C ABBILDUNGSVERZEICHNIS ........................................................................................................................................................................................112
ANHANG D TABELLENVERZEICHNIS ............................................................................................................................................................................................115
ANHANG E LISTINGS .................................................................................................................................................................................................................117
ANHANG F LITERATURVERZEICHNIS ............................................................................................................................................................................................118
ANHANG G INHALT DER CD-ROM .............................................................................................................................................................................................126
vii
Kapitel 1
Einführung
Gehe nicht, wohin der Weg führen mag, sondern dorthin, wo kein Weg ist, und hinterlasse eine Spur.
(Jean Paul, 21.03.1763 - 14.11.1825)
Kapitel 1
Einführung
Seit Anbeginn der Aufzeichnungen des modernen Menschen stellen Karten der Welt wichtige Zeugnisse der
Geschichte dar. Sie dokumentieren die Verbreitung des Menschen über den gesamten Erdball und spiegeln den Grad
der Erforschung unseres Planeten zur jeweiligen Zeit wieder. Auch heute noch spielen Kartendaten eine
entscheidende Rolle. Sie stellen die Grundlage jeglicher Form mobiler Navigation dar – sei es nun klassisch mit Karte
und Kompass oder elektronisch mit Hilfe eines Navigationssystems. Mobile Navigation ist heutzutage ein wichtiger
Bestandteil der Automobiltechnik. Kaum ein Fahrzeug ist noch auf deutschen Autobahnen ohne „Navi‚ unterwegs und
auch im Bereich der Fussgängernavigation ist viel Bewegung. Der Markt an Navigationssystemen ist mittlerweile kaum
mehr überschaubar. Waren früher Navigationssysteme auf im Fahrzeug festeingebaute Systeme mit einfacher
Pfeildarstellung beschränkt, so hat heutzutage jeder genug Rechenleistung in seinem Mobiltelefon integriert, dass es
kein Problem ist, hochauflösende Navigationskarten darzustellen. Dank GPS-Empfänger – mittlerweile auch nahezu
Standardausstattung in modernen Smartphones – stellt auch eine ungefähre Positionsbestimmung keine wirkliche
Herausforderung mehr dar.
1.1
Motivation
Eine wichtigte Voraussetzung für die Nutzung solcher Systeme ist das Vorhandensein von akkuratem und aktuellem
Kartenmaterial. Dedizierte Navigationsgeräte bieten zu diesem Zweck die Möglichkeit von Kartenupdates ihres
internen Kartenmaterials an. Diese sind zumeist kostenpflichtig bzw. maximal für einen gewissen Zeitraum
subventioniert und können oft nur über den heimischen PC oder per Update DVD eingespielt werden. Das
Kartenmaterial steht in den allermeisten Fällen auch nur für ein eingeschränktes Gebiet zur Verfügung – etwa
Deutschland, Österreich, Schweiz oder bestenfalls Westeuropa. Wer mit seinem deutschen Navigationssystem z.B.
nach Australien möchte, ist in jedem Fall gezwungen neue Karten kostspielig zu erwerben. Auch gibt es immer noch
Gebiete in der Welt, die von den gängigen Lieferanten von Navigationskarten nur unzureichend abgedeckt sind. Dies
sind nicht nur Gegenden in infrastrukturschwachen Ländern der Dritten Welt, sondern auch Gebiete hierzulande,
welche ausschließlich für eingeschränkte Personenkreise interessant sind, wie z.B. Wald- und Forstwege.
Die immer größer werdende Verbreitung sogenannter Daten-Flatrates bei Mobilfunktarifen und die zunehmende
Verfügbarkeit mobiler Breitbandzugänge ermöglicht eine weitere Form der Datenaktualisierung: das Beziehen des
1
Kapitel 1
Einführung
Kartenmaterials direkt aus dem Internet. In den Navigationsprogrammen, welche auf Mobiltelefonen verwendet
werden, ist dies bereits gang und gäbe. Bei dedizierten Navigationsgeräten ist jedoch bisher nur eine geringe aber
steigende Zahl mit einem eigenen GSM-Modem ausgestattet. Dieses wird gegenwärtig jedoch ausschließlich für den
Empfang von Informationen zum Verkehrsstatus genutzt und liegt die meiste Zeit brach.
Durch das direkte herunterladen aus dem Internet wird es ermöglicht immer genau die Karten lokal vorzuhalten,
welche gerade benötigt werden. Doch auch bei den allerneusten Daten aus dem Netz gibt es Bereiche, die nicht auf
dem aktuellsten Stand oder nur dürftig erfasst sind. Mit OpenStreetMap steht ein System zur Verfügung, das sich
diesem Problem zu stellen vermag, da die Kartendaten von jedermann frei verändert und aktualisiert werden dürfen.
Beim sogenannten Geo-Mapping werden z.B. mit einem GPS-Handgerät die Koordinaten einer bisher nicht
verzeichneten Straße erfasst und im Anschluss am PC mit Hilfe geeigneter Programme in eine Kartendatenbank, wie
OpenStreetMap, eingetragen. In der Praxis stellt sich jedoch häufig das Problem, dass die GPS-Position, die derartige
Handgeräte liefern, nur bedingt genau genug für einen solchen Zweck ist. Insbesondere äußert sich dies bei niedrigen
Geschwindigkeiten in unschönen Punktwolken und verzogenen GPS-Spuren. Auch die flächendeckende Verwendung
von Korrekturdaten, um systembedingte Fehler von GPS auszugleichen, ist in den wenigsten Fällen gegeben. Die
genannten Effekte werden beim Eintragen in die Datenbank dadurch ausgeglichen, dass der Autor die Straße nach
eigenem Gutdünken einmittelt.
1.2
Problemstellung
Ziel der Arbeit ist die Definition der notwendigen Komponenten und Verfahren um den oben geschilderten Ablauf des
Geo-Mappings im Rahmen des Möglichen zu automatisieren. Hierzu sind zunächst geeignete Methoden zu
untersuchen, welche die Genauigkeit der Positionsbestimmung mit Hilfe von GPS verbessern. Zur Anwendung sollen
nur handelsübliche GPS-Empfänger des unteren Preissegments kommen. Auch ist die Verwendung jeglicher weiterer
Sensorik, wie etwa Radsensoren oder Gyroskope, zu vermeiden. Dies würde die Portierung auf andere
Anwendungsfälle und Systeme u.U. erschweren.
Unter mobil ist erstens zu verstehen, dass das System in einem Fahrzeug zur Anwendung kommt und zweitens, dass
für die gesamte Datenkommunikation ausschließlich eine Mobilfunkschnittstelle zur Verfügung steht. Die notwendige
Bandbreite ist zu untersuchen. Das System sollte außerdem in einem mobilfunktechnisch unterversorgten Gebiet noch
funktionieren – also auch mit Verbindungsabbrüchen und niedrigen Bandbreiten umgehen können.
Als Grundlage der Geodaten ist OpenStreetMap als Datenquelle zu verwenden. Die Anwendung soll in der Lage sein,
den erfassten GPS-Track1 automatisch sowohl in die lokale Datenbank, als auch in das OpenStreetMap-Online-System
zu übernehmen. Evaluiert werden soll auch der Grad der möglichen Automatisierung. Es gilt zu untersuchen, welche
Daten automatisiert erfasst werden können und bei welchen Kartenmerkmalen Einschränkungen hinzunehmen sind.
Die notwendigen Kartendaten müssen in geeigneter Weise aus OpenStreetMap lokal verfügbar gemacht werden.
Eventuelle Kartenänderungen sollen unverzüglich zurück in OpenStreetMap geladen werden.
Da die Nutzung der OpenStreetMap-Daten vollkommen kostenfrei ist und die verwendete Creative Commons Lizenz
(vgl. [CrC10] ) nur geringe Einschränkungen mit sich bringt, sollte ein kostengünstiges System geschaffen werden
können, das für alle Bereiche der Erde hochaktuelles Kartenmaterial bereithält und noch dazu selbst einen Beitrag
zum Erhalt der Aktualität zu leisten vermag.
1
Unter einem GPS-Track ist eine Menge von sequentiell aufgezeichneten GPS-Koordinaten zu verstehen.
2
Kapitel 1
1.3
Einführung
Systemumgebung
Die Arbeit an diesem Projekt fand im Umfeld des Labors InCarMultimedia des Fachbereichs Informatik an der
Hochschule Darmstadt statt. Daraus resultierte die Verfügbarkeit einiger Basiskomponenten zur Abstraktion von
Betriebssystemfunktionalitäten in Form eines dort entwickelten komponentenbasierten Frameworks. Außerdem
standen zu Beginn der Entwicklung bereits einige Programmcodeauszüge für den Umgang mit OpenStreetMap-Daten
und das Rendern von Kartenmaterial frei zur Verfügung. Für den Empfang des GPS-Signals konnten u.a. mehrere im
Labor vorhandene GPS-Mäuse unterschiedlichen Typs, sowie einige eigene Mäuse und Handgeräte verwendet
werden.
Besondere Vorgaben für die Entwicklung wurden nicht gemacht, einzig die Nutzung von GPS als Datenquelle zur
Positionsbestimmung wurde festgelegt.
Als Entwicklungsplattform diente ein Linux-System mit Ubuntu 9.04 als Betriebssystem und Eclipse CDT als
Entwicklungsumgebung. Für alle Programmteile wurde C++ als Programmiersprache gewählt. Bibliotheken konnten
frei gewählt und verwendet werden.
1.4
Überblick
Diese Niederschrift ist Grundsätzlich in zwei Teile gegliedert. Im Anschluss an diese Einführung folgt ein ausführlicher
Grundlagen Teil, in dem alle notwendigen Teilaspekte und Technologien beleuchtet werden. In Kapitel 2 werden
zunächst einige wichtige Grundbegriffe der Geodäsie definiert und erläutert, welche notwendig waren, um sich im Feld
der Kartographie und GPS zurecht zu finden. Das Kapitel 3 widmet sich ausschließlich und intensiv dem Thema GPS.
Es wird nicht nur auf die grundlegende Funktionsweise eingegangen, sondern auch auf Fehlereinflüsse und
Möglichkeiten die Positionsbestimmung zu verbessern. Gegenstand von Kapitel 4 sind die verschiedenen Aspekte der
OpenStreetMap Datenbank. Insbesondere geht es um das verwendete Datenmodell und die bereitgestellten APIs um
darauf zuzugreifen.
Der zweite Teil der Arbeit widmet sich konkret der prototypischen Umsetzung der geforderten Aufgabenstellung. In
Kapitel 5 werden unter Berücksichtigung der Erkenntnisse aus den vorherigen Kapiteln geeignete Verfahren
ausgewählt und eine Grundarchitektur des Systems entwickelt und vorgestellt. In Kapitel 6 sollen die geschaffenen
Programmteile und Komponenten aufgeführt werden. In diesem Kapitel werden auch Probleme dargestellt, die
während der praktischen Entwicklung des Systems aufgetreten sind. Kapitel 7 wagt den Versuch einer Bewertung der
vorgestellten Arbeitsergebnisse. Die Verfahren sollen hinsichtlich der Qualität ihrer Ergebnisse analysiert werden – in
diesem Fall z.B. wie gut eine eingezeichnete Straße dem tatsächlichen Verlauf entspricht. Außerdem wird die Arbeit
noch einmal zusammengefasst und über weitere ausstehende Fragestellungen des Projekts informiert.
3
Teil I
Grundlagen
Kapitel 2
Geodäsie
Dieses Kapitel will versuchen einige wichtige grundsätzliche Begriffe der Geodäsie zu erläutern, welche in späteren
Kapiteln von Bedeutung sein werden. Es soll zunächst eine Einführung in die Thematik gegeben werden, bevor näher
auf die Bedeutung von Geodätischem Datum und die verwendeten Projektionen und Koordinatensystemen
eingegangen wird. Wichtiges Ziel dieses Kapitels soll auch sein, die notwendigen Grundlagen zu schaffen,
Koordinaten unterschiedlicher Systeme ineinander konvertieren zu können inkl. der Beurteilung der Qualität der
Umrechnung. Zum Abschluss werden einige wichtige Berechnungen vorgestellt, die im Laufe des Projekts benötigt
wurden.
2.1
Definition
Nach [Wik10b] ist die Geodäsie „die Wissenschaft von der Ausmessung und Abbildung der Erdoberfläche‚. Es geht
darum, die Erdgestalt möglichst exakt zu bestimmen und darauf basierend Methoden zu definieren, die Position eines
gegebenen Punktes auf der Erde eindeutig wiedergeben zu können. Wichtigste Grundelemente zur Beschreibung der
Erdform sind das Ellipsoid und das Geoid.
Die Kartographie ist eng mit der Geodäsie verzahnt. Man versteht darunter „die Wissenschaft und Technik zur
Darstellung der Erdoberfläche in topographischen und thematischen Karten‚ [Wik10g] . Die Aufgabe eines
Kartografen ist es, die geographischen Informationen über die Gegebenheiten eines Gebietes (z.B. Straßen, Flüsse,
Waldgebiete oder besiedelte Bereiche), welche etwa durch Landvermesser ermittelt wurden, in Form von Landkarten
verständlich aufzubereiten. Hierbei werden je nach Typus der gewünschten Karte unterschiedliche Anforderungen
gestellt. Von der einfachen politischen Karte bis hin zur hochdetaillierten topografischen Karte mit allen Details. Daher
sahen sich viele Kartografen früher gar als Künstler. Der Entstehungsprozess der OpenStreetMap, wie er in Kapitel 4
dargestellt wird, ist somit gleichermaßen ein Prozess in der Geodäsie, als Form der Landvermessung, wie auch der
Kartographie, durch die automatisierte Umwandlung erfasster Daten in verständliche Kartendarstellungen.
2.1.1 Ellipsoid
Im Gegensatz zur allgemeinen Vorstellung, die Erde sei eine Kugel, muss richtigerweise gesagt werden, dass es sich
um ein Rotationsellipsoid handelt, welches an den Polen abgeflacht ist. Also eine Ellipse, die um ihre kleinere
5
Kapitel 2
Geodäsie
Halbachse gedreht wurde. Ein solches Rotationsellipsoid ist definiert durch seine große Halbachse a und seine kleine
Halbachse b bzw. die Abplattung f, welche den Grad der Verkürzung der kleineren Halbachse im Verhältnis zur
größeren angibt.
Bei der Erde handelt es sich um ein Ellipsoid mit a ca. 6380 km und b ca. 6360 km. Daraus resultiert eine Abplattung
von ungefähr 1:300. Genauere Zahlen können im Kapitel 2.3 nachgelesen werden.
f 
a b
 1 : 300
a
Formel 2.1: Zusammenhang zwischen Abplattung und
Halbachsen
Abb 2.1: Ellipse mit großer und kleiner Halbachse
2.1.2 Geoid
Aber auch ein Ellipsoid ist nur eine Näherung der Erdgestalt und nicht vollständig korrekt. Aufgrund von
Dichteunterschieden im Inneren und der Rotation der Erde ähnelt sie vielmehr einem an der Oberfläche leicht
verbeulten Ellipsoid – dem sogenannten Geoid. Es handelt sich um die „Niveaufläche des Erdschwerefeldes, die sich
der Oberfläche der Ozeane anpasst‚ [Man04] . Insbesondere für Höhenbetrachtungen ist das Geoid unerlässlich. Es
ist nicht gleichzusetzen mit der tatsächlichen Topographie der Erdoberfläche (siehe Abb 2.2). Da ein Ellipsoid
beispielsweise die Weltmeere nur im Mittel annähert, hätte eine Stelle A (unabhängig vom Einfluss der Gezeiten oder
der Sonne) auf dem Meer u.U. eine andere (mittlere) Höhe als eine Stelle B auf dem Meer – dies kann mit Hilfe des
Geoids vermieden werden.
Abb 2.2: Zusammenhang Topographie und Geoid
Abb 2.3: Darstellung des Erdschwerefeldes, stark überzeichnet,
Quelle: [Wik10c]
Wie man in Abb 2.3 sieht, lässt sich das Geoid im Gegensatz zum Ellipsoid nicht auf einfache Weise mathematisch
beschreiben. Die natürliche Lotrichtung steht an jedem Punkt des Geoids senkrecht auf der Geoidoberfläche. Der
Winkel zwischen der Flächennormalen bezüglich des Ellipsoids an einem gegebenen Punkt und der Lotrichtung wird
als Lotabweichung bezeichnet, der Höhenunterschied zwischen Geoidoberfläche und Ellipsoidoberfläche als
Geoidundulatation U. Diese bewegt sich in einem Größenbereich von –108 Metern (südlich von Indien) bis +82 Meter
(in Neuguinea) (vgl. [LeG10] ). Um Höhenangaben vergleichbar zu machen ist anzugeben, ob es sich um die Höhe
über dem Ellipsoid, die Höhe über dem Geoid (siehe H in Abb 2.2) oder eine andere Form der Angabe handelt.
6
Kapitel 2
2.2
Geodäsie
Koordinatensysteme
Neben der genauen Untersuchung der Erdform, beschäftigt sich die Geodäsie vor allem mit der Festlegung von
Bezugssystemen, um Positionen auf der Erdoberfläche eindeutig bestimmen und benennen zu können. Es seien an
dieser Stelle zunächst zwei verschiedene Arten von Koordinatensystemen beschrieben: kartesische und
geographische Koordinatensysteme.
2.2.1 Kartesische Koordinaten
Bei kartesischen Koordinaten wird eine Position durch ein Koordinaten-Tripel eindeutig bestimmt. Das
zugrundeliegende Koordinatensystem besitzt die orthogonal zueinander liegenden Achsen X, Y und Z. Der Ursprung
des Systems liegt im Zentrum des Rotationsellipsoids (siehe Abb 2.4). Fallen Erdmittelpunkt und Ursprung zusammen,
spricht man auch von geozentrischen Koordinaten. Die Z-Achse entspricht gewöhnlich der mittleren Rotationsachse
der Erde – diese unterliegt aufgrund der Taumelbewegung der Erde leichten Schwankungen. Bei modernen Systemen
wird meist die Rotationsachse der Erde zum Zeitpunkt des 1. Januars 2000 verwendet [Bau97] . So erhält man ein
erdfestes Bezugssystem. Die X/Z-Ebene definiert einen sogenannten Nullmeridian und besitzt keine natürliche
Begründung. Häufig verläuft sie durch das Royal Greenwich Observatory in London bzw. ca. 100 m östlich. X und Y
Achse zeigen jeweils in Richtung des Äquators. Als Einheit wird im europäischen Raum meist Meter verwendet.
Beispielhaft die Koordinaten eines Trigonometrischen Punktes P im Bürgerpark in Darmstadt:
 X   4.070.325,206 
  

 Y    620.317,413  m
 Z   4.855.143,185 
  

2.2.2 Geographische Koordinaten
Die heute gebräuchlichste Form von Koordinaten im Bezug auf die Erde sind geographische Breite B und
geographische Länge L (evtl. ergänzt durch eine Höhenangabe HE). Auf einem Ellipsoid kann die Position mithilfe
dieser beiden Polarkoordinaten exakt ermittelt werden. Der Breitengrad (engl. Latitude) bestimmt den Winkel des
Normalkrümmungsradiuses2 gegenüber der Äquatorebene und der Längengrad (engl. Longitude) den Winkel
gegenüber der Ebene, die durch den Nullmeridian, wie er im vorherigen Kapitel durch die X/Z-Ebene definiert wurde,
aufgespannt wird. Nummeriert wird der Längengrad von 0° am Nullmeridian bis 180° westliche bzw. östliche Länge,
die geographische Breite von 0° am Äquator bis 90° nördliche bzw. südliche Breite an den Polen. Alternativ zu den
Bezeichnern südliche Breite und westliche Länge findet auch die Verwendung eines vorangestellten negativen
Vorzeichens Anwendung. Die genauere Gradunterteilung erfolgt entweder dezimal oder durch Angabe von Minuten (‘)
und Sekunden (‚,mit Nachkommastellen), wobei 60 Sekunden eine Minute ergeben und 60 Minuten ein Grad. Alle
Punkte mit gleichem Breitengrad werden als Breitenkreise und alle Punkte mit gleichem Längengrad als Meridiane
oder Längenkreise bezeichnet.
In Abb 2.5 stellen L und B die geographische Länge und Breite dar. N definiert den Normalkrümmungsradius. In
[Gruber08] und [Man04] finden sich die notwendigen Berechnungsvorschriften, um die beiden Typen von Koordinaten
ineinander umzurechnen.
2
Unter dem Normalkrümmungsradius versteht man in diesem Fall den Radius der Oberflächennormalen gegenüber der Z-Achse.
7
Kapitel 2
Geodäsie
Beispielkoordinaten Punkt P: ( L, B, h)  (8° 39' 54.71988" ,49° 53' 26.44796",234.005)
Abb 2.4: Kartesische Koordinaten,
Quelle: [Gruber08]
2.3
Abb 2.5: Geographische Koordinaten,
Quelle: [Gruber08]
Geodätisches Datum
In der historischen Entwicklung der Geodäsie bzw. der Landesvermessung wurden zahlreiche sogenannte
Referenzellipsoide bestimmt und definiert. Diese werden für bestimmte eingeschränkte Gebiete jeweils als
bestanschließendes Ellipsoid verwendet, da sie das Geoid am besten annäheren (siehe Abb 2.6).
Abb 2.6: Zusammenhang Geoid, mittleres Erdellipsoid und lokale Ellipsoide
Anhand sogenannter Fundamentalpunkte (auch Zentral- oder Lagerungspunkte genannt) werden diese fest auf der
Erdoberfläche gelagert. Hierzu wurden früher mit Mitteln der Astronomie der Breiten- und Längengrad eines solchen
Punktes bestimmt. Mithilfe der Lotrichtung, einer vorhandenen Höhe, sowie Abstand und Azimut3 zu einem weiteren
Punkt, kann durch Gleichsetzung mit den Koordinaten auf dem Referenzellipsoid eine fixe Verbindung mit der
Erdoberfläche erreicht werden. Dies ermöglicht es ausgehend vom Fundamentalpunkt ein Netz von
Vermessungspunkten zu bestimmen, deren Koordinaten sich nun allesamt auf das Referenzellipsoid beziehen (vgl.
[Bau97] ). In Deutschland finden nach der Wiedervereinigung zwei verschiedene Geodätische Daten Anwendung: auf
dem Gebiet der alten Bundesländer das Deutsche Hauptdreiecks Netz (DHDN) mit dem Fundamentalpunkt Potsdam
3
Der Azimut definiert den Winkel gegenüber einem Längenkreis zu einem entfernten Punkt. Üblicherweise wird in der Geodäsie von Norden beginnend im
Uhrzeigersinn gezählt.
8
Kapitel 2
Geodäsie
(auch bekannt als System Rauenberg), basierend auf dem Bessel Ellipsoid von 1841, und in den neuen
Bundesländern das Staatliche Trigonometrische Netz STN der ehemaligen DDR mit dem Fundamentalpunkt Pulkowo,
basierend auf dem Krassowski Ellipsoid von 1942.
Um Kartenmaterial und die darin verwendeten Koordinaten nutzen zu können ist es wichtig, das Referenzellipsoid und
den Fundamentalpunkt – und somit die genaue Lage des Ellipsoids relativ zum Erdkörper - zu kennen. Dies gilt
insbesondere dann, wenn Koordinaten mit Systemen weiterverarbeitet werden, denen ein anderes Bezugssystem
zugrunde liegt. Zu diesen Zweck wurde das sogenannte Geodätische Datum definiert. Es enthält neben
Fundamentalpunkt und Ellipsoid noch weitere Parameter, die für die Verwendung notwendig sind. Heutzutage findet
sich in einem Geodätischen Datum auch die genaue Lage des Ellipsoids bezüglich des Erdschwerpunktes. Dies
ermöglicht die Umrechnung der Koordinaten aus den nationalen Systemen in benachbarte nationale oder globale
Koordinatensysteme. Moderne Karten führen unter Datum ergänzend auch die verwendete Kartenprojektion auf (siehe
Kapitel 2.3.1). Das unten aufgeführte WGS 84 definiert gar Rotationsgeschwindigkeit, Masse und
Gravitationskonstante der Erde.
Bezeichnung
Deutsches Hauptdreiecksnetz
DHDN (Deutschland)
Fundamentalpunkt
Potsdam bzw.
Rauenberg
Ellipsoid
Bessel (1841)
große Halbachse
6.377.397,155
1/Abplattung
299,1528128
staatliches trigonometrisches
Netz STN (Deutschland)
Militärgeographisches Institut
MGI (Österreich)
Nouvelle triangulation de la
France NTF (Frankreich)
North American Datum 1927
NAD (USA, Kanada, Mexiko)
European Datum ,ED 50
Pulkowo
(St. Petersburg)
Hermanskogel
(Wien)
Pantheon
(Paris)
Meadas Ranch
(Kansas, USA)
Potsdam u.a.
Krassowski (1942)
6.378.245,0
298,3
Bessel (1841)
6.377.397,155
299,1528128
Clarke (1880)
6.378.249,145
293,4650
Clarke (1866)
6.378.206,4
294,9786982
Hayford (1927)
Internat. Ellipsoid
6.378.388,0
297,0
Tabelle 2.1: Wichtige Geodätische Daten (vgl. [deL06] )
Mit Einführung der Satellitengeodäsie ist man übergegangen nicht mehr vom Geodätischen Datum sondern von
Referenz System oder Referenz Rahmen zu sprechen, da hierbei Vermessungen nicht mehr lokal von einem
Fundamentalpunkt ausgehend durchgeführt werden, sondern global mit einem großen Netz aus Fixpunkten, deren
genaue Positionen mit verschiedensten Verfahren regelmäßig neu bestimmt werden. Unter System versteht man die
theoretischen Vorgaben und Definitionen und unter Rahmen den jeweiligen Katalog von Feststationen mit ihren
Koordinaten. Durch regelmäßige Aktualisierung der Koordinatenkataloge können auch Veränderungen durch
tektonische Bewegungen berücksichtigt werden. Insbesondere die verwendeten Ellipsoide sind nun nicht mehr lokal
bestangleichend, sondern global ausgeglichen und haben daher auch meist den Massemittelpunkt der Erde als
Koordinatenursprung. Aus diesem Grund sind in diesem Bereich nur noch zwei Ellipsoide gebräuchlich, welche noch
dazu als quasi identisch angesehen werden können: WGS 84 (World Geodetic System 1984, Grundlage von GPS) und
GRS 80 (Geodetic Reference System 1980).
9
Kapitel 2
Bezeichnung
WGS 84
GRS 80
Geodäsie
Große Halbachse
6.378.137,000
6.378.137,000
1/Abplattung
298,257223563
298,257222101
Tabelle 2.2: Global angepasste Referenzellipsoide, Quelle: [Wik10i]
Drei Referenzsysteme sind für uns von Bedeutung: ITRS, WGS 84 und ETRS 89. Bei ersterem, dem International
Terrestrial Reference System, handelt es sich um ein Netz von zurzeit ca. 400 Referenzstationen auf der ganzen Welt,
die das Koordinatensystem aufspannen. Als solches wird ein rein kartesisches verwendet. Werden dennoch
geographische Koordinaten benötigt, wird das GRS 80 Ellipsoid empfohlen. Das WGS 84 stellt die Grundlage von GPS
dar (siehe Kapitel Kapitel 3). Es definiert und verwendet den oben genannten WGS 84 Ellipsoid und wird in
unregelmäßigen Abständen – zuletzt im Januar 2000 – an das ITRS angeglichen. Der europäische Anteil der
Feststationen des ITRS wird innerhalb des ETRS 89 zu einem einheitlichen europäischen System zusammengefasst.
Jeweils nachgeordnet sind nationale Referenznetze wie das deutsche DREF. Als Ausgangskoordinaten für das ETRS
wurden die jeweiligen Koordinaten im ITRS aus dem Jahre 1989 festgesetzt. Dies hat den Vorteil, dass die Bewegung
der eurasischen Platte von derzeit 2,5 cm/Jahr entgegen der Nordamerikanischen in den Koordinaten kaum mehr ins
Gewicht fällt (siehe Abb 2.7 und Abb 2.8), da die Messstationen des ETRS als zueinander weitgehend feststehend
angesehen werden können. Bei [deL06] wird dies noch weiter ausgeführt. Der Unterschied zwischen den ETRS
Koordinaten und den standardmäßig bei GPS verwendeten WGS 84 Koordinaten liegt bei zurzeit etwa 50 cm – dies
muss je nach Genauigkeitsanforderung berücksichtigt werden.
Abb 2.7: Verschiebung der ITRS-Koordinaten pro Jahr,
Quelle: [Aug01]
Abb 2.8: Verschiebung der ETRS-Koordinaten pro Jahr,
Quelle: [Aug01]
Wie Abb 2.7 und Abb 2.8 verdeutlichen, muss bei gegebenen ETRS 89 Koordinaten ein Verschiebevektor in Richtung
Nord-Ost (etwa 42°) angewandt werden, um WGS 84 Koordinaten zu erhalten.
2.3.1 Projektionen
Aufgrund der Ellipsoidform der Erde ist es nicht ohne weiteres möglich, sie auf eine zweidimensionale Fläche in Form
einer Landkarte verzerrungsfrei abzubilden. Hierzu wurden im Laufe der Jahre verschiedene mathematische
Vorschriften entwickelt, diese Abbildung durchzuführen. Die so entstandenen Projektionen sind in unterschiedlicher
Weise Winkel-, Flächen- oder Streckentreu4 – nie jedoch alles zugleich. In diesem Abschnitt soll zunächst eine
4
Winkel, Längen oder Flächen werden relativ zur Realität korrekt wiedergegeben.
10
Kapitel 2
Geodäsie
Auflistung der wichtigsten Projektionen dargestellt werden. Die Im Rahmen des Evaluationsprozesses relevanten
Systeme UTM und Gauß-Krüger werden im anschließenden Kapitel 2.3.2 noch einmal näher betrachtet.
Prinzipiell unterscheidet man Projektionen durch die Wahl eines geeigneten Projektionskörpers und die Lage dessen
Achse. Eine detaillierte Auflistung kann unter [MaC00] gefunden werden.
Projektionskörper
Eingebürgert haben sich die nachfolgend abgebildeten Grundkörper: Ebene, Zylinder und Kegel. Bei der
Azimutalprojektion berührt die Projektionsebene die Erde entweder in genau einem Punkt (Tangentialebene) oder sie
schneidet die Erdoberfläche in Form eines Kreises. Alle Winkel, vom Berührpunkt aus betrachtet, werden korrekt
wiedergegeben. Im Gegensatz hierzu werden die Koordinaten im zweiten Fall auf die Oberfläche eines Zylinders
abgebildet. Die Zylinderprojektion – auch als Mercatorprojektion bezeichnet - ist eines der am meisten verwendeten
Verfahren. Entspricht der Radius der großen Ellipsoidhalbachse, berührt der Projektionskörper die Erde am Äquator
(bei der axialen Lage, siehe unten) – dieser wird streckentreu abgebildet. Bei kleinerem Radius entstehen zwei zum
Äquator parallele Schnittkreise. Dies führt je nach Gebiet zu geringeren Verzerrungen. Der letzte wichtige
Projektionskörper ist der Kegel. Es gelten ähnliche Eigenschaften, wie bei der Zylinderprojektion. Jedoch können
besonders nördliche oder südliche Breiten mit der Kegelprojektion besser abgebildet werden.
Abb 2.9: Verschiedene Projektionskörper, Quelle: [deL06]
Projektionslage
Auch bei der Lage der Projektion werden drei grundsätzliche Formen unterschieden: die axiale oder normale Position,
die querachsige bzw. transversale Position und die schräge Position. „Bei der normalen Lage fallen Erdachse und
Rotationsachse des Zylinders oder Kegels zusammen‚ [deL06] . Im Fall der transversalen Position liegt die
Rotationsachse orthogonal zur Erdachse. Dadurch ist jedoch keine endgültige Lage definiert. Bei einer konkreten
Projektion wählt man daher jeweils noch einen (bzw. mehrere) Bezugsmeridian(e).
Abb 2.10: Verschiedene Projektionslagen, Quelle: [deL06]
11
Kapitel 2
Geodäsie
2.3.2 Wichtige Koordinatengitter
Insbesondere die transversale Mercatorprojektion hat sich in der Landesvermessung in Europa seit dem 18.
Jahrhundert etabliert und bildet die Grundlage sowohl für die ältere Gauß-Krüger Projektion als auch für das moderne
UTM-Koordinatengitter.
Gauß-Krüger
Die Grundsteine für das System legten Carl Friedrich Gauß im 18. Jahrhundert und Johann Heinrich Louis Krüger im
20. Jahrhundert. Wie bereits erwähnt, handelt es sich beim Gauß-Krüger-System um eine transversale
Mercatorprojektion. D.h. der Projektionszylinder liegt quer zur Erdachse. Die Projektion gibt nicht zwingend ein
Ellipsoid vor. Jedoch wird in Deutschland das Bessel-Ellipsoid (DHDN, siehe oben) und zum Teil noch das
Krassowski-Ellipsoid (STN, siehe oben) verwendet. Im Sprachgebrauch der Landesvermessungsämter werden GaußKrüger-Koordinaten auch als Lagestatus 100 bezeichnet [Hec04] .
Die Erde wird in 120 3° breite Streifen eingeteilt (auch 6°-Streifen kommen zur Anwendung). Diese erhält man, wenn
man beginnend am Nullmeridian den Projektionszylinder jeweils um 3° weiter dreht. Der mittlere Längenkreis wird als
Bezugsmeridian bezeichnet. Die Streifen werden von zwei Meridianen westlich und östlich des Bezugskreises im
Abstand von theoretischen 1,5 Grad begrenzt, praktisch aber etwas mehr, damit sich die Streifen an ihren
Randbereichen überlappen.
Abb 2.11: Gauß-Krüger-Zonen in Deutschland, Quelle: [deL06]
Die eigentlichen Koordinaten werden angegeben in Form eines Rechts- und eines Hochwertes, wobei ersterer den
Abstand des Punktes vom Bezugsmeridian angibt und letzterer den Abstand des Punktes vom Äquator (bezogen auf
den Mittelmeridian). Zur Vermeidung negativer Rechtswerte wird ein konstanter Wert von 500.000 m hinzuaddiert und
die Nummer der Gauß-Krüger-Zone vorangestellt (vgl. [GIS06] ). Die Berechnungsvorschriften zur Umrechnung aus
bzw. in geographischen Koordinaten finden sich in [Gruber08] , ebenso für die Nachfolgend dargestellten UTMKoordinaten.
Längengrad
GK-Zone
…
…
-6°
118
-3°
119
0°
0
3°
1
6°
2
9°
3
12°
4
…
…
Tabelle 2.3: Benennungsschema der Gauß-Krüger Zonen
Beispielkoordinaten Punkt P: ( R, H , h)  (3476016.987,5528301.406,186.141 ) (GK Zone 3)
UTM
Das UTM-Gitter basiert prinzipiell auf der gleichen Abbildungsvorschrift, wie das Gauß-Krüger-Gitter. In diesem
Abschnitt seien die zentralen Unterschiede hervorgehoben. Zunächst einmal wird das UTM-System meist mit WGS 84
12
Kapitel 2
Geodäsie
bzw. ETRS 89 als Datum verwendet. Aber auch andere Systeme, welche auf geographischen Koordinaten basieren,
sind möglich. Die Koordinatenabweichungen zwischen WGS 84/UTM und ETRS 89/UTM liegen derzeit in der
Größenordnung von ca. 50 cm, wie es bereits weiter oben im Kapitel dargestellt wurde. In der deutschen Landes- und
Katastervermessung werden heutzutage alle Koordinaten von Gauß-Krüger auf das auch mit Lagestatus 4895
bezeichnete Netz ETRS 89/UTM umgestellt.
Der Hauptunterschied ist jedoch die Verwendung von 6° breiten Streifen anstelle von 3°. Dies führt zu größeren
Verzerrungen an den Streifenrändern. Um dies auszugleichen wird der Bezugsmeridian um einen Faktor von 0,996
verkürzt dargestellt, wodurch der Projektionszylinder den Mittelmeridian nicht mehr berührt, sondern die Erde in Form
von Durchdringungskreisen schneidet. Außerdem wird ein anderes Benennungsschema der Zonen verwendet, als bei
Gauß-Krüger.
Längengrad
GK-Zone
-177°
1
-171°
2
…
…
-3°
30
3°
31
9°
32
…
…
171°
59
177°
60
Tabelle 2.4: Benennungsschema der UTM Zonen
Die Streifen reichen jedoch nur jeweils von 80° südliche Breite bis 84° nördliche Bereite. Die Polkappen werden durch
eine Universelle polare Stereographische Projektion – kurz UPS - abgebildet [LVB09] . Die verbleibenden 164
Breitengrade werden in Bändern zu je 8° bzw. 12° beim nördlichsten Band eingeteilt und mit einem Buchstaben
versehen. Abb 2.12 zeigt die Aufteilung in Europa. Deutschland liegt somit zum größten Teil in der Zone 32 Band U.
Die Abbildung zeigt in der Feineinteilung auch noch die weitere Einteilung in sogenannte Planquadrate von 100x100
km, wie sie das UTM-Referenzsystem (UTMREF) definiert. Diese werden jeweils durch eine Doppelbuchstabenfolge
nach einem vorgegebenen Schema benannt.
Abb 2.12: UTM-Gitter für Europa und Deutschland, Quelle: [Wik10k] , [LVB09]
5
Lagestatus 389 wird dagegen für kartesische und Lagestatus 889 für geographische ETRS 89 Koordinaten verwendet.
13
Kapitel 2
Geodäsie
Die Koordinaten sind ähnlich aufgebaut wie Gauß-Krüger-Koordinaten. Man spricht jedoch nicht von Rechts- und
Hochwert, sondern von East und North. Dem East-Wert werden die Zone und das Band vorangestellt. Auch hier wird
ein Offset von 500.000 m addiert, um negative East-Werte zu vermeiden. Ähnlich verfahren wird mit der NorthKomponente bei Koordinaten südlich des Äquators. Im Falle der UTMREF-Kodierung werden die erste Stelle des EastWertes und die ersten beiden Stellen des North-Wertes weggelassen und dadurch ersetzt, dass das Planquadrat
vorangestellt wird.
Beispielkoordinaten Punkt P in UTM: ( E, N , h)  (32U 475951.520,5526529.857,186.141)
Beispielkoordinaten Punkt P in UTMREF: 32U MA 75951 26529
2.3.3 Datumstransformation
Innerhalb des Projektes wurde es notwendig, Koordinaten bezüglich des Geodätischen Datums in ein anderes Datum
zu transformieren. Dies stellte sich als nicht-triviales Problem heraus und soll in diesem Kapitel näher erläutert werden.
Grundproblem ist die nicht-Eindeutigkeit der Parameter für die dieser Operation zugrundeliegenden
Datumstransformation zwischen den Bezugssystemen des DHDN, ETRS 89 und WGS 84.
Vorgehen
Eine Datumstransformation ist notwendig, wenn Koordinaten zwischen zwei Systemen mit unterschiedlichem Ellipsoid
und Ursprung, sowie unterschiedlicher Ausrichtung der Achsen konvertiert werden sollen. Gelöst wird diese Aufgabe
meist mit einer sogenannten 7-Parameter-Helmert-Transformation. Hierzu müssen die umzurechnenden Koordinaten in
ihrer kartesischen Form vorliegen. Eine Umrechnung geographischer Koordinaten ist bei einer vorhandenen
elliptischen Höhe unproblematisch und kann in [Man04] nachgelesen werden.
Abb 2.13: Helmert-Transfomation, Quelle: [Gruber08]
Die Parameter für den Datumsübergang von Datum 1 nach Datum 2 bestehen aus drei Werten für eine Translation des
Ursprungs (in Metern), drei Werten für eine Rotation der Achsen (in Winkelsekunden) und einem Maßstabsfaktor (als
Änderung in ppm – parts per million - angegeben).
14
Kapitel 2
Geodäsie
rz  ry   X 
X
 dx   m 0 0   1
 
  
 
  
  dy    0 m 0     rz
1
rx    Y 
Y 
Z
  
 
1   Z  Datum1
  Datum2  dz   0 0 m   ry  rx
Formel 2.2: 7-Parameter-Helmert-Transformation, Quelle: [Gen00]
Die obige Drehmatrix stellt eine hinreichend genaue Näherung der exakten auf trigonometrischen Funktionen
basierenden Drehmatrix dar (~1 mm für kleine Drehwinkel) (vgl. [Gruber08] ). Für die umgekehrte Richtung werden
alle Parameter mit umgedrehtem Vorzeichen verwendet.
Die erhaltenen kartesischen Koordinaten können nun mit den im Zieldatum geltenden Parametern in geographische
Koordinaten oder z.B. in Gauß-Krüger/UTM-Koordinaten umgerechnet werden.
Probleme
Das eigentliche Problem bei der Durchführung einer solchen Transformation ist nicht die Umsetzung des
beschriebenen Verfahrens, sondern vielmehr die Verwendung der korrekten Parameter. Im Internet findet man
zahlreiche sogenannte Standard-Parametersätze (Tabelle 2.5), welche die gewünschten Abbildungen ins WGS 84
System durchführen.
Gebiet
Deutschland
Deutschland
dx
591,28
639,9
dy
81,35
24,22
dz
396,39
447,47
rx
-1,477
-0,99
ry
0,0736
-0,38
rz
1,458
-1,16
m
9,82
-0,74
Tabelle 2.5: Verschiedene Standard-Parametersätze in Deutschland
für die Umwandlung von DHDN nach WGS 84, Quelle: [Kra99]
Durch die Erstellung der historischen Vermessungsnetze, basierend auf einzelnen Fundamentalpunkten, entstanden
durch kleinste Messfehler Spannungen6 innerhalb der Netze. Diese werden umso größer, je weiter ein
trigonometrischer Punkt vom Zentralpunkt entfernt ist. Auf Bundeslandebene wurden diese Spannungen mittlerweile
ausgeglichen (vgl. [Gen00] ). In den Übergangsbereichen können jedoch größere Koordinatensprünge auftreten.
Außerdem treten Abweichungen in den Netzen aufgrund der Geoidundulatation auf.
Um eine höchstmögliche Genauigkeit zu erreichen ist es notwendig für die Transformation von Koordinaten aus dem
DHDN in das ETRS 89 Netz sehr lokal definierte Parametersätze zu verwenden, welche das Netz regional bestmöglich
angleichen. Hierzu bieten die Landesvermessungsämter Parametersätze für die jeweiligen Bundesländer an (Tabelle
2.6).
Gebiet
Hessen
dx
584.8095
dy
71.2415
dz
401.6035
rx
0.410816
ry
0.069420
rz
-2.210466
m
10.00867
Tabelle 2.6: Parametersatz für die Umwandlung von DHDN nach ETRS 89 in Hessen, Quelle: [Hec07a]
Die Verwendung eines Standardparametersatzes kann zu Abweichungen bis zu 3 Metern gegenüber den
tatsächlichen Koordinaten führen, wohingegen die speziellen Sätze meist im mm Bereich danebenliegen. In [Hec07b]
findet man eine Darstellung der Lagerestklaffung für die Umrechnung von Gauß-Krüger nach ETRS 89. Damit kann
abgeschätzt werden mit welchem Unsicherheitsfaktor in einem Gebiet zu rechnen ist. Es gilt jedoch zu beachten, dass
es sich bei den amtlichen Transformationsparametern um Parameter für eine DHDN/ETRS-Umwandlung handelt, nicht
6
Als Spannung werden Verzerrungen eines Netzes gegenüber seiner eigentlichen homogenen Gestalt bezeichnet.
15
Kapitel 2
Geodäsie
um eine DHDN/WGS 84-Transformation, wie sie für GPS notwendig wäre. Aber auch hier gilt, dass es sich um eine
Frage der Anforderungen handelt, ob die Verschiebung von 50 cm berücksichtigt werden muss.
2.3.4 EPSG-Codes
Eine wichtige Grundlage bei der Arbeit mit Koordinaten unterschiedlichen Datums stellt die Datenbank der EPSG dar,
der European Petroleum Survey Group, einer wissenschaftlichen Organisation, die in enger Verbindung zur
europäischen Erdölindustrie steht und mittlerweile von der OGP 7 übernommen wurde. Die Datenbank enthält alle
wichtigen Ellipsoide, Geodätischen Daten, Koordinatensysteme und Vorschriften für deren Transformation. Die
einzelnen Datensätze werden jeweils über eine eindeutige Schlüsselnummer identifiziert und können z.B. unter
http://spatialreference.org/ abgefragt werden. Zahlreiche Softwareprodukte können diesen Schlüssel verarbeiten.
Bezeichnung
Bessel 1841
WGS 84
ETRS 89
ETRS 89/UTM Zone 32 N
DHDN Gauß-Krüger 3° Zone 2
Helmert-Transformation Variante
EPGSG-Code
4004
4326
4258
25832
31466
31467
31468
9606
Tabelle 2.7: Wichtige EPSG-Codes
2.4
Wichtige Berechnungen
Einige relevante Berechnungen, die im Laufe der Implementierung notwendig wurden, sollen nachfolgend erläutert
werden. Zunächst die Distanzbestimmung zwischen zwei Punkten. Daran anschließend werden Kursermittlung und
Punktprojektion vorgestellt, sowie abschließend die Ermittlung der Distanz zwischen einem Punkt und einer
gegebenen Strecke. Im Rahmen des Projekts kam die GeographicLib zur Anwendung (Kapitel 6.3.3), welche die
nachfolgenden Formeln implementiert.
Folgende Symbole werden festgelegt:
𝑙𝑜𝑛1
Längengrad des ersten Punktes
𝑙𝑎𝑡1
Breitengrad des ersten Punktes
𝑙𝑜𝑛2
Längengrad des zweiten Punktes
𝑙𝑎𝑡2
Breitengrad des zweiten Punktes
𝑑
Distanz im Bogenmaß
𝐷
Distanz in km
7
OGP: International Association of Oil & Gas Producers.
16
Kapitel 2
Geodäsie
2.4.1 Distanzmaße
Je nach Koordinatensystem müssen unterschiedliche Berechnungen für einen Punktabstand angewandt werden. In
diesem Fall konzentrieren sich die Ausführungen auf den Abstand zweier Punkte bezogen auf die Ellipsoidoberfläche.
Im speziellen Fall bezogen auf das GRS 80 Ellipsoid.
Für ein relativ kleines Gebiet kann man mit dem Satz des Pythagoras eine einfache Näherung angeben, um den
Abstand zweier Punkte zu bestimmen (siehe Formel 2.3). „Die Konstante 111.3 ist dabei der Abstand zwischen zwei
Breitenkreisen in km und 71.5 der durchschnittliche Abstand zwischen zwei Längenkreisen in unseren Breiten‚
[Kom10] . D.h. je nach Breitengrad, muss die Konstante angepasst werden, da die Längenkreise an den Polen
konzentrisch zusammenlaufen.
dx  71.5 * (lon1  lon 2)
dy  111.3 * (lat1  lat 2)
D  dx 2  dy 2
Formel 2.3: vereinfachte Distanzberechnung
Oben genannte Berechnung stützt sich darauf, dass die Verbindung zweier Punkte eine Gerade ist. Auf einer
Kugeloberfläche (welche hier als Näherung für das Erdellipsoid ausreicht) liegt die kürzeste Verbindung jedoch auf
einem sogenannten Großkreis, wie in Abb 2.14 dargestellt. Daher müssen für exakte Berechnungen die Vorschriften
des Kugeldreiecks verwendet werden.
Abb 2.14: Großkreis als kürzeste Verbindung zweier Punkte, Quelle: [Kom10]
Die Berechnung liefert zunächst den Abstand zwischen A und B auf dem Großkreis im Bogenmaß. Die Konstante
6371,0 in Formel 2.4 definiert den mittleren Erdradius in km.

d  2 * arcsin 


D  d * 6371,0
2
  lat1  lat 2  
  lon1  lon 2  
 sin 
   coslat1 * coslat 2 *  sin 
 
2
2


 
 
Formel 2.4: Distanz im Kugeldreieck, Quelle: [Wil10]
17
2




Kapitel 2
Geodäsie
2.4.2 Kursrichtung zwischen zwei Punkten
Die Kursrichtung zwischen zwei Punkten wird auch als Azimut bezeichnet. Angegeben wird der Wert in diesem Fall im
Bogenmaß und kann entsprechend umgerechnet werden. Mit der Zählung begonnen wird am geographischen
Nordpol in Richtung Osten.
𝑙 = 𝑠𝑖𝑛 𝑙𝑜𝑛2 − 𝑙𝑜𝑛1
𝑙 < 0:
𝑎𝑧𝑖𝑚𝑢𝑡 =
𝑙 ≥ 0:
𝑠𝑖𝑛 𝑙𝑎𝑡2 − 𝑠𝑖𝑛 𝑙𝑎𝑡1 ∗ 𝑐𝑜𝑠 𝑑
sin 𝑑 ∗ 𝑐𝑜𝑠 𝑙𝑎𝑡1
𝑠𝑖𝑛 𝑙𝑎𝑡2 − 𝑠𝑖𝑛 𝑙𝑎𝑡1 ∗ 𝑐𝑜𝑠 𝑑
2𝜋 − 𝑎𝑟𝑐𝑐𝑜𝑠
sin 𝑑 ∗ 𝑐𝑜𝑠 𝑙𝑎𝑡1
𝑎𝑟𝑐𝑐𝑜𝑠
Formel 2.5: Berechnung der Kursrichtung zwischen zwei Punkten, Quelle: [Wil10]
2.4.3 Projektion eines Punktes
Als dritte wichtige Berechnungsvorschrift soll die Punktprojektion entlang eines Großkreises vorgestellt werden. Es sei
hierzu ein Punkt, ein Winkel und ein Abstand gegeben. Es wird iterativ zunächst der Breitengrad bestimmt und
anschließend der Längengrad. Die Formel kann angewandt werden bis zu einem Abstand von einem Viertel
Erdumfang. Für größere Abstände findet man in [Wil10] auch eine allgemeinere Form.
𝑙𝑎𝑡2 = 𝑎𝑟𝑐𝑠𝑖𝑛 𝑠𝑖𝑛 𝑙𝑎𝑡1 ∗ 𝑐𝑜𝑠 𝑑 + 𝑐𝑜𝑠 𝑙𝑎𝑡1 ∗ 𝑠𝑖𝑛 𝑑 ∗ 𝑐𝑜𝑠 𝑎𝑧𝑖𝑚𝑢𝑡
𝑙𝑜𝑛2 =
𝑙𝑜𝑛1 − 𝑎𝑟𝑐𝑠𝑖𝑛
𝑠𝑖𝑛 𝑎𝑧𝑖𝑚𝑢𝑡 ∗ 𝑠𝑖𝑛 𝑑
𝑐𝑜𝑠 𝑙𝑎𝑡2
+ 𝜋 𝑚𝑜𝑑(2𝜋) − 𝜋
Formel 2.6: Projektion eines Punktes [Wil10]
2.4.4 Abstand zu einer Strecke
Die Aufgabenstellung hierbei sei die folgende: Es seien zwei Punkte A,B gegeben,
die die Begrenzung eines Großkreisabschnittes markieren, und ein weiterer Punkt P,
für den der Abstand zur definierten Strecke bestimmt werden soll. Die Grundidee für
diese Berechnung ist einfach und orientiert sich an der Abstandsberechnung
zwischen Punkt und Gerade im euklidischen Raum. Der Großkreis wird als
Spiegelachse betrachtet, an welcher der betrachtete Punkt P gespiegelt wird. Auf
halber Strecke zwischen P und P‘ liegt der Schnittpunkt S mit dem Großkreis. Liegt
der Schnittpunkt innerhalb der Strecke, wird die Distanz PS als Abstand
angenommen, liegt er außerhalb ist der Abstand definiert durch den kürzeren der
beiden Abstände des Punktes P zu den Streckenbegrenzungspunkten A und B. Die
Spiegelung erfolgt durch Projektion des Punktes A auf den Punkt P‘ mit dem Abstand
AP und dem Winkel –α gegenüber dem Großkreisabschnitt (siehe nachfolgende
Abbildung). Die relevanten Formeln wurden in Kapitel 2.4.1 bis 2.4.3 bereits
hergeleitet. Für kleine Strecken kann auch hier wieder eine Näherung im euklidischen
Raum angegeben werden.
18
Abb 2.15: Spiegelung an
einem Großkreisabschnitt
Kapitel 2
2.5
Geodäsie
Lagefestpunkte
Um lokale Vermessungen durchführen zu können, betreiben die Landesvermessungsämter verschiedene
Vermessungsnetze. Die einzelnen Messpunkte werden hierbei als Lagefestpunkte oder auch trigonometrische Punkte
bezeichnet [Kah93] . Ihre Position liegt in Form hochgenauer Koordinaten vor, welche früher über klassische
Triangulation ermittelt wurden und heutzutage meist über hochgenaue Satellitenvermessungen bestimmt werden. Die
Festpunkte sind in Hierarchiestufen 1. bis 4. Ordnung eingeteilt, je nach Genauigkeit der Bestimmung und Abstand zu
anderen Punkten gleicher Hierarchie (vgl. [Wik10j] ). In der höchsten Genauigkeitsstufe kann ein solcher Punkt bis in
den Millimeter-Bereich genau bestimmt sein. Ähnliche Festpunktfelder gibt es auch für die Höhe (z.B. Deutsches
Haupthöhennetz DHHN) und das Erdschwerefeld.
Eine Schwierigkeit ist häufig, solche Punkte tatsächlich aufzufinden, denn es ist gängige Praxis, die eigentliche Säule
50-80 cm im Boden einzugraben, um sie vor Manipulation und äußeren Einflüssen zu schützen. Man verwendet hierbei
z.B. Quader aus Granit bzw. Stahl oder Tonrohre.
Abb 2.16: Trigonometrischer Punkt in Form eine Granitsäule
im Boden versenkt, Quelle: [Wik10j]
Abb 2.17: Deutsches Hauptdreiecksnetz,
Quelle: [Hab09]
Um die in diesem Projekt notwendige Evaluation der GPS-Messungen durchführen zu können, war es notwendig, die
gemessenen Positionsdaten mit bekannten Sollkoordinaten zu vergleichen. Hierzu wurden mehrere solcher
Lagefestpunkte zu Hilfe genommen. Ein Problem ist, dass die gegebenen Sollkoordinaten meist im Gauß-Krüger
Format vorlagen. Um einen tatsächlichen Vergleich anstellen zu können, war es notwendig, die Sollkoordinaten in das
WGS 84-Datum zu transformieren.
Die Umwandlung ist nur mit den in Kapitel 2.3.3 betrachteten Schwierigkeiten und Ungenauigkeiten möglich. Dies
muss bei der Bewertung der Ergebnisse berücksichtigt werden. Dadurch macht eine Genauigkeitsuntersuchung der
GPS-Messungen nur bis zur gleichen Genauigkeitsgrößenordnung Sinn, wie sie von der Koordinatentransformation
realisiert werden kann.
19
Kapitel 3
Satellitengestützte Positionsbestimmung mit GPS
Die eigene Position zu kennen, oder die Koordinaten bestimmter Punkte zu ermitteln, ist seit Jahrhunderten in vielen
Bereichen eine wichtige Herausforderung und dies nicht nur, um das Kreuzchen auf der Schatzkarte zu finden. Früher
oft zur Navigation auf See benötigt, wurde diese Aufgabenstellung mit rudimentären Mitteln, wie Karte, Kompass und
natürlichen Gegebenheiten, wie Sonne und Sterne bewältigt. In der Landvermessung wurden Positionen bis ins 20.
Jahrhundert mit Festpunktnetzen und klassischer Triangulation bestimmt. Mit Aufkommen der satellitengestützten
Ortungsverfahren stehen heutzutage Verfahren zur Verfügung, die dieses Problem mit hoher Genauigkeit bei relativ
geringem Aufwand lösen. Hierfür finden sich mittlerweile ungezählte Anwendungsfälle, welche heute oft mit dem
Schlagwort „location based services‚ untermalt sind. Von der Fahrzeugnavigation bis hin zur Suche nach dem
nächstgelegenen Geldautomat oder dem besten Italiener in der näheren Umgebung. In diesem Kapitel soll ein
tiefgehender Überblick über dieses Thema gegeben werden, beginnend beim grundlegenden Aufbau eines solchen
Systems über die notwendige Hardware bis hin zu Genauigkeitsbetrachtungen und Methoden wie die Genauigkeit
gesteigert werden kann. Insbesondere beschränkt sich das Kapitel vornehmlich auf das NAVSTAR-GPS, welches wohl
als der wichtigste Vertreter der Gattung globaler satellitengestützter Navigationssysteme (GNSS)8 bezeichnet werden
darf. Die vorgestellten Verfahren können jedoch als allgemeingültig betrachtet werden und finden in gleicher oder
ähnlicher Weise bei anderen Systemen Anwendung.
3.1
Entwicklung
1978 konnte das US-amerikanische Verteidigungsministerium den ersten Satelliten des NAVSTAR-GPS (vollständige
Bezeichnung: NAVigation System with Timing And Ranging - Global Positioning System) in Betrieb nehmen. Das
System trat die Nachfolge des mittlerweile eingestellten TRANSIT-Systems der US-Marine an. Zwei verschiedene
Dienste stehen seither für die Nutzung zur Verfügung: das zivile Signal Standard Positioning Service (SPS), für die
Allgemeinheit frei verfügbar, sowie die militärische Variante Precise Positioning Service (PPS), welche nur autorisierten
Stellen, vornehmlich der US-Regierung, zur Verfügung steht. Das System wurde mehrmals erneuert und ist mittlerweile
auf 31 aktive Satelliten angewachsen, welche die Erde in ca. 20.000 km in mehreren Bahnen umkreisen.
8
Engl. Global Navigation Satellite Systems [Zog09a]
20
Kapitel 3
Aus Angst vor Terroranschlägen bzw. die Verwendung von GPS in Präzisionswaffen, wurde bis Mai 2000 das zivile
Signal durch die so bezeichnete Selective Availability künstlich verrauscht, was die Positionsgenauigkeit etwa um den
Faktor 10 auf ungefähr 100m Genauigkeit verschlechterte.
Bis etwa zum Jahr 2020 soll das GPS-System in seiner dritten Generation ausgebaut sein und dank zusätzlicher
Frequenzen und modernerer Technik eine noch höhere Genauigkeit und Verfügbarkeit als bisher ermöglichen. Aktuell
ist GPS die derzeit „einzige weltweit funktionierende satellitengestützte Navigationshilfe‚ [Zog09b] .
3.2
Systemaufbau
GPS ist in drei grundlegende Bestandteile eingeteilt. Beginnend bei den Satelliten, die das sogenannte Raumsegment
bilden, dem Kontrollsegment, welches die Satellitenbahnen und -Positionen überwacht und das Benutzersegment, in
dem die Endgeräte zusammengefasst sind.
3.2.1 Raumsegment
Von den bisher 57 Satelliten sind derzeit noch 31 aktiv. Sie bewegen
sich auf sechs verschiedenen Bahnen in einer Höhe von 20.183 km. Für
den Betrieb benötigt werden jedoch nur 24. Die Bahnellipsen sind um
55° gegenüber der Äquatorebene geneigt und jeweils um 60°
gegeneinander verdreht. Dies ermöglicht, dass an jedem Ort der Erde
zu jeder Tageszeit immer mindestens vier Satelliten sichtbar sind9. Die
Geschwindigkeit der Satelliten beträgt „relativ zu Stationen am Boden
bis maximal 2.8 km/s‚ [Rot05] . Für einen kompletten Umlauf benötigt
ein GPS-Satellit 23 Stunden, 55 Minuten und 56,6 Sekunden. Die
Bahnen können mit einfachen mathematischen Grundlagen auf Basis
der Keplerschen Gesetze zur Planetenbewegung berechnet werden.
Einen tieferen Einblick erlauben [Bau97] und [Man04] .
Abb 3.1: GPS-Satellitenbahnen, Quelle:
[Zog09a]
Für die ausgestrahlten Signale wurden die beiden Sendefrequenzen 1575,42
MHz (L1) und 1227,60 MHz (L2) gewählt. Details über die ausgesendeten
Signale können in Kapitel 3.3 nachgelesen werden.
Alle Satelliten sind mit zwei bis vier Atomuhren10 ausgestattet, die als
hochgenaue Zeitnormale verwendet werden und innerhalb aller GPSSatelliten eine gemeinsame Zeitbasis schaffen.
Abb 3.2: Satellit des Blocks II,
Quelle: [Man04]
Die Baureihen der Satelliten werden als Block bezeichnet, bisher wurden fünf
verschiedene Typen (Block I bis Block IIR-M) in den Weltraum befördert. Ab
2010 bis ca. 2020 sind zwei neue Baureihen für den Einsatz geplant (Block IIF
und Block III). Genaueres über die Zukunft von GPS findet man in [Zog09b] .
9
An den Polen sieht man die Satelliten jedoch nie über 42° Elevationswinkel (Winkel über dem Horizont). Dies führt u.U. zu einer schlechten
Satellitengeometrie (siehe Kapitel 3.6.3).
10
Als Atomuhren werden Rubidium- und Cäsiumfrequenznormale verwendet mit einer Genauigkeit von 1s/300000 Jahre, [Man04] .
21
Kapitel 3
3.2.2 Kontrollsegment
Die Hauptaufgabe des Kontrollsegments ist die ständige Überwachung der Satellitenpositionen und die Bestimmung
der Bahnparameter. Diese werden in Form des Almanachs und der Ephemeriden11 über die Satelliten zum Empfänger
ausgestrahlt. Neben der Sicherstellung der Integrität des Systems ist eine weitere wichtige Aufgabe des
Kontrollsegments die Synchronisation der Atomuhren in den Satelliten. Dies umfasst die Definition einer eigenen
Systemzeit, der sogenannten GPS-Zeit. Zum 05.01.1988 stimmte diese mit der UTC12 überein. Da jedoch bei GPS
keine Schaltsekunden eingeführt wurden, differieren UTC und GPS-Zeit um aktuell etwa 15 Sekunden. Die GPS-Zeit
wird in Wochen und Sekunden gezählt. Die als Master Control Station bezeichnete Zentrale hat ihren Sitz in der Nähe
von Colorado Springs. Weltweit verteilt sind mehrere Monitor- und Uplink-Stationen, die den ständigen Kontakt zu den
Satelliten ermöglichen.
Abb 3.3: Verteilung der Bodenstationen, Quelle: [Köh08b]
3.2.3 Nutzersegment
Als Nutzersegment werden alle verwendeten GPS-Empfänger bezeichnet. Diese können auf verschiedene Art und
Weise unterschieden werden. Das wichtigste Unterscheidungsmerkmal bezieht sich auf die empfangbaren
Frequenzen. Die weit verbreiteten Geräte des unteren und mittleren Preissegments können nur die L1-Frequenz
empfangen. Professionelle Empfänger sind in der Lage auch die Frequenz L2 zu verarbeiten. Das zweite wichtige
Kriterium ist die Fähigkeit, ob neben der reinen Auswertung der Navigationsnachrichten auch die Trägerphase des
Signals zur Positionsbestimmung berücksichtigt wird. Genaueres hierzu folgt in Kapitel 3.3.
Endverbraucher-Geräte
Die Geräte des unteren und niedrigen Preissegments von etwa 50 bis ca. 400
EUR basieren auf fertigen GPS-Modulen bzw. Chipsätzen einiger weniger
Hersteller, wie etwa Sirf, MTK oder U-blox. Derartige Module finden nicht nur in
einfachen GPS-Mäusen, GPS-Loggern oder Handgeräten Anwendung, sondern
auch in Mobiltelefonen oder Fahrzeug-Navigationssystemen. Ihnen ist gemein,
dass sie nur eine der beiden GPS-Frequenzen zur Positionsbestimmung nutzen
können. Einige wenige Chipsätze sind in der Lage, neben den
Navigationsnachrichten auch die Trägerphase zu bestimmen und auszuwerten.
11
Abb 3.4: GPS-Modul U-blox LEA 4S,
Quelle: www.u-blox.com
Über den Almanach sendet ein Satellit längerfristige Daten über den Bahnverlauf und die Position aller Satelliten aus. Im Gegensatz hierzu beinhalten die
Ephemeriden nur den kurzzeitigen Bahnverlauf des jeweiligen Satelliten, dafür aber hochgenau.
12
UTC: Universal Time Coordinated, Koordinierte Weltzeit
22
Kapitel 3
Auf die Nutzung von Korrekturdaten wie sie in 3.7.1 beschrieben werden, verstehen sich Geräte dieses Preissegments
ebenfalls nur begrenzt. Die Möglichkeit der Ausgabe von Rohdaten der Entfernungsmessungen findet man nur bei den
allerwenigsten Chipsätzen. Die Genauigkeit der Geräte liegt laut den Herstellerangaben bei etwa 10 Metern ohne die
Verwendung von Korrekturinformationen.
Abb 3.5: USB-GPS-Maus Navilock
402u, Quelle: www.navilock.de
Abb 3.6: GPS-Logger WBT 202,
Quelle: www.wintec-gps.de
Abb 3.7: Handgerät Garmin eTrex
VistaHCx, Qelle: www.garmin.com
Professionelle Geräte
Im Gegensatz zu den Endverbraucher-Geräten sind nahezu alle professionellen GPS-Empfänger fähig die Phasenlage
des Trägersignals zu bestimmen, also die exakte Verschiebung der empfangenen Phase gegenüber einer selbst
erzeugten Referenzschwingung (siehe Kapitel 3.4.1). Außerdem sind viele der Geräte in der Lage beide Frequenzen
auszuwerten. Dies ermöglicht einen deutlichen Genauigkeitsgewinn. Sie kosten jedoch zwischen dem zehn(Einfrequenzempfänger) und hundertfachen (Zweifrequenzempfänger) eines einfachen Handgerätes. Um
Genauigkeiten im Submeterbereich zu erreichen ist es außerdem notwendig Korrekturdaten zu verarbeiten.
Professionelle Geräte sind durch die verschiedensten Schnittstellen, wie etwa serielle Schnittstellen, Bluetooth,
Mobilfunk oder UKW, dazu in der Lage. Auch die Ausgabe von Rohdaten stellt diese Geräteklasse vor keine größeren
Schwierigkeiten. GPS-Empfänger dieser Kategorie, Empfänger der cm-Klasse, werden auch als geodätische
Empfänger bezeichnet, da sie die für Vermessungsaufgaben notwendige Genauigkeit liefern.
Abb 3.8: Einfrequenzempfänger mit 40cm
Genauigkeit Leica SR-20,
Quelle: www.leica-geosystems.com
Abb 3.9: Zweifrequenzempfänger mit 10-30cm Genauigkeit: Trimble
Pathfinder ProXRT, Quelle: www.trimble.com
23
Kapitel 3
3.3
GPS-Signal
Die wichtigste Aufgabe eines GPS-Satelliten ist die Aussendung der Navigationssignale. Es sind drei Dinge von
Bedeutung: das Trägersignal, die Impulsfolgen der Pseudo Random Noise Codes (PRN) und die eigentlichen
Navigationsnachrichten. Die Zusammenhänge zwischen diesen drei Aspekten der Signalübertragung sollen in diesem
Abschnitt näher betrachtet werden.
3.3.1 Navigationsnachrichten
Um eine genaue Positionsbestimmung vornehmen zu können, benötigt der Empfänger diverse Informationen über den
Status der Satelliten. Unter anderem sind dies „präzise Bahndaten des (empfangenen) Satelliten (Ephemeriden)‚,
„Zeitkorrekturinformationen zur Bestimmung der exakten Satellitenzeit‚, „Ungenauere Bahndaten aller Satelliten
(Almanach)‚ sowie „Informationen über den technischen Zustand (Status) der Satelliten‚ [Zog09a] . All diese
Informationen werden in den Navigationsnachrichten kodiert. Für die Nachrichten steht ein fester Rahmen von 1500 Bit
zur Verfügung, welche in fünf Unterrahmen zu je 300 Bit aufgeteilt sind. Die Übertragungsrate beträgt 50 Bit/s, d.h. die
Übertragung eines ganzen Rahmens dauert genau 30 Sekunden, ein einzelner Unterrahmen wird in 6 Sekunden
ausgesandt. Die Unterrahmen bestehen jeweils aus einem Header beginnend mit einer Präambel 13 (10001011) und
den Nutzdaten. Der Header beinhaltet auch die aktuelle GPS-Zeit. Da innerhalb eines Rahmens der Platz für die BahnInformationen aller GPS-Satelliten nicht ausreicht, werden die zugehörigen Unterrahmen im Wechsel übertragen. 25
verschiedene Unterrahmen sind für den kompletten Almanach notwendig. Daher kann es bis zu 12,5 Minuten dauern
bis der Bahnkatalog vollständig zum Empfänger übertragen ist. An dieser Stelle sei bemerkt, dass die
Navigationsnachrichten beim Standard Positioning Service und beim Precise Positioning Service identisch sind –
zumindest bei abgeschalteter Selective Availability.
3.3.2 Trägersignal
Bei GPS fiel die Wahl der Übertragungsfrequenzen, wie bei verschiedenen anderen satellitenbasierten
Navigationssystem, auf das L-Band. Die Frequenzen um 1500 MHz stellen einen guten Kompromiss zwischen
Laufzeitverzögerungen in der Atmosphäre durch größere Wellenlängen und Dämpfungseffekte bei kürzeren
Wellenlängen dar. Da jedoch eine detailliertere Diskussion über die zugrundeliegenden physikalischen Effekte den
Rahmen dieser Arbeit sprengen würde, sei an dieser Stelle auf [Bau97] verwiesen.
Die beiden Frequenzen L1 1575,42 MHz und L2 1227,60 MHz werden durch Vervielfachung aus einer
Grundschwingung von 10,23 MHz generiert, welche durch die Atomuhren erzeugt wird. Erstere Frequenz wird sowohl
für die Übertragung des Standard Positioning Service Signals als auch des Precise Positioning Service Signals
verwendet. Die L2-Frequenz steht alleine dem Precise Positioning Service zur Verfügung.
Abb 3.10: Prinzip der Phasenumtastung
13
Mit der Präambel wird es bei der Wiederherstellung des Signals im Empfänger ermöglicht, die einzelnen Unterrahmen wieder heraus zu filtern.
24
Kapitel 3
Das bei GPS verwendete Modulationsverfahren, mit dem die Nutzdaten auf den hochfrequenten Träger moduliert
werden, ist die Phasenumtastung (PSK14). Das bedeutet, dass die Phase des Trägersignals, je nachdem, ob eine 0
oder 1 übertragen werden soll, um 180° verschoben wird oder nicht (siehe Abb 3.10).
3.3.3 Pseudo Random Noise Codes
Da alle Satelliten die gleichen Frequenzen verwenden, ist ein Mechanismus notwendig, die einzelnen Signale beim
Empfänger wieder voneinander trennen zu können. Im Allgemeinen spricht man hier von Multiplex-Verfahren. Im
speziellen Fall von GPS wird ein Codemultiplex (CDMA15) Algorithmus angewandt. Es handelt sich um ein sogenanntes
Bandspreizverfahren16. Dabei wird ein Signal niedriger Bandbreite und hoher Leistung auf ein Signal großer
Bandbreite und niedriger Leistung gespreizt. Dieser Vorgang erhöht die Störfestigkeit des Signals (siehe Abb 3.11).
Einen tieferen Einblick gewährt [Man04] .
Abb 3.11: Schematische Darstellung der Signale mit angewandter Bandspreizung
P ist die spektrale Leistungsdichte, f die Frequenz
Die Grundlage bilden Impulsfolgen aus den sogenannten Pseudo Random Noise Codes. Dies sind Binärfolgen,
welche eine scheinbar zufällige Verteilung von Nullen und Einsen gleich einem Rauschen aufweisen. Diese sind
jedoch alles andere als zufällig, da sie auf genau definierten Vorschriften basieren und für jeden Satelliten eindeutig
festgelegt sind. Im Falle von GPS werden sie durch „Rückgekoppelte Schieberegister erzeugt‚ [Zog09a] .
Zwei verschieden Codes kommen bei GPS zur Anwendung: der C/A-Code17 für das SPS-Signal und der P(Y)-Code18
für das PPS-Signal. Bis auf die zusätzliche Verschlüsselung der P(Y)-Variante unterscheiden sich die beiden nur durch
die unterschiedliche Wahl der Parameter. Die Codes stellen jeweils nur Binärfolgen dar, welche keine Information
tragen. Daher werden die einzelnen Impulse auch nicht als Bits sondern als Chips bezeichnet. Die Folgen des C/ACodes sind jeweils 1023 Chips lang und werden mit 1,023 MHz auf den Träger moduliert. Sie wiederholen sich jede
14
Engl. Phase Shift Keying
Engl. Code Division Multiple Access
16
Engl. Spread Sepctrum
17
Engl. Coarse Acquisition-Code
18
Engl. Precise-Code
15
25
Kapitel 3
Millisekunde. Unter Annahme der Lichtgeschwindigkeit ist ein einzelner Chip daher etwa 293 m lang [Rot05] . Der
P(Y)-Code hingegen verwendet Chips der Länge 6,1871*1012 und wird mit 10,23 MHz moduliert. Eine Folge wiederholt
sich nur alle 7 Tage19 und ein Chip ist mit 29,3 m deutlich kürzer. Aufgrund bestimmter Eigenschaften der
Verschlüsselung sind moderne Zweifrequenzempfänger in der Lage das Signal des P(Y)-Codes trotz der Chiffrierung
zur Messung zu verwenden [Rot05] .
3.3.4 Modulation
Durch Modulation werden der niederfrequente Navigationsdatenstrom und der höherfrequente PRN-Strom mit dem
Trägersignal vereint. Wie bereits erwähnt, geschieht dies durch binäre Phasenumtastung. Zunächst werden hierzu
jedoch die Code-Datenströme mit dem Navigationsdatenstrom verrechnet. Dies geschieht bitweise mit dem ExklusivOder-Operator (Abb 3.12). Jeweils 20 C/A-Codefolgen kommen auf ein Datenbit. Auf die gleiche Weise können die
Navigationsdaten mit dem PRN-Code beim Empfänger wieder zurückgewonnen werden.
Abb 3.12: XOR-Verknüpfung von PRN-Datenstrom und Navigationsdaten, sowie die resultierende Phasenlage
Anschließend wird anhand des so entstandenen Bitstroms im Modulator die Phasenumtastung vorgenommen. Da auf
der L1-Frequenz, sowohl der C/A-Code, als auch der P(Y)-Code gesendet wird, „wird der Träger in zwei Orthogonale
Komponenten aufgeteilt‚ [Man04] . So können die Codes getrennt voneinander übertragen werden, ähnlich einem
Zeitmultiplex Verfahren.
Abb 3.13: GPS-Modulationsschema, nach [Dan99]
3.3.5 Korrelation
Um ein Signal beim Empfänger wieder aus dem Rauschen zurück zu gewinnen, bedient man sich der Korrelation mit
einem Referenzsignal. D.h. ein im Empfänger generiertes Muster, identisch mit der ursprünglichen Impulsfolge im
19
Eigentlich werden sogar noch längere Codefolgen verwendet, sie werden jedoch einmal pro Woche automatisch zurückgesetzt.
26
Kapitel 3
Satelliten, wird so lange zeitlich verschoben, bis es optimal mit dem empfangenen Signal übereinstimmt - korreliert.
Aus der zeitlichen Verschiebung kann die Laufzeit des Satellitensignals ermittelt werden. Sie wird auch als Codephase
bezeichnet. Tabelle 3.1 bis Tabelle 3.3 verdeutlichen diesen Vorgang nochmals. Das grüne Feld markiert jeweils den
Anfang einer Impulsfolge. Als Berechnungsfunktion wird bitweise die Modulo-2-Addition bzw. XOR-Funktion
angewandt. Der Gesamtkorrelationsfaktor ist die Summe der binären Einsen in der Ergebniszeile.
A 1 0 0 1 0 1 1 1 0 0 1 1 0 0 1 1 0 1 0 1 1 1 0 0 1 0 1 0 1 1
B 1 1 1 0 0 1 1 0 0 1 1 0 1 0 1 1 1 0 0 1 0 1 0 1 1 1 0 0 1 0
⨂ 1 0 0 0 0 1 1 0 0 0 1 0 0 0 1 1 0 0 0 1 0 1 0 0 1 0 0 0 1 0
∑ = 10
Tabelle 3.1: Geringe Korrelation zwischen Eingangssignal A und vorlaufendem Referenzsignal B (Zeit t+5 Chips)
A 1 0 0 1 0 1 1 1 0 0 1 1 0 0 1 1 0 1 0 1 1 1 0 0 1 0 1 0 1 1
B 1 0 0 1 0 1 1 1 0 0 1 1 0 0 1 1 0 1 0 1 1 1 0 0 1 0 1 0 1 1
⨂ 1 0 0 1 0 1 1 1 0 0 1 1 0 0 1 1 0 1 0 1 1 1 0 0 1 0 1 0 1 1
∑ = 17
Tabelle 3.2: Maximale Korrelation zwischen Eingangssignal A und synchronem Referenzsignal B
A 1 0 0 1 0 1 1 1 0 0 1 1 0 0 1 1 0 1 0 1 1 1 0 0 1 0 1 0 1 1
B 0 1 0 1 1 1 0 0 1 0 1 1 1 0 0 1 1 0 0 1 1 0 1 0 1 1 1 0 0 1
⨂ 0 0 0 1 0 1 0 0 0 0 1 1 0 0 0 1 0 0 0 1 1 0 0 0 1 0 1 0 0 1
∑ = 10
Tabelle 3.3: Geringe Korrelation zwischen Eingangssignal A und nachlaufendem Referenzsignal B (Zeit t-5 Chips)
Damit eine Chipfolge für die Bandspreizung verwendet werden kann, müssen zwei Dinge erfüllt sein. Zum einen eine
hohe Autokorrelation, d.h., dass ein ausgeprägtes Maximum entsteht, wenn man das empfangene Signal bei korrekter
zeitlicher Synchronisation mit dem gleichen Code als Referenzsignal korreliert. Und zum anderen eine niedrige
Kreuzkorrelation, also nur eine geringe Korrelation beim Vergleich mit anderen Impulsfolgen. Aus der Vielzahl an
möglichen Chip-Folgen wurden diejenigen für die GPS-Satelliten ausgewählt, welche optimale Eigenschaften
bezüglich der Autokorrelation und Kreuzkorrelation aufweisen. Die sogenannten „Gold-Codes‚ [Köh08a] .
Bei der Korrelation muss ein weiterer physikalischer Effekt berücksichtigt werden. Aufgrund der
Relativgeschwindigkeiten zwischen kreisendem Satellit und einem unter Umständen ebenfalls in Bewegung
befindlichen Empfänger kommt es zu Dopplerverschiebungen der empfangen Signale. Also eine Streckung oder
Stauchung des Trägersignals. Daher müssen sowohl Zeit-, als auch Frequenzverschiebung eines Signals
berücksichtigt werden. Die ermittelte Frequenzverschiebung erlaubt es auch, auf die Eigengeschwindigkeit des
Empfängers zu schließen. Das beschriebene Verfahren wird in der nächsten Abbildung noch einmal veranschaulicht.
Bei der Signalverarbeitung im Empfänger werden drei Phasen des Empfangs unterschieden: Searching (suchen),
Acquisition (erfassen) und Tracking (nachführen). In der ersten Phase suchen die Korrelatoren nach empfangbaren
Satelliten. Dies dauert umso länger je weniger sie über die aktuell verfügbaren Satelliten wissen. Etwa, wenn der
Almanach veraltet ist oder die Position sich stark verändert hat. Der Suchraum wird, wie in Abb 3.14 dargestellt, für
jeden möglichen PRN-Code abgearbeitet. Dies ist jedoch nur in annehmbarer Zeit machbar, weil in heutigen
Chipsätzen mehrere hunderttausend Korrelatoren parallel arbeiten. Wird ein korrektes Signal entdeckt, beginnt die
Phase der Erfassung gewechselt. Da sich Abstand und Relativgeschwindigkeit zu einem Satelliten jedoch ständig
27
Kapitel 3
ändern, muss der GPS-Empfänger ständig die Parameter nachregeln. Der Satellit befindet sich im Zustand der
Nachführung.
Abb 3.14: Korrelation bezüglich Zeit (Code) und Frequenz,
Quelle: [Zog09a]
3.4
Positionsbestimmung
Die Positionsbestimmung bei Satelliten-Navigationssystemen basiert auf der Bestimmung von Entfernungen zwischen
der ortenden Stelle und mehreren Satelliten. Die ermittelten Streckenlängen werden auf Basis der bekannten
Satellitenpositionen für eine Triangulation verwendet, aus der die Position hervorgeht.
3.4.1 Entfernungsbestimmung
Die oben geschilderte Korrelation ist eines der wichtigsten Verfahren bei GPS. Sie bildet die Grundlage für die
Laufzeitbestimmung, welche ihrerseits wiederum wichtig für die Entfernungs- und Positionsbestimmung ist. Basierend
auf der Annahme, dass Satellit und Empfänger über eine einheitliche Zeitbasis verfügen, wird ein Empfänger in die
Lage versetzt, die absolute zeitliche Code-Verschiebung im Signal zu ermitteln. Endverbraucher-Geräte können den
Versatz auf unter ein Prozent der Länge eines Chips ermitteln. Bei einer Chip-Länge von etwa 300 Meter und 1023
Chips pro Folge kommt man auf ein nicht eindeutiges Intervall von ungefähr 300 km innerhalb dessen man den
Abstand zum Satelliten mit bekannter Formel 3.1 auf ca. 1-3 m genau ermitteln kann. Da die Flugbahn jedoch etwa
20.000 Kilometer beträgt, müssen die auftretenden Mehrdeutigkeiten für eine Entfernungsbestimmung erst gelöst
werden. Die Satelliten übermitteln in jedem Unterrahmen der Navigationsmitteilungen als zusätzliche relevante
Information, wann eine Nachricht verschickt worden ist: die sogenannte Time of Week (TOW) - auch als Z-Count
bezeichnet. Aus diesem kann wiederum abgeleitet werden, wann ein einzelner Chip versendet wurde. Hierzu müssen
jedoch zunächst die Navigationsnachrichten aus dem Eingangssignal wiederhergestellt werden.
𝑡 = 𝑇𝑟 − 𝑇𝑠
𝑠 =𝑡∗𝑐
𝑇𝑟
Empfangszeitpunkt
𝑇𝑠
Sendezeitpunkt
𝑠
Entfernung zum Satellit
𝑐
Lichtgeschwindigkeit (im Vakuum)
28
𝑡
Zeitversatz:
Kapitel 3
Formel 3.1: Grundlegende Formel zur Bestimmung einer Entfernung
Geodätische Empfänger sind in der Lage neben der reinen Auswertung der PRN-Codes die genaue Phasenlage des
Trägersignals zu bestimmen. Diese ist jedoch ebenfalls nur innerhalb der Wellenlänge von etwa 20 cm eindeutig,
ähnlich der Codephasenlage. D.h. der Empfänger ermittelt mehrere Möglichkeiten für die Entfernung. Wie solche
Mehrdeutigkeiten bei der Entfernungs- und Positionsbestimmung mit Hilfe von differentiellen Ansätzen gelöst werden
beschreibt [Rot05] .
3.4.2 Triangulation
Die Grundidee der Positionsbestimmung aus Entfernungen besteht in der Bildung von Standpunkten, Standlinien und
Standflächen [Man04] . Damit bezeichnet man die Menge der Positionen, an der sich die ortende Stelle befinden kann.
In der Ebene und einem einzelnen Distanzmaß ist diese definiert durch einen Kreis um den Bezugspunkt, im
dreidimensionalen einer Kugel. Mit jedem zusätzlich ermittelten Abstand lässt sich die Kandidatenmenge weiter
einschränken. Für eine dreidimensionale Positionsbestimmung benötigt man theoretisch drei Abstände. Es muss
jedoch berücksichtigt werden, dass es oft mehrere scheinbare und nur einen wahren Standpunkt gibt. Durch einfache
Annahmen (die ortende Stelle befindet sich auf der Erde) kann dieser jedoch selektiert werden. Abb 3.15 zeigt die
Ortung für ein vereinfachtes zweidimensionales Weltmodell inkl. der beiden resultierenden Standpunkte. Abb 3.16
dagegen für den dreidimensionalen Fall. Auch hier kann es einen scheinbaren Standpunkt geben. Zur einfacheren
Darstellung ist dieser jedoch nicht eingezeichnet. Wie im einfachen Fall liegt er außerhalb des Erdellipsoids und kann
somit ausgeschlossen werden.
Abb 3.15: Ortung vereinfacht in einer zweidimensionalen Welt
Abb 3.16: Ortung in einer dreidimensionalen Welt
Zur tatsächlichen Berechnung der Position seien nachfolgende Formeln gegeben:
𝑠=
𝑋𝑖𝑠
𝑌𝑖𝑠
𝑍𝑖𝑠
𝑋𝑖𝑠 − 𝑋𝑟
2
+ 𝑌𝑖𝑠 − 𝑌𝑟
2
+ 𝑍𝑖𝑠 − 𝑍𝑟
2
𝑋𝑟
𝑌𝑟
𝑍𝑟
Position des Satelliten i
(bekannt durch Ephemeriden)
Position des Empfängers
Formel 3.2: geometrischer Abstand des Empfängers zum Satelliten nach Pythagoras
29
Kapitel 3
Aus Formel 3.1 und Formel 3.2 folgt:
2
2
+ 𝑍𝑖𝑠 − 𝑍𝑟 2 = 𝑡 ∗ 𝑐
Formel 3.3: Zusammenhang zwischen gemessener Entfernung und geometrischer Entfernung
Die Berechnung der Position erfolgt mit Hilfe eines Gleichungssystems, welches für jeden Koordinaten-Wert eine
Unbekannte aufweist. Daher werden drei Satelliten benötigt. Für jeden Satelliten wird eine Gleichung aufgestellt. Eine
mathematisch sehr ähnliche Herangehensweise zeigt [Rot05] .
3.4.3 Uhrzeitkorrektur
Ein großes Problem der bisherigen Betrachtung liegt darin begründet, dass die Grundannahme, Satellit und
Empfänger verfügen über eine gemeinsame Zeitbasis, nicht haltbar ist. Die Satelliten selbst verfügen, wie bereits
beschrieben, über hochgenaue Atomuhren. Die Empfänger müssen sich mit einfachen Quarz-Oszillatoren begnügen.
Daher kann i.A. nicht von synchronen Uhren ausgegangen werden. Dies ist in so fern problematisch, als dass aus
einem Uhrenunterschied von einer tausendstel Sekunde ein Entfernungsfehler von ca. 300km resultiert – vergleiche
hierzu die Chip-Dauer in Kapitel 3.3.3. Die Uhren müssen im Nanosekundenbereich synchron arbeiten, um die
gewünschte Genauigkeit von unter 10 m zu erhalten. Durch die Atomuhren in den Satelliten kann (vereinfachend)
angenommen werden, dass alle Satellitenuhren synchron sind. Daher ist der Uhrenfehler des Empfängers zu allen
Satelliten gleich und durch △ 𝑡 gegeben. Die nach dem bisherigen Verfahren bestimmten Streckenlängen werden
auch Pseudoentfernungen20 genannt, da sie nicht der aktuellen realen geometrischen Distanz entsprechen. Zur
einfacheren Darstellung und zum besseren Verständnis erfolgt auch hier zunächst die Lösung dieses Problems für den
zweidimensionalen Raum: anstelle von zwei notwendigen Entfernungen nimmt man eine weitere hinzu und betrachtet
den Uhrenfehler als weitere Variable neben X und Y. Die Zeit wird als weitere Dimension berücksichtigt. Dies kann an
den nachfolgenden Abbildungen nachvollzogen werden.
Abb 3.17: Fehlerhaft ermittelter Standort aufgrund von
Uhrenfehlern
Abb 3.18: Korrekt ermittelter Standort dank Korrektur des
Uhrenfehlers mit einem weiteren Satelliten
20
Engl. Pseudo Ranges
30
Kapitel 3
Im dreidimensionalen ist die Lösung äquivalent: anstelle von drei Satelliten werden vier verwendet. Das
Gleichungssystem hat somit auch vier Gleichungen und kann entsprechend gelöst werden. Anstelle der
Ursprungsformel muss nun eine um den Uhrenfehler ergänzte Form verwendet werden:
2
2
+ 𝑍𝑖𝑠 − 𝑍𝑟 2 = 𝑡 +△ 𝑡 ∗ 𝑐 = 𝑡 ∗ 𝑐 +△ 𝑡 ∗ 𝑐
2
2
+ 𝑍𝑖𝑠 − 𝑍𝑟
2
−△ 𝑡 ∗ 𝑐 = 𝑡 ∗ 𝑐
Formel 3.4: Gleichung zur Positionsbestimmung ergänzt um Uhrenfehler
Aufgrund der Notwendigkeit des Verfahrens zur Uhrzeitkorrektur für eine exakte Positionsbestimmung resultiert die
Anforderung des NAVSTAR-Systems, dass immer mindestens vier Satelliten von einem Punkt aus sichtbar sind. Ein
weiterer Gewinn durch diesen Ansatz ist, dass jeder GPS-Empfänger zu einer kostengünstigen Uhr mit QuasiAtomuhrgenauigkeit wird. Spezielle Empfänger sind in der Lage bei vorgegebener und exakt vermessener Position mit
nur einem einzelnen Satellitensignal eine hochgenaue Zeit zur Verfügung zu stellen.
3.5
Alternative Systeme
Wie zu Anfang des Kapitels gesagt, ist GPS das derzeit einzige weltweit verwendbare Satellitennavigationssystem.
Dies wird sich jedoch in absehbarer Zeit wieder ändern. Mehrere Systeme werden in Zukunft eine verstärkte Rolle
spielen. Darunter das etwas in die Jahre gekommene System GLONASS der ehemaligen Sowjetunion, das System
Beidou/Compass, beheimatet in China, sowie GALILEO, das Prestigeprojekt der europäischen Weltraumbehörde ESA.
Eins ist bereits jetzt schon klar: aufgrund zahlreicher Bestrebungen die Systeme zueinander kompatibel zu gestalten,
werden viele neue Empfängergenerationen in der Lage sein, die Signale mehrerer, wenn nicht sogar aller globalen
Systeme zu empfangen. Dadurch wird eine Genauigkeit, insbesondere für Empfänger aus den unteren
Preissegmenten, von ungekannter Qualität ermöglicht. Da die verwendeten Systeme dem GPS sehr ähnlich sind, soll
an dieser Stelle jeweils nur ein Abriss über die Rahmendaten der einzelnen Projekte folgen. Es existieren neben den
Genannten noch einige weitere Systeme, welche jedoch regional eingeschränkt oder veraltet sind.
3.5.1 GLONASS
Bereits Ende des Jahres 1982 wurden die ersten Satelliten von der damaligen UdSSR in die Umlaufbahn gebracht.
GLONASS ist eine Abkürzung für GLObal Navigation Satelite System und wird heute vom Verteidigungsministerium der
russischen Föderation betrieben. Wie auch GPS werden im Vollausbau 24 aktive Satelliten benötigt. Obwohl das
System 1996 „offiziell als operationell erklärt wurde‚ [Wik10e] , kann bis zum heutigen Tag nicht garantiert werden,
dass zu jeder Zeit und an jedem Ort die notwendige Zahl an Satelliten für eine Positionsbestimmung verfügbar ist.
„Aufgrund vieler Ausfälle waren Ende Februar 2007 noch zehn Satelliten funktionsfähig‚ [Zog07] . 2008 verabschiedete
die damalige Regierung unter Wladimir Putin einen umfassenden Erneuerungsplan für das System bis zum Jahre
2012.
Ein nennenswerter Unterschied zwischen GLONASS und GPS ist die Verwendung eines Frequenz-MultiplexVerfahrens (FDMA21) anstelle von Codemultiplex. Es kommt zwar ebenfalls eine Kombination aus C/A- und P(Y)-Code
zur Anwendung, jedoch benutzen alle Sender die gleichen PRN-Folgen. Um die Signale der Satelliten dennoch
21
Engl. Frequency Division Multiple Access
31
Kapitel 3
trennen zu können benutzt jeder der künstlichen Erdtrabanten zwei ihm eigene Frequenzen, basierend auf zwei
Grundschwingungen von 1602 MHz (L1) und 1246 MHz (L2).
3.5.2 Beidou
Das System Beidou, eigentlich Beidou 1, war ursprünglich rein für die Verwendung in China gedacht und wird seit
etwa 2000 dort verwendet. Aufgrund der Gebietsbegrenzung werden keine umlaufenden Satelliten eingesetzt sondern
geostationäre. Die Positionsbestimmung dieses Systems basiert auf einem iterativen, interaktiven Austausch von
Positionsinformationen zwischen Navigationsempfänger und den Satelliten (vgl. [Zog09a] ).
Obwohl China am europäischen GALILEO-Projekt beteiligt ist, sollen in einer neuen Ausbaustufe – Beidou2/Compass –
bis 2015 30 umlaufende Satelliten im Orbit verfügbar sein, die einen weltweiten Regelbetrieb ermöglichen. Die
Umsetzung dieses Vorhabens läuft bereits seit 2003 [Man04] .
3.5.3 GALILEO
Im Gegensatz zu den militärisch kontrollierten Systemen GLONASS und GPS,
war es von Anfang an die Zielsetzung des GALILEO-Projekts eine
unabhängige zivile Navigationslösung zu schaffen. Aufgrund der hohen
Kosten kam es jedoch zu großen zeitlichen Verzögerungen in der
Fertigstellung des Systems. Insbesondere wurde der Betrieb von Galileo im
Mai 2007 neu ausgeschrieben. Am 28. Dezember 2005 wurde mit „GIOVE-A‚
der erste Galileo-Satellit ins All gebracht. Bisher sind neben dem Teilprojekt
EGNOS (siehe Kapitel 3.7) erst zwei Testsatelliten in Betrieb. Bis 2012 bzw.
2013 sollen jedoch „die bis zu 32 Navigationssatelliten gestartet werden‚
[OPE10] . Neben den Ländern der Europäischen Union sind noch zahlreiche
weitere Länder auf internationaler Ebene beteiligt oder verhandeln derzeit
über eine Teilnahme. Im Endausbau wird das System über 4 Mrd. EUR
gekostet haben.
Abb 3.19: Galileo Testgebiet in
Berchtesgaden, Quelle: [GAT10]
Für die Entwicklung und Erprobung von Empfängern steht vor dem operationellen Systemstart ein Netz aus 6
sogenannter Pseudoliten im Rahmen des GATE-Projekts (Galileo Test- und Entwicklungsumgebung) im Raum
Berchtesgaden zur Verfügung [GAT10] . Es handelt sich um erdgebundene Sender, welche die Signale der
eigentlichen Galileo-Satelliten nachahmen.
Der wichtigste Unterschied gegenüber GPS stellt die feinere Einteilung der verfügbaren Dienste dar. Vier Dienste
stehen dem Nutzer zur Verfügung. Daneben eine besondere Unterstützung für Search-and-Rescue Anwendungen und
Notrufe (vgl. hierzu [Zog09a] ).
Open Service
Der Open Service ist der Standarddienst von Galileo und das direkte Pendent zum Standard Positioning Service von
GPS. Die Positionsgenauigkeit wird zwischen 4 und 10 m liegen. Durch die Kompatibilität mit GPS (in der dritten
Generation) werden aber mehr Satelliten verfügbar sein und somit eine höhere Genauigkeit ermöglichen.
32
Kapitel 3
Commercial Service
Mit dem Commercial Service bietet Galileo eine höhere Positionsgenauigkeit durch die Integration von Korrekturdaten.
Neben weiteren Mehrwertdiensten sind Integritätsgarantien verfügbar. Der Zugang ist auf Empfängerebene durch
Zugriffscodes geschützt.
Safety-of-Life Service
Für kritische Anwendungen des Verkehrswesens steht der Safety-of-Life Service zur Verfügung. Hier geht es
vornehmlich um den Wasser-, Schienen- und Luftverkehr. Wichtigstes Kennzeichen ist eine automatisierte Warnung,
wenn das System nicht mehr korrekt arbeitet. Sie muss innerhalb von sechs Sekunden beim Empfänger ankommen.
Dies ist einer der wenigen großen Vorteile, die Galileo bieten wird. Der Dienst verlangt die Nutzung von ZweifrequenzEmpfängern.
Public Regulated Service
Der Zugriff auf den öffentlichen regulierten Dienst wird von staatlichen Stellen
überwacht und kontrolliert. Die Primärzielgruppe sind Organisationen des
Zivilschutzes. Die Verfügbarkeit soll auch dann noch garantiert werden können,
wenn andere GALILEO-Dienste in Krisenfällen bereits außer Betrieb gesetzt sind.
Search-and-Rescue Service
Durch den Search-and-Rescue Service wird es möglich automatisiert Notrufe über
Satellit zu empfangen, die Position an die entsprechenden Stellen weiterzuleiten und
gegebenenfalls den Notruf zu quittieren. Hierzu arbeitet Galileo mit bereits
bestehenden Systemen dieser Art zusammen.
3.6
Abb 3.20: Ablauf eines Notrufs
bei Galileo, Quelle: [Zog06]
Genauigkeit
Das wichtigste Untersuchungskriterium der satellitengestützten Positionsbestimmung ist die Positionsgenauigkeit. Die
Untersuchungen in diesem Abschnitt stellen den Ausgangspunkt der praktischen Realisierung des Prototyps dar, wie
er später vorgestellt wird. Hierzu ist es jedoch notwendig, zunächst einmal zu definieren, welche Anforderung an ein
GNSS überhaupt gestellt werden – also für welchen Anwendungsfall welche Genauigkeit benötigt wird. Daran
schließen sich Ausführungen über die relevanten Fehlerquellen und Fehlergrößen an. Zum Abschluss folgen die
Ergebnisse verschiedener praktischer Versuchsreihen.
3.6.1 Anforderungen
Da GPS mittlerweile in den verschiedensten Anwendungsdomänen beheimatet ist, muss eine Vielzahl
unterschiedlicher Situationen abgedeckt werden. Hierbei werden jeweils unterschiedliche Genauigkeits- und
Integritätsanforderungen gestellt. Zwei Arten von Anwendungen können unterschieden werden: statische
Anwendungen, sowie dynamische Anwendungen. Wird im ersten Fall nur eine Punktbestimmung benötigt, noch dazu
ohne große Echtzeitkriterien, ist es bei letzteren Anwendungen erforderlich ein bewegtes Objekt in Echtzeit zu
verfolgen. Die Integritätsanforderungen ergeben sich aus den Folgen eines Ausfalls für die konkrete Anwendung.
Unter einer hohen Integrität ist nicht zu verstehen, dass das System keinesfalls ausfallen oder falsche Daten senden
darf, sondern vielmehr, dass das System selbständig erkennt und darüber informiert, dass ein Problem besteht.
33
Kapitel 3
Plattentektonik und geodynamische Untersuchungen
Im Falle dieser Art von Untersuchungen werden die höchsten Anforderungen an die Genauigkeit gestellt. Die
Kontinentalplatten weisen pro Jahr eine Bewegung im Millimeter- oder Zentimeterbereich auf (siehe Kapitel 2.3).
Allerdings sind hier auch sehr lange Beobachtungszeiten (wenige Stunden bis mehrere Jahre) problemlos möglich
und die Anforderungen an die Integrität sind vergleichsweise gering.
Vermessung
In der Land- und Ingenieursvermessung werden ebenfalls hohe Genauigkeiten gefordert. Je nach Anwendungsfall im
Dezimeter-, Zentimeter- oder Millimeterbereich. Die Beobachtungszeiten sind ebenfalls noch relativ lang – mehrere
Minuten bis zu mehreren Stunden. Eine hohe Integrität spielt eine untergeordnete Rolle.
Schiffs-, Straßen- und Schienenverkehr
Die verschiedenen Verkehrsarten stellen annähernd die gleichen Anforderungen an ein Navigationssystem. Im
Gegensatz zu den bisher genannten Applikationen wird hier jedoch ein kontinuierlicher Koordinatenstrom benötigt, der
ein Objekt in Echtzeit verfolgt. Die Integritätsanforderungen müssen daher höher angesetzt werden. Dies gilt
insbesondere für den Schiffs- und Schienenverkehr, da hier teilweise bereits automatische Steuerungs- und
Überwachungssysteme eingesetzt werden. Die Genauigkeit hingegen liegt im Bereich mehrerer Meter. Neue
Anwendungen, wie z.B. Fahrspurassistenten für Straßennavigationssysteme benötigen höhere Genauigkeiten.
Landwirtschaft
Einen Sonderfall stellen landwirtschaftliche Anwendungen dar, konkret geht es
um die exakte Bestellung landwirtschaftlicher Nutzflächen. Hier entstand aus
ökonomischen Gründen die Notwendigkeit genauer paralleler Fahrspuren. Die
Anforderungen sind definiert durch eine Genauigkeit im unteren
Dezimeterbereich in Echtzeit bei gleichzeitig hoher Integrität. Die hohe
Integrität rührt daher, dass es mit Hilfe verschiedener auf dem Markt
befindlicher Systeme möglich geworden ist, Landwirtschaftliche Arbeitsgeräte,
wie z.B. Traktoren, automatisiert zu betreiben.
Abb 3.21: Landwirtschaftliches
Parallelfahrsystem, Quelle: [Top07]
Luftverkehr
Die Anforderungen der Luftfahrt sind zweigeteilt. Generell wird eine Positionsbestimmung in Echtzeit bei
höchstmöglicher Integrität gefordert, da auch hier bekanntermaßen automatisierte Steuerungssysteme verwendet
werden und Unfälle sehr hohe Schäden an Menschen und Sachgütern nach sich ziehen können. Die
Genauigkeitsanforderungen differieren jedoch zwischen dem gewöhnlichen Streckenflug und dem Landeanflug. Steht
die meiste Zeit eines Fluges ein Korridor in der Größenordnung von 100 Metern und mehr zur Verfügung, so muss
beim Landeanflug die Position bis in den Submeterbereich bekannt sein. Insbesondere die Höhe ist von
entscheidender Bedeutung. Erschwerend kommt hinzu, dass die Landegeschwindigkeiten moderner
Verkehrsflugzeuge bei etwa 250 km/h liegen. Daher können die Anforderungen, wie sie für Instrumentenlandeanflüge
definiert sind (vgl. [Man04] ) von GPS alleine in seiner Grundform bisher nicht geleistet werden. Zusätzliche lokale
differentielle Korrektursysteme oder andere Hilfsmittel sind notwendig.
Fußgängernavigation
Auch die Fußgängernavigation stellt GPS vor besondere Herausforderungen. Die Integritätsvorgaben dürfen als sehr
niedrige angesehen werden. Das Problem ist jedoch einerseits, dass Fußgänger sich oft in Gebieten mit schlechten
Empfangsbedingungen, wie Gebäuden, Häuserschluchten oder Waldgebieten aufhalten und andererseits, dass das
vorhandene Kartenmaterial zu ungenau für die Freiheitsgrade eines Fußgängers ist. Das macht die Anwendung von
Street-Matching-Verfahren (siehe Kapitel 3.7.2) sehr schwer. Als Positionierungsgenauigkeit dürfen je nach konkretem
34
Kapitel 3
Anwendungsfall zehn Meter bis hinunter auf etwa zwei Meter angenommen werden. Die Position muss in Echtzeit zur
Verfügung stehen. Ein Sonderfall stellt die Blindennavigation dar. Hier wird eine durchgehend hohe Integrität bei
gleichzeitiger hoher Positionsgenauigkeit von ein bis zwei Metern gefordert.
Abb 3.22: Zusammenhang zwischen Genauigkeit und Integrität
bezogen auf verschiedene Anwendungsgebiete
Innerhalb des Projekts soll als Ziel zunächst definiert sein, bestehende Verfahren zu erarbeiten, soweit möglich zu
evaluieren und einen Kompromiss zwischen Genauigkeit und Mitteleinsatz für den zu erstellenden Prototypen zu
finden. Die für das automatisierte Erstellen von Karten notwendige Genauigkeit orientiert sich an den bereits
vorhandenen Kartendaten und wird in späteren Abschnitten nochmals beleuchtet.
3.6.2 Fehlerquellen
In den voran gegangenen Kapiteln zur Positionsbestimmung wurde GPS sehr idealisiert betrachtet. Verschiedene
Einflussgrößen wirken jedoch störend auf die Genauigkeit einer Ortung mit einem GNSS. An dieser Stelle sollen diese
im Einzelnen benannt und untersucht werden. Beginnend beim Satelliten bis hinunter zum Empfänger. Alle
Fehlerquellen wirken sich auf die Bestimmung der Pseudoentfernungen aus und können mehr oder weniger gut
kompensiert werden.
Grundsätzlich unterscheiden kann man Fehlereinflüsse, welche sich auf alle Empfänger innerhalb eines gewissen
Gebietes gleich auswirken, sie werden als systembedingte Fehler bezeichnet, und Fehlereinflüsse, welche nur für
einen einzelnen Empfänger gelten, sogenannte lokale Fehler. Erstere sind durch Messungen von Referenzstationen
ermittelbar und somit kompensierbar, letztere haben meist statistischen Charakter und können nicht auf einfache
Weise heraus gerechnet werden. Die in der Literatur oft erwähnte künstliche Verschlechterung des Signals durch die
Selective Availabilty soll hier nicht weiter behandelt werden, da nach [Zog09b] die neuste Generation von GPSSatelliten diese Möglichkeit der Verschleierung ohnehin nicht mehr unterstützt.
Relativistische Einflüsse
Aufgrund der relativ großen Relativgeschwindigkeiten der Satelliten zur Erdoberfläche und Ihrem großen Abstand
treten sowohl Effekte der allgemeinen, als auch der speziellen Relativitätstheorie auf, welche die Frequenz der
Atomuhren beeinflussen. Zum einen vergeht die Zeit für in Bewegung befindliche Körper langsamer (Satellit mit
Relativgeschwindigkeit von etwa 2 km/s) und zum anderen vergeht sie für Körper in schwachen Gravitationsfeldern
schneller (Satellitenbahn in einer Höhe von 20.000 km). Dies führt in Summe dazu, dass, vom Empfänger auf der
35
Kapitel 3
Erdoberfläche aus betrachtet, die Uhren der Satelliten „etwa 38 Mikrosekunden pro Tag‚ [Köh08c] zu schnell laufen.
Dieser Einfluss kann jedoch als konstant für alle GPS-Satelliten betrachtet werden und wird mit einem einfachen Trick
kompensiert: anstelle der Nennfrequenz von 10,23 MHz betreibt man die Atomuhren mit einer Frequenz von
10.229999995453 MHz, rechnet jedoch weiterhin mit dem Ursprungswert. Somit kann dieser Einflussfaktor als
vernachlässigbar angesehen werden. Für weitere Informationen zu relativistischen Effekten sei auf die entsprechende
Literatur verwiesen.
Uhrenfehler der Satelliten
Wie bereits in Kapitel 3.4.3 beschrieben, führen Zeitunterschiede zwischen den verwendeten Uhren von Satellit und
Empfänger zu erheblichen Fehlern in der Entfernungsbestimmung. Zur Erinnerung: eine tausendstel Sekunde macht
einen Fehler von 300 Kilometern aus. In der bisherigen Betrachtung wurden alle Satellitenuhren dank
Atomuhrgenauigkeit als gleich betrachtet. Dies ist jedoch nur die halbe Wahrheit, denn auch die Satellitenuhren
unterliegen Schwankungen und Ungenauigkeiten. Zur Kompensation dieses Effekts liefern die Satelliten in den
Navigationsmitteilungen verschiedene Informationen, die notwendig sind, diesen Fehler zu korrigieren.
Bahnfehler
Die Positionsbestimmung basiert neben der Ermittlung der Signallaufzeiten grundsätzlich darauf, dass man die
aktuelle Position eines Satelliten genau kennt. Dies wird erreicht, durch die Übermittlung der Ephemeriden in den
Navigationsmitteilungen. Die Ephemeriden enthalten sämtliche Bahnparameter, die notwendig sind, um die Position
eines Satelliten zu einem bestimmten Zeitpunkt zu ermitteln. Die Bahnen sind jedoch aufgrund diverser Einflüsse nicht
konstant. Die Bahndaten basieren auf Messungen und Vorausberechnungen der Bodenstationen. Die Ergebnisse
werden an die Satelliten übertragen, welche sie wiederum an die Empfänger weiterleiten. Die übermittelten Bahndaten
sind jedoch nur auf etwa 2m genau (vgl. [Rot05] ).
Atmosphärische Einflüsse
Bei den Laufzeitbestimmungen wurde bisher vereinfachend die Lichtgeschwindigkeit im Vakuum als
Ausbreitungsgeschwindigkeit angenommen. Das Signal muss jedoch auf dem Weg zum Empfänger durch die
Erdatmosphäre: ‚Die unterschiedlichen Ausbreitungsbedingungen …, die das Signal auf seinem Weg vom Satelliten
zum Empfänger vorfindet, führen dazu, dass das Signal einen kurvenförmigen Weg durchläuft und sich mit
unterschiedlichen Geschwindigkeiten ausbreitet‚ [Bau97] . Das heißt zum einen der Signalweg wird länger und zum
anderen das Signal wird verlangsamt. Die für die Beeinflussung maßgeblichen Schichten sind die Ionosphäre und die
Troposphäre.
Ionosphäre
Die Besonderheit der Ionosphäre liegt im Vorhandensein geladener Teilchen, sogenannter Ionen. Diese entstehen vor
allem durch starke Sonnenaktivitäten. Durch Ultraviolette, sowie Röntgenstrahlung werden negativ geladene
Elektronen aus Gasmolekülen abgespalten. Sobald die Sonnenaktivität wieder nachlässt, bilden sich die Ionen wieder
zurück. Das erklärt, warum es zu tageszeitlichen, jahreszeitlichen und örtlichen Schwankungen kommt. Insbesondere
nachts geht die Ionisation zurück. Die Schicht erstreckt sich von etwa 60 km bis etwa 1000 km über Grund. Je nach
Ionisationsgrad werden die Signale unterschiedlich stark abgelenkt und abgebremst. Sind die Pseudoentfernungen
nachts kaum durch die Ionosphäre beeinflusst, so können am Tag Abweichungen bis zu 50 Metern entstehen. Da die
Ionosphäre für den Frequenzbereich der GPS-Signale ein dispersives22 Medium darstellt, sind Zweifrequenzempfänger
in der Lage den Einfluss der Schicht heraus zu rechnen. Basierend auf dem Klobuchar-Modell werden in den
Navigationsmitteilungen Korrekturparameter für die Ionosphäre übermittelt (vgl. [Bau97] ).
22
Dispersives Medium bedeutet, dass der Grad der Ablenkung bzw. Geschwindigkeitsveränderung abhängig von der gewählten Frequenz ist.
36
Kapitel 3
Troposphäre
Unter Troposphäre versteht man die unteren 10 bis 15 Kilometer der Erdatmosphäre. In ihr „vollziehen sich die
Wettervorgänge‚ [Man04] . Hier kommt es ebenfalls zu Brechungseffekten aufgrund von unterschiedlichen
Ausbreitungsgeschwindigkeiten. Diese resultieren sehr stark aus dem Grad der Luftfeuchtigkeit. Je höher der
Wasserdampfgehalt, desto weniger wird das Signal abgelenkt. Entscheidend ist auch die Weglänge, die ein Signal
innerhalb der Troposphäre zurücklegen muss. Diese ist bei einem flachen Einstrahlwinkel deutlich länger und wirkt
sich somit stärker auf die Pseudostreckenmessung aus.
Mehrwegeeinflüsse
Ein weiteres Problem stellen die physikalischen Effekte der Beugung (Abb 3.23) und Reflexion (Abb 3.24) dar, da sie
ebenfalls den Signalweg verlängern und somit die Laufzeit verfälschen. Insbesondere kann es dazu kommen, dass an
einem bestimmten Punkt ein und dasselbe Signal mehrfach empfangen wird (Abb 3.25). Dann spricht man von
Mehrwegeempfang. Besonders tragisch ist dies, wenn die Korrelatoren fälschlicherweise ein reflektiertes Signal
erfassen und ein direktes Signal ignorieren. Bei niedrigen Erhebungswinkeln der Satelliten über dem Horizon ist dieser
Effekt am stärksten.
Abb 3.23: Empfang durch Beugung
Abb 3.24: Empfang durch Reflexion
Abb 3.25: Mehrwegeempfang
(direkt und reflektiert)
Die Bedingungen eines Mehrwegeempfangs wechseln sehr oft. So kann es zu starken Schwankungen der Position im
Sekunden- oder Minutentakt kommen. Der Mehrwegeempfang stellt insbesondere bei statischen Messungen eines der
größten Probleme von GPS dar. Eine geeignete Wahl der Antennenkonstruktion ermöglicht eine höhere Störfestigkeit
gegenüber Reflexionen (vgl. [Köh08c] ).
Uhren- und Rundungsfehler des Empfängers
Neben den bisher genannten Einflüssen kommt es im Empfänger selbst durch ungenaue Quarze, Verzögerungen
durch die Berechnungen, Sensorrauschen und ähnlichen Ursachen zu einem Uhrenfehler auf Empfängerseite. Diese
werden zum großen Teil durch die in Kapitel 3.4.3 beschriebene Uhrzeitkorrektur ausgeglichen.
Gegenseitige Störungen bei Verwendung mehrerer Empfänger
Im Verlauf des Projekts wurde untersucht, in wie weit der Empfang mit mehreren parallelen, voneinander
unabhängigen Empfängern einen Gewinn bringen kann. Hier ist zu beachten, dass es nicht auszuschließen ist, dass
sich die GPS-Empfänger untereinander stören. Die verwendeten PRN-Codes, welche in Kapitel 3.3.3 beschrieben
wurden, gelten als relativ unempfindlich gegenüber Störungen. Doch schreibt [Ral01] beispielsweise: „Ein GPS-Gerät
kann einen Magnetkompass stören und zu erheblichen Missweisungen führen, wenn sich die beiden Geräte in
unmittelbarer Nähe befinden‚. Dieser Effekt könnte auch in den praktischen Versuchen festgestellt werden. Von einer
gegenseitigen Abschirmung kann nicht ausgegangen werden. Auch wenn die erhobenen Testreihen aufgrund zu
großer Ungenauigkeiten keinen Rückschluss auf eine gegenseitige Beeinflussung erlauben, so ist es doch
vorzuziehen, mehrere Empfänger mit Abstand zu positionieren und die Distanzen im Nachhinein oder in Echtzeit
heraus zu rechnen. Auch andere elektromagnetische Einflüsse sollten weitestmöglich vermieden werden.
37
Kapitel 3
Fehlerbilanz
Wenn man alle noch verbleibenden Fehler berücksichtigt erhält man in etwa nachfolgende Fehlerbilanz (die Zahlen
sind jedoch nur als Größenordnung zu verstehen und schwanken in der Literatur entsprechend stark):
systembedingte Fehler
lokale Fehler
Fehlerart
Uhrenfehler der Satelliten
Bahnfehler der Ephemeriden
Störungen in der Ionosphäre
Störungen in der Troposphäre
Mehrwegefehler
Uhren- und Rundungsfehler des Empfängers
∑
Größenordnung
±2 𝑚
±2.5 𝑚
±5 𝑚
±0.5 𝑚
±1 𝑚
±1 𝑚
±12 𝑚
Tabelle 3.4: Fehlerbilanz für GPS ohne Korrekturinformationen, Zahlen aus [Köh08c]
Das besondere an systembedingten Fehlern ist, dass sie mit Hilfe von Referenzstationen für limitierte Gebiete
berechnet werden und somit eliminiert werden können. Dies wird in Kapitel 3.7.1 verdeutlicht.
Neben den hier geschilderten „groben‚ Fehlern, sind bei hochgenauen Anforderungen noch weitere Einflüsse zu
berücksichtigen. Diese bewegen sich jedoch im cm und mm Bereich und können im Rahmen dieses Projekts
vernachlässigt werden. Darunter fallen z.B. die Berücksichtigung des Phasenzentrums der Sende- und
Empfangsantenne, d.h. der gedachte Punkt an der Antennenkonstruktion an dem die Messung erfolgt.
3.6.3 Fehlergrößen
Bei der Frage nach der Genauigkeit einer Positionsbestimmung ist es notwendig, sich zunächst über die relevanten
Kenngrößen Gedanken zu machen. Nur so ist eine empirisch fundierte Aussage möglich. In [Köh09c] wird eine
Einführung in die Definitionen von Präzision, Richtigkeit und Genauigkeit gegeben. Die hier geschilderte Verwendung
der Begrifflichkeiten soll noch einmal aufgegriffen werden, da dies sich sehr gut auf die Gegebenheiten von GPS in
Bezug auf Abweichungen anwenden lässt. Im Anschluss werden die sogenannten DOP-Werte untersucht, welche sich
aus der Satellitengeometrie ableiten, sowie weitere statistisch relevante Fehlermaße.
Begriffsbestimmung
Mit dem Begriff der Präzision wird zunächst einmal definiert, wie stark Messwerte voneinander abweichen. In Bezug
auf GPS bedeutet das, dass eine Messung umso unpräziser ist, je größer die eingenommene Fläche der ermittelten
Positionen ist. Eine hohe Präzision bedeutet zunächst nicht, dass die ermittelte Position der tatsächlichen Position
besonders gut entspricht, sondern nur wie gut eine Messung wiederholbar die gleichen Ergebnisse liefert.
Im Gegensatz hierzu meint Richtigkeit, wie gut sich die Messergebnisse in Summe an die tatsächliche Position
annähern. Betrachtet wird das Mittel aller erfassten Messwerte. Wenn es die Referenzposition gut annähert, spricht
man von einer hohen Richtigkeit.
Die Genauigkeit einer Messung ergibt sich daraus, wie nahe jeder einzelne Messwert an der Sollposition liegt. Sind
Präzision und Richtigkeit hoch, hat man auch eine hohe Genauigkeit. Abb 3.26 bis Abb 3.29 verdeutlichen diesen
Zusammenhang noch einmal. Die grünen Felder stellen jeweils den Streuungsbereich der Messergebnisse dar. Nur im
letzten Fall ist auch eine hohe Genauigkeit gegeben.
38
Kapitel 3
Das Fadenkreuz markiert den Referenzpunkt, der grüne Kreis markiert den Streuungsradius
Abb 3.26: Niedrige
Richtigkeit und Präzision
Abb 3.27: Niedrige Richtigkeit
und hohe Präzision
Abb 3.28: Hohe Richtigkeit
aber niedrige Präzision
Abb 3.29: Hohe Richtigkeit
und hohe Präzision
Bezugnehmend auf die in Kapitel 3.6.2 genannten Fehlerquellen kann man an dieser Stelle vereinfachend annehmen,
dass eine schlechte Richtigkeit eine Folge großer systembedingter Einflüsse darstellt. Eine schlechte Präzision
hingegen eher auf stark schwankende lokale Bedingungen zurückzuführen ist, wie etwa einem wechselnden
Mehrwegeempfang. Dies kann jedoch nur als Orientierung betrachtet werden.
Satellitengeometrie
Unter der Satellitengeometrie versteht man die momentane geometrische Konstellation, in der die empfangenen
Satelliten und der Empfänger zueinander stehen. Obwohl dies keinen direkten Einflussfaktor auf die Qualität der
Pseudostrecken darstellt, so kann es jedoch in einer schlechteren Positionsgenauigkeit resultieren. Stehen die
Satelliten nahe beieinander ergibt sich bei gleicher Pseudostreckenlängen-Ungenauigkeit eine größere Fehlerfläche,
als wenn Satelliten weit auseinander stehen. Abb 3.30 und Abb 3.31 zeigen dies für den vereinfachten
zweidimensionalen Fall.
Abb 3.30: Stehen Satelliten nahezu orthogonal zueinander,
ergibt sich die kleinstmögliche Fehlerfläche
Abb 3.31: Stehen Satelliten nahe beieinander,
ergibt sich eine große Fehlerfläche
Die Kenngröße, die diesen Effekt beschreibt, wird als „Dilution of Precision‚ oder kurz DOP bezeichnet – zu Deutsch
die „Abschwächung der Genauigkeit‚. Es „ist somit ein Faktor bzw. Mass für die konstellationsabhängige
Ungenauigkeit‚ der aktuellen Satellitenkonfiguration und „kann als reziproker Wert des Volumens eines Tetraeders
gedeutet werden, der aus Satelliten- und Nutzerpositionen gebildet wird‚ [Zog09a] , wie Abb 3.32 und Abb 3.33
zeigen. Der Positionsfehler ist direkt proportional zum DOP-Wert.
Abb 3.32: Großes Volumen - Kleiner DOP-Wert
Abb 3.33: Kleines Volumen - großer DOP-Wert
39
Kapitel 3
Da sich die Satellitenkonstellation unterschiedlich auf die einzelnen Freiheitsgrade (X,Y,Z,t) einer Positionsbestimmung
auswirkt, werden in der Praxis auch unterschiedliche DOP Maße bestimmt. Insgesamt fünf Werte werden vom GPSEmpfänger anhand der Satellitengeometrie ermittelt (siehe Tabelle 3.5). Wie sich die einzelnen Werte mit Hilfe einer
Varianz-Kovarianzmatrix aus dem Gleichungssystem zur Bestimmung der Position ableiten lassen, beschreibt [Bau97]
.
Bezeichnung
HDOP
VDOP
PDOP
TDOP
GDOP
Beschreibung
Abschwächung der Lagegenauigkeit (Horizontal DOP)
Abschwächung der Höhengenauigkeit (Vertical DOP)
Abschwächung der Positionsgenauigkeit (Position DOP)
Abschwächung der Zeitgenauigkeit (Time DOP)
Gesamtabschwächung (Geometrical DOP)
Tabelle 3.5: Die verschiedenen DOP-Kenngrößen
Die genannten Einflussgrößen sind insbesondere dann relevant, wenn man sich in Gebieten mit schlechten
Empfangsbedingungen aufhält, wie etwa in Häuserschluchten, Waldgebieten oder Gebirgen. Hier kommt es zu
starken Abschattungen und somit zu einer schlechten Satellitengeometrie. In den nachfolgenden Abbildungen ist ein
HDOP-Verlauf über 24 Stunden dargestellt, jeweils für einen Messpunkt ohne Abschattung und für einen Messpunkt
mit starker Abschattung. Für die Praxis sind DOP-Werte unter drei ausreichend für eine gute bis sehr gute
Positionsermittlung. Über zehn ist die Positionsbestimmung kaum mehr möglich oder extrem ungenau.
Abb 3.34: 24-Stunden Verlauf des HDOPs ohne Abschattung (max HDOP<1.9),
Quelle: [Zog09a]
Abb 3.35: 24-Stunden Verlauf des HDOPs mit starker Abschattung (max HDOP>20),
Quelle: [Zog09a]
Statistische Genauigkeitsmaße
Neben dem zunächst etwas abstrakt wirkenden DOP-Maß kommen bei der Bewertung von Messungen auch bekannte
statistische Messgrößen zur Anwendung. Sie sollen hier ebenfalls in aller Kürze vorgestellt werden. Es sei bemerkt,
40
Kapitel 3
dass sich die vorgestellten Maße auf die Beurteilung der Positionsbestimmung beziehen, nicht auf die Bestimmung
der Pseudostrecken. Da die absoluten systembedingten Fehler keinen statistischen Gesetzmäßigkeiten folgen, kann
über sie auch keine Aussage mit den Mitteln der Statistik erfolgen. Sie auszuschließen oder zu verringern ist die
Aufgabe der Methoden, die in Kapitel 3.7 vorgestellt werden. Für die lokalen Streuungen ist dies jedoch möglich,
daher wäre es auch korrekter von Präzisionsmaßen anstelle von Genauigkeitsmaßen zu sprechen (siehe oben
Präzision und Richtigkeit). Sollen trotzdem absolute Fehler angegeben werden, empfiehlt es sich den mittleren
Abstand zum Lagefestpunkt anzugeben. Drei Größen haben sich in der Praxis bewährt: zum einen die
Standardabweichung, der mittlere Punktfehler und die sogenannten CEP-Fehlerkreise. Damit man als Größenangabe
einen Wert in Metern erhält, ist es von Vorteil, die Berechnungen in einem orthogonalen, metrischen
Koordinatensystem durchzuführen, wie z.B. UTM. Außerdem können die hier vorgestellten Methoden nur für statische
Positionsmessungen durchgeführt werden.
Standardabweichung
Die Standardabweichung ist einer der wichtigsten mathematischen Streuungsparameter. Voraussetzung für die
korrekte Deutung des Zahlenwerts ist jedoch, dass die zugrundeliegende Messreihe normalverteilt ist. Eine solche
Messreihe ist durch den Mittelwert und die Standardabweichung eindeutig beschrieben. Allgemein wird die
Normalverteilung bei GPS-Messungen als gegeben angenommen. Ermittelt wird sie mit Hilfe nachfolgenden Formel:
𝜎=
𝜎
𝑛
1
𝑛−1
𝑛
(𝑥𝑖 − 𝑥 )2
𝑖=1
Standardabweichung
Anzahl der Messwerte
𝑥𝑖
𝑥
Messwert i
Arithmetischer Mittelwert
Formel 3.5: Standardabweichung
Wie man erkennt, ist die Formel der Standardabweichung ein eindimensionales Maß. Eine Positionsbestimmung ist
jedoch mindestens zweidimensional. Daher müssen die einzelnen Koordinatenteile getrennt betrachtet werden. Das
besondere an normalverteilten Größen im Bezug auf ihre Standardabweichung ist ihre einfache Deutung bezüglich der
Wahrscheinlichkeit, dass ein bestimmter Messwert innerhalb einer bestimmten Abweichung zum Mittelwert liegt. So
liegen 68,3% der Messewerte innerhalb von ±𝜎 um den Mittelwert, 95,5% innerhalb von ±2𝜎 und 99,7% innerhalb
von ±3𝜎.
Mittlerer Punktfehler
Üblicherweise ergeben die Messwerte einer Positionsbestimmung keine nach allen Richtungen normalverteilte
Punktmenge mit gleicher Standardabweichung. Die Messwerte sind vielmehr in Form einer Ellipse verteilt. Um dies zu
beschreiben „müßte man also die Größen der Halbachsen der „Fehlerellipse‚ und deren Richtung im jeweiligen
Koordinatensystem einführen.‚ [Bau97] In der Praxis möchte man jedoch ein einfaches verständliches Maß zur
Bewertung der Positionsgenauigkeit in Form eines Fehlerradius‘ um den Mittelwert. Der mittlere Punktfehler hat sich als
geeignetes Mittel zu diesem Zweck herausgestellt. Im englischen wird er oft als distance root mean square
bezeichnet (drms) Die Begriffe sind jedoch nur unter vereinfachenden Annahmen identisch, wie sie z.B. in [Wel03]
erwähnt sind. Tatsächlich angegeben wird außerdem meist nicht der drms sondern der 2drms-Wert.
41
Kapitel 3
𝑑𝑟𝑚𝑠 =
𝜎𝑥
𝜎𝑦
𝜎𝑥2 + 𝜎𝑦2
2𝑑𝑟𝑚𝑠 =
(2𝜎𝑥 )2 + (2𝜎𝑦 )2
Standardabweichung der X-Komponente
Standardabweichung der Y-Komponente
Formel 3.6: Mittlerer Punktfehler drms
Abb 3.36: Doppelter mittlerer Punktfehler 2drms
Wie nachfolgende Grafik zeigt, lässt sich der mittlere Punktfehler relativ einfach mit Hilfe der Standardabweichungen
geometrisch interpretieren. Mit dem 2drms-Wert geht dies äquivalent. Aus statistischer Sicht bedeutet der Wert, dass
mindestens 63,2% bis maximal 68,3% der Messwerte innerhalb des Fehlerkreises liegen, je nach Verhältnis zwischen
𝜎𝑥 und 𝜎𝑦 , innerhalb des 2drms –Kreises zwischen 95,4% und 98,2%.
Abb 3.37: Geometrische Interpretation des mittleren Punktfehlers
CEP-Fehlerkreise
Die CEP-Werte dürften wohl die bekanntesten statistischen Messgrößen bei GPS sein, da die meisten
Endverbraucher-Geräte Ihre jeweilige Genauigkeit auf diese Art angeben. Das Kürzel steht für Circular Error Probable.
Angegeben werden typischerweise entweder der CEP50 oder der CEP95. Damit sind die Radien der Fehlerkreise
gemeint, innerhalb derer sich entweder 50% oder 95% aller Messwert befinden. Um die CEP Radien aus den
Standardabweichungen zu bestimmen kann man sich nachfolgender Faustformeln bedienen:
𝐶𝐸𝑃50 ≈ 0,59 ∗ (𝜎𝑥 + 𝜎𝑦 ) ± 3%
𝐶𝐸𝑃95 ≈ 2,08 ∗ 𝐶𝐸𝑃50
Formel 3.7: Bestimmung des CEP50-Radius aus den
Standardabweichungen
Formel 3.8: Bestimmung des CEP95-Radius aus dem CEP50Radius
3.7
Methoden zur Verbesserung von GPS
In diesem Abschnitt sollen verschiedene Methoden vorgestellt werden, mit deren Hilfe man die
Positionierungsgenauigkeit verbessern kann. Die verwendeten Mittel sollen sich rein auf GPS-basierte Verfahren
stützen. Mit dieser Einschränkung wird sichergestellt, dass die vorgestellten Ansätze ohne weiteres auch auf andere
Szenarien als die Fahrzeugnavigation angewandt werden können. Zur Verfügung stehen ausschließlich GPSEmpfänger, die vorhandenen Kartendaten, sowie ein mobiler Internetzugang über GSM zur Anbindung an eine evtl.
notwendige externe Infrastruktur.
Ansätze, die eine zusätzliche Sensorik (z.B. Radsensoren, Magnetfeldmesser oder Gyroskope) benötigen, wie etwa
bei der Koppel- und Trägheitsnavigation bei inertialen Navigationssystem bleiben außen vor. Ebenso optische oder
bodenfunkgestützte Methoden. Derartige Vorgehensweisen sind in [Gür09] , [Lut08] , [Jot01] oder [Stü04] zu finden.
42
Kapitel 3
Prinzipiell sollen an dieser Stelle zwei grundsätzliche Bereiche unterschieden werden. Zum einen die technische
Ebene. Durch direkte Einbringung von Korrekturdaten in die Messung des Empfängers soll eine Verbesserung herbei
geführt werden. Zum anderen auf logischer Ebene. Damit ist gemeint, dass man mit Hilfe der vom Empfänger
ermittelten Positionsdaten versucht auf höherer Ebene die Ergebnisse zu verbessern. Ein weiteres
Untersuchungskriterium ist die Notwendigkeit einer Infrastruktur: Ist der Empfänger bei dem jeweils untersuchten
Verfahren in der Lage die Verbesserung autonom durchzuführen, oder ist er auf weitere Informationen angewiesen.
3.7.1 Technische Ebene
Die hier vorgestellten Methoden werden im allgemeinen
Sprachgebrauch mit dem Begriff des Differential GPS
zusammengefasst. Grundidee ist, dass zwei Stationen in
unmittelbarer Nähe zueinander den gleichen systembedingten
Fehlern ausgesetzt sind. Da dies aber gleich mehrere
Verfahren mit teils sehr unterschiedlichen Ansätzen umfasst,
soll hier eine feinere Differenzierung gewählt werden. Der
Hauptunterschied liegt darin, ob die Messung der Abb 3.38: Grundaufbau eines Differential GPS Systems
Pseudostreckenlängen auf Basis der Codephasenlage oder
der Trägerphasenlage (siehe Kapitel 3.4.1) durchgeführt wird. Der Aufbau ist jedoch bei beiden Ansätzen
vergleichbar: Eine Referenzstation empfängt die aktuellen GPS-Signale. Da die Position der Station exakt bekannt ist,
kann sie Abweichungen und systembedingte Fehler mathematisch bestimmen. Diese werden in Form von
Korrekturdaten an die eigentlichen GPS-Empfänger geschickt. Die Qualität der Korrektur ist somit implizit abhängig
von der Qualität der Referenzstationskoordinaten. Außerdem ist der Abstand Referenzstation zum Messempfänger von
entscheidender Bedeutung. Die GPS-Geräte, welche nicht als Referenzstation eingesetzt werden, sondern für die
eigentliche Messung, werden als Rover23 bezeichnet. Abb 3.38 stellt einen solchen Aufbau dar.
Codephasenbasiertes DGPS
Korrektursignale auf Basis der Codephase stellen die einfachste Form der differentiellen Korrektur dar. Die
Referenzstation, welche ihre Koordinaten exakt kennt, kann mit Hilfe der vorhandenen Satellitenbahnmodelle die
exakte Solldistanz zu einem Satelliten berechnen. Außerdem empfängt sie die aktuellen GPS-Signale auf der
Codeebene und ermittelt so die gegenwärtige Pseudodistanz. Die Differenz zwischen Sollstrecke und Iststrecke wird
als Korrekturparameter verwendet. Zu beachten ist, dass der Empfängeruhrenfehler der Referenzstation aus den
Korrekturen heraus gerechnet werden muss [Bau97] . Damit können Bahnfehler und atmosphärische Einflüsse
weitestgehend ausgeschlossen werden. Der maximal realistische Genauigkeitsgewinn dieses Verfahrens begrenzt
sich jedoch auf den Grad der ermittelbaren Chip-Verschiebung (siehe Kapitel 3.4.1), welche bei normalen Empfängern
in etwa zwischen 1 und 3 m liegt. Dafür kann der Abstand zur Referenzstation relativ groß sein. Distanzen von 100km
sind noch problemlos.
Trägerphasenbasiertes DGPS
„Mit der Messgröße Träger-Phase ergibt das Differentialverfahren eine hohe Genauigkeit im cm Bereich‚, so [Man04] .
Wie bereits beschrieben ergibt sich in diesem Fall jedoch das Problem der Mehrdeutigkeiten in der Phasenlage, weil
diese nur innerhalb der Wellenlänge von etwa 20 cm eindeutig ist. Je nach Genauigkeit der zugrundeliegenden
Messdaten ist durch entsprechend lange Beobachtungszeiten (> 1h) Millimetergenauigkeit möglich.
23
Zu Deutsch Wandernder
43
Kapitel 3
Im Gegensatz zur Codephasenvariante, bei der Streckenkorrekturparameter zur Verfügung gestellt werden, erfasst
man in diesem Fall die Phasendifferenzen zwischen Referenzstation und Rover. Die Berechnungen erfolgen durch die
sogenannte einfache (ein Satellit, zwei Empfänger), zweifache (zwei Satelliten, zwei Empfänger) oder dreifache (zwei
Satelliten, zwei Empfänger, zwei verschiedene Zeitpunkte) Differenzenbildung. Die beiden ersteren Verfahren erlauben
es Uhrenfehler der Satelliten, Bahnfehler und atmosphärische Einflüsse heraus zu rechnen. Die dreifache
Differenzierung ermöglicht zusätzlich die gewünschte Auflösung der Mehrdeutigkeiten. Die genauen mathematischen
Hintergründe sind in [Bau97] und [Rot05] nachzulesen. Durch die Differenzenbildung ermittelt man keine absoluten
Koordinaten mehr, sonder einen Vektor relativ zur Referenzstation – die sogenannte Baseline24. Zur Gewinnung der
Zielkoordinaten müssen Referenzstationsposition und Baselinevektor aufaddiert werden. Solche Basislinien können ca.
10 bis 100 km lang sein.
Besonders unterschieden werden Verfahren der Trägerphasenmessung durch den Zeitaufwand, der für eine einzelne
Positionsmessung erforderlich ist. Dieser reicht von Stunden bis in den Echtzeitbereich. Außerdem ist entscheidend,
an welcher Stelle die Positionsberechnungen durchgeführt werden. Üblicherweise werden Korrekturdaten an den
Rover geschickt. Es ist aber je nach Verfahren auch möglich, dass der Rover Rohdaten an die Referenzstation schickt,
welche ihrerseits die Position des Rovers bestimmt. Das ist zwar aufwendiger, da eine größere Datenmenge
transportiert werden muss (insbesondere bei Echtzeitanforderungen), ermöglicht aber höhere Genauigkeiten.
Realtime Kinematics
Da für die spätere Anwendung in diesem Projekt Echtzeitfähigkeit benötigt wird, sei hier besonders auf EchtzeitKinematische-Verfahren (Abk. engl. RTK) hingewiesen. Darunter sind Systeme zusammengefasst, die die Position
eines beweglichen Objekts, sofern sie ein erstes Mal initialisiert wurde, kontinuierlich und hochgenau ermitteln können.
Anwendung finden derartige Verfahren beispielsweise in der Landwirtschaft. Die Genauigkeiten, die erreicht werden,
liegen im Bereich Dezimeter und weniger.
Post-Processing
Das genaue Gegenteil einer Echtzeitanwendung stellen Post-Processing Lösungen dar. Dabei werden Rohdaten von
Empfängern und Referenzstationen zur späteren Verarbeitung aufgezeichnet, meist in Form des standardisierten
RINEX-Datenformats25. Das besondere an diesem Verfahren ist, dass hochgenaue Satellitenbahnen verwendet werden
können, welche erst nach der Messung sehr exakt vermessen und berechnet werden. Die Rohdaten werden
zusammen mit den Bahnparametern einer geeigneten Auswertesoftware zugeführt. Damit können Positionen bis auf
wenige Millimeter genau ermittelt werden.
Phasenmessungen mit Endverbraucher-Geräten
Das Hauptproblem der Trägerphasenmessung ist, dass die meisten in GPS-Mäusen oder Handgeräten verbauten
Chips nicht in der Lage sind Rohdaten mit Phasenmessungen auszugeben, geschweige denn, die Phasenlage in ihre
Berechnungen mit einzubeziehen. Einige wenige bieten diese Option jedoch und ermöglichen die Auswertung.
[Sch06] beschreibt die Verwendung von Garmin eTrex Handgeräten im Post-Processing bei erzielten Genauigkeiten
im Bereich von 4 cm. Allerdings auch bei Beobachtungszeiten von bis zu vier Stunden.
24
Zu Deutsch Basislinie
Beim Receiver Independent Exchange Format (RINEX) handelt es sich um ein empfängerunabhängiges Daten-Austauschformat für GPS-Messungen,
welches insbesondere Phasendaten speichern kann.
25
44
Kapitel 3
Eine Echtzeitlösung liefert [Tak08] mit einer, als
RTKlib bezeichneten, frei verfügbaren
Bibliothek,
welche
zahlreiche
Chips
unterschiedlicher Hersteller unterstützt, darunter
auch den U-blox Antaris AEK4-T, welcher
kurzzeitig im Rahmen dieses Projekts zur
Verfügung stand. Obwohl vorgenannte RTKlib
Echtzeitverfolgungen ermöglicht, sind jedoch
Initialisierungszeiten zwischen zwei Minuten und
Abb 3.39: U-blox Antaris AEK-4T, Quelle: www.u-blox.com
einer Stunde notwendig, um eine erste genaue
Position mit aufgelösten Phasenmehrdeutigkeiten zu erhalten. Da für diese Arbeit nur ein einzelner Empfänger des
oben genannten Typs zur Verfügung stand und mindestens zwei für eine DGPS-Lösung benötigt werden, konnten die
Ergebnisse aus [Tak08] nicht evaluiert werden. Aufgrund der Recherchen im Rahmen dieser Arbeit, wird diesem
Verfahren jedoch sehr großes Potential im Niedrigpreissektor zugerechnet. Mit [Nov10] steht ein kommerzielles
Produkt zur Verfügung, das u.a. auch mit dem AEK4-T Empfänger arbeiten kann und in der Lage ist bis zu 20
Empfänger gleichzeitig zentimetergenau zu verfolgen. Der hohe Preis der Software macht sie jedoch für Anwendungen
mit Niedrigpreisanforderung uninteressant.
Korrekturdatenübertragung
Um Korrekturdaten von der Referenzstation zum Empfänger zu übertragen, werden in der Praxis verschiedene Wege
verwendet. Es sollte hier vorweg erwähnt werden, dass der Betrieb von Referenzstationen immer weniger selbst
durchgeführt wird. Vielmehr haben sich Dienstleister etabliert, die über standardisierte Protokolle Korrekturdaten für
die verschiedensten Systeme und Verfahren anbieten. Sogenannte Referenzstationsdienste. Das Konzept solcher
Netze soll nachfolgend vorgestellt werden.
Referenzstationsnetze
Ein großer ökonomischer Fortschritt ist mit der Einrichtung von Referenznetzen entstanden, die in der Lage sind
hochgenaue Korrekturparameter an die Nutzer auszusenden. In der ursprünglichen Betriebsweise wurde bei einer
Messung aus dem Netz des Anbieters die jeweils nächste Station ausgewählt. Je nach Dichte der Stationen führte das
aufgrund schwankender Distanzen zu mehr oder weniger guten Korrekturen. In der heutigen Fassung solcher Netze
spricht man auch von Netz-RTK. Zur Erzeugung optimaler Korrekturdaten werden alle Stationen eines Betreibers
vernetzt. Ein Nutzer überträgt seine eigene „grobe‚ Position an das Referenznetz. Ein Server berechnet aus den
benachbarten Stationen durch Interpolation genau die Korrekturdaten, die eine tatsächliche Referenzstation an der
angegebenen Stelle ermitteln würde, somit erhält man eine virtuelle Referenzstation in optimalem Abstand zur
Messung. Dadurch werden über die Fläche deutlich weniger Referenzstationen benötigt. Näheres zu diesem Ansatz
erläutert [Wan08] .
Das wichtigste Netz dieser Art in Deutschland ist SAPOS. Der Satellitenpositionierungsdienst wird von den
Landesvermessungsämtern betrieben und bietet Korrekturdaten verschiedener Genauigkeitsstufen an. Sowohl für
Codephasenkorrekturen (Echtzeit-Positionierungsdienst EPS), als auch für Trägerphasen-Korrekturen (Hochpräziser
Echtzeitpositionierungsdienst HEPS) und Post-Processing-Verfahren (Geodätischer Post-Processing
Positionierungsdienst GPPS). Damit deckt der Dienst Genauigkeitsanforderungen im Meter, Submeter und
Millimeterbereich ab (vgl. [Der01] ). Im Rahmen dieser Arbeit wurde vom hessischen Landesamt für
Bodenmanagement und Geoinformation ein kostenloser Zugang zum SAPOS-EPS-Dienst für Evaluationszwecke zur
Verfügung gestellt.
45
Kapitel 3
Eine Besonderheit ist bei der Nutzung von SAPOS zu beachten: Da die mehr als 200 Referenzstationen im ETRS 89
Koordinatensystem eingemessen sind, führt die Anwendung der Korrekturparameter zu einer Positionierung in ETRS
89 Koordinaten im Gegensatz zu den sonst üblichen WGS 84 Koordinaten(vgl. [Aue04] ).
RTCM SC-104
Unter der Bezeichnung RTCM SC-104 hat die Radio Technical Commission for Maritime Services ein Protokoll
standardisiert, welches mittlerweile zum wichtigsten Übertragungsformat für GPS-Korrekturdaten avanciert ist. Zur
Übertragung sind zurzeit 63 unterschiedliche Mitteilungsformate spezifiziert, welche mit Hilfe von 30-Bit-Worten
übertragen werden. Diese reichen von Bahnkorrekturdaten über Referenzstationsparameter, Daten zu Entfernungsund Phasenkorrekturen bis hin zu GPS-Integritätsinformationen. Eine Auflistung der relevanten Datensätze findet man
in [Bag01] und [Bau97] .
Übertragung auf Kurzstrecken
Beim Betrieb eigener lokaler Referenzstationen werden die Daten meist direkt per Funk zwischen Station und Rover
übertragen. Hierzu gibt es als Ergänzung zu den Geräten entsprechende Sende-/Empfangseinheiten.
Radiofrequenzen
In der Vergangenheit wurde die Übertragung von Korrekturdaten diverser
Referenznetzbetreiber über unterschiedliche Radiofrequenzen gewährleistet. So
wurden z.B. auch die UKW- und Mittelwellensender der Rundfunkanstalten verwendet,
aber auch See- und Flugfunkfeuer. Der GPS-Empfänger muss ebenfalls mit einem
entsprechenden Empfangsgerät verbunden sein, häufig als Radio Beacon Empfänger
bezeichnet. Beim Kauf eines solchen Gerätes ist somit gleich eine Nutzungsgebühr für
das zugehörige Referenznetz enthalten. Die Gültigkeit der Korrekturdaten richtet sich
nach der jeweiligen Reichweite der Übertragungsfrequenz. Im Übrigen sind auch
einige der einfachen Handgeräte, welche über eine serielle Schnittstelle verfügen, in Abb 3.40: Trimble GeoBeaconder Lage, Korrekturdaten eines Beacon-Empfängers zu verarbeiten. Das SAPOS-Netz
Empfänger,
Quelle:
www.trimble.com
in Hessen hat zum Jahreswechsel 2008/2009 die Bereitstellung von Korrekturdaten
über UKW eingestellt [HLG09] .
GSM
Heutzutage werden DGPS-Daten am Häufigsten über GSM mit Hilfe eines Mobiltelefons an den Rover übertragen.
Hierzu wählt der GPS-Empfänger eine bestimmte Nummer und baut eine Datenfernübertragungs-Verbindung auf.
Zurück erhält er Korrekturdaten im RTCM-Format. Bei vernetzten Referenzstationen muss der Empfänger zunächst
jedoch seine Position bekannt geben, damit die Korrekturen berechnet werden können.
Ntrip
Mit zunehmender Verbreitung kostengünstiger mobiler Internetzugänge verlagert sich auch die Abfrage von DGPSDaten auf IP-basierte Techniken. Hierfür wurde Ntrip entworfen. Das „Networked Transport of RTCM via Internet
Protocol‚ dient zur Kapselung von RTCM Daten innerhalb eines HTTP-Aufrufs. Das Verfahren beruht auf drei
Bausteinen. Ein Server ist für die Erzeugung der Korrekturdaten zuständig, während der Ntrip-Caster sie verteilt. Auf
Nutzerseite dient ein Client dem Empfang der Daten und der Übermittlung an den GPS-Empfänger. Details zum
Protokoll findet man in [Len04] .
Der Zugang zum bereitgestellten SAPOS EPS ist über Mobilfunk und Ntrip möglich. Um diesen nutzen zu können, ist
es notwendig die Koordinaten der gewünschten virtuellen Referenzstation an den SAPOS-Server zu übergeben.
46
Kapitel 3
Neben SAPOS liegen auch noch für einige weitere Referenzstationsnetze des Bundesamtes für Kartographie und
Geodäsie Ntrip-Zugangsdaten vor.
SBAS
Die unter dem Titel „Satallite Based Augmentation System‚ zusammengefassten Verfahren werden im eigentlichen
Sinne nicht zu den Differentiell GPS-Verfahren gezählt. Das Grundprinzip ist jedoch das gleiche, daher spielt die
genaue Trennung der Begriffe im Rahmen dieser Arbeit keine weitere Rolle. Die Grundaufgabe ist auch bei SBAS die
Verteilung von Korrekturparametern an GPS-Empfänger. Der entscheidende Unterschied ist jedoch der
Verteilungsweg. Anstelle von Bodengestützten Telekommunikationswegen werden die Daten direkt von einem
Satelliten zu den Empfängern übertragen. Das ist möglich, weil die gleichen Frequenzen und Modulationen zum
Einsatz kommen, wie bei den eigentlichen GPS-Satelliten. Theoretisch wäre es sogar denkbar, die Satelliten in die
Positionsbestimmung mit einzubeziehen.
Drei Nennenswerte Systeme kommen derzeit zum Einsatz: das WAAS (Wide Area Augmentation System) in den USA,
das MSAS (Multi-functional Satellite Augmentation System) in Asien und EGNOS (European Geostationary Navigation
Overlay Service) in Europa. Die Nachfolgenden Informationen beziehen sich auf das in Europa verwendete System,
gelten aber so oder ähnlich auch für die anderen Vertreter.
Der große Vorteil dieser Systeme ist, dass quasi alle aktuell am Markt befindlichen Empfänger die satellitengestützten
Korrekturparameter verarbeiten können und keine weitere Infrastruktur benötigt wird. Das Problem ist jedoch, dass der
Empfang nur relativ selten gewährleistet ist. Der Grund ist in der Tatsache zu suchen, dass es sich bei den
Flugbahnen der Satelliten um geostationäre Bahnen handelt. D.h. die Satelliten stehen in unseren Breiten immer sehr
flach am südlichen Horizont, so dass schon kleinste Erhebungen den Empfang erheblich stören. Für die Luftfahrt, für
die die Methode ursprünglich entwickelt wurde stellt das jedoch kein größeres Problem dar. Das europäische EGNOS
ging im September 2009 in den Regelbetrieb und liefert seither DGPS Daten über drei verschiedene geostationäre
Satelliten aus [RPO09] . Die Satelliten gelten als Vorstufe des Galileo-Systems.
Neben Informationen über die aktuelle Integrität der GPS-Satelliten bestimmt eine größere Anzahl von Bodenstationen,
die Ranging and Integrity Monitoring Stations (RIMS) [Man04] , ein Ionosphären- und Troposphären-Korrekturgitter,
welches über die Satelliten zu den Empfängern übermittelt wird. Darin liegt ein weiterer wichtiger Unterschied zum
„normalen‚ Differential GPS, bei dem feste Korrekturparameter ermittelt werden. Ein Empfänger bestimmt anhand des
empfangenen Korrekturgitters die für ihn geltenden Korrekturparameter. Übertragen werden außerdem genauere
Informationen zur Bahnkorrektur und Daten zur Korrektur des Satellitenuhrenfehlers. Eine detaillierte Untersuchung des
EGNOS Systems wurde in [Mül04] durchgeführt.
Bei der Verwendung von SBAS Systemen ist außerdem zu beachten, dass die Empfänger korrekt eingestellt sind. Es
könnte theoretisch passieren, dass ein Empfänger in Europa das Korrekturgitter für die USA erhält und damit falsche
Korrekturparameter verwendet (vgl. [Köh08d] ).
Mit dem zuvor beschriebenen Ntrip steht mittlerweile eine Möglichkeit zur Verfügung, die EGNOS-Daten nicht über die
Satelliten, sondern über das Internet zu Empfangen. Das Bundesamt für Kartographie und Geodäsie (BKG) betreibt
unter der Bezeichnung EGNOS-IP einen Server, der die EGNOS-Daten empfängt, in RTCM-Daten konvertiert und über
Ntrip bereitstellt.
47
Kapitel 3
Assisted GPS
Die auch als AGPS bezeichneten proprietären Verfahren sind mit den Differential GPS Varianten dahingehend
verwandt, als dass sie zusätzliche Informationen liefern um die Positionsbestimmung zu verbessern. Es geht jedoch
meist nur darum, die Zeit bis zur ersten fixen Position zu verkürzen, wenn z.B. die Almanach-Daten des Empfängers
veraltet sind. Hierzu bedienen sich AGPS-fähige Empfänger zunächst einer groben Ortung über Mobilfunkzellen.
Anhand dieser Position laden sie die aktuell notwendigen Almanach-Daten über GSM aus dem Internet. Dies wird
wiederum vom eigentlichen Empfänger benutzt um schneller die empfangbaren Satelliten zu bestimmen. Außerdem
bieten verschiedene AGPS-Dienste genauere Satellitenbahnen an, als die originalen Bahndaten (vgl. [Zog09a] ). Bei
dem Hersteller U-blox wird dieses Verfahren z.B. als Almanach Plus bezeichnet.
3.7.2 Logische Ebene
Neben den bisher vorgestellen differentiellen Verfahren sollen in diesem Abschnitt Methoden zur Verbesserung
dargestellt werden, die erst nach der eigentlichen Positionsbestimmung ansetzen. Der besondere Vorteil an einem
solchen Verfahren ist, dass es mit allen GPS-Empfängern funktioniert. Die ersten beiden Ansätze stellen rein autonome
Verfahren dar, wohingegen der letzte eine Infrastruktur voraussetzt.
Mittelwertbildung
Die bisherigen Erfahrungen mit GPS haben gezeigt, dass gerade die günstigen Empfänger eine sehr starke Streuung
bei statischen Messungen aufweisen. Es kommt zu großen Punktwolken um einen definierten Mittelwert. Die
interessante Fragestellung an dieser Eigenschaft ist, in wie weit die Verwendung von mehreren parallelen Empfängern
dazu verwendet werden kann, diese großen Punktwolkeneffekte zu verringern und die Messung zu glätten. Um auf
das Kapitel 3.6.3 zu verweisen: der erhoffte Effekt ist die Erhöhung der Präzision einer Messung.
Damit ist die Mittelwertbildung ein Verfahren, dass sich nicht um die Kompensation systembedingter Fehler kümmert,
sondern um die Verringerung lokaler Störungseinflüsse, wie Mehrwegeempfang oder Empfängerrauschen. Daraus
folgt jedoch, dass man für eine Verbesserung des absoluten Fehlers, hervorgerufen durch die systembedingten
Einflüsse, noch andere Methoden anwenden muss.
Es ist zu zeigen, dass der mittlere Punktfehler durch eine solche Korrektur reduziert werden kann. Auch ist der
empirische Nachweis zu führen, wie viele Empfänger für eine Verbesserung benötigt werden. In wie weit das Verfahren
einen tatsächlichen Gewinn bringt wird in Kapitel 3.9.1 untersucht. Zu berücksichtigen ist außerdem, dass eine
gegenseitige Störung der Empfänger ausgeschlossen werden kann (siehe Kapitel 3.6.2). Dazu müssen die Empfänger
mit einem gewissen Abstand zueinander positioniert werden. Für die Mittelwertberechnung ist dies wieder
herauszurechnen.
Street Matching
Hierbei handelt es sich um einen Ansatz, der vornehmlich in Fahrzeugnavigationssystemen eingesetzt wird. Beim
Street Matching oder auch Map Matching geht man von der einfachen Annahme aus, dass GPS-Empfänger, z.B.
eingebaut in einem Navigationssystem, sich auf einer Straße befinden müssen, da sie in einem Auto oder LKW
betrieben werden. Ist eine Position vom Empfänger bestimmt, wird geprüft, ob diese auf einer Straße liegt. Ist dies
nicht der Fall, wird die Position innerhalb definierter Schwellwerte und nach geeigneten Berechnungen optimal auf eine
der nahegelegenen Straßen versetzt. Es handelt sich demnach primär um ein Verfahren für eine dynamische
Positionsverbesserung, also für einen Empfänger in Bewegung. Es kommen unterschiedliche Ansätze zur Anwendung.
Zwei sollen nachfolgend beschrieben werden:
48
Kapitel 3
Der einfachste Ansatz ist die Position an die nächstmögliche Stelle zu verschieben, die auf einer Straße liegt. Bei
einem weitläufigen Netz von Fahrwegen ist dies ein guter Ansatz. Befindet man sich jedoch in dicht besiedeltem
Gebiet oder auf Straßen, die z.B. parallel zu einer Autobahn verlaufen, könnte durch starke Schwankungen der GPSPosition ein häufiges hin- und herspringen die Folge sein.
Daher wählt man oft komplexere Algorithmen bei der Wahl einer Zielposition. Vor allem geht es darum, die bisherige
Fahrstrecke zu berücksichtigen, nicht nur die aktuelle Position. Es wird versucht einen ermittelten globalen Fehler zu
minimieren und die zurückgelegte Strecke optimal ins Straßennetz einzupassen. Beispiele solcher Verfahren sind u.a.
in [Bra05] und [Och02] beschrieben.
Probleme hinsichtlich dieses Verfahrens liegen vor allem bei unvollständigen Karten vor, wenn z.B. die Straße, auf der
man sich gerade befindet, noch nicht in den Kartendaten des Navigationssystems eingetragen ist, wird die Position
evtl. auf eine falsche Straße in nächster Nähe versetzt. Weiterhin muss man bedenken, dass die Genauigkeit des
Ergebnisses direkt von der Genauigkeit der Karte abhängt. Es kann außerdem nur richtungsabhängig ein
Positionsfehler korrigiert werde. Das bedeutet, ein Fehler quer zur Fahrbahn lässt sich gut korrigieren. Ein Fehler
entlang der Fahrtrichtung lässt sich erst nach dem nächsten Richtungswechsel ausgleichen.
Differenzposition
Zum Abschluss der Untersuchungen zu den Verbesserungen bei GPS soll ein Verfahren vorgestellt werden, das es
zum Ziel hat, den systembedingten Fehler einer Positionsabweichung auf logischer Ebene zu kompensieren (Abb
3.41). Die Idee dahinter ist, die Abweichung der Position einer angenommenen Referenzstation als Korrekturvektor zu
verwenden. Man beachte den Unterschied zu codephasenbasiertem DGPS, bei dem die Pseudostrecken korrigiert
wurden, nicht die Position.
Abb 3.41: Funktionsprinzip der Differenzposition
Ein großer Vorteil an diesem zunächst einfach klingenden Ansatz ist, dass jeder GPS-Empfänger ohne großen
Aufwand zu einer Referenzstation umfunktioniert werden kann. Wenn man davon ausgeht, dass durch genügend lange
Mittelung an einem festen Standort die tatsächlichen Koordinaten nahe genug angenähert werden, würde auch eine
hohe absolute Genauigkeit resultieren. Neben gemittelten Positionen könnten andere Bestimmungsverfahren
verwendet werden: Die Korrektur der Position durch Street Matching könnte u.U. als ausreichend betrachtet werden,
oder fest eingerichtete Stationen an vorgegebenen Punkten z.B. einer Ampel. Für einen auf Street Matching
basierenden Ansatz ist die Genauigkeit der Karte und der verwendete Matchingalgorithmus von größter Bedeutung.
[Lab02] hat hierzu verschiedene Untersuchungen angestellt und ist zu überraschend guten Ergebnissen gekommen.
Zahlreiche Einschränkungen müssen jedoch Beachtung finden, die die Anwendung eines solchen Ansatzes stark
einschränken.
49
Kapitel 3
Die Art der Streuung bzw. Abweichung der Messung hängt, wie bereits mehrfach beschrieben, von lokalen und
systembedingten Faktoren ab. Die letzteren resultieren aus Fehlern in der Pseudostreckenbestimmung. Sie sind in
Summe nur gleich, wenn die gleichen Satelliten betrachtet werden, ebenso ist der durch Mehrwegeempfang
ausgelöste lokale Fehler satellitenabhängig. [Zog09a] schreibt: „Eine Korrektur, die auf der Differenzposition anstelle
von Pseudorange-Differenzen beruht, ist unzuverlässig, da die Verwendung unterschiedlicher Satelliten in der
Positionsberechnung zu falschen Resultaten führen‚. „Deshalb muss die Wahl der Satelliten vom Nutzer und von der
Referenzstation koordiniert werden‚ [Man04] , um tatsächlich Erfolg mit dieser Methode zu haben.
Dies führt aber zu weiteren Problemen: Es werden unter Umständen
Satelliten ausgewählt, die nur auf einer der beiden Seiten gut zu
empfangen sind, oder deren geometrische Konstellation einen
schlechten Dilution of Precision Wert ergeben. Für eine Anwendung in
einem dynamischen Szenario mit ständigem Wechsel der
Empfangsbedingungen kann dieses Verfahren nahezu ausgeschlossen
werden. Die Basisstation könnte als Alternative auch für alle
Kombinationen aus jeweils vier Satelliten Korrekturen bereitstellen. Dies
ist aber mit hohem technischem Aufwand verbunden. Außerdem wird
eine Einschränkung auf bestimmte Satelliten von den meisten normalen
Empfängern nicht unterstützt. Mit einem Trick ist es jedoch dennoch
möglich. Zum einen über den als Elevationmask bezeichneten
Abb 3.42: Satellitenauswahl durch
Schwellwert, der den minimalen Erhebungswinkel eines Satelliten über
Einschränkung des minimalen
dem Horizont bestimmt (Abb 3.42) und zum anderen über
Erhebungswinkels auf 35°
Integritätsmeldungen, welche über das RTCM-Protokoll in den Empfänger
eingespielt werden. Im ersten Fall führt dies oft zu einer schlechten Satellitengeometrie und letzteres ist nur mit großem
Aufwand zu betreiben und unter Beachtung, dass nur zwei der im Projekt verwendeten Empfänger überhaupt über
eine RTCM-Einspeisemöglichkeit verfügen. Zusätzlich müssen die Empfänger so eingestellt sein, dass sie keine
Egnoskorrekturen vornehmen.
3.8
NMEA Standard
Unter dem NMEA-Standard, genauer gesagt dem NMEA 0813 Standard, versteht man ein Datenaustauschprotokoll,
das die National Marine Electronics Association speziell für Geräte im marinen Einsatz entwickelt und erstmals 1983
veröffentlicht hat. Da praktisch jeder GPS-Empfänger in der Lage ist, dieses Protokoll auszugeben, ist es für Aufgaben
in diesem Bereich sehr wichtig. Es basiert auf den Zeichen des ASCII-Datensatzes und ist zeilenorientiert. Einzelne
Zeilen werden als NMEA-Sätze bezeichnet und dürfen maximal 80 Zeichen haben. Ausgegeben werden die Zeilen
über eine serielle Schnittstelle. Auch ohne Protokollparser ermöglicht der einfache Aufbau der Sätze eine
Interpretation.
3.8.1 Aufbau
Jeder Satz beginnt mit einem Dollarzeichen und endet mit einem Stern gefolgt von einer Prüfsumme. Nach dem
Dollarzeichen folgt ein zweistelliger Code, der die Geräteart identifiziert. Von der NMEA sind verschiedene Gerätearten
vorgegeben. Nachfolgende Tabelle zeigt eine Auswahl.
50
Kapitel 3
Code
AP
CV
EC
EP
GP
Geräteart
Autopilot
VHF Funk
Elektronische Seekarte
Notsignal Sender
GPS
Code
GL
HC
RA
SD
WI
Geräteart
GLONASS
Kompass-Steuerkurs
Radar
Akustischer Tiefenmesser
Wetterstation
Tabelle 3.6: NMEA Gerätearten, Quelle: [NME02]
Die Geräteart P kann für proprietäre Ausgaben verwendet werden. Danach folgt ein weiterer Code, der in Form von
drei Zeichen die Art der Nachricht spezifiziert. Danach folgen die einzelnen Werte jeweils durch Kommas getrennt. Ein
Beispielsatz sieht dann in etwa so aus:
$GPRMC,124517.000,A,4953.4392,N,00839.9146,E,0.00,0.00,130310,0.0,W,A*1C
Die Prüfsumme wird ermittelt durch XOR-Verknüpfung der 8-Bit ASCII-Werte der einzelnen Zeichen zwischen dem
Dollarzeichen und dem Stern. Die Ausgabe wird in hexadezimaler Darstellung an den Satz angehängt.
3.8.2 GPS-Sätze
Bei dem oben beispielhaft angegebenen NMEA-Satz handelt es sich um den für GPS-Empfänger wichtigsten
Datensatz. Jedes GPS-Gerät sollte ihn ausgeben können. Er wird als Recommended Minimum Sentence C bezeichnet
– als empfohlener minimal Datensatz C. Neben diesem sind für GPS noch zahlreiche weitere Arten solcher Sätze
definiert. Bevor der GPRMC näher beleuchtet wird zunächst einen Abriss der definierten Typen.
Code
GPRMC
GPDTM
GPGGA
GPALM
GPGSA
GPGSV
GPGLL
GPVTG
GPZDA
Datensatzart
Empfohlener minimal Datensatz
Geodätisches Datum
Positionsdaten und Genauigkeitsinformationen
Almanach-Daten
Liste der verwendeten Satelliten und DOP-Werte
Informationen über empfangene Satelliten
Positionsdaten mit Länge und Breite
Geschwindigkeit und Kurs über Grund
Zeit- und Datumsinformationen
Tabelle 3.7: Für GPS definierte NMEA-Datensätze, Quelle: [NME02]
GPRMC
Um den Aufbau noch einmal zu verdeutlichen sei an dieser Stelle der sogenannte Recommended Minimum Sentence
C, wie er bereits oben aufgeführt ist, näher untersucht.
$GPRMC,124517.000,A,4953.4392,N,00839.9146,E,18.00,172.00,130310,0.0,W,A*1C
51
Kapitel 3
Wert
124517.000
A
Beschreibung
Uhrzeit der Übertragung
Gültigkeit des Datensatzes
4953.4392,N
00839.9146,E
18.00
172.00
130310
11.0, W
A
Breitengrad
Längengrad
Geschwindigkeit
Steuerkurs in Grad, Azimut
Datum
Magnetische Missweisung
Bestimmungsart
12:45:17.000
A=Gültig
V=Ungültig
49° 53.4392’ Nord
8° 39.9146’ Ost
18.00 Knoten/Stunde
172.00°
13. März 2010
11° Richtung West
A=Autonom
D=Differentiell
E=Geschätzt
N=Ungültig
S=Simulator
Tabelle 3.8: Auswertung eines GPRMC-Datensatzes in der Reihenfolge der Datenfelder
3.9
Praktische Untersuchungen
Als garantierte Genauigkeit für den Standardortungsdienst von GPS nennt [Man04] einen doppelten mittleren
Punktfehler von 30m bei guten Bedingungen und zitiert damit eine Unterabteilung des amerikanischen
Verteidigungsministeriums zu den Spezifikationen des Systems von 1984. In der Realität und dank diverser
Verbesserung werden unter normalen Voraussetzungen jedoch deutlich bessere Werte erreicht, die zwischen 7,5 und
10 Metern liegen dürften. In diesem Abschnitt soll der Istzustand einfacher GPS-Messungen näher untersucht werden.
Hierzu wurden mehrere Testreihen mit GPS-Mäusen und Handgeräten erstellt. Auf eine Untersuchung der
Höhengenauigkeit wird im Rahmen dieser Arbeit verzichtet. Aus den praktischen Erfahrungen mit GPS kann jedoch
davon ausgegangen werden, dass die Höhe mit einer etwa zwei- bis dreimal schlechteren Genauigkeit angegeben
werden kann, als die Position. Weiterhin sollen die in Kapitel 3.7 vorgestellten Verfahren soweit möglich auf Ihre
Wirksamkeit hin untersucht werden.
Vorweg einige Grundbedingungen die bei den Experimenten berücksichtigt wurden: Wie bereits erwähnt stellen
Mehrwegeempfang und Abschattungen sehr große Probleme für eine genaue GPS-Messung dar. Daher sollte darauf
geachtet werden, dass der Empfänger möglichst freie Sicht zum Himmel und in alle vier Richtungen hat. Bei
Messungen, die parallel mit mehreren Empfängern durchgeführt werden, sind möglichst die gleiche Firmware und die
gleichen Einstellungen zu verwenden. Da für den späteren Prototypen Positionsinformationen in Echtzeit verfügbar
sein sollten, wurden die Empfänger so eingestellt, dass pro Sekunde eine Messung erfolgt. Verschiedene Chipsätze
sind dank einer hohen Zahl paralleler Empfangskanäle in der Lage, die Ausgabegeschwindigkeit sogar noch zu
erhöhen und z.B. pro Sekunde bis zu vier Messwerte zu senden. Außerdem ist der Empfang von Korrekturdaten, wie in
3.7.1 beschrieben, zunächst zu deaktivieren, um die Messungen vergleichbar zu machen. Die Übertragung der GPSDaten an den Rechner wird in Form des NMEA-Protokolls über RS232- bzw. USB-Schnittstellen gewährleistet. Um eine
genaue Beurteilung der Messwerte zu ermöglichen, wurden sie (soweit vorhanden) gegen genau vermessene
52
Kapitel 3
Lagefestpunkte (Kapitel 2.5) durchgeführt. Die Versuche wurden mit GPS-Mäusen des Typs Navilock 402u und
Conrad CR4, sowie zwei Garmin eTrex Handgeräten durchgeführt. Da bei diesen Geräten weit verbreitete GPS-Chips
in der jeweils aktuellen Generation zum Einsatz kommen, dürften die Erfahrungen auf die meisten aktuellen
Endverbraucher-Geräte mit geringen Schwankungen übertragbar sein.
3.9.1 Statische Untersuchungen
Zunächst folgen einige Untersuchungen zur statischen Positionsmessung. Die Aufgabenstellung ist hierbei die
Bestimmung eines unbewegten Punktes. Darauf aufbauend werden mehrere parallele Empfänger untersucht, sowie
die Verwendung von Korrekturdaten bewertet.
Untersuchung einzelner Empfänger
Jeder Empfänger wird zunächst nur für sich alleine betrachtet. Üblicherweise zeigen einfache GPS-Geräte, wie sie hier
verwendet werden, bei statischen Messungen einen Positionsdrift. D.h. die gelieferte Koordinate ist ständig in
Bewegung und es entsteht nach einer gewissen Zeit eine Punktwolke um einen Mittelwert. Dieses Drift-Verhalten
unterscheidet sich sehr stark zwischen den verschiedenen Typen. Generell kann durch die Art und Ausprägung der
Koordinatenspur der relative Unsicherheitsfaktor abgeschätzt werden, den eine solche Messung enthält. Auch soll
zunächst eine der Grundannahmen der Genauigkeitsmessungen beurteilt werden: Für die Fehlerabschätzung wird in
Anlehnung an Kapitel 3.6.3 von einer Gleichverteilung der Messwerte ausgegangen. Dies soll im Rahmen der
Experimente evaluiert werden.
Es werden jeweils Aufzeichnungen von etwa 45 Minuten erfasst. Die Grafiken zur Darstellung der Punktwolken sind der
besseren Vergleichbarkeit halber alle im gleichen Maßstab. Eingezeichnet sind jeweils auch der Mittelwert, die
Standardabweichung sowie Minima und Maxima der Komponenten. Der äußere Kreis der Grafiken markiert einen 7Meter-Radius. Der gelbe Kreis stellt den mittleren Punktfehler da.
Garmin eTrex Vista HCx
Das Handgerät zeigte bei der Messung einen kontinuierlichen Drift von etwa 5 cm/s. Es sei an dieser Stelle erwähnt,
dass die Bedingungen der Messung, ebenso wie bei der Untersuchung des Modells eTrex H nicht hundertprozentig
ideal waren, weil eine leichte Abschattung nach Süden vorlag. Da im Laufe der Messung die vorhandenen Satelliten
jedoch gut empfangbar waren, lässt der Verlauf der Spur auf das Vorhandensein von Mehrwegeeffekten schließen.
Abb 3.43: Messverlauf eTrex Vista HCx
Abb 3.44: eTrex Vista HCx Histogramm der
Längen- (oben) und Breitengrade (unten)
53
Kapitel 3
Die Messung ergab einen mittleren Punktfehler von 4,38 Meter. Die Messwerte sind in der Tabelle am Ende dieses
Abschnitts mit Hilfe der definierten Genauigkeitsgrößen zusammengefasst. An den Histogrammen erkennt man, dass
die statistische Grundannahme der Gleichverteilung nur in geringem Maße erfüllt ist – dies ist bei der Beurteilung der
Werte zu berücksichtigen. Da zum Zeitpunkt der Messungen kein Lagefestpunkt zur Verfügung stand, kann in diesem
Fall keine Angabe über den absoluten Fehler gemacht werden.
Garmin eTrex H
Das zweite Gerät aus der eTrex Reihe liefert trotz ähnlicher Bauart, gleichen Bedingungen und Einstellungen einen
gänzlich anderen Verlauf. Es weist einen deutlich langsameren Drift auf und erweckt so den Eindruck einer stabileren
(und genaueren) Position. Zu bemerken ist, dass die Positionsdaten über das NMEA-Protokoll von diesem Gerät nur
alle zwei Sekunden geliefert werden, nicht wie bei den anderen Geräten üblich jede Sekunde.
Abb 3.45: Messverlauf eTrex Vista HCx
Abb 3.46: eTrexH Histogramm der Längen(oben) und Breitengrade (unten)
Auch hier kann keine Gleichverteilung der Längen- und Breitengrade festgestellt werden. Zum besseren Vergleich
sind bei beiden eTrex-Messungen die verwendeten Ursprungskoordinaten in der Grafik gleich. Die resultierenden
Werte des eTrex H liegen zum Großteil nur im dritten Quadranten, im Gegensatz zu denen des Vista HCx. Daher ist bei
diesem Gerät der mittlere Punktfehler auch deutlich geringer.
Navilock 402u und Conrad CR4
Mit den Modellen 402u von Navilock und CR4 von Conrad werden in diesem Abschnitt die verwendeten GPS-Mäuse
untersucht. Auch hier zeigen die Messungen einen völlig anderen Verlauf als bei den beiden vorherigen Kandidaten.
Da sich die Ergebnisse der beiden Empfänger weitestgehend gleichen, sollen sie hier gemeinsam betrachtet werden.
Außerdem arbeiten im Inneren der beiden Mäuse verwandte GPS-Chips. In der CR4 ein U-Blox Antaris 4 und im
Fabrikat von Navilock der etwas modernere U-Blox 5. Bis auf eine etwas größere Streuungsbreite konnte kein
signifikanter Unterschied festgestellt werden. Bei diesen Messungen wurde ein Lagefestpunkt im Bürgerpark in
Darmstadt zu Hilfe genommen, daher können Aussagen über den absoluten Fehler gemacht werden. Der
Lagefestpunkt befindet sich jeweils im Ursprung des Koordinatenkreuzes.
54
Kapitel 3
Abb 3.47: Messverlauf Navilock 402u
Abb 3.48: Navilock 402u Histogramm der Längen(oben)
und Breitengrade (unten)
Abb 3.49: Messverlauf Conrad CR4
Abb 3.50: Conrad CR4 Histogramm der Längen(oben)
und Breitengrade (unten)
An den Histogrammen kann man erstmals eine näherungsweise Gleichverteilung erkennen, daher haben die
statistischen Größen ihre volle Aussagekraft. Die eingezeichneten Mittelwerte liegen in etwa 40-50 cm vom
Lagefestpunkt entfernt. Der Drift-Verlauf der beiden Messungen deckt die Umgebung innerhalb des einfachen
mittleren Punktfehlers von etwa 2m relativ homogen ab.
𝝈𝑩𝒓𝒆𝒊𝒕𝒆 𝝈𝑳ä𝒏𝒈𝒆
Garmin eTrex Vista HCx 3,82m
2,14m
Garmin eTrex H
1,55m
1,62m
Navilock 402u
1,44m
0,82m
Conrad CR4
1,76m
1,27m
𝒅𝒓𝒎𝒔
4,38m
2,24m
1,66m
2,17m
Tabelle 3.9: Zusammenfassung der Einzelmessungen
55
Kapitel 3
Zusammenfassend lässt sich feststellen, dass aufgrund der ersten Ergebnisse nur die GPS-Mäuse eine Position
liefern, die statistisch verwendbar ist. Insbesondere die Navilock Maus erreicht unter guten Bedingungen und ohne
weiteres Zutun sehr gute Ergebnisse. Die Auswertung der Handgeräte legt die Vermutung nahe, dass interne Filter die
ausgegebenen und angezeigten Positionen glätten und somit verfälschen.
Untersuchungen mit mehreren Empfängern
Wie in Kapitel 3.7.2 vorgeschlagen, soll an dieser Stelle untersucht werden, in wie weit die Verwendung mehrerer
Empfänge für eine genauere Position von Nutzen sein kann. Es ist hier zu zeigen, in wie weit solche Messungen
ergodische Charakteristiken aufweisen, also in wie weit ein Zeitmittelwert durch einen Scharmittelwert ersetzt werden
kann. So führen Langzeitmessungen mit GPS meist zu einem relativ stabilen Mittelwert. Können systembedingte Fehler
von GPS kompensiert werden, sind so auch handelsübliche Empfänger in der Lage genaue Positionen im
Einmeterbereich zu liefern.
Für die folgende Messung wurden insgesamt fünf Empfänger parallel
betrieben und ausgewertet. Abb 3.51 zeigt die Befestigung der
Empfänger auf einem Fotostativ mit Quertraverse. Die GPS-Mäuse
wurden im Abstand von ca. 25cm betrieben und exakt von Ost nach
West orientiert. Damit können die unterschiedlichen Positionen der
Empfänger heraus gerechnet werden und die Wiederholbarkeit des
Aufbaus ist gewährleistet. Es ist jedoch zu erwarten, dass die
erreichbare Genauigkeit außerhalb dieser Parameter liegt. Die
nebenstehende Abbildung zeigt Versuchsaufbau positioniert auf einem
trigonometrischen Punkt. Die Ergebnisse der Untersuchungen ergeben
zunächst fünf einzelne Messreihen, welche vereinfacht in den
nachfolgenden Abbildungen dargestellt sind. Das weiße Kreuz in der
Mitte markiert den Lagefestpunkt. Die Darstellung ist bereits um die auf
dem Stativ verschobene Position korrigiert.
Abb 3.51: Fotostativ mit Quertraverse
und montierten Empfängern
Abb 3.52: Einzelgrafiken der Parallelmessung mit fünf Empfängern
𝝈𝑩𝒓𝒆𝒊𝒕𝒆 𝝈𝑳ä𝒏𝒈𝒆 𝒅𝒓𝒎𝒔
𝒅𝒕𝒑−𝒎𝒘
Empfänger 1 1,44m
0,82m 1,66m
0,53
Empfänger 2 1,65m
0,82m 1,84m
0,48
Empfänger 3 1,36m
1,02m 1,70m
0,57
Empfänger 4 1,76m
1,27m 2,17m
0,60
Empfänger 5 1,66m
1,11m 2,00m
0,62
𝒅𝒕𝒑−𝒎𝒘 gibt den Abstand zwischen Mittelwert und Lagefestpunkt an
Tabelle 3.10: Einzelergebnisse der Parallelmessung mit fünf Empfängern
56
Kapitel 3
Wie an der Tabelle zu erkennen ist, orientieren sich die Ergebnisse an den vorherigen Zahlen der Einzelmessungen.
Die interessante Fragestellung ist nun, was passiert, wenn man die fünf einzelnen Messwerte pro Sekunde um die
Verschiebung korrigiert und zusammenmittelt? Abb 3.53 und Abb 3.54 stellen die Resultate grafisch dar. Zunächst mit
der Mittelung alleinstehend und anschließend durch Überlagerung mit den fünf Einzelmessungen in gleichem
Maßstab. Der innere Kreis markiert einen fünf Meter, der äußere einen zehn Meter Radius. Man erkennt deutlich, dass
die eingenommene Fläche geringer ist, als bei den ursprünglichen Ergebnissen. Dies äußert sich auch bei den
statistischen Messgrößen in Tabelle 3.11.
Abb 3.53: Ergebnis der Mittelung
Abb 3.54: Mittelung überlagert mit den Messwerten
der einzelnen Empfänger
𝝈𝑩𝒓𝒆𝒊𝒕𝒆 𝝈𝑳ä𝒏𝒈𝒆 𝒅𝒓𝒎𝒔
Messwerte aller Empfänger 1,61m
1,16m 1,98m
Mittelung
0,77m
0,45m 0,89m
0,35m
Tabelle 3.11: Auswertung der Mittelung gegenüber allen Einzelmesswerten
drms
Am mittleren Punktfehler zeigt sich, dass der Gewinn bei fünf Empfängern in etwa eine Verbesserung um den Faktor
zwei beträgt. Verschiedene weitere Messungen haben gezeigt, dass die Ergebnisse reproduzierbar sind. Empirisch
konnte ermittelt werden, dass eine Verbesserung um den Faktor zwei eine Grenze darstellt, die mit diesem Verfahren,
selbst mit noch mehr Empfängern, kaum mehr unterboten werden kann. In Abb 3.55 ist der erreichte mittlere
Punktfehler der Anzahl der verwendeten Empfänger gegenübergestellt.
2,5
2
1,5
1
1
2 3 4 5 6
Empfänger Anzahl
Abb 3.55: Mittlerer Punktfehler bei unterschiedlichen Empfängeranzahlen
57
Kapitel 3
Um auf den Begriff „ergodisch‚ zurück zu kommen, kann man empirisch feststellen, dass in diesem Fall tatsächlich
eine Form der Ergodizität im Sinne von [Fri07] vorliegt, da eine lange Beobachtungsphase mit einem einzelnen GPSGerät durch den Einsatz mehrerer Empfänger verkürzt werden kann. Der Mittelwert nährt sich bereits nach deutlich
kürzerer Zeit der tatsächlichen Position an.
Verwendung der Differenzposition
Im Rahmen des vorherigen Kapitels wurde bereits diskutiert, ob auf Basis von Differenzpositionen der systembedingte
Fehler von GPS beseitigt werden kann. Bei den Versuchen mit parallelen Empfängern konnte jedoch keine
systematische Abhängigkeit in den Messungen erkannt werden. Dies lag jedoch auch daran, dass die Messungen
bereits sehr nahe am Lagefestpunkt lagen und die verbleibenden Resteinflüsse somit weitgehend lokaler Natur waren.
In weiteren Experimenten wurde mit Hilfe der Elevationmask der Erhebungswinkel soweit eingegrenzt, dass nur noch
vier Satelliten verfügbar waren. Die Empfänger zeigten mehrmals über einen Zeitraum von wenigen Minuten
tatsächlich charakteristisch ähnliche Messkurven drifteten dann aber auch wieder im Bereich mehrerer Meter stark ab.
Die Messungen führten zu dem Schluss, dass eine stabile Lösung auf diesem Wege für dynamische Szenarien nicht
realistisch ist. Daher wird verstärkt auf das Konzept der Pseudostreckenkorrektur gesetzt.
Verwendung von Korrekturdaten
Zunächst folgt ein Überblick, welche Empfänger mit welcher Art von Korrekturdaten umgehen können. Es werden zwei
verschiedene Möglichkeiten betrachtet. Da wäre zum einen der Empfang von Korrekturen über Satellit zu nennen. Im
unseren Fall über EGNOS. Dies ist theoretisch mit allen Empfängern möglich. Sowohl die Handgeräte als auch die
GPS-Mäuse können SBAS-Signale verarbeiten. Problem ist der bereits erwähnte schlechte Empfang der
geostationären Satelliten. In der Praxis konnten nur die Garmin Geräte mit sehr unterschiedlichem Erfolg tatsächlich
eine DGPS-Korrektur auf diese Art durchführen. Während beide Empfänger ihre Unsicherheitsbreiten etwas verkleinern
konnten, wurde nur der eTrex H Empfänger so korrigiert, dass der Mittelwert sich dem Lagefestpunkt annähert. Das
Vista-Gerät lag in etwa zwei Meter daneben.
𝝈𝑩𝒓𝒆𝒊𝒕𝒆
1,45m
1,02m
Garmin eTrex H
Garmin eTrex Vista HCx
Abb 3.56: Untersuchung des
EGNOS Empfangs,
Garmin eTrex H
𝝈𝑳ä𝒏𝒈𝒆
0,91m
0,71m
𝒅𝒓𝒎𝒔
1,71
1,24m
<10cm
2,30m
Tabelle 3.12: Ergebnisse der Messungen mit EGNOS-Empfang
Die zweite im Rahmen der Arbeit relevante Einspeisemöglichkeit für differentielle Korrekturen ist die Verwendung des
RTCM-Protokolls über die serielle Schnittstelle. Dies wird nur von zwei Empfängertypen unterstützt: dem eTrex H
Handgerät und der CR4-Maus von Conrad. Allerdings konnte nur Letztere dazu bewegt werden, die Korrekturdaten in
der Praxis auch zu verwenden.
58
Kapitel 3
Bezogen wurden die Korrekturdaten mit dem Ntrip-Client, der vom BKG
kostenlos zur Verfügung gestellt wird. Zwei Datenströme kamen zur
Anwendung. Zum einen die Korrekturdaten des SAPOS EPS Dienstes und
zum anderen die aktuell verfügbaren EGNOS-Korrekturen. Damit gleichzeitig
Korrekturdaten eingespeist und NMEA Daten ausgewertet werden konnten,
musste zur Schnittstellenabstraktion das Programm GPS-Gate eingesetzt
werden. Es dient dazu, die physischen seriellen Schnittstellen durch virtuelle
zu ersetzen. So ist es z.B. möglich per TCP/IP auf ein GPS-Gerät
zuzugreifen, oder sich einen Empfänger mit mehreren Anwendungen zu
teilen. Um Korrekturdaten zu erhalten, sind für EGNOS und EPS jeweils
andere Vorgehensweisen nötig. Beim EPS müssen zunächst die eigenen Abb 3.57: Netz der verfügbaren EGNOS
Koordinaten zum SAPOS Server geschickt werden, damit werden die Bezugspunkte in Europa, Quelle: [Bun10]
individuellen Korrekturparameter für eine virtuelle Referenzstation berechnet. Im Gegensatz dazu bietet der EGNOS
Dienst ein Netz aus Einwahlknoten an, welche die Daten jeweils eines definierten Bezugspunktes bereitstellen (Abb
3.57).
Der Umfang der übertragenen Datenmenge lässt sich problemlos über schmalbandige Mobilfunkverbindungen
abdecken. Übertragen werden drei wichtige Informationen. Die Korrektur der Pseudostreckenlänge (Pseudo Range
Correction, PRC), das Alter der Korrekturinformation, sowie die Änderung der Pseudostreckenkorrektur über die Zeit
(Range Rate Correction, RRC). Dies ist notwendig, da sich die Werte durch die Bewegung der Satelliten ständig
ändern. In Abb 3.58 sind die Ausgaben der Korrekturdaten zweier Empfänger zum gleichen Zeitpunkt dargestellt.
Interessant ist zu sehen, dass die Korrekturen der Streckenlängen mit bis zu 30 Metern unerwartet hoch ausfallen. Des
Weiteren ist zu bemerken, dass die Korrekturen von EGNOS und SAPOS EPS zumindest als „ähnlich‚ bezeichnet
werden dürfen. Dies liegt jedoch möglicherweise an der zufälligen Nähe zwischen dem Bezugspunkt der EGNOSDaten (50° N, 10° O) und der Position der virtuellen Referenzstation in der SAPOS Variante, denn das Raster der
EGNOS-Bezugsstationen beträgt in etwa 330 km – der Abstand der Messungen zum Bezugspunkt nur etwa 47km.
Abb 3.58: Vergleich der Korrekturdaten von EGNOS (links) und SAPOS EPS (rechts) zum gleichen Zeitpunkt
Als Ergebnis der Versuche lässt sich festhalten, dass die Korrekturen die Messungen in etwa auf die gleiche Weise
beeinflusst haben, unabhängig davon, ob es sich um die EGNOS oder SAPOS Korrekturen handelte. Die jeweiligen
Mittelwerte über eine Stunde stellten sich in einem Abstand von ca. 25 cm voneinander entfernt ein. Gleichwohl lagen
die mittleren Punktfehler im Rahmen der bisherigen Ergebnisse. Im Vergleich zu einem Empfänger, der während der
gleichen Zeit ohne Korrekturen betrieben wurde, sind die Mittelwerte um etwa 70 cm Meter in Richtung des
angenommenen Referenzpunktes verschoben. Somit kann hier eine Kompensationswirkung der systembedingten
Fehler festgestellt werden. Ob dies tatsächlich empirisch bei allen Messungen Gültigkeit hat, kann zurzeit mangels
59
Kapitel 3
langfristiger Daten noch nicht beantwortet werden. In [Pel05] wird die Anwendung von Korrekturdaten mit einfachen
GPS-Empfängern aufgrund mangelhafter stabiler Ergebnisse in Frage gestellt. In [Zog09a] wird festgestellt, dass
durch Anwendung von Korrekturdaten der Einfluss von Mehrwegeempfang auf die Pseudostreckenlängen zunimmt,
eine nähere Erläuterung hierfür wird dort jedoch nicht geliefert.
3.9.2 Dynamische Untersuchungen
Da für Navigationssysteme die Genauigkeit einer unbewegten Messung von nachrangiger Bedeutung ist, soll nun das
Augenmerk auf die Betrachtung von dynamischen Messungen gelenkt werden. Dies gestaltet sich erwartungsgemäß
schwieriger als die Betrachtung einer ruhenden Position. Das Problem ist das Fehlen eines festen Bezugssystems, in
dem man den Drift einer GPS-Messung verfolgen kann. Dies ist auch die Ursache, warum in der Literatur, etwa in
[Ram09] , Aussagen der Art zu finden sind, dass eine bewegte GPS-Messung genauer sei, als eine ruhende. Die
charakteristischen Punktwolken sind bei bewegten Messungen nicht zu finden. Die Experimente in diesem Abschnitt
haben aber gezeigt, dass der Drift sehr wohl vorhanden ist, allerdings durch die Bewegung entzerrt wird und so nicht
mehr erkennbar ist.
Die Beurteilung der Qualität der Messung soll in diesem Abschnitt etwas weiter gelöst werden von einer rein
empirischen Betrachtungsweise, da die statistischen Messwerte aus den vorherigen Messungen ohnehin nicht
ermittelt werden können. Vielmehr soll die Sicht auf den späteren Anwendungszweck gelenkt werden, nämlich die
Nutzung der Positionsdaten im Zusammenhang mit Kartographie und Navigation. Dazu wird zum einen amtliches
topografisches Kartenmaterial im Maßstab 1:10.000 und zum anderen Luftbildaufnahmen als Referenzen für die
Abweichungsbeurteilung zugrunde gelegt. Aufgrund der Erfahrungen aus den statischen Messungen werden
außerdem von Anfang an mehrere parallele Empfänger für die Datenerfassung verwendet.
In einer ersten Testfahrt sollte der Genauigkeitsunterschied zwischen den verschiedenen Gerätetypen untersucht
werden. Hierzu wurden die beiden Garmin Geräte, sowie eine Navilock GPS-Maus im Testfahrzeug montiert und
mehrere Male eine definierte Strecke in einem Wohngebiet abgefahren. Die Geschwindigkeit wurde so weit möglich
konstant auf 30 km/h gehalten und es wurde versucht eine weitgehend gleiche Fahrlinie zu wählen.
Wie aus den bisherigen Messungen zu erwarten war, zeigten die
gemessenen Strecken große Unterschiede zwischen den verschiedenen
Typen. Am schlechtesten ist die Aufzeichnung des eTrex H Gerätes zu
beurteilen (Abb 3.59, in blau dargestellt). Die Abweichungen quer zur
Fahrlinie waren sowohl in Nord/Süd-Richtung als auch in Ost/WestRichtung im Bereich von 15 bis 30 Metern und damit quasi nicht zu
gebrauchen. Ähnliche Ergebnisse lieferte das zweite Garmin Handgerät
(gelb) mit Maximalabweichungen von 15 Metern. Einzig die GPS-Maus
(grün) lieferte konstant gute Messergebnisse, die sich maximal etwa 4
Meter von der Referenzfahrtstrecke unterschieden.
In wie weit sich der Ansatz der Positions-Mittelung für dynamische
Szenarien eignet, sollte ein zweite Messfahrt mit ähnlichem
Abb 3.59: Testfahrt mit unterschiedlichen Versuchsaufbau zeigen. Es wurden ausschließlich die vorhandenen GPSEmpfängern
Mäuse verwendet. Die Maximaldifferenz zwischen zwei unterschiedlichen
Empfängern lag nach Auswertung der Ergebnisse bei etwa 12 Metern. Die
60
Kapitel 3
meiste Zeit bewegten sich die Messwerte innerhalb eines Radius von fünf Metern um den Mittelwert. Bei der
Auswertung der Daten wurde auch die unterschiedliche Position der Empfänger berücksichtigt und entsprechend der
Fahrtrichtung heraus gerechnet. Die Resultate können in der Gegenüberstellung in Abb 3.60 begutachtet werden. Die
gemittelte Strecke besitzt einen der Realität sehr gut angepassten Verlauf mit Abweichungen von maximal etwa 3
Metern, gegenüber der Referenzfahrtstrecke, was einem geschätzten mittleren Punktfehler von 1,5 m bis 2 m
entspricht.
Abb 3.60: Auswertung mehrerer paralleler Empfänger bei einer bewegten Messung,
Quellen: Top 10 Viewer, Google Earth
3.9.3 Langfristige Untersuchungen
Eine interessante Langzeitbeobachtung wird in [GPS10] unternommen. Ein fest installierter, handelsüblicher GPSEmpfänger zeichnet seit mittlerweile sechs Jahren kontinuierlich seine GPS-Position auf. Gut erkennt man an den
Analysen die Schwankungen von Länge, Breite und Höhe, welche sich ungefähr im 10 Minutentakt im Bereich von
zwei bis vier Metern ändern. Da ein vergleichbarer GPS-Chip eingesetzt wird, kann auch auf die absolute Genauigkeit
der innerhalb dieser Arbeit verwendeten Empfänger geschlossen werden. Ergänzend sei erwähnt, dass bei dieser
Langzeitbeobachtung die Abweichung der 24-Stunden Mittelwerte im Bereich von einem halben Meter gegenüber
dem Jahresmittelwert liegen.
Abb 3.61: Untersuchungen zur Abweichung von Längen- und Breitenposition über 24 Stunden,
Quelle: [GPS10]
Interessant an dieser Stelle wäre, die gleichen Daten mit zwei oder mehr parallelen Empfängern zu erheben. Dies
würde evtl. einen besseren Aufschluss darüber geben, in wie weit eine solche Abweichungsinformation als
Referenzwert genutzt werden kann. Auch wäre zu untersuchen, wie stark das Verfahren der Mittelung im
tageszeitlichen- und jahreszeitlichen Verlauf noch schwankt.
61
Kapitel 4
OpenStreetMap
Das Projekt OpenStreetMap, nachfolgend nur nach als OSM bezeichnet, existiert seit etwa 2004 und wurde in
Großbritannien gegründet. In Anlehnung an Wikipedia lag die Zielsetzung in einer frei verfügbaren Weltkarte, die von
jedermann aktualisiert werden kann. Im Gegensatz zu anderen Kartendiensten im Internet unterliegt OSM nur geringen
lizenzrechtlichen Einschränkungen, welche in der Creative Commons Lizenz (vgl. [CrC10] ) festgeschrieben sind.
Dieses Kapitel soll die einzelnen Bestandteile des Projektes näher beleuchten. Nach einer Einführung zu Geodaten,
einem Überblick über den aktuellen Stand des Projekts und dessen Intention folgen nähere technische Details zum
verwendeten Datenmodell, den verschiedenen Darstellungsformen und den vorhandenen Zugriffsmöglichkeiten. Zum
Abschluss des Kapitels wird der Prozess des Geo-Mappings, also die Erstellung von Kartendaten, näher erläutert.
4.1
Geodaten
Der Begriff der Geodaten fasst alle Arten von Informationen über die Lage geographischer Objekte zusammen. Solche
Objekte können z.B. Flüsse, Straßen, Küsten, Wälder oder besiedelte Gebiete sein. Auch fallen darunter häufig
sogenannte Points-of-Interest, also Objekte, die aus verschiedenen Gründen von besonderem Interesse sind, von der
einfachen Tankstelle bis zur historischen Sehenswürdigkeit. Die Vielfallt der gespeicherten Daten ist nahezu
unbegrenzt und kann an dieser Stelle kaum aufgezählt werden. Die gebräuchlichste Verwendungsart von Geodaten,
sind die vorhandenen Landkarten, wie z.B. topografische Karten oder Katasterkarten, wie sie bei Vermessungsämtern
zur Grundstücksverwaltung vorgehalten werden.
4.1.1 Speicherung
Wurden in früherer Zeit derartige Daten mit Hilfe von klassischen Karten festgehalten, ist man mittlerweile dazu
übergegangen, Computersysteme für die Verarbeitung und Speicherung zu verwenden. Ein solches System wird als
Geoinformationssystem (GIS) bezeichnet.
Die Vorhaltung der Geodaten erfolgt auf vielfältigen Wegen. So können sie z.B. in Form von Bilddaten gespeichert
werden. Dies wird als rasterbasierte Speicherung bezeichnet und ist das Resultat der Verwendung von vorhandenem
analogem Kartenmaterial oder Luftbildern. Als effektivere Speicherformen haben sich jedoch vektororientierte
Verfahren herausgestellt. Sie bieten Vorteile durch bessere Verwaltbarkeit, einfachere Indizierbarkeit und höhere
62
Kapitel 4
OpenStreetMap
Flexibilität. Vor allem dadurch, dass es einfacher ist, auf einzelne Objekte zuzugreifen und geometrische Operationen 26
mit ihnen durchzuführen (vgl. [Bri08] ). In Abb 4.1 sind verschiedene Speichervarianten gegenüber gestellt.
Im Laufe der Entwicklungsgeschichte von Geoinformationssystemen haben sich verschiedene Speicherungsformen für
vektororientierte Geodaten verbreitet. Ursprünglich wurden Geo-Objekte meist mit Hilfe proprietärer Formate der
verschiedensten Hersteller in Dateien bzw. als Binärobjekte in Datenbanksystemen, oder mit Hilfe relational
verknüpfter Tabellen abgelegt. Erst Mitte der Neunziger Jahre entwickelte sich mit dem „Simple Feature Model‚ ein
Standard, der mittlerweile von zahlreichen Datenbankherstellern und Softwarefirmen mehr oder weniger adaptiert
wurde. So stehen für die meisten Datenbanksysteme sogenannte Spatial Extensions zur Verfügungen, die die
Datenbanken um die Fähigkeit zur Ablage räumlicher Informationen erweitern. So etwa PostGIS für PostgreSQLDatenbanken oder Locator für Oracle Systeme (vgl. [Kno06] ). Den Datenbanksystemen werden geeignete Datentypen
hinzugefügt, die die Speicherung von räumlichen Objekten ermöglichen. Außerdem wurden Funktionen für räumliche
Basisanfragen ergänzt, wie z.B. zur Schnittberechnung oder zur Erzeugung minimalumschließender Rechtecke (vgl.
[Stö09a] ). Die standardisierten Primitive sind u.a. Punkt, Linie oder Polygon. Nähere Details findet man in [Bri06] .
a)
b)
c)
Abb 4.1: Gegenüberstellung der Speicherung von Geodaten am Beispiel eines Sees
als Luftbild (a), topografische Karte (b) und vektorbasiertes Polygon (c), Quelle:, Top10 Viewer, OpenStreetMap.org
4.1.2 Übertragungsformate
Zusätzlich zur reinen Speicherung in Geoinformationssystemen besteht die Notwendigkeit des Datenaustauschs und
der weiteren Verarbeitung. Neben eigenen proprietären Binärformaten werden zur Übertragung von Geodaten auch
XML-Formate verwendet. Durch die Verwendung von XML ist eine hohe Interoperabilität gewährleistet. Daher findet
auch bei OSM ein solches Format Anwendung. Genaueres hierzu ist dem Kapitel 4.3.2 zu entnehmen.
4.2
Projektüberblick
An dieser Stelle soll zunächst ein grober Umriss über die Idee und das Konzept von OSM skizziert werden.
Insbesondere soll dargelegt werden, wo die Vorteile des Systems liegen und wie man den aktuellen Stand der
Erfassung einschätzen muss. Außerdem soll der grundsätzliche Systemaufbau erläutert und die Genauigkeit der
Kartendaten beurteilt werden.
4.2.1 Motivation
Wenn man sich mit dem Projekt OSM beschäftigt, stellt sich zunächst die Frage, warum OSM und nicht einen der
zahlreichen anderen im Internet verfügbaren Datendienste. Letztlich stellen drei Dinge die Hauptmotivation dar.
Zunächst ist die freie Verwertbarkeit der Karten für viele Nutzer ausschlaggebend, den Dienst zu benutzen. So stellt
26
Geometrische Operationen liefern z.B. topologische Informationen, wie Schnitt- oder Nachbarschaftsbeziehungen.
63
Kapitel 4
OpenStreetMap
z.B. die Verwendung eines Kartenausschnitts in einer gedruckten Anfahrtsbeschreibung bei den meisten Anbietern
bereits eine Verletzung der hierbei geltenden Lizenzrechte dar (vgl. [Elk08] ). Im Gegensatz zur OSM-Karte, welche
lediglich die Erlaubnis zur freien Vervielfältigung fordert. Der zweite Aspekt, ist die flexible Gestaltung und Auswertung
der vorhandenen Informationen. Die freie Weltkarte erlaubt jedem den direkten Zugriff auf die Geodaten. Dies
ermöglicht die Gestaltung eigener Karten nach ganz individuellen Bedürfnissen. Es existieren beispielsweise Rad-,
Wander- oder Skipistenkarten welche die jeweils relevanten Wege und Strecken besonders hervorheben. Der dritte
und letzte Punkt ist die freie Editierbarkeit der Daten. Jeder, der einen Fehler findet oder noch unerfasste Gegenden
auf der Landkarte aufdeckt, ist in der Lage, dies zu korrigieren. Er muss sich nur mit einem Benutzernamen und einem
Passwort registrieren und kann fortan Änderungen eintragen.
Ein weiterer großer Vorteil des OSM-Projekts, welcher zurzeit an Bedeutung gewinnt, ist die kostenfreie Nutzung in
mobilen Navigationssystemen. Im Gegensatz hierzu müssen Kartenaktualisierungen für ältere Geräte meist teuer bei
großen kommerziellen Anbietern, wie NAVTEQ, eingekauft werden. Dies kann je nach Gerät und gewünschter
Länderabdeckung sehr kostspielig werden, als Beispiel [Nav10] . Die Nutzung von OSM ermöglicht hingegen die
Verwendung von aktuellem Kartenmaterial ohne finanzielle Aufwendungen.
Außerdem ist für kommerzielle Anbieter nicht jedes Gebiet von gleichem Interesse. Insbesondere strukturschwache
Gegenden sind davon stark betroffen und teilweise schlecht bis überhaupt nicht erfasst. In Abb 4.2 wird dieser
Unterschied am Beispiel von Bagdhad sehr deutlich.
Abb 4.2: Unterschiedliche Qualität der Abdeckung am Beispiel von Bagdhad,
Quellen: maps.google.com (links), www.openstreetmap.org (rechts)
4.2.2 Aktueller Stand
Das Projekt startete im Jahr 2004 quasi bei null. Im Laufe der Zeit nahm die
Zahl der Projektteilnehmer stetig zu. Zurzeit zählt OSM ca. 230.000
Mitglieder, von denen etwa 10% als aktive "Mapper" gezählt werden. Als
solche werden Mitglieder der OSM-Community bezeichnet, die Daten
erfassen um OSM zu aktualisieren und zu erweitern. Die Abdeckung des
Kartenmaterials schwankt von Land zu Land sehr stark. Im weltweiten
Vergleich zählt "Deutschland in OpenStreetMap zu den best erfassten
Gebieten" [OSM10d] . Vor allem Großstädte sind nahezu vollständig
enthalten. So meldete Hamburg am 24.10.2008 die nachgewiesene
64
Abb 4.3: OSM-Aktivität in Europa 2008,
Quelle www.itoworld.com
Kapitel 4
OpenStreetMap
Erfassung von 99,8 % des Straßennetzes [hei08] . In ländlichen Gebieten finden sich dagegen immer noch weiße
Flecken. An der nebenstehenden Abb 4.3 lassen sich die Länder mit der höchsten Aktivitätsrate (helle Flächen) in
Europa erkennen. Allen voran Deutschland, Schweiz und Österreich, gefolgt von den Niederlanden, Großbritannien
und Weißrussland. Weltweit wurden bisher fast 600 Mrd. Koordinaten in die Datenbank eingetragen. Das umfasst das
Straßennetz, aber auch Gebäudeumrisse oder Landesgrenzen. Als Datenquellen werden vornehmlich die GPSAufzeichnungen der Nutzer verwendet. Jedoch stehen auch einige externe Quellen zur Verfügung. Darunter die
TIGER-Daten27 in den USA, Satellitenbilder von Yahoo und die Daten der Firma AND (Automotive Navigation Data) aus
den Niederlanden.
4.2.3 Systemaufbau
OSM verfolgt ein mehrschichtiges Konzept. Die Basis des Systems bildet
die eigentliche OSM-Datenbank. Es handelt es sich um eine MySQLDatenbank, die am University College London betrieben wird. Die
sogenannte OSM-API (Application Programming Interface) ermöglicht den
lesenden und schreibenden Zugriff auf die Geodaten.
Zwei primäre Anwendungsfälle sind für die Nutzung von OSM definiert.
Zum einen die Verwendung durch einen gewöhnlichen Benutzer, der
ausschließlich fertige Karten benötigt. Diese werden von einem der
Abb 4.4: Aufbau der OpenStreetMap
zahlreichen Renderer aus den Rohdaten erzeugt und bereitgestellt. Zum anderen die Verwendung durch einen
Mapper, der eine direkte Verbindung zur OSM-Datenbank benötigt. Hierfür stehen verschiedene Editoren zur
Verfügung. Renderer und Editoren stammen oft von Drittanbietern.
4.2.4 Genauigkeit
Eine feste Aussage über die Genauigkeit von OSM zu treffen fällt auf Grund der unterschliedlichen
Datenerfassungsmethoden schwer. Gebiete, die mit Hilfe externer Datenquellen importiert wurden, weisen oft eine
konstante Qualität auf.
Ausschließlich per GPS erfasste Daten schwanken stark in ihrer Genauigkeit. Dies liegt zum einen an der
Ungenauigkeit der Positionsbestimmung und zum anderen an den unterschiedlich arbeiteten Mappern. So wird in
[Ram09] empfohlen, eine Gegend unter Umständen mehrfach und an unterschiedlichen Tagen zu erfassen um den
tatsächlichen Verlauf der Straßen beim Editieren der Datenbank besser ausmitteln und Schwankungen des GPSSystems ausgleichen zu können.
Um ein Gefühl für mögliche Abweichungen zu bekommen ist in Abb 4.5 ein und derselbe GPS-Track sowohl in eine
amtliche topografische Karte als auch in OSM eingezeichnet. Man erkennt, dass die OSM-Karte in weiten Teilen nach
Osten abweicht. Die maximale Abweichung liegt bei etwa 25 Metern, was als hoch einzuschätzen ist. Eine detaillierte
Untersuchung der Qualität der OSM-Karten findet man in [Zol08] .
27
‚Topologically Integrated Geographic Encoding and Referencing‛ bezeichnet einen Datensatz des United States Census Bureau, einer amerikanischen
Volkszählungsbehörde, welcher das US-Straßennetz weitestgehend abdeckt.
65
Kapitel 4
OpenStreetMap
Abb 4.5: Vergleich einer topografischen Karte (links) mit der OSM-Karte (rechts),
Quelle Top10 Viewer, www.openstreetmap.org
4.3
Datenmodell
Um die Funktionsweise und den Aufbau von OSM, sowie die damit zusammenhängenden Schnittstellen zu verstehen,
ist es notwendig, sich einen detaillierten Blick auf das zugrunde liegende Datenmodell zu verschaffen. Die Entwickler
haben Wert auf eine einfache, verständliche aber trotzdem flexible Struktur gelegt. So gibt es nur vier Datentypen
innerhalb des Modells, mit deren Hilfe die freie Weltkarte modelliert wird (vgl. [Ram09] ). Zusätzlich zu dem hier
dargestellten Modell verwaltet das System mit Hilfe von internen Changesets eine Versionshistorie, mit der es
ermöglicht wird, alle Änderungen zu verfolgen (siehe Kapitel 4.3.2).
Koordinaten werden durch Knoten (engl. „Nodes‚) repräsentiert. Sie bilden die grundlegende Einheit in OSM und
enthalten Längen- und Breitengrad in der WGS 84-Angabe (siehe. Kapitel 2.3). Daneben gibt es Wege (engl. „Ways‚),
als sortierte Folge von mindestens 2 Knoten. Damit sind aber nicht nur Wege und Straßen gemeint, sondern alle Arten
von Streckenzügen innerhalb der Karte. Also z.B. auch Küstenlinien, Gebäudeumrisse oder Flüsse. Einen Datentyp
Polygon hingegen gibt es nicht. Polygone werden u.a. dadurch definiert, dass erster und letzter Punkt eines Weges
identisch sind (vgl. [OSM09b] ). Der Datentyp Relation (engl. „Relation‚) dient dazu, übergeordnete Beziehungen zu
definieren. Dies ermöglicht etwa alle Bundesautobahnen in einer Relation zusammenzufassen. Jedem
Relationsmitglied kann eine Rolle (engl. „Role‚) zugeordnet werden, die frei definierbar ist und über die Funktion eines
Elements in der Relation Auskunft gibt.
Abb 4.6: Vereinfachtes Datenmodell von OSM
Zu bemerken ist, dass mit Hilfe der genannten Relationen auch die Speicherung von Multipolygonen gelöst ist.
Multipolygone zeichnen sich dadurch aus, dass sie nicht nur über einen äußeren geschlossenen Streckenzug definiert
sind, sondern auch ein oder mehrere innere Streckenzüge aufweisen, welche „Löcher‚ im Polygon darstellen. Ein
Waldstück mit einer Lichtung in der Mitte kann nur auf diese Art definiert werden. Die OSM Lösung sieht vor, dass man
66
Kapitel 4
OpenStreetMap
innerhalb einer Relation mehrere Polygone zusammenfasst. Ein Polygon erhält die Rolle „outer‚, womit der äußere
Rand gemeint ist. Alle weiteren erhalten die Rolle „inner‚, womit die Löcher bezeichnet werden (vgl. [Ram09] ).
Alle Knoten, Wege und Relationen erhalten bei der Erzeugung eindeutige Primärschlüssel (ID) aus einem jeweils
eigenen Nummernkreis und können mit Hilfe von sogenannten „Tags‚ näher beschrieben werden. Das kann z.B. die
Art eines Weges sein, oder der Name einer Straße. Die Verwendung des Tag-Typs ist nicht fest vorgeschrieben.
Weitere hinterlegte Metadaten sind der Zeitpunkt der letzten Änderung und ein Verweis auf den Benutzer, der diese
durchgeführt hat.
4.3.1 Gängige Tags
Um die Elemente näher zu beschreiben werden wie beschrieben sogenannte Tags verwendet. Je nach Bedarf werden
nur einzelne Knoten oder der ganze Weg bzw. die Relation mit Tags versehen. Es handelt es sich um Schlüssel/WertPaare, die vom Mapper beliebig vergeben werden können. Sowohl die Bezeichnung des Schlüssels als auch die Wahl
des Wertes kann frei entschieden werden. Damit die Renderer, welche für die Erstellung der Kartengrafiken zuständig
sind, die Geodaten korrekt interpretieren können, empfiehlt sich die Orientierung an den gängigen Bezeichnungen. Mit
der Zeit hat sich in der OSM-Community ein stabiles Schema entwickelt, nach dem die eingetragenen Daten
gekennzeichnet werden. [Pid09] liefert dazu eine schöne Übersicht. Unter [OSM10b] findet man eine Auflistung von
gängigen Tags für etwa 300 verschiedene Objekttypen. Nachfolgend ein Auszug von Beispielen und die dafür
empfohlenen Bezeichnungen.
Objekt
Autobahn
Fußweg
Gut befestigter Weg
Fussgängerzone
Dorf
Bushaltestelle
Eisenbahnschienen
Bahnhof
Empfohlene Tags
highway=motorway
highway=footway
highway=track
tracktype=grade3
highway=pedestrian
place=village
highway=bus_stop
railway=rail
railway=station
Objekt
Krankenhaus
Industriegebiet
Einbahnstrasse
Bäckerei
Golfplatz
Zoo
Burg oder Schloss
Landebahn
Empfohlene Tags
amenity=hospital
landuse=industrial
highway=*
oneway=yes
shop=bakery
leisure=golf
tourism=zoo
historic=castle
aeroway=runway
Tabelle 4.1: Ausgewählte OSM-XML-Tags
4.3.2 Changesets
Um vorgenommene Änderungen an den Geodaten nachvollziehen zu können oder um gegebenenfalls Änderungen
wieder rückgängig zu machen, speichert die Datenbank sogenannte Changesets. Damit nicht jede einzelne Änderung
an einem Knoten verwaltet werden muss, sind in einem solchen Datensatz in sich abgeschlossene und
zusammengehörende Änderungen zusammengefasst. Sie „sollen für eine bessere Übersicht sorgen und die Analyse
erleichtern, welcher Benutzer wann und wo welche Änderung durchgeführt hat‚ [Ram09] . Als Beispiel sei das
Hinzufügen oder Korrigieren einer ganzen Straße genannt. Dies umfasst die Manipulation zahlreicher Knoten und
Wege, stellt aber nur ein einziges Changeset dar.
67
Kapitel 4
OpenStreetMap
Beim Ändern von Daten muss zunächst ein Changeset erstellt und geöffnet werden, da der Server eine Aktualisierung
der Datenbank nur unter Angabe einer Changeset-ID erlaubt. Nach Durchführung der gewünschten Änderung wird
der Datensatz geschlossen. Ein nachträgliches Wiedereröffnen oder Löschen ist nicht erlaubt.
4.3.3 XML-Protokoll
In Anlehnung an das Datenmodell entstand das OSM-XML-Protokoll, welches den verschiedenen Schnittstellen in
Kapitel 4.5 zugrunde liegt, aber auch an anderen Stellen innerhalb des OSM-Projekts verwendet wird. Unter [OSM10a]
findet sich die Document Type Definition (DTD) welche gemäß dem XML-Standard die zulässigen Elemente eines
OSM-XML-Dokuments genau spezifiziert. Als Dateiendung wird .osm verwendet. Ebenso findet das OSM Kürzel als
XML-Wurzelelement28 Anwendung. Eine Datei, die in diesem Format bereitgestellt wird, ist die „planet.osm‚. Es handelt
sich um eine 160 GB große wöchentlich erstellte Kopie der OSM-Datenbank.
Zur Angabe der geographischen Grenzen der Daten wurde ein Bounds-Element definiert, das jeweils den minimalen
bzw. maximalen Längen- und Breitengrad angibt (Listing 4.1). Danach folgt eine beliebig lange Liste von Knoten,
Wegen und Relationen.
5
<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6">
<bounds minlat="50.106" minlon="9.346" maxlat="50.118" maxlon="9.370"/>
…
</osm>
Listing 4.1: Rahmen eines OSM-XML-Dokuments
Tags
Zur näheren Beschreibung definiert OSM sogenannte Tags. In der Darstellung als XML-Code wird der Schlüssel über
das Attribut k (key), der Wert über das Attribut v (value) festgelegt. Einige Beispiele:
<tag k="highway" v="residential"/>
<tag k="name" v="Sternstraße"/>
<tag k="postal_code" v="63831"/>
Listing 4.2: Beispiele von OSM-XML-Tags
Knoten
Längen und Breitengrad eines Nodes bzw. Knotens werden mit sieben Nachkommastellen abgelegt. Das reicht für
eine Genauigkeit von etwa einem halben Meter und ist somit genauer, als die meisten heutigen GPS-Geräte (vgl.
[Bra09] ). Neben der Positionsangabe liefert das Node-Element aber auch Informationen zur letzten Änderung, wie
Zeitpunkt, Benutzername, Versionsnummer oder zugehöriges Changeset. Das Attribut „visible‚ gibt an, ob ein Knoten
sichtbar ist (=„true‚) oder gelöscht wurde (=„false‚).
5
…
<node id="634131991" lat="50.1100512" lon="9.3643223"
user="misteret112" uid="182332" visible="true" version="1"
changeset="3830080" timestamp="2010-02-09T09:11:21Z"/>
…
Listing 4.3: Beispiel eines OSM-XML-Nodes
Wege
Ein Weg bzw. Way enthält die gleichen Metadaten, wie Node. Daneben ist eine sortierte Liste mit Referenzen auf die
zum Weg gehörenden Knoten enthalten. Diese werden angegeben mit dem Kürzel nd und der Nummer des Knotens.
28
Unter XML-Wurzelelement versteht man das oberste Element in einem XML-Dokument, welches alle nachgeordneten Elemente enthält.
68
Kapitel 4
OpenStreetMap
Als Einschränkung ist die maximale Anzahl von Knoten pro Weg auf 2000 festgelegt. Üblicherweise enthält ein Weg
Tags zur näheren Beschreibung.
5
<way id="49895854" user="misteret112" uid="182332" visible="true"
version="2" changeset="3838359" timestamp="2010-02-10T08:21:19Z">
…
<nd ref="634131991"/>
<nd ref="634131992"/>
…
<tag k="highway" v="residential"/>
…
</way>
Listing 4.4: Beispiel eines OSM-XML-Ways
Relationen
Um auszudrücken, dass mehrere Elemente miteinander in Beziehung stehen, werden Relationen verwendet. Jede
Relation enthält neben den üblichen Metadaten eine Liste von bis zu 1000 Mitgliedern. Wichtig ist, dass der Typ eines
Mitglieds angegeben werden muss, da die IDs für Knoten, Wege und Relationen nur innerhalb der jeweiligen Klasse
eindeutig sind.
Falls eine Rolle vergeben werden soll, kann diese mit dem Attribut role angegeben werden. Außerdem empfiehlt sich
die nähere Beschreibung anhand von Tags.
Relationen werden u.a. eingesetzt, wenn die Knotenanzahl für einen Weg überschritten wurde. Um die Knotenanzahl
zu verringern wird der betroffene Weg in zwei einzelne Wege aufgeteilt, die mit Hilfe einer Relation in Beziehung
zueinander gesetzt werden.
5
10
<relation id="22199" user="nebel" uid="187788" visible="true"
version="6" changeset="3546111" timestamp="2010-01-05T15:01:23Z">
…
<member type="way" ref="23540621" role=""/>
<member type="way" ref="14990863" role=""/>
…
<tag k="highway" v="secondary"/>
<tag k="name" v="Staatsstraße St 2905"/>
<tag k="operator" v="Freistaat Bayern"/>
<tag k="ref" v="St 2905"/>
…
</relation>
Listing 4.5: Beispiel einer OSM-XML-Relation
4.4
Visualisierung
Damit man die erfassten Geodaten auch zur Orientierung verwenden kann, müssen daraus Kartengrafiken erstellt
werden. Dieser Prozess wird bei OSM als rendern bezeichnet. Die Programme, die diesen Prozess übernehmen,
werden im Folgenden Renderer genannt. Sie laden nach einem vorgegebenen Schema die Daten aus der OSMDatenbank und erzeugen anhand von definierten Vorlagen – sogenannten Stylesheets - die Kartengrafiken. Als
Projektion wird im Allgemeinen eine Mercator Projektion verwendet (siehe Kapitel 2.3.1).
Da es nicht möglich ist, eine Karte der gesamten Welt in allen Details auf einmal zu erzeugen, bedient man sich meist
einem mehrstufigen Prozess, bei dem die Erdoberfläche in Kacheln unterschiedlicher Größe und Detailgenauigkeit
zerlegt wird. In der niedrigsten Zoomstufe 0 wird die Weltkarte durch eine einzige Kachel repräsentiert. Auf Stufe 10
sind es bereits 17 Millionen und die höchste Stufe (18) benötigt ganze 69 Milliarden Kacheln [OSM10f] .
69
Kapitel 4
OpenStreetMap
Der Zugriff erfolgt z.B. mit Hilfe einer „Slippy Map‚, einer einfachen Bedienoberfläche, die im Webbrowser dargestellt
wird und in der man per Mausnavigation zoomen, sowie in alle Richtungen navigieren kann. Je nach ausgewähltem
Bereich werden automatisch die passenden Kacheln in der richtigen Auflösung von einem Server im Internet
nachgeladen. Die Kacheln werden durch ein Koordinaten-Tripel (Z/X/Y) eindeutig identifiziert. Wobei z für die
Zoomstufe und X bzw. Y für die Koordinaten der Kacheln verwendet werden. Zum besseren Verständnis ist in Abb 4.7
die Berechnungsvorschrift zum Wechseln der Zoomstufe dargestellt. Da die Verzerrungen bei der Mercatorprojektion
an den Polen zu stark sind, werden die Kacheln nur bis zum 85 Breitengrad nach Norden bzw. Süden erzeugt.
Abb 4.7: Berechnungsvorschrift zur Bestimmung
der Koordinaten für die nächste Zoomstufe
Unabhängig von der Möglichkeit eigene Karten für bestimmte Gebiete zu erstellen, stellt OSM verschiedene
Weltkarten – in diesem Fall als Layer bezeichnet - vorgerendert zur Verfügung. Mit dem „Mapnik‚- und dem
„Osmarender‚-Layer werden die beiden wichtigsten im Anschluss erläutert. Neben diesen sind im Internet aber noch
zahlreiche andere Layer für die unterschiedlichsten Zwecke zu finden, welche aus den OSM-Daten generiert wurden.
Abb 4.8: Vergleich der Darstellung zwischen Mapnik- (links) und Osmarender-Layer (rechts),
Quelle: www.openstreetmap.org
4.4.1 Mapnik-Layer
Der durch den Mapnik-Renderer erzeugte Layer ist die standardmäßig ausgewählte Anzeigeform der Slippy Map auf
der OSM-Webseite. Die einzelnen Bereiche der Karte werden in unregelmäßigen Abständen aktualisiert. Kacheln, die
häufig von Nutzern abgerufen werden, erstellt das System spätestens alle drei Tage neu. Die genaue Prozedur kann
unter [OSM10e] nachvollzogen werden.
70
Kapitel 4
OpenStreetMap
4.4.2 Osmarender-Layer
Der Osmarender-Layer unterscheidet sich nicht nur optisch von den Mapnik-Karten (siehe Abb 4.8). Auch der
Herstellungsprozess der Kacheln ist ein gänzlich anderer. Die Karten werden nicht, wie im vorherigen Kapitel von
einem Server zentral gerendert, sondern im Rahmen des Tiles@home-Projekts (vgl. [Ram09] ) von weltweit verteilten
Clientprogrammen erzeugt, die auf Rechnern von Nutzern installiert sind. Eine zentrale Instanz delegiert anstehende
Renderaufträge an Clients, welche die angeforderten Grafiken in den geforderten Zoomstufen erstellen und zurück
senden.
4.5
Schnittstellen
Der direkte Zugriff auf die SQL-Datenbank wird von OSM nicht erlaubt. Hierfür wird eine Programmierschnittstelle zur
Verfügung gestellt. Die OSM-API (OSM Application Programming Interface). Sie ermöglicht einen lesenden und
schreibenden Zugriff auf die Geodaten. Neben dieser existieren weitere APIs für spezielle Anwendungen, die von
Drittanbietern vorgehalten werden.
Als Transferprotokoll wird HTTP verwendet. Die Aufrufe erfolgen zustandslos, d.h. jeder Aufruf stellt eine atomare
Operation dar und ist für sich abgeschlossen. Es werden keine Sitzungsinformationen angelegt oder benötigt. Dies
orientiert sich am sogenannten RESTless Design, wie es in [Fie00] vorgestellt wird.
4.5.1 Application Programming Interface („API“)
Die OSM-API wird einer ständigen Weiterentwicklung unterzogen und steht mittlerweile in der Version 0.6 zur
Verfügung. Wie beschrieben stellt sie neben dem lesenden Zugriff auch Methoden zur Verfügung, um Datensätze zu
erzeugen, zu ändern oder zu löschen. Hierzu bedient man sich unterschiedlicher Aufrufe. Tabelle 4.2 nennt die
Wichtigsten. Weitere Aufrufe werden u.a. in [Ram09] vorgestellt.
In der Auflistung kann das <typ>-Feld jeweils mit node, way und relation ersetzt werden. Bis auf die LöschenOperation lassen sich die Aufrufe auch auf Changesets anwenden („Ändern‚ jedoch nur bei einem geöffnetes
Changeset, siehe Kapitel 4.3.2).
Die HTTP-Methode in der Tabelle bezeichnet die verschiedenen Anfrage-Modelle, die durch HTTP definiert sind. Die
Unterschiede zwischen den verwendeten Methoden werden in [Win10] detailliert erklärt.
Neuanlage
Lesen
Ändern
Löschen
HTTP-Methode
und URL
Anfrage Parameter
Antwort
PUT
/api/0.6/<typ>/create
GET
/api/0.6/<typ>/<id>
PUT
/api/0.6/<typ>/<id>
DELETE
/api/0.6/<typ>/<id>
XML
ID
-
XML
XML
Version
XML
-
Tabelle 4.2: Wichtige Methoden der API, nach [Ram09]
Für alle schreibenden Operationen muss sich der Nutzer authentifizieren. Dies geschieht mit Hilfe der HTTPAuthentifizierung (vgl. [Ram09] ). Passwort und Benutzername werden unverschlüsselt übertragen.
71
Kapitel 4
OpenStreetMap
Bounding Box
Neben dem Abruf einzelner Elemente, wie in der Tabelle aufgeführt, existiert noch ein wichtiger Aufruf für den
lesenden Zugriff: die Abfrage aller Objekte innerhalb einer sogenannten Bounding Box. Als solche, wird ein Rechteck
bezeichnet, das einen bestimmten Bereich vollständig umschließt. In diesem Fall erfolgt die Angabe in Form von West, Süd-, Ost- und Nordkoordinaten, die die Begrenzungen in die jeweiligen Richtungen definieren:
GET /api/0.6/map?bbox=<West>,<Süd>,<Ost>,<Nord>
Da die Verwendung der API ausschließlich zum Editieren der Datenbank vorgesehen ist, sind der Bounding BoxMethode gewisse Einschränkungen auferlegt. Eine davon ist die Begrenzung der Abfrage auf eine Fläche von 0,25
Quadratgrad29. In den Breitengraden Europas entspricht dies ungefähr 2000 km² und ist somit für die meisten
Anwendungsfälle ausreichend. In der Praxis stellt die Limitierung auf maximal 5.000 Knoten ein viel größeres Problem
dar. Dies muss bei der Verwendung der Methode durch die Angabe entsprechend kleiner Ausschnitte berücksichtigt
werden (vgl. [OSM09a] ).
Bei der Abfrage ist weiterhin zu berücksichtigen, dass Wege, die nur teilweise in einem angeforderten Bereich liegen,
vollständig übertragen werden. Bei einer kachelbasierten Ladestrategie kann dies zu Redundanzen und einem
erhöhten Datenaufkommen führen.
osmChange
Mit einem Änderungsdokument nach der osmChange Definition existiert eine weitere Methode zur Aktualisierung der
Daten. Mit Hilfe eines osmChange Dokuments ist es möglich, gleich mehrere Änderungen in einem Aufruf
zusammenzufassen. Es handelt sich um einen Sonderfall des OSM-XML-Formats (siehe Listing 4.6). Die Änderungen
werden durch beliebige Folgen von create- (Neuanlage), modify- (Ändern) oder delete- (Löschen) Abschnitten an den
Server übermittelt. Der Aufruf erfolgt durch Übermittlung des Dokuments an den Server:
POST /api/0.6/changeset/<id>/upload
Werden neu zu erstellende Elemente referenziert, sind negative Zahlen zu verwenden. Die Datenbank erzeugt beim
Erstellen daraus eindeutige Referenznummern und liefert diese an den Aufrufer zurück.
5
10
15
<osmChange version="0.3">
<create version="0.3">
<node id="-1" lat="-33.9133118" lon="151.1173353"/>
<node id="-2" lat="-33.9233113" lon="151.1173352"/>
<way id="-3">
<nd ref="-1"/>
<nd ref="-2"/>
</way>
</create>
<modify version="0.3">
<node id="91575880" lat="50.0213528" lon="9.2987305"/>
</modify>
<delete version="0.3">
<node id="91575880"/>
</delete>
</osmChange>
Listing 4.6: Vereinfachtes osmChange-Dokument
Das Übernehmen eines osmChange Dokuments erfolgt in Form einer Transaktion. D.h. alle Änderungen in einem
Dokument werden als atomar betrachtet, mit der Folge, dass entweder das ganze Dokument übernommen, oder bei
Fehlern das ganze Dokument abgelehnt wird (vgl. [Wik10l] ).
29
Quadratgrad ergeben sich aus Breitenausdehnung mal Längenausdehnung.
72
Kapitel 4
OpenStreetMap
4.5.2 Mobile Binary Protocol
Neben der normalen XML-API befindet sich das Mobile Binary Protocol derzeit in der Entwicklung. Es soll Daten in
einer Binärkodierung vor allem an mobile Geräte übermitteln. Dies hat im Vergleich zur XML-Variante den Vorteil, dass
weniger Daten übertragen werden müssen. [OSM09c] spricht von möglichen Kompressionsraten bis zu 98%. Es
handelt sich bisher nur um eine Spezifikation des Formats. Konkrete Implementierungen einer API die das Mobile
Binary Protokoll unterstützt, werden von OSM zurzeit noch nicht zur Verfügung gestellt.
Als Alternative zu einem Binärformat, bieten die Webserver des OSM-Projekts an, die HTTP-Kompression für die
normale API zu verwenden. Die übertragenen XML-Daten werden mit dem Kompressionsalgorithmus Gzip um
durchschnittlich 89% verkleinert (vgl. [OSM09c] ).
4.5.3 Weitere Schnittstellen
Neben den beiden vorgenannten Zugriffsmöglichkeiten, stehen noch weitere für spezielle Anwendungen zur
Verfügung. Ein wichtiger Unterschied zwischen den hier vorgestellten Sonder-APIs und der OSM-API ist, dass sie auf
Kopien der OSM-Datenbank arbeiten, welche in unterschiedlichen Abständen mit der OSM synchronisiert werden.
ROMA
Die Read Only Map API (ROMA) wurde speziell für das Tiles@home-Projekt entwickelt. Es handelt sich um eine
abgespeckte API, die ausschließlich den lesenden Zugriff per Bounding Box Aufruf ermöglicht.
GET /api/0.6/map?bbox=<West>,<Süd>,<Ost>,<Nord>
TRAPI
Auch die Tiled Read only API (TRAPI) ist aus dem Tiles@home-Projekt heraus entstanden und löst die vorige ROMASchnittstelle derzeit ab. Die Clients innerhalb dieses Projekts rufen immer gleichgroße Bereiche in einem festgelegten
Raster ab, das sich an dem in Kapitel 4.4 beschriebenen Verfahren der Kachelung orientiert. Das besondere an TRAPI
ist die Vorhaltung der OSM-XML-Daten für genau diese Kacheln. Der Aufruf einer Bounding Box ist zwar ebenfalls
möglich, der Server rundet die Angaben jedoch intern auf volle Kachelgrenzen auf [OSM10g] . Der native Zugriff
erfolgt nach der bereits beschriebenen Adressierungsart mit einem Koordinatentripel (Z/X/Y).
GET api/0.6/map?bbox=<Süd>,<West>,<Nord>,<Ost>
GET api/0.6/map?tile=<Z>,<X>,<Y>
XAPI
Die XAPI, oder Extended API, unterstützt die gleichen Abfragefunktionen, wie die normale API. Die Beschränkung von
0.25 Quadratgrad wurde jedoch auf 100 Quadratgrad erhöht.
Eine wichtige Besonderheit ist die Möglichkeit, die Ergebnismenge durch Filter einzuschränken. So können durch
nachfolgenden Aufruf alle Tankstellen die innerhalb der angegebenen Begrenzung (ungefähr Deutschland) liegen
abgefragt werden. In [Ram09] finden sich noch zahlreiche weitere Beispiele.
GET /api/0.6/*[bbox=6,53,14,55][amenity=fuel]
4.6
Mapping
In Kapitel 4.5.1 wurde bereits erläutert, über welche Wege die OSM-Datenbank aktualisiert werden kann. In diesem
Abschnitt wird dargestellt, wie der eigentliche Prozess des Mappings konkret abläuft, und welche Probleme damit
verbunden sind. Des Weiteren soll betrachtet werden, wie man diesen Vorgang automatisieren kann.
73
Kapitel 4
OpenStreetMap
4.6.1 Erfassung
Die Erfassung oder Korrektur einer bestimmten Gegend beginnt damit, die relevanten Straßen oder andere
interessante Objekte mit dem GPS-Gerät zu erfassen. Evtl. sind manuelle Notizen sinnvoll, um die Aufzeichnungen
später nachvollziehen zu können. Wie bereits in Kapitel 4.2.4 dargelegt, wird zur Genauigkeitssteigerung empfohlen,
eine Messung mehrfach und an verschiedenen Tagen durchzuführen. Der Nutzer muss beim Erfassen manuell die
neue Straße einmitteln. Dadurch sollen Schwankungen des GPS-Systems berücksichtigt werden.
Mit entsprechender Software werden die Daten aus dem GPS-Gerät in den Rechner übertragen. Als Format für die
Weiterverarbeitung bietet sich GPX30an, da es von den meisten Programmen verstanden wird und auch auf den Server
von OSM geladen werden kann. Es existieren die verschiedensten Programme, um aus den unterschiedlichen
Aufzeichnungstypen GPX-Dateien zu erzeugen. Allen voran GPSBabel [GPS10] . Das Hochladen der eigenen
Aufzeichnungen wird von den OSM Machern empfohlen [Ram09] . Damit kann nachgewiesen werden, dass z.B. eine
Straße manuell erfasst und nicht aus urheberrechtlich geschütztem Material abgezeichnet worden ist.
4.6.2 Editoren
Die manuelle Aktualisierung der Geodaten geschieht mit einem der vorhandenen Editoren. Die Programme dienen als
Benutzerschnittstelle zur zentralen OSM-API. Sie sind teilweise recht unterschiedlich gestaltet und haben andere
Bedienkonzepte. Die prinzipielle Funktionsweise ist jedoch bei allen Vertretern ähnlich. Zum einen besteht die
Möglichkeit die erwähnten GPX-Dateien zu laden und zum anderen können die aktuellen Roh-Daten über die OSM-API
angezeigt werden. Je nach Editor stehen Anzeigemöglichkeiten für Luftbilder oder andere Hilfen zur Verfügung.
Aufgabe des Benutzers ist anhand seiner
Aufzeichnungen die Korrekturen vorzunehmen.
Dies umfasst hauptsächlich das Erstellen,
Manipulieren oder Löschen von Knoten und Wegen,
sowie die Vergabe oder Korrektur von Tags. Bei der
Erstellung von Wegen ist zu berücksichtigen, dass
nicht überall da, wo das GPS-Gerät einen Punkt
erfasst hat, auch ein Knoten gesetzt werden muss.
Bei geraden Strecken genügen entsprechend zwei
Punkte - am Anfang und am Ende. Außerdem sind
Abb 4.9: Java OpenStreetMap Editor (JOSM)
kleinere Abweichungen des GPS-Geräts bei
Geraden zu vernachlässigen. Stehen mehrere Messungen zur Verfügung, so muss der Mapper manuell den neuen
Weg ausmitteln, um die GPS-Tracks möglichst optimal anzunähern. Dies kann man an Abb 4.9 gut erkennen. Gelb und
rot stellen jeweils Wege dar. Die GPS-Tracks sind in Cyan gehalten. In der Praxis stehen Editoren wie JOSM,
Merkaator, Potlatch und Vespucci zur Verfügung. Letzterer ist ein mobiler Editor der auf der Arbeit von [Bra09] basiert.
Es handelt sich um ein Prorgramm für das Android Betriebssystem mit einem im Vergleich zu den vorgenannten
Editoren eingeschränkten Funktionsumfang. Dennoch demonstriert das Projekt die Möglichkeiten der mobilen Nutzung
und Aktualisierung der OSM-Datenbank.
30
GPX: GPS Exchange Format. Es definiert drei Datentypen: Punkte, erfasste Tracks und manuell erstellte Routen.
74
Kapitel 4
OpenStreetMap
4.6.3 Linienvereinfachung
Eine Technik, die auch bei den Editoren zur Anwendung kommt, ist die Linienvereinfachung (engl. Line Simplification).
Aufgabe ist es einen komplexen Linienverlauf anhand vorgegebener Qualitätsmerkmale so zu vereinfachen, dass der
ursprüngliche Verlauf bestmöglich angenähert wird. Der in [Tay00] beschriebene Ansatz nach Douglas und Peucker,
ist das bekannteste Verfahren dieser Art. Im Rahmen des OSM-Projekts finden derartige Algorithmen Anwendung bei
der Reduktion von GPS-Aufzeichnungen auf die wesentlichen Stützpunkte.
Der Ansatz, basiert darauf, eine komplexe Strecke
maximal zu vereinfachen um sie im Anschluss, so
lange wieder zu verfeinern, bis ein definierter
Toleranzwert
unterschritten
wird.
Als
Ausgangssituation wählt man Start und Endpunkt einer
Strecke als Lösung. Danach, wird aus allen Punkten
der ursprünglichen Strecke derjenige gesucht,
Abb 4.10: Vereinfachung nach Douglas und Peucker,
welcher den maximalen Abstand zur Start-EndeQuelle: [Wik09]
Strecke hat. Ist der Abstand kleiner als die definierte
Toleranz, ist der Algorithmus beendet, andernfalls wird die Strecke an dem gefunden Punkt aufgeteilt und mit den
beiden entstandenen Teilstrecken beginnt der Vorgang rekursiv von vorne.
4.7
Mobile Karten-Nutzung
Eine nicht nur im Kontext dieser Arbeit wichtige Betrachtung ist die Frage, nach der Tauglichkeit von OSM zur mobilen
Nutzung. Auch für Navigation und Routing spielt dies eine wichtige Rolle. Daher stellen Navigationssysteme ähnliche
Anforderungen, wie sie an eine automatisierte, mobile Kartenerfassungslösung gestellt werden. An dieser Stelle wird
ein Vergleich gewagt zwischen Techniken, wie sie in gewöhnlichen Navigationssystemen angewandt werden und den
Möglichkeiten die OSM, sowie andere Online-Kartendienste derzeit bieten. Grundsätzlich stoßen zwei unterschiedliche
Ansätze aufeinander. Während auf der einen Seite klassische mobile Navigationsgeräte einen strengen Offline-Ansatz
verfolgen, also ohne jegliche Netzwerkverbindung arbeiten, sind auf der anderen Seite die meisten vorhandenen
internetbasierten Systeme von einer beständigen Verbindung abhängig.
4.7.1 Offline-Verfahren
Wer heute ein Navigationssystem kauft, ob als mobiles Gerät oder fest in einem Fahrzeug verbaut, erwirbt auch
gleichzeitig das aktuelle Kartenmaterial des jeweiligen Herstellers. Dieses wird meist in Form proprietärer Binärformate
direkt im Speicher des Gerätes vorgehalten. Aktualisiert werden kann es oft nur durch den Kauf neuer Karten, die mit
Hilfe eines Computers auf das Navigationssystem übertragen werden. Bei festeingebauten Geräten werden meist
Karten-DVDs verwendet.
Um ein solches System zu nutzen gibt der Nutzer sein Ziel ein. Daraus wird mit Hilfe eines Algorithmus auf Basis der
lokal vorhandenen Daten und dem aktuellen Standort die gewünschte Route berechnet. Sowohl die Routenführung als
auch das Erstellen der Grafikausgabe erfolgt direkt im Gerät. Anhand der Daten und der Route berechnet das
Navigationssystem auch alle notwendigen Ansagen für die Sprachausgabe oder zur Anzeige auf dem Bildschirm. Eine
Netzwerkverbindung wird zu keinem Zeitpunkt benötigt.
75
Kapitel 4
OpenStreetMap
Bewegt sich der Nutzer abseits der vorgegebenen Strecke, etwa auf einer anderen Straße, kann dies mit Hilfe von
Street Matching Verfahren (siehe Kapitel 3.7.2) erkannt werden. Daraufhin berechnet das Navigationsgerät meist
automatisch eine neue Route.
Für verschiedene GPS-Empfänger werden, aus den OSM-Daten berechnete, Binär-Dateien angeboten. So z.B. für
verschiedene Garmin-Modelle [OSM10c] . Somit ist in diesem Fall auch mit den OSM-Daten eine Offline-Nutzung
möglich.
4.7.2 Online-Verfahren
Systeme, die Kartendienste im Internet für eine Navigation nutzen, arbeiten anders. Dies beginnt bei der
Kartendarstellung. Da keine Geodaten lokal vorgehalten werden, kann die Grafik nicht selbständig erstellt werden. Die
Karten müssen aus dem Internet geladen werden. Hierzu bedient man sich der bereits bestehenden Kachel-Server,
wie sie z.B. OSM anbietet. Daraus resultiert eine optisch ansprechende zweidimensionale Kartendarstellung, wie sie
selbst von dedizierten Navigationsgeräten kaum geboten wird. Außerdem wird so die höchstmögliche Aktualität
gewährleistet. Es setzt aber auch einen durchgehenden Kontakt zum Server voraus.
Die zweite Ursache für die Notwendigkeit einer ständigen Internetverbindung ist ebenfalls der Tatsache geschuldet,
dass keine Daten auf dem Gerät vorgehalten werden. Hierdurch ist es nicht möglich, eine Route direkt auf dem Gerät
zu berechnen. Für diesen Zweck werden Dienste verwendet, die im Netz bereitstehen, z.B. www.openrouteservice.org.
Mit Hilfe von Start- und Zielkoordinaten kann ein solcher Webservice auf Basis seiner eigenen Kartendaten den Verlauf
der Strecke berechnen (vgl. [Ram09] ) . Der Verlauf wird in Form einer sortierten Koordinatenliste an das
Navigationsgerät übertragen, welches die Route den angezeigten Kartenkacheln überlagert. Eine Übermittlung der
relevanten Ansagen erfolgt meist nicht oder kann vom Gerät nicht verarbeitet werden. Abb 4.11 zeigt besonders gut
die Überlagerung der Karte mit einer Route. Bei einem Verbindungsabriss, wird die Route weiter im Speicher gehalten,
die Karten sind je nach Implementierung nicht mehr verfügbar.
Ein Street Matching abseits der berechneten Route ist nicht möglich. Dies führt oftmals dazu, dass die Position relativ
zur Karte falsch angezeigt wird.
Mit [sko10] steht ein zurzeit sehr erfolgreiches Navigationsprodukt zur Verfügung, das komplett auf OSM setzt.
Abb 4.11: Kartendarstellung eines Online-Navigationsprogramms
vor und nach Abriss der Netzwerkverbindung, Quelle: iPhone Anwendung xGPS
76
Kapitel 4
OpenStreetMap
4.7.3 Hybride Ansätze
Die Vereinigung der beiden Ansätze ist der Versuch die Vorteile beider Welten zu kombinieren. Es wird versucht, die
Geodaten bzw. Kartenkacheln auf intelligente Weise lokal auf dem Gerät vorzuhalten, um bei Abbruch einer
Internetverbindung normal weiterarbeiten zu können. Sobald die Verbindung wieder verfügbar ist, werden die Daten
aktualisiert oder ergänzt. Für die Kartendarstellung ist dies möglich und wird bereits von verschiedenen Produkten in
dieser Weise eingesetzt.
Für die Routenberechnung hingegen besteht das Problem, dass die Daten des gesamten gewünschten
Einzugsgebiets vorgehalten werden müssen, so z.B. für ganz Deutschland. Sonst könnte z.B. keine Route von
München nach Hamburg bestimmt werden. Der Transfer dieser großen Datenmenge (z.B. Deutschland benötigt
komprimiert etwa 800 MB) ist jedoch nur bedingt in kurzer Zeit über mobile Schnittstellen realisierbar. Ein Ansatz ist die
Einführung verschiedener Detailstufen auf Ebene der Rohdaten, wie sie auch bei den Kartengrafiken bereits Stand der
Technik ist. So reicht es unter Umständen aus, für eine grobe Routenberechnung nur die Autobahnen und
Bundesstraßen vorzuhalten. Ein Auszug der deutschen Autobahnen aus der OSM-Datenbank hat komprimiert etwa
eine Größe von 6 MB, was unter Berücksichtigung heutiger mobiler Breitbandzugänge vertretbar ist. Nur für die jeweils
aktuelle Position und die Zielumgebung werden Geodaten mit allen Details geladen. Um für diese lokalen Bereiche
Rohdaten im Voraus zu laden bedient man sich sogenannter Precachingstrategien, wie sie in [Ott09] vorgestellt
werden. Es handelt sich um kachelbasierte Verfahren, bei denen ein ähnliches Raster verwendet wird, als bei den
Kartengrafiken (siehe Kapitel 4.4). Es wird versucht, mit einfachen Annahmen, wie die Berücksichtigung von Position
und Fahrtrichtung, eine Vorhersage der notwendigen Kacheln zu treffen. Anhand geometrischer Formen werden die
entsprechenden Kacheln selektiert. Wie in Abb 4.12 dargestellt, kommen beispielsweise rechteckige, kreisförmige
oder ellipsoide Auswahlstrategien zur Anwendung.
Abb 4.12: Unterschiedliche Kachelselektionsstrategien bei Precachingverfahren
77
Teil II
Konzept und Durchführung
Kapitel 5
Konzept
In den vorherigen Kapiteln wurden die Grundlagen vorgestellt, die für die Umsetzung der Aufgabenstellung als
notwendig erachtet werden. In diesem und den folgenden Abschnitten werden die Lösungen für die einzelnen
Teilaufgaben erarbeitet. Zunächst konzeptionell und im Anschluss konkret in Hinblick auf Realisierung und Evaluation.
5.1
Vorüberlegung
Das Ziel dieser Arbeit ist die Entwicklung eines Systems zur automatisierten mobilen Kartenerfassung, welches eine
verbesserte Methode zur Bestimmung der GPS-Position als Grundlage verwendet. Als Datengrundlage soll OSM
dienen. Um diesen Zweck zu erfüllen sind verschiedene Arbeitsschritte notwendig.





Nutzung geeigneter Methoden zur Verbesserung der Positionierungsgenauigkeit
Lokale Vorhaltung der OSM-Daten
Mapping neuer Straßen
Aktualisierung der OSM-Datenbank
Darstellung der Ergebnisse
Für die einzelnen Teilaspekte sind die verwendeten Methoden zu definieren, welche in der Implementierung zur
Anwendung kommen. Beim Entwurf der Systemarchitektur sind die Qualitätskriterien Erweiterbarkeit und Portierbarkeit
zu berücksichtigen, damit eine spätere Umstellung auf andere Betriebssysteme oder die Ergänzung neuer Fähigkeiten
erleichtert wird.
Die wichtigste Frage ist, wie die Geodaten vorgehalten werden können. Voraussetzung ist der Zugriff auf die OSM-API.
Es ist eine Schnittstelle zu schaffen, die es ermöglicht OSM-XML-Daten zu laden und in eine lokale Datenbank
aufzunehmen. Der Zugriff erfolgt kachelbasiert in einem zu definierenden Raster.
Aufgrund der Vielzahl an untersuchten Methoden zur Verbesserung der GPS-Position, muss entschieden werden,
welche Verfahren im Rahmen dieser Arbeit tatsächlich umgesetzt werden.
79
Kapitel 5
Konzept
Ein mobiler Internetzugang steht ein über ein Mobiltelefon zur Verfügung. Auch wenn bei einer verfügbaren UMTSVerbindung Geschwindigkeiten bis zu 3,6 MBit/s und mehr möglich sind, wird in der Entwicklung berücksichtigt, dass
in ländlichen Gegenden mit geringerer Breitbandabdeckung maximal 200 KBit/s realistisch erscheinen. Gerade in
diesen Gebieten ist die OSM-Abdeckung oft unvollständig.
5.2
Architektur
Um die Anforderungen Portierbarkeit und Erweiterbarkeit zu berücksichtigen, orientiert sich die Entwicklung an einem
Framework für eingebettete mobile Systeme, das im Rahmen des InCarMultimedia Labors erfolgreich eingesetzt wird.
Die Grundkonzepte sind in [Wie05] beschrieben. Es handelt sich um einen komponentenbasierten Ansatz, bei dem
autonome Softwaremodule für jeweils spezifische Aufgaben entwickelt werden. Die Kommunikation untereinander
erfolgt über Ereignisnachrichten, sogenannte Events. Die Übertragung von Events erfolgt ausschließlich asynchron,
also ohne blockierende Aufrufe.
Das Framework dient zur Abstraktion der Betriebssystemfunktionalitäten und ermöglicht eine schnelle Implementierung
unter Einhaltung eines einheitlichen Aufbaus. Ergänzt wurde das Konzept um eine Variante des Oberserver Patterns,
wie es in [Wik10h] erklärt wird. Eine Komponente A ist dadurch in der Lage, sich bei einer Komponente B für ein
spezifisches Event E anzumelden. Komponente A wird von nun an immer benachrichtigt, wenn Ereignis E auftritt und
kann entsprechend darauf reagieren. Die Grundbestandteile einer Komponente sind:
 Eine Warteschlange zur Bearbeitung von anstehenden Nachrichten
 Eine Schnittstelle zur Eventanmeldungen und zum Auslösen von Events
 Eine Routine zum Bearbeiten von empfangenen Events
5.3
Positionsverbesserung
Aus den vorgestellten und evaluierten Methoden zur Verbesserung der Positionsbestimmung eignen sich nur wenige
für die Anwendung innerhalb dieses Projekts. Geräte, die eine Trägerphasen-Verarbeitung erlauben, stehen in diesem
Projekt nicht zur Verfügung. Dadurch kann ein Verfahren auf dieser Basis nicht eingesetzt werden. Die durchgeführten
Recherchen zeigten jedoch, dass dieses Verfahren den aktuellen Stand der Forschung wiederspiegelt und die zurzeit
bestmöglichen Resultate erzeugt. Auch Street Matching kann nicht zur Positionsverbesserung angewandt werden, da
dies z.B. bei der Neuerfassung einer Straße per Definition nicht möglich ist.
Von der Nutzung dedizierter GPS-Empfängern als Referenzempfänger für eine Differenzposition wird aufgrund der
schwankenden Ergebnisse abgesehen. Außerdem wäre eine zusätzliche Infrastruktur notwendig, die die
Korrekturvektoren bereithält und übermittelt.
Als verwendbare Verfahren kommen das codephasenbasierte DGPS zur Korrektur systembedingter
Positionsabweichung und die Positionsmittelung zum Ausgleich lokaler Störeinflüsse in Frage.
5.3.1 Codephasen-DGPS
Da die Umsetzung einer DGPS-Referenzstation einen hochgenau vermessenen Lagefestpunkt, sowie den Einsatz
leistungsfähiger Hardware voraussetzt, wird auf den Betrieb einer eigenen Station verzichtet. Stattdessen können die
vorhandenen und bereits erfolgreich getesteten Referenzdienste EGNOS und SAPOS genutzt werden. Der
80
Kapitel 5
Konzept
Schwerpunkt wird in der Praxis auf der Nutzung von EGNOS liegen, da es sich beim SAPOS um ein kostenpflichtiges
Angebot handelt. Mit den vorhandenen Empfängern sind bei beiden Anbietern in etwa gleiche Ergebnisse zu erwarten.
Der Zugriff erfolgt mit Hilfe des Protokolls Ntrip. Ein entsprechendes Modul steht bereits zur Verfügung. Bei den
praktischen Untersuchungen betrug die verwendete Bandbreite zwischen einem und zehn Kbit/s und kann somit
vernachlässigt werden. Für die prototypische Implementierung ist zu berücksichtigen, dass derzeit nur zwei
Empfänger vorhanden sind, die Korrekturdaten über die Hardware-Schnittstelle entgegen nehmen können.
5.3.2 Positionsmittelung
Zur Korrektur lokaler Störeinflüsse wird das Verfahren der Mittelwertbildung aus mehreren GPS-Empfängern
angewandt. Die Empfänger sollen verteilt über das gesamte Fahrzeug montiert werden, um gegenseitige
elektromagnetische Beeinflussungen zu vermeiden. Die relative Position der Empfänger ist herauszurechnen. Die
Fahrtrichtung ist zu berücksichtigen. Dies wird im Folgenden als Layout Korrektur bezeichnet.
Layout Korrektur
Das Prinzip des Verfahrens ist in Abb 5.1 dargestellt. Es werden zunächst die Parameter für die Fahrtrichtung 0°
festgelegt – also exakt Richtung Norden. Für jeden Empfänger werden Distanz und Azimut zu einem
Projektionszentrum ermittelt. Ein Empfänger, der sich im Projektionszentrum befindet muss folglich nicht korrigiert
werden.
Während der Fahrt wird aus allen erfassten GPS-Daten der mittlere Fahrtrichtungswinkel ermittelt. Im Anschluss daran
wird zur eigentlichen Layout Korrektur für jeden Empfänger eine Punktprojektion (siehe Kapitel 2.4.3) durchgeführt,
wobei als Winkel der Azimut plus der mittlere Fahrtrichtungswinkel verwendet wird. Als Projektionsabstand, dient die
zuvor ermittelte Distanz.
Abb 5.1: Prinzip der Layout Korrektur für unterschiedliche Fahrtrichtungen
Mittelwertbildung
Nach erfolgter Positionskorrektur für jeden einzelnen Empfänger ist es möglich, für beide Koordinaten-Komponenten
den arithmetischen Mittelwert zu bestimmen. Es ist zu berücksichtigen, dass nicht jeder Empfänger immer einen
gültigen Datensatz liefert. Wenn zu wenig Satelliten empfangen werden oder ein Empfänger den Almanach noch nicht
vollständig empfangen hat, ist keine Positionsbestimmung möglich.
Eine Erweiterung des einfachen Mittelwerts stellt der gewichtete Mittelwert dar. Hierzu wird jeder von den Empfängern
gelieferten Position eine Gewichtung zugeordnet. Die Gewichtung stellt ein Maß der Qualität des Signals dar. In der
Praxis kann entweder die Empfangsqualität eines Empfängers oder die DOP-Werte einer Positionsbestimmung
verwendet werden. Im Rahmen der Implementierung wird der Horizontale DOP-Wert Anwendung finden.
81
Kapitel 5
5.4
Konzept
Kartendaten
Um neue Straßen erfassen zu können, müssen zuerst die bestehenden Daten im System verfügbar gemacht werden.
Der Download erfolgt über die OSM-API. Zum Abruf wird die Methode „map‚ verwendet, welche alle notwendigen
Daten innerhalb einer übergebenen Bounding Box in Form eines XML-Dokuments zurückliefert.
Für eine strukturierte Speicherhaltung wird ein kachelbasiertes Raster definiert. Hierzu werden die räumliche
Ausdehnung einer Kachel (in Längen- und Breitengrad) und ein Adressierungsschema festgelegt. Dabei muss
berücksichtigt werden, dass sich die Datenmenge bei gleicher Kachelgröße für ländliche und städtische Gebiete
unterscheidet. Eine Kachel mit einer Fläche von drei Quadratkilometern benötigt für ein ländliches Gebiet ca. 0,4 MB
und für einen Innenstadtbereich ca. 1,8 MB. Zur Reduzierung der übertragenen Datenmenge, soll die HTTPKompression verwendet werden.
Damit die tatsächlich benötigten Daten auch zur Verfügung stehen, wenn zeitweilig keine Netzwerkverbindung besteht
muss das System neben der aktuell benötigten Kachel einen größeren Bereich im Voraus laden. Für diese Aufgaben
wurde eine prioritätsbasierte Precachingstrategie entwickelt. Prioritätsbasiert bedeutet, dass Kacheln nahe dem
Standpunkt eine höhere Priorität haben und somit früher geladen werden als Kacheln, die weiter von der aktuellen
Position entfernt sind. Als geometrische Grundlage wurde ein rechteckiger Bereich gewählt. Die Fahrtrichtung findet
zunächst keine Berücksichtigung, könnte aber in die weitere Entwicklung einfließen. In Abb 5.2 ist der Ablauf des
Precachings unter Berücksichtigung der Priorität skizziert. Beginnend von der aktuellen Kachel werden spiralförmig
weitere Bereiche ausgewählt und geladen.
Abb 5.2: : Prioritätsbasiertes Precaching
für eine rechteckige Fläche
5.4.1 Datenmodell
Ist eine Kachel in Form des XML-Dokuments geladen, müssen die Daten vor der Verwendung in das eigene
Datenmodell überführt werden. Dieser Vorgang wird als Parsen bezeichnet. Im Rahmen dieser Arbeit findet eine, im
Vergleich zum eigentlichen OSM-Datenmodell, vereinfachte Variante Anwendung. Zur Abgrenzung gegenüber dem
OSM-Modell werden anstelle von Wegen Kanten (engl. „Edge‚) verwendet. Relationen werden nicht berücksichtigt.
Ausschließlich das highway-Tag wird in Form eines Type-Attributes einer Edge zugedordnet. Andere Tags werden
nicht berücksichtig. Dieses Modell ist ausreichend, um die Anforderung der Straßenerfassung zu erfüllen.
Abb 5.3: Internes Datenmodell
82
Kapitel 5
5.5
Konzept
Automatisiertes Mapping
Dieser Abschnitt beschäftigt sich mit der Konzeption des automatisierten Mappings. Zunächst wird festgelegt, welche
Geodaten überhaupt erfasst werden sollen. Im Anschluss daran wird erörtert, wie das Mapping automatisiert werden
kann und welche Abläufe dafür notwendig sind.
5.5.1 Erfassbare Merkmale
GPS stellt für die prototypische Umsetzung die einzige Sensorik dar, die verwendet werden soll. Hinzu kommen die
OSM-Daten. Dadurch sind die Möglichkeiten der automatischen Erfassung von vornherein eingeschränkt. Als primäres
Ziel wird die Erfassung bisher nicht vorhandener Straßen festgelegt. Andere Merkmale, wie Points-of-Interest, können
auf diesem Wege per se nicht erfasst werden. Hierzu wäre eine Interaktion mit dem Benutzer erforderlich, was der Idee
eines automatisierten Mappings widerspräche.
Denkbar wäre, die Ableitung einer zulässigen Höchstgeschwindigkeit, aus den GPS-Datensätzen. Das würde
wiederum voraussetzen, dass sich Nutzer des Systems genau an die vorhandenen Begrenzungen halten.
Möglicherweise kann hier in Zukunft auf andere Komponenten im Fahrzeug zurückgegriffen werden, da immer mehr
Hersteller Systeme zur Verkehrsschilderkennung anbieten, um zugelassene Höchstgeschwindigkeiten oder
Überholverbote zu detektieren (vgl. [aut09] ). Die Daten einer solchen Technik sind als Quelle für ein automatisiertes
Mapping sehr gut geeignet.
Die per GPS ermittelte Geschwindigkeit kann jedoch für eine Klassifizierung der Straße verwendet werden, wie sie
OSM mit dem highway-Tag vorsieht. Da allerdings die Grenzen zwischen den unterschiedlichen Straßentypen in
Bezug auf die gefahrene Geschwindigkeit fließend sind, kann nur eine grobe Einteilung über dieses Kriterium erfolgen.
Folgende Staffelung kann als Orientierung angenommen werden:
Tag
motorway
primary
tertiary
road
empfohlene deutsche Entsprechung
Autobahn
Bundesstraße
Kreisstraße
noch nicht näher klassifiziert
Geschwindigkeitsbereich
>130 km/h
80-130 km/h
65-80 km/h
0-65 km/h
Tabelle 5.1: Grobe Einteilung in verschiedene highway-Tag-Klassen anhand der gefahrenen Geschwindigkeiten
OSM sieht keine fixen Entsprechungen zwischen Tag und tatsächlicher Straßenbezeichnung vor. Dies wird von Land
zu Land unterschiedlich gehandhabt. Die Straßen sollen rein aufgrund des Ausbauzustandes ausgezeichnet werden.
Um zu vermeiden, dass eine Landstraße versehentlich als Autobahn klassifiziert wird, ist die Grenze relativ hoch
gewählt.
Der Geschwindigkeitsbereich unter 65 km/h wird in Tabelle 5.1 als road gekennzeichnet. Das bedeutet, dass die
Straße nicht näher klassifiziert wurde und einer manuellen Aktualisierung bedarf. Dies rührt daher, dass in diesem
Geschwindigkeitsbereich sehr viele Klassifikationen zur Auswahl stehen und eine Einteilung nur anhand der
Geschwindigkeit nicht möglich ist.31 Es ist außerdem darauf zu achten, dass die Klassifikation nicht aufgrund
schwankender Geschwindigkeiten ständig gewechselt wird. Deshalb muss die Einteilung der Straße über größere
Abschnitte erfolgen und nicht von einem Messpunkt zum nächsten.
31
Z.B. residential, unclassified, living_street, service oder track (vgl. [Ram09] und [OSM10b] )
83
Kapitel 5
Konzept
Für den prinzipiellen Beweis der Machbarkeit eines automatisierten Mappings genügt es, im Rahmen der
prototypischen Implementierung generell auf eine nähere Klassifikation der Straße zu verzichten und prinzipiell nur das
road-Tag zu vergeben.
Einschränkungen
Bei der Anwendung eines automatisierten Mappings treten verschiedene Probleme auf. Daher müssen
Plausibilitätsprüfungen durchgeführt werden, bevor eine Aktualisierung stattfinden kann. Dazu werden im Folgenden
einige Beispiele erläutert:
 Bei Brücken kann nicht festgestellt werden, ob darüber hinweg oder darunter durch gefahren wurde. Ein
automatisiertes Mapping wird eine Kreuzung feststellen.
 Die Detektion von dediziertem Privatgrund ist nicht möglich. So können keine Einfahrten oder Parkplätze
erfasst werden. Evtl. muss eine Mindestgeschwindigkeit für die Erfassung vorgegeben werden.
 Sackgassen, die dicht an dahinterliegenden Straßen enden, könnten als Durchfahrtsstraßen erfasst werden.
Eine Lösung wäre, vor der Aktualisierung zu prüfen, ob tatsächlich eine Einfahrt in die andere Straße erfolgt.
 Ungenauigkeiten der Roh-Daten (siehe Kapitel 4.2.4) wirken sich direkt auf Ungenauigkeiten von Start- und
Endpunkt des Mappings aus
 Serpentinen sollten als solche erkannt werden, daher ist unter Umständen die Höhe zusätzlich zu
berücksichtigen.
5.5.2 Street Matching
Für diese Arbeit wurde ein zweistufiges Street Matching Verfahren entwickelt. Damit kann festgestellt werden, ob man
sich auf bzw. an einer Straße befindet oder nicht. Zunächst werden die relevanten Positionen ermittelt. Um den
aktuellen Standpunkt wird ein Rechteck aufgespannt, innerhalb dessen die Kandidatenmenge bestimmt wird. Für eine
grobe Auswahl werden zuerst die relevanten Kacheln ermittelt. Zusätzlich zur aktuellen Kachel müssen die acht
Umliegenden berücksichtigt werden. Die Auswahl erfolgt anhand einer Prüfung auf Überlappung (vgl. [Stö09a] )
zwischen Kachelgrenzen und untersuchtem Gebiet. Zur detaillierteren Selektion werden nach dem gleichen Prinzip die
Straßen in den verbleibenden Kacheln ausgewählt. Die resultierenden Kandidaten erhält man durch Abschreiten der
einzelnen Segmente der Straßen und einer Prüfung, ob sich die untersuchte Position innerhalb des
Kandidatenrechtecks befindet. Ist die Kandidatenmenge leer, war das Matching erfolglos. Andernfalls muss man aus
den ermittelten Positionen diejenige bestimmen, die einen niedrigsten Fehler aufweist, wenn man den Standpunkt
dorthin verschiebt.
Abb 5.4: Grundprinzip des Street Matching Verfahrens
84
Kapitel 5
Konzept
Dies stellt die zweite Stufe des Verfahrens dar. In der einfachsten Variante wird der vom Standpunkt aus nächste
Kandidat gewählt. Dies berücksichtigt nicht, welche Strecke bisher gefahren wurde. Hierfür muss der aufgezeichnete
GPS-Track untersucht werden. Für eine bestimmte Anzahl bisheriger Positionen wird für die Verschiebung ermittelt, wie
groß der Abstand zur nächstgelegenen Straße ist. Der Kandidat für den die Summe der Abstände minimal ist, wird als
Match ausgewählt. Das Verfahren ist rechenintensiv, liefert aber gute Ergebnisse. Abb 5.4 veranschaulicht den
Prozess noch einmal. Man beachte, dass zum besseren Verständnis der Suchraum gegenüber den Kacheln zu groß
dargestellt ist.
5.5.3 Vorgehen
Als erster Schritt zur Erfassung einer neuen Straße muss festgestellt werden, ob man sich auf einer bereits im System
vorhandenen Straße befindet. Hierfür wird der vorgestellte Street Matching Algorithmus verwendet. Sobald man den
erfassten Bereich verlässt und kein Street Matching mehr möglich ist, beginnt die Erfassung einer neuen
Aufzeichnung. Es wird so lange aufgezeichnet, bis das System wieder eine Position auf einer bereits bestehenden
Straße feststellt.
Abb 5.5: Prinzip der Vereinfachung einer GPS-Aufzeichnung
Da die GPS-Daten jede Sekunde eine neue Koordinate liefern, ist die Aufzeichnung zu komplex, um als Straße in die
Datenbank aufgenommen zu werden. Die Aufzeichnung wird deshalb einem Vereinfachungs- und Kontrollprozess
unterzogen, der folgende Schritte durchführt:
 Vereinfachung gerader Linien zu Strecken mit einem Start- und einem Endpunkt. Hierfür müssen
entsprechende Abweichungstoleranzen definiert werden.
 Auflösen von Punktwolken bei Fahrzeugstillstand zu einem einzigen Punkt.
 Auflösen von Stichstraßen, Sackgassen oder anderen Szenarien, bei denen Wege während der
Aufzeichnung mehrfach verwendet werden.
 Prüfung der Straßen anhand von Plausibilitätskriterien.
Abb 5.6: Ablauf des automatisierten Mappings
85
Kapitel 5
Konzept
Ist dieser Vorgang vollzogen, kann die Straße in die Datenbank aufgenommen werden. Unter Umständen sind neue
Abzweigknoten in bestehende Wege einzubringen, bevor die eigentliche Aktualisierung durchgeführt werden kann. Als
Position dieser Knoten werden die Punkte definiert, bei denen das Street Matching Verfahren zuletzt noch (Start der
neuen Straße) bzw. zuerst wieder (Ende der neuen Straße) einen Match festgestellt hat. Abb 5.6 stellt den prinzipiellen
Ablauf dar.
Plausibilitätskriterien
Als Prüfungskriterien für eine Aktualisierung der Datenbank mit der aufgezeichneten Strecke werden folgende Punkte
festgelegt:
 Minimale Länge einer Strecke
 Minimale Geschwindigkeit
Durch die Festlegung einer Mindestlänge werden kurzzeitige Unterbrechungen eines gültigen Matchings nicht
berücksichtig. Diese treten bei ungenau erfassten Straßen häufig auf. Die Mindestgeschwindigkeit dient zum
Vermeiden der Kartierung von Bereichen in denen langsam gefahren wird und deren automatische Erfassung nicht
sinnvoll ist, wie z.B. größere Parkplätze.
5.5.4 Aktualisierung
Zum Übertragen einer neuen Straße in die OSM-Datenbank sind drei Schritte notwendig. Der Aktualisierungsvorgang
wird mit einem einzigen osmChange-Aufruf durchgeführt, wie er in Kapitel 4.5.1 beschrieben wurde. Zunächst werden
alle Punkte der Strecke erzeugt. Anschließend wird ein Weg erstellt, der alle Punkte enthält.
Zur Anbindung an das bestehende Straßennetz müssen der erste und der letzte Punkt den jeweils zugehörigen
Straßen an der richtigen Stelle eingefügt werden.
5.6
Kommunikationsmodell
Für die vorgestellte Aufgabenstellung bieten sich zwei verschiedene Kommunikationsmodelle an. Im ersten Modell
kommuniziert jedes einzelne System direkt mit der OSM-API und nimmt Änderungen vor. Im zweiten Modell übernimmt
eine zentrale Instanz in Form eines Proxy-Servers die Kommunikation mit der OSM-API.
5.6.1 Proxy
Der Vorteil eines zentralen Ansatzes ist die Möglichkeit, die Erfassung einer Straße und weiterer Merkmale erst bei
Vorliegen mehrerer GPS-Aufzeichnungen durchzuführen. Dadurch kann eine Mittelung der erfassten geographischen
Lage und der für eine Klassifizierung notwendigen Geschwindigkeit (siehe Kapitel 5.5) durchgeführt werden. Des
Weiteren kann auf diesem Wege eine absichtlich oder unabsichtlich fehlerbehaftete Aktualisierung wirksam verhindert
werden. Dies setzt jedoch die Vorhaltung einer Server-Infrastruktur voraus. Außerdem wird die für eine Mittelung
notwendige kritische Masse an Teilnehmern zu Beginn nicht erreicht und es würde lange dauern, bis Änderungen in
die Datenbank publiziert werden.
Aus diesen Gründen wird das Verfahren vorerst nicht weiter verfolgt.
86
Kapitel 5
Konzept
5.6.2 Direkte Kommunikation
Kommuniziert das System direkt mit der OSM-Datenbank, können Änderungen sofort wirksam werden. Die
Änderungen stehen anderen Nutzern augenblicklich zur Verfügung. Die Implementierung eines Prototyps wird
außerdem deutlich vereinfacht. Um jedoch keine falsche Klassifikation einer Straße mangels ausreichend genauer
Geschwindigkeitsdaten zu erfassen, wird auf die vorgeschlagene Einteilung in Kapitel 5.5.1 verzichtet und in der
prototypischen Implementierung nur der Tag highway=road vergeben.
5.7
Zusammenfassung
Nachdem die wichtigen Arbeitsschritte erläutert sind, sollen nun die Komponenten festgelegt werden, die
implementiert werden müssen. Das System wird aus nur einer Anwendung bestehen, die alle Funktionalitäten
beinhaltet. Für die Bereitstellung der DGPS Korrekturdaten wird ein externes Modul verwendet, das neben der
eigentlichen Anwendung läuft. Zur Umsetzung des Konzepts ist es notwendig eine Rahmenumgebung zu
implementieren, in der die Komponenten betrieben werden. Neben diesem Framework müssen auch
Basisfunktionalitäten zur Verwaltung von Karteninhalten bereitgestellt werden. Die grafische Ausgabe erfolgt über eine
eigene Komponente. Abb 5.7 gibt einen Überblick über das Gesamtsystem.
5.7.1 Positionserfassung
Für die Positionserfassung werden zwei Module entwickelt. Das erste Modul dient der Verarbeitung der eingehenden
NMEA-Datensätze eines einzelnen GPS-Empfängers. Dies beinhaltet die Erfassung der Koordinaten sowie der
Informationen über die Qualität der aktuellen Satellitenkonstellation. Für jeden verwendeten GPS-Empfänger wird eine
eigene Komponente benötigt. Das zweite Modul hat die Aufgabe die Daten der einzelnen Empfänger zu sammeln und
die Mittelung durchzuführen. Sind neue Positionsdaten verfügbar, wird dies im System mittels eines Events bekannt
gegeben.
5.7.2 Kachelverwaltung
Eine zentrale Komponente übernimmt die Verwaltung der Kacheln, dazu gehört das Bereithalten der entsprechenden
Kacheln im lokalen Zwischenspeicher, welche durch die Precachingstrategie bestimmt werden.
Die Verbindung mit der OSM-Datenbank übernimmt eine eigene Kommunikations-Komponente, die auch für die
Durchführung der Aktualisierungen zuständig ist. Ist eine Kachel erfolgreich vom OSM-Server geladen, wird sie in den
Speicher geladen. Diese Aufgabe übernimmt ein Parser-Modul.
5.7.3 Mapping
Die beiden letzten Komponenten sind der Street Matcher und das Mapping Modul. Die Street Matcher-Komponente
prüft bei jedem Positionsupdate, ob ein erfolgreiches Matching durchgeführt werden kann. Ist dies nicht mehr der Fall,
wird ein Event ausgelöst. Ebenso, wenn ein Matching wieder möglich ist. Auf Basis dieser Events führt das Mapping
Modul das beschriebene Kartenerfassungsverfahren durch. Ist eine Kartenaktualisierung durchzuführen, wird diese
der Kommunikationskomponente übergeben.
87
Kapitel 5
Konzept
Abb 5.7: Übersicht über die Komponenten
88
Kapitel 6
Implementierung
Im Rahmen der Implementierung mussten zahlreiche Komponenten, Klassen und Algorithmen entwickelt werden.
Dieses Kapitel gibt einen Überblick über den erstellten Prototypen. Zunächst folgen einige allgemeine Aspekte zur
Entwicklungsumgebung und zur Hardwareanbindung. Danach werden verwendete Bibliotheken dargestellt und der
Grundaufbau der realisierten Komponentenstruktur aufgezeigt. Zum Abschluss werden die wichtigsten Komponenten
untersucht. Das Hauptziel dieses Abschnitts soll sein, wichtige Problemfelder aufzuzeigen, die in der praktischen
Umsetzung des Konzepts entstanden sind.
6.1
Entwicklungsumgebung
Die Entwicklung wurde auf einem Dual-Core Rechner mit 2,0 GHz Taktfrequenz und 2 GB Arbeitsspeicher
durchgeführt. Als Plattform für die Entwicklungs- und Zielumgebung wurde Ubuntu 9.04 ausgewählt. Die Entwicklung
erfolgte mit C++ unter Eclipse. Dies ermöglichte die Verwendung von bereits vorhandenen Komponenten. So standen
zu Beginn Komponenten zur Darstellung einer Kartengrafik und zum Import von OSM-Daten zu Verfügung. Außerdem
konnten wichtige Klassen zur Abstraktion von Betriebssystemfunktionalitäten wiederverwendet werden. Diese stammen
aus dem in Kapitel 5.2 erwähnten Framework des InCarMultimedia Labors.
6.2
Hardwareanbindung
Ein mobiler Internetanschluss wurde zu Testzwecken über eine Bluetooth-Verbindung zu einem Mobiltelefon realisiert.
Die Anbindung der GPS-Empfänger erfolgte per USB mit Hilfe eines einzelnen USB-Hubs.
Während der Tests kam es bei der Verbindung zu den GPS-Geräten immer wieder zu Problemen. Nach mehrmaligem
starten und beenden des Systems verweigerten die Empfänger ihren Dienst. Der Effekt trat auch auf, als mit anderen
Programmen eine Verbindung mehrmals auf und abgebaut wurde. Eine Ursache für dieses Verhalten konnte bisher
nicht gefunden werden. Die Lösung brachte eine Umstellung der Anbindung von der direkten Nutzung der seriellen
Schnittstelle auf eine Socket Verbindung, die der gpsd-Dienst unter Linux bereitstellt (vgl. [Ubu09] ). Es handelt sich
um einen Daemon, also einen Hintergrunddienst, der eine dauerhafte Verbindung zu den GPS-Empfängern aufbaut
und diese jeweils über eigene Ports anbietet, auf die per TCP/IP zugegriffen werden kann. Dadurch wird erreicht, dass
89
Kapitel 6
Implementierung
sich mehrere Programme einen GPS-Empfänger teilen können. Viele GPS-fähige Programme unter Linux sehen die
Verwendung des gpsd-Daemon vor. Durch diese Konstellation wird außerdem der parallele Betrieb mit dem
Programm NtripClient ermöglicht, mit dessen Hilfe die DGPS-Korrekturdaten in die Empfänger eingespielt werden.
6.3
Bibliotheken
Während der Entwicklung kamen verschiedene externe Bibliotheken zur Anwendung, um die Implementierung von
Standardfunktionalitäten, wie den Abruf von Webinhalten oder das Parsen eines XML-Dokuments, zu vereinfachen.
Alle verwendeten Funktionsbibliotheken sind frei verfügbar und im Quellcode einsehbar. Darüber hinaus sind sie für
alle gängigen Betriebssysteme verfügbar.
6.3.1 cURL
cURL bzw. libcurl ist eine Bibliothek zur Kommunikation auf Basis von Internetprotokollen. Unterstützt werden u.a.
HTTP, FTP, TELNET oder SMTP. Für die Implementierung kamen die HTTP-Fähigkeiten zur Anwendung. cURL
unterstützt mit GET, PUT und POST alle HTTP-Methoden, die für eine Kommunikation mit der OSM-API notwendig sind.
Wie in Listing 6.1 dargestellt, gestaltet sich die Verwendung sehr einfach. Es müssen zunächst einige grundsätzliche
Parameter gesetzt und ein Speicherbereich für die zu empfangenen Daten übergeben werden (z. 5-7). Danach kann
man den Aufruf durchführen (z. 8). Die gesetzten Parameter sind über den Aufruf hinaus gültig. Details findet man in
[cUR10] .
5
10
char m_Buffer[10000];
CURL *m_ptrCurl;
…
char url[100]= "http://www.openstreetmap.org/api/0.6/node/91575879";
…
curl_easy_setopt(m_ptrCurl,CURLOPT_WRITEDATA, m_Buffer);
curl_easy_setopt(m_ptrCurl,CURLOPT_ENCODING,"gzip");
curl_easy_setopt(m_ptrCurl,CURLOPT_URL,url);
…
curl_easy_perform(m_ptrCurl);
Listing 6.1: Beispiel eines cURL-Aufurfs.
Bei den Methoden PUT und POST werden im Gegensatz zu GET auch Daten an den Server geschickt. Hierzu stehen
verschiedene Funktionen bereit, welche die zu übertragenden Informationen an die Bibliothek zu übergeben.
Außerdem wird HTTP-Authentifizierung unterstützt.
6.3.2 libXML
Die libXML stellt Methoden zum Parsen und Ausgeben von XML-Dokumenten bereit. Es steht unter anderem ein
sogenannter SAX-Parser (Simple API for XML) zur Verfügung, also ein Parser, der XML sequentiell abarbeitet, sowie
ein baumorientierter DOM-Parser (Document Object Model), welcher in der Entwicklung verwendet wurde. Die
Unterschiede zwischen den Typen können in [Stö09b] nachgelesen werden. Die DOM-Variante hält alle notwendigen
Funktionen zur Navigation in der Dokumentenstruktur und zum Auslesen der Daten bereit.
90
Kapitel 6
Implementierung
6.3.3 GeographicLib
Zur Durchführung verschiedener Operationen mit geographischen Koordinaten wurde die GeographicLib
eingebunden. Sie besteht aus einer kleinen Anzahl von C++-Klassen, welche neben den in Kapitel 2.4 vorgestellten
Berechnungen die Konvertierung zwischen verschiedenen Koordinatensystemen und Projektionen unterstützt (vgl.
[Kar10] ). Im Projekt wurden die beiden Methoden „Direct‚ und „Inverse‚ verwendet. Direct führt eine Punktprojektion
durch, Inverse berechnet den Abstand zwischen zwei gegebenen Punkten.
Geodesic::Direct(float lat1, float lon1, float azi1, float s12, float
&lat2, float &lon2, float &azi2, float &m12, bool arcmode=false)
5
Geodesic::Inverse(float lat1, float lon1, float lat2, float lon2, float
&s12, float &azi1, float &azi2, float &m12)
Listing 6.2: GeographicLib-Aufrufe zur Punktprojektion und zur Abstandsberechnung
6.3.4 OpenGL
Die grafische Ausgabe ist mit OpenGL realisiert. Einer „Spezifikation für eine plattform- und
programmiersprachenunabhängige Programmierschnittstelle‚ [Wik10m] . Als konkrete Implementierung wird die
FreeGlut verwendet, eine frei verfügbare Bibliothek, welche die darunter liegenden OpenGL-Treiber-Aufrufe
abstrahiert.
6.4
Komponentenstruktur
Zur Erhaltung der Wartbarkeit wurde auf eine einheitliche Struktur der Komponenten Wert gelegt. Hierzu wurde die in
Kapitel 5.2 vorgestellt Architektur implementiert. Das Grundkonzept besteht zum einen aus Klassen zum Betrieb der
Komponenten und zum anderen aus Objekten zur Verwaltung, zur Verarbeitung und zum Austausch von Nachrichten.
6.4.1 Übersicht
Die Basisklasse, von der alle nachfolgenden Komponenten abgeleitet werden, ist CComponent. Grundsätzlich wird
jede Komponente in einem eigenen Thread betrieben. Hierzu wurde das Konzept von Thread Träger und Thread
Objekt verwendet, wie es in [Wie05] beschrieben ist. Für die Implementierung bedeutet das, dass jede Komponente
die IRunnable Schnittstelle realisieren muss. Zum Start eines Threads wird eine Instanz der Klasse CThread erzeugt,
welche die notwendigen Betriebssystemaufrufe durchführt. Bei der Erzeugung wird das IRunnable-Objekt übergeben.
Die Synchronisation der Kommunikation zwischen den Objekten wird durch Mutexe und Semaphoren abgesichert. Zur
Erzeugung und Verwaltung der einzelnen Komponenten wurde ein Administrationsobjekt erstellt. Über die statische
Methode „getComponent(…)‚ dieses Objekts erhält man Zugriff auf einzelne Komponenten. Einen Überblick über die
gesamte Struktur gibt Abb 6.1.
91
Kapitel 6
Implementierung
Abb 6.1: Basisklassen und Schnittstellen der Komponentenarchitektur, Darstellung vereinfacht
6.4.2 Events und Nachrichten
Als Container für Nachrichten dient die Klasse CMessage. Sie enthält neben einem Nachrichtentyp und den
Nachrichtendaten auch einen Schlüssel der den Absender identifiziert, sowie eine Priorität. Zur asynchronen
Kommunikation zwischen Komponenten wurden zwei Wege festgelegt. Jede Instanz von CComponent besitzt eine
Warteschlange für Nachrichten. Hierüber können Nachrichten direkt an eine bestimmte Komponente gesendet
werden.
Die zweite Möglichkeit besteht in der Übermittelung von Events (siehe Listing 6.3). Zum Anmelden und Auslösen von
Events wurde die Klasse CEventManager entwickelt. Damit eine Komponente ein konkretes Event einer anderen
Komponente erhält, muss sie sich bei deren EventManager mit der Funktion „attach‚ registrieren. Tritt ein Event ein,
wird in der „raiseEvent‚-Methode des EventManagers jede für das Event angemeldete Komponente durch Aufrufen
einer „handleEvent‚-Methode benachrichtigt.
m_gpsComponent->getEventManager()->attach(this,
CGPSDeviceEvents::POSITION_CHANGED);
5
CMessage msg(CGPSDeviceEvents::POSITION_CHANGED);
m_eventManager.raiseEvent(msg);
Listing 6.3: Anmelden und auslösen von Events
92
Kapitel 6
6.5
Implementierung
Geodatenverarbeitung
An dieser Stelle werden die Klassen erläutert, die für den Download, die Verarbeitung und Speicherung der Geodaten
zuständig sind. Der Abschnitt Repräsentation führt in die grundlegenden Klassen zur Speicherung der Daten ein. Im
anschließenden Kapitel Bereitstellung werden die Komponenten und Abläufe dargestellt, die den Zugriff auf die
Geodaten ermöglichen.
6.5.1 Repräsentation
Zentrales Element stellt die Kachel dar, repräsentiert durch die Klasse COSMTile. Sie dient der Speicherung des XMLDokuments und zur Vorhaltung der internen Datenstruktur, wie sie in Kapitel 5.4 vorgestellt wurde. Eine wichtige
Eigenschaft einer Kachel ist der Kachelstatus. Damit wird der aktuelle Zustand der Kachel beschrieben. Eine Kachel,
die gerade erzeugt wurde und noch keine Daten enthält, wird mit dem Status „new‚ gekennzeichnet. Werden gerade
die Daten von OSM heruntergeladen, wird der Status auf „downloading‚ gesetzt. Erst wenn der Kachelstatus „parsed‚
erreicht hat, sind die XML-Daten in das interne Datenmodell überführt und die Kachel kann benutzt werden.
Zur Speicherung von Knoten und Kanten dient die Klasse CMap, die die Datenelemente CEdge und CNode in Form
von zwei getrennten dynamischen Listen bereithält. Jede Instanz von CEdge hält intern eine weitere dynamische Liste
vor, die Referenzen auf die zugehörigen CNode-Objekte speichert. Jede Kachel hält für das von ihr abgedeckte
Gebiet eine eigene Instanz von CMap vor.
Abb 6.2: Klassen zur internen Repräsentation der Geodaten
Als Adressierungsschema der Kacheln wird das gleiche Schema verwendet, wie es auch für die Kacheln der Slippy
Map auf Zoom-Stufe 14 verwendet wird. Bezogen auf die durchschnittlich zu übertragende Datenmenge resultiert
daraus eine sowohl für den städtischen als auch für den ländlichen Bereich verwendbare Kachelgröße von 2,5 km².
Bei Verwendung der HTTP-Kompression müssen maximal 0,2 MB pro Kachel übertragen werden. Die Berechnung der
Kachelkoordinaten in Formel 6.1 basiert auf der Mercatorprojektion, die für das Rendern der Kacheln verwendet wird
(vgl. [OSM10f] ). Aus der X- und Y-Komponente wird eine eindeutige TileID abgeleitet.
𝑥=
𝑙𝑜𝑛 + 180
∗ 2𝑧
360
𝑙𝑎𝑡𝑟𝑎𝑑 =
𝑦=
𝑙𝑎𝑡 ∗ 𝜋
180
1−
log⁡ 𝑡𝑎𝑛 𝑙𝑎𝑡𝑟𝑎𝑑 +
1
cos⁡𝑙𝑎𝑡𝑟𝑎𝑑
𝜋
93
∗ 0.5 ∗ 2𝑧
Kapitel 6
𝑙𝑜𝑛
𝑙𝑎𝑡
𝑙𝑎𝑡𝑟𝑎𝑑
Implementierung
Längengrad
Breitengrad
Breitengrad im
Bogenmaß
𝑥
𝑦
𝑧
X-Koordinate der Kachel
y-Koordinate der Kachel
Zoomstufe (=14)
Formel 6.1: Berechnung der Kachelkoordinaten
6.5.2 Bereitstellung
Für die Bereitstellung der einzelnen Kacheln und die Koordination der notwendigen Arbeitsabläufe ist ein Tile-Cache
(COSMTileCache) zuständig. Basierend auf der aktuellen Position und der dargestellten Karte bestimmt die Klasse,
welche Kacheln mit welcher Priorität geladen werden müssen. Hier findet die Precachingstrategie aus Kapitel 5.4
Anwendung. Wenn eine benötigte Kachel noch nicht existiert, wird sie erstellt und an die Download-Komponente
übergeben. Ist sie bereits heruntergeladen aber noch nicht in das Datenmodell aufgenommen, wird sie an die ParserKomponente weitergeleitet. Sobald ein COSMTile-Objekt den Status verändert, wird der Tile-Cache benachrichtigt.
Dieser kann daraufhin den nächsten Bearbeitungsschritt einleiten.
Eine besondere Herausforderung während der Entwicklung stellte der Download der OSM-Daten dar. Unabhängig von
der Größe der Kacheln besteht das Problem, dass eine Anfrage von der OSM-API mit einer Verzögerung von
mehreren Sekunden beantwortet wird. Dies lässt sich auf die Abfrage der Daten aus der OSM-Datenbank und die
Erzeugung der XML-Antwort zurückführen. Während dieser Zeit liegt die Verbindung brach und es wird wertvolle
Bandbreite verschwendet. Durch die Verwendung mehrerer paralleler Downloads wird die Bandbreite effektiver
ausgenutzt. Dadurch kann das Problem verringert werden. In der Praxis hat sich eine Zahl von zehn parallelen
Downloads als effizient herausgestellt. Es wird vor allem die Dauer des Downloads untersucht. Dieses Vorgehen hat
außerdem den Vorteil, dass eine einzelne sehr große Kachel keine anderen Kacheln für längere Zeit blockiert. Für die
Verwaltung freier Downloadkapazitäten musste ein zusätzliches Objekt eingeführt werden. Die Tile-CacheKomponente übergibt den Downloadauftrag nun nicht mehr an eine Download-Komponente, sondern an eine Instanz
der Klasse CLoadBalancer. Die Download-Komponente COSMDownloader wird mehrfach erzeugt. Sobald eine
Komponente nach einem Download wieder verfügbar ist, wird der Load-Balancer benachrichtigt und vergibt den
nächsten Auftrag anhand der vergebenen Prioritäten. Das Sequenzdiagramm in Abb 6.3 soll das Verfahren noch
einmal verdeutlicht werden. Die Zahlen in Klammern sollen die TileIDs andeuten.
Abb 6.3: Sequenzdiagramm zur Darstellung des Load-Balancing Verfahrens
94
Kapitel 6
Implementierung
Die letzte wichtige Komponente zur Vorhaltung der OSM-Daten ist COSMParser. Die Komponente erhält ein
COSMTile-Objekt, das die heruntergeladenen XML-Daten enthält. Beim Abarbeiten des Dokuments werden die
korrespondierenden Knoten bzw. Kanten erzeugt und zum CMap-Objekt der Kachel hinzugefügt. Bei der Entwicklung
stellte sich ein ähnliches Problem, wie beim Download der Kacheln. Wenn ein Parser eine Kachel mit sehr vielen Daten
abarbeiten muss, kommt es vor, dass andere Kacheln blockiert werden. Um dies zu vermeiden wird auch hier die
Klasse CLoadBalancer eingesetzt. Tests haben gezeigt, dass drei parallel arbeitende Parser-Komponenten
ausreichen, den geschilderten Effekt zu vermeiden.
In der Praxis hat es sich als vorteilhaft erwiesen, die Kacheln in Form von XML-Dateien zwischen zuspeichern. Diese
Aufgabe übernimmt eine zusätzliche Komponente CFileWriter, welche ebenfalls durch den Tile-Cache kontrolliert wird.
6.5.3 Visualisierung
Die grafische Darstellung ist durch eine eigene Komponente CMapViewer realisiert. Ziel war eine rudimentäre
Ausgabe der relevanten Daten. Die Umsetzung erfolgte mit OpenGL. Folgende Informationen werden dargestellt:






Karten-Daten, jedoch ohne Berücksichtigung der Flächen
GPS-Positionen und GPS-Tracks der einzelnen Empfänger
Verbesserte GPS-Position samt GPS-Track
Status des Street Matchings
Einzeichnung von Lagefestpunkten und Mittelwerten
Neu erfasste Straßen
Der Bereich der angezeigt wird richtet sich primär nach der aktuellen Position. Mit Hilfe der Pfeiltasten kann jedoch in
alle Richtungen gescrollt werden. Die notwendigen Karten-Kacheln werden in diesem Fall nachgeladen, da der TileCache für das Event POSITION_CHANGED der Klasse CMapViewer registriert ist.
Abb 6.4: Darstellung bei der Erfassung einer neuen Straße
Abb 6.5: Darstellung von Darmstadt
mit eingezeichneten Kacheln
Die korrekte Darstellung von Flächen ist zurzeit nicht möglich. Das liegt daran, dass OpenGL nur konvexe Flächen
unterstützt. Die bei OSM verwendeten Flächen haben diese Einschränkung jedoch nicht. Um sie richtig darzustellen
müsste ein Polygon einer Tesselierung unterzogen werden. Die Fläche wird in einzelne Dreiecke zerlegt, welche
wiederum korrekt gerendert werden können. Näheres zur Tesserlierung von Oberflächen findet man z.B. in [Wie04] .
95
Kapitel 6
6.6
Implementierung
Positionsbestimmung
Zur Positionsbestimmung mit Hilfe der Positionsmittelung stehen zwei Verschiedene Komponenten zur Verfügung. Zum
einen die Klasse CGPSDevice und zum anderen die Klasse CGPSAverager. Für das Einspielen der Korrekturdaten ist
das Modul NtripClient verantwortlich. Ntrip sieht verschiedene sogenannte Zugriffspunkte vor. Darunter ist eine
Zeichenkette zur Identifikation unterschiedlicher Dienste zu verstehen. Zum Aufruf des Programms müssen neben dem
Zugriffspunkt der zu verwendende Server, Zugangsdaten und verschiedene Kommunikationsparameter übergeben
werden. Außerdem ist bei SAPOS EPS ein NMEA-Datensatz mit der aktuellen Position zu senden. Als Ziel muss ein
serieller Port angegeben werden. Für die Anwendung im Rahmen dieser Entwicklung wurde ein virtueller com-Port
erzeugt, der auf den TCP/IP-Port der Empfänger umgeleitet wurde.
ntripclient -m DGPS_HE -s www.SAPOS-HE-NTRIP.de -r 2101
-p *Password* -u *User* -D com3 -B 9600 –n
"$GPGGA,091720.464,4953.44101,N,00839.91231,E,1,5,0.0,233.0,M,0.0,M,,*51"
Listing 6.4: Anwendung des NtripClients
6.6.1 NMEA-Auswertung
Die prinzipielle Funktionsweise der Positionsmittelung wurde bereits ausführlich erklärt. An dieser Stelle soll die
praktische Umsetzung dargestellt werden. Für jeden GPS-Empfänger wird eine Instanz von CGPSDevice erzeugt. Die
Aufgabe dieser Komponente ist die Auswertung der NMEA-Datensätze, die von den Empfängern geliefert werden.
Hierzu muss zunächst eine Socketverbindung auf den TCP-Port des jeweiligen Empfängers erstellt werden. Die
ankommenden Daten werden zeilenweise bearbeitet. Zur Speicherung wurde für jeden Datensatz-Typ ein Container
erstellt, der die enthaltenen Daten aufnehmen kann. Als Beispiel der Container für den GPRMC-Datensatz:
5
10
struct GPRMC
{
float time;
//Zeit mit Nachkommastellen
GPRMCstate::Enum state;//A=Gültig, V=Ungültig
CPosition position;
//Aktuelle Position
GPRMCkind::Enum kind; //A=Autonom, D=Differentiell, …
double velocity;
//Geschwindigkeit in Knoten
double direction;
//Fahrtrichtung
int date;
//Aktuelles Datum
};
Listing 6.5: Container für NMEA-GPRMC Datensatz
Wenn der GPRMC-Datensatz eine gültige Position liefert, löst das CGPSDevice-Objekt das Event
POSITION_CHANGED aus. Die GPS-Empfänger sind so eingestellt, dass sie immer zur vollen Sekunde NMEA-Daten
ausgeben. Dadurch wird erreicht, dass alle synchron arbeiten.
6.6.2 Positionsmittelung
Zur Positionsmittelung dient die Komponente CGPSAverager. Sie ist bei allen CGPSDevice-Instanzen für das
POSITION_CHANGED-Event registriert. Bei jedem Durchlauf wartet die Komponente, bis alle Empfänger ihre Position
übermittelt haben. Danach wird die Mittelung durchgeführt, wie sie in Kapitel 5.3.2 erklärt wurde. Zunächst wird
anhand der GPRMC-Daten die mittlere Fahrrichtung bestimmt. Als Gewichtung bei der Mittelung wird der HDOP-Wert
verwendet. Im System sind die Parameter der notwendigen Layout-Korrektur jedes Empfängers für die Fahrtrichtung 0°
hinterlegt. Die Korrektur einer Position geschieht mit Hilfe der Methode „Projection‚ der Klasse CPosition. Intern wird
der Aufruf an die Direct-Methode der GeographicLib übergeben.
96
Kapitel 6
Implementierung
correctedPos=currentPos.Projection(
dAvgDirection+dCorrectionAngle,dCorrectionDistance);
Listing 6.6: Berechnung der korrigierten Position
Sobald die Mittelung abgeschlossen ist, löst die CGPSAverager-Komponente das Event POSITION_CHANGED aus.
Dadurch, dass beide Komponenten die gleichen Schnittstellen und die gleichen Events verwenden, ist es für andere
Komponenten transparent, ob nun ein CGPSDevice oder die CGPSAverager-Komponente verwendet wird.
6.6.3 Erweiterungen
In Ergänzung zum entwickelten Konzept, wurden zwei weitere Funktionen hinzugefügt. Zum einen wurde für
Testzwecke eine Simulations-Komponente geschaffen, die in der Lage ist mehrere aufgezeichnete NMEA-Dateien zu
öffnen und die Daten parallel in regelmäßigen Abständen über TCP-Ports zu versenden. TCP wurde an dieser Stelle
verwendet, damit die Klasse CGPSDevice nicht angepasst werden musste. Als zweite Ergänzung wurde eine
Möglichkeit entwickelt die Positionsdaten, welche die CGPSAverager-Komponente berechnet, in Form von selbst
generierten NMEA-Datensätzen über einen TCP-Port abzufragen. Dadurch können externe Programme von der
genaueren Positionsbestimmung profitieren.
6.7
Mapping
Die Realisierung des automatisierten Mappings umfasst die beiden Komponenten CStreetMatcher und CMapper. Zur
Aktualisierung der Datenbank wurde die Download-Komponente entsprechend angepasst. Zunächst wird die Street
Matching Komponente untersucht.
6.7.1 Street Matching
Hauptaufgabe des CStreetMatcher-Objekts ist die Feststellung, ob das System sich zurzeit auf oder an einer Straße
befindet. Hierzu bietet die Komponente vier verschiedene Events an:




MATCH_FOUND
MATCH_VALID
MATCH_LOST
NO_MATCH
Die Positionsaktualisierung erhält die Komponente über das Event POSITION_CHANGED von CGPSAverager. Mit den
erhaltenen Koordinaten werden nach dem in Kapitel 5.5.2 beschriebene Verfahren zur Kandidatenfindung zunächst
die Kacheln, darauf aufbauend die Straßen und danach die einzelnen Straßenabschnitte bestimmt (siehe Listing 6.7).
Findet sich ein geeigneter Kandidat, wird je nach Ausgangszustand entweder das Event MATCH_VALID oder
MATCH_FOUND ausgelöst, je nachdem, ob beim letzten Durchgang ein Match gefunden wurde oder nicht. Falls sich
kein Kandidat findet, wird dementsprechend MATCH_LOST oder NO_MATCH ausgelöst.
Zur Verdeutlichung der Funktionsweise ein kurzer Auszug aus dem Verfahren zur Kandidatenbestimmung. Durch
Projektion der aktuellen Position auf die Eckpunkte einer quadratischen Fläche wird ein Suchraum definiert. In diesem
Falle mit einer Diagonalen Länge von 10 Metern. Danach werden die umliegenden Kacheln auf Schnitt mit dem
Suchraum geprüft. Hierzu bietet die Klasse CBounds die Methode „intersects‚.
97
Kapitel 6
Implementierung
CPosition NorthEast=m_CurrentGPSPosition.Projection(45.0,5.0);
CPosition SouthWest=m_CurrentGPSPosition.Projection(225.0,5.0);
CBounds gpsArea(NorthEast,SouthWest);
5
currentTileBounds=COSMTileCache::getBounds(iCurrentTile);
if(currentTileBounds.intersects(gpsArea))
{ … }
Listing 6.7: Awenden der Schnittmethode zur Selektion der Kacheln.
In gleicher Weise kann mit einzelnen Straßen und Straßenabschnitten verfahren werden. Die einzelnen
Straßenabschnitte müssen abschließend untersucht werden, ob sie den Suchraum schneiden – falls ja, ist das Street
Matching erfolgreich.
6.7.2 Mapping
Sobald kein Matching mehr möglich ist, erhält die CMapper-Komponente das Event MATCH_LOST und beginnt
daraufhin mit der Aufzeichnung. Sie registriert sich ebenfalls für das POSITION_CHANGED Event von CGPSAverager
und beginnt damit die Aufzeichnung. Die Aufzeichnung endet mit einem MATCH_FOUND Event der Street Matcher
Komponente. Bevor jedoch eine Aktualisierung der OSM-Datenbank durchgeführt werden kann, wird die
Linienvereinfachung durchgeführt.
Line Simplification
Die Positionen der CMapper-Komponente sind hierfür in einer verketteten Liste organisiert. Die Vereinfachung beginnt
damit, dass die Strecke nur durch Start und Ziel repräsentiert wird. Danach wird, wie in Kapitel 4.6.3 beschrieben,
überprüft, ob der aktuelle Teilabschnitt das Toleranzkriterium der maximalen Abweichung erfüllt. Hierzu wurde die
Funktion DistanceToEdgeSegment erstellt, die für einen gegebenen Punkt, sowie Start und Ziel einer Strecke, den
minimalen Abstand zu dieser Strecke bestimmt (siehe Listing 6.8).
double Position.DistanceToEdgeSegment(
m_pActiveMappingBuffer->at(iStart).Position,
m_pActiveMappingBuffer->at(iEnd).Position);
Listing 6.8: Funktion zur Berechnung des Abstands eines Punktes zu einer Strecke
Dieser Aufruf wird für jeden Punkt zwischen dem aktuellen Start- und dem aktuellen Zielpunkt durchgeführt.
Überschreitet der maximale Abstand das Toleranzkriterium – für die hier vorliegende Aufgabe hat sich (entsprechend
der erreichten GPS-Genauigkeit) 1,0 Meter als guter Wert herausgestellt – so wird der Streckenabschnitt an der
gefundenen Stelle geteilt und das Verfahren wird für die Teilabschnitte erneut gestartet.
Es ist zu bemerken, dass das implementierte Verfahren zurzeit noch nicht die Anforderung erfüllt, dass Sackgassen
und dergleichen korrekt ermittelt werden. Hierzu müsste die Aufzeichnung einer weiteren Verarbeitung unterzogen
werden, bei der feststellt wird, ob Streckenteile mehrfach befahren wurden.
Aktualisierung
Ist die Linienvereinfachung abgeschlossen, wird die Prüfung der Plausibilitätskriterien durchgeführt. Für den Fall das
dies erfolgreich verläuft, kann die Aktualisierung der Datenbank durchgeführt werden. Hierzu wird ein osmChangeDokument mit Hilfe der libXML erzeugt, das sich an nachfolgendem Beispiel orientiert:
98
Kapitel 6
Implementierung
<osmChange version="0.3">
<create version="0.3">
5
10
15
20
25
30
35
<!—Erzeugen der Punkte -->
<node id="-1" lat="-33.9133128" lon="151.1173333"/>
…
<node id="-10" lat="-33.9233146" lon="151.1173391"/>
<!—Erzeugen der Strecke -->
<way id="-11">
<nd ref="-1"/>
…
<nd ref="-10"/>
<tag k="highway" v="road"/>
</way>
</create>
<modify version="0.3">
<!— Anbindung an das Straßennetz
<way id="45184823">
<nd ref="91575880"/>
…
<nd ref="-1"/>
…
<nd ref="91575215"/>
…
</way>
<way id="78136410">
<nd ref="78924673"/>
…
<nd ref="-10"/>
…
<nd ref="78927652"/>
…
</way>
</modify>
</osmChange>
-->
Listing 6.9: osmChange-Dokument zum Hinzufügen einer neuen Straße
Es werden zunächst die Knoten erstellt, Danach der Weg, der alle Knoten verbindet. Wie bereits in Kapitel 5.5.4
dargestellt müssen zur Anbindung an das bestehende Straßennetz der erste und der letzte Punkt den jeweils
zugehörigen Straßen an der richtigen Stelle eingefügt werden.
Das Dokument wird an das COSMDownloader-Objekt übergeben, welches bei einer bestehenden Verbindung
zunächst ein Changeset öffnet, das Dokument überträgt und anschließend das Changeset wieder schließt.
Außerdem muss die erzeugte Strecke in die lokale Datenstruktur aufgenommen werden. Dies geschieht entweder
durch manuelles Hinzufügen der Nodes und der Edge, oder durch das vollständige Neu Laden der betroffenen
Kacheln.
99
Kapitel 7
7.1
Zusammenfassung und Ausblick
Bewertung der Ergebnisse
Um die Fragestellung, die dieser Arbeit zugrunde liegt, abschließend zu beantworten, bedarf es einer Qualitativen
Bewertung der einzelnen Teilaspekte. In den Folgenden Abschnitten werden die Ergebnisse hinsichtlich der
Genauigkeit der Positionsbestimmung, der Verfügbarkeit der OSM-Daten und der Qualität des automatisierten
Mappings noch einmal zusammengefasst.
7.1.1 Genauigkeit der Positionsbestimmung
Im Rahmen der Recherchen wurden umfangreiche Untersuchungen zur Genauigkeit von GPS angestellt. Es konnte
gezeigt werden, dass die Nutzung mehrerer Empfänger prinzipiell einen Gewinn an Präzision mit sich bringt, da
dadurch lokale Störeinflüsse kompensiert werden können. Einzelne Ausreißer bei den GPS-Positionen der Empfänger
in Folge eines Mehrwegeempfangs konnten gar vollständig kompensiert werden. Es wurde aber auch ermittelt, dass
eine höhere Steigerung, als um den Faktor zwei auch mit mehr als fünf oder sechs Empfängern nicht realistisch
erscheint (siehe Kapitel 3.6, 3.7 und 3.9).
Für die Entwicklung des Prototyps wurde ein Konzept zur Verbesserung der Positionsgenauigkeit erarbeitet, das
sowohl die Bereitstellung von DGPS-Korrekturdaten über das Internet, als auch die Anwendung einer
Positionsmittelung über mehrere parallel betriebene Empfänger vorsieht (siehe Kapitel 5.3 und 6.6)
Im Rahmen der Implementierung konnte dieses Konzept erfolgreich umgesetzt werden. Die erreichten
Verbesserungen entsprechen den Ergebnissen, wie sie bereits von den praktischen Voruntersuchungen bekannt
waren. So ermöglicht der Ansatz eine Verringerung des mittleren Punktfehlers auf etwa 90 cm – in Bewegung auf etwa
1,5 m (siehe Kapitel 3.9). In der Praxis bedeutet das, dass die Position nunmehr nur noch um ca. einen Meter
schwankt. Von einer leichten Verzögerung durch die Berechnung abgesehen, steht damit eine, im Vergleich zu den
ursprünglichen Messergebnissen, sehr genaue Position zur Verfügung, die über dem liegt, was OSM derzeit bietet.
Dadurch konnte eine Grundlage geschaffen werden, die es ermöglicht, Straßen in der notwendigen Qualität zu
erfassen.
100
Kapitel 7
7.1.2 Verfügbarkeit der OSM-Daten
Ein wichtiges Zwischenziel war die Integration der OSM-Daten in die Anwendung. Hierzu wurden mehrere
Komponenten realisiert. Der Dreh und Angelpunkt hierfür ist die Komponente CTileCache. Sie koordiniert die
Bereitstellung der Kachelobjekte. Die besondere Herausforderung stellte vor allem die richtige Wahl der zu ladenden
Kacheln dar, damit auch bei schlechter Abdeckung des Mobilfunknetzes möglichst immer die notwendigen Kacheln
verfügbar sind.
Um dieses Ziel zu erreichen wurden mehrere Dinge berücksichtigt und umgesetzt:




Auswahl der Kacheln mit Hilfe einer prioritätsbasierten Precachingstrategie
Nutzung der HTTP-Kompression
Verwendung paralleler Download-Komponenten
Prioritätsbasierte Verteilung der Download-Aufträge mit Hilfe der CLoadBalancer Komponente
Zur Darstellung der Effektivität des erstellten Ansatzes sei auf Tabelle 7.1, Tabelle 7.2 und Tabelle 7.3 verwiesen. Es
werden verschiedene Gebiete mit unterschiedlicher Bebauungsdichte und somit unterschiedlichen KachelDatenmengen geladen. Die Untersuchung wurde sowohl für eine DSL-Verbindung durchgeführt, als auch für die
beiden gängigen Mobilfunkschnittstellen UMTS und EDGE. Es werden jeweils 45 Kacheln mit einer Gesamtfläche von
112,5 km² geladen. Bei Verwendung von 10 parallelen Downloads konnte das komplette Gebiet von Frankfurt in
spätestens 6 Minuten geladen werden. Da jedoch in Städten wie Frankfurt eine entsprechend hohe UMTS-Abdeckung
zu erwarten ist, sind etwa 3 Minuten realistisch.
Gebiet
Frankfurt
Darmstadt
Spessart
Kacheln
45
45
45
Fläche (km²)
112,5 km²
112,5 km²
112,5 km²
Datenmenge (MB)
4,5 MB
2,5 MB
1,5 MB
1 Downloader
410 Sekunden
150 Sekunden
38 Sekunden
5 Downloader
195 Sekunden
115 Sekunden
22 Sekunden
10 Downloader
150 Sekunden
61 Sekunden
8 Sekunden
Tabelle 7.1: Gegenüberstellung der Ladedauer für unterschiedliche Konstellationen mit DSL
Gebiet
Frankfurt
Darmstadt
Spessart
Kacheln
45
45
45
Fläche (km²)
112,5 km²
112,5 km²
112,5 km²
Datenmenge (MB)
4,5 MB
2,5 MB
1,5 MB
1 Downloader
670 Sekunden
235 Sekunden
64 Sekunden
5 Downloader
318 Sekunden
174 Sekunden
46 Sekunden
10 Downloader
231 Sekunden
88 Sekunden
17 Sekunden
Tabelle 7.2: Gegenüberstellung der Ladedauer für unterschiedliche Konstellationen mit UMTS
Gebiet
Frankfurt
Darmstadt
Spessart
Kacheln
45
45
45
Fläche (km²)
112,5 km²
112,5 km²
112,5 km²
Datenmenge (MB)
4,5 MB
2,5 MB
1,5 MB
1 Downloader
884 Sekunden
362 Sekunden
102 Sekunden
5 Downloader
478 Sekunden
316 Sekunden
56 Sekunden
10 Downloader
365 Sekunden
157 Sekunden
25 Sekunden
Tabelle 7.3: Gegenüberstellung der Ladedauer für unterschiedliche Konstellationen mit EDGE
Anhand der ermittelten Daten kann davon ausgegangen werden, dass in den allermeisten Fällen eine ausreichende
Zahl an Kacheln für den Fall eines Verbindungsabrisses zwischengespeichert werden kann. Es sei denn, der Start des
Systems erfolgt in einem Gebiet ohne Mobilfunkverbindung. Für diesen Fall ist eine persistente Zwischenspeicherung
101
Kapitel 7
der Kacheln vorgesehen. Hierbei erfolgt das Laden der Kacheln nicht über die OSM-API sondern über XML-Dateien,
die bei vorherigen Verbindungen im Dateisystem gespeichert worden sind.
Weitere Komponenten, die im Rahmen der Implementierung der Geodatenverarbeitung erfolgreich umgesetzt werden
konnten sind die Folgenden:
 COSMParser zum Parsen der OSM-XML-Daten
 CMapViewer zur Darstellung der Geodaten
7.1.3 Mapping-Qualität
Zur Evaluation des implementierten Ansatzes wurde eine Testfahrt durchgeführt, deren Resultate in Abb 7.1 dargestellt
sind. Es konnten erfolgreich drei Strecken erfasst werden. Diese sind in der Darstellung der OSM-Karte (rechts oben)
blau hervorgehoben. Anhand der Luftaufnahmen (links unten) bzw. der topografischen Karte (rechts unten, zum
Vergleich ohne Strecken dargestellt), kann man erkennen, dass die Strecken der Realität entsprechend verlaufen.
Abb 7.1: Gegenüberstellung der Testfahrt-Resultate.
Es muss dabei jedoch berücksichtigt werden, dass es sich bei den Strecken um relativ einfache Fälle handelte, da sie
zum Großteil außerhalb von bebauten Flächen lagen und entsprechend einfach erfasst werden konnten. Trotzdem ist
damit gezeigt worden, dass der prinzipielle Ansatz erfolgreich funktioniert und Ergebnisse von guter Qualität liefert,
insbesondere Aufgrund der verbesserten GPS-Genauigkeit. Das größere Problem stellt beim Mapping letztlich die
Ungenauigkeit der OpenStreetMap dar, die eine automatische Erfassung an vielen Stellen verhindert.
102
Kapitel 7
7.2
Zusammenfassung
Diese Arbeit sollte verschiedene Ziele bewältigen. Zum einen ging es um die Steigerung der Positionsgenauigkeit
heutiger GPS-Empfänger. Auf der anderen Seite sollte auf Basis der verbesserten Position untersucht werden, in wie
weit es möglich ist, automatisiert neue Straßen in die Geo-Datenbank von OSM zu erfassen. Zur Lösung dieser
Problemstellung wurden zunächst umfangreiche Recherchen unternommen und die Grundlagen der verschiedenen
Themenfelder dieser Arbeit untersucht.
Zu Beginn war es notwendig ein tiefgehendes Verständnis für die kartographischen und geodätischen
Zusammenhänge zu entwickeln. Dies war sowohl für die Beurteilung und Verwendung von GPS hilfreich, als auch für
die Nutzung der OSM-Daten. Es wurden Methoden zur Bezugssystemtransformation zwischen unterschiedlichen
Geodätischen Daten aufgezeigt, die notwendig waren, um die Koordinaten von Lagefestpunkten in der erforderlichen
Genauigkeit in das Koordinatensystem von GPS zu übernehmen. Außerdem sind verschiedene relevante
Koordinatenoperationen vorgestellt worden, die für die spätere Umsetzung innerhalb des Prototyps benötigt wurden.
Zur Beurteilung und Verbesserung der GPS-Daten wurde ein vollständiger Überblick über die Verfahren hinter GPS
und anderen globalen satellitengestützten Navigationssystemen erarbeitet. Nur mit einem genauen Verständnis der
Zusammenhänge ist eine Einschätzung des Potentials von Verbesserungsmaßnahmen möglich. Besonders wichtig ist
die Trennung der Störeinflüsse des GPS-Systems in systembedingte und lokale Störungen. Da diese jeweils
unterschiedliche Ansätze zur Kompensation notwendig machen.
In intensiven praktischen Experimenten wurden die Eigenschaften handelsüblicher GPS-Empfänger unter die Lupe
genommen. Und zwar sowohl in statischen Untersuchungen in Bezug auf Lagefestpunkt-Koordinaten, als auch in
dynamischen Testreihen bei verschiedenen Testfahrten. Die Untersuchung mehrerer parallel ausgewerteter
Empfänger und der dadurch erreichte Gewinn an Genauigkeit stellen wichtige Erkenntnisse der vorliegenden Arbeit
dar. Die Schwankungen der Position, hervorgerufen durch lokale Störeinflüsse, können durch dieses Verfahren um die
Hälfte reduziert werden.
Zur Kompensation systembedingter Störungen wurde die Nutzung von codephasenbasiertem Differential GPS
untersucht. Dazu wurden die Daten von EGNOS und SAPOS EPS mit Hilfe des Protokolls Ntrip aus dem Internet
geladen. Insgesamt konnte dadurch eine Lösung zusammengestellt werden, die im Vergleich zu einer nicht
optimierten Positionsbestimmung eine klare Verbesserung aufweist.
Im weiteren Verlauf der Arbeit wurde das Projekt OpenStreetMap näher beleuchtet. Es wurde auch hier zunächst eine
Zusammenfassung des aktuellen Standes und der verwendeten Technologien gegeben. Angefangen vom
Systemaufbau über das Datenmodell bis hin zu den verfügbaren Schnittstellen. Es wurde untersucht in wie weit OSMDaten für die mobile Nutzung verwendbar sind und welche Voraussetzungen hierfür erfüllt sein müssen. Weiterhin
wurde der bisherige Weg der Erfassung von Kartendaten aufgezeigt.
Vor der Erstellung des eigentlichen Prototyps war es notwendig, ein geeignetes Konzept zu entwerfen, das es
ermöglicht, die bisher gewonnenen Erkenntnisse zur Umsetzung der Aufgabenstellung einzusetzen. Zunächst wurde
die Verwendung eines komponentenbasierten Ansatzes in Anlehnung an das im InCarMultimedia Labor verwendete
Framework beschlossen. Dadurch sollten die Qualitätskriterien Portierbarkeit und Erweiterbarkeit erreicht werden.
Ergänzt wurde der Ansatz um Fähigkeiten des Observer-Patterns. Konkretisiert wurden außerdem die Verfahren zur
103
Kapitel 7
Positionsbestimmung. So sollte der entwickelte Ansatz zur Verwendung mehrerer GPS-Empfänger Anwendung finden,
sowie die evaluierten Korrekturdaten von EGNOS und SAPOS EPS. Der Nächste wichtige Schritt war die Konzeption
der OSM-Integration, sowie die Entwicklung eines Ansatzes zum automatisierten Mapping und der Untersuchung von
Einschränkungen der Aufgabenstellung.
Das automatisierte Mapping basiert auf zwei Konzepten. Der erste wichtige Schritt ist die Durchführung eines Street
Matchings. Dadurch kann beurteilt werden, ob eine neue Straße erfasst werden darf oder nicht. Der zweite Schritt ist
die Anwendung eines Line Simplification Algorithmus auf den resultierenden GPS-Track. Dadurch wird es ermöglicht
einen komplexen Weg auf die notwendigen Stützpunkte zu reduzieren.
Im Rahmen einer prototypischen Implementierung wurde das entwickelte Konzept umgesetzt. Neben der
Programmierung der komponentenbasierten Architektur, galt es zunächst die Integration der OSM-Daten vorzunehmen
und das entwickelte Verfahren zur Positionsmittelung zu realisieren. Mit Hilfe der Street Matching Komponente und der
Mapping Komponente konnte die Automatisierung der Straßenerfassung unter Berücksichtigung verschiedener
Einschränkungen gelöst werden. Die Ergebnisse hierzu waren gut, konnten jedoch aufgrund von
Kartenungenauigkeiten der OSM nur für sehr einfache Fälle untersucht werden.
7.3
Ausblick
Die vorliegende Arbeit stellte ein herausforderndes Projekt dar. Die erfolgreiche prototypische Umsetzung hat gezeigt,
dass ein automatisiertes Mapping auf Basis einer verbesserten GPS-Position prinzipiell möglich ist. Das System lässt
jedoch in viele Richtungen Spielraum für Weiterentwicklungen und nähere Untersuchungen. An dieser Stelle sollen
einige mögliche Ansatzpunkte aufgezeigt werden.
7.3.1 Positionsbestimmung
Die realisierte Positionsgenauigkeit konnte durch den Einsatz paralleler Empfänger und der DGPS-Korrekturdaten auf
ein für den Zweck des automatisierten Mappings ausreichendes Niveau gehoben werden. Doch steckt in den
Empfängern dieser Preisklasse noch Potential. Dies hat [Tak08] bereits bewiesen. Eine Untersuchung des dort
vorgestellten Ansatzes zur Trägerphasenauswertung mit Empfängern wie dem U-blox AEK-4T könnte Aufschluss
geben, was maximal in diesem Preissegment machbar ist.
Für das bestehende Verfahren sollte die direkte Integration der Ntrip-Schnittstelle in betracht gezogen werden. Dies
würde das Konzept flexibler und Plattformunabhängiger werden lassen, da der bisher verwendete NtripClient nicht für
alle Plattformen zur Verfügung steht.
Der Ansatz zur parallelen Auswertung mehrere Empfänger bietet dahingegen Spielraum, dass derzeit die Höhe noch
nicht in die Verarbeitung mit einfließt. Außerdem entstand im Laufe des Projekts der Wunsch, eine
Richtungsbestimmung auch bei stehendem Fahrzeug durchzuführen. Hierzu müssten zum Beispiel drei Hintere und
drei Vordere Empfänger getrennt ausgewertet werden.
7.3.2 OSM-Daten
Ein derzeit bestehendes Problem liegt darin, dass der Tile-Cache keine Kacheln mehr freigibt, und so auch Kacheln,
die längst nicht mehr benötigt werden, im Speicher (und auf der Festplatte) behält. Es wäre zu untersuchen in wie weit
104
Kapitel 7
gängige Cache-Strategien wie z.B. Least-Recently-Used, First-In-First-Out für ein solches Szenario geeignet sind, oder
ob an dieser Stelle Strategien entwickelt werden müssen, die den geometrischen Bezug berücksichtigen.
Die innerhalb der Arbeit entwickelten Erfahrungen, Konzepte und Komponenten dürften außerdem sehr gut innerhalb
des InCarMultimedia-Frameworks Anwendung finden, vor allem durch die Nutzung der OSM-Daten als Quelle für die
Kartendaten.
7.3.3 Mapping
Das automatisierte Mapping arbeitet in seinen Grundzügen korrekt, jedoch mit zahlreichen Einschränkungen. Hier
sollte weiter untersucht werden, mit welchen Mitteln diese Einschränkungen gelockert werden können. Vor allem sollte
untersucht werden, welche weiteren Vorteile ein zentraler Server an dieser Stelle bringt, der die Daten von mehreren
Mapping-Komponenten auswerten kann.
In Bezug auf die Plausibilitätskriterien ist zu prüfen, in wie weit z.B. ein Ampelstopp, der aufgrund der Unterschreitung
der Mindestgeschwindigkeit zum Abbruch des Mappings führt, detektiert werden kann, oder ob hier vielleicht andere
Untersuchungskriterien wirksamer sind.
Interessant ist auch die Möglichkeit weitere OSM-Features zu erfassen z. B. durch die Integration des Nutzers, aber
auch durch die Anbindung weiterer Komponenten im Fahrzeug, wie Tankanzeige oder Verkehrsschilderkennung. Bei
ersterem könnte beim Auffüllen des Tanks automatisch eine Tankstelle erfasst werden.
7.3.4 Navigation
Ein besonders interessantes Feld zukünftiger Entwicklungen ist die Realisierung eines OSM Navigationssystems
entweder vollständig mit Hilfe von webbasierten Systemen wie Onlineroutenplanern oder aber durch intelligente
Vorhaltung der Straßendaten in einem Level-of-Detail-Konzept. Für diesen Zweck müsste aber auch die aktuell sehr
rudimentäre Darstellung der Karte verbessert werden.
Verbessert werden müsste außerdem die Street Matching Komponente, die auch für eine Navigationsanwendung
notwendig wäre. Sie arbeitet zwar korrekt, jedoch bisher nicht sehr effizient.
105
Teil III
Anhang
Anhang A
Stichwortverzeichnis
Commercial Service
Compass
Creative Commons
cURL
A
Adressierungsschema
Almanach
Assisted GPS
Atmosphärische Einflüsse
Autokorrelation
Azimut
Azimutalprojektion
93
22, 24
48
36
27
8
11
D
Datenmodell
Datumstransformation
Deutsche Hauptdreiecks Netz
Differential GPS
Differenzenbildung
Differenzposition
Dilution of Precision
Distance Root Mean Square
DOM-Parser
Dopplerverschiebung
Douglas-Peucker-Verfahren
DREF
B
Bandspreizverfahren
Basislinie
Beidou
Bessel Ellipsoid
Bestanschließendes Ellipsoid
Bezugssystem
Bounding Box
Breitengrad
25
44
32
9
8
7
72
7
66
14
8
43
44
49
39
41
90
27
75
10
E
Echtzeit-Positionierungsdienst
Editoren
Einfrequenzempfänger
Entfernungsbestimmung
Ephemeriden
EPSG-Codes
Erdschwerefeld
ETRS 89
Events
C
C/A-Code
CDMA
CEP-Fehlerkreise
Changesets
Circular Error Probable
Coarse Acquisition-Code
Code Division Multiple Access
Codemultiplex
Codephase
Codephasenbasiertes DGPS
33
32
62
90
25
25
42
67
42
25
25
25
27
43
107
45
74
23
28
22, 24
16
6
10
80, 92
Anhang A
F
Fehlerquellen
FreeGlut
Frequency Division Multiple Access
Frequenz-Multiplex
Fundamentalpunkt
M
35
91
31
31
8
Map Matching
Mapnik
Mapper
Mapping
Mehrwegeeinflüsse
Mercatorprojektion
Mittelwertbildung
Mittlerer Punktfehler
Mobile Binary Protocol
Modulation
Multipolygon
G
GALILEO
32
Gauß-Krüger
12
Genauigkeit
33, 38
Geodäsie
5
Geodaten
62
Geodätische Datum
9
Geodätischer Post-Processing Positionierungsdienst 45
Geodätisches Datum
8
GeographicLib
91
Geographische Koordinaten
7
Geoid
6
Geoidundulatation
6
Geoinformationssystem
62
GLONASS
31
GPS
20
gpsd
89
GPS-Signal
24
GPS-Zeit
22
GRS 80
9
N
Navigationsnachrichten
NAVSTAR-GPS
Netz-RTK
NMEA 0813
Node
Ntrip
Nullmeridian
Nutzersegment
24
20
45
50
66, 68
46
7
22
O
Oberserver Pattern
Open Service
OpenGL
OpenStreetMap
OSM-API
Osmarender
osmChange
OSM-Datenbank
OSM-XML-Protokoll
H
Helmert-Transformation
Hochpräziser Echtzeitpositionierungsdienst
48
70
64
73
37
11, 93
48
41
73
26
66
14
45
80
32
91
62
71
71
72
65
68
I
ITRS
P
10
P(Y)-Code
Phase Shift Keying
Phasenumtastung
Points-of-Interest
Polygon
Positionsbestimmung
Post-Processing
Präzision
Precachingstrategien
Precise Positioning Service
Precise-Code
Prioritätsbasiertes Precaching
Projektionen
Projektionskörper
Pseudo Random Noise Codes
Pseudo Rang
Pseudo Range Correction
Pseudoentfernungen
Pseudoliten
Public Regulated Service
K
Kartesische Koordinaten
Kartographie
Kegelprojektion
Knoten
Kontrollsegment
Koordinatensysteme
Korrelation
Kreuzkorrelation
7
5
11
66, 68
22
7
26
27
L
Lagefestpunkt
Längengrad
Latitude
Layer
libXML
Line Simplification
Linienvereinfachung
Lokale Fehler
Longitude
Lotabweichung
18
7
7
70
90
75
75
35
7
6
25
25
25
62
66
28
44
38
77
20
25
82
10
11
25
30
59
30
32
33
R
Radio Beacon Empfänger
Range Rate Correction
108
46
59
Anhang A
Ranging and Integrity Monitoring Stations
Raumsegment
Read Only Map API
Realtime Kinematics
Receiver Independent Exchange Format
Referenz Rahmen
Referenz System
Referenzsignal
Referenzstation
Referenzstationsnetze
Relation
Renderer
RESTless
Richtigkeit
Role
Rolle
Rotationsellipsoid
Rover
RTCM SC-104
RTKlib
47
21
73
44
44
9
9
26
43
45
66, 69
69
71
38
66
66
5
43
46
45
Standardabweichung
Street Matching
System Rauenberg
Systembedingte Fehler
T
Tag67, 68
Time of Week
Trägerphasenbasiertes DGPS
Trägersignal
Transversale Mercatorprojektion
Triangulation
Trigonometrischer Punkt
28
43
24
11
29
18
U
Uhrzeitkorrektur
UTM
S
Safety-of-Life Service
Satallite Based Augmentation System
Satellitengeometrie
Satellitenpositionierungsdienst
Search-and-Rescue Service
Selective Availability
Simple Feature Model
Slippy Map
Spatial Extensions
Spread Sepctrum
Staatliches Trigonometrische Netz
Standard Positioning Service
41
48, 84
9
35
30
12
W
33
47
39
45
33
21
63
70
63
25
9
20
Way
Weg
WGS 84
66, 68
66, 68
9
Z
Zweifrequenzempfänger
109
23
Anhang B
AGPS
API
BKG
C/A
CDMA
CEP
DGPS
DHDN
DOP
DSL
DTD
EDGE
EGNOS
EPS
EPSG
ESA
FDMA
GATE
GIS
GLONASS
GNSS
GPPS
GPRS
GPS
Abkürzungsverzeichnis
Assisted Global Positioning System
Application Programming Interface
Bundesamt für Kartographie und Geodäsie
Coarse Acquisition
Code Division Multiple Access
Circular Error Probable
Differential GPS
Deutsches Hauptdreiecksnetz
Dilution of Percision
Digital Subscriber Line
Document Type Definition
Enhanced Data Rates for GSM Evolution
European Geostationary Navigation Overlay Service
Echtzeit-Positionierungs-Service
European Petroleum Survey Group Geodesy
European Space Agency
Frequency Division Multiple Access
Galileo Test- und Entwicklungsumgebung
Geoinformationssystem
Globalnaja Nawigazionnaja Sputnikowaja Sistema - Globales Satellitennavigationssystem
Global Navigation Satellite System
Geodätischer Postprocessing Positionierungs-Service
General Packet Radio System
Global Positioning System
110
Anhang B
GPX
GSM
HEPS
HTTP
IP
NAVSTAR-GPS
NMEA
NTRIP
OGP
OSM
POI
PPS
PRC
PRN
PSK
RIMS
RINEX
ROMA
RRC
RTCM
RTK
SA
SAPOS
SBAS
SPS
SQL
TCP/IP
TIGER
TOW
TRAPI
UMTS
URL
UTC
UTM
WAAS
WGS
WLAN
XAPI
XML
Abkürzungsverzeichnis
GPS Exchange Format
Enhanced Data Rates for GSM Evolution
Hochpräziser Echtzeit-Positionierungs-Service
Hypertext Transfer Protocol
Internet Protocol
NAVigation System with Timing And Ranging Global Positioning System
National Marine Electronics Association
Networked Transport of RTCM via Internet Protocol
International Association of Oil & Gas Producers
OpenStreetMap
Points-of-Intrests
Precise Positioning Service
Pseudo Range Correction
Pseudorandom Noise
Phase Shift Keying
Ranging and Integrity Monitoring Station
Receiver Independent Exchange Format
Read Only Map API
Range Rate Correction
Radio Technical Commission for Maritime Services
Real Time Kinematic
Selective Availability
Satellitenpositionierungsdienst
Satellite Based Augmentation System
Standard Positioning Service
Structured Query Language
Transmission Control Protocol / Internet Protocol
Topologically Integrated Geographic Encoding and Referencing system
Time of Week
Tiled Read-only map API
Universal Mobile Telecommunications System
Uniform Resource Locator
Universal Time Coordinated
Universal Transverse Mercator-Projection
Wide Area Augmention System
World Geodetic System
Wireless Lokal Area Network
Extended API
Extensible Markup Language
111
Anhang C
Abbildungsverzeichnis
Abb 2.1: Ellipse mit großer und kleiner Halbachse ........................................................................................................... 6
Abb 2.2: Zusammenhang Topographie und Geoid........................................................................................................... 6
Abb 2.3: Darstellung des Erdschwerefeldes, stark überzeichnet, Quelle: [Wik10c] ........................................................ 6
Abb 2.4: Kartesische Koordinaten, Quelle: [Gruber08] .................................................................................................... 8
Abb 2.5: Geographische Koordinaten, Quelle: [Gruber08] .............................................................................................. 8
Abb 2.6: Zusammenhang Geoid, mittleres Erdellipsoid und lokale Ellipsoide .................................................................. 8
Abb 2.7: Verschiebung der ITRS-Koordinaten pro Jahr, Quelle: [Aug01] ...................................................................... 10
Abb 2.8: Verschiebung der ETRS-Koordinaten pro Jahr, Quelle: [Aug01] ..................................................................... 10
Abb 2.9: Verschiedene Projektionskörper, Quelle: [deL06] ........................................................................................... 11
Abb 2.10: Verschiedene Projektionslagen, Quelle: [deL06] ........................................................................................... 11
Abb 2.11: Gauß-Krüger-Zonen in Deutschland, Quelle: [deL06] ................................................................................... 12
Abb 2.12: UTM-Gitter für Europa und Deutschland, Quelle: [Wik10k] , [LVB09] ............................................................ 13
Abb 2.13: Helmert-Transfomation, Quelle: [Gruber08] .................................................................................................... 14
Abb 2.14: Großkreis als kürzeste Verbindung zweier Punkte, Quelle: [Kom10] ............................................................ 17
Abb 2.15: Spiegelung an einem Großkreisabschnitt ...................................................................................................... 18
Abb 2.16: Trigonometrischer Punkt in Form eine Granitsäule im Boden versenkt, Quelle: [Wik10j] ............................... 19
Abb 2.17: Deutsches Hauptdreiecksnetz, Quelle: [Hab09] ........................................................................................... 19
Abb 3.1: GPS-Satellitenbahnen, Quelle: [Zog09a] ......................................................................................................... 21
Abb 3.2: Satellit des Blocks II, Quelle: [Man04] ............................................................................................................. 21
Abb 3.3: Verteilung der Bodenstationen, Quelle: [Köh08b] ........................................................................................... 22
Abb 3.4: GPS-Modul U-blox LEA 4S, Quelle: www.u-blox.com....................................................................................... 22
Abb 3.5: USB-GPS-Maus Navilock 402u, Quelle: www.navilock.de ................................................................................ 23
Abb 3.6: GPS-Logger WBT 202, Quelle: www.wintec-gps.de ......................................................................................... 23
Abb 3.7: Handgerät Garmin eTrex VistaHCx, Qelle: www.garmin.com........................................................................... 23
112
Anhang C
Abb 3.8: Einfrequenzempfänger mit 40cm Genauigkeit Leica SR-20, Quelle: www.leica-geosystems.com................... 23
Abb 3.9: Zweifrequenzempfänger mit 10-30cm Genauigkeit: Trimble Pathfinder ProXRT, Quelle: www.trimble.com .... 23
Abb 3.10: Prinzip der Phasenumtastung ......................................................................................................................... 24
Abb 3.11: Schematische Darstellung der Signale mit angewandter Bandspreizung ...................................................... 25
Abb 3.12: XOR-Verknüpfung von PRN-Datenstrom und Navigationsdaten, sowie die resultierende Phasenlage .......... 26
Abb 3.13: GPS-Modulationsschema, nach [Dan99] ....................................................................................................... 26
Abb 3.14: Korrelation bezüglich Zeit (Code) und Frequenz, Quelle: [Zog09a] .............................................................. 28
Abb 3.15: Ortung vereinfacht in einer zweidimensionalen Welt ...................................................................................... 29
Abb 3.16: Ortung in einer dreidimensionalen Welt .......................................................................................................... 29
Abb 3.17: Fehlerhaft ermittelter Standort aufgrund von Uhrenfehlern ............................................................................. 30
Abb 3.18: Korrekt ermittelter Standort dank Korrektur des Uhrenfehlers mit einem weiteren Satelliten .......................... 30
Abb 3.19: Galileo Testgebiet in Berchtesgaden, Quelle: [GAT10] ................................................................................. 32
Abb 3.20: Ablauf eines Notrufs bei Galileo, Quelle: [Zog06] .......................................................................................... 33
Abb 3.21: Landwirtschaftliches Parallelfahrsystem, Quelle: [Top07] ............................................................................. 34
Abb 3.22: Zusammenhang zwischen Genauigkeit und Integrität bezogen auf verschiedene Anwendungsgebiete ...... 35
Abb 3.23: Empfang durch Beugung ............................................................................................................................... 37
Abb 3.24: Empfang durch Reflexion ............................................................................................................................... 37
Abb 3.25: Mehrwegeempfang (direkt und reflektiert) ...................................................................................................... 37
Abb 3.26: Niedrige Richtigkeit und Präzision .................................................................................................................. 39
Abb 3.27: Niedrige Richtigkeit und hohe Präzision ......................................................................................................... 39
Abb 3.28: Hohe Richtigkeit aber niedrige Präzision ........................................................................................................ 39
Abb 3.29: Hohe Richtigkeit und hohe Präzision .............................................................................................................. 39
Abb 3.30: Stehen Satelliten nahezu orthogonal zueinander, ergibt sich die kleinstmögliche Fehlerfläche ..................... 39
Abb 3.31: Stehen Satelliten nahe beieinander, ergibt sich eine große Fehlerfläche ....................................................... 39
Abb 3.32: Großes Volumen - Kleiner DOP-Wert.............................................................................................................. 39
Abb 3.33: Kleines Volumen - großer DOP-Wert .............................................................................................................. 39
Abb 3.34: 24-Stunden Verlauf des HDOPs ohne Abschattung (max HDOP<1.9), Quelle: [Zog09a] ............................. 40
Abb 3.35: 24-Stunden Verlauf des HDOPs mit starker Abschattung (max HDOP>20), Quelle: [Zog09a] ..................... 40
Abb 3.36: Doppelter mittlerer Punktfehler 2drms .............................................................................................................. 42
Abb 3.37: Geometrische Interpretation des mittleren Punktfehlers ................................................................................. 42
Abb 3.38: Grundaufbau eines Differential GPS Systems ................................................................................................ 43
Abb 3.39: U-blox Antaris AEK-4T, Quelle: www.u-blox.com ........................................................................................... 45
Abb 3.40: Trimble GeoBeacon-Empfänger, Quelle: www.trimble.com ........................................................................... 46
Abb 3.41: Funktionsprinzip der Differenzposition ........................................................................................................... 49
Abb 3.42: Satellitenauswahl durch Einschränkung des minimalen Erhebungswinkels auf 35° ....................................... 50
Abb 3.43: Messverlauf eTrex Vista HCx .......................................................................................................................... 53
Abb 3.44: eTrex Vista HCx Histogramm der Längen- (oben) und Breitengrade (unten) ................................................. 53
Abb 3.45: Messverlauf eTrex Vista HCx .......................................................................................................................... 54
Abb 3.46: eTrexH Histogramm der Längen- (oben) und Breitengrade (unten) ............................................................... 54
Abb 3.47: Messverlauf Navilock 402u ............................................................................................................................. 55
Abb 3.48: Navilock 402u Histogramm der Längen- (oben) und Breitengrade (unten) .................................................... 55
Abb 3.49: Messverlauf Conrad CR4 ................................................................................................................................ 55
Abb 3.50: Conrad CR4 Histogramm der Längen- (oben) und Breitengrade (unten) ...................................................... 55
113
Anhang C
Abb 3.51: Fotostativ mit Quertraverse und montierten Empfängern ............................................................................... 56
Abb 3.52: Einzelgrafiken der Parallelmessung mit fünf Empfängern .............................................................................. 56
Abb 3.53: Ergebnis der Mittelung ................................................................................................................................... 57
Abb 3.54: Mittelung überlagert mit den Messwerten der einzelnen Empfänger.............................................................. 57
Abb 3.55: Mittlerer Punktfehler bei unterschiedlichen Empfängeranzahlen .................................................................... 57
Abb 3.56: Untersuchung des EGNOS Empfangs, Garmin eTrex H ................................................................................ 58
Abb 3.58: Vergleich der Korrekturdaten von EGNOS (links) und SAPOS EPS (rechts) zum gleichen Zeitpunkt ............ 59
Abb 3.57: Netz der verfügbaren EGNOS Bezugspunkte in Europa, Quelle: [Bun10] .................................................... 59
Abb 3.59: Testfahrt mit unterschiedlichen Empfängern .................................................................................................. 60
Abb 3.60: Auswertung mehrerer paralleler Empfänger bei einer bewegten Messung, ................................................... 61
Abb 3.61: Untersuchungen zur Abweichung von Längen- und Breitenposition über 24 Stunden, Quelle: [GPS10] ..... 61
Abb 4.1: Gegenüberstellung der Speicherung von Geodaten am Beispiel eines Sees .................................................. 63
Abb 4.2: Unterschiedliche Qualität der Abdeckung am Beispiel von Bagdhad,............................................................. 64
Abb 4.3: OSM-Aktivität in Europa 2008, Quelle www.itoworld.com ................................................................................. 64
Abb 4.4: Aufbau der OpenStreetMap ............................................................................................................................. 65
Abb 4.5: Vergleich einer topografischen Karte (links) mit der OSM-Karte (rechts), ........................................................ 66
Abb 4.6: Vereinfachtes Datenmodell von OSM ............................................................................................................... 66
Abb 4.7: Berechnungsvorschrift zur Bestimmung der Koordinaten für die nächste Zoomstufe ...................................... 70
Abb 4.8: Vergleich der Darstellung zwischen Mapnik- (links) und Osmarender-Layer (rechts), ..................................... 70
Abb 4.9: Java OpenStreetMap Editor (JOSM) ................................................................................................................ 74
Abb 4.10: Vereinfachung nach Douglas und Peucker, Quelle: [Wik09] ......................................................................... 75
Abb 4.11: Kartendarstellung eines Online-Navigationsprogramms ................................................................................ 76
Abb 4.12: Unterschiedliche Kachelselektionsstrategien bei Precachingverfahren ......................................................... 77
Abb 5.1: Prinzip der Layout Korrektur für unterschiedliche Fahrtrichtungen ................................................................... 81
Abb 5.2: : Prioritätsbasiertes Precaching für eine rechteckige Fläche ............................................................................ 82
Abb 5.3: Internes Datenmodell ....................................................................................................................................... 82
Abb 5.4: Grundprinzip des Street Matching Verfahrens ................................................................................................. 84
Abb 5.5: Prinzip der Vereinfachung einer GPS-Aufzeichnung ........................................................................................ 85
Abb 5.6: Ablauf des automatisierten Mappings .............................................................................................................. 85
Abb 5.7: Übersicht über die Komponenten ..................................................................................................................... 88
Abb 6.1: Basisklassen und Schnittstellen der Komponentenarchitektur, Darstellung vereinfacht .................................. 92
Abb 6.2: Klassen zur internen Repräsentation der Geodaten ......................................................................................... 93
Abb 6.3: Sequenzdiagramm zur Darstellung des Load-Balancing Verfahrens ............................................................... 94
Abb 6.4: Darstellung bei der Erfassung einer neuen Straße ........................................................................................... 95
Abb 6.5: Darstellung von Darmstadt mit eingezeichneten Kacheln ................................................................................ 95
Abb 7.1: Gegenüberstellung der Testfahrt-Resultate. ................................................................................................... 102
114
Anhang D
Tabellenverzeichnis
Tabelle 2.1: Wichtige Geodätische Daten (vgl. [deL06] ) ................................................................................................. 9
Tabelle 2.2: Global angepasste Referenzellipsoide, Quelle: [Wik10i] ............................................................................ 10
Tabelle 2.3: Benennungsschema der Gauß-Krüger Zonen ............................................................................................ 12
Tabelle 2.4: Benennungsschema der UTM Zonen .......................................................................................................... 13
Tabelle 2.5: Verschiedene Standard-Parametersätze in Deutschland ............................................................................ 15
Tabelle 2.6: Parametersatz für die Umwandlung von DHDN nach ETRS 89 in Hessen, Quelle: [Hec07a] .................... 15
Tabelle 2.7: Wichtige EPSG-Codes ................................................................................................................................. 16
Tabelle 3.1: Geringe Korrelation zwischen Eingangssignal A und vorlaufendem Referenzsignal B (Zeit t+5 Chips) ..... 27
Tabelle 3.2: Maximale Korrelation zwischen Eingangssignal A und synchronem Referenzsignal B ............................... 27
Tabelle 3.3: Geringe Korrelation zwischen Eingangssignal A und nachlaufendem Referenzsignal B (Zeit t-5 Chips).... 27
Tabelle 3.4: Fehlerbilanz für GPS ohne Korrekturinformationen, Zahlen aus [Köh08c] .................................................. 38
Tabelle 3.5: Die verschiedenen DOP-Kenngrößen ......................................................................................................... 40
Tabelle 3.6: NMEA Gerätearten, Quelle: [NME02] ......................................................................................................... 51
Tabelle 3.7: Für GPS definierte NMEA-Datensätze, Quelle: [NME02] ............................................................................ 51
Tabelle 3.8: Auswertung eines GPRMC-Datensatzes in der Reihenfolge der Datenfelder.............................................. 52
Tabelle 3.9: Zusammenfassung der Einzelmessungen ................................................................................................... 55
Tabelle 3.10: Einzelergebnisse der Parallelmessung mit fünf Empfängern ..................................................................... 56
Tabelle 3.11: Auswertung der Mittelung gegenüber allen Einzelmesswerten ................................................................. 57
Tabelle 3.12: Ergebnisse der Messungen mit EGNOS-Empfang .................................................................................... 58
Tabelle 4.1: Ausgewählte OSM-XML-Tags ...................................................................................................................... 67
Tabelle 4.2: Wichtige Methoden der API, nach [Ram09] ............................................................................................... 71
Tabelle 5.1: Grobe Einteilung in verschiedene highway-Tag-Klassen anhand der gefahrenen Geschwindigkeiten ...... 83
Tabelle 7.1: Gegenüberstellung der Ladedauer für unterschiedliche Konstellationen mit DSL .................................... 101
Tabelle 7.2: Gegenüberstellung der Ladedauer für unterschiedliche Konstellationen mit UMTS ................................. 101
115
Anhang D
Tabellenverzeichnis
Tabelle 7.3: Gegenüberstellung der Ladedauer für unterschiedliche Konstellationen mit EDGE ................................. 101
116
Anhang E
Listings
Listing 4.1: Rahmen eines OSM-XML-Dokuments ........................................................................................................... 68
Listing 4.2: Beispiele von OSM-XML-Tags ...................................................................................................................... 68
Listing 4.3: Beispiel eines OSM-XML-Nodes ................................................................................................................... 68
Listing 4.4: Beispiel eines OSM-XML-Ways..................................................................................................................... 69
Listing 4.5: Beispiel einer OSM-XML-Relation ................................................................................................................. 69
Listing 4.6: Vereinfachtes osmChange-Dokument .......................................................................................................... 72
Listing 6.1: Beispiel eines cURL-Aufurfs. ........................................................................................................................ 90
Listing 6.2: GeographicLib-Aufrufe zur Punktprojektion und zur Abstandsberechnung ................................................. 91
Listing 6.3: Anmelden und auslösen von Events ............................................................................................................. 92
Listing 6.4: Anwendung des NtripClients ........................................................................................................................ 96
Listing 6.5: Container für NMEA-GPRMC Datensatz ....................................................................................................... 96
Listing 6.6: Berechnung der korrigierten Position ........................................................................................................... 97
Listing 6.7: Awenden der Schnittmethode zur Selektion der Kacheln. ............................................................................ 98
Listing 6.8: Funktion zur Berechnung des Abstands eines Punktes zu einer Strecke ..................................................... 98
Listing 6.9: osmChange-Dokument zum Hinzufügen einer neuen Straße ....................................................................... 99
117
Anhang F
Literaturverzeichnis
[cUR10] cURL - libcurl. [Online] [Zuletzt besucht am: 26. März 2010.] http://curl.haxx.se/libcurl/.
[Ubu09] Ubuntu Deutschland e. V. . 2009. gpsd. [Online] 2009. [Zuletzt besucht am: 26. März 2010.]
http://wiki.ubuntuusers.de/gpsd.
[Aue04] Auerswald, Dipl.-Ing. Frank. 2004. SAPOS-EPS : Viel Sicherheit für kleines Geld. Landesamt für Vermessung
und Geoinformation Thüringen. Erfurt : 2004.
[Aug01] Augath, Prof. Dr.-Ing. Wolfgang. 2001. Beiträge des Vermessungswesens zur Ortung. Geodätisches Institut,
TU Dresden. Dresden, 2001.
[aut09] auto motor und sport. 2009. Opel-Eye und Blaupunkt-Gerät im Vergleich . [Online] 2009. [Zuletzt besucht am:
23. März 2010.] http://www.auto-motor-und-sport.de/testbericht/verkehrschilder-erkennung-im-test-1324415.html.
[Bag01] Bagge, Andreas. 2001. DGPS Data Formats 2.0. Garbsen : Geo++® Gesellschaft für satellitengestützte
geodätische und navigatorische Technologien mbH, 2001.
[Bau97] Bauer, Manfred. 1997. Vermessung und Ortung mit Satelliten: NAVSTAR-GPS und andere satellitengestützte
Navigationssysteme. 4., völlig überarbeitete Auflage. Heidelberg : Wichmann Verlag, 1997.
[Bra05] Brakatsoulas, Sotiris, et al. 2005. On Map-Matching Vehicle Tracking Data. In: Proceedings of the 31st VLDB
Conference. Trondheim, Norway, 2005.
[Bra09] Brandt, Matthias. 2009. Vespucci: Entwicklung eines Geodateneditors für das OpenStreetMap-Projekt auf der
Android-Plattform. Fachbereich Medieninformatik, Fachhochschule Wedel. Hamburg, 2009.
118
Anhang F
[Bri06] Brinkhoff, Prof. Dr. Thomas. 2006. Geodatenbanksysteme : Gestern, Heute und Morgen. In: Photogrammetrie,
Fernerkundung, Geoinformation (PFG), Heft 5. 2006.
[Bri08] —. 2008. Geodatenbanksysteme in Theorie und Praxis. 2. Auflage. Heidelberg : Wichmann-Verlag, 2008.
[Bri07] —. 2007. Open-Source-Geodatenbanksysteme. In: Datenbank-Spektrum, Heft 22. 2007.
[Bun10] Bundesamt für Kartographie und Geodäsie (BKG). 2010. EGNOS-IP Ntrip Broadcaster. [Online] 2010. [Zuletzt
besucht am: 19. März 2010.] http://www.egnos-ip.net/home.
[CrC10] Creative Commons. 2010. About Licenses. [Online] 2010. [Zuletzt besucht am: 23. März 2010.]
http://creativecommons.org/about/licenses.
[Dan99] Dana, Peter H. 1999. Global Positioning System Overview. [Online] 1999. [Zuletzt besucht am: 14. März
2010.] http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html.
[deL06] de Lange, Norbert. 2006. Geoinformatik: in Theorie und Praxis. 2. aktualisierte und erweiterte Auflage.
Heidelberg : Springer-Verlag, 2006.
[Der01] Derenbach, Dipl.-Ing. Heinrich. 2001. Satellitenpositionierung mit SAPOS. Landesvermessungsamt BadenWürttemberg. Karlsruhe, 2001.
[Elk08] Ehlke, Thomas. 2008. Teure Karten aus Internet. [Online] 2008. [Zuletzt besucht am: 20. März 2010.]
http://www.allgemeine-zeitung.de/region/alzey/vg-woellstein/woellstein/4880119.htm.
[Fie00] Fielding, Roy Thomas. 2000. Representational State Transfer (REST). [Online] 2000. [Zuletzt besucht am: 22.
März 2010.] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm.
[Fri07] Fried, Dr. J. Michael. 2007. Mathematik für Ingenieure A IV: Ergodizität. Lehrstuhl Angewandte Mathematik,
Universität Erlangen. Erlangen, 2007.
[GAT10] GATE. 2010. The German GALILEO Test and Development Environment. [Online] 2010. [Zuletzt besucht am:
15. März 2010.] http://www.gate-testbed.com/.
[Gen00] Gendt, Michael, Oheim, Frank und Gehrke, Stephan. 2000. Koordinatentransformationen - mittels einer
analytischen Lösung der Gaußschen Abbildung. Geodätisches Seminar, TU Berlin. Berlin : 2000.
[GIS06] GISWiki. 2006. Gauß-Krüger-Koordinatensystem. [Online] 2006. [Zuletzt besucht am: 09. März 2010.]
http://www.en.giswiki.org/wiki/Gauß-Krüger-Koordinatensystem.
[Gla07] Glaab, Markus. 2007. Konzeption und Entwicklung einer Simulationsumgebung für
Fahrzeugkommunikationssysteme. Fachbereich Informatik, Hochschule Darmstadt. Darmstadt : 2007.
[GPS10] GPSBabel. 2010. What is GPSBabel? [Online] 2010. [Zuletzt besucht am: 23. März 2010.]
http://www.gpsbabel.org/.
[Gruber08] Gruber, Franz Josef und Joeckel, Rainer. 2008. Formelsammlung für das Vermessungswesen. 14.
Auflage. Wiesbaden : Vieweg Verlag, 2008.
119
Anhang F
[Gür09] Gürbüz, Erhan und Siebert, Sascha. 2009. Konzeption und prototypische Umsetzung eines
Interaktionssystems unter Verwendung mobiler Projektion und ausgewählter Trackingverfahren. Fachbereich
Informatik, Hochschule Darmstadt. Darmstadt, 2009.
[Hab09] Habermehl, Prof. Dr.-Ing. K., et al. 2009. Geodäsie 1. Fachbereich Bauingenieurwesen, Hochschule
Darmstadt. Darmstadt, 2009.
[Hak08] Haklay, Mordechai und Weber, Patrick. 2008. OpenStreetMap: User-Generated Street Maps. IEEE Pervasive
Computing Volume 7 , Issue 4. 2008.
[Hec04] Heckmann, Dipl.-Ing. Bernhard. 2004. Einführung des Lagebezugssystems ETRS89/UTM beim Umstieg auf
ALKIS. Wiesbaden : Hessische Verwaltung für Bodenmanagement und Geoinformation, 2004.
[Hec07a] —. 2007. Endgültige Transformationsparameter zwischen dem Hessischen Lagestatus 100 (PotsdamDatum) und dem Europäischen Terrestrischen Referenzsystem 1989 (ETRS89). Wiesbaden : Hessisches Landesamt
für Bodenmanagement und Geoinformation, 2007.
[Hec07b] —. 2007. Transformation des ETRS89 in den Hessischen Lagestatus 100: Lagerestklaffungen in den 80
Passpunkten. Wiesbaden : Hessisches Landesamt für Bodenmanagement und Geoinformation, 2007.
[hei08] heise. 2008. Freier Hamburger Straßenplan praktisch komplett. [Online] 2008. [Zuletzt besucht am: 20. März
2010.] http://www.heise.de/open/meldung/Freier-Hamburger-Strassenplan-praktisch-komplett-213264.html.
[HLG09] Hessisches Landesamt für Bodenmanagement und Geoinformation. Echtzeit-Positionierungsdienst (EPS).
[Online] http://www.hvbg.hessen.de/, 2009, zuletzt besucht am 18.03.2010.
[Hop06] Hoppe, Dipl.-Ing. (FH) Michael. 2006. Technische Daten, Systemparameter und Aufbau der DGPS
Referenzstationen nach IALA Standard. Wasser- und Schifffahrtsverwaltung des Bundes. Koblenz, 2006.
[Jot01] Jotzo, Dipl.-Ing. Joachim. 2001. Aktive Landmarken zur Positionsbestimmung von autonomen Fahrzeugen.
Fakultät für Elektrotechnik und Informationstechnik, TU Chemnitz. Chemnitz, 2001.
[Kah93] Kahmen, Prof. Dr.-Ing. Heribert. 1993. Vermessungskunde. 18. völlig neu bearbeitete und erweiterte Auflage.
Berlin : de Gruyter, 1993.
[Kar10] Karney, Charles. 2010. Geographic library - Documentation. [Online] 2010. [Zuletzt besucht am: 27. März
2010.] http://geographiclib.sourceforge.net/html/index.html.
[Kno06] Knopp, Olaf. 2006. OGC konforme Geodatenhaltung: Die Simple Feature Spezifikationen des OGC. Open
Geospatial Consortium. 2006.
[Köh08a] Köhne, Dr. Anja und Wößner, Dr. Michael. 2008. Ausgesendete GPS-Signale. [Online] 2008. [Zuletzt
besucht am: 13. März 2010.] http://www.kowoma.de/gps/Signale.htm.
[Köh08b] —. 2008. Bodenstationen. [Online] 2008. [Zuletzt besucht am: 12. März 2010.]
http://www.kowoma.de/gps/Bodenstationen.htm.
[Köh07] —. 2007. Positionsbestimmung. [Online] 2007. [Zuletzt besucht am: 13. März 2010.]
http://www.kowoma.de/gps/Positionsbestimmung.htm.
120
Anhang F
[Köh08c] —. 2008. Fehlerquellen bei GPS. [Online] 2008. [Zuletzt besucht am: 15. März 2010.]
http://www.kowoma.de/gps/Fehlerquellen.htm.
[Köh08d] —. 2008. WAAS/EGNOS. [Online] 2008. [Zuletzt besucht am: 18. März 2010.]
http://www.kowoma.de/gps/waas_egnos.htm.
[Köh09a] —. 2009. Aufbau des Datensignals. [Online] 2009. [Zuletzt besucht am: 13. März 2010.]
http://www.kowoma.de/gps/Signalaufbau.htm.
[Köh09b] —. 2009. Laufzeitmessung der Signale. [Online] 2009. [Zuletzt besucht am: 13. März 2010.]
http://www.kowoma.de/gps/Signalverschiebung.htm.
[Köh09c] —. 2009. Präzision, Richtigkeit und Genauigkeit. [Online] 2009. [Zuletzt besucht am: 16. März 2010.]
http://www.kowoma.de/gps/zusatzerklaerungen/Praezision.htm.
[Köh10] —. 2010. GPS-Monitor. [Online] 2010. [Zuletzt besucht am: 17. März 2010.]
http://www.kowoma.de/gps/gpsmonitor/gpsmonitor.php.
[Kom10] Kompf, Martin. Sonne und Erde - Entfernungsberechnung. [Online] [Zuletzt besucht am: 10. März 2010.]
http://www.kompf.de/gps/distcalc.html.
[Kra99] Krause, Diana. 1999. Bestimmung der Parameter für die Transformation des DHDN-Systems in das ETRS 89System. Astronomische und Physikalische Geodäsie, TU Berlin. Berlin, 1999.
[Lab02] Labonde, Ottmar. 2002. Ergebnisse von Synchron-Messungen mit zwei GPS-Empfängern gleichen Typs.
[Online] 2002. [Zuletzt besucht am: 18. März 2010.] http://www.ottmarlabonde.de/L1/GPS_DIF.html.
[LVB09] Landesamt für Vermessung Geoinformation Bayern. 2009. UTM-Abbildung und UTM-Koordinaten. München,
2009.
[Len04] Lenz, Elmar. 2004. Networked Transport of RTCM via Internet Protocol (NTRIP): Application and Benefit in
Modern Surveying Systems. In: FIG Working Week. Athen, Griechenland, 2004.
[LeG10] Lexikon der Geowissenschaften. Geoid. [Online] [Zuletzt besucht am: 08. März 2010.]
http://www.wissenschaft-online.de/abo/lexikon/geo/5630.
[Lut08] Lutz, Dipl.-Ing. Andre. 2008. Realisierung und Bewertung von Navigationsmethoden zur fahrzeugautonomen
Positionsbestimmung mit low-cost Sensorik. Fachbereich Maschinenbau, TU Darmstadt. Darmstadt, 2008.
[Man04] Mansfeld, Werner. 2004. Satellitenortung und Navigation: Grundlagen und Anwendung globaler
Satellitennavigationssysteme. 2. Auflage. Wiesbaden : Vieweg Verlag, 2004.
[MaC00] Mapping Applications Center. 2000. Map Projections. Reston, Virgina : U.S. Geological Survey, 2000.
[Mül04] Müller, Dominik. 2004. Untersuchungen zur Nutzung von EGNOS und GPS. Fachbereich Geoinformatik und
Vermessung, Fachhochschule Mainz. Mainz, 2004.
[NME02] National Marine Electronics Association. 2002. NMEA 0183: Standard For Interfacing Marine Electronic
Devices. Severna Park, USA, 2002.
121
Anhang F
[Nav10] Navigon - Shop. 2010. Europakarte. [Online] 2010. [Zuletzt besucht am: 20. März 2010.]
http://www.navigon.com/portal/de/shop/addons/produkt.html?produktFamilieId=15674&produktId=19482.
[Nov10] Novatel. 2010. RTKNav Product Brochure. Alberta, 2010.
[Och02] Ochieng, W.Y., Quddus, M. und Noland, R.B. 2002. Map-Matching in complex urban road networks. In:
Revista Brasileira de Cartografia, Heft 55. 2002.
[OPE10] Open-Report.de. 2010. Deutschland und Frankreich dringen auf Satellitensystem «Galileo». [Online] 2010.
[Zuletzt besucht am: 15. März 2010.] http://www.openreport.de/artikel/Deutschland+und+Frankreich+dringen+auf+Satellitensystem+Galileo.html.
[OSM09a] OpenStreetMap. 2009. API v0.6. [Online] 2009. [Zuletzt besucht am: 22. März 2010.]
http://wiki.openstreetmap.org/wiki/API_v0.6.
[OSM09b] —. 2009. Elemente. [Online] 2009. [Zuletzt besucht am: 21. März 2010.]
http://wiki.openstreetmap.org/wiki/DE:Elemente.
[OSM10a] —. 2010. API v0.6/DTD. [Online] 2010. [Zuletzt besucht am: 22. März 2010.]
http://wiki.openstreetmap.org/wiki/API_v0.6/DTD.
[OSM10b] —. 2010. Map Features. [Online] 2010. [Zuletzt besucht am: 21. März 2010.]
http://wiki.openstreetmap.org/wiki/Map_Features.
[OSM10c] —. 2010. OSM Map On Garmin/Download. [Online] 2010. [Zuletzt besucht am: 23. März 2010.]
http://wiki.openstreetmap.org/wiki/DE:OSM_Map_On_Garmin/Download.
[OSM10d] —. 2010. Presseinformation. [Online] 2010. [Zuletzt besucht am: 20. März 2010.]
http://wiki.openstreetmap.org/wiki/DE:Presseteam/Presseinformation.
[OSM10e] —. 2010. Slippy Map. [Online] 2010. [Zuletzt besucht am: 21. März 2010.]
http://wiki.openstreetmap.org/wiki/DE:Slippy_Map.
[OSM10f] —. 2010. Slippy map tilenames. [Online] 2010. [Zuletzt besucht am: 21. März 2010.]
http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames.
[OSM10g] —. 2010. TRAPI. [Online] 2010. [Zuletzt besucht am: 23. März 2010.]
http://wiki.openstreetmap.org/wiki/Trapi.
[OSM09c] —. 2009. Mobile Binary Protocol. [Online] 2009. [Zuletzt besucht am: 23. März 2010.]
http://wiki.openstreetmap.org/wiki/OSM_Mobile_Binary_Protocol.
[Ott09] Otto, Christian. 2009. Design und Evaluation eines Offline-Kartendienstes auf der Grundlage von
Openstreetmap unter Verwendung von Precachingverfahren. Institut für Informatik, Humboldt-Universität zu Berlin.
Berlin, 2009.
[Pel05] Pellenz, Johannes. 2005. Verbesserte GPS-Positionsschätzung mit IP-transportierten Korrekturdaten für
autonome Systeme im Outdoor-Bereich. Universität Koblenz-Landau. 2005.
122
Anhang F
[Pid09] Pidor, Marloue. 2009. OSM Cheat Sheet. 2009.
[Pri09] Prinz, Dr. Torsten. 2009. DGPS-Messung im Gelände mittels RTCM-Modem und Vergleich mit TP-Koordinaten.
[Online] 2009. [Zuletzt besucht am: 18. März 2010.] http://ivvgeo.unimuenster.de/Vorlesung/GPS_Script/praktikum10.html.
[Ram09] Ramm, Frederik und Topf, Jochen. 2009. OpenStreetMap: Die freie Weltkarte nutzen und mitgestalten. 2.
überarbeitete und erweiterte Auflage. Berlin : Lehmanns Media, 2009.
[Rot05] Rothacher, Univ.-Prof. Dr.phil.nat. Markus. 2005. Satelliten Geodäsie 1: Einführung in GPS. Institut für
Astronomische und Physikalische Geodäsie, TU München. München, 2005.
[Roy04] Royal Observatory of Belgium. 2004. GPS dictionary. [Online] 2004. [Zuletzt besucht am: 14. März 2010.]
http://www.gps.oma.be/gb/dic_gb_ok_css.htm.
[RPO09] RP-Online.de. 2009. EGNOS in Betrieb genommen: Navigationssysteme werden genauer. [Online] 2009.
[Zuletzt besucht am: 18. März 2010.] http://www.rp-online.de/auto/news/Navigationssysteme-werdengenauer_aid_764951.html.
[Ral01] Schönfeld, Ralf. 2001. GPS Handgeräte in der Praxis Teil 4: Tipps und Hinweise beim praktischen Einsatz.
[Online] 2001. [Zuletzt besucht am: 15. März 2010.] http://kanadier.gps-info.de/d-tipps.htm.
[Sch06] Schwieger, Volker und Wanninger, Lambert. 2006. Potential von GPS Navigationsempfängern. Institut für
Anwendungen der Geodäsie im Bauwesen, Universität Stuttgart. Stuttgart, Dresden, 2006.
[sko10] skobbler GmbH. 2010. skobbler. [Online] 2010. [Zuletzt besucht am: 23. März 2010.] http://beta.skobbler.de/.
[Stö09b] Störl, Prof. Dr. Uta. 2009. Datenbanken und XML. Fachbereich Informatik, Hochschule Darmstadt.
Darmstadt : 2009.
[Stö09a] —. 2009. Geodatenbanksysteme. Fachbereich Informatik, Hochschule Darmstadt. Darmstadt : 2009.
[Stü04] Stürzl, Wolfgang. 2004. Sensorik und Bildverarbeitung für Landmarken-basierte Navigation. Max-PlanckInstituts für biologische Kybernetik, Eberhard Karls Universität Tübingen. Tübingen, 2004.
[Tak08] Takasu, Tomoji und Yasuda, Akio. 2008. Evaluation of RTK-GPS Performance with Low-cost Single-frequency
GPS Receivers. Funai Laboratory of Satellite Navigation, Tokyo University of Marine Science and Technology. Tokio,
Japan, 2008.
[Tay00] Taylor, Dr. George. 2000. Line Simplification Algorithms. Department of Surveying, University of Newcastle
upon Tyne. Newcastle upon Tyne, UK, 2000.
[Top07] Top Agrar - Online. 2007. GPS und DGPS-Korrekturdienste. [Online] 2007. [Zuletzt besucht am: 15. März
2010.] http://www.topagrar.com/index.php?option=com_content&task=view&id=299&Itemid=410.
[Wan08] Wanninger, Lambert. 2008. Netz-RTK. Geodätisches Institut, TU Dresden. Dresden, 2008.
[Wel03] Weltzien, Dipl.-Ing. Cornelia. 2003. GPS-Empfänger Vergleich: Genauigkeit der statischen und dynamischen
Positionierung. Potsdam, 2003.
123
Anhang F
[Wie04] Wiebel, Hendrik. 2004. Tesselierung von Oberflächen. Institut für Computervisualistik, Universität Koblenz
Landau. Koblenz : 2004.
[Wie05] Wietzke, Prof. Dr. Joachim und Tran, Prof. Dr. Manh Tien. 2005. Automotive Embedded Systems.
Heidelberg : Springer-Verlag, 2005.
[Wik09] Wikipedia. 2009. Douglas-Peucker-Algorithmus. [Online] 2009. [Zuletzt besucht am: 24. März 2010.]
http://de.wikipedia.org/wiki/Douglas-Peucker-Algorithmus.
[Wik10a] —. 2010. Galileo (Satellitennavigation). [Online] 2010. [Zuletzt besucht am: 15. März 2010.]
http://de.wikipedia.org/wiki/Galileo_(Satellitennavigation).
[Wik10b] —. 2010. Geodäsie. [Online] 2010. [Zuletzt besucht am: 08. März 2010.]
http://de.wikipedia.org/wiki/Geodäsie.
[Wik10c] —. 2010. Geoid. [Online] 2010. [Zuletzt besucht am: 08. März 2010.] http://de.wikipedia.org/wiki/Geoid.
[Wik10d] —. 2010. Global Positioning System. [Online] 2010. [Zuletzt besucht am: 12. März 2010.]
http://de.wikipedia.org/wiki/Global_Positioning_System.
[Wik10e] —. 2010. GLONASS. [Online] 2010. [Zuletzt besucht am: 15. März 2010.]
http://de.wikipedia.org/wiki/GLONASS.
[Wik10f] —. 2010. GPS-Technik. [Online] 2010. [Zuletzt besucht am: 12. März 2010.] http://de.wikipedia.org/wiki/GPSTechnik.
[Wik10g] —. 2010. Kartografie. [Online] 2010. [Zuletzt besucht am: 08. März 2010.]
http://de.wikipedia.org/wiki/Kartografie.
[Wik10h] —. 2010. Observer (Entwurfsmuster). [Online] 2010. [Zuletzt besucht am: 24. März 2010.]
http://de.wikipedia.org/wiki/Observer_(Entwurfsmuster).
[Wik10i] —. 2010. Referenzellipsoid. [Online] 2010. [Zuletzt besucht am: 09. März 2010.]
http://de.wikipedia.org/wiki/Referenzellipsoid.
[Wik10j] —. 2010. Trigonometrischer Punkt. [Online] 2010. [Zuletzt besucht am: 10. März 2010.]
http://de.wikipedia.org/wiki/Trigonometrischer_Punkt.
[Wik10k] —. 2010. UTM-Koordinatensystem. [Online] 2010. [Zuletzt besucht am: 09. März 2010.]
http://de.wikipedia.org/wiki/UTM-Koordinatensystem.
[Wik10l] —. 2010. ACID. [Online] 2010. [Zuletzt besucht am: 26. März 2010.] http://de.wikipedia.org/wiki/ACID.
[Wik10m] —. 2010. OpenGL. [Online] 2010. [Zuletzt besucht am: 27. März 2010.] http://de.wikipedia.org/wiki/Opengl.
[Wil10] Williams, Ed. Aviation Formulary V1.44. [Online] [Zuletzt besucht am: 10. März 2010.]
http://williams.best.vwh.net/avform.htm.
[Win10] Winkler, Jan. HTTP: Request-Methoden. [Online] [Zuletzt besucht am: 22. März 2010.] http://www.htmlworld.de/program/http_3.php.
124
Anhang F
[Zog09b] Zogg, Prof. Dipl.-Ing. FH Jean-Marie. 2009. Die Modernisierung des zivilen GPS. In: wireless, Elektronik.
2009. S. 34-37.
[Zog08] —. 2008. Dilution of Presicion : Wie genau ist’s denn nun. In: Navi Magazin. 2008. S. 101.
[Zog07] —. 2007. Galileo und GPS, kritisch betrachtet : Ein Interview mit Professor Jean-Marie Zogg. In: Navi
Magazin. 2007.
[Zog09a] —. 2009. GPS und GNSS: Grundlagen der Ortung und Navigation mit Satelliten. Thalwil : u-blox AG, 2009.
[Zog06] —. 2006. Von GPS zu Galileo : Die Weiterentwicklung der Satelliten-Navigation. In: Elektronik. 2006.
[Zol08] Zollinger, Stefan. 2008. Kartenkritik an OpenStreetMap: Eine systematische Beurteilung der durch Mapnik
visualisierten freien Weltkarte mit Fokus auf die Schweiz. Institut für Kartografie, ETH Zürich. Zürich, 2008.
125
Anhang G
Inhalt der CD-ROM
Auf der beigefügten CD-ROM befindet sich im Wurzelverzeichnis jeweils ein Ordner für




PDF-Auszüge der verwendeten Webseiten
Alle verwendeten Dokument als PDF
Verwendete Bücher, die digital vorlagen
Quellcode des realisierten Prototypen
126

Ansätze zur präziseren Positionsbestimmung mit GPS

Transcription

Similar documents

ETRS89/UTM

Tipps zum Kartenlesen - Bayerische Vermessungsverwaltung

Handbuch zur Kartenkunde - Kartenkunde leichtgemacht

simbología · legend - INEX

Artikel als pdf

Bedienungsanleitung - AG Neovo Service Website

Amt für Vermessung, Kataster und Stadterneuerung Nutzung der

GPS-Empfänger Handbuch

Die Verfügbarkeit und Genauigkeit von EGNOS steigern

English page 1 Français page 32 Español

Bachelorarbeit Referenzimplementierung einer Mach

Mnemo-Grafias Interculturais

GRS-1 – REFERENZNEtZFähiGER GNSS-RtK

Similarity measures