I just tested with current trunk (compiled on OpenSUSE 64bit):
When I load
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]]
which is EPSG:31468 (proj4 params in QGIS: +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)
QGIS creates a user-defined srs:
+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
although there is a difference in towgs84 params the layer matches a
corresponding PostGIS layer defined with EPSG:31468 (I am aware there
exist different towgs84-parameter sets for this datum)
Same happens when saving as shape file from QGIS deleting the qpj file
and then reloading into QGIS, so QGIS is not able to correctly interpret
its own prj file!
The only way I found to get the shape file loaded as EPSG:31468 is
appending >>AUTHORITY["EPSG","31468"]<< to the prj file
PostGIS' spatial_ref_sys table contains the prj string (field srtext)
and the proj4 params (field proj4text) for the projection
srtext: PROJCS["DHDN / 3-degree Gauss-Kruger zone
4",GEOGCS["DHDN",DATUM["Deutsches_Hauptdreiecksnetz",SPHEROID["Bessel
1841",6377397.155,299.1528128,AUTHORITY["EPSG","7004"]],AUTHORITY["EPSG","6314"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4314"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",12],PARAMETER["scale_factor",1],PARAMETER["false_easting",4500000],PARAMETER["false_northing",0],AUTHORITY["EPSG","31468"],AXIS["Y",EAST],AXIS["X",NORTH]]
proj4text: +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0
+ellps=bessel +datum=potsdam +units=m +no_defs
remarks:
1) srtext contains >>AUTHORITY["EPSG","31468"]<<
2) proj4 says >>+datum=potsdam<< whereas srtext says
>>DATUM["Deutsches_Hauptdreiecksnetz"<<
What could help?
Somehow QGIS needs to use _all_ information given in the prj file and
find a matching srs(proj4 parameters) for that. If there are several
matching the user should choose which to apply, if there is none
matching create a user-defined srs with the parameters given but tell
the user. Maybe the datum parameter should be added to the proj4
definition of the projection. I am aware that a +datum parameter is only
a short for a +towgs84 parameter but the datum is the same for the
projection whereas towgs84 may differ locally.
Maybe in at most 5 years' time we won't need GAUSS-KRUEGER any more as
we are supposed to be switched to ETRS89 by then ;-)
Bernhard
Am 22.03.2012 19:23, schrieb Etienne Tourigny:
The following only applies to builds using master (and upcoming 1.8)
and gdal-1.9
Jeff pushed in master the fix which add missing TOWGS84 parameters (by
using GDAL_FIX_ESRI_WKT=TOWGS84). It is possible that using
GDAL_FIX_ESRI_WKT=GEOGCS would resolve this issue. Perhaps we couls
add an option for this, and set the default to GEOGCS?
how can I use this?
see bug http://hub.qgis.org/issues/5142
Is there a proper fix for this in 1.7.4?
Etienne
On Thu, Mar 22, 2012 at 12:35 PM,<bernhard.stro...@jena.de> wrote:
Am 22.03.2012 16:05, schrieb Bernd Vogelgesang:
So, the problem was now described thoroughly, but what are the
conclusions now?
There is already a ticket open http://hub.qgis.org/issues/4977
although I have no idea if the issue has been solved or not
I'm going to spread QGIS in my region in the next months, and it's quite
hard to explain to the people, who to 99% work with EPSG 31468-data,
that they can't ever rely on any data they produce and that they have to
double-check each layer after creation for the right CRS, even if they
set it correctly in each setting available?!?
I'm not too familiar with all those packages involved handling the CRSs,
so can someone please point me the way who to address with this problem?
For novice QGIS-users, this "bug" is a real exclusion criterion for QGIS
for they will only create crap with it!
Again my findings:
Options settings: new layers and projects are created with EPSG 31468,
promting for CRS ist set.
- EPSG 31468-Layers with a prj-file from ArcGIS get loaded as 2167
without promting for the CRS
- EPSG 31468-Layers loaded into a EPSG 31468-Region in GRASS are handed
back to QGIS as ... 2167
- New Layers created in some plugins (like some ftools-plugins), added
to the TOC, are in ... 2167 .. or even 3397
What can i do? (And i really wonder what all those other german users do
and why the don't complain...)
For me the base of the problem seems to be that the prj file is not matched
to the right EPSG srs. As soon as you tell the layer it is EPSG:31468 it is
positioned correctly. So the problem arises only with shapefiles; at my work
we use PostGIS for most of our data (that is of course no help for you but
explains why I am not "complaining")
Bernhard
Thanx for advice
Bernd
(QGIS 1.7.4, osgeo4w advanced install, Win7 64bit)
________ Information from NOD32 ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com
_______________________________________________
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user
