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:
Source:
Réseau Géodésique Français 1993 (EPSG:6171)
Domain of validity: France - onshore and offshore, mainland and Corsica.
Target:
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);
System.out.println(CRS.getLinearAccuracy(op));
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)?
Martin
