geometry STOverlaps: Intersection Alone Is Not Enough

geometry STOverlaps asks a narrower question than whether two shapes share any points. I test equal and contained regions alongside a partial overlap. Those intersecting cases do not all satisfy the method’s overlap definition.

Everyday wording can describe one region inside another as overlapping. SQL Server’s spatial predicate has a specific topological meaning. A report should use that defined meaning rather than infer behavior from the name alone.

Compare five complete region relationships

The left input is a square extending from zero to four on both axes. The first right rectangle overlaps part of it and extends beyond it. Each region keeps area outside their common part.

The other inputs are equal to the left, entirely inside it, entirely around it, or separated from it. All geometries are valid polygons with reference identifier zero. These cases test more than a convenient partial overlap.

The query returns STOverlaps beside STIntersects. The second flag identifies any shared point set. It helps distinguish a zero overlap result caused by containment from one caused by separation.

WITH Inputs AS
(
    SELECT CaseId, CaseName, RightWkt
    FROM (VALUES
        (1, CAST('Partial overlap' AS varchar(20)), CAST('POLYGON((2 0, 6 0, 6 4, 2 4, 2 0))' AS varchar(200))),
        (2, 'Equal region', 'POLYGON((0 0, 4 0, 4 4, 0 4, 0 0))'),
        (3, 'Inside left', 'POLYGON((1 1, 2 1, 2 2, 1 2, 1 1))'),
        (4, 'Encloses left', 'POLYGON((-1 -1, 5 -1, 5 5, -1 5, -1 -1))'),
        (5, 'Separated', 'POLYGON((6 0, 8 0, 8 2, 6 2, 6 0))')
    ) AS v(CaseId, CaseName, RightWkt)
), Shapes AS
(
    SELECT CaseId, CaseName,
           geometry::STGeomFromText('POLYGON((0 0, 4 0, 4 4, 0 4, 0 0))', 0) AS LeftShape,
           geometry::STGeomFromText(RightWkt, 0) AS RightShape
    FROM Inputs
)
SELECT CaseId, CaseName, LeftShape.STOverlaps(RightShape) AS Overlaps,
       LeftShape.STIntersects(RightShape) AS Intersects
FROM Shapes
ORDER BY CaseId;

Read the five expected outcomes

The partial-overlap row should return one for both predicates. The shared region has the same dimension as the polygon inputs. That shared region is smaller than either complete input.

The equal-region row should return zero for Overlaps and one for Intersects. Its intersection is the complete region on both sides. That fails the requirement that the intersection not equal either input.

Both containment rows should also return zero for Overlaps and one for Intersects. Their common region equals the smaller input entirely. It does not matter which side contains the other for this result.

The separated row should return zero for both flags. It provides the ordinary nonintersection case. A zero Overlaps flag by itself cannot distinguish it from the equal or contained cases.

Apply the defined overlap rule

Overlap needs an intersection with the same dimension as the instances, and that intersection cannot equal either instance. The example uses polygons to make that rule concrete. Boundary-only contact would not supply a two-dimensional common region.

A general intersection check is useful when any contact belongs in the result. An overlap check is useful when this narrower partial relationship is required. Choose the predicate from the business rule rather than treating them as interchangeable.

I don’t use Overlaps as a complete classification of every spatial relationship. Equality, containment and contact can all require additional distinctions. A false flag only says that this particular predicate’s conditions were not met.

The input types matter because the rule includes dimension. This bounded example does not establish every mixed-type combination. Keep relevant types in a separate test set when the source accepts lines or points too.

Keep spatial evidence within its scope

The common reference identifier is deliberate. A mismatched reference can produce NULL instead of a meaningful zero or one. Such a result should not be silently classified as a separated region.

These are planar coordinates in an abstract agreed unit. No earth-surface or physical-unit interpretation is implied. The shapes are also exact examples, without an application tolerance for nearly coincident boundaries.

The query changes no data and creates no schema objects. Its five flags demonstrate logical relationships, not index efficiency. A larger search needs its own execution evidence after the relationship is defined.

Keep the equal and contained cases when adapting the query. A test containing only partial overlap and separation would make STOverlaps look like a generic intersection flag. The complete population makes that mistaken equivalence visible.

Test the equal and contained cases, and the name stops fooling you.

Intersecting is not overlapping, it is a wider relationship than STOverlaps tests.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.