GeoAPI

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

is depended upon by

Task - A task that needs to be done. GEO-1 Finish the creation of Java interfaces for geometries

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Hide
Permalink
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
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: