Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Won't Fix
-
Affects Version/s: 3.00, 3.01, 3.02, 3.03, 3.04, 3.05, 3.06, 3.07, 3.08, 3.09, 3.10, 3.11, 3.12, 3.13, 3.14, 3.15
-
Fix Version/s: 3.16
-
Component/s: Referencing
-
Labels:None
Description
In current CRS implementation, WKT as below:
- {{COMPD_CS[..., GEOGCS[...], VERT_CS[...]]}}
built the exact object counterpart:
- CompoundCRS(... 2D-GeographicCRS ... VerticalCRS)
We should consider to automatically translate the above in a 3D-GeographicCRS object instead, i.e., a GeographicCRS instance using a tridimensional EllipsoidCS. This can be done only if the VerticalCRS is height above the ellipsoid. For other case (eight above geoid, mean sea level, etc.), a CompoundCRS still necessary.
A 3D-GeographicCRS with height above the ellipsoid is more convenient than a CompoundCRS for "geographic to geocentric" operations: a 3D-GeographicCRS can already be processed directly by CoordinateOperationFactory.createTransformationStep(GeographicCRS, GeocentricCRS). A 3D-CompoundCRS can not: the height component is ignored.
We should consider to:
- Identify when a vertical axis is the "height above the ellipsoid" case.
- In the previous point is true, allows WKT parser to translate automatically a COMPD_CS into a 3D-GeographicCRS.
- Conversely, the WKT formatter should split a 3D-GeographicCRS into a CompoundCRS.
- Check what is EPSG usage in their database.
- Test, especially with TransformationTest.testCompoundCRS().
Given a 3D-GeographicCRS, CoordinateOperationFactory should already be capable to includes the height in its operation chain. But it will need to be tested.
This issue is imported from http://jira.codehaus.org/browse/GEOT-401
Issue Links
- is depended upon by
-
GEOTK-81
OperationNotFoundException when sourceCRS is a ProjectedCRS + VerticalCRS
-
As of
GEOTK-81, DefaultCoordinateOperationFactory can now handle CompoundCRS. There is no immediate need to replace CompoundCRS by SingleCRS at WKT parsing time, especially since it would cause the lost of EPSG code for the horizontal and vertical components (unless relying on non-public Identifier3D API) and those EPSG codes are better to be preserved for proper AuthorityBackedFactory work.It is probably safer to parse the CRS as described in its WKT form, and let the user call himself ReferencingFactoryContainer.toGeodetic3D(...) if he really wants to replace the CompoundCRS by a three-dimensional SingleCRS.
GEOTK-81, DefaultCoordinateOperationFactory can now handle CompoundCRS. There is no immediate need to replace CompoundCRS by SingleCRS at WKT parsing time, especially since it would cause the lost of EPSG code for the horizontal and vertical components (unless relying on non-public Identifier3D API) and those EPSG codes are better to be preserved for proper AuthorityBackedFactory work. It is probably safer to parse the CRS as described in its WKT form, and let the user call himself ReferencingFactoryContainer.toGeodetic3D(...) if he really wants to replace the CompoundCRS by a three-dimensional SingleCRS.