Genauigkeit des Solver

klausundelke · 7 Apr. 2008

Wie genau rechnet eigentlich der Solver?
Ich hab da einen Cache vorbereitet und mir scheint das Ergebnis
doch etwas weit auseinander.
Vielleicht wirft da mal jemand einen Blick drauf.

Ich hab immer mit project(....) eine neue Koordinate ausgerechnet
und dann mit distance(...) wieder zurückgerechnet. Da sollte ja eigentlich
die gleiche Entfernung wie in der ersten Funktion rauskommen.
Tut es aber nicht und mir erscheinen die Abweichungen ziemlich groß.

Gruss
Klaus

salzkammergut · 7 Apr. 2008

Hallo Klaus,

ich habe gefunden dass die openmap Bibliothek, die CW für die Koordinatenberechnungen verwendet nicht besonders genau ist. Ausserdem rechnet sie nur mit floats. Normalerweise reicht aber die Genauigkeit für Geocacher aus.

Wenn Du z.B.folgenden Befehl im Solver eingibst:

Code:

x="N12 13.456 E 12 13.456"; distance(x,project(x,90,1000))

so sollte eigentlich das Ergebnis 1000 sein. Ich bekomme aber 1000,947. Bei anderen Winkeln, z.B. 45 Grad ist der Fehler noch deutlich größer.

Grüße
skg

P.S.: Wenn jemand eine bessere Java-Bibliothek für Projektionen kennt bitte melden.

pfeffer · 8 Apr. 2008

Die genaue Berechnung von Entfernungen ist leider eine schwierige Aufgabe. Wir verwenden eine Bibliothek, die offenbar nicht so genau arbeitet :-(
Einen beliebigen Pfad auf einer Ellipse - das ist keine leichte Aufgabe. Die Bibliothek rechnet die Entfernung auf einem Großkreis - was schon mal nicht genau ist (Man kommt, wenn man es richtig machen will um eine Reihenentwicklung oder ein iteratives Verfahren wohl nicht herum). Außerdem rechnet sie (wenn ich das richtig im Kopf habe) mit float (also mit 32 Bits), für eine gute Genauigkeit sind aber double (64 bit) notwendig.

In der Kartenkalibrierung wird eine sehr genaue Berechnung (mit double und reihenentwicklung) verwendet (die ich programmiert habe), aber es wird sicher noch einige Zeit dauern, bis wir sie überall einsetzen können (weil ich noch nicht ganz genau verstanden habe, wie diese Berechnung funktioniert ;-) ).

Gruß,
Pfeffer.

klausundelke · 8 Apr. 2008

salzkammergut schrieb:
Normalerweise reicht aber die Genauigkeit für Geocacher aus.

Na ja, je nach Gelände können 20m Abweichung schon ziemlichen Frust bedeuten...

pfeffer schrieb:
(die ich programmiert habe)

:shock: :shock: :shock: WOW

Danke jedenfalls für die Antworten, da muss ich den Suchradius am Ziel wohl etwas
erhöhen....

Gruss
Klaus

Engywuck · 8 Apr. 2008

Ich hab mal ein bisschen mit dem Formelschnipsel von Pfeffer rumgespielt. Bei mir liegen die Fehler immer um 1-3 Promille, was normalerweise für Geocachingzwecke ausreichen sollte. Wenn man natürlich jetzt kaskadiert die eine Berechnung auf der anderen aufbauen lässt, könnte es schon mehr werden...
(Kann sich aber auch aufheben: Hab mal im Quadrat gerechnet, da war dann die Entfernung zwischen Anfangs und Endpunkt tatsächlich 0...)

Grüße,
Engywuck

Was die Library angeht: Ist kein Mathematiker an Bord? ;-)

klausundelke · 8 Apr. 2008

Bei dem Cache oben geht es ja um ein Pentagon. Gegeben sind 2 Punkte einer Linie, die anderen Eckpunkte muss man sich ausrechnen. Ich hab halt in der ersten Näherung ausgehend von der gegebenen Linie einmal um die Runde gerechnet. Dabei summiert sich natürlich der Fehler. Daher wollte ich nur mal wissen, wie genau der Wolf eigentlich rechnet. Ich hab das jetzt schon umgebaut: Einmal linksrum, einmal rechtsrum und dann die Mittelwerte der beiden ermittelten Koordinaten. Das sollte auf jeden Fall genau genug sein.
(Nicht zur Strafe nur zur Übung ;-))

Gruss
Klaus

Engywuck · 8 Apr. 2008

Was ich mir an der Stelle überlegt hab: Man kann die Koordinaten doch in UTM-Koordinaten umrechnen. Und UTM ist doch (so wie ich das verstanden habe) ein normales Karthesisches Koordinatensystem, in dem man normal rechnen kann. In einem Pentagon mit 1 km Seitenlänge sollte die Erdkrümmung schließlich nicht so viel ausmachen ;-)
Zielkoordinaten dann wieder in WSG84 (oder wie das heisst) umrechnen, fertig ist die Laube...

Grüße,
Engywuck

MiK · 8 Apr. 2008

Ich nehme an in Bereichen, in denen die Erdkrümmung vernachlässigbar ist, ist auch der Fehler in der bisherigen Rechnung vernachlässigbar.

Engywuck · 8 Apr. 2008

Genau das war ja interessanterweise nicht der Fall. (Siehe Beispiel von Pfeffer)
Ich habs auch mal mit anderen Entfernungen ausprobiert (100 m, 10 m) - die Größenordnung des Fehlers war von der Entfernung unabhängig.

Grüße,
Engywuck

MiK · 8 Apr. 2008

Wenn das so ist, dann werden da ganz grobe Fehler gemacht. Das kann dann nicht an der Näherung der Erde als Kugel liegen. Und auch nicht an der Verwendung von floats. Außer es wurden dabei alle Regeln der Numerik missachtet.

MiK · 8 Apr. 2008

salzkammergut schrieb:
Wenn Du z.B.folgenden Befehl im Solver eingibst:

Code:

x="N12 13.456 E 12 13.456"; distance(x,project(x,90,1000))

so sollte eigentlich das Ergebnis 1000 sein. Ich bekomme aber 1000,947. Bei anderen Winkeln, z.B. 45 Grad ist der Fehler noch deutlich größer.

Mit dem Code habe ich gerade auch ein paar Tests gemacht. Aber irgendwann fiel mir auf:
Der Code sagt leider nur aus, dass es Fehler gibt. Aber nicht, ob diese jetzt in "distance" oder "project" liegen. Und auch nicht, wie groß sie wirklich sind. Dazu müsste man von einer der Funktionen wissen, dass sie 100% zuverlässig arbeitet. Theoretisch könnten die Fehler von "project" viel größer sein und nur durch ähnliche Fehler in "distance" kompensiert werden.

Engywuck · 8 Apr. 2008

Ich hab mal die Funktion "project" etwas verbessert. Hoffe ich ;-)
Meiner beobachtung nach sind die berechneten Distances etwas kleiner. In Revision 1343 könnt ihr das mal testen.

Grüße,
Engywuck

MiK · 8 Apr. 2008

Zumindest mit obigem Codeschnipsel reduziert sich so der Fehler auf konstant unter einem halben Meter. Ob das Ergebnis wirklich so genau ist müsste man mit einem anderen Tool testen, von dem man weiß, dass es akkurat arbeitet.

klausundelke · 8 Apr. 2008

Dann werd ich das heute abend auch mal testen. Mit einem halben Meter Abweichung
kann man sicherlich leben.

Gruss
Klaus

pfeffer · 8 Apr. 2008

Engywuck schrieb:
Was ich mir an der Stelle überlegt hab: Man kann die Koordinaten doch in UTM-Koordinaten umrechnen. Und UTM ist doch (so wie ich das verstanden habe) ein normales Karthesisches Koordinatensystem, in dem man normal rechnen kann. In einem Pentagon mit 1 km Seitenlänge sollte die Erdkrümmung schließlich nicht so viel ausmachen ;-)
Zielkoordinaten dann wieder in WSG84 (oder wie das heisst) umrechnen, fertig ist die Laube...

ne, geht leider nicht, jedenfalls nicht, wenn man es genau haben will. Einerseits stimmen die Entfernungen in UTM nur *einigermaßen* (genau können sie nicht für alle Punkte einer Karte gleichzeitig stimmen), andererseits stimmt auch die Nordrichtung und damit alle Winkel nicht genau -> wenn man es genau haben will, sind komplizierte Berechnungen unumgänglich.

Die Änderung, die Du eingecheckt hast, macht eine ältere von mir rückgängig (die ich offenbar versehentlich eingecheckt hatte...).
Ich hatte das damals gemacht, weil (wenn ich mich recht erinnere) die eingebundene Bibliothek die Erde als Kugel annimmt und dabei einen mir nicht einleichtenden Durchmesser verwendet hat. Den Durchmesser wollte ich (glaub ich) korrigieren.
Da aber die Bibliothek (jetzt) sowohl bei project alsauch bei Distanz verwendet wird (und sie selbst konsistent von einem komischen Erddurchmesser ausgeht), erzeugt hin- und herrechnen natürlich nur noch einen minimalen Fehler. Das Testen an Rechnern, die sicher korrekte rechnen ist daher unerlässlich.

Gruß,
Pfeffer.

MiK · 8 Apr. 2008

pfeffer schrieb:
Da aber die Bibliothek (jetzt) sowohl bei project alsauch bei Distanz verwendet wird (und sie selbst konsistent von einem komischen Erddurchmesser ausgeht), erzeugt hin- und herrechnen natürlich nur noch einen minimalen Fehler. Das Testen an Rechnern, die sicher korrekte rechnen ist daher unerlässlich.

Genau soetwas hatte ich ja befürchtet. Wenn Deine Variante die genaueren Ergebnisse liefert, sollten wir sie auch für die Distanz verwenden. Nur wie testen wir das jetzt? Ich kenne mehrere Tools, die Projektionen berechnen. Aber bei keinem könnte ich beschwören, dass es 100% richtig arbeitet.

MiK · 8 Apr. 2008

pfeffer schrieb:
Ich hatte das damals gemacht, weil (wenn ich mich recht erinnere) die eingebundene Bibliothek die Erde als Kugel annimmt und dabei einen mir nicht einleichtenden Durchmesser verwendet hat. Den Durchmesser wollte ich (glaub ich) korrigieren.

Wenn es nur darum geht eine Entfernung auf einer Kugel in den Winkel auf einem Großkreis in Radiant umzurechnen, warum dann so kompliziert? Man muss doch nur die Entfernung durch den idealisierten Erdradius teilen, oder?

Edit: Ich habe mir gerade mal die Bibliothek angeschaut. Dort wird immer der Äquator-Durchmesser genommen. Wenn man schon als Kugel vereinfacht, sollte man wenigstens einen vernünftigen Mittelwert nehmen.

pfeffer · 8 Apr. 2008

MiK schrieb:
Edit: Ich habe mir gerade mal die Bibliothek angeschaut. Dort wird immer der Äquator-Durchmesser genommen. Wenn man schon als Kugel vereinfacht, sollte man wenigstens einen vernünftigen Mittelwert nehmen.

jetzte weißt Du genau, warum ich das geändert hatte

Gruß,
Pfeffer.

Engywuck · 8 Apr. 2008

Vielleicht hat jemand Lust, sich hier einzulesen...?
http://tinyurl.com/3swudm

Grüße,
Engywuck

MiK · 8 Apr. 2008

pfeffer schrieb:
MiK schrieb:

Edit: Ich habe mir gerade mal die Bibliothek angeschaut. Dort wird immer der Äquator-Durchmesser genommen. Wenn man schon als Kugel vereinfacht, sollte man wenigstens einen vernünftigen Mittelwert nehmen.

Zum Vergrößern anklicken....

jetzte weißt Du genau, warum ich das geändert hatte

Ich werde da nachher mal etwas vernünftiges basteln, dass in beiden Fällen den gleichen Radius nimmt. Vielleicht kann man den sogar per Interpolation aus der geografischen Breite bestimmen. Dann hat man überall eine vernünftige Näherung.

Genauigkeit des Solver

Geowizard

Geomaster

Geowizard

Geowizard

Geowizard

Geowizard

Geowizard

Geoguru

Geowizard

Geoguru

Geoguru

Geowizard

Geoguru

Geowizard

Geowizard

Geoguru

Geoguru

Geowizard

Geowizard

Geoguru