geom

package geom

Ordering

Alphabetic

Visibility

Public
Protected

Package Members

package impl
package util

Type Members

class Coordinate extends Comparable[Coordinate] with Cloneable with Serializable
Annotations
@SerialVersionUID()
trait CoordinateFilter extends AnyRef
An interface for classes which use the values of the coordinates in a {link Geometry}.
An interface for classes which use the values of the coordinates in a {link Geometry}. Coordinate filters can be used to implement centroid and envelope computation, and many other functions.
CoordinateFilter is an example of the Gang-of-Four Visitor pattern.
Note: it is not recommended to use these filters to mutate the coordinates. There is no guarantee that the coordinate is the actual object stored in the source geometry. In particular, modified values may not be preserved if the source Geometry uses a non-default {link CoordinateSequence}. If in-place mutation is required, use {link CoordinateSequenceFilter}.
Version
1.7
See also
Geometry#apply(CoordinateFilter)
CoordinateSequenceFilter
class CoordinateList extends ArrayList[Coordinate]
Annotations
@SerialVersionUID()
trait CoordinateSequence extends Cloneable
class CoordinateSequenceComparator extends Comparator[CoordinateSequence]
trait CoordinateSequenceFactory extends AnyRef
A factory to create concrete instances of {link CoordinateSequence}s.
A factory to create concrete instances of {link CoordinateSequence}s. Used to configure {link GeometryFactory}s to provide specific kinds of CoordinateSequences.
Version
1.7
trait CoordinateSequenceFilter extends AnyRef
An interface for classes which process the coordinates in a {link CoordinateSequence}.
An interface for classes which process the coordinates in a {link CoordinateSequence}. A filter can either record information about each coordinate, or change the value of the coordinate. Filters can be used to implement operations such as coordinate transformations, centroid and envelope computation, and many other functions. {link Geometry} classes support the concept of applying a CoordinateSequenceFilter to each {link CoordinateSequence}s they contain.
For maximum efficiency, the execution of filters can be short-circuited by using the {link #isDone} method.
CoordinateSequenceFilter is an example of the Gang-of-Four Visitor pattern.
Note: In general, it is preferable to treat Geometrys as immutable. Mutation should be performed by creating a new Geometry object (see {link GeometryEditor} and {link GeometryTransformer} for convenient ways to do this). An exception to this rule is when a new Geometry has been created via {link Geometry#copy()}. In this case mutating the Geometry will not cause aliasing issues, and a filter is a convenient way to implement coordinate transformation.
Version
1.7
See also
Geometry#apply(CoordinateFilter)
GeometryTransformer
GeometryEditor
Geometry#apply(CoordinateSequenceFilter)
class CoordinateXY extends Coordinate
Annotations
@SerialVersionUID()
class CoordinateXYM extends Coordinate
Annotations
@SerialVersionUID()
class CoordinateXYZM extends Coordinate
Coordinate subclass supporting XYZM ordinates.
Coordinate subclass supporting XYZM ordinates.
This data object is suitable for use with coordinate sequences with dimension = 4 and measures = 1.
Annotations
@SerialVersionUID()
Since
1.16
class Envelope extends Comparable[Envelope] with Serializable
Annotations
@SerialVersionUID()
abstract class Geometry extends Cloneable with Comparable[Geometry] with Serializable
Annotations
@SerialVersionUID()
class GeometryCollection extends Geometry
Models a collection of {link Geometry}s of arbitrary type and dimension.
Models a collection of {link Geometry}s of arbitrary type and dimension.
Annotations
@SerialVersionUID()
Version
1.7
class GeometryCollectionIterator extends Iterator[Geometry]
trait GeometryComponentFilter extends AnyRef
Geometry classes support the concept of applying a GeometryComponentFilter filter to the Geometry.
Geometry classes support the concept of applying a GeometryComponentFilter filter to the Geometry. The filter is applied to every component of the Geometry which is itself a Geometry and which does not itself contain any components. (For instance, all the {link LinearRing}s in {link Polygon}s are visited, but in a {link MultiPolygon} the {link Polygon}s themselves are not visited.) Thus the only classes of Geometry which must be handled as arguments to {link #filter} are {link LineString}s, {link LinearRing}s and {link Point}s.
A GeometryComponentFilter filter can either record information about the Geometry or change the Geometry in some way. GeometryComponentFilter is an example of the Gang-of-Four Visitor pattern.
Version
1.7
class GeometryFactory extends Serializable
Annotations
@SerialVersionUID()
trait GeometryFilter extends AnyRef
GeometryCollection classes support the concept of applying a GeometryFilter to the Geometry.
GeometryCollection classes support the concept of applying a GeometryFilter to the Geometry. The filter is applied to every element Geometry. A GeometryFilter can either record information about the Geometry or change the Geometry in some way. GeometryFilter is an example of the Gang-of-Four Visitor pattern.
Version
1.7
class IntersectionMatrix extends Cloneable
class LineSegment extends Comparable[LineSegment] with Serializable
Annotations
@SerialVersionUID()
class LineString extends Geometry with Lineal
Models an OGC-style LineString.
Models an OGC-style LineString. A LineString consists of a sequence of two or more vertices, along with all points along the linearly-interpolated curves (line segments) between each pair of consecutive vertices. Consecutive vertices may be equal. The line segments in the line may intersect each other (in other words, the linestring may "curl back" in itself and self-intersect. Linestrings with exactly two identical points are invalid.
A linestring must have either 0 or 2 or more points. If these conditions are not met, the constructors throw an {link IllegalArgumentException}
Annotations
@SerialVersionUID()
Version
1.7
trait Lineal extends AnyRef
Identifies {link Geometry} subclasses which are 1-dimensional and have components which are {link LineString}s.
class LinearRing extends LineString
Annotations
@SerialVersionUID()
class MultiLineString extends GeometryCollection with Lineal
Models a collection of {link LineString}s.
Models a collection of {link LineString}s.
Any collection of LineStrings is a valid MultiLineString.
Annotations
@SerialVersionUID()
Version
1.7
class MultiPoint extends GeometryCollection with Puntal
Models a collection of {link Point}s.
Models a collection of {link Point}s.
Any collection of Points is a valid MultiPoint.
Annotations
@SerialVersionUID()
Version
1.7
class MultiPolygon extends GeometryCollection with Polygonal
Models a collection of {link Polygon}s.
Models a collection of {link Polygon}s.
As per the OGC SFS specification, the Polygons in a MultiPolygon may not overlap, and may only touch at single points. This allows the topological point-set semantics to be well-defined.
Annotations
@SerialVersionUID()
Version
1.7
class Point extends Geometry with Puntal
Represents a single point.
Represents a single point.
A Point is topologically valid if and only if:
- the coordinate which defines it (if any) is a valid coordinate (i.e. does not have an NaN X or Y ordinate)
Annotations
@SerialVersionUID()
Version
1.7
class Polygon extends Geometry with Polygonal
Represents a polygon with linear edges, which may include holes.
Represents a polygon with linear edges, which may include holes. The outer boundary (shell) and inner boundaries (holes) of the polygon are represented by {link LinearRing}s. The boundary rings of the polygon may have any orientation. Polygons are closed, simple geometries by definition.
The polygon model conforms to the assertions specified in the <A HREF="http://www.opengis.org/techno/specs.htm">OpenGIS Simple Features Specification for SQL</A>.
A Polygon is topologically valid if and only if:
- the coordinates which define it are valid coordinates
- the linear rings for the shell and holes are valid (i.e. are closed and do not self-intersect)
- holes touch the shell or another hole at at most one point (which implies that the rings of the shell and holes must not cross)
- the interior of the polygon is connected, or equivalently no sequence of touching holes makes the interior of the polygon disconnected (i.e. effectively split the polygon into two pieces).
Annotations
@SerialVersionUID()
Version
1.7
trait Polygonal extends AnyRef
Identifies {link Geometry} subclasses which are 2-dimensional and have components which have {link Lineal} boundaries.
class PrecisionModel extends Serializable with Comparable[PrecisionModel]
Annotations
@SerialVersionUID()
trait Puntal extends AnyRef
Identifies {link Geometry} subclasses which are 0-dimensional and with components which are {link Point}s.
class TopologyException extends RuntimeException
class Triangle extends AnyRef

Value Members

object Coordinate extends Serializable
A lightweight class used to store coordinates on the 2-dimensional Cartesian plane.
A lightweight class used to store coordinates on the 2-dimensional Cartesian plane.
It is distinct from {link Point}, which is a subclass of {link Geometry}. Unlike objects of type {link Point} (which contain additional information such as an envelope, a precision model, and spatial reference system information), a Coordinate only contains ordinate values and accessor methods.
Coordinates are two-dimensional points, with an additional Z-ordinate. If an Z-ordinate value is not specified or not defined, constructed coordinates have a Z-ordinate of NaN (which is also the value of NULL_ORDINATE). The standard comparison functions ignore the Z-ordinate. Apart from the basic accessor functions, JTS supports only specific operations involving the Z-ordinate.
Implementations may optionally support Z-ordinate and M-measure values as appropriate for a {link CoordinateSequence}. Use of {link #getZ()} and {link #getM()} accessors, or {link #getOrdinate(int)} are recommended.
Annotations
@SerialVersionUID()
Version
1.16
object CoordinateArrays
Useful utility functions for handling Coordinate arrays
Useful utility functions for handling Coordinate arrays
Version
1.7
object CoordinateList extends Serializable
A list of {link Coordinate}s, which may be set to prevent repeated coordinates from occurring in the list.
A list of {link Coordinate}s, which may be set to prevent repeated coordinates from occurring in the list.
Annotations
@SerialVersionUID()
Version
1.7
object CoordinateSequence
The internal representation of a list of coordinates inside a Geometry.
The internal representation of a list of coordinates inside a Geometry.
This allows Geometries to store their points using something other than the JTS {link Coordinate} class. For example, a storage-efficient implementation might store coordinate sequences as an array of x's and an array of y's. Or a custom coordinate class might support extra attributes like M-values.
Implementing a custom coordinate storage structure requires implementing the {link CoordinateSequence} and {link CoordinateSequenceFactory} interfaces. To use the custom CoordinateSequence, create a new {link GeometryFactory} parameterized by the CoordinateSequenceFactory The {link GeometryFactory} can then be used to create new {link Geometry}s. The new Geometries will use the custom CoordinateSequence implementation.
For an example, see the code for {link ExtendedCoordinateExample}.
Version
1.7
See also
CoordinateArraySequenceFactory
PackedCoordinateSequenceFactory
ExtendedCoordinateExample
object CoordinateSequenceComparator
Compares two {link CoordinateSequence}s.
Compares two {link CoordinateSequence}s. For sequences of the same dimension, the ordering is lexicographic. Otherwise, lower dimensions are sorted before higher. The dimensions compared can be limited; if this is done ordinate dimensions above the limit will not be compared.
If different behaviour is required for comparing size, dimension, or coordinate values, any or all methods can be overridden.
object CoordinateSequences
Utility functions for manipulating {link CoordinateSequence}s
Utility functions for manipulating {link CoordinateSequence}s
Version
1.7
object CoordinateXY extends Serializable
Coordinate subclass supporting XY ordinates.
Coordinate subclass supporting XY ordinates.
This data object is suitable for use with coordinate sequences with dimension = 2.
The {link Coordinate#z} field is visible, but intended to be ignored.
Annotations
@SerialVersionUID()
Since
1.16
object CoordinateXYM extends Serializable
Coordinate subclass supporting XYM ordinates.
Coordinate subclass supporting XYM ordinates.
This data object is suitable for use with coordinate sequences with dimension = 3 and measures = 1.
The {link Coordinate#z} field is visible, but intended to be ignored.
Annotations
@SerialVersionUID()
Since
1.16
object Coordinates
Useful utility functions for handling Coordinate objects.
object Dimension
Provides constants representing the dimensions of a point, a curve and a surface.
Provides constants representing the dimensions of a point, a curve and a surface. Also provides constants representing the dimensions of the empty geometry and non-empty geometries, and the wildcard constant {link #DONTCARE} meaning "any dimension". These constants are used as the entries in {link IntersectionMatrix}s.
Version
1.7
object Envelope extends Serializable
Defines a rectangular region of the 2D coordinate plane.
Defines a rectangular region of the 2D coordinate plane. It is often used to represent the bounding box of a {link Geometry}, e.g. the minimum and maximum x and y values of the {link Coordinate}s.
Envelopes support infinite or half-infinite regions, by using the values of Double.POSITIVE_INFINITY and Double.NEGATIVE_INFINITY. Envelope objects may have a null value.
When Envelope objects are created or initialized, the supplies extent values are automatically sorted into the correct order.
Annotations
@SerialVersionUID()
Version
1.7
object Geometry extends Serializable
A representation of a planar, linear vector geometry.
A representation of a planar, linear vector geometry. <P>
<H3>Binary Predicates</H3> Because it is not clear at this time what semantics for spatial analysis methods involving GeometryCollections would be useful, GeometryCollections are not supported as arguments to binary predicates or the relate method.
<H3>Overlay Methods</H3>
The overlay methods return the most specific class possible to represent the result. If the result is homogeneous, a Point, LineString, or Polygon will be returned if the result contains a single element; otherwise, a MultiPoint, MultiLineString, or MultiPolygon will be returned. If the result is heterogeneous a GeometryCollection will be returned. <P>
Because it is not clear at this time what semantics for set-theoretic methods involving GeometryCollections would be useful, GeometryCollections are not supported as arguments to the set-theoretic methods.
<H4>Representation of Computed Geometries </H4>
The SFS states that the result of a set-theoretic method is the "point-set" result of the usual set-theoretic definition of the operation (SFS 3.2.21.1). However, there are sometimes many ways of representing a point set as a Geometry. <P>
The SFS does not specify an unambiguous representation of a given point set returned from a spatial analysis method. One goal of JTS is to make this specification precise and unambiguous. JTS uses a canonical form for Geometrys returned from overlay methods. The canonical form is a Geometry which is simple and noded: <UL> <LI> Simple means that the Geometry returned will be simple according to the JTS definition of isSimple. <LI> Noded applies only to overlays involving LineStrings. It means that all intersection points on LineStrings will be present as endpoints of LineStrings in the result. </UL> This definition implies that non-simple geometries which are arguments to spatial analysis methods must be subjected to a line-dissolve process to ensure that the results are simple.
<H4> Constructed Points And The Precision Model </H4>
The results computed by the set-theoretic methods may contain constructed points which are not present in the input Geometry s. These new points arise from intersections between line segments in the edges of the input Geometrys. In the general case it is not possible to represent constructed points exactly. This is due to the fact that the coordinates of an intersection point may contain twice as many bits of precision as the coordinates of the input line segments. In order to represent these constructed points explicitly, JTS must truncate them to fit the PrecisionModel. <P>
Unfortunately, truncating coordinates moves them slightly. Line segments which would not be coincident in the exact result may become coincident in the truncated representation. This in turn leads to "topology collapses" -- situations where a computed element has a lower dimension than it would in the exact result. <P>
When JTS detects topology collapses during the computation of spatial analysis methods, it will throw an exception. If possible the exception will report the location of the collapse. <P>
Geometry Equality
There are two ways of comparing geometries for equality: structural equality and topological equality.
Structural Equality
Structural Equality is provided by the {link #equalsExact(Geometry)} method. This implements a comparison based on exact, structural pointwise equality. The {link #equals(Object)} is a synonym for this method, to provide structural equality semantics for use in Java collections. It is important to note that structural pointwise equality is easily affected by things like ring order and component order. In many situations it will be desirable to normalize geometries before comparing them (using the {link #norm()} or {link #normalize()} methods). {link #equalsNorm(Geometry)} is provided as a convenience method to compute equality over normalized geometries, but it is expensive to use. Finally, {link #equalsExact(Geometry, double)} allows using a tolerance value for point comparison.
Topological Equality
Topological Equality is provided by the {link #equalsTopo(Geometry)} method. It implements the SFS definition of point-set equality defined in terms of the DE-9IM matrix. To support the SFS naming convention, the method {link #equals(Geometry)} is also provided as a synonym. However, due to the potential for confusion with {link #equals(Object)} its use is discouraged.
Since {link #equals(Object)} and {link #hashCode()} are overridden, Geometries can be used effectively in Java collections.
Annotations
@SerialVersionUID()
Version
1.7
object GeometryCollectionIterator
Iterates over all {link Geometry}s in a {link Geometry}, (which may be either a collection or an atomic geometry).
Iterates over all {link Geometry}s in a {link Geometry}, (which may be either a collection or an atomic geometry). The iteration sequence follows a pre-order, depth-first traversal of the structure of the GeometryCollection (which may be nested). The original Geometry object is returned as well (as the first object), as are all sub-collections and atomic elements. It is simple to ignore the intermediate GeometryCollection objects if they are not needed.
Version
1.7
object GeometryFactory extends Serializable
Supplies a set of utility methods for building Geometry objects from lists of Coordinates.
Supplies a set of utility methods for building Geometry objects from lists of Coordinates.
Note that the factory constructor methods do not change the input coordinates in any way. In particular, they are not rounded to the supplied PrecisionModel. It is assumed that input Coordinates meet the given precision.
Instances of this class are thread-safe.
Annotations
@SerialVersionUID()
Version
1.7
object IntersectionMatrix
Models a Dimensionally Extended Nine-Intersection Model (DE-9IM) matrix.
Models a Dimensionally Extended Nine-Intersection Model (DE-9IM) matrix. DE-9IM matrices (such as "212FF1FF2") specify the topological relationship between two {link Geometry}s. This class can also represent matrix patterns (such as "T*T******") which are used for matching instances of DE-9IM matrices.
Methods are provided to: <UL> <LI> set and query the elements of the matrix in a convenient fashion <LI> convert to and from the standard string representation (specified in SFS Section 2.1.13.2). <LI> test to see if a matrix matches a given pattern string. </UL> <P>
For a description of the DE-9IM and the spatial predicates derived from it, see the OGC 99-049 OpenGIS Simple Features Specification for SQL, as well as OGC 06-103r4 OpenGIS Implementation Standard for Geographic information - Simple feature access - Part 1: Common architecture (which provides some further details on certain predicate specifications).
The entries of the matrix are defined by the constants in the {link Dimension} class. The indices of the matrix represent the topological locations that occur in a geometry (Interior, Boundary, Exterior). These are provided as constants in the {link Location} class.
Version
1.7
object LineSegment extends Serializable
Represents a line segment defined by two {link Coordinate}s.
Represents a line segment defined by two {link Coordinate}s. Provides methods to compute various geometric properties and relationships of line segments.
This class is designed to be easily mutable (to the extent of having its contained points public). This supports a common pattern of reusing a single LineSegment object as a way of computing segment properties on the segments defined by arrays or lists of {link Coordinate}s.
Annotations
@SerialVersionUID()
Version
1.7
object LinearRing extends Serializable
Models an OGC SFS LinearRing.
Models an OGC SFS LinearRing. A LinearRing is a {link LineString} which is both closed and simple. In other words, the first and last coordinate in the ring must be equal, and the interior of the ring must not self-intersect. Either orientation of the ring is allowed.
A ring must have either 0 or 4 or more points. The first and last points must be equal (in 2D). If these conditions are not met, the constructors throw an {link IllegalArgumentException}
Annotations
@SerialVersionUID()
Version
1.7
object Location
Constants representing the different topological locations which can occur in a {link Geometry}.
Constants representing the different topological locations which can occur in a {link Geometry}. The constants are also used as the row and column indices of DE-9IM {link IntersectionMatrix}es.
Version
1.7
object PrecisionModel extends Serializable
Specifies the precision model of the {link Coordinate}s in a {link Geometry}.
Specifies the precision model of the {link Coordinate}s in a {link Geometry}. In other words, specifies the grid of allowable points for all Geometrys.
The {link #makePrecise(Coordinate)} method allows rounding a coordinate to a "precise" value; that is, one whose precision is known exactly.
Coordinates are assumed to be precise in geometries. That is, the coordinates are assumed to be rounded to the precision model given for the geometry. JTS input routines automatically round coordinates to the precision model before creating Geometries. All internal operations assume that coordinates are rounded to the precision model. Constructive methods (such as boolean operations) always round computed coordinates to the appropriate precision model.
Currently three types of precision model are supported:
- FLOATING - represents full double precision floating point. This is the default precision model used in JTS
- FLOATING_SINGLE - represents single precision floating point.
- FIXED - represents a model with a fixed number of decimal places. A Fixed Precision Model is specified by a scale factor. The scale factor specifies the size of the grid which numbers are rounded to. Input coordinates are mapped to fixed coordinates according to the following equations: <UL> <LI> jtsPt.x = round( (inputPt.x * scale ) / scale <LI> jtsPt.y = round( (inputPt.y * scale ) / scale </UL>
For example, to specify 3 decimal places of precision, use a scale factor of 1000. To specify -3 decimal places of precision (i.e. rounding to the nearest 1000), use a scale factor of 0.001.
Coordinates are represented internally as Java double-precision values. Since Java uses the IEEE-394 floating point standard, this provides 53 bits of precision. (Thus the maximum precisely representable integer is 9,007,199,254,740,992 - or almost 16 decimal digits of precision).
JTS binary methods currently do not handle inputs which have different precision models. The precision model of any constructed geometric value is undefined.
Annotations
@SerialVersionUID()
Version
1.7
object TopologyException extends Serializable
Indicates an invalid or inconsistent topological situation encountered during processing
Indicates an invalid or inconsistent topological situation encountered during processing
Version
1.7
object Triangle
Represents a planar triangle, and provides methods for calculating various properties of triangles.
Represents a planar triangle, and provides methods for calculating various properties of triangles.
Version
1.7

Packages

geom

package geom

Package Members

Type Members

Value Members

Geometry Equality

Structural Equality

Topological Equality

Ungrouped

Packages

geom

package geom

Package Members

Type Members

Value Members

Geometry Equality

Structural Equality

Topological Equality

Ungrouped

geom