[Qgis-developer] Datum Transformation with target_crs_code different than 4326 gives huge errors

Andre Joost andre+joost at nurfuerspam.de
Fri Jul 4 21:15:40 PDT 2014

Am 04.07.2014 23:07, schrieb Pedro Venâncio:
> Hi,
> I've been doing some tests and found that, using a different
> target_crs_code than 4326 (wgs84), Datum Transformation simply
> ignores the values ​​of transformation.

> The error we get is huge, and I get exactly the same error if I set
> the shift values all to zero. It simply ignores the transformation
> using a different target_crs than 4326. The exception are NTv2 grids.
> Assigning them different target_crs, work well (there is one with
> target_crs 4150 and seven with 4258).
> Actually it's even worse than ignoring, because if I do not choose
> any transformation and do "Cancel" on the Datum Transformation
> window, the point is reprojected based on the values ​​of default CRS
> +towgs84 parameter (gives an error of about 1.13m). With this data I
> am testing (EPSG:3763 vs. EPSG:27493), even without using on-the-fly
> reprojection, the difference between the point is only about 3.2m.
> Using target_crs 4258 in srs.db, regardless of the values​​, the
> error is more than 123m.
> Maybe it generate some conflict with +towgs84 parameter?
> The most recent transformations in some European countries are
> calculated for 4258 and with this issue we can not use them in QGIS.
> I've opened a ticket here [0], where I put test data and images of
> the results.

I think it should be save to set the target_CRS in the QGIS Datum 
transformation tool internally to 4326 if 4258 is provided, or fill in 
the tfm values directly to target_CRS 4326 (although the EPSG database 
has 4258). Nadgrids work differently, but could be handled the same way. 
WGS84 and ETRS89 are still considered as identical.

André Joost

More information about the Qgis-developer mailing list