Streckenlänge berechnen (für Jogginganwendung)
Moderator: Roland
Streckenlänge berechnen (für Jogginganwendung)
Hi,
ich bin neu hier und hoffe, dass ihr mir eventuell weiterhelfen könnt.
Im Rahmen meiner Studienarbeit entwickle ich eine "Jogging"-Software für Handys. Dazu habe ich ein einfaches Nokia GPS-Modul LD-3W, welches mir die Position bestimmt.
Nach dem Start der Anwendung sollen Berechnungen zu der Länge der Strecke, Durchschnittsgeschw., Höhe, etc. ... angezeigt werden. Mein Problem liegt nun in der Berechnung der Streckenlänge.
Zur Zeit führe ich eine Berechnung der Länge zwischen zwei Koordinaten alle 10 sek durch (mit einfachem Pythagoras, da keine Erdkrümmung zu erwarten ist und addiere diese auf, um die Gesamtstreckenlänge zu bekommen. Nach der Überprüfung der Strecke mit GoogleEarth hat sich die berechnete Streckenlänge als sehr ungenau herausgestellt.
GoogleEarth berechnet ca. 3430m (per Handberechung überprüft)
Meine Programm berechnet 1650m
Auf kurzen Strecken ist der Unterschied noch nicht so groß. Aber auch inakzeptabel! (Schlechte Werte des GPS-Moduls sind schon gefiltert und können also nicht zu Fehlberechnungen führen)
Meine Fragen nun:
Wie kann ich meine Berechnung verbessern?
Kann es überhaupt sein, dass durch ungenaue Positionsangaben des GPS-Moduls (gehe von ca. 5 m / Messung aus) ein solch großer Unterschied entsteht? (Fehler sollten sich doch positiv/negativ die Waage halten)
Falls es sein kann, soll ich dann die Messungen nur alle 20 sek durchführen, um die Messfehler pro Messung zu minimieren?
Soll ich die Haversine Formel benutzen (ist doch zu aufwendig für kleine Berechnungen)?
Wie kann ich sonst das Problem angehen?
Hoffe, dass ich mein Problem gut genug erklärt habe.
Vielen Dank im Voraus!
Gruss,
Thomas
ich bin neu hier und hoffe, dass ihr mir eventuell weiterhelfen könnt.
Im Rahmen meiner Studienarbeit entwickle ich eine "Jogging"-Software für Handys. Dazu habe ich ein einfaches Nokia GPS-Modul LD-3W, welches mir die Position bestimmt.
Nach dem Start der Anwendung sollen Berechnungen zu der Länge der Strecke, Durchschnittsgeschw., Höhe, etc. ... angezeigt werden. Mein Problem liegt nun in der Berechnung der Streckenlänge.
Zur Zeit führe ich eine Berechnung der Länge zwischen zwei Koordinaten alle 10 sek durch (mit einfachem Pythagoras, da keine Erdkrümmung zu erwarten ist und addiere diese auf, um die Gesamtstreckenlänge zu bekommen. Nach der Überprüfung der Strecke mit GoogleEarth hat sich die berechnete Streckenlänge als sehr ungenau herausgestellt.
GoogleEarth berechnet ca. 3430m (per Handberechung überprüft)
Meine Programm berechnet 1650m
Auf kurzen Strecken ist der Unterschied noch nicht so groß. Aber auch inakzeptabel! (Schlechte Werte des GPS-Moduls sind schon gefiltert und können also nicht zu Fehlberechnungen führen)
Meine Fragen nun:
Wie kann ich meine Berechnung verbessern?
Kann es überhaupt sein, dass durch ungenaue Positionsangaben des GPS-Moduls (gehe von ca. 5 m / Messung aus) ein solch großer Unterschied entsteht? (Fehler sollten sich doch positiv/negativ die Waage halten)
Falls es sein kann, soll ich dann die Messungen nur alle 20 sek durchführen, um die Messfehler pro Messung zu minimieren?
Soll ich die Haversine Formel benutzen (ist doch zu aufwendig für kleine Berechnungen)?
Wie kann ich sonst das Problem angehen?
Hoffe, dass ich mein Problem gut genug erklärt habe.
Vielen Dank im Voraus!
Gruss,
Thomas
Hallo Thomas,
ohne Programmcode gleicht die Fehlersuche einem Lesen im Kaffesatz. Späßchen.
Nach meiner Meinung kann es an GPS nicht liegen, d.h. auch nicht am Empfänger.
Wie berechnest Du denn die Koordinatenunterschiede und die Teilstreckenlänge ?
Grüße Roland
ohne Programmcode gleicht die Fehlersuche einem Lesen im Kaffesatz. Späßchen.
Nach meiner Meinung kann es an GPS nicht liegen, d.h. auch nicht am Empfänger.
Da kommen wir der Sache vielleicht näher.Soll ich die Haversine Formel benutzen
Wie berechnest Du denn die Koordinatenunterschiede und die Teilstreckenlänge ?
Grüße Roland
- KoenigDickBauch
- Beiträge: 303
- Registriert: 25.01.2007 - 21:59
Re: Streckenlänge berechnen (für Jogginganwendung)
Wenn die Stützstellen nur alle 10sec genommen werden ist ein solch schlechtes Ergebnis zu erwarten.Thomas hat geschrieben:Zur Zeit führe ich eine Berechnung der Länge zwischen zwei Koordinaten alle 10 sek durch (mit einfachem Pythagoras, da keine Erdkrümmung zu erwarten ist und addiere diese auf, um die Gesamtstreckenlänge zu bekommen. Nach der Überprüfung der Strecke mit GoogleEarth hat sich die berechnete Streckenlänge als sehr ungenau herausgestellt.
Ein extremes Beispiel: Lassen wir mal Bop Beaman den 200m Stadion Kreis laufen. Und er ist auch für ihn unwahrscheinlich in 20sec einmal rum, so könnte die 10Sec Messung im schlechtesten Fall nur ein hin und her von jeweils 40m messen. 80m/20sec das schaff ich ja schon.
Also die Stützstellen müssen schneller kommen. 1sec wäre aus dem Bauch heraus schon besser. Ein andere Möglichkeit wäre die Stützstellen in eine Tschebischeff-Approximation zu stecken. Dann würde die Strecke ausgerundet und der Fehler wäre kleiner.
Meine Erfahrung mit Trackaufzeichnungen ist eigentlich eher, das die gemessenen Strecken länger sind als die Wahre! Das kommt daher das die GPS-Signale ein wenig springen. Daher muss man diese Signale in ein Filter stecken und da sind wir wieder beim Tschebischeff.
google mal ein wenig nach dem Herren.
KDB
- Hartmut
- Beiträge: 815
- Registriert: 25.05.2004 - 18:56
- Wohnort: Prachuab Khiri Khan 11°44'37"N 99°47'17"E
- Kontaktdaten:
moin,
mal kurz angedacht, machmal hat man auch ein vagabundierendes bit im quellcode. bist du sicher, das der in ordnung ist und dir auch die hardware keinen streich spielt. berühmtes beispiel ist da der rundungsfehler einiger cpu´s (waren das jetzt die 386er oder die 486er ???), war vor jahren ein riesen buh hai wegen.
bis denn
mal kurz angedacht, machmal hat man auch ein vagabundierendes bit im quellcode. bist du sicher, das der in ordnung ist und dir auch die hardware keinen streich spielt. berühmtes beispiel ist da der rundungsfehler einiger cpu´s (waren das jetzt die 386er oder die 486er ???), war vor jahren ein riesen buh hai wegen.
bis denn
ich bin zwar verantwortlich, für das was ich sage, aber nicht dafür, wie du es verstehst.
rechtschreibfehler sind gewollt und deswegen mit voller Absicht erstellt. wer welche findet, darf sie behalten, verschenken oder auch versteigern.
rechtschreibfehler sind gewollt und deswegen mit voller Absicht erstellt. wer welche findet, darf sie behalten, verschenken oder auch versteigern.
- KoenigDickBauch
- Beiträge: 303
- Registriert: 25.01.2007 - 21:59
Währen wir beim Topfschlagen, dann würde ich sagen: kaltHartmut hat geschrieben:moin,
mal kurz angedacht, machmal hat man auch ein vagabundierendes bit im quellcode. bist du sicher, das der in ordnung ist und dir auch die hardware keinen streich spielt. berühmtes beispiel ist da der rundungsfehler einiger cpu´s (waren das jetzt die 386er oder die 486er ???), war vor jahren ein riesen buh hai wegen.
Na das Problem tauchte doch nur bei ganz seltenen Rechenbeispielen auf, die meist konstruiert wurden, um dem Mitbewerber Knüppel zwischen die Beine zu werfen.
Bei den vielen Simulationsprogrammen, die ich geschrieben haben, lagen die Fehler nie am Prozessor, sondern an meiner eigen Nase.
Eine andere sehr gute Angleichung ist der Akima-Spline. Such mal nach "Akima interpolation track"
Thomas
- KoenigDickBauch
- Beiträge: 303
- Registriert: 25.01.2007 - 21:59
Hallo Roland,
Na da gibt es zwei Ansätze. Den Russischen und den Amerikanischen.
Der Russische Weg:
Man nehme 5 Mathematiker, sperre sie in Sibierien ein oder drohe damit und nach einem halben Jahr hat man eine analytische Herleitung, von ein paar Formeln, die man dann ineinander setzt.
Der Amerikanische weg:
Man lässt eine Gray ein halbes Jahr das Problem simulieren und hat dann eine Tabelle, in die man schaut.
Beim Russischen Weg werfe ich das Handtuch. Aber schauen wir uns dern Amerikanischen an.
Rechen wir uns auf dem AkimaSpline hinreichend genügende Stützstellen aus und wenn den Pythagoras dann an, wie schon weiter oben besprochen.
Gruß
Thomas
PS: An der Wortwahl erkennt man wie alt de Witz ist. Aber beim Projekt Giotto, wo ich ein wenig über die Schultern schauen durfte, habe ich diesen Unterschied mal richtig live sehen können.
So darf mich nur meine Frau nennen.Roland hat geschrieben:Hallo Herr der Ringe
Roland hat geschrieben:nach langem Zögern lege ich jetzt ein Geständnis ab:
Ich weiß auf Anhieb nicht, wie man aus den Approximationsansätzen die Bogenlänge ableitet - bzw. integriert.
Kannst Du - Entschuldigung: könnt IHR Nachhilfe geben ???
Na da gibt es zwei Ansätze. Den Russischen und den Amerikanischen.
Der Russische Weg:
Man nehme 5 Mathematiker, sperre sie in Sibierien ein oder drohe damit und nach einem halben Jahr hat man eine analytische Herleitung, von ein paar Formeln, die man dann ineinander setzt.
Der Amerikanische weg:
Man lässt eine Gray ein halbes Jahr das Problem simulieren und hat dann eine Tabelle, in die man schaut.
Beim Russischen Weg werfe ich das Handtuch. Aber schauen wir uns dern Amerikanischen an.
Rechen wir uns auf dem AkimaSpline hinreichend genügende Stützstellen aus und wenn den Pythagoras dann an, wie schon weiter oben besprochen.
Gruß
Thomas
PS: An der Wortwahl erkennt man wie alt de Witz ist. Aber beim Projekt Giotto, wo ich ein wenig über die Schultern schauen durfte, habe ich diesen Unterschied mal richtig live sehen können.
Hab Das Problem gelöst!
Hi @all,
vielen Dank für eure Hilfeversuche. Ich habe das Problem gelöst.
Der Fehler lag natürlich bei mir! Habe einfach nur bei der Berechnung der Längenangabe (in Meter) den Gradwert (d,dd) mit cos(Längengrad) * 111325 m Multipliziert. Richtig ist natürlich für Länge in Meter: Gradwert * cos(Breitengrad) * 111325 m .
Die Meterberechnung ist jetzt auf ca 1% der Strecke genau (oder besser).
Sorry! Trotzdem vielen Dank!
Gruss,
Thomas
vielen Dank für eure Hilfeversuche. Ich habe das Problem gelöst.
Der Fehler lag natürlich bei mir! Habe einfach nur bei der Berechnung der Längenangabe (in Meter) den Gradwert (d,dd) mit cos(Längengrad) * 111325 m Multipliziert. Richtig ist natürlich für Länge in Meter: Gradwert * cos(Breitengrad) * 111325 m .
Die Meterberechnung ist jetzt auf ca 1% der Strecke genau (oder besser).
Sorry! Trotzdem vielen Dank!
Gruss,
Thomas
- KoenigDickBauch
- Beiträge: 303
- Registriert: 25.01.2007 - 21:59
Re: Hab Das Problem gelöst!
Wie so oft sitzt der Fehler vor der Maschine.Thomas hat geschrieben:Der Fehler lag natürlich bei mir! Habe einfach nur bei der Berechnung der Längenangabe (in Meter) den Gradwert (d,dd) mit cos(Längengrad) * 111325 m Multipliziert. Richtig ist natürlich für Länge in Meter: Gradwert * cos(Breitengrad) * 111325 m .
Die Meterberechnung ist jetzt auf ca 1% der Strecke genau (oder besser).
Die 111325m irritieren mich ein wenig.
Daher das hier:
Code: Alles auswählen
function Distance(Lat1, Lon1, Lat2, Lon2: double): double;
var
e: double;
begin
Lat1 := Lat1 / 180 * Pi;
Lon1 := Lon1 / 180 * Pi;
Lat2 := Lat2 / 180 * Pi;
Lon2 := Lon2 / 180 * Pi;
if (abs(Lat1 - Lat2) < 1E-7) and (abs(Lon1 - Lon2) < 1E-7) then begin
result := 0;
end
else begin
try
e := ARCCOS(SIN(Lat1) * SIN(Lat2) +
COS(Lat1) * COS(Lat2) * COS(Lon2 - Lon1));
result := e * 6378137;
except
Result := 0;
end;
end;
end;
Thomas
- Hartmut
- Beiträge: 815
- Registriert: 25.05.2004 - 18:56
- Wohnort: Prachuab Khiri Khan 11°44'37"N 99°47'17"E
- Kontaktdaten:
Re: Hab Das Problem gelöst!
moin,
bis denn
erfahrungsgemäß sitzen 99% aller fehler zwischen den ohren und nicht unbedingt vor einer maschine.KoenigDickBauch hat geschrieben:Wie so oft sitzt der Fehler vor der Maschine.
bis denn
ich bin zwar verantwortlich, für das was ich sage, aber nicht dafür, wie du es verstehst.
rechtschreibfehler sind gewollt und deswegen mit voller Absicht erstellt. wer welche findet, darf sie behalten, verschenken oder auch versteigern.
rechtschreibfehler sind gewollt und deswegen mit voller Absicht erstellt. wer welche findet, darf sie behalten, verschenken oder auch versteigern.
- KoenigDickBauch
- Beiträge: 303
- Registriert: 25.01.2007 - 21:59
Stimmt.Roland hat geschrieben:wenn Thomas auf 1% hinkommt, braucht man über spezielle Ansätze, genaue Radien besser nicht zu diskutieren; es kann nur schlechter werden.
Na da ich kein russischer Mathematiker bin drückte ich mich vor der analytischen Berechnung des Integrals und habe dir nur den Numerischen gegeben.Roland hat geschrieben:Ich hatte wg. der Approximation von KDB nochwas mit "Integralen" erhofft ... Schwamm drüber.
Thomas