[Bug][BE 1181] Projezieren im Löser [gefixt]

[Robin888]

Hallo allerseits!

Ich musste vorgestern im Feld feststellen, daß die Projektion im Löser seit neustem Fehlerhaft ist. Offenbar gibt es Probleme bei der Implementierung der Radians:

deg()
Koord="N 10 0.000 E 10 0.000"
bear(Koord, proj(Koord, 90, 1000))

Ergibt einen Kurswinkel von (ca.) PI/2°

deg()
Koord="N 10 0.000 E 10 0.000"
bear(Koord, proj(Koord, 180, 1000))

Ergibt einen Kurswinkel von (ca.) PI°

Es wird vor der Operation anscheinend der Gradwinkel in Radian umgerechnet, aber als Gradwinkel interpretiert.

Exakt das gleich passiert auch im RAD-Modus:

rad()
Koord="N 10 0.000 E 10 0.000"
bear(Koord, proj(Koord, PI/2, 1000))

ergibt (ca.) PI*(PI/180)

und

rad()
Koord="N 10 0.000 E 10 0.000"
bear(Koord, proj(Koord, PI/2, 1000))

ergibt (ca.) PI/2*(PI/180)

Das heißt: Die Änderung der Winkelmodus ändert die Funktionsweise der Projektion nicht!

Außerdem ist die Fehlermeldung im RAD-Modus falsch:

"Winkel muss im Bereich [0;360] sein"

es müsste heißen:

"Winkel muss im Bereich [0;2*PI] sein"

Im Recher tritt dieses Problem nicht auf! (Das habe ich aber erst gestern herausgefunden. :-/)

P.S.: Wieso sind die Kurswinkel eigentlich nicht (wertmäßig) die eingegebene Winkel?

Robin(888)

 

[MiK]

Was meinst Du mit "Kurswinkel"?

Wie hast Du das Ergebnis überprüft?

Gib doch mal die Ergebnisse Deiner Projektionen mit an.

 

[Robin888]

Was meinst Du mit "Kurswinkel"?

Der Kurswinkel ist genau das, was bearing() ausrechnen soll:
Der Winkel im (sphärischen) Dreieck <(WP1,WP2,TN) in WP1. Also der Winkel gegen den geographischen Nordpol, unterdem man von WP1 zu WP2 gelangt.

Aber ich habe grad mal nachgerechnet: Die Abweichung beträgt bei 180° bzw PI etwa 0,084%, ist also wohl bloß die Summe der Rundungsfehler.

P.S.: Was mich dennoch mal persönlich interessieren würde ist, wie CacheWOlf diese Dinge (proj(), bear(), dist()) tatsächlich berechnet! Geht ihr von einer perfekten Kugel (Durchmesser?) aus, oder einem Ellipsoiden (Formeln?), wird die Präzision berücksichtigt?

Robin(888)

 

[MiK]

Ah, ok... ich hatte Deinen Code nicht genau gelesen und nicht gesehen, dass Du da bearing und project geschachtelt hattest.

Aber wenn der Fehler jetzt so gering ist, dann ist es ja nicht so schlimm.

Zu genauen Berechnung sagt am besten skg etwas. Aber die Präzision wird bestimmt nicht beachtet, weil wir wohl immer mit geographischem und nicht magnetischem Norden rechnen.

 

[Christian und die Wutze]

Äh, ist eventuell Präzession gemeint? Präzise sollten alle Rechnungen sein.

 

[MiK]

Ich geb ja zu: Ich hab es einfach nur abgeschrieben und nicht nochmal drüber nachgedacht. Hat die Präzession überhaupt etwas mit der Nordrichtung zu tun?

 

[Robin888]

%-) Asche auf mein Haupt! Ich meinte Deklination, aber auch die hat nur bei magnetischen Hilfsmitteln eine Bedeutung.

Bleibt die Frage, auf welchen geometrischen Objekt die Berechnungen stattfinden.

Und natürlich das eigentliche Thema: Der fehlerhafte proj()-Befehl!
Zur Übersicht:

Der proj()-Befehl im Löser wandelt die Winkel-Angabe grundsätzlich im Radian um, behandelt diesen Wert aber weiter als Grad!

Robin(888)

 

[salzkammergut]

Danke für den Hinweis auf den Bug. Sollte jetzt funktionieren.

Was mich dennoch mal persönlich interessieren würde ist, wie CacheWOlf diese Dinge (proj(), bear(), dist()) tatsächlich berechnet! Geht ihr von einer perfekten Kugel (Durchmesser?) aus, oder einem Ellipsoiden (Formeln?), wird die Präzision berücksichtigt?

Cachewolf benutzt die Openmap Bibliothek. Bei der Doku der "LatLonPoint"-Klasse steht unter "getPoint" Find a LatLonPoint a distance and direction away from this point, based on the spherical earth model. Außerdem rechnet sie mit "float" und nicht mit "double" und verliert dadurch etwas an Genauigkeit.

Der CW-Code, der diese Bibliothek aufruft, ist schon sehr alt und ich werde ihn bei Gelegenheit überprüfen. Bei den kurzen Distanzen über die aber beim Cachen normalerweise projiziert wird, sollten sich die Fehler aber in Grenzen halten.

Gruß
salzkammergut

 

[Robin888]

Ah, danke für die Info! Dann werde ich die Ausgabe doch lieber mit Vorsicht genießen. ;-) Aber stimmt natürlich: Für die praktischen Zwecke wird es reichen. (Ich bin halt Mathematiker.)

Aber gerade bei transzendenten Funktionen wäre ein Umgang mit Doubles wünschenswert. Mal sehen, ob es demnächst was neues zu berichten gibt. ;-)

Danke erstmal für die Behebung des Bugs. Ich werde es gleich mal ausprobieren!

Robin(888)