Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## org.opengis.geometry.primitive
Interface Primitive

All Superinterfaces:
  Geometry, TransfiniteSet

All Known Subinterfaces:
  CompositeCurve, CompositeSolid, CompositeSurface, Curve, OrientableCurve, OrientablePrimitive, OrientableSurface, Point, PolyhedralSurface, Ring, Shell, Solid, Surface, Tin, TriangulatedSurface

    @UML(identifier="GM_Primitive",
         specification=ISO_19107)
    public interface Primitive

extends Geometry

Abstract root class of the geometric primitives. Its main purpose is to define the basic "boundary" operation that ties the primitives in each dimension together. A geometric primitive is a geometric object that is not decomposed further into other primitives in the system. This includes curves and surfaces, even though they are composed of curve segments and surface patches, respectively. Those curve segments and surface patches cannot exist outside the context of a primitive.

Any geometric object that is used to describe a feature is a collection of geometric primitives. A collection of geometric primitives may or may not be a geometric complex. Geometric complexes have additional properties such as closure by boundary operations and mutually exclusive component parts. `Primitive` and `Complex` share most semantics, in the meaning of operations and attributes. There is an exception in that a `Primitive` shall not contain its boundary (except in the trivial case of point where the boundary is empty), while a complex shall contain its boundary in all cases.

Since:
  GeoAPI 1.0
Version:
  ISO 19107
See Also:
  `PrimitiveFactory.createPrimitive(org.opengis.geometry.Envelope)`
TODO:
  Some associations are commented out for now.

Method Summary
`Set<Complex>` | `getComplexes()` Returns the set of complexes which contains this primitive.
`Composite` | `getComposite()` Returns the owner of this primitive.
`Set<Primitive>` | `getContainedPrimitives()` Returns the `Primitive`s which are by definition coincident with this one.
`Set<Primitive>` | `getContainingPrimitives()` Returns the `Primitive`s which are by definition coincident with this one.
`OrientablePrimitive[]` | `getProxy()` Returns the orientable primitives associated with this primitive.

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

Methods inherited from interface TransfiniteSet
`contains, contains, difference, equals, intersection, intersects, symmetricDifference, union`

Method Detail

### getContainedPrimitives

    @UML(identifier="containedPrimitive",
         obligation=MANDATORY,
         specification=ISO_19107)
    Set<Primitive> getContainedPrimitives()

  Returns the `Primitive`s which are by definition coincident with this one. This allows applications to override the `TransfiniteSet<DirectPosition>` interpretation and its associated computational geometry, and declare one `Primitive` to be "interior to" another. This set should normally be empty when the `Primitive`s are within a complex, since in that case the boundary information is sufficient for most cases. This association should not be used when the two `Primitive`s are not close to one another. The intent is to allow applications to compensate for inherent and unavoidable round off, truncation, and other mathematical problems indigenous to computer calculations.

  Returns:
    The set of primitives contained into this primitive.
  See Also:
    `getContainingPrimitives()`
  TODO:
    Using a `Set` returns type allows the user to add or remove element in this set at his convenience. Is it the right interpretation of this specification?

### getContainingPrimitives

    @UML(identifier="containingPrimitive",
         obligation=MANDATORY,
         specification=ISO_19107)
    Set<Primitive> getContainingPrimitives()

  Returns the `Primitive`s which are by definition coincident with this one.

  Returns:
    The set of primitives which contains this primitive.
  See Also:
    `getContainedPrimitives()`
  TODO:
    Using a `Set` returns type allows the user to add or remove element in this set at his convenience. Is it the right interpretation of this specification?, Should we stretch out some relation with contained primitive? For example should we update the specification with something like the following? "Invoking `B.getContainingPrimitive().add(A)` is equivalent to invoking `A.getContainedPrimitive().add(B)`".

### getComplexes

    @UML(identifier="complex",
         obligation=MANDATORY,
         specification=ISO_19107)
    Set<Complex> getComplexes()

  Returns the set of complexes which contains this primitive. A `Primitive` may be in several complexes. This association may not be navigable in this direction (from primitive to complex), depending on the implementation.

  Returns:
    The set of complexes which contains this primitive.

### getComposite

    @Association(value="Composition")
    @UML(identifier="composite",
         obligation=OPTIONAL,
         specification=ISO_19107)
    Composite getComposite()

  Returns the owner of this primitive. This method is optional since the association in ISO 19107 is navigable only from `Composite` to `Primitive`, not the other way.

  Returns:
    The owner of this primitive, or `null` if the association is not available or not implemented that way.
  See Also:
    `Composite.getGenerators()`

### getProxy

    @Association(value="Oriented")
    @UML(identifier="proxy",
         obligation=CONDITIONAL,
         specification=ISO_19107)
    OrientablePrimitive[] getProxy()

  Returns the orientable primitives associated with this primitive. Each `Primitive` of dimension 1 or 2 is associated to two orientable primitives, 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 mandatory for curves and `surfaces`, and is not allowed for Points and solids. The later should return `null`.

  Returns:
    The orientable primitives as an array of length 2, or `null` if none.
  See Also:
    `OrientablePrimitive.getPrimitive()`

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

Copyright © 1994-2008 Open Geospatial Consortium. All Rights Reserved.