fix(boolean-contains): treat an equal two-vertex line as contained

[spokodev]

Problem

booleanContains documents the duality contains(a, b) === within(b, a), and as a containment relation it is reflexive: a geometry contains an equal copy of itself. Both properties break for the simplest LineString case.

Two identical 2-vertex lines, e.g. [[0,0],[10,0]] and [[0,0],[10,0]], return contains = false.

The cause is in isLineOnLine, which only records an interior overlap when a vertex of lineString2 is strictly interior to lineString1 (ignoreEndVertices: true). For two equal 2-vertex lines, both of line2's vertices are endpoints, so neither is strictly interior, and the function reports no interior overlap even though the lines are identical.

This is a vertex-counting artifact rather than a geometric one: inserting a redundant collinear midpoint into line2 ([[0,0],[5,0],[10,0]]) flips the answer to true, because the added vertex is now strictly interior. The same line, described with one more vertex, should not change containment.

Fix

Keep the existing vertex check, and additionally probe each segment midpoint of lineString2. If a segment's midpoint is strictly interior to lineString1, the segment shares interior with lineString1, so an interior overlap exists even when no vertex of lineString2 is strictly interior. This is the minimal probe that handles the equal-2-vertex case without changing any other result.

Tests

Fixture added: test/true/LineString/LineString/LineContainsEqualTwoVertexLine.geojson (two identical 2-vertex lines must contain each other). It fails on the current source and passes after the fix.

• boolean-contains: 40/40.
• boolean-within (duality regression): 40/40.

[mfedderly]

Thank you!

This also aligns with PostGIS which I've been using as the source of truth for these things:

SELECT ST_Contains(
     ST_MakeLine(ST_MakePoint(0, 0), ST_MakePoint(10, 0)),
     ST_MakeLine(ST_MakePoint(0, 0), ST_MakePoint(10, 0))
);

st_contains 
-------------
 t
(1 row)

[mfedderly]

Overall performance hit looks to be ~8%, which is probably acceptable for a correctness change. We can try to optimize this further later. This particular input would be caught by just a straight lineString1 === lineString2 coordinate comparison.

Before:

LineIsNotContainedByLine x 4,344,327 ops/sec ±0.36% (99 runs sampled)
LineContainsEqualTwoVertexLine x 6,485,881 ops/sec ±0.59% (97 runs sampled)
LineIsContainedByLine x 4,659,957 ops/sec ±0.44% (98 runs sampled)
LinesExactlySame x 2,936,249 ops/sec ±0.39% (99 runs sampled)

After:

LineIsNotContainedByLine x 4,003,998 ops/sec ±0.23% (99 runs sampled)
LineContainsEqualTwoVertexLine x 4,819,185 ops/sec ±0.15% (101 runs sampled)
LineIsContainedByLine x 4,122,535 ops/sec ±0.30% (97 runs sampled)
LinesExactlySame x 2,733,925 ops/sec ±0.15% (101 runs sampled)