I've experimented with projections of shapes, used the official provided grid beta2007 for germany and noticed differences between transforming by double exporting over custom CRS in QGIS and ogr2ogr of around 0.8-1.0 metres...
Perhaps it's happening because of false strings... I don't see it :)

  1. Exporting I've got the following custom CRS DHDN GK3 with the grid (EPSG:31467):

    +proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +units=m +no_defs +nadgrids=X:\gridshift\BETA2007.gsb +wktext

    Exported the shape with this CRS, loaded it into QGIS and exported it again to an custom CRS ETRS89 / UTM zone 32N with leading 32 (EPSG:4647), this is also the project CRS, on-the-fly projection is enabled:

    +proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=32500000 +y_0=0 +ellps=GRS80 +units=m +no_defs +towgs84=0,0,0,0,0,0,0

  2. Doing the same thing shorter with ogr2ogr

    ogr2ogr -f "ERSI Shapefile" utm32.shp gk3.shp -s_srs "+proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +units=m +no_defs +nadgrids=X:\gridshift\BETA2007.gsb +wktext" -t_srs "+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=32500000 +y_0=0 +ellps=GRS80 +units=m +no_defs +towgs84=0,0,0,0,0,0,0"

Why does this happen?

1 Answer 1


There is/was a bug in gdal regarding nadgrids. A supposed workaround should be to add +nadgrids=@null to the part of the transformation without gsb file.




Another point of distortion is the missing height in "normal" reprojections. A point 10 metres above the ellipsoid A has different coordinates on ellisoid B than a point 200 metres above. It's just because the ellipsoids are not in parallel.That distortion gets greater the more reprojections you do.

  • I'll try that on monday on my workstation. I should have mentioned that I've got correct data from the geodata autority of Niedersachsen. In comparison the projection of ogr2ogr is right and the manual QGIS-result differs. The fact of the missing height is known here, but shouldn't matter in my region. I also thought grids for correction are a solution for this problem. @André personally: Did you study in Suderburg?
    – mdierks
    Commented Feb 8, 2013 at 16:01
  • I did some tests the same way you did, but only get 0.1mm offset with @null, the others align perfectly. Offset between EPSG:31467 and the beta-grid data is indeed about 1 meter. I'm not sure what you did in the first step: I took a GoogleMercator shape and saved at beta-grid. Did you reproject 31467 to beta-grid? Maybe a_srs would be better here. Or exchange the .prj/qpj file.
    – AndreJ
    Commented Feb 9, 2013 at 9:39
  • Yep, I reprojected the 31467 shp to 31467 with beta-grid over Save As... in the first place and yes there is the offset about 1 meter already. I tried to add +a_srs to the 31467 with beta-grid and added +nadgrid=@null to my UTM 32 with leading 32. But results are exactly the same. What do you mean by exchanging the projection file?
    – mdierks
    Commented Feb 11, 2013 at 7:35
  • If you reproject 31467 to grid, the coordintes change, e.g. 35000000 will change to 35000001 according to the beta-grid. You have to take the original GK3-shp and apply the beta-grid definition to it, leaving the coordinates untouched. The prj files are identical, the grid is declared in the .qpj file. But GDAL does not read that. Best way is to use ogr2ogr with the original shp and the paramters you used above. Then work on with the UTM data in QGIS.
    – AndreJ
    Commented Feb 11, 2013 at 8:07
  • By the way, always check which CRS QGIS does assign for a newly added layer. Sometimes it guesses wrong, and takes EPSG:31467 if you intend to use your user-defined CRS with beta-grid.
    – AndreJ
    Commented Feb 11, 2013 at 8:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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