[jira] [Created] (SIS-638) CRS.findOperations(EPSG:4326 → EPSG:4267) fails because the inverse of EPSG:8647 fails step-chaining validation

["Ema Bakar (Jira)" <ji...@apache.org>]

Ema Bakar created SIS-638:
-----------------------------

             Summary: CRS.findOperations(EPSG:4326 → EPSG:4267) fails because the inverse of EPSG:8647 fails step-chaining validation
                 Key: SIS-638
                 URL: https://issues.apache.org/jira/browse/SIS-638
             Project: Spatial Information Systems
          Issue Type: Bug
          Components: Referencing
    Affects Versions: 1.7
         Environment: sis-referencing 1.7 + sis-embedded-data 1.7 (embedded EPSG dataset 13.101), OpenJDK 11.0.25
            Reporter: Ema Bakar


{{CRS.findOperations}} from WGS 84 to NAD27 throws instead of returning operations. It works on 1.4. Found while upgrading the same application from 1.4 (see SIS-629).

{code:java}
CoordinateReferenceSystem source = CRS.forCode("EPSG:4326");
CoordinateReferenceSystem target = CRS.forCode("EPSG:4267");
List<CoordinateOperation> ops = CRS.findOperations(source, target, null);
{code}

{noformat}
org.apache.sis.referencing.factory.InvalidGeodeticParameterException: Invalid coordinate operation step 1, because the reference system “NAD83” cannot be followed by “NAD83(CSRS)”.
    at org.apache.sis.referencing.operation.DefaultConcatenatedOperation.verifyStepChaining(DefaultConcatenatedOperation.java:369)
    at org.apache.sis.referencing.operation.CoordinateOperationRegistry.getSteps(CoordinateOperationRegistry.java:870)
    at org.apache.sis.referencing.operation.CoordinateOperationRegistry.inverse(CoordinateOperationRegistry.java:834)
    at org.apache.sis.referencing.operation.CoordinateOperationRegistry.search(CoordinateOperationRegistry.java:714)
    at org.apache.sis.referencing.operation.CoordinateOperationRegistry.createOperations(CoordinateOperationRegistry.java:546)
    at org.apache.sis.referencing.operation.CoordinateOperationFinder.createOperations(CoordinateOperationFinder.java:279)
    at org.apache.sis.referencing.operation.DefaultCoordinateOperationFactory.createOperations(DefaultCoordinateOperationFactory.java:796)
    at org.apache.sis.referencing.CRS.findOperations(CRS.java:883)
    at org.apache.sis.referencing.CRS.findOperations(CRS.java:845)
{noformat}

*Cause*

EPSG has 78 operations from 4267 to 4326 and none from 4326 to 4267, so SIS builds the inverses. One of them is EPSG:8647 "NAD27 to WGS 84 (78)", a concatenated operation whose steps don't chain in the EPSG data:
* step 1: EPSG:1313 "NAD27 to NAD83 (4)", NAD27 (4267) → NAD83 (4269)
* step 2: EPSG:1946 "NAD83(CSRS) to WGS 84 (2)", NAD83(CSRS) (4617) → WGS 84 (4326)

The forward direction is accepted. {{createCoordinateOperation("EPSG:8647")}} returns a {{DefaultConcatenatedOperation}}, and {{CRS.findOperations(EPSG:4267 → EPSG:4326)}} succeeds. Only the inverse goes through {{verifyStepChaining}} in {{CoordinateOperationRegistry.inverse}}. The exception then ends the whole search, so the other 77 valid inverse operations are not returned either.

On 1.4 the same call returned all 78 operations, including the inverse of 8647 with its mismatched steps unchanged.

*Workaround*

Catch the {{InvalidGeodeticParameterException}} from {{findOperations(source, target)}}, call {{findOperations(target, source)}} instead, and invert each result:
* single operations with {{DefaultCoordinateOperationFactory.createSingleOperation}}, using an "Inverse of <method>" method and {{getMathTransform().inverse()}};
* concatenated operations by inverting their steps in reverse order and passing them to {{createConcatenatedOperation}}.

{{createConcatenatedOperation}} applies the same step-chaining check, so it rejects the inverse of 8647 on its own (we skip it on that exception) and returns the other 77. Their order and first result match 1.4.

*Expected*

{{findOperations}} returns the 77 valid inverse operations and skips EPSG:8647, ideally logging a warning. Alternatively, the inverse could be validated the same way as the forward operation, but then the forward and inverse results should at least agree.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)