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
[email protected]
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
_______________________________________________
Qgis-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-user
