Discussion:
[Qgis-user] Re: Annoying CRS-Problem with EPSG 31468 / 2167: Conclusions?
Bernd Vogelgesang
2012-03-22 16:05:38 UTC
Permalink
So, the problem was now described thoroughly, but what are the conclusions
now?

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...)

Thanx for advice
Bernd


(QGIS 1.7.4, osgeo4w advanced install, Win7 64bit)
-------------- next part --------------
Skipped content of type multipart/related
bernhard.stroebl at jena.de ()
2012-03-22 16:35:45 UTC
Permalink
Post by 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
Post by Bernd Vogelgesang
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!
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
Post by Bernd Vogelgesang
Thanx for advice
Bernd
(QGIS 1.7.4, osgeo4w advanced install, Win7 64bit)
_______________________________________________
Qgis-user mailing list
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
Etienne Tourigny
2012-03-22 19:23:59 UTC
Permalink
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?

see bug http://hub.qgis.org/issues/5142

Is there a proper fix for this in 1.7.4?

Etienne
Post by bernhard.stroebl at jena.de ()
Post by 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
Post by Bernd Vogelgesang
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!
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
Post by Bernd Vogelgesang
Thanx for advice
Bernd
(QGIS 1.7.4, osgeo4w advanced install, Win7 64bit)
_______________________________________________
Qgis-user mailing list
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
http://lists.osgeo.org/mailman/listinfo/qgis-user
bernhard.stroebl at jena.de ()
2012-03-23 09:27:20 UTC
Permalink
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
Post by Etienne Tourigny
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
Post by 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?
Post by Etienne Tourigny
see bug http://hub.qgis.org/issues/5142
Is there a proper fix for this in 1.7.4?
Etienne
Post by 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
Post by Bernd Vogelgesang
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!
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
Post by Bernd Vogelgesang
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
Etienne Tourigny
2012-03-23 13:32:43 UTC
Permalink
Post by bernhard.stroebl at jena.de ()
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)
+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
1) srtext contains >>AUTHORITY["EPSG","31468"]<<
2) proj4 says >>+datum=potsdam<< whereas srtext says
Post by Etienne Tourigny
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
Post by 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?
Berhard, this is already in Master and 1.8. Can you try setting
GDAL_FIX_ESRI_WKT=GEOGCS in qgsogrprovider.cpp?

You can also play with the command line and see what comes up.

GDAL_FIX_ESRI_WKT=GEOGCS gdalsrsinfo file.prj
GDAL_FIX_ESRI_WKT=TOWGS84 gdalsrsinfo file.prj
GDAL_FIX_ESRI_WKT=NO gdalsrsinfo file.prj

although in this case I am afraid that gdal/ogr sees it as
Deutsches_Hauptdreiecksnetz

all the best,
Etienne
Post by bernhard.stroebl at jena.de ()
Post by Etienne Tourigny
see bug http://hub.qgis.org/issues/5142
Is there a proper fix for this in 1.7.4?
Etienne
Post by 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
Post by Bernd Vogelgesang
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!
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
Post by Bernd Vogelgesang
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
bernhard.stroebl at jena.de ()
2012-03-26 07:42:30 UTC
Permalink
Post by Etienne Tourigny
Post by bernhard.stroebl at jena.de ()
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)
+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
1) srtext contains>>AUTHORITY["EPSG","31468"]<<
2) proj4 says>>+datum=potsdam<< whereas srtext says
Post by Etienne Tourigny
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
Post by 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?
Berhard, this is already in Master and 1.8. Can you try setting
GDAL_FIX_ESRI_WKT=GEOGCS in qgsogrprovider.cpp?
Etienne,

thank you for your instructions
I replaced WGS84 in qgsogrprovider.cpp with GEOGCS (QGIS master)
result stays the same: User-defined srs with towgs84 params is applied
Post by Etienne Tourigny
You can also play with the command line and see what comes up.
GDAL_FIX_ESRI_WKT=GEOGCS gdalsrsinfo file.prj
PROJ.4 : '+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 '
Post by Etienne Tourigny
GDAL_FIX_ESRI_WKT=TOWGS84 gdalsrsinfo file.prj
PROJ.4 : '+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 '
Post by Etienne Tourigny
GDAL_FIX_ESRI_WKT=NO gdalsrsinfo file.prj
PROJ.4 : '+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0
+datum=potsdam +units=m +no_defs '

This would be my preferred parameters as datum=potsdam can be different
towgs84 parameters in different locations

However the problem persists that QGIS does not recognize the projection
as EPSG:31468 no matter if I set it to GEOGCS, TOWGS84 or NO!
Neiter does it detect the correct projction from the prj file QGIS
itself created.

Bernhard
Post by Etienne Tourigny
although in this case I am afraid that gdal/ogr sees it as
Deutsches_Hauptdreiecksnetz
all the best,
Etienne
Post by bernhard.stroebl at jena.de ()
Post by Etienne Tourigny
see bug http://hub.qgis.org/issues/5142
Is there a proper fix for this in 1.7.4?
Etienne
Post by 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
Post by Bernd Vogelgesang
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!
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
Post by Bernd Vogelgesang
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
--
Bernhard Str?bl
Anwendungsbetreuer GIS

Kommunale Immobilien Jena
Am Anger 26
07743 Jena

Tel.: 03641 49- 5190
E-Mail: ***@jena.de
Internet: www.kij.de



Kommunale Immobilien Jena
Eigenbetrieb der Stadt Jena
Werkleiter: Thomas Dirkes


________ Information from NOD32 ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com
Jürgen E. Fischer
2012-03-26 07:58:35 UTC
Permalink
Moin Bernhard,
Post by bernhard.stroebl at jena.de ()
thank you for your instructions
I replaced WGS84 in qgsogrprovider.cpp with GEOGCS (QGIS master)
result stays the same: User-defined srs with towgs84 params is applied
Just to be sure: You are using GDAL 1.9?


J?rgen
--
J?rgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstra?e 13 Fax. +49-4931-918175-50
Software Engineer D-26506 Norden http://www.norbit.de
IRC: jef on FreeNode committ(ed|ing) to Quantum GIS
--
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
bernhard.stroebl at jena.de ()
2012-03-26 08:32:33 UTC
Permalink
Post by Jürgen E. Fischer
Moin Bernhard,
Post by bernhard.stroebl at jena.de ()
thank you for your instructions
I replaced WGS84 in qgsogrprovider.cpp with GEOGCS (QGIS master)
result stays the same: User-defined srs with towgs84 params is applied
Just to be sure: You are using GDAL 1.9?
J?rgen
Moin moin,

this is GDAL 1.9.0-3.6 (OpenSUSE-repo)

I changed line 2103 of qgsogrprovider.cpp

Just to double check (I am not familiar with compiling software): I did
a git pull in branch master and followed the build instructions given
here:
http://hub.qgis.org/wiki/quantum-gis/Building_QGIS_from_Source#Building-on-GNULinux

Bernhard



________ Information from NOD32 ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com
Etienne Tourigny
2012-03-30 02:23:36 UTC
Permalink
Post by bernhard.stroebl at jena.de ()
Post by bernhard.stroebl at jena.de ()
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)
+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
1) srtext contains>>AUTHORITY["EPSG","31468"]<<
2) proj4 says>>+datum=potsdam<< ?whereas srtext says
Post by Etienne Tourigny
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
Post by 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?
Berhard, this is already in Master and 1.8. ?Can you try setting
GDAL_FIX_ESRI_WKT=GEOGCS in qgsogrprovider.cpp?
Etienne,
thank you for your instructions
I replaced WGS84 in qgsogrprovider.cpp with GEOGCS (QGIS master)
result stays the same: User-defined srs with towgs84 params is applied
You can also play with the command line and see what comes up.
GDAL_FIX_ESRI_WKT=GEOGCS gdalsrsinfo file.prj
PROJ.4 : '+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 '
GDAL_FIX_ESRI_WKT=TOWGS84 gdalsrsinfo file.prj
PROJ.4 : '+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 '
GDAL_FIX_ESRI_WKT=NO gdalsrsinfo file.prj
PROJ.4 : '+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0
+datum=potsdam +units=m +no_defs '
This would be my preferred parameters as datum=potsdam can be different
towgs84 parameters in different locations
How would this be decided? By the user or some magic way?

This sort of contradicts your statement that it should be recognized
as EPSG:31468 because that code is NOT potsdam datum (in GDAL/OGR
anyway)
Post by bernhard.stroebl at jena.de ()
However the problem persists that QGIS does not recognize the projection as
EPSG:31468 no matter if I set it to GEOGCS, TOWGS84 or NO!
Neiter does it detect the correct projction from the prj file QGIS itself
created.
The GEOGCS option to GDAL_FIX_ESRI_WKT fixes the GEOGCS authority
node, but not the root node which is a PROJCS (see example below)!
Trying to match all possible projections can be more challenging than
matching the possible geogcs definitions. It is possible, but I didn't
get there yet.

Just to make sure I understand - is the expected behaviour in QGis
(from you POV) to see the file as EPSG:31468 with the TOWGS84
parameters seen above? Or the more generic 'potsdam' datum?

===>
Perhaps QGis could be modified to scan existing proj4 definitions for
a match with the layer's proj4 string as Berhard suggests.
That should probably work in this case (because all that is missing is
the authority nodes - which is probably the comparison inside Qgis) -
am I right Jurgen?


Example of working GEOGCS detection:

$ GDAL_FIX_ESRI_WKT=GEOGCS gdalsrsinfo tmp1.prj

PROJ.4 : '+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 '

OGC WKT :
PROJCS["Transverse_Mercator",
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",12],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",4500000],
PARAMETER["false_northing",0],
UNIT["Meter",1]]

and compare with EPSG:31468, the GEOGCS node has correct authority (4314)

$ gdalsrsinfo EPSG:31468

PROJ.4 : '+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 '

OGC WKT :
PROJCS["DHDN / 3-degree Gauss-Kruger zone 4",
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",12],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",4500000],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["X",NORTH],
AXIS["Y",EAST],
AUTHORITY["EPSG","31468"]]

Etienne
Post by bernhard.stroebl at jena.de ()
Bernhard
although in this case I am afraid that gdal/ogr sees it as
Deutsches_Hauptdreiecksnetz
all the best,
Etienne
Post by bernhard.stroebl at jena.de ()
Post by Etienne Tourigny
see bug http://hub.qgis.org/issues/5142
Is there a proper fix for this in 1.7.4?
Etienne
Post by 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
Post by Bernd Vogelgesang
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!
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
Post by Bernd Vogelgesang
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
--
Bernhard Str?bl
Anwendungsbetreuer GIS
Kommunale Immobilien Jena
Am Anger 26
07743 Jena
Tel.: 03641 49- 5190
Internet: www.kij.de
Kommunale Immobilien Jena
Eigenbetrieb der Stadt Jena
Werkleiter: Thomas Dirkes
________ Information from NOD32 ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com
bernhard.stroebl at jena.de ()
2012-03-30 10:24:05 UTC
Permalink
Etienne,

I see this stuff from a user's point of view. I am currently not working
with different projections but my projects are EPSG:31468 and my data,
too. So this is my perspective. I am neither a geodesist nor did I dig
into how different software handles srs or prj files. All that I know is
that QGIS (1.7.4) imports EPSG:31468 shape files as EPSG:2167 because it
does neither evaluate the DATUM["D_Deutsches_Hauptdreiecksnetz" nor the
SPHEROID["Bessel_1841" infos given.
Trunk creates a user-defined SRS and does not apply EPSG:31468 either.
I would prefer QGIS to recognize the shape file as being EPSG:31468.


Am 30.03.2012 03:23, schrieb Etienne Tourigny:
[snip]
Post by Etienne Tourigny
Post by bernhard.stroebl at jena.de ()
Post by Etienne Tourigny
You can also play with the command line and see what comes up.
GDAL_FIX_ESRI_WKT=GEOGCS gdalsrsinfo file.prj
PROJ.4 : '+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 '
Post by Etienne Tourigny
GDAL_FIX_ESRI_WKT=TOWGS84 gdalsrsinfo file.prj
PROJ.4 : '+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 '
Post by Etienne Tourigny
GDAL_FIX_ESRI_WKT=NO gdalsrsinfo file.prj
PROJ.4 : '+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0
+datum=potsdam +units=m +no_defs '
This would be my preferred parameters as datum=potsdam can be different
towgs84 parameters in different locations
How would this be decided? By the user or some magic way?
The user can change it with the plugin "Coordinate Systems Updater". You
see: if the datum gets translated into a towgs84 parameter and the
projection is matched based on this then if a different user-defined
towgs84 paramter exists the right projection is not found.
according to http://mapref.org/GeodeticReferenceSystemsDE.html#Zweig733
the towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7
is applicable for the whole country of Germany
but local towgs84 parameters may differ
Post by Etienne Tourigny
This sort of contradicts your statement that it should be recognized
as EPSG:31468 because that code is NOT potsdam datum (in GDAL/OGR
anyway)
AFAIK the DHDN is the realisation of the Potsdam Datum see e.g. here:
http://georepository.com/datum_6314/Deutsches-Hauptdreiecksnetz.html
so in the prj file it is called DATUM["Deutsches_Hauptdreiecksnetz"
whereas Proj4 says +datum=potsdam ; both mean the same
Post by Etienne Tourigny
Post by bernhard.stroebl at jena.de ()
However the problem persists that QGIS does not recognize the projection as
EPSG:31468 no matter if I set it to GEOGCS, TOWGS84 or NO!
Neiter does it detect the correct projction from the prj file QGIS itself
created.
The GEOGCS option to GDAL_FIX_ESRI_WKT fixes the GEOGCS authority
node, but not the root node which is a PROJCS (see example below)!
Trying to match all possible projections can be more challenging than
matching the possible geogcs definitions. It is possible, but I didn't
get there yet.
Just to make sure I understand - is the expected behaviour in QGis
(from you POV) to see the file as EPSG:31468 with the TOWGS84
parameters seen above? Or the more generic 'potsdam' datum?
Maybe it would be better to see the towgs84 parameters (as defined by
QGIS default or the user via the plugin) but
1) it must be imported as EPSG:31468 (and not as user-defined)
2) if saving to shapefile only the DATUM["Deutsches_Hauptdreiecksnetz"
must be written (as QGIS does) and IMHO not the
TOWGS84[598.1,73.7,418.2,0.202,0.045,-2.455,6.7]
Post by Etienne Tourigny
===>
Perhaps QGis could be modified to scan existing proj4 definitions for
a match with the layer's proj4 string as Berhard suggests.
That should probably work in this case (because all that is missing is
the authority nodes - which is probably the comparison inside Qgis) -
am I right Jurgen?
$ GDAL_FIX_ESRI_WKT=GEOGCS gdalsrsinfo tmp1.prj
PROJ.4 : '+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 '
PROJCS["Transverse_Mercator",
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",12],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",4500000],
PARAMETER["false_northing",0],
UNIT["Meter",1]]
this is intersting as the definition has a datum and a towgs84 parameter
AFAIK the towgs84 values are translating the datum for the use in a
7-parameter datum transformation. This becomes relevant when my project
has a srs using a WGS84 ellipsoid and I need otf transformation of data
defined in EPSG:31468
I doubt it is useful to store a DATUM _and_ a TOWGS84 node, only the
datum is part of the srs and thus part of the data whereas the question
how to transform to wgs84 is more the responsibility of the software
that performs the transformation.
Post by Etienne Tourigny
and compare with EPSG:31468, the GEOGCS node has correct authority (4314)
$ gdalsrsinfo EPSG:31468
PROJ.4 : '+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 '
PROJCS["DHDN / 3-degree Gauss-Kruger zone 4",
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",12],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",4500000],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["X",NORTH],
AXIS["Y",EAST],
AUTHORITY["EPSG","31468"]]
Etienne
[more snip]


How does QGIS work? What happens when it is confronted with a prj file?
How does the matching work if no authority is given for the PROJCS?
With EPSG:31468 we have the problem that the srs string uses a different
name for the datum than Proj4 and that this datum can obtain different
towgs84 paramters for different parts of the world.

Bernhard


________ Information from NOD32 ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com
Etienne Tourigny
2012-03-30 18:45:00 UTC
Permalink
Post by bernhard.stroebl at jena.de ()
Etienne,
I see this stuff from a user's point of view. I am currently not working
with different projections but my projects are EPSG:31468 and my data, too.
So this is my perspective. I am neither a geodesist nor did I dig into how
different software handles srs or prj files. All that I know is that QGIS
(1.7.4) imports EPSG:31468 shape files as EPSG:2167 because it does neither
evaluate the DATUM["D_Deutsches_Hauptdreiecksnetz" nor the
SPHEROID["Bessel_1841" infos given.
Trunk creates a user-defined SRS and does not apply EPSG:31468 either.
I would prefer QGIS to recognize the shape file as being EPSG:31468.
Strictly speaking it is not exactly EPSG:31468 (that would require the
AUTHORITY node, which .prj files do not have), but the PROJ.4 string
should match that of EPSG:31468, at least.
That is the problem with .prj files, it`s not easy to relate them to EPSG.
Post by bernhard.stroebl at jena.de ()
[snip]
Post by Etienne Tourigny
Post by bernhard.stroebl at jena.de ()
Post by Etienne Tourigny
You can also play with the command line and see what comes up.
GDAL_FIX_ESRI_WKT=GEOGCS gdalsrsinfo file.prj
PROJ.4 : '+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 '
Post by Etienne Tourigny
GDAL_FIX_ESRI_WKT=TOWGS84 gdalsrsinfo file.prj
PROJ.4 : '+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 '
Post by Etienne Tourigny
GDAL_FIX_ESRI_WKT=NO gdalsrsinfo file.prj
PROJ.4 : '+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0
+datum=potsdam +units=m +no_defs '
This would be my preferred parameters as datum=potsdam can be different
towgs84 parameters in different locations
How would this be decided? By the user or some magic way?
The user can change it with the plugin "Coordinate Systems Updater". You
see: if the datum gets translated into a towgs84 parameter and the
projection is matched based on this then if a different user-defined towgs84
paramter exists the right projection is not found.
according to http://mapref.org/GeodeticReferenceSystemsDE.html#Zweig733 the
towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7
is applicable for the whole country of Germany
but local towgs84 parameters may differ
Then it makes sense to have those +towgs84 parameters as the default,
if you leave them out then you get an incorrect datum shift.
Post by bernhard.stroebl at jena.de ()
Post by Etienne Tourigny
This sort of contradicts your statement that it should be recognized
as EPSG:31468 because that code is NOT potsdam datum (in GDAL/OGR
anyway)
http://georepository.com/datum_6314/Deutsches-Hauptdreiecksnetz.html
so in the prj file it is called DATUM["Deutsches_Hauptdreiecksnetz" whereas
Proj4 says +datum=potsdam ; both mean the same
OK

Using proj-4.7.1 and gdal-1.9 the +datum=potsdam gives different
towgs84 parameters than EPSG:4314. This has been fixed in proj-4.8.
Could this contribute to the problem?

$ gdalsrsinfo '+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0
+datum=potsdam +units=m +no_defs '

PROJ.4 : '+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0
+ellps=bessel +towgs84=606,23,413,0,0,0,0 +units=m +no_defs '

$ gdalsrsinfo EPSG:4314

PROJ.4 : '+proj=longlat +ellps=bessel
+towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 +no_defs '
Post by bernhard.stroebl at jena.de ()
Post by Etienne Tourigny
Post by bernhard.stroebl at jena.de ()
However the problem persists that QGIS does not recognize the projection as
EPSG:31468 no matter if I set it to GEOGCS, TOWGS84 or NO!
Neiter does it detect the correct projction from the prj file QGIS itself
created.
The GEOGCS option to GDAL_FIX_ESRI_WKT fixes the GEOGCS authority
node, but not the root node which is a PROJCS (see example below)!
Trying to match all possible projections can be more challenging than
matching the possible geogcs definitions. It is possible, but I didn't
get there yet.
Just to make sure I understand - is the expected behaviour in QGis
(from you POV) to see the file as EPSG:31468 with the TOWGS84
parameters seen above? Or the more generic 'potsdam' datum?
Maybe it would be better to see the towgs84 parameters (as defined by QGIS
default or the user via the plugin) but
1) it must be imported as EPSG:31468 (and not as user-defined)
2) if saving to shapefile only the DATUM["Deutsches_Hauptdreiecksnetz" must
be written (as QGIS does) and IMHO not the
TOWGS84[598.1,73.7,418.2,0.202,0.045,-2.455,6.7]
I agree. What is written to .prj file by QGis when you choose EPSG:31468 ?
Post by bernhard.stroebl at jena.de ()
Post by Etienne Tourigny
===>
Perhaps QGis could be modified to scan existing proj4 definitions for
a match with the layer's proj4 string as Berhard suggests.
That should probably work in this case (because all that is missing is
the authority nodes - which is probably the comparison inside Qgis) -
am I right Jurgen?
$ ?GDAL_FIX_ESRI_WKT=GEOGCS gdalsrsinfo ?tmp1.prj
PROJ.4 : '+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 '
PROJCS["Transverse_Mercator",
? ? 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",12],
? ? PARAMETER["scale_factor",1],
? ? PARAMETER["false_easting",4500000],
? ? PARAMETER["false_northing",0],
? ? UNIT["Meter",1]]
this is intersting as the definition has a datum and a towgs84 parameter
AFAIK the towgs84 values are translating the datum for the use in a
7-parameter datum transformation. This becomes relevant when my project has
a srs using a WGS84 ellipsoid and I need otf transformation of data defined
in EPSG:31468
I doubt it is useful to store a DATUM _and_ a TOWGS84 node, only the datum
is part of the srs and thus part of the data whereas the question how to
transform to wgs84 is more the responsibility of the software that performs
the transformation.
in GDAL/OGR if you do not have TOWGS84 then the projection is
effectively treated as TOWGS84=0,0,0,0,0,0,0 so you do need a TOWGS84
node. In proj.4 that is a different story (I think).
So internally, you do need to have TOWGS84 node in addition to DATUM.
See the CT-1.0 specs.
Post by bernhard.stroebl at jena.de ()
Post by Etienne Tourigny
and compare with EPSG:31468, the GEOGCS node has correct authority (4314)
$ gdalsrsinfo EPSG:31468
PROJ.4 : '+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 '
PROJCS["DHDN / 3-degree Gauss-Kruger zone 4",
? ? 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",12],
? ? PARAMETER["scale_factor",1],
? ? PARAMETER["false_easting",4500000],
? ? PARAMETER["false_northing",0],
? ? UNIT["metre",1,
? ? ? ? AUTHORITY["EPSG","9001"]],
? ? AXIS["X",NORTH],
? ? AXIS["Y",EAST],
? ? AUTHORITY["EPSG","31468"]]
Etienne
[more snip]
How does QGIS work? What happens when it is confronted with a prj file? How
does the matching work if no authority is given for the PROJCS?
I have no idea here, hoping some of the qgis devs would comment.
Perhaps sending a mail to the qgis-dev list is more proper.
Post by bernhard.stroebl at jena.de ()
With EPSG:31468 we have the problem that the srs string uses a different
name for the datum than Proj4 and that this datum can obtain different
towgs84 paramters for different parts of the world.
I might add this problem is not unique for your case. In fact many
datums have different datum shifts depending on location. GDAL/OGR
uses the "preferred" datum shift values.
I think that this is a different issue, and is up to the user to
select which datum is needed on a per-case basis (or change the
default values as you suggested).

What needs to be resolved is the .prj<->WKT/PROJ.4 relations and
correct preffered datum and EPSG code (or Qgis representation of
them).
Post by bernhard.stroebl at jena.de ()
Bernhard
________ Information from NOD32 ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com
bernhard.stroebl at jena.de ()
2012-04-02 07:28:25 UTC
Permalink
Post by Etienne Tourigny
Post by bernhard.stroebl at jena.de ()
Etienne,
I see this stuff from a user's point of view. I am currently not working
with different projections but my projects are EPSG:31468 and my data, too.
So this is my perspective. I am neither a geodesist nor did I dig into how
different software handles srs or prj files. All that I know is that QGIS
(1.7.4) imports EPSG:31468 shape files as EPSG:2167 because it does neither
evaluate the DATUM["D_Deutsches_Hauptdreiecksnetz" nor the
SPHEROID["Bessel_1841" infos given.
Trunk creates a user-defined SRS and does not apply EPSG:31468 either.
I would prefer QGIS to recognize the shape file as being EPSG:31468.
Strictly speaking it is not exactly EPSG:31468 (that would require the
AUTHORITY node, which .prj files do not have), but the PROJ.4 string
should match that of EPSG:31468, at least.
yup
Post by Etienne Tourigny
That is the problem with .prj files, it`s not easy to relate them to EPSG.
then I would like to come back to my former suggestion: analyze the prj
file and find any matching EPSG-code
one EPSG -> OK but tell user
several -> let user choose (and probably remember choice)
none -> ask user
Post by Etienne Tourigny
Post by bernhard.stroebl at jena.de ()
[snip]
Post by Etienne Tourigny
Post by bernhard.stroebl at jena.de ()
Post by Etienne Tourigny
You can also play with the command line and see what comes up.
GDAL_FIX_ESRI_WKT=GEOGCS gdalsrsinfo file.prj
PROJ.4 : '+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 '
Post by Etienne Tourigny
GDAL_FIX_ESRI_WKT=TOWGS84 gdalsrsinfo file.prj
PROJ.4 : '+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 '
Post by Etienne Tourigny
GDAL_FIX_ESRI_WKT=NO gdalsrsinfo file.prj
PROJ.4 : '+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0
+datum=potsdam +units=m +no_defs '
This would be my preferred parameters as datum=potsdam can be different
towgs84 parameters in different locations
How would this be decided? By the user or some magic way?
The user can change it with the plugin "Coordinate Systems Updater". You
see: if the datum gets translated into a towgs84 parameter and the
projection is matched based on this then if a different user-defined towgs84
paramter exists the right projection is not found.
according to http://mapref.org/GeodeticReferenceSystemsDE.html#Zweig733 the
towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7
is applicable for the whole country of Germany
but local towgs84 parameters may differ
Then it makes sense to have those +towgs84 parameters as the default,
if you leave them out then you get an incorrect datum shift.
agreed
Post by Etienne Tourigny
Post by bernhard.stroebl at jena.de ()
Post by Etienne Tourigny
This sort of contradicts your statement that it should be recognized
as EPSG:31468 because that code is NOT potsdam datum (in GDAL/OGR
anyway)
http://georepository.com/datum_6314/Deutsches-Hauptdreiecksnetz.html
so in the prj file it is called DATUM["Deutsches_Hauptdreiecksnetz" whereas
Proj4 says +datum=potsdam ; both mean the same
OK
Using proj-4.7.1 and gdal-1.9 the +datum=potsdam gives different
towgs84 parameters than EPSG:4314. This has been fixed in proj-4.8.
Could this contribute to the problem?
I would not think so, as it is just another towgs84 parameter set which
gives a different position when making a 7-parameter transformation
Post by Etienne Tourigny
$ gdalsrsinfo '+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0
+datum=potsdam +units=m +no_defs '
PROJ.4 : '+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0
+ellps=bessel +towgs84=606,23,413,0,0,0,0 +units=m +no_defs '
$ gdalsrsinfo EPSG:4314
PROJ.4 : '+proj=longlat +ellps=bessel
+towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 +no_defs '
Post by bernhard.stroebl at jena.de ()
Post by Etienne Tourigny
Post by bernhard.stroebl at jena.de ()
However the problem persists that QGIS does not recognize the projection as
EPSG:31468 no matter if I set it to GEOGCS, TOWGS84 or NO!
Neiter does it detect the correct projction from the prj file QGIS itself
created.
The GEOGCS option to GDAL_FIX_ESRI_WKT fixes the GEOGCS authority
node, but not the root node which is a PROJCS (see example below)!
Trying to match all possible projections can be more challenging than
matching the possible geogcs definitions. It is possible, but I didn't
get there yet.
Just to make sure I understand - is the expected behaviour in QGis
(from you POV) to see the file as EPSG:31468 with the TOWGS84
parameters seen above? Or the more generic 'potsdam' datum?
Maybe it would be better to see the towgs84 parameters (as defined by QGIS
default or the user via the plugin) but
1) it must be imported as EPSG:31468 (and not as user-defined)
2) if saving to shapefile only the DATUM["Deutsches_Hauptdreiecksnetz" must
be written (as QGIS does) and IMHO not the
TOWGS84[598.1,73.7,418.2,0.202,0.045,-2.455,6.7]
I agree. What is written to .prj file by QGis when you choose EPSG:31468 ?
1.7.4:
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]]

which gets imported as EPSG:2167 when deleting the qpj file.
Post by Etienne Tourigny
Post by bernhard.stroebl at jena.de ()
Post by Etienne Tourigny
===>
Perhaps QGis could be modified to scan existing proj4 definitions for
a match with the layer's proj4 string as Berhard suggests.
That should probably work in this case (because all that is missing is
the authority nodes - which is probably the comparison inside Qgis) -
am I right Jurgen?
$ GDAL_FIX_ESRI_WKT=GEOGCS gdalsrsinfo tmp1.prj
PROJ.4 : '+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 '
PROJCS["Transverse_Mercator",
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",12],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",4500000],
PARAMETER["false_northing",0],
UNIT["Meter",1]]
this is intersting as the definition has a datum and a towgs84 parameter
AFAIK the towgs84 values are translating the datum for the use in a
7-parameter datum transformation. This becomes relevant when my project has
a srs using a WGS84 ellipsoid and I need otf transformation of data defined
in EPSG:31468
I doubt it is useful to store a DATUM _and_ a TOWGS84 node, only the datum
is part of the srs and thus part of the data whereas the question how to
transform to wgs84 is more the responsibility of the software that performs
the transformation.
in GDAL/OGR if you do not have TOWGS84 then the projection is
effectively treated as TOWGS84=0,0,0,0,0,0,0 so you do need a TOWGS84
node. In proj.4 that is a different story (I think).
So internally, you do need to have TOWGS84 node in addition to DATUM.
OK
Post by Etienne Tourigny
See the CT-1.0 specs.
Post by bernhard.stroebl at jena.de ()
Post by Etienne Tourigny
and compare with EPSG:31468, the GEOGCS node has correct authority (4314)
$ gdalsrsinfo EPSG:31468
PROJ.4 : '+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 '
PROJCS["DHDN / 3-degree Gauss-Kruger zone 4",
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",12],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",4500000],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["X",NORTH],
AXIS["Y",EAST],
AUTHORITY["EPSG","31468"]]
Etienne
[more snip]
How does QGIS work? What happens when it is confronted with a prj file? How
does the matching work if no authority is given for the PROJCS?
I have no idea here, hoping some of the qgis devs would comment.
Perhaps sending a mail to the qgis-dev list is more proper.
Post by bernhard.stroebl at jena.de ()
With EPSG:31468 we have the problem that the srs string uses a different
name for the datum than Proj4 and that this datum can obtain different
towgs84 paramters for different parts of the world.
I might add this problem is not unique for your case. In fact many
datums have different datum shifts depending on location. GDAL/OGR
uses the "preferred" datum shift values.
which is fine
Post by Etienne Tourigny
I think that this is a different issue, and is up to the user to
select which datum is needed on a per-case basis (or change the
default values as you suggested).
agreed, I was just trying to sum up open questions in relation to QGIS
Post by Etienne Tourigny
What needs to be resolved is the .prj<->WKT/PROJ.4 relations and
correct preffered datum and EPSG code (or Qgis representation of
them).
agreed!
Post by Etienne Tourigny
Post by bernhard.stroebl at jena.de ()
Bernhard
________ 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

Etienne Tourigny
2012-03-30 20:56:44 UTC
Permalink
Berhard,

I thinks I have found a solution to your problem (in master only
though). I suspect the same can be applied to 1.7.4 , if gdal-1.9 is
used.

First, make sure that 'crssync' is executed after installing master,
this adds the necessary definitions that are missing. This is probably
why EPSG:31468 is not found.

Second, the value that is found is not EPSG:31468 but the deprecated
EPSG:31464 . I have added a patch for this in bug#4977:
http://hub.qgis.org/issues/4977

Please let me know if this works for you.

Etienne
Post by bernhard.stroebl at jena.de ()
Etienne,
I see this stuff from a user's point of view. I am currently not working
with different projections but my projects are EPSG:31468 and my data, too.
So this is my perspective. I am neither a geodesist nor did I dig into how
different software handles srs or prj files. All that I know is that QGIS
(1.7.4) imports EPSG:31468 shape files as EPSG:2167 because it does neither
evaluate the DATUM["D_Deutsches_Hauptdreiecksnetz" nor the
SPHEROID["Bessel_1841" infos given.
Trunk creates a user-defined SRS and does not apply EPSG:31468 either.
I would prefer QGIS to recognize the shape file as being EPSG:31468.
[snip]
Post by Etienne Tourigny
Post by bernhard.stroebl at jena.de ()
Post by Etienne Tourigny
You can also play with the command line and see what comes up.
GDAL_FIX_ESRI_WKT=GEOGCS gdalsrsinfo file.prj
PROJ.4 : '+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 '
Post by Etienne Tourigny
GDAL_FIX_ESRI_WKT=TOWGS84 gdalsrsinfo file.prj
PROJ.4 : '+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 '
Post by Etienne Tourigny
GDAL_FIX_ESRI_WKT=NO gdalsrsinfo file.prj
PROJ.4 : '+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0
+datum=potsdam +units=m +no_defs '
This would be my preferred parameters as datum=potsdam can be different
towgs84 parameters in different locations
How would this be decided? By the user or some magic way?
The user can change it with the plugin "Coordinate Systems Updater". You
see: if the datum gets translated into a towgs84 parameter and the
projection is matched based on this then if a different user-defined towgs84
paramter exists the right projection is not found.
according to http://mapref.org/GeodeticReferenceSystemsDE.html#Zweig733 the
towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7
is applicable for the whole country of Germany
but local towgs84 parameters may differ
Post by Etienne Tourigny
This sort of contradicts your statement that it should be recognized
as EPSG:31468 because that code is NOT potsdam datum (in GDAL/OGR
anyway)
http://georepository.com/datum_6314/Deutsches-Hauptdreiecksnetz.html
so in the prj file it is called DATUM["Deutsches_Hauptdreiecksnetz" whereas
Proj4 says +datum=potsdam ; both mean the same
Post by Etienne Tourigny
Post by bernhard.stroebl at jena.de ()
However the problem persists that QGIS does not recognize the projection as
EPSG:31468 no matter if I set it to GEOGCS, TOWGS84 or NO!
Neiter does it detect the correct projction from the prj file QGIS itself
created.
The GEOGCS option to GDAL_FIX_ESRI_WKT fixes the GEOGCS authority
node, but not the root node which is a PROJCS (see example below)!
Trying to match all possible projections can be more challenging than
matching the possible geogcs definitions. It is possible, but I didn't
get there yet.
Just to make sure I understand - is the expected behaviour in QGis
(from you POV) to see the file as EPSG:31468 with the TOWGS84
parameters seen above? Or the more generic 'potsdam' datum?
Maybe it would be better to see the towgs84 parameters (as defined by QGIS
default or the user via the plugin) but
1) it must be imported as EPSG:31468 (and not as user-defined)
2) if saving to shapefile only the DATUM["Deutsches_Hauptdreiecksnetz" must
be written (as QGIS does) and IMHO not the
TOWGS84[598.1,73.7,418.2,0.202,0.045,-2.455,6.7]
Post by Etienne Tourigny
===>
Perhaps QGis could be modified to scan existing proj4 definitions for
a match with the layer's proj4 string as Berhard suggests.
That should probably work in this case (because all that is missing is
the authority nodes - which is probably the comparison inside Qgis) -
am I right Jurgen?
$ ?GDAL_FIX_ESRI_WKT=GEOGCS gdalsrsinfo ?tmp1.prj
PROJ.4 : '+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 '
PROJCS["Transverse_Mercator",
? ? 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",12],
? ? PARAMETER["scale_factor",1],
? ? PARAMETER["false_easting",4500000],
? ? PARAMETER["false_northing",0],
? ? UNIT["Meter",1]]
this is intersting as the definition has a datum and a towgs84 parameter
AFAIK the towgs84 values are translating the datum for the use in a
7-parameter datum transformation. This becomes relevant when my project has
a srs using a WGS84 ellipsoid and I need otf transformation of data defined
in EPSG:31468
I doubt it is useful to store a DATUM _and_ a TOWGS84 node, only the datum
is part of the srs and thus part of the data whereas the question how to
transform to wgs84 is more the responsibility of the software that performs
the transformation.
Post by Etienne Tourigny
and compare with EPSG:31468, the GEOGCS node has correct authority (4314)
$ gdalsrsinfo EPSG:31468
PROJ.4 : '+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 '
PROJCS["DHDN / 3-degree Gauss-Kruger zone 4",
? ? 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",12],
? ? PARAMETER["scale_factor",1],
? ? PARAMETER["false_easting",4500000],
? ? PARAMETER["false_northing",0],
? ? UNIT["metre",1,
? ? ? ? AUTHORITY["EPSG","9001"]],
? ? AXIS["X",NORTH],
? ? AXIS["Y",EAST],
? ? AUTHORITY["EPSG","31468"]]
Etienne
[more snip]
How does QGIS work? What happens when it is confronted with a prj file? How
does the matching work if no authority is given for the PROJCS?
With EPSG:31468 we have the problem that the srs string uses a different
name for the datum than Proj4 and that this datum can obtain different
towgs84 paramters for different parts of the world.
Bernhard
________ Information from NOD32 ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com
Torsten Lange
2012-03-22 19:32:37 UTC
Permalink
Post by bernhard.stroebl at jena.de ()
Post by 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 haven't been aware of this as well. However, as stated in the comments for the ticket, in Debian there is this 'crssync' tool. For my case at least it assigns the depricated id 31463 instead of the currently valid id 31467 (which I just checked). Except for the id there is no shifting..., that's why _I_ didn't complain. Anyway it waked me up to be more "checky" ;)
Post by bernhard.stroebl at jena.de ()
Post by Bernd Vogelgesang
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!
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
Post by Bernd Vogelgesang
Thanx for advice
Bernd
Torsten
Andy Harfoot
2012-03-23 12:47:09 UTC
Permalink
Post by Bernd Vogelgesang
So, the problem was now described thoroughly, but what are the
conclusions now?
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!
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...)
I confess that I haven't looked at this problem in a huge amount of
detail, but came across the 'Coordinate Systems Updater' plugin that
might be a way to push modifications to the QGIS CRS database out to
users - might this offer a workaround?

Andy
--
Andy Harfoot

GeoData Institute
University of Southampton
Southampton
SO17 1BJ

Tel: +44 (0)23 8059 2719
Fax: +44 (0)23 8059 2849

www.geodata.soton.ac.uk
Loading...