Namespace Spatial4n.Core.Shapes

A collection of Shape objects, analogous to an OGC GeometryCollection. The implementation demands a List (with random access) so that the order can be retained if an application requires it, although logically it's treated as an unordered Set, mostly.

Ideally, Relate(IShape) should return the same result no matter what the shape order is, although the default implementation can be order dependent when the shapes overlap; see RelateContainsShortCircuits(). To improve performance slightly, the caller could order the shapes by largest first so that Relate() will have a greater chance of short-circuit'ing sooner. As the Shape contract states; it may return intersects when the best answer is actually contains or within.If any shape intersects the provided shape then that is the answer.

This implementation is not optimized for a large number of shapes; relate is O(N). A more sophisticated implementation might do an R-Tree based on bbox'es, for example.

A circle, also known as a point-radius since that is what it is comprised of.

A Point with X & Y coordinates.

A rectangle aligned with the axis (i.e. it is not at an angle).

In geospatial contexts, it may cross the international date line (-180 longitude) if CrossesDateLine however it cannot pass the poles although it may span the globe. It spans the globe if the X coordinate (Longitude) goes from -180 to 180 as seen from MinX and MaxX.

The base interface defining a geometric shape. Shape instances should be instantiated via one of the create* methods on a SpatialContext or by reading WKT which calls those methods; they should not be created directly.

Shapes are generally immutable and thread-safe. If a particular shape has a Reset(...) method then its use means the shape is actually mutable. Mutating shape state is considered expert and should be done with care.

The set of spatial relationships. Naming is consistent with OGC spec conventions as seen in SQL/MM and others.

No equality case. If two IShape instances are equal then the result might be CONTAINS (preferred) or WITHIN.
Client logic may have to be aware of this edge condition; Spatial4n testing certainly does.

The "CONTAINS" and "WITHIN" wording here is inconsistent with OGC; these here map to OGC "COVERS" and "COVERED BY", respectively. The distinction is in the boundaries; in Spatial4n there is no boundary distinction -- boundaries are part of the shape as if it was an "interior", with respect to OGC's terminology.