3

I'm having a QGIS project in local coordinates (Gauss-Kruger, EPSG:3399) with some layers in the same reference system. On top of that, I want to display point coordinates, which I digitized using google maps, so I assume them to be in Pseudo-Mercator/ WGS84 (EPSG:3857).

Now, when I add the point coordinates, they won't show up in the map. If I change their reference to EPSG:4326, they are displayed, but they have a mismatch of more than 150 meters.

In addition, I loaded a WMS layer, in WGS84 (EPSG:4326) which fits fine with the point coordinates but also does not align with the other layers from the project.

I included a partial view of the project, where you can see the misalignment. The overlay shows a river obtained from a DTM (in local coordinates) in blue. The displacement with the river in the orthoimage is clearly visible. The green points are the ditigized ones, as said above.

I am aware, that the on-the-fly transformation in the GIS might not be able to get me the exact match between local coordinates and global WGS-coordinates. But somehow I need to get the local coordinates from the point locations without having to digitize them again, because I am also missing georeferenced orthoimages in the local coordinates.

Any ideas how to handle this?

Alignment of point coordinates example

  • 1
    Note that projection conversions and transformations are somewhat distinct operations. A transformation is required when datasets are using a different datum, as I believe yours are. Since your two WGS84 layers line up (I think?) but your other layers don't, it sounds like you haven't specified any or the correct transformation to use. See bottom of docs.qgis.org/2.2/en/docs/user_manual/working_with_projections/… – Chris W Apr 7 '15 at 23:23
  • Not sure if I get you right. If I define a CRS for a layer in QGIS, it should have complete transformation information in the projection string. – tareq Apr 8 '15 at 20:03
  • Per Andre's answer, apparently not. The way I understand it, QGIS either uses the one specified or a default if one isn't. You can set it to always prompt if undefined (per my link above), which is recommended. – Chris W Apr 8 '15 at 20:19
3

In QGIS, the projection string for EPSG:3399 is:

+proj=tmerc +lat_0=0 +lon_0=15 +k=1 +x_0=5500000 +y_0=0 +ellps=bessel +units=m +no_defs

This projection string has no datum shift +towgs84, which I would expect for every transformation from the German DHDN/bessel to the WGS ellipsoid. See this page in German for more information on official transformation parameters: http://www.landesvermessung.sachsen.de/inhalt/etrs/method/method.html

  • 1
    The 7par transform from EPSG:31469 are +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 – Mike T Apr 8 '15 at 5:32
  • 1
    These are for whole Germany. Better regional values can be found here (in German): forum.openstreetmap.org/viewtopic.php?id=12723 – AndreJ Apr 8 '15 at 5:46
  • Ok, thanks everyone for the information. It was quite confused but the point really just seems to be, there are the transformation parameters missing, as you pointed out. So what I finally did is using EPSG:31469 instead of EPSG:3399. It has the same parameters but +towgs84 included as well (still using the standard values given by @MikeT which are included in QGIS). That way my point coordinates seem to align with the wgs84 data correctly. I'll check for detailed accuracy. – tareq Apr 8 '15 at 21:13
  • The accuracy improves from around 3m to less than 1m. I guess you will not notice that with the raster resolution you have. – AndreJ Apr 9 '15 at 3:53

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.