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

[Markus Neteler]

On Sun, Aug 10, 2008 at 9:14 AM, Maciej Sieczka <tutey at o2.pl> wrote:
> 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.

As European I am curious how to deal with this problem.
Should we bring it up on PROJ4?

Markus