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
