[GRASS-de] umrechnung von utm nach gk

Markus Neteler neteler at itc.it
Mo Jan 27 08:47:11 CET 2003


Hallo Oliver,

On Mon, Jan 27, 2003 at 07:04:59AM +0100, Otto Dassau wrote:
> Hallo Oliver,
>  
> > Ich hab' ein kleines Problem mit dem Befehl m.proj (interaktives
> > Umrechnen von Koordinaten). Ich hab einen Ausschnitt einer TK25 gescannt
> > und georeferenziert. Weil die Karte ein UTM Gitternetz aufweist (und nur
> > kleine GK Striche am Rand), hab ich die Ziellocation als UTM Location
> > eingerichtet. Nun brauch ich aber einige GK Koordinaten und dachte, dass
> > ich diese mit m.proj umrechnen könnte. Und hier liegt das Problem, denn
> > die Werte weichen um einige 100 meter ab??
> > 
> > Hier die meiner Meinung korrekten Werte, die ich mit einem kleinen
> > Windowsprogramm ermittelt habe (TRANSDAT, Fa. C. Killet
> > Softwareentwicklung):
> 
> Ich habe das Transdat auch schonmal verwendet, und kann mich daran
> erinnern, dass ich dort anfangs falsche Ergebnisse bekam, die auch um
> einige 100m abwichen, von den G-K Kreuzen in der Karte (mit denen hast du
> deine m.proj Werte bestimmt verglichen, oder?)

[...]

es gibt einen wichtigen Unterschied bei GRASS zu beachten: GRASS 5.0.0
macht keine Datumstransformation. Daher kann die Abweichung stammen.

Die gute Nachricht: Gestern wurde die Unterstuetzung fuer
Datumstransformation ins CVS gesteckt, Eric Miller und Paul Kelly
haben sich damit beschaeftigt. Darauf haben wir viele Jahre gewartet!

Da es noch dauern wird, bis eine offizielle Version herausgegeben wird, habe
ich 2 Scripte angehaengt, die UTM nach Gauss-Krueger transformieren (benutzt
cs2cs aus PROJ4). Die neuen GRASS-Routinen benutzen nun ebenfalls die
Datumstransformationsroutinen von PROJ4, damit sollten bei cs2cs und der
aktuellen CVS Version (u.a. wohl TRANSDAT) dieselben Ergebnisse rauskommen.
Allerdings sind im CVS erst s.proj, v.proj und r.proj auktualisiert,
m.proj/m.proj2 fehlen noch.

cs2cs hat einen Fehler von weniger als 10m (hier in Trento hatte ich 2m
Fehler bei einem Vergleich mit eingemessenen Punkten), besser wird TRANSDAT
vermutlich auch nicht sein.

Benutzung der Skripte (dazu wird PROJ von http://remotesensing.org/proj/
benoetigt):

utm2latlong.sh: 
           rechnet x y z in UTM/WGS84 nach Lat/Long um
latlong2gausskrueger.sh:
           rechnet x y z in Lat/Long nach Gauss-Krueger/Potsdam - DHDN um

Wenn nicht Potsdam - DHDN Datum gilt, muessen die Werte im Skript angepasst
werden. Auf der Karte sollte das Kartendatum angegeben sein.

Bei Fragen helfe ich gerne,

 schoene Gruesse

  Markus
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : utm2latlong.sh
Dateityp    : application/x-sh
Dateigröße  : 619 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.fossgis.de/pipermail/fossgis-talk-liste/attachments/20030127/5ad6024f/utm2latlong.sh>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : latlong2gausskrueger.sh
Dateityp    : application/x-sh
Dateigröße  : 969 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.fossgis.de/pipermail/fossgis-talk-liste/attachments/20030127/5ad6024f/latlong2gausskrueger.sh>