Details

    • Type: Sub-task Sub-task
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0, 2.1, 2.2
    • Fix Version/s: 2.3-M3
    • Component/s: referencing
    • Labels:
      None
    • Number of attachments :
      0

      Description

      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.

        Issue Links

          Activity

          Hide
          Martin Desruisseaux added a comment -

          Documented on trunk.

          Show
          Martin Desruisseaux added a comment - Documented on trunk.
          Hide
          Martin Desruisseaux added a comment -

          VerticalDatumType was defined in the ISO 19111 specification published in 2003. However this code list has been removed from the 2007 revision. Whatever we keep them in GeoAPI or not is a new open issue. We may want to keep this code list for historical reasons, and also because it has programmatic value since the proposed replacement - the anchor point - is a free text.

          If we keep VerticalDatumType for technical and historical reasons, maybe we can keep the ELLIPSOIDAL value for the same reasons.

          Show
          Martin Desruisseaux added a comment - VerticalDatumType was defined in the ISO 19111 specification published in 2003. However this code list has been removed from the 2007 revision. Whatever we keep them in GeoAPI or not is a new open issue. We may want to keep this code list for historical reasons, and also because it has programmatic value since the proposed replacement - the anchor point - is a free text. If we keep VerticalDatumType for technical and historical reasons, maybe we can keep the ELLIPSOIDAL value for the same reasons.
          Hide
          Martin Desruisseaux added a comment -

          The ELLIPSOIDAL code is not in GeoAPI 3.0.0. Whether we keep the VerticalDatumType enumeration as a whole is an other question.

          Show
          Martin Desruisseaux added a comment - The ELLIPSOIDAL code is not in GeoAPI 3.0.0. Whether we keep the VerticalDatumType enumeration as a whole is an other question.

            People

            • Assignee:
              Martin Desruisseaux
              Reporter:
              Martin Desruisseaux
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 hour
                1h
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 hour
                1h