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

[Andre Joost]

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