BBoxStrategy and PointVectorStrategy miss a shape on a query edge at 0 when one zero is -0.0 and the other +0.0, so BBoxStrategy finds a point Intersecting a rectangle but not Within it

BBoxStrategy and PointVectorStrategy (module lucene/spatial-extras, both @lucene.experimental) answer a spatial query with DoublePoint range queries on the stored coordinates. An inclusive bound taken from the query rectangle is passed to DoublePoint.newRangeQuery unchanged, and DoublePoint ranges follow Double#compareTo, where -0.0 sorts just below +0.0. spatial4j, whose relate decides SpatialOperation.evaluate for a point and a rectangle, compares coordinates there as primitives, where -0.0 == 0.0. So a shape exactly on a query edge at x = 0 or y = 0 whose coordinate is the other zero silently drops out: a point stored at (-0.0, 5) against Rect(0.0, 10, 0, 10) gives hits [BBox Intersects 1, BBox IsWithin 0, PointVector Intersects 0, PointVector IsWithin 0] instead of [1, 1, 1, 1]. BBoxStrategy's Intersects uses only exclusive bounds, moved with Math.nextUp/Math.nextDown, which give the same double for both zeros, so it still finds the point: BBoxStrategy contradicts itself. The same miss affects BBoxStrategy Contains, PointVectorStrategy circle queries, the Y axis, non-geo contexts and the reverse direction. Only missed hits, never extra ones. Every release that ships the strategies has it (PointVectorStrategy since 4.0.0, BBoxStrategy since 4.10.0) through 10.6.0 and main. Widening a zero bound to [-0.0, +0.0] before the range query is built fixes it.

1. The contract. SpatialStrategy.makeQuery builds "a Query based principally on SpatialOperation and Shape" (SpatialStrategy.java:116). SpatialOperation's predicates are explained by "the source implementation of evaluate", and "Lucene-spatial makes no distinction of shape boundaries" (query/SpatialOperation.java:30-35). Intersects is relate(...).intersects() (:89-95); IsWithin is "CoveredBy ... (boundary-neutral)", relate == WITHIN || equals (:124-136).
2. BBoxStrategy, inclusive bounds. makeWithin (bbox/BBoxStrategy.java:523) states "docMinX >= queryExtent.getMinX() ... docMaxX <= queryExtent.getMaxX()" (:526-527) and builds inclusive ranges (:531-532, :546-547); makeContains (:283) is the mirror (:286-287, :291-292, :304-305).
3. BBoxStrategy, the range helper makeNumericRangeQuery (:651-672): a null bound becomes ±infinity (:654-660); an exclusive lower bound becomes Math.nextUp(min) (:663), an exclusive upper bound Math.nextDown(max) (:667), then DoublePoint.newRangeQuery(fieldname, min, max) (:670). An inclusive bound is passed unchanged. Fix site. Every caller passes its null side as exclusive, so that side ends at -/+Double.MAX_VALUE.
4. BBoxStrategy Intersects is "has an envelope AND NOT disjoint" (makeIntersects, :473, :491-494), and makeDisjoint (:366) uses only exclusive bounds, e.g. docMaxX < query minX (:393). For the edge 0.0 that range is [-Double.MAX_VALUE, -4.9E-324] (printed bbox__maxX:[-1.7976931348623157E308 TO -4.9E-324]), which holds neither zero, so the point is not disjoint and is found. Math.nextUp/nextDown return the same double for -0.0 and +0.0.
5. PointVectorStrategy. makeQuery (vector/PointVectorStrategy.java:188-205) answers both Intersects and IsWithin of a rectangle with makeWithin(bbox) (:194), and a circle with makeWithin(circle.getBoundingBox()) plus a distance filter (:196-198). makeWithin (:209-222) adds MUST ranges on x and y via rangeQuery (:228-238), which passes the bounds unchanged to DoublePoint.newRangeQuery (:238). Fix site.
6. The order. DoublePoint.newRangeQuery: "Ranges are inclusive ... Range comparisons are consistent with Double#compareTo(Double)" (lucene/core/.../document/DoublePoint.java:210-213). So [0.0, 10] excludes a stored -0.0, and [-10, -0.0] excludes a stored +0.0.

Point (-0.0, 5), query Rect(minX=0.0, maxX=10, minY=0, maxY=10):

• BBox IsWithin needs docMinX in [0.0, Double.MAX_VALUE] (printed bbox__minX:[0.0 TO 1.7976931348623157E308]): -0.0 sorts below 0.0, so 0 hits.
• PointVector, both operations, needs x in [0.0, 10.0]: 0 hits.
• BBox Intersects needs the point to be outside every disjoint range, e.g. docMaxX in [-Double.MAX_VALUE, -4.9E-324] or docMinX in [10.000000000000002, Double.MAX_VALUE]: -0.0 is in none of them, so 1 hit.

• Same point, other zero (control, default IndexWriterConfig, main and 10.6.0): makePoint(0.0, 5) gives [1, 1, 1, 1]; makePoint(-0.0, 5) and WKT POINT(-0 5) give [1, 0, 0, 0].
• Parsed query strings: a point at longitude -0.0, latitude 51.5 is missed by IsWithin(ENVELOPE(0, 180, 90, -90)) (the eastern hemisphere) in both strategies and by Intersects(ENVELOPE(0, 20, 60, 0)) in PointVectorStrategy; RecursivePrefixTreeStrategy finds it. The western neighbour cell still finds the point, so it drops out on one side only.
• Circles: Circle(Pt(5, 0), 5 deg) has a spatial4j-computed bounding box with west edge +0.0; PointVectorStrategy misses a point at (-0.0, 0) that lies on the circle.
• Bounded-exhaustive sweep (exhaustive over a small domain: coordinates {-10, -0.0, +0.0, 10}, 121 query rectangles, 137 shapes, 5 operations, 4 strategies, geo and non-geo; plus 7 selected circles; 439,082 checks): 6,120 zero-sign defects, all missed matches (per context BBox IsWithin 1,184, BBox Contains 1,313, PointVector Intersects 276 and IsWithin 276, circles 5-6 per operation); 0 for BBox Intersects / IsDisjointTo / IsEqualTo, RecursivePrefixTreeStrategy and SerializedDVStrategy; 0 with the fix.

Not part of this finding: IsEqualTo (an exact match, which agrees with spatial4j's own Double.compare-based equals); IsWithin of two rectangles identical up to a zero's sign (spatial4j's equals again); BBoxStrategy Contains / IsEqualTo extra hits for non-rectangles, which occur without any zero because other shapes are indexed by their bounding box (BBoxStrategy.java:54-55).

• Who is hit. Applications that index points or rectangles with BBoxStrategy and query with IsWithin or Contains, or with PointVectorStrategy and query a rectangle (Intersects or IsWithin) or a circle. Both strategies are @lucene.experimental (BBoxStrategy.java:71, PointVectorStrategy.java:80); otherwise default codec, IndexWriterConfig and searcher, any index size, geo and non-geo contexts.
• When. A shape exactly on a query edge at x = 0 or y = 0 (the prime meridian, the equator, a hemisphere or tile boundary, or a 0 bound in a non-geo context), with -0.0 on one side and +0.0 on the other. The query edge is usually an ordinary +0.0; -0.0 comes from caller data, for example WKT or text such as -0 or -0.0, a negated 0.0 (a 0-degree "W" longitude stored as -lon), or Math.ceil of a small negative number. The WKT reader keeps the sign, in POINT(-0 5) and in ENVELOPE(-10, -0, 10, 0). In the hunt's producer search none of 4,114 spatial4j circle bounding boxes had a -0.0 edge, but spatial4j's pointOnBearing returned x = -0.0 in 88 of 82,280 calls, all from 8 start points on longitude 180 (2 of them the poles), e.g. from (180, 10) with bearing 0 and distance 90: another way -0.0 can reach caller data.
• Size of the error. Only missed matches, never extra ones: a raw inclusive bound at one zero only leaves out a coordinate at the other zero, and every inclusive range sits in MUST or SHOULD clauses (BBoxStrategy's only MUST_NOT clauses, :390, :398, :494, hold term queries on ±180 and the exclusive-only disjoint query; PointVectorStrategy has none). In the sweep all 6,120 zero-sign defects were misses. The shape drops out on one side of the edge only; the neighbouring cell still finds it.
• Silent. No exception and no assertion, with assertions on and off.
• Other strategies are fine. In the point-on-edge cases tested, RecursivePrefixTreeStrategy and SerializedDVStrategy in the same module return the hit, and so do the core geo queries: the XYShape and LatLonShape box queries and the XYPointField polygon query (48 checks, 0 mismatches), and LatLonPoint.newBoxQuery, LatLonPoint.newPolygonQuery and XYPointField.newBoxQuery (32 checks, 0 mismatches, run by this doc's fact check).
• Likelihood: rare. It needs an exact -0.0 on exactly a zero edge, in two experimental strategies; the searches recorded on 2026-11-02 found no report of it since 4.0.0 (2012).

The test is the hunt's minimal repro with the license header added and its one comment reworded so that it passes :lucene:spatial-extras:check -x test (google-java-format); the code is otherwise identical. It uses newIndexWriterConfig(), the usual randomized test config; a plain IndexWriterConfig fails the same way (the independent reproducer's test and this doc's control). Executed: seed 5EED1113 (codec Asserting(Lucene104)), 5 random-seed iterations and the plain config; not every codec was run, and no codec dependence is expected because the order comes from DoublePoint's sortable encoding of the double (DoublePoint.java:176).

Executed: gradle on main e1faeba08bde with assertions on and off (seed 5EED1113) and 5 iterations with a random master seed: fails every time; with the fix it passes. The hunt's runs fail the same way.

Use the same test as the regression test.

cp $REPRO/TestNegativeZeroOnZeroEdge.java $LUCENE/lucene/spatial-extras/src/test/org/apache/lucene/spatial/
cd $LUCENE && ./gradlew :lucene:spatial-extras:test --tests TestNegativeZeroOnZeroEdge -Ptests.seed=5EED1113 -Ptests.asserts=true
# also with -Ptests.asserts=false; 5 of 5 random-seed iterations (-Ptests.iters=5) failed the same way

TestNegativeZeroOnZeroEdge > testPointAtNegativeZeroOnZeroEdge FAILED
    org.junit.ComparisonFailure: expected:<[1, [1, 1, 1]]> but was:<[1, [0, 0, 0]]>
        at __randomizedtesting.SeedInfo.seed([5EED1113:6E82DED7DFEFBC3D]:0)
        at app/junit@4.13.2/org.junit.Assert.assertEquals(Assert.java:117)
        at app/junit@4.13.2/org.junit.Assert.assertEquals(Assert.java:146)
        at app//org.apache.lucene.spatial.TestNegativeZeroOnZeroEdge.testPointAtNegativeZeroOnZeroEdge(TestNegativeZeroOnZeroEdge.java:60)
:lucene:spatial-extras:test (FAILURE): 1 test, 1  failure

# JUnit's diff brackets: expected "[1, 1, 1, 1]", actual "[1, 0, 0, 0]"
# with the fix: :lucene:spatial-extras:test (SUCCESS): 1 test

• Contract. BBoxStrategy "supports all SpatialOperations" (BBoxStrategy.java:47), qualified at :57 as "Supports most SpatialOperations but not Overlaps", and its makeQuery maps Intersects, IsWithin and Contains to their own queries (:265-271); PointVectorStrategy: "Intersects and IsWithin is supported" (PointVectorStrategy.java:63-64). The query is built "principally on SpatialOperation" (SpatialStrategy.java:116), whose predicates are defined by evaluate() and are boundary-neutral (SpatialOperation.java:30-35, :124). BBoxStrategy's own comments state the Within and Contains conditions as plain comparisons, docMinX >= queryExtent.getMinX() (:526-527, :286-287), which hold for -0.0 against 0.0. Nothing says -0.0 is a different position from 0.0.
• Tests. StrategyTestCase.testOperation asserts operation.evaluate(indexedShape, queryShape) == match before it searches (StrategyTestCase.java:233), and RandomSpatialOpStrategyTestCase uses operation.evaluate as truth (prefix/RandomSpatialOpStrategyTestCase.java:103). TestBBoxStrategy.testAlongDatelineOppositeSign and testWithinBugDatelineEdge require IsWithin to match when one edge is written as +180 and as -180 (bbox/TestBBoxStrategy.java:154, :126): the same kind of equivalence. No test in the module uses -0.0.
• History. The strategies built inclusive ranges from raw bounds from the start (2012). LUCENE-7094 (#8150, 2016-03-30) moved them to DoublePoint ranges and to Math.nextUp/nextDown for exclusive bounds, which created the Intersects-vs-Within split; its discussion never mentions zeros. LUCENE-7594 (#8645, 2016-12-21), nine months later, set the Double.compare guidance for core point ranges and never mentions spatial-extras.

The strongest "intended" case (built by the intended-behaviour verifier; an intended-lens cross-model review, OpenAI GPT-5.6, rated it moderate): DoublePoint documents Double#compareTo order on purpose, and LUCENE-7594's reporter wrote that Float/Double points "are supposed to be consistent with Double/Float.compare, so +0 is supposed to compare greater than -0"; both strategies say they are built on DoublePoint ranges; spatial4j's RectangleImpl.equals is sign-sensitive too; the strategies are experimental, and callers could normalize -0.0.

Why it fails: DoublePoint order is the encoding the strategies use, not the contract they promise. Users call SpatialOperation, whose predicates are evaluate(), and the module's tests use evaluate as truth; RPT, SerializedDV and the core geo queries find a point on the zero edge. The sign-sensitive equals is why IsEqualTo is not part of this finding; a point against a rectangle goes through relate, which compares primitives. "Experimental" allows API changes, not missed hits, and nothing documents a normalization rule while the WKT reader keeps -0.0. Decisive: BBoxStrategy answers Intersects and IsWithin of a point differently for the same document. Switching its exclusive bounds to DoublePoint.nextUp would remove the contradiction only by making Intersects miss too. Verdict: not intended, a defect.

One fix was built and validated in a scratch worktree of e1faeba08bde; the alternatives are listed with their trade-offs.

The same lines in both methods, just before the return DoublePoint.newRangeQuery(...). min and max are Double, so min == 0 unboxes and is true for both zeros; a lower bound of either zero becomes -0.0 and an upper bound +0.0, so a zero edge includes both. Exclusive bounds were already moved off zero by nextUp/nextDown, so they are unaffected. The exact-match path used by IsEqualTo and the dateline clauses is left alone.

      // spatial4j compares coordinates as primitives (-0.0 == 0.0) but DoublePoint orders -0.0
      // below 0.0, so a zero bound must cover both zeros
      if (min == 0) {
        min = -0d;
      }
      if (max == 0) {
        max = 0d;
      }

      return DoublePoint.newRangeQuery(fieldname, min, max); // fieldName in PointVectorStrategy

Trade-offs

Results change only on a zero edge: on the inclusive range paths the patch changes, a -0.0 input now gets the answer of its +0.0 twin (the exact-term path used by IsEqualTo is unchanged and still tells the zeros apart, as spatial4j's equals does), so BBoxStrategy's documented bounding-box extra hits for non-rectangles under Contains also appear for those twins (no new kind of mismatch). No index-format change; documents already stored with -0.0 are found without reindexing. One comparison per bound (two per range query) at query-build time.

What the checks validated

• Gradle, JDK 25, scratch worktree of e1faeba08bde (removed afterwards): the test fails on stock with assertions on and off (seed 5EED1113) and in 5 of 5 random-seed iterations, and passes with the fix, assertions on and off.
• With the fix: the test plus TestBBoxStrategy and TestPointVectorStrategy, 17 tests, 0 failures, 1 skipped; the whole :lucene:spatial-extras:test, 118 tests including the new one, 0 failures, 5 skipped (on stock: the same 118 tests with exactly 1 failure, the new test); :lucene:spatial-extras:check -x test passes (google-java-format, ecj lint and forbidden APIs ran; eclint was not configured and Error Prone was skipped).
• Which copy of the test: the 5 iterations, the 17-test and 118-test runs and the fixed run with assertions off used an earlier copy whose only difference was one over-long comment line; the check, the fixed run with assertions on and the stock runs on and off used the final copy. The fact check re-ran the final copy through gradle: stock fails on and off, fixed passes on and off, and the whole fixed module passes (118 tests, 5 skipped).
• The hunt: the minimal repro and the mirror-direction test pass with the fix shadowed, the cross-model reviewers' own tests pass with it, and the bounded-exhaustive sweep has 0 zero-sign defects.

Add 0.0 to every indexed coordinate in createIndexableFields and to every query bound (x + 0.0 turns -0.0 into +0.0).

Trade-offs

Fixes new documents only: those already indexed with -0.0 stay invisible on a 0 edge until reindexed, and it touches more code paths (stored values, doc values, distance sources). Not validated.

Use DoublePoint.nextUp/nextDown instead of Math.nextUp/nextDown in BBoxStrategy.makeNumericRangeQuery, as LUCENE-7594 recommends for core ranges.

Trade-offs

Not recommended: it removes the contradiction only by making Intersects miss the point too, so both strategies would still disagree with SpatialOperation.evaluate, RPT and SerializedDV. Not validated. A side note: DoublePoint's 1-D newRangeQuery javadoc names DoublePoint.nextUp/nextDown for exclusive ranges (DoublePoint.java:210-211), while the n-dimensional overload's javadoc still says Math#nextUp / Math.nextDown (:232-233).

State the restriction in the class javadocs.

Trade-offs

Not recommended: it legitimises silent missed hits that a small change removes, and the WKT reader produces -0.0 from ordinary input. Not validated.

Method: semi-formal (a Z3 witness for a generic fact about doubles, which became a Lucene lead through a caller grep and an executed probe).

• Round 22 of the hunt ran a numeric-casts lens with Z3. One of its queries asked for non-NaN doubles x <= q under primitive comparison (the semantics spatial4j's relate uses) whose DoublePoint order is x > q; the only witnesses are x = +0.0, q = -0.0. A grep for callers that pass spatial4j bounds straight to DoublePoint ranges found only BBoxStrategy and PointVectorStrategy outside the lucene/sandbox module and the query parsers. Public-API probes on main and 10.6.0 (2026-11-02) showed the missed hits, and a core-geo control showed none.
• The round's skeptic re-ran it. The hunt unit that judged it wrote a public-API JUnit, a bounded-exhaustive differential sweep with a sign-erasure oracle (439,082 checks), a producer search for -0.0 and a history port. An independent reproducer, cross-model reviews (OpenAI GPT-5.6, executed), a devil's-advocate verifier, an adjudication, an audit and a last minimal-repro check then re-ran it.