28. BWINF, Runde 1, Aufgabe 3: Wegfehler - Matthias Springer .DE

28. BWINF, Runde 1, Aufgabe 3: Wegfehler
Stefan Hansch Markus Wirsing Matthias Springer
12. November 2009
1 Lösungsidee
1.1 Einlesen der Bilddatei
Momentan sollen noch keine Änderungen oder Anpassungen an den GPS-Daten
vorgenommen werden, sie sollen lediglich unverändert eingezeichnet werden. Wie
bei Aufgabe 5 handelt es sich um das PPM-Format. Deshalb wurden einige Zeilen
Quelltext aus Aufgabe 5 übernommen und es gelten die gleichen Anforderungen
an die Eingabedatei. So muss die PPM-Datei etwa im P5-Format vorliegen
und es können nur 24-bit-PPMs verarbeitet werden. Die gesamte Bilddatei wird
in eine W x H x C-Matrix eingelesen, wobei W die Breite und H die Höhe der
Bilddatei in Pixel ist. Die dritte Dimension der Matrix dient wie gewohnt zur
Identifikation der drei Farbkanäle rot, grün und blau (RGB). Es soll nun nicht
weiter auf das Einlesen der Bilddatei eingegangen werden, da es wie in Aufgabe
5 durchgeführt wird und im Quelltext gut kommentiert wurde.
1.2 Einlesen der GPS-Daten
Mit Pixel-Daten lässt es sich meiner Meinung nach leichter arbeiten, als mit
GPS-Daten. Deshalb werden Längen- und Breitengrade in entsprechende Pixel-
Koordinaten auf der Bilddatei umgerechnet. Die Koordinaten der Ecken der
Bilddatei wurden der BWINF-Seite (Material zu den Aufgaben) entnommen
und können vom Benutzer nicht verändert werden. Da es sich bei der Landkarte
um einen relativ kleinen Bereich der Erdoberfläche handelt, kann die Krümmung
der Erde in diesem Bereich vernachlässigt werden. Das Problem wird vereinfacht,
indem einfach angenommen wird, dass es sich um einen rechteckigen Bereich
handelt.
Um nun zum Beispiel den x-Pixelwert eines Punktes zu berechnen, wird
zuerst das Verhältnis Pixel pro Längengrad bestimmt. Dieses ergibt sich aus
dem Quotienten der Breite (Proportionen in x-Richtung) des Bildes in Pixel und
der Breite des Bildes in geographischer Länge. Letzterer Wert ergibt sich aus der
Differenz der geographischen Längen der gegebenen Eckpunkte der Landkarte.
Definition 1 Somit kann die x-Koordinate eines geographischen Punktes mittels
der Funktion
proportions[0]
x pixel(Longitude[x]) =
Longitude[rechts]−Longitude[links]
· (Longitude[x] −
Logitude[links])
1

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
in einen Pixel-Wert auf der zu Grunde liegenden Landkarte konvertiert werden,
wobei x pixel der x-Koordinate eines Punktes auf der Landkarte, Logitude[x]
dem Längengrad (geographische Länge) des Punktes aus dem GPS-Daten
und proportions[0] der Breite des Bildes in Pixel entsprechen.
Die Bezeichnungen der Variablen entsprechen dabei so weit wie möglich den
im Quelltext verwendeten Variablennamen und den bereits in Aufgabe 5 verwendeten
Bezeichnungen. Analog wird bei der Berechnung der y-Koordinaten
verfahren, jedoch ist hier zu beachten, dass die Breitengrade entgegengesetzt zu
den y-Pixelwerten wachsen. Das heißt, dass die Pixel-Werte von oben nach unten
zunehmen, die Breitengrade jedoch von unten nach oben (auf der Bilddatei). Die
komplette Log-Datei wird im Arbeitsspeicher in drei Arrays gespeichert, wobei
Zeit, Längengrad und Breitengrad (jeweils als Pixel) gespeichert werden. Zeitangaben
werden in vorzeichenlose Ganzzahlen umgewandelt, die die seit 00:00:00
Uhr vegangene Zeit in Sekunden angeben. Zu Problemen kommt es jedoch, wenn
eine Log-Datei über mehrere Tage geht, d. h. wenn ein Sprung von 23:59:59 Uhr
auf 00:00:00 Uhr stattfindet. Ein solcher Spezialfall wird nicht abgedeckt, da er
in Dominics GPS-Logs nicht auftritt.
1.3 Einzeichnen eines Weges auf der Karte
Schreibe ein Programm, das einen Weg auf der Karte einzeichnet.
Es sollen zunächst keine Anpassungen an den GPS-Daten vorgenommen werden.
Es sollen alle Daten (ggf. mit Fehlern) auf die Karte gezeichnet werden.
Dazu iteriert das Programm über alle Einträge in den Log-Daten und zeichnet
entsprechende Linien auf der Landkarte ein, indem die betroffenen Pixel
grün eingefärbt werden. Für diesen Vorgang sind lediglich die Koordinaten der
GPS-Daten von Interesse, nicht jedoch die Zeitangaben. Zum Schluss wird das
neue Bild wie in Aufgabe 5 auf der Festplatte gespeichert. Das Bild vom Aufgabenblatt
erhält man, indem man alle drei Log-Dateien auf eine Landkarte
einzeichnet.
Eine Strecke wird dazu als ein Vektor ⃗v mit Aufpunkt A aufgefasst. Die
Länge einer Strecke ergibt sich durch den
√
Betrag des Vektors |⃗v| und wird mittels
Pythagoras über die Beziehung |⃗v| = vx 2 + vy 2 berechnet. Nun wird aus den
Pixelangaben (Start- und Zielpunkt der Strecke) der Einheitsvektor gebildet.
Dieser Vektor hat die Länge 1 und dient lediglich dazu, die Richtung anzuzeigen.
Er wird gebildet, indem der Vektor durch seine Länge (ein Skalar) dividiert
wird. Nun iteriert das Programm ganzzahlig über das Intervall i ∈ [0; |⃗v|] und
berechnet den Punkt, der vom Aufpunkt A genau i (Pixel-)Einheiten entfernt ist
und die Richtung von ⃗v besitzt. Dazu wird der Einheitsvektor mit i multipliziert.
Dieser Punkt wird eingefärbt. Zum Schluss ist also mit Sicherheit die ganze
Strecke eingefärbt.
1.4 Korrektur der Fehler
In den GPS-Logs können Daten fehlen oder falsch sein. Erweitere
Dein Programm so, dass es versucht, die Fehler zu korrigieren, um
so den Weg möglichst realistisch einzeichnen zu können.
2

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
Bei der Betrachtung des eingezeichneten Weges fallen bereits einige offensichtliche
Fehler auf. So liegen manche Punkte, die Dominic besucht, beispielsweise
außerhalb der Landkarte und werden mit einer atemberaubenden Geschwindigkeit
erreicht. Diese und weitere Fehler sollen nun behoben werden. Dabei habe
ich angenommen, dass die in den Log-Dateien auftretenden Fehler repräsentativ
für alle Testfälle sind, also nur solche Fehler behoben werden müssen, die in
den drei bekannten Testfällen auftreten. So könnte es theoretisch vorkommen,
dass manche Zeitangaben falsch sind. Das ist jedoch in den bekannten Testfällen
nicht der Fall. Es kann lediglich vorkommen, dass manche Einträge komplett fehlen
oder nicht im 5-Sekunden-Rhythmus aufgenommen wurden. Das Programm
muss die folgenden Fehler in den Log-Dateien verarbeiten können.
1. Die GPS-Koordinaten sind zu einem bestimmten Zeitpunkt oder in einem
ganzen Zeitintervall falsch.
2. Zu bestimmten Zeitpunkten oder in einem ganzen Zeitintervall fehlen Log-
Einträge.
3. Aufeinanderfolgende Log-Einträge wurden nicht im 5-Sekunden-Rhythmus
aufgezeichnet.
Die nun folgenden Annahmen über die Log-Daten müssen erfüllt sein, damit der
Algorithmus die GPS-Daten möglichst korrekt rekonstruieren kann. Die meisten
dieser Anforderungen könnten mit Änderungen am Algoritmus mit Sicherheit
fallen gelassen werden, jedoch würde dies einerseits einen großen Aufwand
erfordern und andererseits treten diese Spezialfälle in den Testfällen von der
BWINF-Seite ohnehin nicht auf.
1. Es treten nur die in der vorherigen Liste genannten Fehler auf.
2. Der erste Eintrag in der Log-Datei ist immer korrekt.
3. Die Fehler in der Log-Datei halten sich in Grenzen.
4. Dominic bewegt sich mit annähernd konstanter Geschwindigkeit. Leichte
Abweichungen führen in der Regel nicht zu Problemen.
1.5 Fehler in den GPS-Koordinaten
Ein Fehler in den GPS-Koordinaten soll mit Hilfe von späteren GPS-Daten
behoben werden. Da keine weiteren Informationen zur Verfügung stehen, ist
natürlich nicht genau bekannt, welchen Weg Dominic zurücklegt. Deshalb kann
nur mit Hilfe von später aufgezeichneten Daten ein Fehler in den GPS-Koordinaten
behoben werden, indem man annimmt, dass sich Dominic zum Beispiel geradlinig
auf einen Koordinatenpunkt zubewegt, von dem bekannt ist, dass er korrekt
ist. Allerdings ist nicht bekannt, welche Koordinaten richtig und welche falsch
sind. Aus diesem Grund berechnet das Programm eine Wahrscheinlichkeitsfunktion,
die für jeden Punkt in den GPS-Koordinaten ausgibt, wie wahrscheinlich es
ist, dass sich Dominic auf irgendeinen späteren Punkt in den GPS-Koordinaten
zubewegt.
Hinter der Wahrscheinlichkeitsfunktion steckt die Idee, dass sich Dominic
mehr oder weniger mit konstanter Geschwindigkeit bewegt. In den GPS-Daten
können bestimmte Fehler dadurch erkannt werden, dass innerhalb kürzester Zeit
3

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
sehr große Strecken zurückgelegt werden. Eine Wahrscheinlichkeitsfunktion soll
nun für jede beliebige Geschwindigkeit (velocity) eine Aussage darüber geben,
wie wahrscheinlich es ist, dass sich Dominic mit dieser Geschwindigkeit fortbewegt.
Dazu iteriert das Programm über alle GPS-Koordinaten und berechnet
die Geschwindigkeit, mit der sich Dominic zum nächsten Punkt fortbewegt
(Geschwindigkeit = Strecke / Zeit, Array db p segment). Eine Geschwindigkeit
velocity soll genau dann als sehr wahrscheinlich angenommen werden, wenn die
Funktion db p getProbability an dieser Stelle minimal ist.
Definition 2 Die Funktion ist dabei mit db p getProbability(velocity) = ∑ n−1
i=1 v i−
velocity definiert.
Mit Hilfe der Funktion db p getProbability kann also zu jeder beliebigen
Geschwindigkeit velocity ausgesagt werden, wie wahrscheinlich es ist, dass sich
Dominic mit dieser Geschwindigkeit fortbewegt. Dazu werden einfach die Differenzen
zwischen allen Geschwindigkeiten aus der Log-Datei und der Geschwindigkeit
velocity aufsummiert. Die Geschwindigkeiten aus der Log-Datei können
einfach mit der Beziehung Geschwindigkeit = Strecke/Zeit berechnet werden.
Dabei ist Strecke der geometrische Abstand zwischen zwei aufeinanderfolgenden
GPS-Einträgen und Zeit der zeitliche Abstand zwischen den zwei
GPS-Einträgen. Der Term n − 1 in Definition 2 steht für die Anzahl aller
Geschwindigkeits-Daten, die der Log-Datei entnommen werden können, wenn
n Einträge in der Log-Datei vorliegen.
Nach einigen Experimenten, habe ich die Funktion db p getProbability so
abgeändert, dass insgesamt nur Geschwindigkeitsüberschreitungen betrachtet
werden, und keine Unterschreitungen. Dadurch erzielt das Programm bessere
Ergebnisse. Es kann schließlich vorkommen, dass Dominic auch mal langsamer
geht. Nur besonders hohe Geschwindigkeiten sind besonders unwahrscheinlich.
Wenn Fehler in den GPS-Koordinaten auftreten, können diese nicht gänzlich
korrigiert werden. Schließlich kann keine sichere Aussage darüber getroffen werden,
wie sich Dominic wirklich bewegt hat. Es besteht lediglich die Möglichkeit,
bestimmte GPS-Koordinaten als falsch zu deklarieren, wenn es sehr unwahrscheinlich
ist, dass sich Dominic in einem bestimmten Zeitfenster dort hin begeben
hat. Wenn der fehlerhafte Bereich erst einmal identifiziert wurde, kann er
mit sinnvollen Daten ersetzt werden. Ob sich Dominic jedoch wirklich so bewegt
hat, kann man nicht sagen.
Abbildung 1 zeigt einen Weg, den Dominics GPS-Gerät aufgezeichnet hat.
Dabei stellen die schwarzen Linien den korrekt aufgezeichneten Weg dar. Die
roten Linien befinden sich ebenfalls in den GPS-Logs, sind jedoch falsch. Wenn
das Programm erkannt hat, dass der fehlerhafte Bereich zwischen den Punkten
E und H liegt, versucht es, die Logs zu korrigieren. Dazu wählt es die grüne Linie
als Ersatz für die roten Linien. Ob sich Dominic jedoch wirklich so fortbewegt
hat, oder aber so, wie die blauen Linien verlaufen, bleibt ungewiss.
Um nun Fehler in den GPS-Koordinaten zu korrigieren, iteriert das Programm
über alle Punkte aus der Log-Datei (äußere Schleife). Jetzt wird für
jeden solchen Punkt der nächste (darauffolgende) Punkt bestimmt. Dazu iteriert
das Programm über alle Punkte, die zeitlich nach dem aktuellen Punkt
liegen (innere Schleife). Mit Hilfe der Funktion db p getProbability kann nun
bestimmt werden, wie wahrscheinlich es ist, dass der aktuelle Punkt in der innersten
Schleife der Nachfolger des aktuellen Punktes in der äußeren Schleife
4

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
Abbildung 1: Korrektur von GPS-Fehlern
5

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
Abbildung 2: Falsche Korrektur von GPS-Fehlern
ist. Als Strecke wird die geometrische und als Zeit die zeitliche Differenz zwischen
den beiden Punkte in die Funktion eingesetzt (Geschwindigkeit = Strecke
/ Zeit).
Bei der Verarbeitung der Daten scheiden somit diejenigen Punkte aus, die
laut GPS-Daten mit einer unwahrscheinlichen Geschwindigkeit erreicht werden.
In Abbildung 1 sei der zeitliche Abstand in den GPS-Logs zwischen den einzelnen
Punkte A bis J jeweils eine Zeiteinheit (also gleich). Dann ist es sehr
unwahrscheinlich, dass sich Dominic von Punkt E nach Punkt F fortbewegt,
weil er seine Geschwindigkeit mehr als versechsfacht. Wenn die äußere Schleife
bei Punkt E angelangt ist und nach einem geeigneten Nachfolger sucht, wird
Punkt F sehr schlecht bewertet. Ebenso wird Punkt G schlecht bewertet. Dominic
stehen nun zwar zwei Zeiteinheiten zur Verfügung, um jedoch von Punkt E
nach Punkt G zu gelangen, würde Dominic seine Geschwindigkeit immer noch
mehr als verfünffachen. Schließlich wird Punkt H betrachtet. Dieser Punkt wird
als viel wahrscheinlicher eingeschätzt, weil Dominic seine Geschwindigkeit von
E nach H beibehälten würde.
Jedoch ergibt sich das Problem, dass möglicherweise viele Punkte aus den
GPS-Logs übersprungen werden, weil die Wahrscheinlichkeitsfunktion (bisher)
nur Strecke und Zeit beachtet. Dazu betrachte man Abbildung 2. Es sind keine
Fehler in den GPS-Logs aufgetreten und trotzdem schlägt das Programm
die grüne Strecke von Punkt E nach Punkt J vor. Ab Punkt E beschleunigt
Dominic etwas. Man stelle sich vor, die GPS-Logs seinen etwas größer, als der
dargestellte Bereich und Dominic würde sich nach Punkt J weiter mit konstanter
6

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
Geschwindigkeit, wie von Punkt A bis Punkt E, bewegen. Das bedeutet, dass es
wahrscheinlicher ist, dass sich Dominic mit der Geschwindigkeit wie von Punkt
A bis Punkt E bewegt, als mit der Geschwindigkeit wie von Punkt E bis Punkt
J. Wenn die äußere Schleife bei Punkt E angelangt ist, werden alle potentiellen
Nachfolgepunkte betrachtet. Schließlich wird Punkt J gewählt, weil Dominic bei
geradliniger Bewegung von Punkt E nach Punkt J seine Geschwindigkeit beibehalten
würde. Eine minimale Änderung der Fortbewegungsgeschwindigkeit hat
also dazu geführt, dass ein richtiger Weg verworfen wird.
Dies kann man verhindern, indem man Punkte in der inneren Schleife nach
der Anzahl der übersprungenen Punkte (Anzahl der übersprungenen Punkte
zwischen aktuellen Punkten in der inneren und äußeren Schleife) gewichtet.
Je mehr Punkte übersprungen werden müssten, desto unwahrscheinlicher wird
dieser Nachfolger eingestuft. Wenn Fehler in den GPS-Logs zu stark überhöhten
Geschwindigkeiten führen, werden die Logs trotzdem korrigiert, weil der Geschwindigkeits-
Aspekt in der Wahrscheinlichkeitsfunktion stärker wiegt, als die Gewichtung
auf Grund von übersprungenen Punkten. Zu Problemen kann es aber kommen,
wenn zu große Teile der Log-Datei fehlerhaft sind. Eine große Anzahl an GPS-
Koordinaten wird in der Regel nicht übersprungen.
Man betrachte hierzu wieder Abbildung 2. Um den Weg von Punkt E nach
Punkt J wie vorgeschlagen zu korrigieren, müssten vier Punkte (F bis I) übersprungen
werden. Dieser Faktor Vier fließt auf irgendeine negative Weise in die
Gewichtung ein, sodass der Weg in Abbildung 2 nicht korrigiert wird. Es muss
nun festgestellt werden, wie dieser Faktor genau in die Gewichtung einfließt.
Wiegt er zu stark, werden evtl. Fehler wie in Abbildung 1 nicht mehr korrigiert,
wiegt er zu schwach, treten Fehler wie in Abbildung 2 auf. Der Faktor könnte
beispielweise linear oder exponentiell in die Bewertung einfließen. Im letzteren
Fall wiegen große Zahlen auf Grund des schnellen Wachstums der exponentiellen
Funktion sehr stark, kleine Zahlen jedoch nicht so stark. Es wird also angenommen,
dass es schon mal vorkommen kann, dass einzelne Punkte falsch sind. Auf
der anderen Seite wird auch angenommen, dass es sehr unwahrscheinlich ist,
dass weite Punkt-Intervalle falsch sind.
1.6 Fehler in den Zeitangaben
Wie bereits erwähnt, können Log-Einträge nur entweder ganz fehlen oder in
verschiedenen Zeitintervallen aufgenommen werden. Beide Fälle können gleich
behandelt werden, weil das Fehlen von Log-Einträgen dem Aufzeichnen von
Log-Daten in unterschiedlichen Zeitintervallen gleicht. Bei Betrachtung des im
vorherigen Kapitel vorgestellten Algorithmus wird klar, dass fast keine weiteren
Änderungen notwendig sind. Der Algorithmus funktioniert auch dann, wenn die
Zeitintervalle zwischen zwei Log-Einträgen unterschiedlich sind.
Zu Problemen kann es nur dann kommen, wenn große Teile der GPS-Daten
fehlen. In diesem Fall kann der fehlende Bereich nicht sinnvoll rekonstruiert
werden. Stattdessen wird der Weg durch eine gerade Strecke angegleicht. Dieser
Fall wurde bereits im vorherigen Kapitel erläutert. In der Ausgabedatei werden
solche Bereiche mit einer anderen Farbe eingezeichnet.
7

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
2 Programm-Dokumentation
Das Programm wurde mit C++ geschrieben und als Linux-Binary kompiliert.
Wenn der Quelltext unter Windows kompiliert werden soll, sind offensichtlich einige
Änderungen notwendig (besonders im Zusammenhang mit Zeilenbrüchen).
Zumindest kam es bei meinen Versuchen zu Problemen.
Das Programm geht bei der Verarbeitung einer Log-Datei nach den folgenden
Schritten vor.
1. Einlesen der Bilddatei und der Log-Datei in den Arbeitsspeicher.
2. Anwendung der Wahrscheinlichkeitsfunktion auf jeden Log-Eintrag.
3. Bearbeitung der Bilddatei und Speichern der Bilddatei.
2.1 Einlesen der Eingabedateien
Das Einlesen der Eingabedateien funktioniert analog zu Aufgabe 5. Es wurden
für die Bilddatei die gleichen Arrays und Bezeichnungen verwendet. Einige
Zeilen Quelltext wurden sogar komplett übernommen. Die Log-Datei wird
in drei Arrays übertragen, wobei db time[i] den Zeitpunkt des i-ten Eintrags,
db pos x[i] die x-Koordinate und db pos y[i] die y-Koordinate bezeichnen. Der
Zeitwert gibt die seit 00:00:00 Uhr vergangenen Sekunden an und wird nach
der Formel db time[i] = stunden · 3600 + minuten · 60 + sekunden berechnet.
Weil keine weiteren Anpassungen vorgenommen wurden, kann es zu den bereits
genannten Problemen kommen.
GPS-Koordinaten werden in Pixel-Koordinaten konvertiert. Jeder Pixel-Wert
wird auf einen ganzen Integer-Wert abgerundet.
Die Log-Datei wird zeilenweise eingelesen. Weil anfangs noch nicht bekannt
ist, wie viele Zeilen gelesen werden müssen, werden eine Endlosschleife benutzt
und so lange neue Zeilen eingelesen, bis die aktuelle Zeile weniger als 5 Zeichen
lang ist. In einem solchen Fall springt das Programm in den ersten Teil der
entsprechenden If-Struktur und fährt dort mit der Verarbeitung der eingelesenen
Daten fort. Es gibt keine explizite Abbruchbedingung für die Endlosschleife.
Diese terminiert dann, wenn das Programm nach der Verarbeitung der Daten
terminiert.
Es gibt einige Anforderungen an die Eingabedateien, die erfüllt sein müssen,
damit die sie korrekt einlesen werden können.
1. Die Log-Datei weist das gleiche Format wie die Testfälle von der BWINF-
Seite auf. Insbesondere überprüft das Programm, ob die erste Zeile mit der
Zeichenfolge TIME,LATITUDE,LONGITUDE übereinstimmt, um grob
zu überprüfen, ob der Benutzer wirklich eine Log-Datei ausgewählt hat.
2. Die Log-Datei hat den Dateinamen log.csv und die Bilddatei hat den Namen
karte.ppm. Die Ausgabe erfolgt in die Datei karte out.ppm.
3. Es handelt sich um eine 24-bit-PPM vom Typ P6, siehe auch Aufgabe 5.
4. Es findet kein Zeitsprung von 23:59:59 Uhr auf 00:00:00 Uhr statt.
5. Es liegen weniger als 2000 Log-Einträge vor.
6. Die Log-Datei ist korrekt formatiert (wie in den BWINF-Testfällen).
8

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
2.2 Die Wahrscheinlichkeitsfunktion
Der Wert der Wahrscheinlichkeitsfunktion ergibt sich, indem die Differenzen einer
Geschwindigkeit zu allen Geschwindigkeiten in der Log-Datei aufsummiert
werden (siehe Lösungsidee). Dazu wird die Wahrscheinlichkeitsfunktion bei jedem
Aufruf neu berechnet. Es wäre möglich, diesen Vorgang etwas effizienter
zu gestalten, indem die Durchschnittsgeschwindigkeit verwendet wird, jedoch
ergibt sich dadurch effektiv nur ein geringer Laufzeitgewinn, da es sich bei den
BWINF-Testfällen um kleine Eingabedaten handelt.
Nach dem Einlesen der Eingabedateien gilt es, die Wahrscheinlichkeitstabelle
aufzubauen. Da in der Log-Datei nur Zeitangaben und Positionswerte eingetragen
sind, müssen Geschwindigkeiten aus diesen Daten berechnet werden. Nach
diesem Vorgang ist für jedes Paar von aufeinanderfolgenden Log-Einträgen ein
entsprechender Geschwindigkeitseintrag vorhanden (Array db p segment).
√
(db pos x[i+1]−db pos x[i])2 +(db pos y[i+1]−db pos y[i]) 2
Definition 3 Jeder Eintrag im Geschwindigkeitsarray ergibt sich durch die Formel
db p segment[i] =
db time[i+1]−db time[i]
. Dabei
bezeichnen der im Zähler stehende Term den geometrischen Abstand zweier
Punkte und der im Nenner stehende Term den zeitlichen Abstand zweier Punkte.
Nun iteriert das Programm über alle Punkte in der Log-Datei und sucht für
jeden solchen Punkt den wahrscheinlichsten Nachfolger. Dazu wird die Wahrscheinlichkeitsfunktion
auf jeden potentiellen Nachfolger eines solchen Punktes
angewendet. Als Eingabe erwartet die Wahrscheinlichkeitsfunktion eine Geschwindigkeit
die sich analog zu Definition 3 ergibt, nur dass es sich nun nicht
notwendigerweise um aufeinanderfolgende Punkte handeln muss. Je kleiner die
Ausgabe der Wahrscheinlichkeitsfunktion ist, desto wahrscheinlicher ist es, dass
der aktuelle Punkt der beste Nachfolger ist.
In der Funktion db p getProbability wird die Summe der Geschwindigkeitsdifferenzen
wird durch die Durchschnittsgeschwindigkeit und durch n−1 geteilt
(n ist die Anzahl der Punkte). Dadurch erhält man sozusagen eine prozentuale
Abweichung von der Durchschnittsgeschwindigkeit. Ursprünglich hatte ich eine
andere Idee, die ich jedoch aus Zeitgründen nicht realisieren konnte (deshalb so
umständlich). Im Kapitel Lösungsidee wurde bereits angedeutet, wie eine Wahrscheinlichkeitsfunktion
aussehen kann. Ich habe schließlich keine Exponentialfunktion
gewählt. Stattdessen wird die Anzahl der übersprungenen Punkte mit
dem Faktor 0, 45 gewichtet und einfach aufaddiert. Der Nachteil dieser Methode
liegt darin, dass sie speziell auf die in den Testfällen auftretenden Geschwindigkeiten
optimiert ist. Diese Geschwindigkeiten wirken sich auf die Ausgabe
der Wahrscheinlichkeitsfunktion (Funktion db p getProbability, ohne Beachtung
der übersprungenen Punkte) aus. Wenn sich Dominic nun beispielsweise immer
doppelt so schnell bewegt, oder allgemein die auftretenden Geschwindigkeiten
zwischen zwei aufeinanderfolgenden Punkten proportional zueinander um einen
relativen Wert vergrößert werden, nimmt der Einfluss der übersprungenen Punkte
ab. Man müsste in diesem Fall den Faktor 0, 45 ebenfalls vergrößern, nämlich
um den Faktor 2.
Man könnte das Problem auch lösen, indem man den Wert nicht aufaddiert,
sondern multipliziert. Dann müsste man aber einen anderen Faktor als 0, 45
verwenden. In meinen eigenen Versuchen habe ich mit dem Aufaddieren die
besten Ergebnisse erzielt.
9

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
Wenn das Programm mehrere Punkte übersprungen hat, so wird der dazwischen
liegende Bereich durch eine Gerade angegleicht. Dazu müssen die Koordinaten
der dazwischen liegenden Punkte entsprechend geändert werden. Wenn
gerade der Punkt mit dem Index i betrachtet wird und der Punkt j > i als Nachfolger
ermittelt wurde, so wird zunächst die Geschwindigkeit ermittelt, mit der
sich Dominic von i nach j bewegt. Dazu wird Definition 3 angewendet. Dann
wird ermittelt, welche Strecke Dominic in der Zeit db time[i + 1] − db time[i]
zurückgelegt haben muss. Die Koordinaten von i+1 werden dann entsprechend
gesetzt, die anderen Punkte bleiben unverändert. Im nächsten Schritt wird ein
Nachfolger für i + 1 gesucht. Die Wahrscheinlichkeitsfunktion bewertet jetzt
j wieder als wahrscheinlichsten Nachfolger, da j schon vorher der wahrscheinlichste
Nachfolger war. Die Wahrscheinlichkeit steigt u. U. sogar etwas, weil sich
Dominic schon gezielt auf den Punkt j zubewegt hat. Der Vorgang setzt sich so
lange fort, bis der der Punkt mit dem Index j erreicht wurde.
2.3 Kürzen fehlerhafter Pfade
Es gibt gewisse Fehler, die der vorgestellte Algorithmus möglicherweise nicht
korrekt löst. Unter Kapitel Programm-Ablaufprotokoll zeigt die Abbildung log2.csv
mit Änderungen und ohne Kürzen einen solchen Fall. Es fehlen einige GPS-
Einträge, weshalb rote Strecken eingezeichnet wurden. Dass Dominic sich zur
Straße Neupforte bewegt, halte ich für einen offensichtlichen Fehler. Trotzdem
konnte das Programm den Fehler zunächst nicht beheben. Das liegt einerseits
daran, dass kein passender Punkt als Nachfolger gefunden werden konnte, als
die erste rote Strecke gezeichnet wurde. Offensichtlich ist Dominic ein paar Mal
im Kreis gelaufen oder hat sich nicht direkt auf einen passenden Punkt mit
der richtigen Geschwindigkeit zubewegt. Viel wichtiger ist aber, dass etwa 10
Punkte hätten übersprungen werden müssen. Diesen Fall hat die Wahrscheinlichkeitsfunktion
als äußerst unwahrscheinlich eingestuft und deshalb abgelehnt.
Eine Änderung der Gewichtung in der Wahrscheinlichkeitsfunktion brachte bei
meinen Experimenten keine wirkliche Verbesserung, da dann auch noch viele
richtige Punkte korrigiert wurden.
Solche Fehler können behoben werden, indem das Programm die Anzahl der
zwischen zwei roten Strecken vorkommenden Punkte zählt. Handelt es sich um
weniger als 15 Punkte, so wird der Zwischenraum übersprungen. Rote Strecken
kommen genau dann zu Stande, wenn mehr als 30 Sekunden zwischen zwei
GPS-Einträgen fehlen.
2.4 Bearbeitung der Bilddatei
Bevor der neue Weg schließlich auf die Karte gezeichnet wird, untersucht das
Programm die Koordinaten auf mögliche Unstimmigkeiten und Fehler. Dadurch
ist es möglich, die Qualität der Rekonstruktion abzuschätzen. Bevor eine Strecke
gezeichnet wird, wird untersucht, wie schnell sich Dominic dort im Vergleich
zur Durchschnittsgeschwindigkeit in der Log-Datei bewegt. Wenn die Geschwindigkeit
stark überschritten wird, wird der Bereich gelb eingezeichnet, wenn die
Geschwindigkeit hingegen stark unterschritten wurde, wird der Bereich hellblau
eingezeichnet. Wenn zwischen zwei Punkten mehr als 30 Sekunden in der Log-
Datei fehlen, so wird der Bereich rot eingezeichnet. In einem solchen Fall kann
10

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
der Weg nicht richtig rekonstruiert wurde, weil keine Informationen darüber vorliegen,
wie sich Dominic bewegt haben könnte. Rote Segmente, sowie kleinere
Stücke, die von roten Segmenten eingeschlossen werden, sind also mit Vorsicht
zu genießen.
Das Speichern der Bilddatei erfolgt wie in Aufgabe 5 und Änderungen an
der Log-Datei werden nicht gespeichert. Stattdessen werden Änderungen in der
Kommandozeile ausgegeben.
2.5 Fakten zum Programm
Das Programm hat, so wie es aufgebaut ist, einige Vorteile, aber auch Macken.
So arbeitet es beispielsweise relativ schnell, wurde aber nur auf den BWINF-
Ausgangsdaten ausgiebig getestet. Es ist jedoch nicht so einfach möglich, den
Algorithmus zu erweitern, sodass er mehr Fälle abdecken kann. Dennoch behebt
er die Fehler auf den BWINF-Testfällen meiner Meinung nach relativ gut und
Dominic erhält einen guten Überblick darüber, wo er überall war. Es werden
nun einige Fakten und Ideen zum Programm und Algorithmus aufgelistet.
1. Es handelt sich um einen Greedy-Algorithmus, der immer die aktuell beste
Möglichkeit sucht und auswählt. Deshalb wählt das Programm immer den
nächsten Nachfolger so, wie er aktuell als am wahrscheinlichsten erachtet
wird. Der weitere Verlauf des Pfades wird nicht beachtet, es wird immer
nur der beste Nachfolger für den aktuellen Punkt betrachtet. Das führt
sicher nicht immer zum besten Ergebnis.
2. Wie in der BWINF-Newsgroup bereits diskutiert, spielt die Landkarte
keine Rolle, sie wird lediglich unter den Weg gelegt.
3. Es wäre möglich, nicht nur die Geschwindigkeit, sondern auch die Beschleunigung
Dominics zu betrachten, das wurde aber nicht implementiert.
4. Änderungen am Pfad werden immer durch Geraden durchgeführt.
3 Programm-Ablaufprotokoll
Es folgen nun die Ausgaben des Programms in die Ausgabedatei karte out.ppm,
wobei immer der Weg zuerst ohne und dann mit Änderungen angezeigt wird.
Grüne Linien stellen Strecken dar, auf denen sich Dominic mit seiner Durchschnittsgeschwindigkeit
aus der aktuellen Log-Datei bewegt. Wenn Linien gelb
dargestellt werden, so bewegt sich Dominic schneller und wenn Linien hellblau
dargestellt werden, so bewegt sich Dominic langsamer. Der Übergang ist dabei
fließend. Rote Strecken sind mit Vorsicht zu genießen, da dort mindestens 30
Sekunden Log-Daten fehlen. Es kann somit nicht festgestellt werden, wie sich
Dominic dort fortbewegt hat.
Eine Ausgabe des Programms ist dann gut, wenn sie möglichst wenige gelbe
Strecken und möglichst wenige Abweichungen von den Original-Daten aufweist.
Betrachtet man die Karte von log1.csv, so fallen u. a. Änderungen im
nördlichen Teil der Karte auf. Dort bewegt sich Dominic nun anders. Besonders
auffällig ist, dass in den Original-Daten eine große gelbe Strecke, gefolgt
von sehr vielen, kleinen, hellblauen Stecken, auftritt. Der Algorithmus hat die
11

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
Abbildung 3: log1.csv ohne Änderungen
12

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
Abbildung 4: log1.csv mit Änderungen
13

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
Abbildung 5: log2.csv ohne Änderungen
Abbildung 6: log2.csv mit Änderungen, ohne Kürzen
14

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
Abbildung 7: log2.csv mit Änderungen
15

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
Abbildung 8: log3.csv ohne Änderungen
Abbildung 9: log3.csv mit Änderungen
16

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
Log-Daten entsprechend verändert und nun sind an dieser Stelle keine gelben
Strecken mehr zu sehen. Der ursprüngliche Pfadverlauf wurde weitestgehend
beibehalten. Viel interessanter sind die Ausgaben für log2.csv. Dort fallen zwei
große Fehler, nämlich die Ausschweifer nach Norden und nach Westen auf. Diese
Wege hat Dominic laut den Logs mit überhöhter Geschwindigkeit begangen.
Zudem fehlen dort auch noch Log-Einträge. Der Weg konnte größtenteils korrigiert
werden, jedoch sind noch einige kurze, rote Strecken zu sehen, an denen
der genaue Weg nicht bekannt ist, weil Log-Daten fehlen. Kleinere Änderungen
wurden im Bereich Domschatzkammer durchgeführt, wo sich Dominic mit
überhöhter Geschwindigkeit fortbewegt hat. Die Karte von log3.csv zeigt nicht
viel Neues. Einige Ausläufer von Dominics Weg an der Jakobstraße sind nun
nicht mehr so deutlich, weil Dominic diese bei genauer Betrachtung wieder mit
hoher Geschwindigkeit durchquert hat.
Abschließend lässt sich sagen, dass das Programm hauptsächlich die sofort
offensichtlichen Fehler gut behebt. Kleine Geschwindigkeitsüberschreitungen haben
keine allzu großen Auswirkungen.
4 Programm-Quelltext
1 #include
2 #include
3 #include
4 #include
5 #include
6 #include
7 #include
8
10
9 using namespace std;
11 // Vordeklarationen fuer eigene Funktionen
12 void readLine(FILE * file_handle);
13 void paintDot(int x, int y);
14 void paintLine(int x1, int x2, int y1, int y2, int r, int g, int b);
15 void setPixel(int x, int y, int r, int g, int b);
16 int convertCoordinateToPixelEast(double value);
17 int convertCoordinateToPixelNorth(double value);
18 void insertDatabaseEntry(int index);
19 void db_calculateAverageDistance();
20 double db_calculateDistance(int index1, int index2);
21 double db_p_getProbability(double velocity);
22
23 // Aktuell eingelesene Zeile. Keine Zeile darf mehr als 9999 Zeichen haben!
24 char currentLine[10000];
25
26 // Matrix: Enthaelt das gesamte Bild (Karte)
27 unsigned char*** matrix;
28
29 // Proportionen (Groesse in Pixel) der Bilddatei
30 int proportions[2];
31
32 // Log-Datenbank, maximal 2000 Datensaetze
33 // TO-DO: Verkettete Liste anstatt Array, um Entries effizient einfuegen zu
koennen!
34 int db_time[2000];
35 int db_pos_x[2000]; // Pixelangaben
36 int db_pos_y[2000]; // Pixelangaben
37 int db_count_entries = 0;
38 double db_average_distance_per_time = 0.0; // Durchschnittliche
Geschwindigkeit
39 double db_average_velocity_difference = 0.0; // Durchschnittliche
Abweichung der Geschwindigkeiten voneinander (absolut)
40
41 // Wahrscheinlichkeitsfunktion fuer Geschwindigkeit
17

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
42 double db_p_segment[2000];
43
44 // Konstanten fuer Koordinatenecken
45 const double coord_left = 6.0711;
46 const double coord_right = 6.0918;
47 const double coord_top = 50.7820;
48 const double coord_bottom = 50.7716;
49
50 /// *************************************************
51 /// * Hier startet das Programm. *
52 /// *************************************************
53 int main(int argc, char** argv)
54 {
55 // freopen( "file.txt", "w", stdout );
56
57 FILE * pFileMap = fopen("karte.ppm", "r");
58 FILE * pFileLog = fopen("log.csv", "r");
59
60 // Maximale Laenge einer Zeile im Header: 5000 Zeichen (5 KB)
61 char fbuffer_header[5000];
62 memset(fbuffer_header , 5000, 0);
63 fread(fbuffer_header , 2, 1, pFileMap);
64
65 // Dateiformat ueberpruefen
66 if (strcmp(fbuffer_header , "P6") != 0)
67 {
68 printf("Die Eingabedatei karte.ppm weist ein unerwartetes Format auf
und kann nicht verarbeitet werden (nur PPM-P6).\n");
69 return 0;
70 }
71
72 // Zeilenumbruch einlesen
73 fread(fbuffer_header , 1, 1, pFileMap);
74
75 // Proportionen einlesen
76 readLine(pFileMap);
77 sscanf(currentLine, "%d %d", &proportions[0], &proportions[1]);
78 printf("Proportionen der Datei karte.ppm: %d x %d Pixel.\n", proportions
[0], proportions[1]);
79
80 // Farbtiefe auslesen
81 readLine(pFileMap);
82
83 if (strcmp(currentLine, "255") != 0)
84 {
85 printf("Die Eingabedatei karte.ppm weist ein unerwartetes Format auf
und kann nicht verarbeitet werden (nur 24-bit-Farbtiefe).\n");
86 return 0;
87 }
88
89 printf("Reserviere Speicherplatz. Dieser Vorgang kann einige Sekunden
dauern...\n");
90
91 // Matrix: Enthaelt die ganze Bilddatei
92 // Speicher dynamisch allokieren
93 matrix = new unsigned char**[proportions[0]];
94
95 for (int i = 0; i < proportions[0]; i++)
96 {
97 matrix[i] = new unsigned char*[proportions[1]];
98
99 for (int j = 0; j < proportions[1]; j++)
100 {
101 matrix[i][j] = new unsigned char[3];
102 }
103 }
104
105 // Matrix fuellen
106 printf("Lese alle Pixel in den Arbeitsspeicher. Dieser Vorgang kann
einige Sekunden dauern...\n");
107
108 for (int i = 0; i < proportions[1]; i++)
109 {
110 // Iteriere ueber alle "Zeilen"
18

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
111
112 for (int j = 0; j < proportions[0]; j++)
113 {
114 // Iteriere ueber alle Zeichen in der aktuellen "Zeile"
115 fscanf(pFileMap,"%c%c%c", &matrix[j][i][0], &matrix[j][i][1], &
matrix[j][i][2]);
116 }
117 }
118
119 printf("Lese LOG-Datei in den Arbeitsspeicher...\n");
120 fread(fbuffer_header , 23, 1, pFileLog);
121
122 if (strcmp(fbuffer_header , "TIME,LATITUDE,LONGITUDE") != 0)
123 {
124 printf("Die Log-Datei weist ein unbekanntes Format auf und kann nicht
verarbeitet werden (ungueltiger Header).\n");
125 return 0;
126 }
127
128 // Zeilenumbruch einlesen
129 fread(fbuffer_header , 1, 1, pFileLog);
130
131 while (true)
132 {
133 readLine(pFileLog);
134
135 if (strlen(currentLine) < 5)
136 {
137 // Log-Datei wurde komplett eingelesen, weiterer Programmablauf
in dieser If-Struktur
138
139 printf("Sollen die Log-Daten ohne weitere Anpassungen auf die
Karte gezeichnet werden? (j/n)\n");
140 char tmp_input;
141 scanf("%c", &tmp_input);
142
143 // Berechne durchschnittliche Geschwindigkeit
144 db_calculateAverageDistance();
145 printf("Die durchschnittliche Geschwindigkeit betraegt %f Pixel/
Sekunde.\n", db_average_distance_per_time);
146
147 if (tmp_input == ’n’)
148 {
149 // Verarbeite Log-Daten
150 printf("Verarbeite Daten, Berechnung laeuft. Dieser Vorgang
kann einige Sekunden dauern.\n");
151
152 // Baue Wahrscheinlichkeitsfunktion fuer Geschwindigkeit auf
153 for (int i = 0; i < db_count_entries - 1; i++)
154 {
155 // Iteriere ueber alle Eintraege in der Log-Datenbank
156 // Geschwindigkeit = Strecke / Zeit
157 db_p_segment[i] = db_calculateDistance(i, i + 1) / (
db_time[i + 1] - db_time[i]);
158 }
159
160 int db_last_missing = -1; // Wann haben zum lezten Mal
zu viele Eintraege gefehlt?
161
162 // Wende Wahrscheinlichkeitsfunktion auf jeden Eintrag in der
Log-Datenbank an
163 for (int i = 0; i < db_count_entries - 1; i++)
164 {
165 // Iteriere ueber alle Eintraege in der Log-Datenbank.
Der erste und letzte Eintrag sind per Definition
richtig!
166
167 if (db_time[i + 1] - db_time[i] > 30)
168 {
169 printf("[W] Es fehlen zu viele Eintraege in %d bis %d
!\n", i, i + 1);
170
171 if (db_last_missing == -1)
172 {
19

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
173 // nichts machen
174 }
175 else
176 {
177 if (i - db_last_missing < 15)
178 {
179 printf("[W] Es fehlen in einem kleinem
Intervall zu viele Eintraege!\n");
180
181 // Innerhalb eines kleines Intervalls fehlen
zu viele Daten!
182 for (int j = db_last_missing; j < i + 1; j++)
183 {
184 // Alle Koordinaten zuruecksetzen
185 db_pos_x[j] = db_pos_x[i + 1];
186 db_pos_y[j] = db_pos_y[i + 1];
187 }
188 }
189 }
190
191 db_last_missing = i + 1;
192 }
193
194 int currentBestIndex = -1; // Eintrag mit hoechster
Wahrscheinlichkeit
195 double currentBestProbability = 1000000.0; // Wert der
hoechsten Wahrscheinlichkeit
196
197 for (int j = i + 1; j < db_count_entries - 1; j++)
198 {
199 // Berechne Wahrscheinlichkeit fuer den Weg von i
nach j
200 double newProb = db_p_getProbability(
db_calculateDistance(i, j) / (db_time[j] -
db_time[i])) + ((j - i) * 0.45);
201 if (newProb < currentBestProbability)
202 {
203 //printf(" [Min] Neues Minimum bei %d mit %f
fuer [%d].\n", j, newProb, i + 1);
204
205 // Maximum der Wahrscheinlichkeitsfunktion
speichern
206 currentBestProbability = newProb;
207 currentBestIndex = j;
208 }
209 }
210
211 if (currentBestIndex != -1)
212 {
213 // Es wurde eine Loesung gefunden
214
215 if (currentBestIndex > i + 1)
216 {
217 double currentBestSpeedX = (db_pos_x[
currentBestIndex] - db_pos_x[i]) / (db_time[
currentBestIndex] - db_time[i]);
218 double currentBestSpeedY = (db_pos_y[
currentBestIndex] - db_pos_y[i]) / (db_time[
currentBestIndex] - db_time[i]);
219
220 // Aendere Koordinaten des Punktes
221 db_pos_x[i + 1] = db_pos_x[i] + currentBestSpeedX
* (db_time[i + 1] - db_time[i]);
222 db_pos_y[i + 1] = db_pos_y[i] + currentBestSpeedY
* (db_time[i + 1] - db_time[i]);
223
224 printf("[W] Aendere Koordinaten des Punktes %d
auf (%d | %d).\n", i + 1, db_pos_x[i + 1],
db_pos_y[i + 1]);
225 printf(" Geschwindigkeit: %f Pixel / Sekunde.\
n", sqrt(currentBestSpeedX *
currentBestSpeedX + currentBestSpeedY *
currentBestSpeedY));
226
20

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
227 }
228 else if (currentBestIndex == i + 1)
229 {
230 //printf("[I] Koordinaten von %d nicht geaendert
.\n", i + 1);
231 }
232
233 //printf(" p = %f\n", currentBestProbability);
234 }
235 else
236 {
237 printf("[W] Kein Eintrag in der
Wahrscheinlichkeitstabelle fuer %d gefunden.\n",
db_time[i + 1]);
238
239 // Keine Loesung gefunden
240 // TO-DO: Kann dieser Fall ueberhaupt eintreten?
241 }
242 }
243 }
244
245 // Zeichne Weg
246 printf("Zeichne den Weg auf die Karte. Dieser Vorgang kann einige
Sekunden dauern.\n");
247
248 // Gehe alle Eintraege in der Log-Datenbank durch
249 for (int i = 0; i < db_count_entries - 1; i++)
250 {
251 if (db_time[i + 1] - db_time[i] > 30)
252 {
253 paintLine(db_pos_x[i], db_pos_x[i + 1], db_pos_y[i],
db_pos_y[i + 1], 255, 0, 0);
254 }
255 else
256 {
257 int color_blue = 0;
258 double currentVelocity = ((double)db_calculateDistance(i,
i + 1)) / ((double)(db_time[i + 1] - db_time[i]));
259
260 color_blue = (int)((currentVelocity -
db_average_distance_per_time) /
db_average_distance_per_time * 255.0);
261
262 if (color_blue > 254) color_blue = 254;
263 if (color_blue < -254) color_blue = -254;
264
265 if (color_blue < 0)
266 {
267 paintLine(db_pos_x[i], db_pos_x[i + 1], db_pos_y[i],
db_pos_y[i + 1], 0, 255, color_blue * (-1));
268 }
269 else
270 {
271 paintLine(db_pos_x[i], db_pos_x[i + 1], db_pos_y[i],
db_pos_y[i + 1], color_blue, 255, 0);
272 }
273 }
274 }
275
276 // Speichere Datei im PPM-Format ab
277 FILE * pFileOut = fopen("karte_out.ppm", "w");
278 fprintf(pFileOut, "P6\n#CREATOR: 28_1_bwinf_3\n%d %d\n255\n",
proportions[0], proportions[1]);
279
280 for (int i = 0; i < proportions[1]; i++)
281 {
282 for (int j = 0; j < proportions[0]; j++)
283 {
284 fprintf(pFileOut, "%c%c%c", matrix[j][i][0], matrix[j][i
][1], matrix[j][i][2]);
285 }
286 }
287
288 fclose(pFileOut);
21

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
289 fclose(pFileMap);
290 fclose(pFileLog);
291
292 printf("Ausgabedatei karte_out.ppm wurde erstellt. Fertig.\n");
293 return 0;
294 }
295 else
296 {
297 // Eingelesene Zeile in das Array umkopieren
298 // Zeile auswerten
299
300 int beginCurrentRecord = 0; // An welcher Stelle beginnt der
aktuelle "Datensatz" in der aktuellen Zeile?
301 int recordCounter = 0; // Der Index des aktuellen
Datensatzes (der wieviele Datensatz in dieser Zeile?)
302
303 // String anpassen (Terminatoren einfuegen, um einzelne Werte
auszulesen)
304 currentLine[2] = 0;
305 currentLine[5] = 0;
306 currentLine[8] = 0;
307 currentLine[18] = 0;
308 currentLine[27] = 0;
309
310 // Drei Datensaetze einlesen
311 int currentTime = atoi(currentLine) * 3600 + atoi(currentLine +
3) * 60 + atoi(currentLine + 6);
312 double currentLat = atof(currentLine + 9);
313 double currentLong = atof(currentLine + 19);
314 db_pos_y[db_count_entries] = convertCoordinateToPixelNorth(
currentLat);
315 db_pos_x[db_count_entries] = convertCoordinateToPixelEast(
currentLong);
316 db_time[db_count_entries] = currentTime;
317
318 printf("Datensatz eingelesen: time=%d, latitude=%f, longitude=%f
.\n", currentTime, currentLat, currentLong);
319 db_count_entries++;
320 }
321 }
322 }
323
324 /// *************************************************
325 /// * Liest die naechste Zeile ohne Kommentare ein. *
326 /// *************************************************
327 void readLine(FILE * file_handle)
328 {
329 memset(currentLine, 10000, 0);
330
331 if (feof(file_handle))
332 {
333 currentLine[0] = 0;
334 return;
335 }
336
337 // Erstes Zeichen einlesen
338 fread(currentLine, 1, 1, file_handle);
339
340 if (feof(file_handle))
341 {
342 currentLine[0] = 0;
343 return;
344 }
345
346 if (strcmp(currentLine, "#") == 0)
347 {
348 // Bei dieser Zeile handelt es sich um einen Kommentar
349 char tmp = 0;
350
351 while (currentLine[0] != 10)
352 {
353 // Zeichen fuer Zeichen bis zum Zeilensprung einlesen
354 fread(currentLine, 1, 1, file_handle);
355 }
22

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
356
357 // Naechste Zeile lesen, da es die aktuelle Zeile ein Kommentar ist
358 readLine(file_handle);
359 }
360 else
361 {
362 int counter = 0;
363 // Erstes Zeichen der Zeile einlesen
364 // fread(currentLine + 1, 1, 1, file_handle);
365
366 while (currentLine[counter] != 10)
367 {
368 // Zeichen fuer Zeichen bis zum Zeilensprung einlesen
369 counter++;
370 fread(currentLine + counter, 1, 1, file_handle);
371 }
372
373 currentLine[counter] = 0;
374 }
375 }
376
377 /// *************************************************
378 /// * Zeichnet einen dicken Punkt auf die Map. *
379 /// *************************************************
380 void paintDot(int x, int y)
381 {
382 // Ueberpruefe, ob der Punkt ueberhalb auf die Karte gezeichnet werden
kann
383
384 if ((x > -1) && (x < proportions[0]) && (y > -1) && (y < proportions[1]))
385 {
386 setPixel(x, y, 0, 0, 0);
387
388 // Zeichne einen dicken Punkt
389 setPixel(x - 1, y, 0, 0, 0);
390 setPixel(x + 1, y, 0, 0, 0);
391 setPixel(x, y - 1, 0, 0, 0);
392 setPixel(x, y + 1, 0, 0, 0);
393 }
394 else
395 {
396 printf("[W] Punkt kann nicht gezeichnet werden, da ausserhalb der
Landkarte! Pixel(%d | %d).\n", x, y);
397 }
398 }
399
400 /// *************************************************
401 /// * Zeichnet eine Linie auf die Map. *
402 /// *************************************************
403 void paintLine(int x1, int x2, int y1, int y2, int r, int g, int b)
404 {
405 // Startpunkte der Linien zeichen
406 paintDot(x1, y1);
407 paintDot(x2, y2);
408
409 // Ueberprufe, ob die Stecke ueberhaupt gezeichnet werden kann
410 if ((x1 > -1) && (x2 > -1) && (y1 > -1) && (y2 > -1) && (x1 < proportions
[0]) && (x2 < proportions[0]) && (y1 < proportions[1]) && (y2 <
proportions[1]))
411 {
412 // Alles in Ordnung!
413 }
414 else
415 {
416 printf("[W] Linie kann nicht gezeichnet werden, da ausserhalb der
Landkarte! Zeichne nur den sichtbaren Bereich ein!\n");
417 }
418
419 // Zeichen Linie
420 double vector_direction[2]; // Der Richtungsvektor der Gerade
421 vector_direction[0] = x2 - x1;
422 vector_direction[1] = y2 - y1;
423 // Richtungsvektor zum Einheitsvektor (Laenge 1) machen
424 double vector_length = sqrt(vector_direction[0] * vector_direction[0] +
23

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
vector_direction[1] * vector_direction[1]);
425 vector_direction[0] /= vector_length;
426 vector_direction[1] /= vector_length;
427
428 // Zeichne die Strecke
429 for (int i = 0; i < (int)ceil(vector_length) + 1; i++)
430 {
431 setPixel(x1 + (int)(vector_direction[0] * (double)i), y1 + (int)(
vector_direction[1]* (double)i), r, g, b);
432 }
433 }
434
435 /// *************************************************
436 /// * Setzt einen Pixel auf eine Farbe. *
437 /// *************************************************
438 void setPixel(int x, int y, int r, int g, int b)
439 {
440 // Ueberpruefe, ob der Pixel gueltig ist, d.h. in der Matrix liegt
441
442 if ((x > -1) && (x < proportions[0]) && (y > -1) && (y < proportions[1]))
443 {
444 matrix[x][y][0] = r;
445 matrix[x][y][1] = g;
446 matrix[x][y][2] = b;
447 }
448 }
449
450 /// *************************************************
451 /// * Gibt zu einer x-Koordinate den Pixelwert aus. *
452 /// *************************************************
453 int convertCoordinateToPixelEast(double value)
454 {
455 double coord_difference = value - coord_left;
456 double pixel_per_coordinate_quotient = (double)proportions[0] / (
coord_right - coord_left);
457
458 return (int)(coord_difference * pixel_per_coordinate_quotient);
459 }
460
461 /// *************************************************
462 /// * Gibt zu einer y-Koordinate den Pixelwert aus. *
463 /// *************************************************
464 int convertCoordinateToPixelNorth(double value)
465 {
466 double coord_difference = value - coord_bottom;
467 double pixel_per_coordinate_quotient = (double)proportions[1] / (
coord_top - coord_bottom);
468
469 return proportions[1] - (int)(coord_difference *
pixel_per_coordinate_quotient);
470 }
471
472 /// *************************************************
473 /// * Macht einen Eintrag in der Datenbank frei. *
474 /// *************************************************
475 // edit: nicht benoetigt!
476 void insertDatabaseEntry(int index)
477 {
478 for (int i = db_count_entries; i > index; i--)
479 {
480 db_time[i] = db_time[i - 1];
481 db_pos_x[i] = db_pos_x[i - 1];
482 db_pos_y[i] = db_pos_y[i - 1];
483 }
484
485 db_count_entries++;
486 }
487
488 /// *************************************************
489 /// * Berechnet die durschnittliche Geschwindigkeit.*
490 /// *************************************************
491 void db_calculateAverageDistance()
492 {
493 db_average_distance_per_time = 0.0;
24

Aufgabe 3
Stefan Hansch, Markus Wirsing, Matthias Springer
494
495 double timeElapsed = 0.0; // Vergangene Zeit
496
497 for (int i = 1; i < db_count_entries; i++)
498 {
499 timeElapsed += db_time[i] - db_time[i - 1];
500 db_average_distance_per_time += db_calculateDistance(i - 1, i);
501 }
502
503 db_average_distance_per_time /= timeElapsed;
504
505 // Berechne durchschnittlichen Unterschied zwischen Geschwindigkeiten (
siehe Doku)
506 db_average_velocity_difference = 0.0;
507 double sortedVelocities[2000];
508
509 for (int i = 0; i < db_count_entries - 1; i++)
510 {
511 sortedVelocities[i] = db_calculateDistance(i, i + 1) / (db_time[i +
1] - db_time[i]);
512 }
513
514 // Geschwindigkeiten sortieren, edit: wird fuer den neuen Algorithmus
nicht mehr benoetigt!
515 vector v_sortedVelocites(sortedVelocities , sortedVelocities +
db_count_entries - 1);
516 sort(v_sortedVelocites.begin(), v_sortedVelocites.end());
517
518 for (int i = 0; i < db_count_entries - 2; i++)
519 {
520 // Iteriere ueber alle Intervalle in der sortieren
Geschwindigkeitsauflistung
521
522 db_average_velocity_difference += v_sortedVelocites[i + 1] -
v_sortedVelocites[i];
523 }
524
525 db_average_velocity_difference /= db_count_entries - 2;
526 }
527
528 /// *************************************************
529 /// * Berechnet den Abstand zwischen 2 Punkten. *
530 /// *************************************************
531 double db_calculateDistance(int index1, int index2)
532 {
533 return sqrt((db_pos_y[index2] - db_pos_y[index1]) * (db_pos_y[index2] -
db_pos_y[index1]) + (db_pos_x[index2] - db_pos_x[index1]) * (
db_pos_x[index2] - db_pos_x[index1]));
534 }
535
536 double db_p_getProbability(double velocity)
537 {
538 // Iteriere ueber alle Geschwindigkeitsintervalle
539 double return_value = 0.0;
540
541 for (int i = 0; i < db_count_entries - 1; i++)
542 {
543 return_value += velocity - db_p_segment[i];
544 }
545
546 if (return_value < 0.0)
547 {
548 return 0.0;
549 }
550
551 // Normen auf einen Punkt, nur wichtig, damit der Faktor 0.45 im
Algorithmus passt; hatte urspruenglich andere Plaene, eigentlich ist
das also nicht unbedingt notwendig
552 return return_value / (db_average_distance_per_time * (db_count_entries -
1));
553 }
25