Genaue proj4 Definition EPSG 31466 (Gauß Krüger)

Ich bräuchte Hilfe bei der Umwandlung von Vektordaten. Ich arbeite gerade mit EPSG 31466 Daten also Gauß Krüger Zone 2.
Die habe ich bisher einfach in QGIS geladen (sie sind in einer Postgis DB) und dann dort in andere Formate umgewandelt (900913 oder 4326)
Bisher habe ich mir da auch noch keine weitere Gedanken gemacht.

Heute habe ich mal nicht die Daten in Qgis sondern über postgis mit der ST_Transform Funktion umgewandelt.
Dabei habe ich einen Versatz gegenüber den gleichen in qgis gewandelten Daten festgestellt um etwa 8 Meter
Ich habe mir jetzt mal einige proj4 Definitionen angesehen, die in den Programmen verwendet werden:

POSTGIS: +proj=tmerc +lat_0=0 +lon_0=6 +k=1 +x_0=2500000 +y_0=0 +ellps=bessel +datum=potsdam +units=m +no_defs
QGIS: +proj=tmerc +lat_0=0 +lon_0=6 +k=1 +x_0=2500000 +y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 +units=m +no_defs
MAPSERVER: +proj=tmerc +lat_0=0 +lon_0=6 +k=1 +x_0=2500000 +y_0=0 +ellps=bessel +towgs84=582,105,414,1.04,0.35,-3.08,8.3 +units=m +no_defs

Dabei produzieren Mapserver und Qgis fast das gleiche Ergebnis (ca 40cm Abweichung) , die Umwandlung mit Postgis liefert aber tatsächlich 8m Abweichung, ersetze ich die von qgis verwendete 31466 Projektion mit einer benutzererstellten Projektion die Definition von Postgis, ist das Ergebnis wie zu erwarten identisch mit den von Postgis gelieferten Daten nach ST_Transform.

Welches Format ist den nun korrekt ? Kennt sich da jemand aus und kann mir helfen, 8m Unterschied ist mir doch etwas zu viel.

Hi,

oh, ist doch einfach, nimm doch das ‘potsdam’, welches am besten passt :wink:

grep potsdam /usr/lib/grass64/etc/datumtransform.table
potsdam “towgs84=612.4,77.0,440.2,-0.054,0.057,-2.797,2.55” “Germany (Sachsen)” “Accuracy <1m”
potsdam “towgs84=599.4,72.4,419.2,-0.063,-0.022,-2.723,6.46” “Germany (Thüringen)” “Accuracy <1m”
potsdam “towgs84=590.5,69.5,411.6,-0.796,-0.052,-3.601,8.30” “Germany (West - North - 52d20’N to 55d00’N)” “Accuracy <1m”
potsdam “towgs84=584.8,67.0,400.3,0.105,0.013,-2.378,10.29” “Germany (West - Middle - 50d20’N to 52d20’N)” “Accuracy <1m”
potsdam “towgs84=597.1,71.4,412.1,0.894,0.068,-1.563,7.58” “Germany (West - South - 47d00N to 50d20’N)” “Accuracy <1m”
potsdam “towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70” “Germany (Whole Country)” “Accuracy 3m”

Ciao,
Frank

In der Wikipedia zur Helmert-Transformation hab ich den Link zum BKG gefunden. Das sollte auf 3m genau sein (plus der Ungenauigkeit ETRS89 zu WGS84, also sagen wir “4m”) und vor allem ist es “amtlich” :wink: entspricht der unteren Zeile von Franks Beitrag.

Danke für die Infos, das ist auch die Zeile von Qgis … also ist dann wohl Postgis tatsächlich recht ungenau. Ich werde dann mal gleich in der Postgis Geo Tabelle mit den Definitionen (“spatial_ref_sys”) den proj4 String anpassen.

Hi,

hab’ noch ein bischen rumgestöbert, es ist eigentlich nicht postgis, welche so ungenau ist, sondern die
libproj, die von postigis wohl verwendet wird.
Dort finden wir in “pj_datums.c”
“potsdam”, “towgs84=606.0,23.0,413.0”, “bessel”, “Potsdam Rauenberg 1950 DHDN”,
welches hardcodiert mit eincompiliert wird: Supi :frowning:

Statt der vollen 7-parametrigen Helmerttrafo wird nur eine 3-paramet. Translation verwendet und so verwundert
die Ungenauigkeit nicht mehr allzusehr.

Ciao,
Frank

Ja per default wird das Datum aus libproj verwendet, da ja “+datum=potsdam” in der spatial_ref_sys steht.

Lässt sich aber einfach korrigieren indem man den Eintrag abändert mit


update spatial_ref_sys set proj4text = 
'+proj=tmerc +lat_0=0 +lon_0=6 +k=1 +x_0=2500000 +y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 +units=m +no_defs'
where srid = 31466;

Will man den noch genaueren Wert für die Region und nicht für ganz Deutschland, dann wählt man die Potsdam Parameter für die jeweilige Region, die du ja schon genannt hast

Hi,

hab’ jetzt mal im proj-trac ein ticket eröffnet bzgl. datum potsdam.

Wer’s noch genauer haben will, kann die sog. “BeTa2007”-Daten verwenden.
Statt
+datum=potsdam
dann
+nadgrids=./BETA2007.gsb
verwenden

Vgl. hierzu http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/de_dhdn2etrs_beta.php

Ciao,
Frank

So, letzten Monat wurde PROJ 4.8.0 released, ist jetzt drin:
proj-4.8.0/src/pj_datums.c:“potsdam”, “towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7”, “bessel”, “Potsdam Rauenberg 1950 DHDN”

Hi,

bin etwas neu bei dem Thema und hab die letzten Posts dazu verfolgt, da ich auch immer wieder mit den verschiedenen Transformationsparametern zu kämpfen habe. Hätte dazu auch noch eine konkrete Frage, wär schön wenn mir dazu jemand eine kurze Antwort geben könnte:

Heißt das, falls man verschiedene Transformationsparameter vorhalten will, mit denen die Daten je nach Gebiet oder Abdeckung transformiert werden sollen, müsste man sich dafür jeweils verschiedene Koordinatensysteme in der “spatial_ref_sys” anlegen, die bis auf die unterschiedlichen Transformationsparameter gleich sind?

:frowning:

Schöne Grüße,

Stefan

Hi,

bin etwas neu bei dem Thema und hab die letzten Posts dazu verfolgt, da ich auch immer wieder mit den verschiedenen Transformationsparametern zu kämpfen habe. Hätte dazu auch noch eine konkrete Frage, wär schön wenn mir dazu jemand eine kurze Antwort geben könnte:

Heißt das, falls man verschiedene Transformationsparameter vorhalten will, mit denen die Daten je nach Gebiet oder Abdeckung transformiert werden sollen, müsste man sich dafür jeweils verschiedene Koordinatensysteme in der “spatial_ref_sys” anlegen, die bis auf die unterschiedlichen Transformationsparameter gleich sind?

:frowning:

Schöne Grüße,

Stefan