Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 3.06
-
Fix Version/s: 3.07
-
Component/s: Referencing
-
Labels:None
Description
Conversion of sourceCRS to targetCRS fails when the CRS have the following characteristics:
- The sourceCRS is a tree-dimensional CompoundCRS, made of a ProjectedCRS with a VerticalCRS.
- The targetCRS is a two-dimensional GeographicCRS.
- The sourceCRS and targetCRS use different datum. Nevertheless, all Bursa-Wolf parameters are declared equal to 0
- The VerticalCRS in the sourceCRS does not measure height above the ellipsoid.
The current behavior is to fail with an exception like the one below:
org.opengis.referencing.operation.OperationNotFoundException: Aucune transformation du système "CompoundCRS[ETRS89 + Sigma level]" vers "GeographicCRS[WGS 84]" n'est disponible.
at org.geotoolkit.referencing.operation.DefaultCoordinateOperationFactory.createOperationStep(DefaultCoordinateOperationFactory.java:1205)
at org.geotoolkit.referencing.operation.DefaultCoordinateOperationFactory.createOperation(DefaultCoordinateOperationFactory.java:349)
at org.geotoolkit.referencing.operation.CachingCoordinateOperationFactory.createOperation(CachingCoordinateOperationFactory.java:222)
at org.geotoolkit.referencing.operation.CachingCoordinateOperationFactory.createOperation(CachingCoordinateOperationFactory.java:251)
at org.geotoolkit.referencing.CRS.findMathTransform(CRS.java:1221)
at org.geotoolkit.referencing.CRS.findMathTransform(CRS.java:1185)
at org.geotoolkit.referencing.operation.WithEPSG_Test.testProjected3D_to_2D(WithEPSG_Test.java:93)
This is the wanted behavior, because accurate conversion require first converting the "sigma-level" height (or any non-standard height) to ellipsoidal height before to apply the datum shift, and in the test case used above the referencing module doesn't know how to perform this height conversion.
However in the special case where the height is going to be dropped anyway in the targetCRS and when the (latitude, longitude) are not affected by the datum shift because all Bursa-Wolf parameters are explicitly set to 0, it is correct to process anyway. We should allow the referencing module to detect such special case.
Actually the last paragraph in the above description is wrong. Even if the Bursa-Wolf parameters are explicitly set to zero, the ellipsoids can still be different. This is the case for example between NAD83 and WGS84 datum. With the proposed patch we will nevertheless proceed in very last ressort before throwing an exception, when every attempt to handle correctly the height have failed. This is based on the assumption that when the BursaWolf parameters between a pair of datum is zero, most users consider those datum as equivalent in practice (e.g. NAD83 vs WGS84).