## Interface OrientablePrimitive

• All Superinterfaces:
`Geometry`, `Primitive`, `TransfiniteSet`
All Known Subinterfaces:
`CompositeCurve`, `CompositeSurface`, `Curve`, `OrientableCurve`, `OrientableSurface`, `PolyhedralSurface`, `Ring`, `Shell`, `Surface`, `Tin`, `TriangulatedSurface`

```@UML(identifier="GM_OrientablePrimitive",
specification=ISO_19107)
public interface OrientablePrimitive
extends Primitive```
Primitives that can be mirrored into new geometric objects in terms of their internal local coordinate systems (manifold charts). For curves, the orientation reflects the direction in which the curve is traversed, that is, the sense of its parameterization. When used as boundary curves, the surface being bounded is to the "left" of the oriented curve. For surfaces, the orientation reflects from which direction the local coordinate system can be viewed as right handed, the "top" or the surface being the direction of a completing z-axis that would form a right-handed system. When used as a boundary surface, the bounded solid is "below" the surface. The orientation of points and solids has no immediate geometric interpretation in 3-dimensional space.

`OrientablePrimitive` objects are essentially references to geometric primitives that carry an "orientation" reversal flag (either "+" or "-") that determines whether this primitive agrees or disagrees with the orientation of the referenced object.

NOTE: There are several reasons for subclassing the "positive" primitives under the orientable primitives. First is a matter of the semantics of subclassing. Subclassing is assumed to be a "is type of" hierarchy. In the view used, the "positive" primitive is simply the orientable one with the positive orientation. If the opposite view were taken, and orientable primitives were subclassed under the "positive" primitive, then by subclassing logic, the "negative" primitive would have to hold the same sort of geometric description that the "positive" primitive does. The only viable solution would be to separate "negative" primitives under the geometric root as being some sort of reference to their opposite. This adds a great deal of complexity to the subclassing tree. To minimize the number of objects and to bypass this logical complexity, positively oriented primitives are self-referential (are instances of the corresponding primitive subtype) while negatively oriented primitives are not.
Since:
GeoAPI 1.0
Author:
Martin Desruisseaux (IRD)
• ### Method Summary

All Methods
Modifier and Type Method Description
`int` `getOrientation()`
Determines which of the two possible orientations this object represents.
`Primitive` `getPrimitive()`
Returns the primitive associated with this `OrientablePrimitive`.
• ### Methods inherited from interface Geometry

`clone, distance, getBuffer, getCentroid, getClosure, getConvexHull, getCoordinateDimension, getCoordinateReferenceSystem, getDimension, getEnvelope, getMaximalComplex, getMbRegion, getPrecision, getRepresentativePoint, isCycle, isMutable, isSimple, toImmutable, transform, transform`
• ### Methods inherited from interface Primitive

`getBoundary, getComplexes, getComposite, getContainedPrimitives, getContainingPrimitives, getProxy`
• ### Methods inherited from interface TransfiniteSet

`contains, contains, difference, equals, intersection, intersects, symmetricDifference, union`
• ### Method Detail

• #### getOrientation

```@UML(identifier="orientation",
obligation=MANDATORY,
specification=ISO_19107)
int getOrientation()```
Determines which of the two possible orientations this object represents.
Returns:
+1 for a positive orientation, or -1 for a negative orientation.
• #### getPrimitive

```@Association("Oriented")
@UML(identifier="primitive",
obligation=OPTIONAL,
specification=ISO_19107)
Primitive getPrimitive()```
Returns the primitive associated with this `OrientablePrimitive`. Each primitive of dimension 1 or 2 is associated to two `OrientablePrimitive`s, one for each possible orientation. For curves and surfaces, there are exactly two orientable primitives for each geometric object. For the positive orientation, the orientable primitive shall be the corresponding curve or surface.

This method is optional since the association in ISO 19107 is navigable only from `Primitive` to `OrientablePrimitive`, not the other way.

Returns:
The primitive, or `null` if the association is not available or not implemented that way.
`Primitive.getProxy()`