Genauigkeit des Solver

[pfeffer]

warum nicht gleich den Code nehmen, den Engywuck verlinkt hat?

Das geht nicht so einfach mit der Breite... es gibt ja nicht nur Entfernungsmessungen entlang des Äquators oder genau auf einen der Pole zu.

Gruß,
Pfeffer.

 

[MiK]

warum nicht gleich den Code nehmen, den Engywuck verlinkt hat?

Ich wollte jetzt eigentlich nicht noch kurzfristig eine weitere Bibliothek einbinden.

Das geht nicht so einfach mit der Breite... es gibt ja nicht nur Entfernungsmessungen entlang des Äquators oder genau auf einen der Pole zu.

So hatte ich das auch nicht gemeint. Auf die Pole zu ist sowieso kein Einheitlicher Radius. Eigentlich gibt es auf der Erde auch kein Gebiet, in dem die Erdkrümmung dem Polradius entspricht. Von daher war meine Überlegung aber auch falsch.

Meine Überlegung war: In der Nähe des Äquators nehmen wir den Äquatorradius und je näher wir an den Pol kommen, desto mehr nähern wir uns dem Polradius. Das würde aber nur stimmen, wenn wir uns nur entlang der Breitengrade bewegen würden. Aber vielleicht wäre es trotzdem eine gute Näherung, bis wir etwas besseres eingebaut haben.

 

[Engywuck]

Ich wollte jetzt eigentlich nicht noch kurzfristig eine weitere Bibliothek einbinden.

Welche Art Probleme befürchtest Du?

Engywuck

 

[pfeffer]

hast Du die die Funktionen, die Engy... verlinkt hat angeguckt?
Es sind nur wenige. Entweder Du bindest die Bibkiothek ein, oder Du bastelst kopierst einfach den Berechnungscode daraus. Die "Bibliothek" enthaält praktsch nichts anderes (soweit ich das auf den ersten Blick gesehen habe), deswegen dürfte das einbinden oder code kopieren nicht so schweirig sein.


Gruß,
Pfeffer.

 

[MiK]

Habe es mir jetzt näher angeschaut. Scheint ja wirklich nicht viel mehr zu sein, als das was wir suchen. Werde es mir jetzt noch genauer anschauen und dann entscheiden, wie wir das am besten einbinden.

Hat jemand gesehen unter welcher Lizenz der Code steht? Das sollte vorher geklärt sein.

 

[pfeffer]

steht am Anfang jeder Quellcode-Datei: jeder darf damit machen, was er will.

Ich finde, in den Quellecode einen Link zur Quelle eine passende Ehre.

Gruß,
Pfeffer.

 

[MiK]

Was meint ihr? Sollen wir das ganze Paket einbinden oder nur das, was wir brauchen?

Wenn wir es komplett nehmen, haben wir halt einiges doppelt. Für GlobalCoordinates kann man z.B. genauso gut CWPoint nehmen. Ich würde vorschlagen nur Ellipsoid und GeodeticCalculator aufzunehmen und entsprechend anzupassen, dass es mit unseren Datentypen funktioniert.

 

[pfeffer]

Ellipsoid gibt es auch schon in meinen TransformCoordiante-Klassen irgendwo.

Ich bin dafür möglichst wenig Klassen zu haben, die das gleiche machen.

Gruß,
Pfeffer.

 

[MiK]

Ja, die sollte es auch tun. Man muss nur noch das flattening einbauen.

 

[pfeffer]

das ist schon drin. Es gibt einen entsprechenden Konstrukor, der aus Abflachung die kleine Halbachse berechnet.

 

[MiK]

Ich meinte, dass man das dann auch abfragen kann. Das wird für die Berechnung verwendet.

 

[MiK]

Wie war das? "Jeder darf das SVN mal kaputt machen."?

Ich habe die Algorithmen von Engywucks Link eingebaut. Bitte, bitte ausführlich testen!!!

Solche grundlegenden Umbauten wollte ich eigentlich vor der 1.0 vermeiden. Also bitte testet alles, wo es gebraucht werden könnte. Also z.B. Liste, Goto, Karte, Projektion. Nicht nur den Solver.

 

[Engywuck]

Habs mal ausprobiert - ähnlich genau wie mit der alten Bibliothek.
Waaah, was sind wir doch deppert! Auf die einfachsten Lösungen kommt man wohl tatsächlich immer zum Schluß. Heute morgen im Auto auf dem Weg zum Kunden ist mir dann schließlich aufgefallen, dass 3 Minuten-Nachkommastellen ja nicht die maximal mögliche Präzision ist, die die Mathematik zur Koordinatenrepräsentation bereit hält. Und ein Konstrukt der Form project("N 50° 59.100 E 006° 58.000",33,1000) zeigt sicher irgendwo hin - aber nicht auf etwas, was sich ohne Fehler mit 3 Minutennachkommastellen darstellen lässt.
Und wie man sieht

x="N 50° 59.100 E 006° 58.000"
y="N 50° 59.101 E 006° 58.001"
distance(x,y)

2.230328294851

liegt die übliche Abweichung der einer Milliminute (hängt dann noch vom Winkel ab) im Meterbereich. Genau das, was wir auch beobachtet haben.

Also alles im grünen Bereich,
Engywuck

 

[MiK]

Das war der Fehler, den wir beobachtet haben, nachdem Du den Erdradius, der für Projektion und Distanzrechnung benutzt wird angeglichen hast. Vorher entstanden viel größere Fehler, da eben verschiedene Erdradien benutzt wurden. Jetzt wird ja wirklich ein Ellipsoid benutzt und nicht mehr eine Näherung durch eine Kugel.

Alles in allem sagt der Test mit distance und project im Solver aber nur aus, dass die beiden Funktionen konsistent zueinander arbeiten. Dadurch wissen wir immer noch nicht, ob die Ergebnisse richtig sind. Dazu müssen wir die Ergebnisse mit anderen Tools oder noch besser mit realen bekannten Werten vergleichen.

 

[MiK]

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.

Dazu ist mir gestern abend noch etwas eingefallen. Kann das denn überhaupt vernünftig funktionieren, wenn das Fünfeck auf einer Kugelfläche liegt? Kann man dort einfach mit den gleichen Winkeln rechnen, wie in der Ebene? Gerade, wenn ich mir das in der Nähe der Pole vorstelle, kommen mir da erhebliche Zweifel. Vielleicht hängt es aber davon auch gar nicht ab.

 

[Engywuck]

Alles in allem sagt der Test mit distance und project im Solver aber nur aus, dass die beiden Funktionen konsistent zueinander arbeiten.

Was ja schonmal eine wichtige Teilaussage ist.

Dadurch wissen wir immer noch nicht, ob die Ergebnisse richtig sind. Dazu müssen wir die Ergebnisse mit anderen Tools oder noch besser mit realen bekannten Werten vergleichen.

Das ist richtig, aber bislang gibt es auch keine Hinweise darauf, dass die Berechnungen nicht mit - für geocaching-Zwecke - hinreichender Genauigkeit durchgeführt werden.
Es gibt doch etliche GPS-Geräte, die Projektionen können (meins leider nicht). Dort einfach mal ein paar Testdaten eingeben und vergleichen - wenn hier keine substanziell anderen Werte rauskommen (die signifikant größer sind als der oben beschriebene Fehler), so würde ich die Berechnungen als hinreichend genau für unsere Zwecke betrachten.

Engywuck

 

[pfeffer]

@Engywuk: doch sie waren vor der Umstellung der Erdradien doch nicht allzugenau. Ich bin froh, dass das endlich genau ist.

Zum Testen:
Distanz kann man in GoogleEarth messen.
wahrscheinlich geht es auch mit dem GeoGrid-Viewer der Landesvermessungsämter?
Waren nicht Testdaten auf der Seite, auf der auch der java-Code war irgendwo?

Gruß,
Pfeffer.

 

[pfeffer]

ich habe mal mit GoogleEarth verglichen.
dist("N 53.094852 E 8.799601", "N53.095585 E 8.798668") gibt in CacheWolf in der neusten Version (r1349) 102,76543245951753 (in java), während dasGoogleEarth-Lineal auf 103,10 Meter kommt. das sind immerhin 33cm Abweichung auf ca. 100m ist weniger als 1%, aber mehr als 1 Promille und nicht wirklich toll :-(

In der Relation ist dist("N 53.079445 E 8.802699", "N 48.152120 E 11.552876") schon besser.
in CacheWolf: 581,5411905410334 km
in GoogleEarth:581,54549 km
also 4,2994589666m unterschied auf ca. 600km, also einem relativen Fehler von ca. 7 ppm.
in Map24: 581,34km (in Luftbild die Kirchtumspitze identifiziert, weil man dort keine Kooridunaten eingeben kann)

Ich finde 7 ppm das ist akzeptabel, aber mehr als 1 Promille ist nicht so schön. Vielleicht können andere da auch noch tests machen. Wenn es auf den kurzen Distanzen (sagen wir bis 2km) nicht mehr als 50 cm sind, könnte man es noch ok finden, finde ich

Gruß,
Pfeffer.

 

[MiK]

Mit allem, was unter einem Meter bleibt können wir gut leben. Wobei wir natürlich auch keine Ahnung haben, wie GoogleEarth rechnet. Theoretisch kann das ja genauso schlimm sein, wie unser alter Ansatz...

 

[maierkurt]

Mit allem, was unter einem Meter bleibt können wir gut leben.

Genauigkeit ist sicher immer wünschenswert, aber:

Wobei wir natürlich auch keine Ahnung haben, wie GoogleEarth rechnet.

So sieht es aus. Am besten wäre doch mal ein Vergleich mit den kommerziellen GPS-Geräten. Ich meine, wie wird denn so ein Projektions-Cache angelegt? Die meißten Owner benutzen doch wahrscheinlich Garmin und Konsorten. Wenn jetzt CW 1a rechnet, die Vielzahl an Caches aber mit "ungenauen" Berechnungen gelegt werden, ist es doch auch wieder nicht so toll.

Gruß, maierkurt