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
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-user
