[gdal-dev] could GDAL enforce towgs84=0,0,0 for ETRS89-based CRSs?

[Maciej Sieczka]

Maciej Sieczka pisze:

> Due to a change in PROJ 4.6.0, no datum shift is aplied when
> 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 about 150 m and makes using
> EPSG codes for ETRS89-based CRS impossible. Could PROJ.4 and GDAL
> enforce towgs84=0,0,0 for all ETRS89 CRSs that have no implicit datum
> definition otherwise?
> 
> For instance, GRASS always forces towgs84=0,0,0 for EPSG 2180 and does
> the reprojection right.

I'm repeating my request. Please read above for the general outline.
More details follow below.

There are 58 CRSs in PROJ.4 4.6 epsg file that are based on ETRS89
datum. Using any of their EPSG codes leads to *huge* reprojection errors
because towgs84=0,0,0 is not applied for them. Example:

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
it 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 only 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

Please do something about it. Currently, GDAL dependent software that
relies on GDAL's interpretation of EPSG codes will introduce
reprojection errors of dozens of meters for all the 58 ETRS89 based
CRSs, including e.g. pan-European LCC (EPSG 3034) or LAEA (EPSG 3035),
when datum shift is involved. Lots of users are affected.

Maciek

-- 
Maciej Sieczka
www.sieczka.org