Inhaltsverzeichnis · Aufgabenstellung dieser Arbeit war eine Fahrdatenanalyse auf Basis einer objektrelationalen GeoDatenbank und eines GPS-Empfängers zu ermöglichen. Um dieses

Inhaltsverzeichnis

Abbildungsverzeichnis IV

Tabellenverzeichnis VI

1 Einleitung 11.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Hilfsmittel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Geodäsie 42.1 Geoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Vereinfachte Bezugsflächen . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Koordinatensysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 Geozentrische erdfeste X,Y,Z-Koordinaten . . . . . . . . . . . . . . 72.3.2 Geographische Koordinaten . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Universale Transversale Mercator(UTM)-Projektion . . . . . . . . . . . . . . 10

3 Global Positioning System (GPS) 133.1 Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Einsatzgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Funktionsweise und Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4 Genauigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Aufzeichnung von Fahrzeugdaten 174.1 Predictive Light Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Matlab/Simulink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.3 dSpace-MicroAutoBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.4 Datenaustauschformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Digitale Straßenkarten 215.1 Geographic Data Files (GDF) . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.1.1 GDF-Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.2 Darstellungsebenen . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

I

Inhaltsverzeichnis

5.1.3 Attributkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.1.4 Genauigkeit der Realitätsabbildung . . . . . . . . . . . . . . . . . . 29

5.2 Datenbankmanagementsystem (DBMS) . . . . . . . . . . . . . . . . . . . . 305.2.1 Begriffserklärung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2.2 PostgreSQL 7.4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2.3 PostGIS 0.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.3 Geographische Informationen in der Datenbank . . . . . . . . . . . . . . . . 355.3.1 Fahrstrecke als Points . . . . . . . . . . . . . . . . . . . . . . . . . 365.3.2 Straßenverbindungen als Points . . . . . . . . . . . . . . . . . . . . 375.3.3 Straßennetz als Multilinestrings . . . . . . . . . . . . . . . . . . . . 375.3.4 Stadtgrenze als Polygon . . . . . . . . . . . . . . . . . . . . . . . . 38

6 Betrachter für digitale Karten 416.1 Thuban 1.0.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.1.1 Schnittstellen für Erweiterungen . . . . . . . . . . . . . . . . . . . . 416.1.2 Schnittstelle zur Datenbank . . . . . . . . . . . . . . . . . . . . . . 42

6.2 Erweiterung zur Fahrdatenauswertung . . . . . . . . . . . . . . . . . . . . . 426.2.1 Python 2.3.3 / wxWindows / wxPython . . . . . . . . . . . . . . . . 436.2.2 Erweiterung ”Data Analysis” . . . . . . . . . . . . . . . . . . . . . . 44

7 Fahrdatenauswertung 467.1 Verfügbare Fahrzeugdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.1.1 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477.1.2 Tachosignal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477.1.3 Radumdrehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477.1.4 Rad-Impuls-Zähler . . . . . . . . . . . . . . . . . . . . . . . . . . . 487.1.5 Gierrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.2 Berechnungen aus Radsensoren . . . . . . . . . . . . . . . . . . . . . . . . 497.2.1 Wegelement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507.2.2 Krümmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.2.3 Richtungsänderung . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.3 Bestimmung der Fahrzeugposition . . . . . . . . . . . . . . . . . . . . . . . 537.3.1 GPS-Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.3.2 GPS-Position und Radrotation/Rad-Impuls-Zähler . . . . . . . . . . 547.3.3 GPS-Position, Rad-Impuls-Zähler/Radrotation und Gierrate . . . . . 57

7.4 Map Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.4.1 Lotabbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.4.2 Kritische Lotfällung . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.5 Auswertung des Fahrverhaltens . . . . . . . . . . . . . . . . . . . . . . . . . 627.5.1 Auswertung der Fahrtgeschwindigkeit . . . . . . . . . . . . . . . . . 627.5.2 Auswertung der erlaubten Fahrtrichtung . . . . . . . . . . . . . . . . 627.5.3 Auswertung von Überholvorgängen . . . . . . . . . . . . . . . . . . 64

II

Inhaltsverzeichnis

7.6 Datenexport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657.6.1 Extensible Markup Language (XML) . . . . . . . . . . . . . . . . . 657.6.2 Export aus Thubanerweiterung . . . . . . . . . . . . . . . . . . . . . 65

8 Resümee 678.1 Überprüfung der Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . 678.2 Ausblicke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Literaturverzeichnis 68

A Entity Relationship Model (GDF-Ebene 0 bis 2) 70A.1 Ebene 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70A.2 Ebene 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71A.3 Ebene 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

B Quelltext 73B.1 Einfache Thuban-Erweiterung . . . . . . . . . . . . . . . . . . . . . . . . . 73

C Erklärung zur Diplomarbeit 75

III

Abbildungsverzeichnis

2.1 Geoid (allgemein) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 WGS-84 Geoid (NIMA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Rotationsellipsoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Definition der geographischen Breite und Länge . . . . . . . . . . . . . . . . 82.5 UTM-Projektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6 Nord- und Ostwert (UTM) . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.7 UTM-Koordinaten und Zonenfelder für Deutschland . . . . . . . . . . . . . 122.8 UTM-Berechnung mit PostgreSQL/PostGIS . . . . . . . . . . . . . . . . . . 12

3.1 Satelliten des NAVSTAR-GPS . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Ortung im dreidimensionalen Raum . . . . . . . . . . . . . . . . . . . . . . 163.3 Genauigkeit verschiedener GPS-Verfahren . . . . . . . . . . . . . . . . . . . 16

4.1 Fahrzeug, dSpace-Box, Matlab . . . . . . . . . . . . . . . . . . . . . . . . . 184.2 MicroAutoBox der Firma dSpace . . . . . . . . . . . . . . . . . . . . . . . . 19

5.1 Beziehung zwischen Data Records . . . . . . . . . . . . . . . . . . . . . . . 235.2 GDF-Data-Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.3 Entity Relationship Model (GDF - Level 0) . . . . . . . . . . . . . . . . . . 245.4 Darstellung in Level 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.5 Darstellung in Level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.6 Darstellung in Level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.7 Segmentieres Attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.8 Digitalisierung von Kurven . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.9 psql, pgAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.10 Darstellung einer GDF-Datei (TeleAtlas GDF Viewer) . . . . . . . . . . . . 355.11 Fahrstrecke als Menge von Punkten . . . . . . . . . . . . . . . . . . . . . . 365.12 Straßenverbindungen als Menge von Punkten . . . . . . . . . . . . . . . . . 375.13 Straßen als Linienzüge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.14 Straßenverbindungen mit Straßen . . . . . . . . . . . . . . . . . . . . . . . . 395.15 Stadtgrenze von Osnabrück als Polygon . . . . . . . . . . . . . . . . . . . . 40

6.1 Geodatenbetrachter ”Thuban” . . . . . . . . . . . . . . . . . . . . . . . . . 41

IV

Abbildungsverzeichnis

6.2 Thuban-Erweiterung zur Fahrdatenauswertung . . . . . . . . . . . . . . . . 446.3 Einfaches Klassendiagramm der Erweiterung . . . . . . . . . . . . . . . . . 45

7.1 Induktiver ABS-Sensor (Westbrook und Turner (1994)) . . . . . . . . . . . . 487.2 Drehbewegung an einem Fahrzeug (Jaschke (2002)) . . . . . . . . . . . . . . 497.3 Wegelement, Richtungsänderung und Krümmung aus Odometern . . . . . . . 507.4 Wegelement aus Fahrzeugdaten (in Thuban) . . . . . . . . . . . . . . . . . . 507.5 Vergleich der Wegelementberechnung aus Fahrzeugdaten (in Thuban) . . . . 517.6 Darstellung einer Testfahrt (in Thuban) . . . . . . . . . . . . . . . . . . . . . 527.7 Auswertung der Krümmung (in Thuban) . . . . . . . . . . . . . . . . . . . . 527.8 Auswertung der Richtungsänderung (in Thuban) . . . . . . . . . . . . . . . . 537.9 Positionsbestimmung mit GPS (in Thuban) . . . . . . . . . . . . . . . . . . 537.10 Bestimmung des Startrichtungswinkels . . . . . . . . . . . . . . . . . . . . . 557.11 Richtungswinkel bezogen auf P1 als Koordinatenursprung . . . . . . . . . . 567.12 Positionsbestimmung mit Radumdrehungen (in Thuban) . . . . . . . . . . . 577.13 Positionsbestimmung mit Rad-Impuls-Zähler (in Thuban) . . . . . . . . . . . 577.14 Positionsbestimmung mit Rad-Impuls-Zähler und Gierrate (in Thuban) . . . . 587.15 Zone einer Straße zur Einpassung . . . . . . . . . . . . . . . . . . . . . . . 597.16 Lot auf Strassenelement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.17 Kritische Lotfällung an Kreuzungen . . . . . . . . . . . . . . . . . . . . . . 617.18 In Richtung des Line Features . . . . . . . . . . . . . . . . . . . . . . . . . 647.19 In entgegengesetzte Richtung des Line Features . . . . . . . . . . . . . . . . 647.20 Möglicher Überholvorgang durch Krümmung (in Thuban) . . . . . . . . . . 64

V

Tabellenverzeichnis

2.1 Geodätisches Datum, Ellipsoid, Verschiebung, Einsatzgebiet . . . . . . . . . 7

3.1 Entwicklungsphasen des NAVSTAR-GPS . . . . . . . . . . . . . . . . . . . 13

4.1 Aufbau der Transferstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 Normierungsfaktoren der Transferstruktur . . . . . . . . . . . . . . . . . . . 20

5.1 Beispiel für Simple Features . . . . . . . . . . . . . . . . . . . . . . . . . . 265.2 Erfasste Feature-Arten bei TeleAtlas (Walter (1996)) . . . . . . . . . . . . . 275.3 Segmentieres Attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.4 Räumliche Objekttypen in SQL . . . . . . . . . . . . . . . . . . . . . . . . . 335.5 Aufbau der Tabelle ”tracking_point” . . . . . . . . . . . . . . . . . . . . . . 365.6 Aufbau der Tabelle ”junction_point” . . . . . . . . . . . . . . . . . . . . . . 375.7 Aufbau der Tabelle ”roadelement_multilinestring” . . . . . . . . . . . . . . . 385.8 ”Order-i Area” - Typen für Deutschland . . . . . . . . . . . . . . . . . . . . 395.9 Aufbau der Tabelle ”boundaryelement_multilinestring” . . . . . . . . . . . . 405.10 Aufbau der Tabelle ”speedrestrictions_polygon” . . . . . . . . . . . . . . . . 40

7.1 Navigationssysteme, Sensoren, Kartendaten . . . . . . . . . . . . . . . . . . 467.2 Direction of Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.3 Fahrzeugarten für ”Direction of Traffic Flow” . . . . . . . . . . . . . . . . . 63

VI

Danksagung

Mein Dank gilt DIPL.-INFORM. (FH) BENEDIKT WOLF und DIPL.-INFORM.(FH) GERRIT HARTBROD, die mir bei zahlreichen Fragen in der Einarbeitungs-phase Rede und Antwort gestanden haben.

Ebensolchen Dank gilt auch meinen Betreuern PROF. DR. JÜRGENBIERMANN und PROF. DR. THEODOR GERVENS für Ihre zahlreichen inter-essante Anregungen während der Arbeit.

Natürlich möchte ich mich auch recht herzlich bei der FIRMA HELLA KGHUECK & CO für die Bereitstellung der GDF-Kartensätze und des Test-fahrzeugs bedanken.

VII

1 Einleitung

Zu Beginn des Jahres 2003 hatte sich die Mehrheit der Teilnehmer des 41. Verkehrsgerichts-tags in Goslar für eine obligatorische Blackbox in PKWs ausgesprochen (Rötzer (2003)). Umriskantes Fahrverhalten einzudämmen oder aber das eigene Fahrverhalten zu Analysieren,könnte so ein Geräte verwendet werden. Aber auch andere Einsatzgebiete wären denkbar. Sowäre es möglich mit einem Unfalldatenschreiber fortlaufend Daten wie die Geschwindigkeit,Überholmanöver oder Richtungsänderungen aufzuzeichnen. Diese könnten dann zur Klärungvon Schuldfragen bei der Rekonstruktion eines Unfalls sehr hilfreich sein.

Die Kombination von Blackbox und GeoDaten bietet in diesem Zusammenhang außerdemneue Möglichkeiten. Mit den räumlichen Informationen wäre es möglich Auswertungen zuerzeugen, welche direkten Bezug zu einer befahrenen Straße besitzen (Einbahnstraße, Ge-schwindigkeitsbeschränkungen).

1.1 Aufgabenstellung

Aufgabenstellung dieser Arbeit war eine Fahrdatenanalyse auf Basis einer objektrelationalenGeoDatenbank und eines GPS-Empfängers zu ermöglichen. Um dieses zu erreichen, wurdenfolgende Zielsetzungen festgelegt:

• Die Bereitstellung der nötigen Veränderungen an einer schon vorhandenen objektrela-tionalen GeoDatenbank

• Anzeige der Straßenkarte und sämtlicher Auswertungen mit dem GeoDaten-ViewerThuban

• Auswertung einer gefahrenen Strecke hinsichtlich Geschwindigkeitsüberschreitungen,Überholvorgängen, Einhaltung der erlaubten Fahrtrichtungen (zum Beispiel bei Ein-bahnstraßen)

Aufgrund der Tatsache, dass bei dem Testfahrzeug der Firma Hella KG Hueck & Co auchDaten von den Radsensoren und der Gierrate zur Verfügung standen, kamen noch weitereZielsetzungen hinzu. Diese umfassten die allgemeine Auswertung dieser Sensoren und diePositionsbestimmung des Fahrzeugs durch kombinierten Einsatz von GPS, Radsensoren undGierrate.

1

1 Einleitung

1.2 Hilfsmittel

Beim Verfassen dieser Arbeit wurde fast ausschließlich Freie Software eingesetzt. Unter Li-nux (Debian) kamen hierbei unter anderem LATEX, aspell, Gimp, xfig und kate zum Einsatz.Als DBMS wurde das freie PostgreSQL (mit PostGIS) genutzt. Zudem wurde für die Anzeigevon Straßeninformationen das frei erhältliche Thuban der Firma Intevation GmbH eingesetzt.Lediglich bei der Gestaltung des Klassendiagramms kam Together 6 zum Einsatz.

Aus Hartbrod (2003) sind die ER-Modelle im Anhang entnommen.

1.3 Gliederung der Arbeit

Die vorliegende Arbeit ist grob unterteilt in den Grundlagen zur Einführung und Verständnisder Arbeit (Kapitel 2 und 3), der Datenbereitstellung und Darstellung (Kapitel 4 bis 6) undder Datenauswertung (Kapitel 7).

Geodäsie (Kapitel 2)

Zum Grundverständnis des Vermessungswesens werden hier Begriffe wie Geoid, Ellipsoidoder UTM besprochen. Dieses ich wichtig für das Verständnis der Positionsinformationeneines Fahrzeugs.

Global Positioning System (Kapitel 3)

Die Ortung einer Fahrzeugposition ist mit einem satellitengestützten Verfahren, dem GPS,möglich. GPS-Empfänger sind damit zu einem der wichtigsten Ortungsgeräte in Fahrzeugengeworden.

Aufzeichnung von Fahrzeugdaten (Kapitel 4)

In diesem Kapitel wird gezeigt, welche Informationen von der Blackbox des Fahrzeuges zurVerfügung standen.

Digitale Straßenkarten (Kapitel 5)

GDF-Dateien sind die Basis für digitale Straßeninformationen. Mit dem Einspielen dieser Da-ten in einer objektrelationalen GeoDatenbank, wird PostgreSQL (in Verbindung mit PostGIS)zu einem mächtigen Werkzeug.

2

1 Einleitung

Betrachter für digitale Karten (Kapitel 6)

Als Betrachter für geographische Daten wurde das freie Programm »Thuban« gewählt. Zudembesitzt Thuban eine Schnittstelle zur Datenbank und gute Erweiterungsmöglichkeit für eigeneModule.

Fahrdatenauswertung (Kapitel 7)

Dieses Kapitel befasst sich mit der Durchführung und den Ergebnissen der Fahrdatenanalyse.

Zusammenfassung (Kapitel 8)

Zum Schluss wird noch einmal die Zielsetzung überprüft. Außerdem wird ein Ausblick aufweitere Möglichkeiten der Fahrdatenanalyse gegeben.

3

2 Geodäsie

Unter dem Begriff Geodäsie (geo : Erde, dasei : teilen) ist nach Helmert(1885) die Lehre der Ausmessung und Abbildung der Erdoberfläche zu verstehen (Möser(2003)). Schon in frühen Zeiten wurde versucht, die Form und Größe unseres Planeten zubeschreiben.

Der griechische Dichter Homer (ca. 850 v. Chr.) dachte noch, die Erde sei eine Scheibe. Späterwurde von Pythagoras (582 v. Chr.) und Aristoteles (384 v. Chr.) angenommen, dass die Formder Erde eine Kugel sei. Diese Vermutung ist zwar etwas korrekter, aber in Wahrheit entsprichtdie Erde eher einer »Kartoffel« (ellipsoide Form).

2.1 Geoid

Um möglichst genau die Erdform zu modellieren, wird der theoretische Körper des »Geoids«angenommen. Ein Geoid (geoid : erd-förmig) ist die (unter den Kontinenten fort-gesetzte) Form der Erde, welche durch die Oberfläche der Weltmeere gegeben ist. Die Meeresollen hierbei keiner anderen Kraft, als die der Schwerkraft ausgesetzt sein (Gezeiten, Strö-mungen, Temperaturunterschiede, etc.). Somit ist jeder Punkt des Geoids rechtwinklig zurRichtung der Schwerkraft (Abbildung 2.1 (Gründig (2003))). Diese Variationen der Gravita-tion sind durch Materialunterschiede im Erdkern und der Erdoberfläche zu erklären.

Abbildung 2.1: Geoid (allgemein)

Deutlich zu erkennen ist dieses Phänomen auf den Bildern der »U.S National Imagery andMapping Agency (NIMA)«. Abbildung 2.2 stellt das Modell des WGS-84-Geoids (WorldGeodetic System 1984) dar. Bei geodätischen Messungen wird immer ein Bezug zu diesem

4

2 Geodäsie

»realen Erdmodell« geschaffen. Da es sich durch seiner Komplexität aber nicht für mathema-tische Berechnungen eignet, werden alternative Bezugsflächen angenommen.

Abbildung 2.2: WGS-84 Geoid (NIMA)

2.2 Vereinfachte Bezugsflächen

Die Problematik in diesem Vorgehen ist, dass auf dem Geoid gemessen, aber gleichzeitig aufder vereinfachten Bezugsfläche gerechnet wird. Aus diesem Grund müssen sich der Geoid unddie Ersatzfläche möglichst gleichen.

Hierzu gibt es drei Varianten dieser Fläche:

• Tangentialebene (für örtliche Vermessungen)

• Kugel (für kleine Länder)

• Rotationsellipsoid (weltweit)

Für örtliche Messungen reicht eine Tangentialebene, um die gekrümmte Erdoberfläche abzu-bilden. Hierbei wird im Mittelpunkt des zu vermessenen Gebietes eine Ebene angelegt, diesenkrecht zum Geoid (also zur Schwerkraft) steht. Soll kein Fehler größer als 1 bis 2 cm entste-hen, darf der Durchmesser des Vermessungsgebietes nicht größer als 5 km sein. Diese Formder Vermessung kann bei Katastervermessungen (Grundbuch) und der Ingenieurgeodäsie (Hoch-

5

2 Geodäsie

bau, Verkehrswegebau, Brücken, Tunnel, etc.) angewandt werden.

Bei größeren Gebieten (bis 200 km) kann eine »Schmiegungskugel« benutzt werden. Hierbeiwird Größe und Position so gewählt, dass sie sich dem Geoid (im Bereich des Messgebietes)möglichst gut anschmiegt.

Die bedeutendste Bezugsfläche ist der Rotationsellipsoid. Dieser wird unter Angabe der Haupt-(a) und Nebenhalbachse (b) beschrieben. Unter der Haupthalbachse ist der Äquatorradius undunter der Nebenhalbachse ist der Polradius zu verstehen. Das Verhältnis zwischen den Achsengibt die Abflachung f des Ellipsoiden wieder.

f =a − b

a(2.1)

Deutlich zu erkennen ist, dass f kleiner wird, je mehr sich die Form einer Kugel nähert. Beia = b (und damit f = 0) wird dieses erreicht.

Haupthalbachse(a)

Nebenhalbachse(b)

Abbildung 2.3: Rotationsellipsoid

In Abhängigkeit des Bezugs zum Geozentrums werden zwei Arten von Rotationsellipsoidenunterschieden (Möser (2003)). Dem mittleren und dem lokalen Ellipsoiden (Referenzellip-soiden).

Auf dem mittlere Erdellipsoid können Berechnungen für die gesamte Erde ausgeführt werden.Dieses ist möglich, da er das Geoid als Ganzes ersetzen kann. Mit Hilfe von Satellitenvermes-sungen wurde so ein immer genaueres weltweites Referenzsystem berechnet. Seit 1987 wirdfür das GPS (Global Positioning System) der weltweit gültige WGS-84-Ellipsoid benutzt.Dieser beschreibt den Äquatorradius mit einer Genauigkeit von ein bis zwei Metern. Für denmittleren Ellipsoiden gelten zudem einige Anforderungen:

6

2 Geodäsie

• Mittelpunkt im Geozentrum

• Identische Drehachse

• Volumen von Ellipsoid und Geoid müssen gleich sein

Sind keine weltweiten Vermessungen notwendig, kann auf einem lokalen Ellipsoiden zurück-gegriffen werden. Dieser passt sich einem Teil der Erde möglichst gut an, so dass sogar eineGeoidannäherung bis auf Zentimeterbereiche möglich ist. Im Gegensatz zum mittleren Ellip-soiden, muss seine Achse hier bloß parallel zur (mittleren) Rotationsachse der Erde sein. EineVerschiebung des Ellipsoidzentrums gegenüber dem Erdschwerpunkt ist somit möglich.

Der Satz von Daten, welcher die Lage zum Erdkörper beschreibt, wird als »GeodätischesDatum« bezeichnet. Ein besonderes Datum bildet hierbei das Datum »WGS-84«. Hierfürwird der WGS-84-Ellipsoid unverändert (ohne Verschiebungen) übernommen. NachfolgendeTabelle 2.11 soll dieses verdeutlichen:

Geodätisches Datum Ellipsoid X Y Z EinsatzgebietWGS 84 WGS 84 0 0 0 weltweitMassawa Bessel 1841 639 405 60 Äthiopien

European 1950 International 1924 -112 -77 -145 TunesienEuropean 1950 International 1924 -84 -107 -120 Portugal, Spanien

Tabelle 2.1: Geodätisches Datum, Ellipsoid, Verschiebung, Einsatzgebiet

2.3 Koordinatensysteme

Durch das Approximieren der Erdoberfläche durch einen Ellipsoiden, existieren verschiedeneModelle zur Positionsbestimmung. Zwei davon sind das geozentrische erdfeste X,Y,Z-Koordi-natensystem und das geographische Koordinatensystem.

2.3.1 Geozentrische erdfeste X,Y,Z-Koordinaten

Dieses Koordinatensystem hat seinen Ursprung im Erdschwerpunkt. Von diesem Punkt auskann, durch ein dreidimensionales kartesisches Koordinatensystem, jeder Punkt auf der Erdeoder in deren Nähe beschrieben werden. »Erdfest« bedeutet in diesem Zusammenhang, dasssich das Koordinatensystem mit der Erde dreht (Z-Achse). Die X,Y-Ebene entspricht derEbene des Äquators und die X,Z-Ebene die des Nullmeridians (Meridian : Längenkreis).Ein Anwendungsbeispiel für dieses System ist die Bahnbestimmung von Satelliten (Bill (1999)).

1aus www.kowoma.de/gps vom 18.03.2004

7

2 Geodäsie

2.3.2 Geographische Koordinaten

Bei dieser Positionsangabe wird eine eindeutige Position durch einer geographischen Breite(φ), der geographischen Länge (λ) und einer geographischen Höhe (h) bestimmt. Die Höhewird orthogonal zur Ellipsoidoberfläche gemessen. Um einen festen Bezug zu einem Punktauf dem Ellipsoiden zu schaffen, wurden feste Referenzen eingeführt.

So ist die Breite der Winkel zwischen der Verbindungslinie eines Punktes mit dem Erdmit-telpunkt und der Ebene des Erdäquators. Orte mit gleicher Breite sind auf, dem zum Äquatorparallelen, gleichen Breitenkreis. Der Breitengrad wird vom Äquator nach Norden und Südenmit je 90 Grad gezählt (nördliche Breite / südliche Breite).

Die geographische Länge entspricht dem Winkel zur Ebene, die durch das astronomische Ob-servatorium von Greenwich (England) verläuft. Greenwich ist somit auf dem Nullmeridian.Der Längengrad wird vom Nullmeridian jeweils nach Osten und Westen mit je 180 Gradgezählt (östliche Länge / westliche Länge). Beim 180◦-Meridian befindet sich das Gegenstückzum Nullmeridian (die »Internationale Datumsgrenze«). Zudem haben Orte gleicher Länge inetwa die gleiche Zeit.

Südpol

Position auf Erdoberfläche

Äquator

geographische Breite

geographische Länge

Nullmeridian

Nordpol

Abbildung 2.4: Definition der geographischen Breite und Länge

8

2 Geodäsie

GPS-Empfänger arbeiten standardmäßig mit geographischen Koordinaten, wobei sich derWGS-84-Ellipsoid (mit dem geodätischen Datum WGS 84) als Erdersatz durchgesetzt hat.

Die Darstellung von Breite und Länge kann in Bogengrad (◦), Bogenminute (’) und Bo-gensekunde (”) erfolgen. Interessant ist, dass die mittlere Länge einer Bogenminute einerSeemeile (1,852 km) entspricht. Der Abstand zwischen zwei geographischen Breiten (der Bo-gengrad) ist somit 60 Seemeilen lang (ca. 111 km). Eine Umrechnung zwischen Dezimalgradund Grad, Minute und Sekunden kann wie folgt erfolgen:

Dezimalgrad = Bogengrad +Bogenminute

60+

Bogensekunde

3600(2.2)

Beispielsweise entspricht der Punkt N 50,02528◦ und E 008,22222 (Raum Mainz) den Koor-dinaten N 50◦ 01’ 31” und E 8◦ 13’ 20”. Natürlich ist auch eine Angabe in Grad und Dezi-malminuten vorstellbar (N 50◦ 01,517’ und E 8◦ 13,333’).

Zur Konvertierung zwischen geozentrische erdfeste X,Y,Z-Koordinaten und den geographi-schen Koordinaten stehen folgende Formeln zur Verfügung (Bill (1999)):

X = (N + h) cos φ cos λ (2.3)

Y = (N + h) cos φ sin λ (2.4)

Z = (N(1 − e2) + h) sin φ (2.5)

φ = arctan

(

Z

s

(

1 − e2N

N + h

)

−1)

(2.6)

λ = arctanY

X(2.7)

h =s

cos φ− N (2.8)

Die Hilfsgrößen N , s und e2 entsprechen den Formeln 2.9 bis 2.11. a und b sind die schonbesprochenen Haupt- und Nebenhalbachsen des jeweiligen Ellipsoiden.

N =a

√

1 − e2 sin2 φ(2.9)

s =√

X2 + Y 2 (2.10)

e2 =a2 − b2

a2(2.11)

9

2 Geodäsie

2.4 Universale Transversale Mercator(UTM)-Projektion

Zur weiteren Vereinfachung der Erdform können Punkte aus den dreidimensionalen Koor-dinatensystemen in ebene Koordinatensysteme überführt werden. Dieses erlaubt dann ein-fachere Berechnungsmöglichkeiten. Für Karten und Vemessungszwecke ist es außerdem sin-nvoll, wenn ein rechtwinkliges Gitter mit gleichen Abständen genutzt wird.

Eine Projektionsart, des Ellipsoiden auf einer Ebene, ist die UTM-Projektion (transversaleMercatorprojektion von Gerhard Kremer (1512-1594)). Das Ergebnis entspricht der Projek-tion einer Lichtquelle (im Erdzentrum) die auf einen außen liegendem Zylinder scheint (Abbil-dung 2.5, Möser (2003)). Allerdings wird bei UTM (wie auch bei der Gauss-Krüger-Projektion)nicht alles auf einmal und einem Zylinder projiziert, sondern auf mehrere Streifen. Die brei-te der Streifen wird so gewählt, dass sich die Verzerrungen minimieren lassen. Allerdings isteiner verzerrungsfrei zweidimensionale Abbildung der dreidimensionalen Erde nicht möglich.Nur an den Mittelmeridianen (den Berührungspunkten auf der Streifenmitte) ist die Projektionohne Verzerrung. Je weiter ein Punkt sich von diesem Meridian entfernt, je größer wird auchdie Verzerrung.

Abbildung 2.5: UTM-Projektion

Wegen der Ausdehnung von sechs Grad pro Streifen, existieren 60 Streifen (360◦:6◦=60).Diese sind von 1 bis 60 durchnummeriert. Innerhalb eines Streifens findet die Orientierungdurch den Abstand zum Mittelmeridian und zum Äquator statt. Als Ostwert (E) wird diesenkrechte Entfernung zum Mittelmeridian bezeichnet. Der Nordwert (N) ist die entsprechendeEntfernung zum Äquator. Bei der Gauss-Krüger-Projektion entspricht der Nordwert demHochwert und der Ostwert dem Rechtswert.

Um negative Ostwerte zu vermeiden ist es üblich den Ostwert des Mittelmeridians auf 500.000Meter zu setzen. Positionen, die östlich vom Mittelmeridian liegen, haben demnach Ostwertegrößer als 500.000. Alle Ostwerte westlich dieses Meridians sind kleiner als 500.0000.

Jede Zone wird außerdem in 8◦ breite Bänder unterteilt. Die Bandbezeichnung für den größten

10

2 Geodäsie

Teil Deutschlands ist ”U”.

Äquator

Ostwert

Nordwert

Grenze des Streifens

Grenze des Streifens

Mittelmeridian

Abbildung 2.6: Nord- und Ostwert (UTM)

Für Europa wurde ursprünglich das Hayford-Ellipsoid, für Nordamerika das Clark 1866und für Afrika das Clark 1880 genutzt. Heute wird aber dazu übergegangen weltweit für alleUTM-Koordinaten das WGS-84-Ellipsoid zu verwenden. Zudem soll die in Deutschland weitverbreitete Gauss-Krüger-Projektion zukünftig durch UTM (Abbildung 2.7 2) abgelöst wer-den (Grande u. a. (2004)).

Um die relativ aufwendige Umrechnung von geographischen Koordinaten in UTM-Koordinatenzu vereinfachen, kann die Funktion ”transform(geomery,integer)” von PostGIS genutzt wer-den. Weiterführende Ausführungen sind in Kapitel 5 zu finden.

Nachfolgend befindet sich eine PL/pgSQL-Funktion und ein Beispielaufruf, die transform()nutzt (Abbildung 2.8.) Die geographische Koordinate N 50,919225◦ E 007,169041◦ entsprichtder UTM-Koordinate Zone 32, Ostwert 371303.868, Nordwert 5642438.948.

1 -- ----------------------------------------------------------- Grad (WGS84) in UTM-Koordinaten (Zone 32,WGS84) umrechnen-- ---------------------------------------------------------DROP FUNCTION grad_2_utm(DOUBLE PRECISION,DOUBLE PRECISION);CREATE FUNCTION grad_2_utm(DOUBLE PRECISION,DOUBLE PRECISION) RETURNS TEXT AS ’DECLARE

rec RECORD;x_value RECORD;y_value RECORD;

10 ret TEXT;transform_text TEXT;

BEGIN

2aus www.geodaten.bayern.de vom 10.06.2004

11

2 Geodäsie

Abbildung 2.7: UTM-Koordinaten und Zonenfelder für Deutschland

transform_text := ’’SRID=4326;POINT(’’ ||$1||’’ ’’||$2||’’)’’;SELECT transform(transform_text::geometry,32632) INTO rec;IF FOUND THEN

SELECT x(rec.transform) INTO x_value;SELECT y(rec.transform) INTO y_value;ret := ’’ ’’ || x_value.x || ’’ ’’ || y_value.y || ’’ ’’;

ELSE20 RAISE NOTICE ’’Fehler bei Transform!’’;

ret := ’’(0 0)’’;END IF;RETURN ret;

END;’LANGUAGE ’plpgsql’;

Abbildung 2.8: UTM-Berechnung mit PostgreSQL/PostGIS

12

3 Global Positioning System (GPS)

Der GPS-Empfänger ist eines der wichtigsten Geräte zur Positionsbestimmung im Fahrzeug.Dieses Kapitel soll zum Verständnis von GPS beitragen.

3.1 Geschichte

Für eine weltweite Navigation in Echtzeit begannen in den 70er Jahren die USA und dieUdSSR mit der Entwicklung von Globalen-Navigations-Satellitensystemen (GNSS). Auf deramerikanischen Seite wurde NAVSTAR-GPS (Navigation Satellite Timing and Ranging-GlobalPositioning System) entwickelt. Das sowjetische Gegenstück hieß GLONASS (Global’nayaNavigatsivannaya Sputnikovaya Sistema) (SAPOS (2004)).

Geschichtlich gesehen, lassen sich bei NAVSTAR-GPS mehrere Phasen unterscheiden:

Zeitraum Phasen1974 - 1979 Überprüfungsphase1979 - 1985 Entwicklungsphase1985 - 1993 Ausbauphase

Tabelle 3.1: Entwicklungsphasen des NAVSTAR-GPS

Seit Dezember 1993 befindet sich das System in der Erprobungsphase durch das Verteidi-gungsministerium der USA (DoD - Department of Defence) (Schumann (1996a))

Um ein von Amerika unabhängiges System zu nutzen, wurde von der Europäischen Union undder Europäischen Weltraumorganisation (ESA) mit der Entwicklung eines eigenen GNNS be-gonnen. Das 3,2 Mrd. Euro teure Projekt, mit dem Namen ”Galileo”, soll 2008 abgeschlossenwerden.

3.2 Einsatzgebiete

Es gibt viele Möglichkeiten das GPS-System mehr oder weniger sinnvoll einzusetzen. EinigeBeispiel hiervon sind in Barie (2000) beschrieben:

• Digitale Routenplaner

13


• Tragbare Bar-Suchmaschine (der Brauerei Heineken)

• Straßen-Leitsystem zur Lockerung des Verkehrsflusses mit dynamischenGeschwindigkeitsbegrenzungen und Umleitungen

• Elektronische Fesseln für Straftäter

• Geschosse der Artillerie mit GPS-Empfängern

• Automatische Berechnung von Erträgen je Parzelle auf Mähdreschern

3.3 Funktionsweise und Aufbau

Der Aufbau des GPS-Systems besteht aus drei Segmenten. Dieses sind die Raumsegmente(Satelliten), den Bodensegmenten (Kontrollstationen) und den Nutzersegmenten (Empfangs-technik) (SAPOS (2004)).

Abbildung 3.1: Satelliten des NAVSTAR-GPS

Zum Raumsegment gehören momentan 29 Satelliten, welche die Erde in einer Höhe von20230 km umrunden (Abbildung 3.1, Schumann (1996b)). Hierdurch ist der Datenempfangvon 4 bis 12 Satelliten gleichzeitig möglich.

Die Positionsbestimmung beruht auf der Laufzeitmessung eines Signals vom Satelliten zumEmpfänger. Ist die Laufzeit des Signals bekannt, kann dieser mit der Ausbreitungsgeschwindig-keit der Welle (Lichtgeschwindigkeit) multipliziert werden, um die Entfernung (pseudo range)zu erhalten (Schumann (1996a)). Reflexionen dieses Signals an Häusern, Brücken, usw. er-höhen die Laufzeit und senken somit die Genauigkeit.

Für die räumliche Positionsbestimmung sind drei Satelliten notwendig. Zusätzlich wird einvierter Satellit zur Zeitkorrektur genutzt.

14


S1, S2 und S3 in Abbildung 3.2 sollen die genau bekannten Positionen der Satelliten sein.Die gemessenen Entfernungen zum Empfänger sind p1, p2 und p3. Auf einer Kugel (je Satel-lit) mit den Radien p1 bis p3, muss sich der Empfänger irgendwo auf der Oberfläche dieserKugeln befinden. Der Schnittpunkt aller Kugeloberflächen ist also die Empfängerposition.Diese Überlegungen führen zu folgenden Formeln:

p1 =√

(xp − x1)2 + (yp − y1)2 + (zp − z1)2 + Pabweichung + e1 (3.1)

p2 =√


p3 =√


p4 =√

(xp − x4)2 + (yp − y4)2 + (zp − z4)2 + Pabweichung + e4 (3.4)Pabweichung = c · Tabweichung (3.5)

pi Gemessene Entfernungen zum Empfängerxp, yp, zp Gesuchte Empfängerpositionxi, yi, zi Bekannte Satellitenpositionenei Sonstige SystemfehlerPabweichung Entfernungsabweichungen wegen UhrzeitfehlerTabweichung Zeitabweichung beim Empfänger

Aus 3.1 bis 3.5 sind so die Unbekannten xp, yp, zp und Tabweichung zu berechnen.

3.4 Genauigkeit

Am 1. Mai 2000 verkündete US-Präsident Bill Clinton: „Ich darf Ihnen mitteilen, dass dieVereinigten Staaten heute um Mitternacht die Verschlechterung der Signale des Globalen Posi-tioning System (GPS) stoppen werden” (Barie (2000)). Gemeint war hiermit die Abschaltungdes ”Selective-Availability” (SA). Diese Technik wurde dazu genutzt, um aus sicherheitspoli-tischen Erwägungen, das GPS-Signal künstlich zu verschlechtern. Nach Aussagen des US-Verteidigungsministeriums (2001) verbesserte sich somit die Positionsbestimmung von 100 mauf ≤ 13 m (bei 95%iger Wahrscheinlichkeit).

Zur weiteren Genauigkeitssteigerung existiert das Differential GPS (DGBS). Statt einem (mo-bilen) Empfänger wird zusätzlich noch ein zweiter (statischer) Empfänger verwendet. Dieserbefindet sich an einem exakt vermessenen Punkt, wodurch die Messfehler zu den Satellitenkorrigiert werden können. Aus Abbildung 3.3 von Schraut (2000) sind die Genauigkeiten ver-schiedener GPS-Varianten ersichtlich. Im Rahmen dieser Arbeit stand Standard-GPS (ohneSA) am Fahrzeug zur Verfügung.

15


p1

p2

p3

S2(x2,y2,z2)

S3(x3,y3,z3)

S1(x1,y1,z1)

Abbildung 3.2: Ortung im dreidimensionalen Raum

Abbildung 3.3: Genauigkeit verschiedener GPS-Verfahren

16

4 Aufzeichnung von Fahrzeugdaten

4.1 Predictive Light Control

In Kooperation zwischen der Firma Hella KG Hueck & Co und der Fachhochschule Os-nabrück wurde von Dipl.-Inform. (FH) Benedikt Wolf das Matlab-Programm PLC (PredictiveLight Control) entwickelt. Es dient zur Aufnahme und Verifizierung von Daten während ei-ner Fahrt. Ziel dieses Projekts ist eine "vorausschauende Ausleuchtungssteuerung", basierendauf Fahrzeuginformationen und digitalen Kartendaten, zu entwickeln. Hierbei sollen Fahr-daten mit einer digitalen Landkarte kombiniert werden, so dass es möglich ist die Scheinwer-fer intelligent auszurichten.

Das System besteht aus dem Fahrzeug, einem GPS-Empfänger, einer dSpace-MicroAutoBoxund einem Notebook mit dem Programm ”PLC”. Der GPS-Empfänger und der CAN-Bus(Controller Area Network Bus) des Fahrzeuges sind an der dSpace-Box angeschlossen, umDaten an das Matlab-Programm zu übertragen. Über dem CAN-Bus sind zum Beispiel In-formationen über die aktuelle Gierrate, dem Tachosignal oder der Radumdrehung abfragbar.Außerdem ist das Notebook an der Box angeschlossen, um die Daten zu lesen und eine wei-tere Verarbeitungen vorzunehmen. Innerhalb Matlab werden die Daten mit Zuhilfenahme derBibliothek ”mlib” aus der dSpace-Box übertragen und in einen Datenpuffer geschrieben (Ab-bildung 4.1).

4.2 Matlab/Simulink

Matlab, in Kombination mit Simulink, ist derzeit weltweiter Standard zur Simulation und Ent-wicklung technischer Systeme. Die Bezeichnung Matlab steht für ”MATrix LABoratory”.Dieses spiegelt die Bedeutung von Matrizen und Vektoren wieder, da Matlab diese grund-sätzlich für die Darstellung von Daten gebraucht. Eingesetzt wird Matlab zur Lösung undDarstellung von wissenschaftlichen Berechnungen. Für spezielle Problembereiche existieren”Toolboxen”. Eine spezielle Toolbox ist Simulink. Es ermöglicht mathematische Modelle fürSchalt- und Regelkreise zu erstellen.

17


Fahrzeugdaten(Gierrate, Tacho,Raddrehzahl, etc.)über CAN−Bus

GPS−Empfänger

dSpace−Box

Simulink

Matlab−Programm

Datenaufnahme

"mlib"

− Vorverarbeitung (Umrechnungen)− Lokalisierung− Ausleuchtungs− strategien− Graphische Darstellung

Datenpuffer

Abbildung 4.1: Fahrzeug, dSpace-Box, Matlab

4.3 dSpace-MicroAutoBox

Im Testfahrzeug wurde eine MicroAutoBox von dSpace eingesetzt (Abbildung 4.2). Die kom-pakte Box bietet hier die Möglichkeit des schnellen Prototypings, da Simulink-Programme im-portiert werden können. Das Simulink-Programm übernimmt einen Teil der Vorverarbeitungund des Empfangs der Daten von der GPS- und CAN-Schnittstelle. Somit stehen alle fahrzeug-relevanten Daten über das Simulink-Modell zur Verfügung.

4.4 Datenaustauschformat

Als Datenpuffer zwischen der Datenaufnahme und der weiteren Vorverarbeitung in PLCdient die ”Transferstruktur”. Diese Matlab-Struktur wurde, zur späteren Verarbeitung, in eineCSV-Datei (Comma Separated Value) exportiert. Der genauen Aufbau wird aus Tabelle 4.1ersichtlich.

Nachfolgend befindet sich ein Auszug aus einer CSV-Datei. Hierbei entspricht eine Zeilejeweils einem Datensatz.

1 94801,53.1524,52292616.6667,8016623.3333,57,0,-8,-1,0,918,923,178,170,0,0,42778,0,094802,54.634,52292713.3333,8016465,57,0,-8,-1,0,921,920,222,215,0,0,42786,0,094802,54.634,52292713.3333,8016465,57,0,-8,-1,0,926,927,11,3,0,0,42794,0,094802,54.634,52292713.3333,8016465,58,0,-8,-1,0,931,932,85,78,0,0,42806,0,094802,54.634,52292713.3333,8016465,58,0,-8,-1,0,931,933,100,93,0,0,42810,0,094802,54.634,52292713.3333,8016465,58,0,-8,-1,0,930,928,189,182,0,0,42826,0,0

18


Abbildung 4.2: MicroAutoBox der Firma dSpace

94802,54.634,52292713.3333,8016465,58,0,-8,-1,0,932,931,234,226,0,0,42834,0,094802,54.634,52292713.3333,8016465,58,0,-8,-1,0,928,930,52,45,0,0,42846,0,094802,54.634,52292713.3333,8016465,58,0,-8,-28,0,929,927,111,104,0,0,42858,0,0

10 94802,54.634,52292713.3333,8016465,57,0,-8,-82,0,925,933,156,149,0,0,42866,0,094802,54.634,52292713.3333,8016465,58,0,-8,-55,0,938,936,231,224,0,0,42878,0,094802,54.634,52292713.3333,8016465,58,0,-8,-1,0,944,935,20,13,0,0,42886,0,094802,54.634,52292713.3333,8016465,58,0,-8,-82,0,927,936,110,103,0,0,42902,0,094802,54.634,52292713.3333,8016465,58,0,-8,-109,0,932,941,170,163,0,0,42914,0,094802,54.634,52292713.3333,8016465,58,0,-8,-82,0,940,939,200,193,0,0,42918,0,094803,56.6712,52292813.3333,8016301.6667,58,0,-8,-1,0,933,939,4,253,0,0,42930,0,094803,56.6712,52292813.3333,8016301.6667,58,0,-8,-1,0,931,932,49,42,0,0,42938,0,094803,56.6712,52292813.3333,8016301.6667,58,0,-4,-55,0,935,933,94,87,0,0,42946,0,094803,56.6712,52292813.3333,8016301.6667,58,0,-4,-1,0,931,937,123,117,0,0,42950,0,0

20 94803,56.6712,52292813.3333,8016301.6667,58,0,-4,-55,0,936,936,183,176,0,0,42962,0,0

Diese Daten sind als ”Rohdaten” des Fahrzeugs zu verstehen, die nicht direkt übernommenwerden können. Aus diesem Grund müssen sie (teilweise) noch mit einem Normierungsfaktorumgerechnet werden (Tabelle 4.2). In Zeile 11 der CSV-Datei befindet sich das Fahrzeug somitauf Breitengrad 52.2927133333 und Längengrad 8.016465. Seine momentane Geschwindigkeit(Tachosignal) liegt bei 58 km/h.

19


Position Bedeutung1 GPS-Zeit (Stunde,Sekunde,Minute)2 GPS-Geschwindigkeit (km/h)3 GPS-Breitengrad4 GPS-Längengrad5 Fahrzeuggeschwindigkeit (Tachosignal,km/h)6 7 Lenkwinkelsignal8 Gierrate9

10 Raddrehzahl (linkes Vorderrad)11 Raddrehzahl (rechtes Vorderrad)12 Rad-Impuls-Zähler (linkes Vorderrad)13 Rad-Impuls-Zähler (rechtes Vorderrad)14 Blinker (links)15 Blinker (rechts)16 CAN-Timer17 Abblendlicht18 Rückwärtsgang

Tabelle 4.1: Aufbau der Transferstruktur

Mit dem CAN-Timer (16. Stelle) kann die Gültigkeitsdauer eines Datensatzes berechnen wer-den. Dieser zählt jeden Takt des CAN-Busses von 0 bis 65535. Nach 65535 wird wieder von 0an gezählt (Überlauf). Durch Bildung der Differenz zwischen aktuellem und vorherigen CAN-Timer-Wert (∆CANTimer) und anschließender Multiplikation mit der Dauer eines Taktes(7.5ms), lässt sich die Datensatz-Gültigkeitsdauer berechnen. Diese wird für die Ermittlungeiner zurückgelegten Wegstrecke benötigt (Kapitel 7).

Bedeutung Normierungsfaktor MaßeinheitGPS-Breitengrad 1000000−1 GradGPS-Längengrad 1000000−1 Grad

Gierrate 100−1 Grad/SekundeRaddrehzahl (linkes Vorderrad) 2−1 Umdrehungen/MinuteRaddrehzahl (rechtes Vorderrad) 2−1 Umdrehungen/Minute

Tabelle 4.2: Normierungsfaktoren der Transferstruktur

20

5 Digitale Straßenkarten

5.1 Geographic Data Files (GDF)

GDF ist ein Standard für den Austausch von digitalen Karten in Europa. In dieser Arbeit wur-den Kartensätze (hauptsächlich aus dem Raum Osnabrück) der Firma TeleAtlas genutzt, dieim Format ”GDF ASCII Sequential” vorlagen. Ein anderer großer Anbieter ist ”Navtech”.

Eine sehr ausführliche Beschreibung des Formats (ca. 480 Seiten) ist bei ERTICO (1995)zu erhalten. Jeder der zehn Teile dieser Dokumentation beschäftigt sich mit einem eigenenThema:

• Introduction - Ziele, Definitionen von grundlegenden Fachbegriffen

• General Data Model - Entwicklungsgeschichte, GDF-Struktur, NIAM-Diagramm

• Feature Catalogue - Definition von GDF-Objekten (Road Element, Road, Railway Ele-ment, etc.)

• Attribute Catalogue - Attribute der Objekte

• Relationship Catalogue - Beziehungen zwischen den Objekten

• Feature Representation - Darstellungsebenen (Ebene 0 bis 2)

• Quality Description Specification - Qualitätsmessung der GDF-Daten

• Global Data Catalogue - Geodätisches Datum, Projektionsmethoden

• GDF Logical Data Structures - Beschreibung von Datenstrukturen (Elemente von Ob-jekten, elementare Datentypen)

• Media Record Specifications - Zum Lesen von GDF-Dateien benötigte Informationenüber Datensätze/-felder

21


5.1.1 GDF-Parser

Bereits zu Beginn stand ein Parser für GDF-AS-Dateien zur Verfügung. Dieser wurde vonDipl.-Inform. (FH) Gerrit Hartbrod entwickelt (Hartbrod (2003)) und ermöglicht das automa-tische Importieren von Daten aus GDF in eine objektrelationale GeoDatenbank (PostgreSQL).Logische Strukturen und Terminologien des GDF-Formats wurden bei der Überführung in dasDatenbanksystem beibehalten. Hierbei wurde zunächst noch kein PostGIS genutzt. Die Koor-dinaten von GDF-Objekte sind als einfache Floats angelegt (in geographische Koordinaten).Abbildung 5.2 bis 5.3 sollen an dieser Stelle exemplarisch die Überführung verdeutlichen.

Grundsätzlich ist zwischen den Formaten GDF ASCII Sequential (GDF-AS) und GDF ASCIIRelational (GDF-AR) zu unterscheiden. Beim relationalen Format sind die Objekte eines Typs(Nodes, Edges, Faces, etc.) in einer separaten Datei abgelegt. In der sequentielle Ausführungbefinden sich diese in einer einzigen Textdatei. Nachfolgender Ausschnitt stammt aus einergenutzten GDF-AS-Datei:

1 251029002067 189480 5 0251029002068 189481 5 0251029002069 189482 5 0251029002070 189483 5 0251029002071 189484 5 0251029002072 189485 5 0251029116653 189486 5 0251029116763 189487 5 0251029116774 189488 5 0

10 251029116787 189489 5 0251029346069 189490 5 0251029346090 189491 5 024 29003955 29003840 29003841 29000005 29000003 2 024 29003957 29003842 29003843 29000003 29000180 2 024 29003959 29003844 29003845 29000006 29000004 2 024 29003960 29003844 29003846 29000004 29000213 2 024 29003961 29003846 29003847 29000004 29000005 2 024 29003962 29003847 29003845 29000004 29000120 2 024 29003963 660736 29003841 29003847 29000005 29000124 2 0

20 24 29003964 660737 29003846 29003840 29000005 29040158 2 024 29003965 290038451028000549 29000006 29000125 2 024 29003966 1028000548 29003844 29000006 29000216 2 024 29003967 660738 29003848 29003849 29000007 29000012 2 024 29003968 660739 29003851 29003849 29000270 29000007 2 024 29003969 660740 29003850 29003851 29039875 29000007 2 024 29003970 660741 29003852 29003850 29039916 29000007 2 0

Die ersten beiden Bytes eines Datensatzes (in diesem Fall ein ”Data Record”) beginnen miteinem Record Type Code. ”Edge Records” haben hierfür die 24 und ”New Node Records”die 25. In den Abbildungen 5.2 und 5.1 ist der jeweilige Aufbau und Ihre Beziehungen un-tereinander zu sehen. So zeigt zum Beispiel die FromNodeID/ToNodeID eines Edge Records

22


(Kante) auf jeweils einer NodeID eines New Node Records (Knoten). Auf dieser Weise ist derAnfangs- und Endknoten einer gerichteten Kante gegeben.

Abbildung 5.1: Beziehung zwischen Data Records

Abbildung 5.2: GDF-Data-Record

Nach dem Lesen der Records werden die Daten vom GDF-Parser in entsprechende Tabellenabgelegt. Die Tabellen (zu dem obigen Beispiel) sind in Abbildung 5.3 als ER-Modell dargestellt.

Ursprünglich wurde der Parser im Zusammenhang mit dem in Kapitel 4 erwähnten Projekt”Predictive Light Control” entwickelt. Die Datenbank soll dabei die nötigen Straßeninforma-tionen (Straßenkrümmung, Straßenbreite, etc.) bereitstellen. Innerhalb dieser Arbeit sind, mitder Fahrdatenanalyse (Geschwindigkeitsüberschreitungen, Fahrverhalten, Einhaltung der er-laubten Fahrtrichtungen, etc.), weitere Anwendungsfelder untersucht worden. Dieses zeigt,dass eine GeoDatenbank ein universelles Werkzeug für viele Problemstellungen darstellt.

23


Abbildung 5.3: Entity Relationship Model (GDF - Level 0)

5.1.2 Darstellungsebenen

Die Geographic Data Files nutzen ein dreistufiges Ebenenmodel (Ebene 0 bis 2). Auf jederhöheren Ebene steigt der Abstraktionsgrad bezüglich der realen Welt.

24


Level 0: Ebener Graph

Ebene 0 stellt eine reine Geometrie-Ebene dar, die als planarer Graph zu verstehen ist (Abbil-dung 5.4). Es existieren gerichtete Kanten (Edges), Knoten (Nodes) und Flächen (Faces). Indiesem ebenen Graph dürfen keine zwei verschiedenen Knoten oder Kanten die selbe Positionbesitzen. Um Krümmungsverläufe von Kanten zu approximieren, werden zwischen den zweiKnoten einer Kante sogenannte ”Intermediate Points” (Zwischenpunkte) gesetzt.

Wichtig ist, dass auf dieser Schicht noch nicht entschieden werden kann, was eine bestimmteKante darstellen soll. Alle Kanten sind hier noch als gleichwertig anzusehen.

Abbildung 5.4: Darstellung in Level 0

Level 1: Simple Features

Auf dieser Ebene erhalten die Elemente aus Ebene 0 einen Bezug zur realen Welt (Abbildung5.5). Kanten können so beispielsweise Straßen, Flüsse oder Bahnstrecken sein. Anstatt Edges,Nodes und Faces werden hier Line Feature, Point Feature und Area Feature dargestellt. Ihregemeinsame Bezeichnung ist Simple Feature.

Für die Beziehung zwischen Ebene 0 und Ebene 1 gilt:

• Jeder Point Feature korrespondiert zu einem Node

25


• Ein Node wird durch keinem, einem oder mehrere Point Features dargestellt

• Jedes Line Feature korrespondiert zu einem oder mehreren Edges

• Ein Edge wird durch keinem, einem oder mehrere Line Features dargestellt

• Jedes Area Feature korrespondiert zu einem oder mehrere Faces

In Tabelle 5.1 sind Beispiele welche ”Objekte der realen Welt” (Feature Class) ein Line-/Point-/Area-Feature sein können. Darüber hinaus werden diese realen Objekte in ”FeatureThemes” eingeteilt (Tabelle 5.2).

Feature Feature Class BedeutungLine Feature Road Element Ein Straßenzug (bzw. ein Teilstück)Point Feature Junction Verbindungspunkte zweier Road ElementsArea Feature Order-8-Area Gemeindefläche

Tabelle 5.1: Beispiel für Simple Features


26


Feature Theme Feature ClassAdministrative Area Country

Order 1 Area - Order 9 AreaCentre of Administrative Area

Boundary JunctionBoundary Element

Settlements Built up AreaCentre of Settlement

Roads and Ferries Address Area Boundary ElementAddress AreaRoad Element

JunctionEnclosed Traffic Area

Ferry ElementRoad

IntersectionFreeway Exit

Centre of Freeway ExitRailways Railway Element

Railway Element JunctionWaterways Waterway Junction

Water AreaWater Line Element

Road Furniture SignpostServices Airport

Hotel or MotelParking AreaPetrol Station

Railway StationRest AreaRestaurant

Regions Free PortPark

IslandBrunnels Brunnel

Tabelle 5.2: Erfasste Feature-Arten bei TeleAtlas (Walter (1996))

27


Level 2: Complex Features

Die Simple Features aus Ebene 1 können in Level 2 zu Complex Features zusammengefasstwerden (Abbildung 5.6). So kann eine ”Intersection” (Kreuzungspunkt) die Zusammenle-gung von Road Elements und Junctions der vorherigen Ebene sein. Diese Sicht reicht füreine Verkehrsführung auf einem On-Board-Display in Fahrzeugen aus (Walter (1996)).

Aufgrund der Vereinfachung hat diese Ebene aber keine genaue geometrischen Darstellung.Auch Informationen, wie die erlaubt Fahrtrichtung, gehen durch Verschmelzung mehrere Sim-ple Features verloren. Innerhalb dieser Arbeit war diese Schicht, aus den genannten Gründen,nicht relevant.


5.1.3 Attributkonzept

Mit Attributen lassen sich Eigenschaft zu den Features (Straßenbreite, Straßenname, Haus-nummern, etc.) hinzufügen. Durch Segmentierung (bei linienförmigen Features) kann einBereich angegeben werden, innerhalb dessen ein Attribut gültig ist. Hierzu stehen zu jedemAttribut die Werte ”From Position” und ”To Position” zur Verfügung. In dem Beispiel aus Ab-bildung 5.7 und Tabelle 5.3 soll es sich um eine Straße mit dem Namen ”Parkstraße” handeln.Die Parkstraße ist, außer an einer Verengung auf 8 m, überall 15 m breit.

28


Abbildung 5.7: Segmentieres Attribut

From Position To Position Straßenbreite Straßenname0 220 15

220 220 8220 400 15

0 400 Parkstraße

Tabelle 5.3: Segmentieres Attribut

5.1.4 Genauigkeit der Realitätsabbildung

Ein wichtiges Kriterium für die Güte der GPS-Daten ist die Genauigkeit, mit der die Realitätabgebildet wird. Dieses ist auch für das Map-Matching der Fahrzeugposition zur digitalenKarte von großer Bedeutung. Bei einer (relativ) genauen DGPS-Messung ist ein Map-Matchingmit exakten Karten sicherlich einfacher, als mit ungenauen.

Nach Czommer (2000) ist die GDF-Vorschrift, dass Kantenzüge innerhalb der Straßenbegren-zungen liegen, erfüllt. Bei den in dieser Arbeit vorhandenen Daten von TeleAtlas, weichendie Straßenvektoren nicht mehr als 1/4 der Straßenbreite von der Straßenmitte ab. Die Punkt-genauigkeit kann (in Ballungsgebieten) mit ca. 3 m angenommen werden. Zudem lässt sichsagen, dass sich die Länge eines realen Straßenteilstücks (b) höchstens um 1% vom approx-imierten Kurventeilstück (s) (mit Zwischenpunkten) unterscheidet. Dieses resultiert aus derBedingung, dass die Richtungsänderung zweier Intermediate Points höchstens 15◦ betragendarf.

29


Abbildung 5.8: Digitalisierung von Kurven

5.2 Datenbankmanagementsystem (DBMS)

5.2.1 Begriffserklärung

Nach Heuer und Saake (2000) ist eine ”Datenbank” (DB) eine Sammlung loser Daten. ZurDatenbank gehören Nutzer- und Metadaten. Metadaten können Strukturbeschreibungen oderIntegritätsbedingungen sein. Die Art der Datenhaltung spielt beim Begriff ”Datenbank” keineRolle. Als ”Datenbankmanagementsystem” (DBMS) werden alle Softwaremodule bezeich-net, die zur Datenverwaltung notwendig sind. Anwendungen, die auf einem DBMS aufsetzen,heißen ”Datenbankanwendung” (DBA). Bei einer Kombination von DBMS und DBA ist esein ”Datenbanksystem” (DBS).

Für eine Datenbank sind verschiedene Modelle zu unterscheiden:

• Hierarchische Datenbanken - Datensätze sind in einer Baumstruktur gespeichert(70er Jahre)

• Vernetzte Datenbanken - Datensätze sind im gerichteten Graph beliebig verknüpfbar(70er Jahre)

• Relationale Datenbanken - Tabellen-artige Organisation der Datensätze(seit ca. 1980)

• Objektorientierte Datenbanken - Datensätze ohne starre Struktur und Erweiterung vonDatentypen möglich

• Objektrelationale Datenbanken - Kombination von relationalen und objektorientiertenEigenschaften

PostgreSQL ist ein objektrelationales Datenbankmanagementsystem.

30


5.2.2 PostgreSQL 7.4.2

An der Universität von Kalifornien (Berkeley) wurde, betreut von Professor Michael Stone-braker, das Datenbankmanagementsystem ”Ingres” ab 1977 entwickelt. Der Nachfolger vonIngres hieß ”Postgres” - Post Ingres (1986). 1994 begannen freiwillige Helfer, basierendauf dem originalen Postgres-Berkeley-Code, die Weiterentwicklung als Open-Source-Projektfortzuführen. Zu diesem Zeitpunkt fand eine Namensänderung von Postgres in ”Postgres95”statt. Kurz darauf (1996) wurde Postgres95 nochmals, mit der Einführung der AbfragespracheSQL (Structured Query Language), in ”PostgreSQL” umbenannt.

Besonders attraktiv ist dieses Datenbankmanagementsystem durch seine freie Verfügbarkeit(BSD-Lizenz). So ist es, für kommerzielle wie für nicht kommerzielle Anwendungen, kosten-los nutzbar. Bei vielen Linux-Distributionen gehört es deshalb schon zur Standardausstattung.Alternativ ist ein Download von www.postgresql.org möglich.

Mit der Erfüllung des ANSI SQL-92 Standards bietet PostgreSQL zahlreiche Möglichkei-ten.

• Transaktionssicherung (commit/rollback)

• Verschachtelte Abfragen

• Views

• Trigger

• Prozedurale Abfrage-/Programmiersprache (PL/pgSQL)

• Benutzerdefinierte Typen

In dieser Arbeit wurde PostgreSQL in der Version 7.4.2 genutzt. Mit der geographischenErweiterung ”PostGIS” bildete PostgreSQL das DBMS für die GeoDatenbank. Für den Daten-bankzugriff steht das Kommandozeilen-Tool ”psql” zur Verfügung. Eine wesentliche Arbeits-erleichterung bringt aber der Einsatz von graphische Frontends wie ”pgAccess” (Abbildung5.9).

5.2.3 PostGIS 0.8

PostGIS wird von der kanadischen Refractions Research Inc. entwickelt und ist ebenso freiverfügbar wie PostgreSQL. Bei PostGIS (hier in Version 0.8) handelt es sich um eine PostgreSQL-Erweiterung, welche die Verarbeitung von geometrischen Objekten ermöglicht. Auf dieserWeise wird die Datenbank zu einer räumlichen Datenbank für ein ”Geographic InformationSystem” (GIS). Es hat sich eingebürgert jedes System, dass geographische Daten erfassen und

31


Abbildung 5.9: psql, pgAccess

bearbeitet kann, als GIS (auch ”Geo-Informationssystem”) zu bezeichnen. Eine genaue Defi-nition des Begriffs ist bei Bill und Fritsch (1997) zu entnehmen:

”Ein Geo-Informationssystem ist ein rechnergestütztes System, das aus Hardware, Software,Daten und Anwendungen besteht. Mit ihn können raumbezogene Daten digital erfasst undredigiert, gespeichert und reorganisiert, modelliert und analysiert sowie alphanumerisch undgraphisch präsentiert werden.”

Geometrische Objekte

Während der Entwicklung von PostGIS wurde die ”Simple Features Specification for SQL”des Open GIS Consortium (OGC) eingehalten. Dieses ist eine Spezifikation welche festlegt,wie Funktionen und geometrische Objekte für räumliche Datenbanken auszusehen haben. Sosind geographische Daten als Tabellen mit je einem Tupel pro geometrisches Objekt abgelegt.Jedes dieser Objekte verweist dabei auf ein räumliches Referenzsystem (spatial_ref_sys).

In Tabelle 5.4 sind alle möglichen instantiierbaren Objekttypen und ihre Darstellung in SQL

32


(als ”Well-known Text”) aufgeführt. Es gibt Punkte, Linien und Polygone. Die Linien undPolygone ergeben sich jeweils aus dem Verbinden der angegebenen Koordinaten in der angegebe-nen Reihenfolge. Soll ein Objekt mehrere einfache Elemente enthalten, ist dieses mit Multi-Point, MultiLineString, MultiPolygon oder GeomCollection möglich.

Geometrie SQL-DarstellungPoint ’POINT(10 10)’

MultiPoint ’MULTIPOINT(5 5, 10 10)’LineString ’LINESTRING(5 5, 10 10, 15 15)’

MultiLineString ’MULTILINESTRING((5 5, 10 10, 15 15),(20 20, 25 25, 30 30))’Polygon ’POLYGON(5 5, 10 10, 15 15, 5 5)’

MultiPolygon ’MULTIPOLYGON((5 5, 10 10, 15 15, 5 5),(20 20, 25 25, 30 30, 35 35))’GeomCollection ’GEOMETRYCOLLECTION(POINT(10 10),POLYGON(5 5, 10 10, 15 15, 5 5))’

Tabelle 5.4: Räumliche Objekttypen in SQL

Die Eintragungen in der Referenzsystem-Tabelle, für das geographische KoordinatensystemWGS-84 und der entsprechenden UTM-Projektion (siehe Kapitel 2), sind aus nachfolgen-dem Listing ersichtlich. Jeder Eintrag ist hierbei eindeutig durch das Attribut ”srid” (Spatial-Reference-Identifier) festgelegt.

1 -- SPATIAL_REF_SYS

CREATE TABLE spatial_ref_sys (srid integer not null primary key,auth_name varchar(256),auth_srid integer,srtext varchar(2048),proj4text varchar(2048)

);10

---- GCS WGS 1984--INSERT INTO "spatial_ref_sys" (srid, auth_name, auth_srid, srtext, proj4text)VALUES(4326,’EPSG’,4326,’GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]’,’+proj=longlat +ellps=WGS84 +datum=WGS84’);

20

---- WGS 1984 UTM Zone 23N

33


--INSERT INTO "spatial_ref_sys" (srid, auth_name, auth_srid, srtext, proj4text)VALUES(32623,’EPSG’,32623,’PROJCS["WGS_1984_UTM_Zone_23N",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator

30 "],PARAMETER["False_Easting",500000],PARAMETER["False_Northing",0],PARAMETER["Central_Meridian",-45],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0],UNIT["Meter",1]]’,’+proj=utm +zone=23 +ellps=WGS84 +datum=WGS84 +units=m’);

Mit der Funktion ”transform(geometry,integer)” kann zwischen verschiedenen Koordinaten-systemen umgerechnet werden. Das Attribut ”proj4text” beinhaltet dazu die dafür notwendi-gen Informationen, die von der Bibliothek ”proj4” gebraucht werden. Proj4 wird auch vonThuban für seine Projektionen genutzt.

Eine Tabelle mit räumlichen Informationen zu erzeugen erfolgt in zwei Schritten.Zuerst wird eine normale nicht-räumliche Tabelle erzeugt. Danach wird das räumliche Attributdurch die PostGIS-Funktion ”AddGeometryColumn” hinzugefügt. Soll auf keinem Referenz-system bezug genommen werden, muss srid auf -1 gesetzt werden. Mit dem letzten Parametervon AddGeometryColumn wird die räumliche Dimension der Objekte gewählt.

1 CREATE TABLE road_segments (id INTEGER NOT NULL PRIMARY KEY,name VARCHAR(64),

);SELECT AddGeometryColumn(’my_database’,’road_segments’,’centerline’,’-1’,’LINESTRING’,’2’);

INSERT INTO road_segments VALUES(1, ’Main Street’,10 GeometryFromText(’LINESTRING( 44 31, 56 34, 70 38 )’ ,-1)

Installation

Um die volle Funktionalität der räumlichen Erweiterung für eine Datenbank zu nutzen, müssen(nach Installation der Bibliotheken ”proj4” und ”geos”) hierfür die Dateien ”postgis.sql” und”spatial_ref_sys.sql” ausgeführt werden. Dieses wird mit dem Kommandozeilen-Tool psqldurchgeführt. Nachfolgend sind die wichtigsten Schritte aufgeführt, die im Quellverzeichnisvon PostgreSQL auszuführen sind:

cd contribgunzip postgis-0.8.0.tar.gztar xvf postgis-0.8.0.tar

34


cd postgis-0.8.0makemake installcreatelang plpgsql psql -d -f postgis.sqlpsql -d -f spatial_ref_sys.sql

Wie schon oben erwähnt, werden zwei zusätzliche Bibliotheken gebraucht:

• proj4 - wird benötigt um die transform()-Funktion auszuführen. Hiermit können Projek-tionen ausgeführt werden (geographische Koordinaten UTM)

• geos - benötigt für touches(), contains(), disjoint(), intersection(), union(), buffer()

5.3 Geographische Informationen in der Datenbank

Die Straßeninformationen aus der GeoDatenbank und die Fahrzeugdaten mussten für den Geo-betrachter Thuban aufbereitet werden. Hierzu war es notwendig, aus der vorhandenen Daten-bank (siehe 5.1.1) neue Tabellen mit geometrischen PostGIS-Objekten anzulegen. Die Objekteaus diesen Tabellen können dann direkt von Thuban dargestellt werden (siehe auch Kapitel 6).Ziel war es eine ähnliche Darstellung in Thuban zu ermöglichen, wie es auch bei gängigenViewern möglich ist, die direkt die GDF-Dateien einlesen können (Abbildung 5.10).

Abbildung 5.10: Darstellung einer GDF-Datei (TeleAtlas GDF Viewer)

35


5.3.1 Fahrstrecke als Points

Abbildung 5.11: Fahrstrecke als Menge von Punkten

Die gefahrene Strecke des Testfahrzeugs wurde als eine Menge von Punkten in der Ebenedargestellt (Abbildung 5.11). Je nach Methode der Positionsbestimmung ergibt sich die Punkt-position anders. Bei reiner Bestimmung über GPS wurde immer dann ein neuer Punkt gesetzt,wenn aus der CSV-Datei mit den Fahrzeugdaten (Kapitel 4) eine neu GPS-Position zur Verfü-gung stand. Da GPS-Daten mit 1 Hz empfangen wurden, war dieses (bei Fahrzeugbewegung)jede Sekunde möglich. Wurde eine Kombination aus GPS und Radsensoren (eventuell mitGierrate) gewählt, so wurde ein Punkt bei jeder Änderung der GPS-Zeit gesetzt. Die GPS-Zeitist der erste Wert der Transferstruktur (siehe 4.4).

Aus Tabelle 5.5 ist ersichtlich, dass zudem weitere Informationen zu jeder Fahrzeugpositionabgelegt wurden.

Attribut Datentyp Bedeutunggid integer Eindeutiger Wert je Punkt (für Thuban)

roadelement_gid integer gid des zugehörigen Road Elements nach Map Matchingroadelement_pos float Position auf entsprechendes Road Element [m]

speed integer Gefahrene Geschwindigkeit [km/h]traffic_flow_error integer Einhaltung der erlaubten Fahrtrichtung

speed_error integer Übertretung der Geschwindigkeitsbegrenzung [km/h]sidestep integer Festgestellte Überholvorgänge

distance_wheelrotation float Durch Radumdrehung berechnete Wegstrecke [m]distance_impulse float Durch Rad-Impuls-Zähler berechnete Wegstrecke [m]distance_speed float Durch Geschwindigkeit berechnete Wegstrecke [m]

deflection_wheelrotation float Durch Radumdrehung berechnete Krümmung [m−1]deflection_impulse float Durch Rad-Impuls-Zähler berechnete Krümmung [m−1]

direction_wheelrotation float Durch Radumdrehung berechnete Richtungsänderung [◦]direction_impulse float Durch Rad-Impuls-Zähler berechnete Richtungsänderung [◦]

geom point Punkt als geometrisches Objekt

Tabelle 5.5: Aufbau der Tabelle ”tracking_point”

36


5.3.2 Straßenverbindungen als Points

Die ”Junctions” sind Verbindungspunkte von ”Road Elements”. Sie werden im GDF eindeutigdurch eine ”point_id” festgelegt. Durch die Attribute ”from_point” und ”to_point” (des RoadElements) wird somit die Orientierung eines Straßenelements vorgegeben. Dieses ist zumBeispiel für Auswertungen hinsichtlich der erlaubten Fahrtrichtung von Bedeutung.


point_id integer ID aus GDFgeom point Punkt als geometrisches Objekt

Tabelle 5.6: Aufbau der Tabelle ”junction_point”

Abbildung 5.12: Straßenverbindungen als Menge von Punkten

5.3.3 Straßennetz als Multilinestrings

Alle Kanten zwischen zwei ”Junctions”, die zu einem ”Road Element” gehören, bilden einMultilinestring. Auch sie hat in GDF eine eindeutige ID (”life_id”). Es ist es möglich, dassdie Orientierung eines Road Elements eine andere ist, als die der Kante. In diesem Fall müssendie Koordinaten der Kante in Richtung des Road Elements gedreht werden.

37



life_id integer ID aus GDFfrom_point_id integer Anfangspunkt (”Junction”)

to_point_id integer Endpunkt (”Junction”)length float Länge des Road Elements [m]

name_attr varchar(50) Straßennametraffic_flow integer Erlaubte Fahrtrichtung

geom multilinestring Linienzug als geometrisches Objekt

Tabelle 5.7: Aufbau der Tabelle ”roadelement_multilinestring”

Abbildung 5.14 verdeutlicht den Zusammenhang zwischen Junction und Road Element.Hier wurden die Linienzüge (Abbildung 5.13) und Punkte (Abbildung 5.12) übereinandergelegt. Eine Junction muss dabei nicht unbedingt, wie hier dargestellt, auf einer Kreuzungliegen. Die GDF-Katensätze von TeleAtlas benutzen nur ein segmentiertes Attribut , dass aufder ganzen Länge gültig ist, je Road Element. Bei Änderung einer Straßeneigenschaft, zwi-schen zwei Kreuzungen, ist es also notwendig die Straße in mehrere kleinere Straßenelementezu unterteilen. Bei dieser Unterteilung werden so auch Junctions zwischen Kreuzungspunktenangelegt.

Abbildung 5.13: Straßen als Linienzüge

5.3.4 Stadtgrenze als Polygon

Zur Modellierung von geschlossenen geometrischen Flächen gibt es in GDF die ”Area Fea-tures”. Leider fehlte in der vorhandenen GeoDatenbank der Bezug zwischen den Area Fea-

38


Abbildung 5.14: Straßenverbindungen mit Straßen

tures (Ebene 1) und den dazugehörigen Elementen aus Ebene 0. So war es nicht möglich,aus den Area Features die Stadtgrenze zu bilden (um innerhalb dessen eine erlaubt Höchst-geschwindigkeit festzulegen).

Eine andere Möglichkeit bestand, in dem direkt auf das Line Feature ”Boundary Element”zugegriffen wurde. Dieses ist die kleinste Einheit, um eine ”Administrative Area” zu be-grenzen. Die höchste Ebene wird dabei ”Country” genannt. Unterabteilungen davon sind die”Order-i Areas”. ”i” und deren genaue Bedeutung ist für jedes Land unterschiedlich (Tabelle5.8). In den vorhandenen Kartensätzen für Osnabrück bildeten alle Boundary Elements in etwadie Stadtgrenze.

order-n Bedeutung1 Bundesland2 Regierungsbezirke3 Kreis8 Gemeinde9 Ortsteil

Tabelle 5.8: ”Order-i Area” - Typen für Deutschland

Da es sich um eine geschlossene Fläche handelt, bietet sich das geometrische Objekt ”Poly-gon” an. Zunächst wurde eine Tabelle ”boundaryelement_multilinestring” angelegt, in der alle

39


Boundary Elements vorhandenen waren. Aus dieser wurde hiernach die Tabelle ”speedrestric-tions_polygon” erstellt.


life_id integer ID aus GDFfrom_point_id integer Anfangspunkt (”Junction”)

to_point_id integer Endpunkt (”Junction”)length float Länge des Boundary Elements [m]

name_attr varchar(50) geom multilinestring Linienzug als geometrisches Objekt

Tabelle 5.9: Aufbau der Tabelle ”boundaryelement_multilinestring”


speed integer Erlaubte Höchstgeschwindigkeit [km/h]geom polygon Geschlossene Fläche als geometrisches Objekt

Tabelle 5.10: Aufbau der Tabelle ”speedrestrictions_polygon”

Abbildung 5.15: Stadtgrenze von Osnabrück als Polygon

40

6 Betrachter für digitale Karten

6.1 Thuban 1.0.0

Thuban ist ein in Python und C++ geschriebener interaktiver Viewer für geographische Da-ten. Herausgegeben wird dieser unter der GNU GPL als Freie Software von der IntevationGmbH. Neben Python wird die Bibliothek wxWindows genutzt, so dass es plattformunab-hängig auf Linux und Windows ausgeführt werden kann. Zudem ist dieser Betrachter dazugeeignet Werte von Attributen zu visualisieren, welche zusätzlich zur Geometrie angelegt wur-den. Die Objekte werden dabei anders farbig (je nach Wert) dargestellt.

Abbildung 6.1: Geodatenbetrachter ”Thuban”

6.1.1 Schnittstellen für Erweiterungen

Ein großer Vorteil von Thuban ist seine leichte Erweiterbarkeit. Somit kann es als Basis fürweiterer GIS-Applikationen dienen.

Die Schnittstelle, zur Entwicklung von Add-Ons, steht in Form der Klasse ”context” zur Ver-fügung. Über eine Instanz dieser Klasse sind Instanzen der Klassen ”application”, ”session”und ”mainwindow” erreichbar. Mit ihnen ist es möglich, auf alle wichtigen Komponenten vonThuban zugreifen zu können. Im Anhang ist hierzu ein kleines ”Hello World!”-Beispiel zufinden.

41


• context.application - wird nur benötigt, wenn eine Session geladen oder gesichert wer-den soll. (Thuban/UI/application.py im Thuban-Verzeichnis)

• context.session - hiermit findet die Verbindung zur Datenbank statt. So liefert”context.session.DBConnections()” ein Array von Instanzen der KlassePostGISConnection. (Thuban/Model/session.py im Thuban-Verzeichnis)

• context.mainwindow - ermöglicht, durch Aufruf von ”context.mainwindow.canvas.full_redraw()”,die aktuelle Karte neu zu zeichnen. (Thuban/UI/mainwindow.py im Thuban-Verzeichnis)

6.1.2 Schnittstelle zur Datenbank

Im Thuban-Verzeichnis ”Thuban/Model” befindet sich das Python-Modul ”postgisdb.py”.Hier gibt es eine Klasse mit Namen ”PostGISConnection”, über deren Methode ”cursor()”eine Cursor-Instanz für Datenbankzugriffe angefordert werden kann. Die Abfrage der Daten-bank gestaltet sich dann, mit gewohnten SQL-Befehlen, sehr einfach.

1 # ******** DELETE ********db_execute = "DELETE FROM my_table"self.cursor.execute(db_execute)

# ******** SELECT ********db_execute ="SELECT * from my_table"self.cursor.execute(db_execute)values = self.cursor.fetchall()

10 # ******** INSERT ********db_execute = "INSERT into my_table (value) values (%d)" % (1)self.cursor.execute(db_execute)

Sollen geometrische Objekten (aus einer Datenbank) in Thuban dargestellt werden, so müssendie Tabellen folgende Eigenschaften besitzen:

• ”srid” muss den Wert -1 haben

• Jede darzustellende Tabelle, mit geometrischen Informationen, muss ein eindeutiges At-tribut mit Namen ”gid’ besitzen (als ”integer”)

• Thuban kann nur geometrische Objekte vom Typ Polygon, Multipolygon, Multilinestringund Point aus der Datenbank darstellen

6.2 Erweiterung zur Fahrdatenauswertung

Die in dieser Arbeit entwickelte Erweiterung für Thuban (”Data Analysis”) wurden in Pythongeschrieben. Für die graphische Oberfläche setzt Thuban auf wxWindows auf. In diesem Ab-schnitt wird daher zunächst auf Python/wxWindows eingegangen und hiernach auf die Er-weiterung.

42


6.2.1 Python 2.3.3 / wxWindows / wxPython

Python 2.3.3

Die Annahme, Python habe etwas mit einem Reptil zu tun, ist falsch. Tatsächlich ist der Namevon britischen Komikern - Monty Python’s Flying Circus - entliehen (von Löwis und Fischbeck(2001)). Im Gegensatz zu C ist Python keine kompilierte Sprache. Sie ist eine Interpreter-sprache, welche zur Laufzeit aus dem Quellcode einen Bytecode erzeugt. Dieser Bytecodeverzichtet auf Maschinencode und ist somit plattformunabhängig ausführbar. Ein ähnlichesVorgehen ist bei der Sprache Java wiederzufinden.

Einige der Vorteile, bei Verwendung von Python, sind:

• Plattformunabhängigkeit

• Fehlertoleranter (im Gegensatz zu C-Programme)

• Python besitzt einen einfachen Syntax

• Klare Strukturen, die eingehalten werden müssen, erleichtern das spätere Lesen vonPython-Programmmen

• Verbesserter Programmaufbau und einfache Wartung durch Unterstützung der objekt-orientierten Programmierung (OOP)

• Integration von C-Modulen in Python-Programme möglich(Python selbst ist in C geschrieben)

• Python ist Open Source

Diese Gründe tragen dazu bei, dass sich Python bei der schnellen Prototypenentwicklung(Rapid Prototyping) großer Beliebtheit erfreut.

wxWindows / wxPython

An der Universität von Edinburgh wurde das kostenlose wxWindows entwickelt. Es han-delt sich hierbei um eine in C++ geschriebene Bibliothek zur Programmierung von graphis-chen Oberflächen. Der große Vorteil, bei Verwendung von wxWindows, liegt in seiner Unter-stützung für viele Plattformen. Eine einmal entwickelte Anwendung lässt sich so einfach aufWindows, Linux oder Mac portieren.

Das von Robin Dunn entwickelte wxPython ist eine Sammlung von Pythonmodulen, dieein Ansprechen von wxWindows ermöglichen. Durch die ähnliche Programmarchitektur zuwxWindows kann deren Dokumentation ebenfalls verwendet werden.

43


Um einen ersten Einblick in die Möglichkeiten dieser Module zu erlangen, ist es sehr empfeh-lenswert die vorgefertigte Sammlung von Programmbeispielen anzusehen. Sie werden au-tomatisch bei der Installation von wxPython mit installiert.

6.2.2 Erweiterung ”Data Analysis”

Die Einbindung der Erweiterung ”Data Analysis” kann in Thuban auf zwei verschiedenenArten erfolgen.

• Alle Dateien der Erweiterung werden in das Verzeichnis ”.thuban” kopiert, oder

• Der Pfad zu den Dateien ist in der Systemvariable ’PYTHONPATH” eingetragen

Bei beiden Methoden ist aber wichtig, dass die Datei ”thubanstart.py” vorhanden ist, da sienach Programmstart importiert wird. In ihr werden die Importe zu sämtliche Erweiterungenangegeben. Wurde alles erfolgreich ausgeführt, erscheint ein weiterer Menüpunkt in Thuban(”Fahrdaten”), über dem das Analyse-Modul (Abbildung 6.2) erreicht werden kann.

Abbildung 6.2: Thuban-Erweiterung zur Fahrdatenauswertung

Menüpunkte

• File - Laden von Fahrzeug-CSV-Dateien

• Analyze - MapMatching, Auswertung der Fahrtrichtung, Geschwindigkeitsüber-schreitungen und Überholvorgänge

• Set - Setzen von Geschwindigkeitsbegrenzungen auf Straßen(teilstücken)

• Show - Graphische Auswertung der Streckenlänge, Krümmung und Richtungsänderung

• Report - Schreibe/Lesen von XML-Dateien mit Informationen über Fahrtrichtung, Ge-schwindigkeitsüberschreitungen und Überholvorgänge

44


Klassen

Nach dem dreireihigen Architekturschema des ”Three-Tiers-Models” wurde auf die Trennungvon Benutzerschnittstelle, Logik der Anwendung und Datenhaltung geachtet. In der Klasse”Processing” findet die gesamte Steuerung der Anwendung statt. Für das Schreiben der XML-Dateien ist die Klasse ”XMLWriter” zuständig (Datenhaltung). Alle anderen Klassen sind demBereich ”Benutzerschnittstelle” zugeordnet.

Die Klassen ”XMLWriter”, ”XMLViewer_Frame” und ”PythonSTC” entstammen aus Tutori-als, die für diese Arbeit angepasst wurden.

Abbildung 6.3: Einfaches Klassendiagramm der Erweiterung

45

7 Fahrdatenauswertung

In diesem Kapitel werden die Methoden und Resultate zur Fahranalyse vorgestellt, wobei Wertauf die mathematischen Zusammenhänge, Algorithmen und Ergebnisse gelegt wird.

7.1 Verfügbare Fahrzeugdaten

Als ”Odometer” werden die Sensoren des Anti-Blockier-Systems (ABS) bezeichnet. Signaledieser Sensoren können, zusammen mit einem Kreisel und/oder elektronischem Kompass,für Fahrzeugnavigationssysteme eingesetzt werden. Mit einem Kreisel können Richtungsän-derungen festgestellt werden. Der elektronische Kompass stellt die Orientierung zum magne-tischen Nordpol fest. In Tabelle 7.1 sind einige Systeme, mit ihren jeweiligen verwendetenSensoren, dargestellt (Czommer (2000)).

Aus dieser Tabelle ist zu erkennen, dass hauptsächlich das Tachosignal (zur Weglängener-mittlung), der Kreisel (Richtungsänderung) und das GPS genutzt werden. Die in dieser Arbeitzu Verfügung gestandenen Fahrzeuginformationen werden im Folgenden erklärt. Alle Datenentstammen aus der Fahrzeug-CSV-Datei (Kapitel 4).

Navigationssystem Radsensor Tacho Kompass Kreisel GPS KartenAlpine NVE-N055ZP X X X Navtech

Becker TrafficStar X X X NavtechBlaupunkt Travel Pilot (RGN08) X X X TeleAtlas

Clarin Nax 9400 E X X X TeleAtlasDelco Telepath 100 X X X EtakGPS Gear Autopilot X TeleAtlas

Grundig Pilot System GPS-1 X X X NavtechMagneti Marelli Route Planer X X X Navtech

Philips Carin 520 X X X NavtechPioneer Car-Navigation System X X X Navtech

Pioneer GPS-X77 X EtakSharp ? X X Navtech

Sony NVX-F160 X ?

Tabelle 7.1: Navigationssysteme, Sensoren, Kartendaten

46


7.1.1 GPS

Dieses entspricht dem Standard-GPS (ohne SA), wie es schon in Kapitel 3 beschrieben wurde.Längen- und Breitengrade sind mit dem Normierungsfaktor 1000000−1 zu multiplizieren, umDezimalgrade zu erhalten (Kapitel 4).

7.1.2 Tachosignal

Die Fahrzeuggeschwindigkeit (in der Einheit km/h) kann direkt aus der CSV-Datei übernom-men werden. Es ist keine Normierung notwendig.

Es ist möglich hieraus, in Verbindung mit dem CAN-Timer (Kapitel 4), eine Längenberech-nung der gefahrenen Wegstrecke durchzuführen:

∆s = Speed ·1000 m

km

3600 sh

· ∆CANTimer · 0.0075s (7.1)

[∆s] = m (7.2)

[Speed] =km

h(7.3)

7.1.3 Radumdrehungen

Von den linken und rechten Vorderrädern stand die Radumdrehung zur Verfügung. Die Berech-nung der Wegstrecke ergibt sich aus 7.4 und 7.5, nach der Multiplikation des Radumdrehungs-wertes aus der CSV-Datei mit dem Faktor 2−1. Für die beiden Räder wird ∆s jeweils getrenntermittelt.

∆sL =WheelRotationL · WheelRadiusL · 2π

60 smin

· ∆CANTimer · 0.0075s (7.4)

∆sR =WheelRotationR · WheelRadiusR · 2π

60 smin

· ∆CANTimer · 0.0075s (7.5)

[∆sL] = m (7.6)

[∆sR] = m (7.7)

[WheelRotationL] = min−1 (7.8)

[WheelRotationR] = min−1 (7.9)

[WheelRadiusL] = m (7.10)

[WheelRadiusR] = m (7.11)

(7.12)

47


WheelRadiusL und WheelRadiusR sind mit dem konstanten Wert 0.32945 m anzunehmen.

7.1.4 Rad-Impuls-Zähler

Beim Rad-Impuls-Zähler werden Impulse gezählt, die von einem rotierenden Zahnrad stam-men (Abbildung 7.1). Jedes dieser Zähne hat den gleichen Abstand, so dass durch die Anzahlder gezählten Impulse die zurückgelegte Wegstrecke berechnet werden kann. In dieser Arbeitsind es 96 Impulse pro ganzer Radumdrehung. Der Zähler beginnt bei 0. Wird 255 überschrit-ten, findet ein Überlauf statt. Auch hier wird die Strecke getrennt ermittelt. Gegenüber denbeiden vorherigen Methoden wird aber kein ∆CANTimer (Kapitel 4) benötigt.

∆sL =WheelRadiusL · 2π

96· ∆Impulse (7.13)

∆sR =WheelRadiusR · 2π

96· ∆Impulse (7.14)

[∆sL] = m (7.15)

[∆sR] = m (7.16)

[WheelRadiusL] = m (7.17)

[WheelRadiusR] = m (7.18)

(7.19)

Abbildung 7.1: Induktiver ABS-Sensor (Westbrook und Turner (1994))

48


7.1.5 Gierrate

Unter ”gieren” ist die Drehbewegung eines Fahrzeugs um seine Hochachse gemeint (Abbil-dung 7.2). Die ”Gierrate” (ω) ist somit die Geschwindigkeit dieser Drehung. Sie wird in denFahrzeugdaten als Grad pro Sekunde angegeben. Sein Normierungsfaktor hierfür ist 100−1.

Abbildung 7.2: Drehbewegung an einem Fahrzeug (Jaschke (2002))

7.2 Berechnungen aus Radsensoren

Aus Czommer (2000) sind die Formeln 7.20 bis 7.28 zu entnehmen. Sie ermöglichen es, diegefahrene Wegstrecke ∆s, die Richtungsänderung ∆ϕ und die Krümmung κ aus den Sensor-daten der Vorderräder zu berechnen. Hierzu sind zwei Odometer notwendig (also mit Rad-Impuls-Zähler oder Radumdrehungen). ∆sL und ∆sR sind jeweils die Strecken aus 7.1.3 und7.1.4. Zusätzlich müssen noch die Parameter a (halbe Spurweite) und b (Radstand) angegebenwerden. Die Werte des Testfahrzeugs waren a = 0.785 m und b = 2.97 m. Rh ist hier derKrümmungsradius.

γ =

√

a2 · (∆s2L + ∆s2R)2(∆s2L − ∆s2R)2

− (a2 + b2) (7.20)

τ = a ·∆s2L + ∆s

2R

∆s2L − ∆s2R(7.21)

Rh =

τ + γ falls ∆sL > ∆sR (Rechtskurven)

τ − γ falls ∆sL < ∆sR (Linkskurven)unendlich falls ∆sL = ∆sR (keine Richtungsänderung)

[Rh] = m (7.22)

49


Abbildung 7.3: Wegelement, Richtungsänderung und Krümmung aus Odometern

7.2.1 Wegelement

∆s =

√

Rh · (∆s2L − ∆s2R)4 · a

(7.23)

[∆s] = m (7.24)

Wenn κ = unendlich, dann gilt ∆s = ∆sL und ∆s = ∆sR.

Abbildung 7.4: Wegelement aus Fahrzeugdaten (in Thuban)

50


Abbildung 7.4 ist ein Beispiel der implementierten Wegelementberechnung/Darstellung inThuban. Auf der X-Achse sind die ”tracking_points” (siehe 5.3.1) - hier mit GPS ermittelt -und auf der Y-Achse die gefahrene Distanz eingezeichnet. Für eine genauere Analyse wurdeauch die Differenz zwischen den Distanzen von tracking_point zu tracking_point und denberechneten Wegstrecken dargestellt. Auffällig ist, dass die Werte aus dem Rad-Impuls-Zählerund der Radumdrehung sehr dicht zusammen liegen. Etwas abseits befindet sich im allge-meinen das Tachosignal (Abbildung 7.5).

Abbildung 7.5: Vergleich der Wegelementberechnung aus Fahrzeugdaten (in Thuban)

7.2.2 Krümmung

κ =1

Rh(7.25)

[κ] = m−1 (7.26)

Aus der Krümmung κ kann auf die Richtung, in der sich das Fahrzeug bewegt, geschlossenwerden. Ist κ < 0, so liegt eine Rechtskrümmung (konkav) vor. Eine Linkskrümmung (kon-vex) liegt vor, wenn κ > 0. Wenn Rh = unendlich, dann soll κ = 0 sein.

51


Abbildung 7.6: Darstellung einer Testfahrt (in Thuban)

Abbildung 7.7: Auswertung der Krümmung (in Thuban)

In Abbildung 7.7 sind deutlich die vier Spitzen zu sehen, die an den Kreuzungspunkten inAbbildung 7.6 auftreten. Da sie negativ sind, muss die Fahrt im Uhrzeigersinn erfolgt sein.

7.2.3 Richtungsänderung

∆ϕ =

√

∆s2L − ∆s2R4 · a · Rh

(7.27)

[∆ϕ] = rad (7.28)

52


ϕ muss Null sein, wenn Rh = unendlich.

Abbildung 7.8: Auswertung der Richtungsänderung (in Thuban)

Die Abbildung 7.8 bezieht sich ebenfalls auf die Fahrt von Abbildung 7.6. Auch hier sinddie Spitzen, wie bei der Krümmung, zu erkennen. Die Darstellung bei Thuban erfolgt in Grad(Y-Achse).

7.3 Bestimmung der Fahrzeugposition

7.3.1 GPS-Position

Dieses ist die einfachste Möglichkeit, die Fahrzeugposition zu bestimmen. Aus der Fahrzeug-CSV-Datei wird dann ein neuer ”tracking_point” gesetzt, wenn eine neue GPS-Position zurVerfügung steht.

Abbildung 7.9: Positionsbestimmung mit GPS (in Thuban)

53


7.3.2 GPS-Position und Radrotation/Rad-Impuls-Zähler

Hier wird die anfängliche Position durch GPS bestimmt. Dies ist notwendig, um die Startpo-sition und Startausrichtung zu ermitteln. Alle weiteren Fahrzeugpositionen werden mit Hilfeder Radsensoren berechnet.

Der Algorithmus:

1. Ersten/nächsten GPS-Punkt (P1) suchen, bei dem die Geschwindigkeit ≥ 20 km/h ist(Fahrzeug soll sich fortbewegen)

2. Nachfolgender (unterschiedlicher) GPS-Punkt ist P2, wenn eine geringe Richtungsän-derung zu P1 stattgefunden hat (wird über Gierrate ermittelt)

3. Wenn die Richtungsänderung bei 2. zu groß war, starte wieder bei 1.

4. P1 und P2 auf der digitalen Straßenkarte einpassen (Map Matching)

5. Aus P1 und P2 die Startausrichtung (Startwinkel) t berechnen

6. Die Koordinaten von P2 sollen (xfahrzeug, yfahrzeug) sein

7. Die Richtungsänderung (∆ϕ), die Krümmung (κ) und das Wegelement (∆s) auf 0 set-zen

8. ∆ϕ, κ und ∆s für den nächsten Datensatz (Fahrzeug-CSV-Datei) bestimmen und auf-summieren

9. Wiederhole 8., wenn sich GPS-Time nicht ändert

10. Neue Fahrzeugausrichtung bestimmen:

t = t − ∆ϕ, wenn κ < 0 (Rechtskrümmung) odert = t + ∆ϕ, wenn κ > 0 (Linkskrümmung)

Auf ”Überläufe” beim Bogenmaß sind zu achten:

t = t − 2π, wenn t > 2πt = 2π + t, wenn t < 0

11. Neue Fahrzeugposition bestimmen (dieses entspricht der ”ersten geodätischen Grund-aufgabe” - Bill (1999))

xfahrzeug = xfahrzeug + ∆s cos tyfahrzeug = yfahrzeug + ∆s sin t

54


12. (xfahrzeug, yfahrzeug) als ”tracking_point” speichern

13. Ab 7. wiederholen, wenn das Dateiende der CSV-Datei noch nicht erreicht wurde

Eine genauere Betrachtung ist noch bei Punkt 5 notwendig, der Bestimmung des Startrich-tungswinkels. Dieses erfolgt mit der ”zweiten geodätischen Grundaufgabe” (Bill (1999)).

t = arctann2 − n1o2 − o1

(7.29)

P1

P2

Ostwert(o)

Nordwert(n)

t

Abbildung 7.10: Bestimmung des Startrichtungswinkels

Der Wertebereich der arctan-Funktion ist aber nur im offenen Intervall (−π/2, π/2) definiert(also zwischen -90◦ und + 90◦). Dieses bedeutet, dass in Abhängigkeit des Nord- und Ost-wertes (Quadranten in Abbildung 7.11) noch ein weiterer Korrekturwert addiert werden muss.

t = arctann2 − n1o2 − o1

+ t0 (7.30)

Documents

Inhaltsverzeichnis · Aufgabenstellung dieser Arbeit war eine Fahrdatenanalyse auf Basis einer objektrelationalen GeoDatenbank und eines GPS-Empfängers zu ermöglichen. Um dieses