The ISO 19107 geometry specification has some constructs regarding curves which were counterintuitive to me. As I do not really understand anything unless I can explain it, this page represents an attempt to collate and digest some answers received on the GeoAPI development mailing list. This discussion concerns ISO/DIS 19107, which is distributed by the OGC as Topic 1: Feature Geometry.
As you read this page, keep in mind that much of the discussion may be centered around conceptual differences among the parts of curve geometry. This may have been the starting point, but the UML diagrams and the accompanying text are the content of the standard. These UML diagrams represent an expression of this mental conceptualization in a formalized framework. The expression of concepts may result in artifacts not present in the original conceptualization. Software systems must deal with these artifacts and if these software systems are to be interoperable, then a common treatment of artifacts must be adopted by all implementations. Decisions about how to handle artifacts are best made by those who grasp the concepts. This excludes me presently.
To express my question, I require a simplified version of Figure 15 from ISO 19107:
In summary, my brain viewed the relationship between Arc and ArcString (or between LineSegment and LineString, etc.) as an aggregation. I considered a LineString to be made up of many LineSegments. I was thinking that a LineString is a special type of curve just the same way that a PolyhedralSurface is a special type of surface. As such, I viewed inheritance as a really wierd way to express aggregation.
The particular UML expression of geometric concepts in 19107 contains artifacts which started me on this quest to figure out what was "really meant". There are three artifacts visible in the above diagram and in the explanatory text associated with the classes in the above figures:
param()
, startParam()
, and endParam()
respond differently if the implementing object is a curve or a curve segment.These artifacts cause a certain level of heartburn from a software design standpoint. Number three, in particular, represents very poor separation of concerns. Regardless of what the abstract notion of a curve may turn out to be, on the software engineering side of things a curve should be responsible for maintaining the relationship between the contained curve segments. Curve segments, when contemplating their startParam()
should not have to "figure it out for themselves" using a different class's data.
So this page is an attempt to understand how to cope with (at least) these artifacts. Keep this in mind as we delve into the abstractions and history of geometry. Any concepts developed here must make good sense from a software implementation standpoint or else they're not very useful to a software library.
This question prompted a response from the editor of ISO 19107, Dr. John Herring. The remainder of this article is my attempt to reformulate that response in my own words (with ample quotes from the good doctor) in order to see if I understand it correctly.
In ISO 19107, there are two issues driving a lot of the structural decisions: one is the geometry and one is the representation of that geometry in a coordinate space. Curve segments and Surface patches are the coordinate guys, and the Curves, Surfaces, etc, are the more abstract, almost Euclidean guys. Euclid would have understood the curve, but not the curve segment. It would be the early 17th century and Descartes before Euclidean space got coordinates. Makes you wonder how Geradus Mercator (who died 2 years before Rene was born) came up with the Mercator projection without coordinates  pure geometry I guess. 
Geometry is a distant memory to me now, so failing to grasp this distinction is probably the root of my problems. It appears that Geometry is related to coordinate representation by extension.

I gather from this discourse that there are two separable factors which logically distinguish a curve from a curve segment. The first is the notion of abstract geometry (curves) vs. coordinate geometry (curve segments). The second factor is the natural tension between algebraically wellbehaved curve segments and the more general notion of a curve which may or may not have a single simple defining equation (but which must be composed of algebraically wellbehaved segmentselse the infinite number of points along a curve couldn't be summarized by a finite number of parameters, ergo: be represented in a finite computing machine.)
It seems, however, that if the above distinction is correct, the ISO 19107 deviates from this definition at the start. From the above illustration, both curves and curve segments implement GM_GenericCurve, and this interface embodies the translation between locationonthecurve and position in an external CRS. According to the spec, the main difference between a curve and a curve segment is that curve segments advertise "continuity" information. 
Orientation is a real mathematical concept that refers to what you learned in calculus about left and right handed coordinate systems. Essentially, for a curve, or a surface, with either 1 or 2 degrees of freedom, the orientation of the object says something about the way it is embedded in the bigger space. For curves, there are two ways, indicating a positive and a negative direction along the preimage line. For a surface, there are two ways, indicating the concept of up and down. It takes a lot of mathematics, but it turns out that this "2 and only 2 orientations" thing is almost universal. The most obvious counterexamples are the Möbius band and the Klein bottle, both of which have only 1 or zero depending on how you generalize the concept. Both of these are surfaces, embedded in 3 and 4 D space respectively. Apparently you need 2D objects to muck up "exactly 2." You might say that these are the canonical pathologies, except that seems to be an oxymoron. 
Reference 
Comment 

Good technical read 

Good coverage of historical perspective 













