GeoAPI

Unidirectional "Composition" aggregation implemented in the backwards direction too.

Details

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

Description

The "Composition" aggregation depicted in Fig. 26, p. 95 of ISO/DIS 19107 goes from GM_Composite to GM_Primitive. It is also specialized to relate the following classes:

  • GM_CompositePoint -> GM_Point
  • GM_CompositeCurve -> GM_OrientableCurve
  • GM_CompositeSurface -> GM_OrientableSurface
  • GM_CompositeSolid -> GM_Solid

The backwards direction (against the arrow in the UML) is named in all these associations, translating to a getComposite() property on the following GeoAPI interfaces:

  • OrientableCurve
  • OrientableSurface

Note that the reverse direction is not implemented on the Point or Solid interfaces. Resolving this problem involves making a determination as to whether to believe the arrow on the UML diagram or the fact that the reverse direction is named and has a multiplicity defined (0..n). Whatever the decision may be, it should be a consistent decision for Primitive and all subinterfaces.

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
Bryce Nordgren added a comment -

Dr. John Herring (editor or 19107) addressed the issue of providing role names for the reverse direction of associations in the GeoAPI-devel email list. The relevant excerpt is attached here:

As for backward, but non-navigable pointers being named, this actually makes sense, if you realize that navigability is a representation issue. Association roles that need to be navigated often, need explicit ways to get about, those that aren't navigated often can be reconstructed by other means (scanning the entire dataset if necessary, but indexes work fine, too).

So for example, the relationship between curve segment and curve is only navigable from GM_Curve to GM_CurveSegment, but is named and
given a cardinality in the other. There are reasons for this. First, the association is a strong aggregation, and a curve segment can exist only in one curve at a time. On the other hand, a GM_CurveSegment can be implemented independently of its containment in GM_Curve and so can
exist independently of the class GM_Curve (although maybe not persistently). This is not the usual interpretation of a strong aggregation, and so the "curve" role in the association is given a "0..1" cardinality, saying the segment can be in a most 1 curve, but can exist without a curve. A bit amusingly, the GM_Curve class cannot exist without a least one GM_CurveSegment (1..* on the segment role). The logic here is that a geometry is useless unless you know where it is. Of course, this is almost the definition of topology, and so like most absolutes, it is questionable. Note that in 19107, topology can exist without geometry, but geometry cannot exist without coordinates. There is a lot of blood on the bridge on that one.

Of course, some behavior between curve and curve segment is common and thus GM_GenericCurve (an interface) was created to hold what we thought of as the most important common behavior, as common operations.

Show
Bryce Nordgren added a comment - Dr. John Herring (editor or 19107) addressed the issue of providing role names for the reverse direction of associations in the GeoAPI-devel email list. The relevant excerpt is attached here: As for backward, but non-navigable pointers being named, this actually makes sense, if you realize that navigability is a representation issue. Association roles that need to be navigated often, need explicit ways to get about, those that aren't navigated often can be reconstructed by other means (scanning the entire dataset if necessary, but indexes work fine, too). So for example, the relationship between curve segment and curve is only navigable from GM_Curve to GM_CurveSegment, but is named and given a cardinality in the other. There are reasons for this. First, the association is a strong aggregation, and a curve segment can exist only in one curve at a time. On the other hand, a GM_CurveSegment can be implemented independently of its containment in GM_Curve and so can exist independently of the class GM_Curve (although maybe not persistently). This is not the usual interpretation of a strong aggregation, and so the "curve" role in the association is given a "0..1" cardinality, saying the segment can be in a most 1 curve, but can exist without a curve. A bit amusingly, the GM_Curve class cannot exist without a least one GM_CurveSegment (1..* on the segment role). The logic here is that a geometry is useless unless you know where it is. Of course, this is almost the definition of topology, and so like most absolutes, it is questionable. Note that in 19107, topology can exist without geometry, but geometry cannot exist without coordinates. There is a lot of blood on the bridge on that one. Of course, some behavior between curve and curve segment is common and thus GM_GenericCurve (an interface) was created to hold what we thought of as the most important common behavior, as common operations.

People

  • Assignee:
    Unassigned
    Reporter:
    Bryce Nordgren
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: