ISO 19111 departure in VerticalDatumType.ELLIPSOIDAL

ISO 19111 states explicitly that VerticalCRS can not be used for ellipsoidal height. The VerticalDatumType code list defined by ISO do not contains an ELLIPSOIDAL item. Their intend is apparently to make sure that a geographic CRS with an ellipsoidal height is constructed as a GeographicCRS instance backed by a three-dimensional EllipsoidalCS, not as a CompoundCRS.

However the legacy OGC 01-009 specification had such item in their code list, maybe because OGC 01-009 didn't had the concept of three-dimensional GeographicCRS. GeoAPI ported this OGC 01-009 concept in their code list, in violation with ISO 19111 restriction:

http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/datum/VerticalDatumType.html#ELLIPSOIDAL

GeoAPI put the burden of converting CompoundCRS(GeographicCRS + ellispoidal VerticalCRS) to a three-dimensional GeographicCRS on the library side. The rational are:

• The WKT specification defines three-dimensional GeographicCRS as COMPD_CS(GEOGCS + VERT_CS) because this specification was created before ISO 19111. So a WKT parser needs to be able to express an ellipsoidal height and merge it later with a geographic CRS anyway.

• We need the capability to express ellipsoidal height as a VerticalCRS in order to allow VerticalExtent.getVerticalCRS() to actually returns a VerticalCRS. Otherwise we would need to relax the return type to CoordinateReferenceSystem and put more burden on the user side, who needs to find the vertical component himself.

• If we can't express ellipsoidal height as VerticalCRS, then any API expecting a vertical CRS would actually needs to accept an arbitrary CoordinateReferenceSystem (loosing type-safety) and analyse it for extracting its vertical component.