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?
Regards,
Gerd
Gerd Müller-Schramm
Software Developer, GeoMedia Smart Client Kommunal
T: +49 (0) 89 96 106 4117
E: gerd.mueller-schr...@hexagon.com
HxGN Safety & Infrastructure GmbH
Wittenberger Straße 15B
04129 Leipzig, Germany
hexagon.com
HxGN SI is part of HEXAGON
-----Original Message-----
From: Martin Desruisseaux <martin.desruisse...@geomatys.com>
Sent: Dienstag, 25. August 2020 17:19
To: MUELLER-SCHRAMM Gerd <gerd.mueller-schr...@hexagon.com>
Cc: user@sis.apache.org
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:
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
