[Qgis-user] Annoying CRS-Problem with EPSG 31468 / 2167

Thu Mar 22 01:28:53 PDT 2012

Problem confirmed here

Example of prj file (produced by GRASS):
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",12],PARAMETER["scale_factor",1],PARAMETER["false_easting",4500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

QGIS loads this with EPSG:2167 which contains the following proj4 
parameters:
+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=krass 
+towgs84=26,-121,-78,0,0,0,0 +units=m +no_defs

whereas EPSG:31468 has:
+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel 
+towgs84=582,105,414,1.04,0.35,-3.08,8.3 +units=m +no_defs

The problem may be there are no explicit towgs84 parameters BUT there is 
a datum given in the prj file which other software translates into a 
towgs84 parameter and vice versa, QGIS does not.

probably related problem: 
http://osgeo-org.1560.n6.nabble.com/all-prj-files-broken-td4128672.html

To me it seems QGIS is fixed to the towgs84 parameter and does not take 
the datum parameter into account if the datum is defined in proj4
Furthermore when loading a layer it seems only the first parameters are 
compared to find a match and EPSG:2167 is the first one to match 
(obviously +ellps is not taken into account!)

If I save a EPSG:31468 layer to shape the prj file reads:
PROJCS["DHDN_3_degree_Gauss_Kruger_zone_4",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",12],PARAMETER["scale_factor",1],PARAMETER["false_easting",4500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

did not test what e.g. GRASS does with that

Bernhard

Am 21.03.2012 22:22, schrieb Ramon Andiñach:
> Hi there,
>
> It could be a .prj file problem, apparently arc can sometimes write .prj without a TOWGS84 tag, which confuses OGR, and hence confuses QGIS. For instance see: http://lists.osgeo.org/pipermail/qgis-user/2012-March/015993.html
>
> In master, OGR has been compiled to take a best guess and appropriate EPSG.
>
> In the meantime, on of the settings that I change straight up on my QGIS installs is Settings ->  Options ->  CRS tab ->  "Prompt for CRS"
> Which makes QGIS ask if it's not sure what the projection for a layer is.
>
> Hope that is of some help.
>
> -ramon.
>
>
> On 22/03/2012, at 24:07 , Bernd Vogelgesang wrote:
>
>> Hi there,
>> in Germany, we still quite often have Gauss-Krüger 4 projection for the source data from clients, formerly edited with ArcGIS.
>> QGIS obviously has some problems with GK4 (EPSG:31468)
>> When i import a shape with a .prj-file from ArcGIS, it doesn't promt for the crs, but immediately loads the shape.
>> The tricky think is: if you do not check the crs manually every time, you run into chaos, cause QGIS always sets the crs to "Pulkovo 1942(83) / Gauss Krueger zone 4 (deprecated)" (EPSG:2167) which has quite an offset to the other crs.
>>
>> I'm quite confident that it's not a problem of the prj-file from ArcGIS, cause when i import a GK4-Layer into GRASS, there set the crs to GK4 as well, do my stuff and then send it back the result to QGIS, there the former EPSG 31468-Layer again is set to EPSG 2167 too !!!
>>
>> Has anyone an idea how to prevent this or what's the reason for this?
>> It's really annoying and quite hard to explain to clients to check everytime the crs when they load a layer file.
>>
>> Greetz
>> Bernd
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
> ________ Information from NOD32 ________
> This message was checked by NOD32 Antivirus System for Linux Mail Server.
> http://www.nod32.com

________ Information from NOD32 ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com