Altes Thema neuer Ansatz. Wenn über die Qualität eines Empfängers schwadroniert wird, dann werden gerne Tracks gezeigt, verglichen und jeder bemüht sich im Kaffeesatzlesen, um möglichst das Ergebnis zu lesen, das ihm passt. Aber abseits dieser Diskussion möchte man vielleicht doch mal gerne wissen, ob die zahlreichen Updates objektiv etwas an der Qualität verbessert haben. Oder man vergleicht zahlreiche Geräte, wie das der Tobias macht, und möchte gerne irgendwie etwas darüber schreiben, das nicht gleich zerrissen wird.
Deswegen die Idee ein Tool zu schreiben, das den Abstand eines Tracks zu einem Referenztrack vergleicht und in statistische Größen umrechnet. Klingt einfach, hat aber auch seine Tücken. Gleich vorne weg ein paar:
1) Die GPS Position hat einen zufälligen und einen systematischen Fehler. Letzterer ist vom Zeitpunkt der Messung abhängig. Es reicht folglich nicht nur einmal einen Track aufzuzeichnen, um dann zu triumphieren. So ein paar Tracks an unterschiedlichen Tagen zeigen der Erfahrung nach aber eine deutliche Tendenz.
2) Die Randbedingungen spielen eine Rolle. Will man Geräte vergleichen, sollten alle die gleiche Chance zum guten Empfang haben. Natürlich kann man aber auch mit so einem Trackvergleich testen, ob unterschiedliche Transportmöglichkeiten den Empfang beeinträchtigen. Außerdem sollte das Aufzeichnungsintervall bei jeder Messung gleich sein. Ein automatisches Intervall ist hier wenig hilfreich, es sei denn man will gerade das testen.
3) Die Referenz sollte gut sein. Nur wie bekommt man eine gute Referenz? Der normale Benutzer hat wohl nur die Chance einen künstlichen Track auf einer Karte oder auf Orthophotos zu zeichnen. Aber das ist doch nicht genau! Hat das Ergebnis dann noch einen Sinn? Als absolute Angabe wie gut ein Empfänger ist? Nein, garantiert nicht. Um relative Unterschiede zwischen Geräten, bzw Firmwareversionen oder sonstigen Modifikationen herauszufinden sollte es jedoch reichen. Immerhin trifft der Fehler in der Referenz alle Messungen gleich.
Man sollte deshalb bei dem ganzen Spiel im Hinterkopf behalten: Die absoluten Zahlen sagen wenig aus. Relativ zueinander kann man jedoch schon gravierende Unterschiede sehen, oder eben auch nicht. Und wenn nicht, dann muss man nicht anfangen den einen Track schön zu reden und beim anderen Erbsen zu zählen.
Was macht das Tool? Es berechnet zu jedem Punkt im Track den kürzesten Abstand zu einem Segment im Referenztrack. Das geht mehr oder weniger so, wie hier beschrieben:
http://programmizm.sourceforge…rom-a-point-to-a-polyline
Bei der Wahl der Referenzrunde sollte man enge Schleifen vermeiden, weil sonst unter Umständen die Distanz zu einem zeitlich früher liegenden Segment kürzer ist als zum richtigen Segment.
Aus den resultierenden Deltas werden folgende statistische Größen berechnet:
1) Der Mittelwert. Naja, der sagt eigentlich nicht viel aus.
2) Die Varianz. Schon besser. Das ist der Wert, der angibt wie stark das Zappeln um die eigentliche Position ist. Und ob dieses Zappeln oft weit ausholt oder nicht.
3) 3Sigma. Sollten die Werte normalverteilt sein dann lägen 99.7% der Werte in dem Bereich. Hm... ob man das so sagen kann?
4) Der vierte Wert ist eigentlich keine wirkliche statistische Größe. Hier wird gezählt wie viele der Deltas in % kleiner als 10m sind.
Soweit mal der Anfang. Das ist sicherlich nicht der Weisheit letzter Schluss und bestimmt sind auch noch Fehler drinnen. Deswegen will ich das hier zur Diskussion stellen. Wer selber ein wenig herumspielen möchte kann gerne den Code über SVN ziehen:
https://svn.code.sf.net/p/qlan…/code/Research/TrackComp/
Mit CMake kann man sich für seine IDE und sein Betriebssystem die nötigen Projektdateien erstellen. Eine Entwicklungsversion von Qt muss man auch installiert haben.
Für den Rest habe ich ein Windows Binary gebastelt. Ich hoffe es läuft.
https://sourceforge.net/projec…dkartegt/files/TrackComp/
In dem Ordner sind auch ein Referenztrack und 3 Aufzeichnungen dabei. Das Ergebnis ist im angehängten Screenshot zu sehen.
Viel Spass beim Spielen!
)
