sis-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Transformation from EPSG:2154 to EPSG:28992
Date Wed, 26 Aug 2020 11:17:53 GMT
Hi Martin,

In my code I've tried the following approach: if accuracy of direct transformation A ->
B is smaller than accuracy(A -> WGS84) + accuracy(WGS84 -> B) then I use the direct
transformation. This works well for my case. 

But how is accuracy determined? I've tried two other CRS: 31467 and 25832 and the accuracy
is also 3000 although there areas overlap.

Regarding your question about a safeguard for CRS that are too far apart: wouldn’t there
be some kind of out of range exception if the coordinate to transform is too far away from
the area of the target CRS?


Gerd Müller-Schramm 
Software Developer, GeoMedia Smart Client Kommunal
T: +49 (0) 89 96 106 4117 

HxGN Safety & Infrastructure GmbH
Wittenberger Straße 15B
04129 Leipzig, Germany
HxGN SI is part of HEXAGON

-----Original Message-----
From: Martin Desruisseaux <> 
Sent: Dienstag, 25. August 2020 17:19
Subject: Re: Transformation from EPSG:2154 to EPSG:28992

This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links,
opening attachments, or replying to this email.

Hello Gerd!

Le 25/08/2020 à 14:42, MUELLER-SCHRAMM Gerd a écrit :

> I’m trying to transform the coordinates from EPSG:2154 to EPSG:28992 
> but it seems that I don’t get a correct result.E.g. for 
> (926713.7022916666, 7348947.025885417) it should be (220798.684126,
> 577583.800638) according to several online transformation tools and 
> Proj4J.But even the Apache SIS 1.0 I get (220762.48670102577, 
> 577396.039844773).
> Is this a bug or do I something wrong? I’ve attached a small test program.
Thanks for the test, I just investigated. This issue has a little bit of history. The test
performs a coordinate transformation between datum of
2 different countries:


    Réseau Géodésique Français 1993 (EPSG:6171)
    Domain of validity: France - onshore and offshore, mainland and Corsica.


    Amersfoort (EPSG:6289)
    Domain of validity: Netherlands - onshore, including Waddenzee,
    Dutch Wadden Islands and 12-mile offshore coastal zone.

The EPSG database does not define coordinate transformation between those two countries. In
such case, Apache SIS or PROJ have to guess what the coordinate transformation may be. The
WKTs in the test contain
TOWGS84 elements, but WGS84 is not the datum of any of the CRS involved in this coordinate
operation. In other words, the TOWGS84 elements in this test do not define a *direct* transformation.
They could be used for an indirect transformation however, as below:

    EPSG:6171  →  WGS84  →  EPSG:6289

Actually Apache SIS was applying such indirect transformation in a previous version. This
feature has been removed in October 2013 because it was considered "dangerous" (more on it
below) and had (at that time) undesirable effects like taking precedence over the more direct
transformations defined in EPSG database. On the other side, PROJ4J and PROJ versions before
PROJ 6 applies the indirect transformation systematically (without querying EPSG database)
even if a direct transform exists, which causes other problems. Removing that systematic use
of WGS84 was one of the main purposes of PROJ 6 effort.

I just tried to reintroduce support for indirect transformation (through
WGS84) when no direct transformation is found and I got the same results than PROJ4J / online
tools. I can commit this change (I think the above-cited interaction problem with EPSG database
does not occur anymore). The "danger" however is to give a false sense of accuracy.
"EPSG:6171  →  WGS84" may be valid for coordinates inside the EPSG:6171 domain of validity,
and "WGS84 →  EPSG:6289" may be valid for coordinates inside the EPSG:6289 domain of validity,
but the "EPSG:6171 →  WGS84  →  EPSG:6289" chain may be invalid if those domains of validity
do not intersect. In this particular case the result may be not too bad because the two countries
are not too far apart, but the transformation result may be erratic if an indirect transformation
is applied between local datum separated by a large distance.

The Apache SIS policy after October 2013 became to not use Bursa-Wolf parameters if not defined
in a direct transformation. Instead, SIS declares a large coordinate operation uncertainty.
It can be verified with the following code:

    CoordinateOperation op = CRS.findOperation(epsg2154, epsg28992, null);

Which prints 3000 meters when no Bursa-Wolf parameters have been applied
(3 km error is the worst case scenario I have observed). The errors observed in this test
are within that range. However I agree that applying the indirect transformation may be a
"less bad" strategy, but I do not know which uncertainty to declare in that case. The PROJ4J
results are not "correct"; they are within some distance of the real value, and I do not know
what this distance is.

So to summarize, I propose to reintroduce the use of indirect transformation (of the form
A  →  WGS84  →  B) when Apache SIS did not found a better path, but we need to decide:

  * Which accuracy to declare.
  * Do we need safeguard against CRS that should not be connected (i.e.
    disallow "A  →  WGS84  →  B" when A and B are too far apart)?


View raw message