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

Sun May 26 13:15:09 PDT 2013

Hi Andre,
so let's try a short summary about our issue:

The problem is:
- QGIS does not recognize projections settings of MapInfo TAB files as it's "own" equivalent build in projection settings (e.g. EPSG 31467), this efforts to assign the correct SRS to MapInfo TAB files every time when they are opened
- same is with EPSG 25832 (problem is different, see later)
- if you change build in projection settings in QGIS (e.g. value for datum shifting), MapInfo TAB files probably won't ever be assigned with that SRS automatically, because it is different from the built in SRS of GDAL/OGR (with towgs84 parameters)

The results are:
- QGIS 1.8 does not use the latest GDAL version, GDAL/OGR 1.10 will fix the problem with wrong "-0" values within towgs84 parameters of EPSG 25832
- there are bugs in GDAL/OGR when you use EPSG codes, that may result in different datum settings; proper projections of MapInfo may not be recognized and the other way around
- GDAL/OGR makes use of projection settings and transformation matters in one file; built in EPSG codes make use of Helmert-7-Parameter-Transformation (towgs84-parameters)
- the thing is that towgs84-parameters change as a function of location and its spatial extensions (so there are no "right" or "wrong" definitions; "right" definitions just depend)
- GDAL/OGR settings for datum shift is static and can't fulfill varying needs; anyway NTv2 transformation is more precise and does not require 7-Parameter
- using proj4text settings (maybe with +nadgrid) instead of EPSG codes will resolve problems while you use GDAL/OGR directly
- QGIS uses build in GDAL/OGR settings; therefore a solution of the problem in QGIS would be to make use of -qrj files for every used format; this would make it possible to resolve restrictions of GDAL/OGR with own proj4text settings; it would be possible for every user to decide what method of datum shifting he wants to use

I think, I got more background to understand my problems now. Unfortunately I can't see a quick solution, so I will have to love my workaround for at least a while  ;-) I hope latest version of GDAL and extension of the purpose of .qrj file will get in QGIS soon.

... but please do not hesitate if you have new or better ideas!

Thanks so far,
Andreas

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: Sonntag, 26. Mai 2013 15:42
An: qgis-user at lists.osgeo.org
Betreff: Re: [Qgis-user] Recognition of SRS in MapInfo-Files

Hi Andreas,

Am 26.05.2013 11:42, schrieb Fischer, Andreas:
> 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).

Ok, I'm not using that software. I saw the ogrinfo output and thought these parametres are stored in the mapinfo files explicitly.

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

This is hardcoded inside the GDAL mapinfo driver. Have a look here:

<http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/mitab/mitab_spatialref.cpp>

in line 383. You even find the outdated towgs84 parametres. But what 
parametres is Mapinfo really using today?
Here is a downloadable zipfile, but not human readable:
<http://testdrive.mapinfo.com/techsupp/miprod.nsf/kbase_by_product/71C24D1304C4A05785256DD600641EB2>

GDAL has to use the values as defined by Mapinfo, regardless from its 
own parameters. So I am not sure if it is a bug or a feature.

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

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

You told ogr2ogr that source and target CRS are the same, so it does no 
reprojection. Should be the same result as giving no SRS information at 
all (if the shapefile has a correct prj file).

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

Definitely wrong here, units and extent do not match.

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

I discovered similar bugs when using EPSG codes instead of full proj 
strings.

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

This looks like an older GDAL version. Current GDAL 1.10 gives the 
following definition:

D:\Karten\gdal\gdal-dev>gdalsrsinfo epsg:31467

PROJ.4 : '+proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 
+ellps=bessel +
towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 +units=m +no_defs '

But all this does not really help if you want to add ntv2 datums to your 
mitab files.

Greetings,
André Joost

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