GeoAPI
  1. GeoAPI
  2. GEO-14

Clash in the semantic of contains(...) method in CompositeCurve

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0, 2.0
    • Fix Version/s: None
    • Component/s: geometry
    • Labels:
      None
    • Number of attachments :
      0

      Description

      In the geometry package, CompositeCurve extends (indirectly) both Primitive and Complex. Consequently, there is a clash in the semantics of some set theoretic operation. Specifically, Primitive.contains(...) (returns FALSE for end points) is different from Complex.contains(...) (returns TRUE for end points).

        Issue Links

          Activity

          Hide
          Martin Desruisseaux added a comment -

          Actually this class is documented in section 6.1 of ISO 19107:

          Objects under GM_Primitive will be open, that is, they will not contain their boundary points; (...) Objects under GM_Complex will be closed, that is, they will contain their boundary points. This leads to some apparent ambiguity. A representation of a line as a primitive must reference its end points, but will not contain these points as a set of direct positions. A representation of a line as a complex will also reference its end points, and will contain these points as a set of direct positions. This means that identical digital representations will have slightly different semantics depending on whether they are accessed as primitives or complexes.

          This difference of semantics is most striking in the GM_CompositeCurve. Composite curves are used to represent features whose geometry could also be represented as curve primitives. From a cartographic point of view, these two representations are not different. From a topological point of view, they are different. (...) The primary semantics of a GM_CompositeCurve is as a closed GM_Object, but it may also act as an open GM_Object under GM_Primitive operations. Interface protocols depending upon the topological details of this object will have to be distinguished as to whether they have been inherited from GM_Primitive or GM_Complex, where the distinction first occurs. Even though these protocols have been inherited from the same operations defined at GM_Object, they will act differently depending upon the branch of the inheritance tree from which they have inherited semantics. Creators of implementation profiles may take this into account and use a proxy mechanism for realization relationships that cause semantic dissonance. Such a procedure will be necessary in object-oriented programming and databases in systems that disallow multiple inheritance or make limiting assumptions about method binding.

          Show
          Martin Desruisseaux added a comment - Actually this class is documented in section 6.1 of ISO 19107: Objects under GM_Primitive will be open, that is, they will not contain their boundary points; (...) Objects under GM_Complex will be closed, that is, they will contain their boundary points. This leads to some apparent ambiguity. A representation of a line as a primitive must reference its end points, but will not contain these points as a set of direct positions. A representation of a line as a complex will also reference its end points, and will contain these points as a set of direct positions. This means that identical digital representations will have slightly different semantics depending on whether they are accessed as primitives or complexes. This difference of semantics is most striking in the GM_CompositeCurve . Composite curves are used to represent features whose geometry could also be represented as curve primitives. From a cartographic point of view, these two representations are not different. From a topological point of view, they are different. (...) The primary semantics of a GM_CompositeCurve is as a closed GM_Object , but it may also act as an open GM_Object under GM_Primitive operations. Interface protocols depending upon the topological details of this object will have to be distinguished as to whether they have been inherited from GM_Primitive or GM_Complex , where the distinction first occurs. Even though these protocols have been inherited from the same operations defined at GM_Object , they will act differently depending upon the branch of the inheritance tree from which they have inherited semantics. Creators of implementation profiles may take this into account and use a proxy mechanism for realization relationships that cause semantic dissonance. Such a procedure will be necessary in object-oriented programming and databases in systems that disallow multiple inheritance or make limiting assumptions about method binding.

            People

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

              Dates

              • Created:
                Updated: