Dear Community,
thanks for your replies. I was very busy this week, so I could make further
tests not until today. Unfortunately after my tests today I'm more confused
than before. But I will try to explain...
First I figured out that Bo Victor is right in my case too. After I opened a
TAB-File with EPSG:25832 the layer SRS definition is exactly as he posted. So
this problem will address gdal/ogr library.
Then I tried out ogrinfo for a TAB file with EPSG 31467 as Jürgen mentioned.
The output shows TOWGS84 parameters! These are used within the automatically
user defined layer SRS definition in QGIS as well, after I open a MapInfo TAB
file with 31467. It seems that ogr always assumes that TOWGS84 parameters have
to be used for EPSG 31467. Even though the CoordSys-String in MapInfo MIF file
(CoordSys Earth Projection 8, 104, "m", 9, 0, 1, 3500000, 0) does not point at
such parameters and I changed the build in SRS definition in QGIS. In my
opinion this is not the best way, because it seems to be impossible to get the
modified build in SRS for EPSG 31467 matched. The purpose for the modification
was to make use of grid shift transformation with BETA2007 / NTv2 instead of
using parameter transformation in general.
In former times I had trouble with ogr and MapInfo too. But these problems were
more easy to solve. Using ogr2org to get PostGIS tables to MapInfo TAB files
with -s_srs EPSG 31467 parameter caused trouble. The same happens with
EPSG:25832. In both cases MapInfo Tab files didn't get the right projection in
MapInfo. The reason are different DATUM parameters. To get around these
problems I used ogrinfo for MapInfo TAB with EPSG 31467 and 25832 to save
suitable SRS definition in text files first. After that I used ogr2org with
-a_srs 31467.txt or -a_srs 25832.txt and everything went fine.
But in case of my recent problem I don't have a chance to do the same, because
everything happens automatically. Even though if the next QGIS-version will
make use of the latest GDAL-library, the problem of detecting the proper build
in SRS I my case isn't solved. Maybe this will be difficult because MapInfo and
ogr do not use equal IDs for projections ;-(
My workaround is to assign the proper SRS after opening a MapInfo TAB file. But
users have to do this every time a MapInfo file is opened in QGIS. Some do not
like this, some don't understand this and some do both.
I would be glad, if you have new ideas!
Best regards
Andreas
Ogrinfo output for MapInfo TAB file with EPSG:31467:
Layer SRS WKT:
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]]
User defined layer SRS definition for the same MapInfo TAB file opened in QGIS:
+proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel
+towgs84=582,105,414,1.04,0.35,-3.08,8.3 +units=m +no_defs
Im Auftrag
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.fisc...@kreis-unna.de
www.kreis-unna.de
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.
_______________________________________________
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user
