ST_Relate — Tests if two geometries have a topological relationship matching an Intersection Matrix pattern, or computes their Intersection Matrix
boolean ST_Relate(
geometry geomA, geometry geomB, text intersectionMatrixPattern)
;
text ST_Relate(
geometry geomA, geometry geomB)
;
text ST_Relate(
geometry geomA, geometry geomB, integer boundaryNodeRule)
;
These functions allow testing and evaluating the spatial (topological) relationship between two geometries, as defined by the Dimensionally Extended 9-Intersection Model (DE-9IM).
The DE-9IM is specified as a 9-element matrix indicating the dimension of the intersections between the Interior, Boundary and Exterior of two geometries. It is represented by a 9-character text string using the symbols 'F', '0', '1', '2' (e.g. 'FF1FF0102'
).
A specific kind of spatial relationship can be tested by matching the intersection matrix to an intersection matrix pattern. Patterns can include the additional symbols 'T' (meaning "intersection is non-empty") and '*' (meaning "any value"). Common spatial relationships are provided by the named functions ST_Contains, ST_ContainsProperly, ST_Covers, ST_CoveredBy, ST_Crosses, ST_Disjoint, ST_Equals, ST_Intersects, ST_Overlaps, ST_Touches, and ST_Within. Using an explicit pattern allows testing multiple conditions of intersects, crosses, etc in one step. It also allows testing spatial relationships which do not have a named spatial relationship function. For example, the relationship "Interior-Intersects" has the DE-9IM pattern T********
, which is not evaluated by any named predicate.
For more information refer to Section 5.1, “Determining Spatial Relationships”.
Variant 1: Tests if two geometries are spatially related according to the given intersectionMatrixPattern
.
Unlike most of the named spatial relationship predicates, this does NOT automatically include an index call. The reason is that some relationships are true for geometries which do NOT intersect (e.g. Disjoint). If you are using a relationship pattern that requires intersection, then include the && index call. |
It is better to use a named relationship function if available, since they automatically use a spatial index where one exists. Also, they may implement performance optimizations which are not available with full relate evalation. |
Variant 2: Returns the DE-9IM matrix string for the spatial relationship between the two input geometries. The matrix string can be tested for matching a DE-9IM pattern using ST_RelateMatch.
Variant 3: Like variant 2, but allows specifying a Boundary Node Rule. A boundary node rule allows finer control over whether the endpoints of MultiLineStrings are considered to lie in the DE-9IM Interior or Boundary. The boundaryNodeRule
values are:
1
: OGC-Mod2 - line endpoints are in the Boundary if they occur an odd number of times. This is the rule defined by the OGC SFS standard, and is the default for ST_Relate
.
2
: Endpoint - all endpoints are in the Boundary.
3
: MultivalentEndpoint - endpoints are in the Boundary if they occur more than once. In other words, the boundary is all the "attached" or "inner" endpoints (but not the "unattached/outer" ones).
4
: MonovalentEndpoint - endpoints are in the Boundary if they occur only once. In other words, the boundary is all the "unattached" or "outer" endpoints.
This function is not in the OGC spec, but is implied. see s2.1.13.2
This method implements the OGC Simple Features Implementation Specification for SQL 1.1.
s2.1.1.2 // s2.1.13.3
This method implements the SQL/MM specification.
SQL-MM 3: 5.1.25
Performed by the GEOS module
Enhanced: 2.0.0 - added support for specifying boundary node rule.
Enhanced: 3.0.0 enabled support for |
Using the boolean-valued function to test spatial relationships.
SELECT ST_Relate('POINT(1 2)', ST_Buffer( 'POINT(1 2)', 2), '0FFFFF212'); st_relate ----------- t SELECT ST_Relate(POINT(1 2)', ST_Buffer( 'POINT(1 2)', 2), '*FF*FF212'); st_relate ----------- t
Testing a custom spatial relationship pattern as a query condition, with &&
to enable using a spatial index.
-- Find compounds that properly intersect (not just touch) a poly (Interior Intersects) SELECT c.* , p.name As poly_name FROM polys AS p INNER JOIN compounds As c ON c.geom && p.geom AND ST_Relate(p.geom, c.geom,'T********');
Computing the intersection matrix for spatial relationships.
SELECT ST_Relate( 'POINT(1 2)', ST_Buffer( 'POINT(1 2)', 2)); ----------- 0FFFFF212 SELECT ST_Relate( 'LINESTRING(1 2, 3 4)', 'LINESTRING(5 6, 7 8)' ); ----------- FF1FF0102
Using different Boundary Node Rules to compute the spatial relationship between a LineString and a MultiLineString with a duplicate endpoint (3 3)
:
Using the OGC-Mod2 rule (1) the duplicate endpoint is in the interior of the MultiLineString, so the DE-9IM matrix entry [aB:bI] is 0
and [aB:bB] is F
.
Using the Endpoint rule (2) the duplicate endpoint is in the boundary of the MultiLineString, so the DE-9IM matrix entry [aB:bI] is F
and [aB:bB] is 0
.
WITH data AS (SELECT 'LINESTRING(1 1, 3 3)'::geometry AS a_line, 'MULTILINESTRING((3 3, 3 5), (3 3, 5 3))':: geometry AS b_multiline ) SELECT ST_Relate( a_line, b_multiline, 1) AS bnr_mod2, ST_Relate( a_line, b_multiline, 2) AS bnr_endpoint FROM data; bnr_mod2 | bnr_endpoint -----------+-------------- FF10F0102 | FF1F00102