Womit navigiert man am besten?

Dazu kommt , dass das GPS die gefahrenen km berechnen muss, aus interpolierten Werten, er muss ja aus den Höhenmessungen eine Korrektur der Strecke ohne Höhe berechnen und das im Intervall. Je nachdem wie groß die Intervalle sind und welche Interpolationsmethode genutzt wird, variiert das Ergebnis.
Ganz so hochkomplex muss es dann aber doch nicht sein.
Man kann die Distanz anhand der jeweiligen GPS-Koordinaten berechnen und ich bin mir ziemlich sicher, dass die Geräte aus dem Consumerbreich dafür auch relativ einfache Formel verwenden.

https://stackoverflow.com/questions/365826/calculate-distance-between-2-gps-coordinates

Hier zwei Beispiele eine meiner häufig gefahren Taunus Rennradrunden (mit Edge 500 bzw. Wahoo Bolt und jeweils gekoppeltem Speed Sensor aufgezeichnet):

1.)
Distanz basierend auf Messung mittels Speed Sensor (vom Edge direkt übernommen): 47,965 km

Distanz basierend auf GPS Messung (anhand der jeweiligen GPS Koordinaten und der obigen Formel nachtärglich aus den protokollierten Datenreihen berechnet): 47,623 km

2.)
Distanz basierend auf Messung mittels Speed Sensor (vom Bolt direkt übernommen): 45,74 km

Distanz basierend auf GPS Messung (anhand der jeweiligen GPS Koordinaten und der obigen Formel nachtärglich aus den protokollierten Datebnreihen berechnet):): 46,404 km

Hält sich dann doch alles im Rahmen. Könnte sinusalba auch relativ leicht mittels geeigneter Software (notfalls geht auch Excel, wenn er die Datenreihen entsprechend in Textform extrahieren kann) nachrechnen, sofern er die Touren protokolliert hat.
 
Ganz so hochkomplex muss es dann aber doch nicht sein.
Man kann die Distanz anhand der jeweiligen GPS-Koordinaten berechnen und ich bin mir ziemlich sicher, dass die Geräte aus dem Consumerbreich dafür auch relativ einfache Formel verwenden.

https://stackoverflow.com/questions/365826/calculate-distance-between-2-gps-coordinates
Klar Luftstrecke zwischen zwei Punkten ist einfach.
Aber erstmal fährst du nicht Luftstrecke und in der Regel hoch und runter. Das heißt du musst viele Punkte mittel GPS ermitteln (mit allen seinen Fehlern) und aus diesen die Entfernung berechnen (und eben die Fehlerhaften Punkte eliminieren) und die Zwischenpunkte interpolieren. Ist ähnlich wie Flächenberechnung ist die Fläche durch unregelmäßige Konturen begrenzt wird es schwierig, dann nutzt man z.B. die Integralrechnung.
Mit einfachen Dreisatz ist es da nicht getan.

Schau dir mal auf Wiki an wie groß die Unterschiede in der Ermittlung der Position alleine sind.
https://de.wikipedia.org/wiki/Globa.../media/Datei:Tracks_around_the_Birkenkopf.png

Dann kann man sich vorstellen wie schnell dabei Fehler entstehen. Wir haben in unserer Runde immer Abweichungen von einigen km zwischen unseren Geräten. Eben aus den genannten Gründen.
 
Zuletzt bearbeitet:
Klar Luftstrecke zwischen zwei Punkten ist einfach.
Aber erstmal fährst du nicht Luftstrecke und in der Regel hoch und runter. Das heißt du musst viele Punkte mittel GPS ermitteln (mit allen seinen Fehlern) und aus diesen die Entfernung berechnen (und eben die Fehlerhaften Punkte eliminieren) und die Zwischenpunkte interpolieren. Ist ähnlich wie Flächenberechnung ist die Fläche durch unregelmäßige Konturen begrenzt wird es schwierig, dann nutzt man z.B. die Integralrechnung.
Mit einfachen Dreisatz ist es da nicht getan.

Schau dir mal auf Wiki an wie groß die Unterschiede in der Ermittlung der Position alleine sind.
https://de.wikipedia.org/wiki/Globa.../media/Datei:Tracks_around_the_Birkenkopf.png

Dann kann man sich vorstellen wie schnell dabei Fehler entstehen. Wir haben in unserer Runde immer Abweichungen von einigen km zwischen unseren Geräten. Eben aus den genannten Gründen.

Ein protokollierter Track basiert nun aber einmal auf aneinandergereiten Punkten, im Endergebnis also quasi die zusammengesetzte Luftstrecke vieler Punkte.

Die Hardcore-Mathematik (Physik) inkl. diverser Glättungsverfahren findet mittlerweile eh bereits im GPS Chip statt. Das ist mehr oder weniger alles gekapselt.

Ausgepuckt werden dann die fertigen Datenreihen, das sind unter anderem die GPS Koordinaten, Speed, Höhe und einiges mehr, die je nach eingestellter Samplerate (bei Bikecomputern heutzutage 1 sek, falls nicht explizit geändert) protokolliert werden. Kann man ja alles den (Track)-Aufzeichnungen entnehmen (FIT, GPX, TCX oder was auch immer für ein Format).

Berechnet man aus diesen Datenreihen und den dazugehörenden Wertepaaren die jeweilige Distanz, dann hat man in der Summe die Gesamtdistanz eine Tracks. Und da fällt es halt auf, dass die Unterschiede so groß dann doch nicht sind. Einzig wenn man viele Pausen macht und der GPS Chipsatz diese nicht filtert, dann kommen auf diese Weise Geisterdistanzen zustande, weil das Rauschen im Stand bei einer Addition natürlich aufschlägt.
Dann müsste die reine GPS-Aufzeichnung gegenüber der sensorbasierten Aufzeichnung aber eher eine größere Distanz zum Ergebnis haben (siehe das Rauschen das man Deiner Verlinkung entnehmen kann).

Unter Android (einige GPS Bikecomputer setzen ja mittlerweile komplett auf Android auf) ist das alles sehr easy zu handeln. Garmin wird das genauso gekapselt haben.

Über die Geschwindigkeitswerte lässt man dann noch mal einen Filter laufen, damit die Geschwindigkeitswerte nicht zu sprunghaft sind. Auch die GPS-Koordinaten wird man etwas säubern, bevor diese protokolliert werden, damit hinterher beim User eine entsprechende sauber Trackauswertung herauskommt.

Was spricht also dagegen, bereits in Echtzeit auf diesen Berechnungen bzw. auf die durch diese Berechnungen gesäuberten Datenreihen aufzusetzen und mittels einfacher Geo-Mathematik die Distanzwerte zu berechnen?
 
Ein protokollierter Track basiert nun aber einmal auf aneinandergereiten Punkten, im Endergebnis also quasi die zusammengesetzte Luftstrecke vieler Punkte.

Die Hardcore-Mathematik (Physik) inkl. diverser Glättungsverfahren findet mittlerweile eh bereits im GPS Chip statt. Das ist mehr oder weniger alles gekapselt.

Ausgepuckt werden dann die fertigen Datenreihen, das sind unter anderem die GPS Koordinaten, Speed, Höhe und einiges mehr, die je nach eingestellter Samplerate (bei Bikecomputern heutzutage 1 sek, falls nicht explizit geändert) protokolliert werden. Kann man ja alles den (Track)-Aufzeichnungen entnehmen (FIT, GPX, TCX oder was auch immer für ein Format).

Berechnet man aus diesen Datenreihen und den dazugehörenden Wertepaaren die jeweilige Distanz, dann hat man in der Summe die Gesamtdistanz eine Tracks. Und da fällt es halt auf, dass die Unterschiede so groß dann doch nicht sind. Einzig wenn man viele Pausen macht und der GPS Chipsatz diese nicht filtert, dann kommen auf diese Weise Geisterdistanzen zustande, weil das Rauschen im Stand bei einer Addition natürlich aufschlägt.
Dann müsste die reine GPS-Aufzeichnung gegenüber der sensorbasierten Aufzeichnung aber eher eine größere Distanz zum Ergebnis haben (siehe das Rauschen das man Deiner Verlinkung entnehmen kann).

Unter Android (einige GPS Bikecomputer setzen ja mittlerweile komplett auf Android auf) ist das alles sehr easy zu handeln. Garmin wird das genauso gekapselt haben.

Über die Geschwindigkeitswerte lässt man dann noch mal einen Filter laufen, damit die Geschwindigkeitswerte nicht zu sprunghaft sind. Auch die GPS-Koordinaten wird man etwas säubern, bevor diese protokolliert werden, damit hinterher beim User eine entsprechende sauber Trackauswertung herauskommt.

Was spricht also dagegen, bereits in Echtzeit auf diesen Berechnungen bzw. auf die durch diese Berechnungen gesäuberten Datenreihen aufzusetzen und mittels einfacher Geo-Mathematik die Distanzwerte zu berechnen?
Stichwort Interpolation zwischen den Punkten und anschliessende Glättung. Irgendwo gab es mal einen Artikel wo die Unterschiede herkommen. Da wurden genau die verschiedenen Verfahren erklärt. Aber wenn das so einfach ist dann bewerbe dich doch bei Garmin, die können fähige Entwickler gebrauchen....
 
Stichwort Interpolation zwischen den Punkten. Irgendwo gab es mal einen Artikel wo die Unterschiede herkommen. Da wurden genau die verschiedenen Verfahren erklärt. Aber wenn das so einfach ist dann bewerbe dich doch bei Garmin, die können fähige Entwickler gebrauchen....
Niemand hat gesagt, dass das alles so einfach wäre. Allerdings reden wir vom Consumerbereich (Bikecomputer) und es hat sich eine Menge getan.
Die Zeiten, wo man einen Doktorgrad in der Physik haben musste, weil man auf Rohdatenebene mit den GPS-Chipsätzen hantiert hat, die sind größtenteils vorbei. Vieles wird heute in den GPS Chipsätzen bereits behandelt und darüber hinaus gibt es Libraries, die die Hersteller der GPS-Chipssätze mitliefern. Ich spreche nicht von Garmins Aviation Segment, das ist eine ganz andere Liga.

Natürlich kann man immer noch vieles falsch machen, aber ich frage mal ganz dumm in die Runde:

Wenn ich mit meiner Fenix, die aus purer Faulheit mit keinem meiner SPD-Bike-Sensoren gekoppelt ist, einen Track aufzeichne und diesen hinterher auswerte und just zum Spaß die von der Fenix berechnete GPS basierte Distanz anhand der GPS-Koordinaten neu berechne, weshalb stimmt die nachträglich berechnete Distanz dann mehr oder weniger mit dem Distanzwert überein, dem ich dem Display meiner Fenix am Ende der Aufzeichnung entnehmen kann?
Mehr oder weniger, weil es natürlich ein paar Mikro-Nachkommastellen Abweichung gibt, alleine schon aufgrund fixen Samplerate. Möglicherweise, weil die Fenix sehr nahe auf den parallel protokollierten Daten operiert und daraus die Distanz ermittelt?

Wenn da soviel Interpolation und was auch immer stattfindet, die ich bei der Nachberechnung nicht vornehme, dann muss die Interpolation bereits eine Stufe zuvor stattgefunden haben. Das da zuvor viel berechnet wird, das ist unstrittig und das habe ich auch nicht bestritten.

Wie auch immer, ich will mich hier nicht streiten... ist dann alles doch nicht so wichtig und in der heutigen Zeit gibt es gravierende Probleme, als diese Feinheiten.

Was der Fragesteller daraus macht, ist eh ihm überlassen. Ich würde auch einen SPD-Sensor mit dem GPS Bike Computer koppeln, aber das hatte ich ja bereits geschrieben.
 
Niemand hat gesagt, dass das alles so einfach wäre. Allerdings reden wir vom Consumerbereich (Bikecomputer) und es hat sich eine Menge getan.
Die Zeiten, wo man einen Doktorgrad in der Physik haben musste, weil man auf Rohdatenebene mit den GPS-Chipsätzen hantiert hat, die sind größtenteils vorbei. Vieles wird heute in den GPS Chipsätzen bereits behandelt und darüber hinaus gibt es Libraries, die die Hersteller der GPS-Chipssätze mitliefern. Ich spreche nicht von Garmins Aviation Segment, das ist eine ganz andere Liga.

Natürlich kann man immer noch vieles falsch machen, aber ich frage mal ganz dumm in die Runde:

Wenn ich mit meiner Fenix, die aus purer Faulheit mit keinem meiner SPD-Bike-Sensoren gekoppelt ist, einen Track aufzeichne und diesen hinterher auswerte und just zum Spaß die von der Fenix berechnete GPS basierte Distanz anhand der GPS-Koordinaten neu berechne, weshalb stimmt die nachträglich berechnete Distanz dann mehr oder weniger mit dem Distanzwert überein, dem ich dem Display meiner Fenix am Ende der Aufzeichnung entnehmen kann?
Mehr oder weniger, weil es natürlich ein paar Mikro-Nachkommastellen Abweichung gibt, alleine schon aufgrund fixen Samplerate. Möglicherweise, weil die Fenix sehr nahe auf den parallel protokollierten Daten operiert und daraus die Distanz ermittelt?

Wenn da soviel Interpolation und was auch immer stattfindet, die ich bei der Nachberechnung nicht vornehme, dann muss die Interpolation bereits eine Stufe zuvor stattgefunden haben. Das da zuvor viel berechnet wird, das ist unstrittig und das habe ich auch nicht bestritten.

Wie auch immer, ich will mich hier nicht streiten... ist dann alles doch nicht so wichtig und in der heutigen Zeit gibt es gravierende Probleme, als diese Feinheiten.

Was der Fragesteller daraus macht, ist eh ihm überlassen. Ich würde auch einen SPD-Sensor mit dem GPS Bike Computer koppeln, aber das hatte ich ja bereits geschrieben.
Das war auch kein Streit sondern sollte ein versteckter Seitenhieb auf Garmin sein.....
Und ja du hast Recht die Glättung geschieht teilweise vorher und genau da ist der Hund begraben. Je nachdem welche Methode gewählt wurde gibt es eben Abweichungen zwischen verschiedenen Geräten.
Ich selber bin ja Entwickler von elektronischen Geräten und es gibt immer viele Möglichkeiten zum Ziel zu komme unter den gegebenen Vorgaben und manchmal muss man eben den einen oder anderen Kompromiss machen, das wird hier nicht anders sein.
Kurze Rede langer Sinn :D Ich wollte sagen aufgrund verschiedener Arten der Umsetzung der Entfernungsberechnung kann es eben aUntersciede alleine zwischen verschiedenen GPS Geräten kommen. Das ist völlig normal.
 
Zuletzt bearbeitet:
Das war auch kein Streit sondern sollte ein versteckter Seitenhieb auf Garmin sein.....
Und ja du hast Recht die Glättung geschieht teilweise vorher und genau da ist der Hund begraben. Je nachdem welche Methode gewählt wurde gibt es eben Abweichungen zwischen verschiedenen Geräten.
Ich selber bin ja Entwickler von elektronischen Geräten und es gibt immer viele Möglichkeiten zum Ziel zu komme unter den gegebenen Vorgaben und manchmal muss man eben den einen oder anderen Kompromiss machen, das wird hier nicht anders sein.
Kurze Rede langer Sinn :D Ich wollte sagen aufgrund verschiedener Arten der Umsetzung der Entfernungsberechnung kann es eben aUntersciede alleine zwischen verschiedenen GPS Geräten kommen. Das ist völlig normal.
Dieses "Wer misst, misst Mist." stimmt natürlich schon in diesem Zusammenhang.

Man kann der Sache aber schon etwas auf den Grund gehen, wenn man auf die Geräte, die solche großen Abweichungen zueinander generieren, zugreifen kann.
Man muss es ja nicht mit der Ursachenforschung übertreiben, aber ein parellel betriebener GPS Logger auf dem Smartphone dürfte schon einen weiteren Einblick erzeugen.
Da viele Smartphone Logger die GPS Daten aber nicht glätten, könnte es sogar sein, dass der GPS Logger auf dem Smartphone noch größere Enddistanzen misst. Das könnte z.B. ein Indiz sein, dass sein GPS Bike-Computer es mit der Glättung übertreibt und daher bei längeren Touren (> 100 km) zuviele Kilometer unterschlagen werden.
Wie auch immer, vielleicht kann sinusalba später ja noch etwas beisteuern. Interessant wäre es schon zu wissen, wer - also welches Gerät - da so daneben liegt (Hobbys erzeugen manchmal komische Angewohnheiten) ;)

PS: Wir hatten mal den Fall eines prellenden Read-Kontakts in einem Speed Sender in Kombination mit einem einfachen Bike-Computer ohne Aufzeichungsfunktion. Das führte auch zu übergroßen Distanzen. komischerweise hatte das auf die Berechnung der Speedwerte bei diesem Bike-Computer weniger Einfluß (vielleicht aufgrund eines Variablenüberlauf?). Erst als wir den Speed-Sender mit einem modernen Bike-Computer mit Aufzeichnungsfunktion verbunden hatten, konnte man sehen, dass der Speed-Sender zu hohe Werte generiert.
Wie Du sagst, da kann wirklich vieles zusammenkommen und je nach Tourenlänge schlägt das dann mal mehr und mal weniger auf.
 
Mein Edge 830 navigiert autonom auch auf Schotterwegen ziemlich gut. D. h. Man kann ein Ziel auswählen und er bringt einen dort hin.
Er ist wesentlich handlicher als ein Smartphone und versperrt wesentlich weniger die Sicht, erträgt auch die Erschütterungen besser als ein Smartphone und die Batterie hält locker 20 Stunden durch. Im Energiesparmodus auch länger.
Das Nachfolgemodell Edge 840 gibt es im Bundle für 499 Euro, dann hat man auch einen Brustgurt, gegen den meine Uhr keinen Auftrag hat bezüglich der Zuverlässigkeit bei der Herzfrequenz.
Wenn man dann auf Anschlag lange fahren will ist das für mich auch sehr wichtig. Denn wenn ich in Wirklichkeit mit 170er Herzfrequenz unterwegs bin, mir die Uhr aber nur 150 anzeigt fahre ich mich, besonders auf den ersten Kilometern, blau und kann dann einpacken, weil ich fertig bin.
Die Uhren sind eine Mode, aber ernsthaftes Material sind sie nicht und ein Handy am Lenker nervt ziemlich, ist einfach viel zu groß und auch anfälliger für Schäden durch die Erschütterungen.
Bin gerade mal wieder in unbekannten Gefilden unterwegs - Navigation mit Funktelefon (Blackview N6000), Aufzeichnung mit Garmin-Uhr. Zur Langzeithaltbarkeit kann ich natürlich noch nichts sagen, aber für mich taugt das sehr gut. Akku nach >4h Laufzeit übrigens noch bei 75%.
Das Telefon hat 200€ gekostet. Barometer vorhanen, BT LE / ANT+ angeblich auch.
Die Größe passt gerade noch; da sich die 200g eher auf die Dicke verteilen als auf die Fläche, versperrt da auch nichts die Sicht.
Das Gerät wird über einen Garminhalter am Rad befestigt, dafür habe ich das gegenstück an der Rückseite des Telefons angeklebt. Hält!

Einziger Kritikpunkt am Telefon: Es gibt keine Halterung für einen Lanyard, deswegen habe ich das zusätzlich in einer TPU-Hülle.

Navigiert wird mit Locus Maps / Openandromaps.
 
Zurück