Ticket #11 (closed defect: fixed)
ETRS89-based CRSs missing datum definition?
|Reported by:||msieczka||Owned by:||warmerdam|
|Keywords:||Cc:||neteler, Mikael.Rittri@…, ajolma|
PROJ 4.6.0 does not apply a datum shift reprojecting between a CRS which has an implicit datum definition (e.g. Pulkovo 1942/58-based EPSG 4179, for which GDAL uses towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84) and an ETRS89-based CRS, e.g. EPSG 2180, that has no implicit towgs84 or datum.
The above results in reprojection errors of dozens of meters and makes using EPSG codes for ETRS89-based CRS unreliable. Should PROJ.4 and GDAL enforce towgs84=0,0,0 for all ETRS89 CRSs that have no implicit datum definition otherwise?
There are 58 CRSs in PROJ.4 4.6 epsg file that are based on ETRS89 datum (including e.g. pan-European LCC EPSG 3034 or LAEA EPSG 3035). Using any of their EPSG codes leads to *huge* reprojection errors.
The source EPSG 4179 is Pulkovo 1942(58) based, target EPSG 2180 is ETRS89 based. Since no explicit towgs84 is specified for EPSG 2180 but there is for EPSG 4179, GDAL fails to perform the datum shift and returns a wrong result:
$ echo "16E 52N 64" | gdaltransform -s_srs EPSG:4179 -t_srs EPSG:2180 294132.884446735 463557.976146893 64
The correct reprojection is possible if the EPSG 2180 definition is given in proj4 format *plus* +towgs84=0,0,0:
$ echo "16E 52N 64" | gdaltransform -s_srs EPSG:4179 -t_srs "+proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +units=m +towgs84=0,0,0" 294006.094422874 463523.916413687 103.090447655879
For instance, GRASS always forces towgs84=0,0,0 for EPSG 2180 and does the reprojection right. I'm not 100% sure if towgs84=0,0,0 is the correct, ultimate solution, but there is something to it.