## Package org.opengis.geometry

Root package for geometries.

See:
Description

Interface Summary
Boundary: The abstract root data type for all the data types used to represent the boundary of geometric objects.
BoundingBox: Represents a two-dimensional envelope.
DirectPosition: Holds the coordinates for a position within some coordinate reference system.
Envelope: A minimum bounding box or rectangle.
Geometry: Root class of the geometric object taxonomy.
PositionFactory: A factory for managing direct position creation.
Precision: Specifies the precision model of the direct positions in a geometry.
PrecisionFactory: A factory for managing direct position creation.
TransfiniteSet: A possibly infinite set; restricted only to values.

Class Summary
PrecisionType: The rounding policy used for a precision model.

Exception Summary
MismatchedDimensionException: Indicates that an operation cannot be completed properly because of a mismatch in the dimensions of object attributes.
MismatchedReferenceSystemException: Indicates that an object cannot be constructed because of a mismatch in the reference systems of geometric components.
UnmodifiableGeometryException: Indicates that an operation is not allowed on a geometry object because it is unmodifiable.

## Package org.opengis.geometry Description

Root package for geometries. The following is adapted from Feature Geometry (Topic 1) specification.

The geometry packages contain the various classes for coordinate geometry. All of these classes through the root class `Geometry` inherit an optional association to a coordinate reference system. All direct positions exposed through the interfaces defined in this specification shall be in the coordinate reference system of the geometric object accessed. All elements of a geometric complex, composite, or aggregate shall be associated to the same coordinate reference system. When instances of `Geometry` are aggregated in another `Geometry` (such as a `Aggregate`, or `Complex`) which already has a coordinate reference system specified, then these elements are assumed to be in that same coordinate reference system unless otherwise specified.

The geometry package has several internal packages that separate primitive geometric objects, aggregates and complexes, which have a more elaborate internal structure than simple aggregates.

Any object that inherits the semantics of the `Geometry` acts as a set of direct positions. Its behavior will be determined by which direct positions it contains. Objects under `Primitive` will be open, that is, they will not contain their boundary points; curves will not contain their end points, surfaces will not contain their boundary curves, and solids will not contain their bounding surfaces. Objects under `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 `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. This distinction appears as an inheritance relationship between `CompositeCurve` and `OrientableCurve`. The primary semantics of a `CompositeCurve` is as a closed `Geometry`, but it may also act as an open `Geometry` under `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 `Primitive` or `Complex`, where the distinction first occurs. Even though these protocols have been inherited from the same operations defined at `Geometry`, 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.

`Geometry` and `Primitive` are purely abstract in the sense that no object or data structure from an application can instantiate them directly. Instances of these classes must be instances of one of their non-abstract subtypes, such as `Point`, `Curve`, or `Surface`. This is not the case for `Complex`, which can be directly instantiated by an application, and need not be an instance of one of the non-abstract subclasses of `Composite`.

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