Ja es war spät gestern (nach Mitternacht) - und die Sache mit dem [/code] wusste ich nicht - müsste man vll. mal irgendwo vermerken, was man hier so alles mit eckigen Klammern anstellen kann...

Die Programmierung habe ich vor Ewigkeiten vorgenommen - so ganz weiß ich da also heute nicht mehr, was ich da alles im Einzelnen gemacht habe, damit es läuft. Ich weiß aber, daß es läuft...

Bsp. (aus der Top50-MV abgegriffen):

Neubrandenburg, TP "am Bunker" (unsereins weiß ja, wo das ist ):

3° Potsdam-Datum (= Bessel-Ellipsoid):
GK ; geographisch (Soll laut Top50) ; geographisch (Ist laut meinem TR)
4581441 ; 13,22919° ; 13,22918°
5936991 ; 53,55962° ; 53,55962°

6° 42/83 (= Krassowski-Ellipsoid):
GK ; geographisch (Soll laut Top50) ; geographisch (Ist laut meinem TR)
3382537 ; 13,22741° ; 13,22740°
5938294 ; 53,55806° ; 53,55806°

WGS84/ETRS89-Ellipsoid:
UTM ; geographisch (Soll laut Top50) ; geographisch (Ist laut meinem TR)
33382586 ; 13,22741° ; 13,22741°
5935821 ; 53,55812° ; 53,55812°

... und bei der Rückrechnung zurück in GK/UTM stimmt es dann auch wieder bis auf Zentimter.
Fazit: Irgendwas muss mein Programm richtig machen!!!

PS: Wegen dem C... Das ist, soweit ich das jetzt bei meinem eigenen Code nachverfolgen konnte, wohl nur bei Soldner wichtig (das kann mein TR-Programm auch) und bei GK und UTM anscheinend auf 0 gesetzt. Besagte erste lange Formel wird dann auch wieder 0 (nun als "neues" C abgespeichert) und hat somit offensichtlich bei GK/UTM gar keine Funktion.

Wie gesagt: Ist schon ein wenig her, daß ich das gemacht habe (daher auch meine eigene leichte Ratlosigkeit). Bei meinen Tests eben (auch mit 3-4 anderen Punkten) liefen GK und UTM jedenfalls...