Hello Michael
Le 28/01/2022 à 23:44, Michael Arneson a écrit :
I am trying to convert the points 3.08, 62.08 from CRS 4320 to CRS
4326. This conversion fails with the following error:
org.opengis.util.NoSuchIdentifierException: No operation method found
for name or identifier “Norway Offshore Interpolation”.
While the EPSG database contains thousands of CRS definitions, all of
them (or all operations between a pair of CRS) use a few dozens of
"Operation methods". Contrarily to the CRS definitions, the operation
methods has to be hard-coded in Java code, because they are formulas.
The operation methods supported by Apache SIS are listed there:
https://sis.apache.org/tables/CoordinateOperationMethods.html
Any CRS definition (or any operation between a pair of CRS) which uses
an operation method not in this list will fail, regardless if the
definition was in EPSG database or elsewhere. This limitation is not
specific to Apache SIS; I do not see how any software could avoid that.
Obviously there is many operation methods that we would like to add.
Some of them are listed there:
https://issues.apache.org/jira/browse/SIS-212
"Norway Offshore Interpolation" is not in this list because I was not
aware of it. I just checked in the EPSG database, but in the "Formula"
section it only said "See information source" and provides no example:
https://epsg.org/coord-operation-method_9620/Norway-Offshore-Interpolation.html
I downloaded the December 2021 version of EPSG guidance Note 7-2
(Coordinate Conversions and Transformations including Formulas) but
found no mention of that operation method:
https://epsg.org/guidance-notes.html
So right now it is difficult to said if that operation method would be
easy to add or not…
I am using the Apache SIS 1.1 libraries. This error occurs when the
EPSG database is used. If the EPSG database is not used, then apache
sis is able to perform the conversion mentioned earlier.
Without EPSG database, SIS fallback on a more generic but less accurate
algorithm. I suggest to print the operation method with
System.out.println(operation) and looks at the OperationAccuracy[…]
element in the WKT. Alternatively I noticed that if the extentInLongLat
argument is replaced by null, the test code succeed with the following
operation method (various WKT fragments omitted for brevity):
CoordinateOperation["ED50 to WGS 84 (1)",
SourceCRS[GeodeticCRS["ED50",
Datum["European Datum 1950", (…snip…)
TargetCRS[GeodeticCRS["WGS 84",
Datum["World Geodetic System 1984", (…snip…)
Method["Geocentric translations (geog2D domain)"], (…snip…)
OperationAccuracy[10.0],
BBox[34.88, -9.56, 71.21, 31.59], (…snip…)
So my guess is that the operation based on “Norway Offshore
Interpolation” was the most accurate operation for the bounding box
specified by extentInLongLat argument, which was around 62.08°N 3.08°E.
By removing this bounding box, SIS fallback on the widest area available
for the given pair of CRS, which appear to use a coordinate operation
supported by SIS ("Geocentric translations").
Admittedly, maybe SIS could be modified for automatic fallback on less
accurate coordinate operation if the most accurate one is not available…
Martin
