Unterschied zw. project und distance

ergibt: 999.279033101978

Der Fehler variiert und beträgt meist 1m; auch bei kleineren Distanzen. Nicht weiter problematisch solange es um die Zielkoordinaten geht, da macht 1m mehr oder weniger nichts aus, aber wenn man mit den Werten weiter rechnet sieht es schon anders aus.

Interessant wäre natürlich auch, warum es überhaupt zur Differenz kommt, ich hätte jetzt gedacht, daß intern mit einheitlichem Formelsatz gearbeitet wird, hier scheinen aber zwei verschieden Modelle zum Einsatz zu kommen.

Ganz einfach: Die Ergebniskoordinate s2 ist wieder eine auf 3 Minutenstellen gerundete Gradangabe. Und eine tausendstel Minute macht ungefähr 1-2 Meter aus. Wenn also das Ergebnis der ersten Rechnung exakterweise heissen müsste "N 37° 42.1234 E ....", so rechnet er im zweiten Schritt mit "N 37° 42.123" weiter, was schon mal ein Startfehler von 0.0004 Minuten ist, also ungefähr in der von Dir beobachteten Größenordnung.
Wenn man mehrere Rechnungen hintereinanderschaltet, kann sich der Fehler hier natürlich summieren, erfahrungsgemäß ist die Größenordnung aber so klein, dass die Ungenauigkeit Deines GPS sowieso größer ist. Lohnt also nicht, jetzt über Heuristiken zu spekulieren, wann es sinnvoll ist, genau weiterzurechnen und wann nicht - außerdem hatten wir das schon mal in einem anderen Thread.

Gruß,
E.

@Engywuck

ah ok, daran habe ich nicht gedacht.
Wäre es nicht praktisch den Funktionen durch einen optionalen Parameter mitzuteilen, mit wie vielen Stellen gerechnet bzw. auch ausgegeben werden soll und wenn nicht angeben dann mit 3 Nachkommastellen.

Intern wird da überhaupt nicht mit Dezimalminuten sondern immer nur mit Dezimalgrad gerechnet. Es kann aber sein, dass der Solver an dieser Stelle das Ergebnis in der Variablen als String speichert. Das weiß ich nicht. Die eigentlichen beiden Berechnungen erfolgen auf jeden Fall mit dem gleichen Modell und in Dezimalgrad.