Ausreißer bei Tracks (Schreibfehler)

[augustus3]

Hallo zusammen,

zunächst herzlichen Dank für das tolle Programm, das ich seit langem nutze. Das einzige, das mir so manche Konvertierung ermöglicht (trk zu ovl oder kml). Super Einbindung der Karten.

Mein Problem (habe lange gesucht, weil ich sicher nicht der erste damit bin, aber erfolglos...):

Nutze seit 2007 unverändert GoPal3 zum Routen und zum Tracken. Das Medion 470T schreibt pro Sekunde eine Position - auf die SD-Card. Natürlich gibt es im Verlauf von Tagestouren bei 30.000 Zeilen so manche Schreibfehler - dabei wird bisweilen einfach das Komma verrückt, sodass vermeintliche Positionen von 58° statt 5.8° Länge geschrieben werden.
Dies verhunzt natürlich den Track und die Anzeigemöglichkeit.

Bisher filtere ich mühsam diese durchschnittlich 1 Fehler pro Trackstunde heraus, wobei auch der Umweg über Excel/Sortieren etc. "maschinenunwürdig" ist.

Frage: gibt es eine smarte Möglichkeit, diese Ausreisser zu entdecken und zu löschen? Es liegt nahe, einen Fehler zu bejahen, wenn der Folgewert in Breite oder Länge zB um über 1° abweicht .... ??

Angehängt ein Beispieltrack einer längeren Querfahrt mit Fehlern (Profis sehen gleich die Wanderdüne :-)


  track20080909_0938.zip (Size: 479.18 KB / Downloads: 776)

Grüße
Andy

[IlmariKrebs]

Wenn du dir die Geschwindigkeiten berechnen lässt das ganze exportiert und in Excel alle Zeilen löscht die alle über einem Schwellwert liegen. Das sollte vermutlich klappen. Oder du Schaudt dir di Differenzen der Längen oder breiten Werte an. Die sollten weniger als 1 Prozent sein. Damit solltest du in Excel auch einen Automatismus generieren und die Daten bequem aufräumen können.

Hth

[augustus3]

Wenn du dir die Geschwindigkeiten berechnen lässt das ganze exportiert und in Excel alle Zeilen löscht die alle über einem Schwellwert liegen. Das sollte vermutlich klappen. Oder du Schaudt dir di Differenzen der Längen oder breiten Werte an. Die sollten weniger als 1 Prozent sein. Damit solltest du in Excel auch einen Automatismus generieren und die Daten bequem aufräumen können.

Hth

Jepp, habe zwischenzeitlich gelernt, dass dies nicht sooo einfach ist - und für mich, (noch) ohne Java- oder C++-Erfahrungen wohl am schnellsten über Excel geht.
Auch das recht nützliche Proggi gps-track-analyse kann Extremwerte bzw. Fehlerstellen erkennen, es induziert aber "Folgefehler":
Bei Tunneldurchfahrten (mit Koordinaten 0.0000) und Löschen dieser "Entbehrlichzeilen" gibt es am Tunnelausgang natürlich einen Koordinaten- und Zeitsprung, der zu v-Rechenfehlern führt (obwohl dies theoretisch nicht sein müsste, hier dürften Unschärfen bei Signalwiederkehr die Ursache sein).

Schätze, dass es sich aufgrund der Vielzahl meiner fehlerhaften Tracks doch lohnen könnte, ein Proggi oder Script zu versuchen mit diesen Randbedingungen:

- Lösche alle Zeilen mit einer oder beiden Koordinatenwerten 0.000
- Lösche alle Zeilen, deren Koordinatenwert(e) um mehr als 0,5° (entspricht ca. 30km) zur Vorzeile differieren

Grüße

[augustus3]

Zwischenbericht:
das erwähnte sinnigbenamte Fremdproggi schafft es doch, die Ausreißer zu eliminieren:
- alle Zeilen mit SAT=0 löschen lassen
- ggfs. Zeilen mit HDOP > 20 löschen lassen
- alle Zeilen mit v > 250 löschen lassen (ggfs. geringere Geschwindigkeiten, je nach Fahrzeug)
- hier evtl. manuell die Vorzeile löschen, da dort der Schlechtwert

Ich bin aber sehr erstaunt (übrigens auch bei RC), dass die Bearbeitung von sagen wir einem 50.000 Zeilen-Track pro Schritt über 20 Sekunden dauert (mit einem 3GHz-Vierkern-Renner), man also WARTEND vor dem Rechner sitzt. Dies bin ich nicht mehr gewohnt !!

Grüße

[lundefugl]

Hallo,

Ich bin aber sehr erstaunt (übrigens auch bei RC), dass die Bearbeitung von sagen wir einem 50.000 Zeilen-Track pro Schritt über 20 Sekunden dauert (mit einem 3GHz-Vierkern-Renner), man also WARTEND vor dem Rechner sitzt. Dies bin ich nicht mehr gewohnt !!

Du musst schon schreiben, welche Aktionen du machst, bei denen du warten musst.
Ich arbeite hier mit Tracks, die über eine Million Wegpunkte haben und habe eigentlich fast nie Wartezeiten. Der RC ist das mir einzige Programm, was mit den Datenmengen umgehen kann und wo es eben keine merklichen Wartezeiten gibt.

Evtl. ist auch nur deine Java-VM speichertechnisch an der Grenze und der GarbageCollector muss ständig aufräumen. Starte doch mal die Jar-Variante direkt und gib ihr mehr Speicher (der Defaultwert von Java ist extrem niedrig und IMHO nicht mehr zeitgemäß) - evtl. behebt das schon dein Geschwindigkeitsproblem.

z.B. startet folgender AUfruf den RC mit 4 GB:
java -jar -Xmx4096m RouteConverterWindows64.jar

Gruß
Thomas

[augustus3]

Hallo Thomas,

danke für den Tipp. Java scheint tatsächlich anfällig für Fehleinstellungen.

Glaube zwischenzeitlich, dass meine Flaschenhälse
- für RC die Kartendarstellung, also die Internetverbindung
- für gta (auch) die "alte" HDD ist (habe noch keine SSD)

Bei einem Löschen von Zwischenpunkten müssen eigentlich alle folgenden (mindestens die Statistiken, Max-Werte etc.) neuberechnet werden, das muss dann doch etwas dauern.

Grüße
Andy

(letztlich doch zufrieden, wie wenig Schreibfehler die SD produziert nach 5 Jahren HeavyDuty: immer 20% freilassen...)

[nordlicht]

...(mit einem 3GHz-Vierkern-Renner)...

von denen sich drei Kerne langweilen, weil dem vierten nicht helfen können . Im Ernst: damit mehrere Kerne für eine Aufgabe benutzt werden können, muß die Aufgabe parallelisierbar sein (was inkrementelle Trackbearbeitung wie deinem Beispiel m.E. nicht ist, ich laß mich da aber gern eines Besseren belehren) und die Software muß auch entsprechend programmiert sein. Sonst werden die zusätzlichen Kerne für andere geöffnete Programme benutzt.