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

Fri Mar 30 12:56:37 PDT 2012

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

On Fri, Mar 30, 2012 at 6:23 AM,  <bernhard.stroebl at jena.de> wrote:
> 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