Bug report #4977

Wrong interpretation of Gauss-Krüger .prj files

Added by Otto Dassau about 12 years ago. Updated about 12 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Projection Support
Affected QGIS version:master Regression?:No
Operating System:Opensuse Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed
Crashes QGIS or corrupts data:No Copied to github as #:14764

Description

Hi,

I just got a Shape file created with ArcGIS. I imported it into GRASS and the boundaries fit with other aerial images I have. Then I loaded the file in QGIS (the data still fit), and saved the file with the context menu tool save as" as EPSG 31467. When I load that new file again, I have a shift of about 50 m in x direction and 150 in y direction.

Does anybody have a similar experience? I use QGIS 1.7.3 with GDAL 1.9.0. Together with the problems I currently have to display mapserver > 6 WMS data in EPSG 31467 I get the impression that there might be something wrong with the projection of Gauss-Krüger in QGIS.

The .prj file from ArcGIS looks like this:

PROJCS["DHDN_3_Degree_Gauss_Zone_3",GEOGCS["GCS_Deutsches_Hauptdreiecksnetz",DATUM["D_Deutsches_Hauptdreiecksnetz",SPHEROID["Bessel_1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Gauss_Kruger"],PARAMETER["False_Easting",3500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",9.0],PARAMETER["Scale_Factor",1.0],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]

The .prj file from QGIS looks like this:

PROJCS["DHDN_3_degree_Gauss_Kruger_zone_3",GEOGCS["GCS_DHDN",DATUM["D_Deutsches_Hauptdreiecksnetz",SPHEROID["Bessel_1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",1],PARAMETER["false_easting",3500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

The .qpj file from QGIS looks like this:

PROJCS["DHDN / 3-degree Gauss-Kruger zone 3",GEOGCS["DHDN",DATUM["Deutsches_Hauptdreiecksnetz",SPHEROID["Bessel 1841",6377397.155,299.1528128,AUTHORITY["EPSG","7004"]],TOWGS84[598.1,73.7,418.2,0.202,0.045,-2.455,6.7],AUTHORITY["EPSG","6314"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4314"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",1],PARAMETER["false_easting",3500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["X",NORTH],AXIS["Y",EAST],AUTHORITY["EPSG","31467"]]

Thanks for your help
Otto

crs_deprecated.patch Magnifier - patch to get non-deprecated crs entry first from queries to srs databases (5.36 KB) Etienne Tourigny, 2012-03-30 12:51 PM

Related issues

Related to QGIS Application - Bug report #5066: (regression) QGIS 1.7.* misdetects EPSG::25884 datasets a... Closed 2012-02-22
Related to QGIS Application - Feature request #4355: Performing deletion on layer with feature counts turned o... Closed 2011-10-06

History

#1 Updated by Jürgen Fischer about 12 years ago

QGIS only uses the CRS information to select a CRS from it's database (and adds a custom CRS, if it can find any). Which CRS did it select for your shape file?

#2 Updated by Otto Dassau about 12 years ago

Hi Jürgen,

Oh, I see. I didn't check that. QGIS loaded the ArcGIS layer with EPSG:2166 - Pulkovo 1942(83) / Gauss Kruger zone 3 (deprecated), that's why the export was shifted. Sorry, that was my fault. Although I wonder why does sth like that happen, that QGIS reads a EPSG 31467 .prj file coming from Esri software as a EPSG:2166? Could this be optimized. I mean Pulkovo 1942(83) used e.g. ellipsoid krass and not bessel.

Thanks for your help!

Regards
Otto

#3 Updated by Otto Dassau about 12 years ago

Hi Jürgen,

I tried with some layers exported from GRASS to Shape and have the same problem. QGIS loads all EPSG 31467 layers as EPSG:2166 - Pulkovo 1942(83) / Gauss Kruger zone 3 (deprecated). The .prj file created with GRASS looks like this:

PROJCS["Transverse_Mercator",GEOGCS["GCS_bessel",DATUM["D_Deutsches_Hauptdreiecksnetz",SPHEROID["Bessel_1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",1],PARAMETER["false_easting",3500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

Would it be possible to make some changes in QGIS, so the .prj files are better interpreted for Gauss-Krueger Projections?

Regards
Otto

#4 Updated by Otto Dassau about 12 years ago

  • Subject changed from Shift with Gauss-Krüger Projection to Wrong interpretation of Gauss-Krüger .prj files

Update of the topic

#5 Updated by Jürgen Fischer about 12 years ago

dassau - wrote:

Would it be possible to make some changes in QGIS, so the .prj files are better interpreted for Gauss-Krueger Projections?

Does the rpm package run crssync (like on debian and osgeo4w)? That syncs the database with the installed GDAL.
That might help - on debian unstable (i.e. GDAL 1.7.3) for instance the prj it identified as EPSG:31463 (the deprecated code for 31467).

#6 Updated by Otto Dassau about 12 years ago

thanks Jürgen, you are talking about QGIS trunk where you added a crssync tool - right? I have the problem in 1.7.3, so that won't help at the moment. But anyway, what would be the procedure, just adding to the spec file a

%post
/usr/lib/qgis/crssync

Regards
Otto

#7 Updated by Etienne Tourigny about 12 years ago

There is a problem in Master with the queries for the crs lookup, they return the deprecated value first, so that one is used.

For example, using the .prj file for EPSG:31468, the srs corresponding to 31464 (deprecated) is returned

sqlite> select * from tbl_srs where parameters='+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 +units=m +no_defs';
srs_id|description|projection_acronym|ellipsoid_acronym|parameters|srid|auth_name|auth_id|is_geo|deprecated
2644|DHDN / 3-degree Gauss zone 4 (deprecated)|tmerc|bessel|+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 +units=m +no_defs|31464|EPSG|31464|0|1
2648|DHDN / Gauss-Kruger zone 4|tmerc|bessel|+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 +units=m +no_defs|31468|EPSG|31468|0|0

The query should have "order by deprecated" (so the non-deprecated is returned first):

sqlite> select * from tbl_srs where parameters='+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 +units=m +no_defs' order by deprecated;
srs_id|description|projection_acronym|ellipsoid_acronym|parameters|srid|auth_name|auth_id|is_geo|deprecated
2648|DHDN / Gauss-Kruger zone 4|tmerc|bessel|+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 +units=m +no_defs|31468|EPSG|31468|0|0
2644|DHDN / 3-degree Gauss zone 4 (deprecated)|tmerc|bessel|+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 +units=m +no_defs|31464|EPSG|31464|0|1

Attaching a patch for qgscoordinatereferencesystem.cpp that adds "order by deprecated" to all sql statements involving 'parameters'.

This patch works for the problem at hand, but I haven't tested it in other contexts (the patch changes a few of the queries) and have not tested for any side effects like crs syncing, etc.

Also, Makefile in master should run the "crssync" tool when installing the crs.db file. Should I create a bug report for that?

#8 Updated by Etienne Tourigny about 12 years ago

The same patch applied to release-1_7_4 branch fixes the problem (the last hunk does not apply).

crssync must be called after install also, but this is not available in qgis-1.7, so what to do in this case?

#9 Updated by Jürgen Fischer about 12 years ago

  • Resolution set to fixed
  • Status changed from Open to Closed

Etienne Tourigny wrote:

The same patch applied to release-1_7_4 branch fixes the problem (the last hunk does not apply).

crssync must be called after install also, but this is not available in qgis-1.7, so what to do in this case?

applied in 157541ed2b025760e489dd47f7f8212fc60e3a8a and commit:807520a84243b7e03772496d2a834a28d6dc39f4

Also available in: Atom PDF