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
[email protected]
www.kreis-unna.de
-----Ursprüngliche Nachricht-----
Von: [email protected]
[mailto:[email protected]] Im Auftrag von Andre Joost
Gesendet: Samstag, 25. Mai 2013 08:41
An: [email protected]
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
[email protected]
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.
_______________________________________________
Qgis-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-user
