[Qgis-user] Recognition of SRS in MapInfo-Files

Sun May 26 02:42:33 PDT 2013

Hi Andre,
thanks for that explanation. I understand the problem mixing projection definition and datum shift now.

But MapInfo lets the user decide what kind of datum shift to use as well (Helmert or nadgrid). I'm doing nadgrid shifting with MapInfo and this works very fine. MapInfo does not mix both. For this purpose MapInfo uses an own file for projection definition (MAPINFOW.PRJ) and datum shifting (NTv2.xml). The settings within last file are not written in MIF file, but they are used for transformation on-the-fly. The projections settings of a MIF file with EPSG 31467 is just follows. This is (without bounds) the definition of 31467 in MAPINFOW.PRJ.

	CoordSys Earth Projection 8, 1000, "m", 9, 0, 1, 3500000, 0 Bounds (-4748143.32561, -10000855.7646) (11748143.3256, 10000855.7646)

This is completely without 7 parameter or nadgrids settings!

So what I think is, that gdal/ogr library searches for "key-words" and "hints" in projection settings of MapInfo files (probably it is the datum, written above with 1000). When gdal/ogr determines that it has to be DHDN/GK3 (EPSG 31467) it adopts its own definition. Unfortunately this definition is mixed with 7-parameter datum shift. For sure QGIS won't find a matching definition, when I changed the build in definition to nadgrid datum shift before, but that is not the first fault ...

... there still is another problem. Even though I do not (!) change projection settings of EPSG 31467 within QGIS an opened MapInfo file with EPSG 31467 will resolve in a user defined SRS setting! In my opinion gdal/ogr library has a detection problem itself. The "key-words" or "hints" do not lead to a proper setting with gdal/ogr. 

Therefore I always used proj4text settings with ogr2ogr, knowing MapInfo "understands" them and enables it to find the right settings for created TAB-files. When I don't do this and use -a_srs EPSG:31467 MapInfo matches wrong projection settings for its TAB file. As I find out it is about the datum value. 

So I guess this problem will occur the other way around as well. In my case while opening MapInfo TAB or MIF in QGIS.

Please have a look at my test settings:

1. Result of ogrinfo with MapInfo TAB (EPSG 31467)

PROJCS["unnamed",
    GEOGCS["unnamed",
        DATUM["DHDN_Potsdam_Rauenberg",
            SPHEROID["Bessel 1841",6377397.155,299.1528128],
            TOWGS84[582,105,414,1.04,0.35,-3.08,8.3]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",9],
    PARAMETER["scale_factor",1],
    PARAMETER["false_easting",3500000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1.0]]

2.) I saved this output from ogrinfo to EPSG31467_mapinfo.prj

3.) I used org2gor to create a MapInfo TAB from Shape (EPSG 31467) with references to EPSG 31467

	ogr2ogr -f "MapInfo File" test2 lp_c110_EPSG31467_region.shp -s_srs EPSG:31467 -t_srs EPSG:31467

4.) I used ogr2ogr to create a MapInfo TAB from Shape (EPSG 31467) with reference to the file, I created before:

	ogr2ogr -f "MapInfo File" test3 lp_c110_EPSG31467_region.shp -s_srs EPSG:31467 -t_srs EPSG31467_mapinfo.prj

When I open the TAB from 3.) it doesn't get the right projection in MapInfo! 

ogrinfo looks like this 

PROJCS["unnamed",
    GEOGCS["unnamed",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.257223563],
            TOWGS84[0,0,0,0,0,0,0]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",9],
    PARAMETER["scale_factor",1],
    PARAMETER["false_easting",3500000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1.0]]

MIF-File shows
	CoordSys Earth Projection 8, 104, "m", 9, 0, 1, 3500000, 0 Bounds (-30000000, -15000000) (30000000, 15000000)

When I open the TAB from 4.) everything is fine. 

ogrinfo looks like this

PROJCS["unnamed",
    GEOGCS["unnamed",
      	  DATUM["DHDN_Potsdam_Rauenberg",
            SPHEROID["Bessel 1841",6377397.155,299.1528128],
            TOWGS84[582,105,414,1.04,0.35,-3.08,8.3]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",9],
    PARAMETER["scale_factor",1],
    PARAMETER["false_easting",3500000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1.0]]

MIF-File shows
	CoordSys Earth Projection 8, 1000, "m", 9, 0, 1, 3500000, 0 Bounds (-4748143.32561, -10000855.7646) (11748143.3256, 10000855.7646)

The Problem is about the wrong datum setting (104) that results from referencing EPSG-Code 31467. Only proj4text in my EPSG31467_mapinfo.prj file makes sure to get the right value 1000.

104 = WGS84/WGS84
1000 = Rauenberg/Bessel

By the way: 
towgs84 parameters (EPSG 31467)  in QGIS and ogrinfo are different. Maybe this is the reason for the non-matching of EPSG 31467 of a MapInfo TAB with build in EPSG 31467.

Best regards

Andreas Fischer
Sachgebietsleiter

Kreis Unna - Der Landrat
Zentrale Datenverarbeitung
Sachgebiet DV-Organisation
Friedrich-Ebert-Straße 17
59425 Unna

Fon 02 3 03 27-44 16
Fax 0 23 03 27-28 96
andreas.fischer at kreis-unna.de
www.kreis-unna.de

-----Ursprüngliche Nachricht-----
Von: qgis-user-bounces at lists.osgeo.org [mailto:qgis-user-bounces at lists.osgeo.org] Im Auftrag von Andre Joost
Gesendet: Samstag, 25. Mai 2013 08:41
An: qgis-user at lists.osgeo.org
Betreff: Re: [Qgis-user] Recognition of SRS in MapInfo-Files

Hi all,

the problem is that QGIS (and GDAL/OGR) mixes projection and datum shift together in one EPSG Code. This is not the way intended by EPSG or ESRI. 
They handle projection and datum shift seperately.

As a consequence, shapefiles by ESRI don't have datum shift paramteres, while QGIS and Mapinfo write them into the file.

Datum shift can be 3- or 7-parameter Helmert, or a nadgrid file.
For some countries, several transformation parameters were published over the years. A 7-parameter transformation does not even have to be more exact, if it was derived only from a few reference stations.
Nadgrid is supposed to be the most precise, but it is not available for all countries and softwares.

EPSG and ESRI let the user decide which datum shift he wants for a given projection; Mapinfo and QGIS don't. And when Mapinfo and QGIS have different datum shifts bundled to a EPSG-code, the result will not match easily.

HTH,
André Joost

Am 25.05.2013 01:57, schrieb Fischer, Andreas:
> Dear Community, I just had an idea:
>
> If a shape file is created with QGIS a .qpj file is created as well.
> This file is used always when it is existing. QGIS doesn't care of 
> settings in .prj file and just uses the definitions in .qpj file.
> That seems to be almost perfect, because all changes of the build in 
> SRS definitions are considered in that qpj file. Unfortunately this 
> file is without use for MapInfo TAB files.
>
> Wouldn't it be possible to make this going on with other formats as 
> well? This might be a solution that does not care about ogr settings 
> in first place. If ogr works fine nobody has needs for .qpj files.
> But in other cases, everyone could determine the parameters to use.
> If these are defined exactly like build in SRS matching should not be 
> a problem.
>

_______________________________________________
Qgis-user mailing list
Qgis-user at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user
Denken Sie an die Umwelt. Pruefen Sie deshalb bitte, 
ob der Ausdruck dieser E-Mail wirklich notwendig ist.

Diese E-Mail wurde beim Ausgang auf Viren geprueft. Wegen der 
potentiellen Gefahr auf den Uebertragungswegen wird zu einer 
Vireneingangskontrolle geraten. Eine Haftung für Virenfreiheit
wird ausgeschlossen.