A. General

The solution to this is to use Facade objects which wrap the non-JTS geometry model classes. In order to avoid having to create and copy large numbers of Coordinate objects, JTS provides the CoordinateSequence interface. A CoordinateSequence-based adapter can be written for whatever structure the foreign model uses to represent sequences of points. JTS Geometry objects will still need to be created to represent the structure of the geometries containing the points, but these are relatively lightweight in comparison.

JTS intentionally allows topologically invalid geometries to be constructed for the following reasons:

1. It allows a wider set of geometry to be read, stored and written from external data sources
2. It allows geometries to be constructed and then validated
3. It avoids the costly overhead of validating topology every time a geometry is constructed

A Coordinate is a relatively simple class which represents a location on the Cartesian plane (optionally with an associated height value). Coordinates are usually treated as mutable objects, in order to simplify certain algorithms.

A Point is a subclass of Geometry that also represents a location on the Cartesian plane. It is a "heavy-weight" object (which for instance may contain an envelope) which support all methods that apply to Geometrys.

The two input geometries are decomposed into labelled topology graphs (GeometryGraphs). The labels are on the nodes and edges of the graphs. They contain full information about the topology of the node/edge in the points/lines/polygons of the original geometry. The labelled topology graphs are merged. This includes merging the labels wherever there is common nodes or edges. For each geometry at each node, the label information is propagated to all edges incident on that node. The resulting relationship (Intersection Matrix, or IM) is determined by the merged label information at the nodes of the merged graph. The labelling of each node and its incident edges is inspected, and the topological relationship information it contributes is added to the overall IM. At the end of this process the IM has been completely determined.

According to the SFS 1.1, section 2.1.3:

The boundary of a Point is the empty set

In some situations it is desirable to use a different definition for determining whether geometry endpoints are on their boundary. To support this, JTS provides the ability to specify a custom BoundaryNodeRule to the RelateOp class.

This is usually due to the fact that JTS predicates are computed exactly, using the full precision of the double-precision coordinates. Other geometry engines sometimes compute in lower precision, or round input coordinates, or use a tolerance when determining whether two lines intersect or cross.

As a specific example, in the following case:

A: POLYGON ((1368.62186660165 17722.3281808793, -1653 9287.5, 4038.14058906538 8613.02390521266, 1368.62186660165 17722.3281808793))

B: POLYGON ((-5846 9287.5, 7453 8380, 9082 16600, -6326.5 18842, -5846 9287.5))

LINESTRING (-5846 9287.5, 7453 8380)

LINESTRING (4038.140589065375 8613.02390521266, 4038.14058906538 8613.02390521266)

D. Robustness & Precision

TopologyExceptions are thrown when JTS encounters an inconsistency in the internal topology structures it creates to compute certain spatial operations (in particular, spatial predicates and overlay operations). These inconsistencies can happen for two reasons:

1. Invalid input geometry
2. Robustness failure due to floating-point roundoff errors causing incorrect results to be computed for internal operations (such as computing point-line orientation, computing the intersection of two line segments, or computing the noded arrangement of a set of line segments)

This is sometimes presented as: "When I intersect two geometries why is the result not contained in either of the originals?" or: "When I union two geometries why does the result not contain either of the originals?"

The short answer to this is that it's for the same reason that floating-point computation does not fully obey the axioms of arithmetic. JTS uses double-precision floating point numbers to represent the coordinates of geometries. The finite representation of real numbers forces rounding to take place during arithmetic computation. This means that operations are not commutative or associative, which has the effect that arithmetic and geometric axioms are not maintained.

A major JTS design goal is that the output of geometric operations is "close" to the theoreticall correct result (using some small epsilon of tolerance and a suitable geometric distance metric.) This goal is generally met by the JTS algorithms.

Many of the details of JTS algorithms (particularly in the areas of performance and robustness) are unique to JTS. However, the general design of the algorithms for computing spatial predicates and spatial overlay follow a generally accepted strategy for computing with 2-dimensional planar linear topological structures. Some papers which present similar approaches are:

• Schutte, Klamer. "An edge-labeling approach to concave polygon clipping"; submitted to ACM Transactions on Graphics, 1995.
• Vatti, B.R. "A Generic Solution to Polygon Clipping"; Communications of the ACM, 35(7), July 1992, pp.56-63.
• M. V. Leonov and A. G. Nikitin. "An Efficient Algorithm for a Closed Set of Boolean Operations on Polygonal Regions in the Plane (draft English translation)". A. P. Ershov Institute of Informatics Systems, Preprint 46, 1997.