Geschwindigkeitsprofil aus GPX-Track erstellen.

Die Einstellungen, die Josm anbietet reichen Dir nicht?

Um das beurteilen zu können müsste ich erst mal wissen, was Josm an disbezüglicher Funktionalität bietet. Ist das irgendwo dokumentiert?

Keine Ahnung, wo da die Doku dazu ist, ist auch recht selbsterklärend.

rechte Maustaste auf die GPX-ebene -> Spureinstellungen -> Geschwindigkeit

Während ich bei JOSM keine absoluten Geschwindigkeitsangaben sehe (die Funktion kannte ich noch gar nicht): QLandkarte GT und QMapShack zeigen Dir z.B. die Geschwindigkeit an der Stelle, an der sich Dein Mauszeiger befindet. Doch Vorsicht: Die ergibt sich aus der Entfernung und Zeitdifferenz zwischen zwei Trackpunkten, und während die Zeiterfassung recht genau ist… Da bist Du bei einem richtig gemütlichen Spaziergang auch gerne mal mit 8km/h unterwegs gewesen 😉 In sofern: Für ordentliche Aussagen müsstest Du konfigurieren können, über wie viele Messpunkte gemittelt werden soll, nur dann hast Du eine Aussage und kennst deren Grenzen. Dazu müsstest Du auch ne Ahnung von dem haben, was Dein Track bietet. Und ein solches Tool kenne ich denn auch nicht… Wobei ich sehe eben: Fürs Auto sollte reichen, was QLandkarte GT und QMapShack bieten - die Trackpunkte beim Autofahren dürften relativ weit auseinander liegen.

Hallo,

ich benutze dafür QLandkarteGT. Dort werden die Trackpoints als Tabelle dargestellt und bei der Auswahl eines Eintrags wird der jeweilige Trackpunkt hervorgehoben.

Was auf meiner ToDo-Liste steht (weil ich das auch haben will): Ein Skript, das aus dem GPS-Track die Geschwindigkeit berechnet, für jeden Trackpoint einen Waypoint erstellt und die Geschwindigkeit in dessen description-Attribut schreibt. Dann kann man die Geschwindigkeits-Waypoints in JOSM laden und sieht eine Reihe an Labeln.

Alternative: ICE fahren und ice-portal-speed-logger von rurseekatze nutzen.

Viele Grüße

Michael

Die Anzeige in Josm ist interessant, nützt mir aber in der Tat nichts, da ich absolute Werte brauche. QLandkarteGT ist ne tolle Sache. Die Spalte Geschwindigkeits bei den Trackpoints sieht schon recht brauchbar aus, hat aber teilweise sehr seltsame außreißer (560 km/h mit der Regionalbahn). Da ist noch eine Spalte die "speed" heißt und einen Werte mit einer Stelle vor den Komma enthällt ohne Einheit, die in keinem für mich erkennbaren Zusammenhang mit der Geschwindigkeitsspalte stehen. Die werte stehen offenbar genau so in dem gpx.file drin in der Art:

<trkpt lat="50.79431691286077" lon="6.218735145860315">
<ele>217.64188273515427</ele>
<time>2016-05-29T13:45:18Z</time>
<extensions>
<speed>1.3436145782470703</speed>
</extensions>
</trkpt>

Weiß jemand, was das ist?

Ist das ein Fußgängertrack? Dann könnte es Meter/Sekunde sein. Umrechnung in km/h wäre dann "*3.6"

gormo wrote:

Ist das ein Fußgängertrack? Dann könnte es Meter/Sekunde sein. Umrechnung in km/h wäre dann "*3.6"

Natürlich! Das sind m/s. Das ich da nicht gleich drauf gekommen bin! Diese Werte sind
offenbar sehr viel besser als das was QLandkarteGT errechnet hat (wie auch immer diese genau ermittelt wurden). Schade, das man diese nicht so einfach auswerten kann. Den Track habe ich übrigens mit OSMTracker für Android erstellt.

Also unter Windows habe ich dazu immer http://www.gps-track-analyse.de/ (ziemlich mächtig) genutzt, unter Linux nutze ich das eher einfach daherkommende GpsPrune 🤔

Trockennasenaffe wrote:

Natürlich! Das sind m/s. Das ich da nicht gleich drauf gekommen bin! Diese Werte sind
offenbar sehr viel besser als das was QLandkarteGT errechnet hat (wie auch immer diese genau ermittelt wurden).

Ich enttäusche dich ungern, aber was sagt dir, daß sie besser sind, sogar „sehr viel besser“? Daß sie mehr Stellen hinter dem Komma haben? Du glaubst aber nicht wirklich, daß dein GPS deine Geschwindigkeit auf 100 Attometer (das ist 1/250 eines Wasserstoffatomdurchmessers) pro Sekunde genau messen kann, oder? Dazu braucht es schon den Heisenbergkompensator aus Star Trek.

Direkt messen kann GPS nur Positionen. Geschwindigkeiten werden ermittelt, indem der Abstand zweier Positionen errechnet und durch die Zeitdifferenz dazwischen dividiert wird. Weil die Meßpunkte selten genauer als 3 Meter sind, kann bei Messungen im Sekundenabstand und Fußgängergeschwindigkeit ein Fehler von Faktor 2 und mehr auftreten (also das Doppelte oder die Hälfte des tatsächlichen Wertes). Weil GPS nun mal die Positionen nicht genauer feststellen kann, kann keine Berechnung genauer sein als das. Die Software glättet das noch etwas, indem sie weitere Meßpunkte hinzuzieht, aber genauer als auf 1 m/s dürfte eine punktuelle Geschwindigkeitsmessung kaum hinzubekommen sein – Mittelwertbildung geht ja nur da, wo du mit gleichmäßiger Geschwindigkeit gelaufen bist. Mein Auto ist mal auf einem kurvigen Waldweg über 700 km/h gefahren. Sagt das GPS. Da lag halt eine Messung 10 Meter hinter dem Heck und die nächste 100 Meter oder mehr vor dem Bug. Solche Abweichungen sind selten, kommen aber vor, gerade im Wald mit irrsinnig vielen Reflexionen und Beugungen der Satellitensignale an den Bäumen.

Genauer als die Inputdaten vom GPS können die errechneten Geschwindigkeitswerte nicht sein, egal wie viele Dezimalstellen dabei rechnerisch entstehen. Und die Inputdaten des GPS haben pro Meßpunkt eine mögliche Abweichung von mehreren Metern. Wenn die Meßpunkte jeweils eine Sekunde auseinanderliegen, dann kann das Ergebnis nicht auf Zehntel-m/s genau werden. Weil die Positionsmessungen schon viel ungenauer sind. Da kann mir eine tatsächliche Geschwindigkeit von 3 km/h als 1,5 km/h ermittelt werden, weil einmal zu weit vorn und einmal zu weit hinten gemessen wurde. Und wenn mir das in der XML-Datei als 1,577839265784930 km/h ausgegeben wird, ist das trotz der vielen Nachkommastellen falsch.

Schade, das man diese nicht so einfach auswerten kann. Den Track habe ich übrigens mit OSMTracker für Android erstellt.

Wo hast du die Hardware getragen? Am Körper, etwa in der Hosentasche? Dann schattest du die Hälfte der Satelliten ab, die Messungen können dann durchaus 10 Meter und mehr danebenliegen. Wenn ich zu Fuß einen möglichst exakten Track haben will, stecke ich mir das Handy unter den Hut. Noch etwas Stoff dazwischen, aber ansonsten freier Blick zu allen Seiten. Oben im Rucksack ist auch ein schöner Platz. Im Auto liefert das Handy nur direkt an der Windschutzscheibe einen brauchbaren Track, auf dem Beifahrersitz liegend kannst du die Messung in die Tonne treten, das ist dann mehr oder weniger nur noch ein grober Anhaltspunkt für den Landkreis, in dem du warst.

--ks

EDIT:: Umgestellt, ist logischer

kreuzschnabel wrote:

Genauer als die Inputdaten vom GPS können die errechneten Geschwindigkeitswerte nicht sein, egal wie viele Dezimalstellen dabei rechnerisch entstehen. Und die Inputdaten des GPS haben pro Meßpunkt eine mögliche Abweichung von mehreren Metern. Wenn die Meßpunkte jeweils eine Sekunde auseinanderliegen, dann kann das Ergebnis nicht auf Zehntel-m/s genau werden. Weil die Positionsmessungen schon viel ungenauer sind. Da kann mir eine tatsächliche Geschwindigkeit von 3 km/h als 1,5 km/h ermittelt werden, weil einmal zu weit vorn und einmal zu weit hinten gemessen wurde. Und wenn mir das in der XML-Datei als 1,577839265784930 km/h ausgegeben wird, ist das trotz der vielen Nachkommastellen falsch.

Für die Geschwindigkeitsberechnung ist der absolute Fehler der Positionsbestimmung völlig irrelevant. Dieser fällt bei der Differenzbildung zwischen zwei Positionsmessung fast vollständig heraus. Nur wenn sich die Empfangsverhältnisse und damit
der absolute Fehler dramatisch ändern, ist die Geschwindigkeitsbestimmung viel ungenauer.

fx99 wrote:

kreuzschnabel wrote:

Genauer als die Inputdaten vom GPS können die errechneten Geschwindigkeitswerte nicht sein, egal wie viele Dezimalstellen dabei rechnerisch entstehen. Und die Inputdaten des GPS haben pro Meßpunkt eine mögliche Abweichung von mehreren Metern. Wenn die Meßpunkte jeweils eine Sekunde auseinanderliegen, dann kann das Ergebnis nicht auf Zehntel-m/s genau werden. Weil die Positionsmessungen schon viel ungenauer sind. Da kann mir eine tatsächliche Geschwindigkeit von 3 km/h als 1,5 km/h ermittelt werden, weil einmal zu weit vorn und einmal zu weit hinten gemessen wurde. Und wenn mir das in der XML-Datei als 1,577839265784930 km/h ausgegeben wird, ist das trotz der vielen Nachkommastellen falsch.

Für die Geschwindigkeitsberechnung ist der absolute Fehler der Positionsbestimmung völlig irrelevant. Dieser fällt bei der Differenzbildung zwischen zwei Positionsmessung fast vollständig heraus. Nur wenn sich die Empfangsverhältnisse und damit
der absolute Fehler dramatisch ändern, ist die Geschwindigkeitsbestimmung viel ungenauer.

Es kommt wie fast immer auf die Umstände an.
Ich verwende auch GPS-Track-Analyse und sehe im Geschwindigkeitsdiagramm sofort, wo der Tempomat beim Auto aktiv war. Das gibt eine waagrechte Linie mit Schwankungen von wenig Prozent.
Ganz anders sieht es auf einem Fußweg im Wald aus, da springen die Werte auch bei einigermaßen gleichmäßigem Tempo oft wild rauf und runter. Bei kurzen Ausreißern wird da auch mal Flugzeuggeschwindigkeit erreicht.

seichter wrote:

Ganz anders sieht es auf einem Fußweg im Wald aus, da springen die Werte auch bei einigermaßen gleichmäßigem Tempo oft wild rauf und runter. Bei kurzen Ausreißern wird da auch mal Flugzeuggeschwindigkeit erreicht.

Eben, deshalb ja auch meine Frage danach (Beispiele hatte ich ja geliefert). Der Meßfehler ist, abhängig von der Aufstellung des GPS-Empfängers, über einen auch kurzen Trackabschnitt eben nicht konstant, und bei Fußgängergeschwindigkeiten schon gar nicht irrelevant (bei Autobahngeschwindigkeiten eher).

--ks

EDIT: Typo

fx99 wrote:

Für die Geschwindigkeitsberechnung ist der absolute Fehler der Positionsbestimmung völlig irrelevant. Dieser fällt bei der Differenzbildung zwischen zwei Positionsmessung fast vollständig heraus.

Wenn man einen hinreichend konstanten Meßfehler annimmt, ja. Meine Tracks, ob mit Montänchen oder mit OSMTracker erstellt, hatten bislang selten eine solche Qualität. Aber deshalb hatte ich ja nach den genaueren Umständen gefragt.

Nur wenn sich die Empfangsverhältnisse und damit
der absolute Fehler dramatisch ändern, ist die Geschwindigkeitsbestimmung viel ungenauer.

Dramatisch? Das tun sie im Wald durchaus alle zwei bis fünf Meter. Jedenfalls ausreichend für eine Zickzacklinie. Sobald ein neuer Baum im Weg gerade dieses einen Satelliten steht, der eben noch so gut zu empfangen war.

– Wie auch immer, mir ging es um die oben geäußerte Annahme, Geschwindigkeitsangaben mit 14 Stellen hinter dem Komma seien sehr viel besser als solche mit einer oder zwei Stellen hinter den Komma. Ich denke, du wirst mir darin recht geben, daß das nicht der Fall ist, weil der physikalische Meßfehler, ob man ihn nun für bedeutend hält oder nicht, allerspätestens in der zweiten Nachkommastelle zuschlägt.

--ks

kreuzschnabel wrote:

Ich enttäusche dich ungern, aber was sagt dir, daß sie besser sind, sogar „sehr viel besser“? Daß sie mehr Stellen hinter dem Komma haben?

Nö, das ist mir völlig egal, ich nehme eh nur die ersten Stellen. Besser an diesen Werten ist, dass sie einen sehr viel glatteren, plausibleren Geschwindigkeitsverlauf ergeben der dem was ich erwarteten würde sehr viel näher kommt. Die Werte, die QLandkarteGT errechnet hat, ergeben einen deutlich anderen Verlauf, der über weite Strecken überhaupt keinen Sinn ergibt.

kreuzschnabel wrote:

Genauer als die Inputdaten vom GPS können die errechneten Geschwindigkeitswerte nicht sein, egal wie viele Dezimalstellen dabei rechnerisch entstehen. Und die Inputdaten des GPS haben pro Meßpunkt eine mögliche Abweichung von mehreren Metern. Wenn die Meßpunkte jeweils eine Sekunde auseinanderliegen, dann kann das Ergebnis nicht auf Zehntel-m/s genau werden. Weil die Positionsmessungen schon viel ungenauer sind. Da kann mir eine tatsächliche Geschwindigkeit von 3 km/h als 1,5 km/h ermittelt werden, weil einmal zu weit vorn und einmal zu weit hinten gemessen wurde. Und wenn mir das in der XML-Datei als 1,577839265784930 km/h ausgegeben wird, ist das trotz der vielen Nachkommastellen falsch.

Da es mir insbesondere um die Geschwindigkeitsbegrenzung von Bahnstrecken geht, ist nur eine Genauigkeit von mehr als 5 km/h im Mittel nicht erforderlich. Wenn das aber dann wie eine Sinuskurve zwischen 50 und 80 km/h aussieht ist es schwer zu beurteilen, ob das jetzt 60 oder 70 ist.

kreuzschnabel wrote:

Wo hast du die Hardware getragen? Am Körper, etwa in der Hosentasche?

Ich saß im Zug und habe das Handy vor die Fensterscheibe gehalten. Der Track ist von der Positionsabweichung mittelmäßig. Ein paar Meter Abweichung werden es schon sein.

Trockennasenaffe wrote:

Ich saß im Zug und habe das Handy vor die Fensterscheibe gehalten. Der Track ist von der Positionsabweichung mittelmäßig. Ein paar Meter Abweichung werden es schon sein.

Hängt von der Fensterscheibe ab :-) Ich wollte mal die Fährstrecke Dover–Dünkirchen mittracken und war doch sehr erstaunt, daß das Montänchen an der großen bugseitigen Fensterfront null Empfang hatte. Kein Signal. Nicht mal auf dem Fenstersims direkt am Glas liegend kam was an. Also wohl gut metallbeschichtetes Glas. Fürs offene Deck war mir das Wetter da wirklich zu mistig, obwohl ich mir gern Seeluft um die Ohren wehen lasse. ICE-Fenster haben auch Metallbeschichtung, aber UKW-Empfang geht innen, dann mag GPS auch gehen. Regionalexpresse sind da sicher problemlos. Das GPS sieht halt prinzipbedingt nur an einer Seite raus, ein lateraler Fehler ist fast unvermeidlich, da alle Meßfehler in dieselbe Richtung zeigen dürften (Verlängerung der Signalwege durch Reflexion ist überall drin, Verkürzung einklich net).

Trockennasenaffe wrote:

Besser an diesen Werten ist, dass sie einen sehr viel glatteren, plausibleren Geschwindigkeitsverlauf ergeben der dem was ich erwarteten würde sehr viel näher kommt. Die Werte, die QLandkarteGT errechnet hat, ergeben einen deutlich anderen Verlauf, der über weite Strecken überhaupt keinen Sinn ergibt.

Da wird es wirklich interessant: QLandkarteGT rechnet anhand der im Track stehenden Werte. Rechnet es falsch oder liegt das Problem im Track?

Es könnte z.B. so sein, dass die "speed"-Werte aus den Originaldaten des Chips stammen und nur echte Messwerte berücksichtigt werden. Im Track stehen dagegen normalerweise viel weniger Daten und die sind zum Teil oft auch noch erfunden. Z.B. wird bei einer Tunnelfahrt oft die Position einfach geraten und angezeigt und diese Werte kommen dann auch in den Track. War der Tunnel dummerweise nicht gerade, dann ist der erste echte Messwert hinter dem Tunnel weit vom letzten geratenen Wert entfernt ... das ergibt dann irre Geschwindigkeiten.

Weide

kreuzschnabel wrote:

Regionalexpresse sind da sicher problemlos.

Kommt sehr auf die Bauart an. Talent 1 geht, Talent 2 geht überhaupt nicht, die meisten Doppelstockwagen scheinen zu gehen.

Weide wrote:

Da wird es wirklich interessant: QLandkarteGT rechnet anhand der im Track stehenden Werte. Rechnet es falsch oder liegt das Problem im Track?

Die Punkte im Track sehen zumindest nicht grob falsch aus. Muss mir das noch mal genauer anschauen.

HI,
bevor Du dich jetzt sonst wie in QLandkarteGT einarbeitest sollte erwähnt werden das dieses Programm nicht mehr weiter entwickelt wird.
Nur noch schwerwiegende Fehler werden beseitigt.
Der Nachfolger ist QMapShack, finde ich zum Teil auch um einiges besser. https://bitbucket.org/maproom/qmapshack/wiki/Home
Ich denke mal dort findest Du auch das was du benötigst.
Gruß

Oh, QLandkarte GT ist tot? Gut zu wissen!

AlterSachse wrote:

Der Nachfolger ist QMapShack, finde ich zum Teil auch um einiges besser. https://bitbucket.org/maproom/qmapshack/wiki/Home
Ich denke mal dort findest Du auch das was du benötigst.

Ist das mittlerweile brauchbar? Vor ~ 6 Monaten hab ich QMapShack weder unter Windows vernünftig zum Laufen gebracht (vielleicht mag es keine virtualisierten Windosen) noch unter Linux überhaupt kompiliert bekommen (der spezielle dafür benötigte Compiler ließ sich gar nicht installieren).

--ks

kreuzschnabel wrote:

AlterSachse wrote:

Der Nachfolger ist QMapShack, finde ich zum Teil auch um einiges besser. https://bitbucket.org/maproom/qmapshack/wiki/Home

Ist das mittlerweile brauchbar? Vor ~ 6 Monaten hab ich QMapShack weder unter Windows vernünftig zum Laufen gebracht

Ich nutze Debian Testing, da gibt es fertige Pakete. QMapShack hat sich ordentlich gemacht, und auch wenns nun nimmer alle fünf Mausaktionen abstürzt: Es ist für mich (noch) kein vollständiger Ersatz zu QLandkarte GT. Das Bedienkonzept ist anders - zwar eigentlich logischer, aber dadurch (für mich) auch umständlicher, weniger effektiv; Mit QLandkarte GT komme ich deutlich schneller zum Ziel, was aber auch schlicht der Gewohnheit geschuldet sein mag. Falls Du Viking und sein Layer-Konzept kennst - in diese Richtung geht es. QMapShack ist auch weniger auf das dateibasierte Arbeiten ausgelegt - viel mehr für das Speichern Deiner Routen und Tracks in einer eigenen, lokalen Datenbank - wo mein Kram auf meiner Festplatte liegt ist nicht so leicht nachvollziehbar. So zumindest meine bisherige Erfahrung mit QMapShack.

Joachim Moskalewski wrote:

[QMapShack] Ich nutze Debian Testing, da gibt es fertige Pakete.

Hui, auch für stable. Schaun mer mal.

--ks

Da gebe ich doch auch mal meinen Senf dazu:

Geschwindigkeitsmessung:
Ein normales Consumer GPS hat neben dem systemischen Fehler (Verschiebung) einen statistischen Fehler (Rauschen). Der statistische Fehler liegt in der Größenordnung von Metern. Berechnet man die Geschwindigkeit aus der Position, wirkt sich dieser Fehler bei einem Fußgänger im Verhältnis natürlich stärker aus, als bei einem Fahrrad oder Auto.

In den Geräten wird die Position auch nochmal durch ein Kalmann-Filter verbessert. Hierzu wird ein unabhängiger Geschwindigkeitsvektor verwendet, um den statistischen Fehler in der Position zu reduzieren. Dieser ist natürlich bei einem Rad oder Auto ausgeprägter als bei einem Fußgänger. Was zusätzlich zu einem besseren Ergebnis führt. Bei den Navis wird in der Regel der Betrag dieses Vektors angegeben, der tatsächlich genauer ist, als die Geschwindigkeit aus der Position. Leider wird dieser Wert selten mit der Aufzeichnung abgelegt. Was echt schade ist.

Algorithmus QLGT/QMS:
Beide Programme benützen den selben Algorithmus. Für jeden Punkt wird der Punkt davor und danach, der mehr als 25m entfernt ist genommen. Aus diesen beiden Punkten wird der zurückgelegte Weg und die Zeit bestimmt, um die Geschwindigkeit zu berechnen. Das führt zu einem Mittelwert.

Wenn ein Geschwindigkeitswert im GPX mit abgespeichert wird:
Der wird bei QLGT ignoriert. Bei QMS wird er als zusätzlicher Wert in der Auswertung angegeben.

Ob nun QLandkarte GT oder QMapShack besser gefällt muss jeder selber entscheiden. Das Benutzerkonzept in QMapShack ist komplett überarbeitet worden und viele Kritikpunkt aus QLandkarte wurden bedacht. QMapShack kann natürlich mit einzelnen Dateien umgehen. Sogar besser als QLGT, weil Daten jetzt nach Datei (Projekt) im Arbeitsplatz gruppiert sind.

Und bitte den Arbeitsplatz nicht mit der eigentlichen Datenbank verwechseln. Sicher, der Arbeitsplatz ist auch eine SQLite Datenbank. Es ist und war aber nie das Konzept diesen als Speicherort zum archivieren von Daten zu verwenden. Um die eigenen Daten zu verwalten, muss man eine Datenbank erstellen/hinzufügen. Und dann ist auch klar wo die Daten auf der Festplatte liegen.

Also noch mal zu QMS.
Ich nutze es nur noch , unter Linux, und kann die Abstürze oder sonst irgendwelche Marotten nicht nachvollziehen. Na klar ist die Installation etwas aufwendiger aber es läuft.
Unter Debian Stable gab es bis vor einigen Wochen die Ver. 0.6. glaub ich.
In Debian Testing gibt es die Ver. 1.6 also die aktuelle und da werden auch gleich alle Abhängigkeiten mit installiert und das lief bei mir auf Anhieb.
Und für Ubuntu/Mint gibt es hier eine Anleitung http://altersachse.de/50-linux/qms/mint.php
Ach ja für Arch ist es glaub auch in der ARU dabei.
Zu WIN kann ich nichts sagen da es aus meinen Rechner verbannt wurde.
Wie gesagt ich nutze QMS schon für die ganze letzte MTB Saison und hatte keine Probleme damit bei der Erstellung und Auswertung meiner Tracks.