[Qgis-user] Re: Annoying CRS-Problem with EPSG 31468 / 2167: Conclusions?

Fri Mar 30 02:23:42 PDT 2012

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]

>>
>>>
>>> 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?

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

>
> 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
>
>>
>> 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]

>
> ===>
> 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]]

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.

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

[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