3

I encountered a strange behaviour in Openlayers(2) while transforming a point from EPSG:4326 to EPSG:31467.

The Input lat/lon in EPSG 4326 is: 48.002718, 7.841573

This is the output in Openlayers:

OpenLayers with latest proj4.js: EPSG 31467: 3413629.117584194 5318941.910572025

https://jsfiddle.net/cag5n970/4/

OpenLayers with proj4.js 1.1.0: EPSG 31467: 3413629.117584194 5318941.910572027

https://jsfiddle.net/cpwqA/75/

This is the output of epsg.io:

enter image description here

With different desktop-GIS-systems I also get the correct coordinates:

GlobalMapper: EPSG 31467: 3413632.71674 5318940.01018

FME: EPSG 31467: 3413632.7176193688 5318940.0085047819

ArcGIS: EPSG31467: 3413633,330872 5318935,858400

OpenJump: EPSG31467: 3413633.0419754055 5318938.324243281

QGIS: EPSG31467: 3413633.35 5318938.35

Here you can see the shift of up to 7.5 meters between the transformed OpenLayers coordinate and the result of the other transformations:

enter image description here

Any idea why Openlayers or the used proj4.js has a wrong output of the transformation?

  • Is one or other transform omitting the datum transformation from WGS84 spheroid to Bessel 1841? cs2cs gives me 3413633.36 5318938.36, but if I tell it to assume that the inputs are already on the Bessel spheroid, I get 3413567.63 5318836.81 instead. Mind you, that's a distance of 139 metres, which is rather larger than the error you are seeing. – Toby Speight Dec 2 '16 at 14:39
  • I think it's likely that the software packages are using different transformations. epsg.io, for 31467 is using EPSG::1777, DHDN to WGS 84 (2). I can't see how to reset the default transformation there, but didn't look very hard. – mkennedy Dec 2 '16 at 18:33
  • 1
    Possible duplicate of gis.stackexchange.com/questions/120754/… . The datum shift oft potsdam datum has been changed inside proj.4 in 2012. And if you want it really exact, you should take a datum shift grid. – AndreJ Dec 5 '16 at 10:05
4

I solved the problem by using a custom proj4.js definition for EPSG:31467.

I replaced "+datum=potsdam" with

"+towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70" to achieve a 7 parameter Helmert Transformation instead of the used simple 3 parameter translation:

proj4.defs["EPSG:31467"] = "+proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70 +units=m +no_defs";

// instead of   
//proj4.defs["EPSG:31467"] = "+proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +datum=potsdam +units=m +no_defs";

Now the transformation has the same output like QGIS: enter image description here

https://jsfiddle.net/wecsoo3x/1/

  • 1
    GDAL 2.2.0dev comes with this Proj.4 string # DHDN / 3-degree Gauss-Kruger zone 3 <31467> +proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +datum=potsdam +units=m +no_defs <> with no +ellps=bessel and without +towgs84. – user30184 Dec 5 '16 at 12:31
  • proj4.defs["EPSG:31467"] = "+proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +datum=potsdam +units=m +no_defs"; does not lead to the "better" result – markgraeflerland Dec 5 '16 at 12:47
  • No better than what? The original one or the one you got with the +towgs84 fix? – user30184 Dec 5 '16 at 12:54
  • @user30184 the result is the same as with the default OpenLayers transformation. It seems as if towgs84 is missing only a 3 parameter spatial translations is used – markgraeflerland Dec 5 '16 at 13:23
  • 1
    There seems to be mismatch between the epsg file that has been delivered with my GDAL installation and the parameters which are really used. Gdalsrsinfo gdal.org/gdalsrsinfo.html gives the same string that you have used PROJ.4 : '+proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel + towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 +units=m +no_defs ' – user30184 Dec 5 '16 at 13:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.