PointVectorStrategy misses a point at longitude ±180° when a rectangle's dateline edge is written with the other sign

In a geo SpatialContext, longitude -180 and +180 are the same meridian, and spatial-extras defines Intersects and IsWithin through spatial4j's relate, which treats them as one. PointVectorStrategy stores a point's x as a plain DoublePoint and, for a rectangle that does not cross the dateline, filters x with one closed range [minX, maxX]. To that range +180 and -180 are different numbers: a point stored at +180 is not found by a box whose west edge is -180, and a point at -180 is not found by a box whose east edge is +180. The western hemisphere rect(-180, 0, -90, 90) returns 0 hits for (180, 10), the eastern hemisphere rect(0, 180, -90, 90) 0 hits for (-180, 10), and rect(180, -170, -10, 10), written with +180 by the caller, 0 hits for (180, 0), because spatial4j itself turns that box's west edge into -180. The oracle and BBoxStrategy return 1 in every case. Both operations fail, with assertions on and off; the miss follows from the query itself, not from the index size (executed with one document and with a 609-document, 7-segment index). Only missed matches, never extra ones. It reproduces on all 14 releases tested from 4.0.0 (2012, when the module moved to spatial4j 0.3) to 10.5.2 and on main. A 6-line fix in makeWithin that also matches the other-sign meridian passes the repro and all spatial-extras tests.

• Geo context: spatial4j's SpatialContext.GEO, the standard context for longitude/latitude in degrees. Longitude runs from -180 to +180, and both values name the same meridian, the antimeridian or dateline.
• PointVectorStrategy (spatial-extras, @lucene.experimental): indexes one point per document as two DoublePoint fields (x and y) plus doc values, and supports Intersects and IsWithin queries by a rectangle or a circle.
• Crossing box: a spatial4j rectangle with minX > maxX, for example rect(170, -170), which covers 170 to 180 and -180 to -170. A box with an edge on ±180 that does not wrap, such as rect(-180, 0), is not crossing.
• The oracle: SpatialOperation.evaluate(indexed, query), which is spatial4j's relate. It defines the predicates for every strategy in the module, and in a geo context it treats x = +180 and x = -180 as one meridian.

1. createIndexableFields(Point) (:163-180) stores x as given: new DoublePoint(fieldNameX, point.getX()) (:175). spatial4j keeps 180 as 180.0.
2. makeQuery (:187-206) sends a rectangle to makeWithin (:209-222). Only a crossing box gets two SHOULD ranges, [-inf, maxX] or [minX, +inf] (:212-216); any other box gets one MUST range [minX, maxX] on x (:217-219), closed at both ends (rangeQuery, :228-242).
3. For the western hemisphere the query is +pv__x:[-180.0 TO 0.0] +pv__y:[-90.0 TO 90.0]. The stored x is 180.0, outside [-180, 0], so the document is missed, while relate says WITHIN.
4. A non-crossing box lies inside [-180, 180], so a point at ±180 can only sit on one of its edges, and only the opposite sign is wrong. A crossing box already accepts both signs.
5. spatial4j writes edges with either sign itself: rect(180, -170) becomes minX = -180, rect(170, -180) becomes maxX = 180, both non-crossing. So no single storage convention avoids the miss.

IsWithin gives the same answers as Intersects on all of these. Circle queries share the bounding-box filter, but a circle's box meets ±180 only at its tangent point, where spatial4j's own answer is rounding-sensitive; no circle miss was found, so circles are not claimed.

• Who is exposed. Users of PointVectorStrategy (@lucene.experimental) in a geo context, typically SpatialContext.GEO, with rectangle Intersects or IsWithin queries. newInstance(ctx, prefix), the default field type, codec and IndexWriterConfig are enough (an independent probe with a plain ByteBuffersDirectory and new IndexWriterConfig() misses the same inputs). Only field types with point values (the default) are affected; without them every rectangle query throws "An index is required for this operation." (PointVectorStrategy.java:241).
• What it takes. A point stored at exactly longitude +180 or -180, and a box that does not cross the dateline with its edge on that meridian written, or normalized by spatial4j, with the other sign. Box edges on ±180 are ordinary (hemisphere boxes, tiles ending at the dateline); points exactly on the antimeridian are uncommon but real (snapped or rounded coordinates, grid data).
• What goes wrong. 0 hits where the oracle says 1. A probe of 9,000,000 checks (4.5 million random point-box pairs, each for both operations) found 0 extra hits against an exact reference; its 96 disagreements with spatial4j relate are rounding in spatial4j on crossing boxes, where the strategy gives the exact answer. No error, and nothing stored is wrong, so a fix needs no reindexing.
• Not affected. Every other strategy class in the module that indexes geo points returns the hit on these inputs: BBoxStrategy, SerializedDVStrategy, CompositeSpatialStrategy, and the prefix-tree strategies on geohash, quad and packed-quad grids (as configured in the probes; these trees are approximate grids, and one quad configuration also matches the outside control at 179.9). Also not affected: boxes that cross the dateline, same-sign edges, the world box. Core LatLonPoint is a different API with its own convention and is not claimed.
• Reach. Less-used strategy: Solr deprecated its PointVectorStrategy field type in 6.6 and removed it in 9.0 (SOLR-10729, SOLR-13138); a code search of the default branches of Elasticsearch, OpenSearch and Solr found no use (re-run 2026-10-28 with a positive control per repository). No report of this bug was found in the public sources searched.

# Lucene main 645d4fe14a20, assertions on (-ea), seed DEADBEEF: 1 test(s) run, 1 failed
    => java.lang.AssertionError: Intersects rect(-180,-170,-10,10) with Pt(180,0) indexed expected:<1> but was:<0>
       org.junit.Assert.fail(Assert.java:89)
       org.junit.Assert.failNotEquals(Assert.java:835)
       org.junit.Assert.assertEquals(Assert.java:647)
       org.apache.lucene.spatial.vector.TestPointVectorDatelineEdge.testPointAtPlus180InBoxFromMinus180(TestPointVectorDatelineEdge.java:49)

• The contract. The class javadoc: "Can query by a rectangle or circle" and "SpatialOperation#Intersects and SpatialOperation#IsWithin is supported" (PointVectorStrategy.java:62-64). SpatialStrategy.makeQuery: "Make a Query based principally on SpatialOperation and Shape" (SpatialStrategy.java:116-117). SpatialOperation: "For more explanation of each predicate, consider looking at the source implementation of evaluate" and "Lucene-spatial makes no distinction of shape boundaries" (SpatialOperation.java:30-34), so a point on an edge counts.
• The oracle. evaluate is spatial4j relate, which in a geo context says (180, 0) is within rect(-180, -170, -10, 10), for points already from spatial4j 0.3 on (the 4.0.0 run prints WITHIN). In locationtech/spatial4j#85, found through Lucene's TestBBoxStrategy, spatial4j extended the convention to zero-width boxes on the dateline, choosing to "deem longitude +/- 180 zero width as equal longitudinally".
• The module states the convention elsewhere. BBoxStrategy.java:387,395: "touches dateline; -180 == 180". TestBBoxStrategy.java:108-175: testIntersectsBugDatelineEdge, testWithinBugDatelineEdge, testContainsBugDatelineEdge, testAlongDatelineOppositeSign, added with LUCENE-5714 (#6776), whose randomized tests "uncovered dateline edge cases (e.g. touches but doesn't cross the dateline) and world-wrap (-180 to 180) bugs", fixed then in BBoxStrategy only. TestRandomSpatialOpFuzzyPrefixTree.java:518-519: "in geo, -180 & +180 are the same place".
• Every other strategy class in the module that indexes geo points returns the hit on these inputs.
• History. LUCENE-4389 (#5455, 2012) added the crossing branch so that "at least it won't be buggy if you stay with Rectangle query shapes"; it handled only boxes that cross. No javadoc, CHANGES entry, MIGRATE note or test asserts the current behaviour, and the 22 upstream tests that use PointVectorStrategy pass with the fix.

The strongest case for "intended" (an intended-behaviour checker and a cross-model reviewer): the class is @lucene.experimental and says "This is a simple Strategy. Search works with a pair of range queries on two DoublePoints" (PointVectorStrategy.java:72-73), so read literally x is a plain number and callers should canonicalize. Core LatLonPoint also treats 180 and -180 as different, and in #9767 (core LatLonShape) a committer called the same kind of opposite-sign behaviour "more like a feature". In #10728 (2021) @dsmiley suggested LatLonDocValuesField.newDistanceSort for geospatial distance sorting "or PointVectorStrategy for general 2D".

Why it fails: the javadoc sentence describes the implementation, not a precondition for callers, and the code already departs from a plain pair of ranges for crossing boxes. LatLonPoint and LatLonShape are core APIs with their own types and oracle, while spatial-extras defines its predicates through spatial4j and says "-180 == 180" in its own code and tests. Canonicalizing the stored points alone cannot work: one storage sign is always missed by one of the two hemisphere boxes, and spatial4j turns the caller's rect(180, -170) into minX = -180; callers can avoid the miss by rewriting every query box that touches the dateline (the workaround under Suggested fix), which no documentation asks for. The #10728 remark is about distance sorting: no javadoc limits the strategy to non-geo contexts, and LUCENE-4389 ("Fix TwoDoubles dateline support") added dateline handling to this very method.

Option A was applied in a scratch worktree at a9779ef3c193 and run through gradle (seed DEADBEEF), and checked against every hunt repro with the patched class shadowed onto the main jars; the other options were not run. Workaround until a fix ships (executed on main): OR the box's query with a second PointVectorStrategy query for the degenerate box on the other-sign meridian, for example rect(180, 180, minY, maxY) next to rect(-180, 0, minY, maxY); the western hemisphere then finds (180, 10) and still misses (179.9, 10).

A new branch in makeWithin between the crossing branch and the plain range: if ctx.isGeo() and the box has minX == -180 or maxX == 180, the x filter becomes two SHOULD clauses with setMinimumNumberShouldMatch(1), the plain range and an exact match on the opposite-sign meridian (+180 for a west edge at -180, -180 for an east edge at +180). It mirrors the crossing branch above it and BBoxStrategy's special case; the closest precedent is BBoxStrategy.makeWithin, which for the same boxes ORs in an exact match on the opposite dateline edge (BBoxStrategy.java:550-559).

       bq.setMinimumNumberShouldMatch(1); // must match at least one of the SHOULD
+    } else if (ctx.isGeo() && (bbox.getMinX() == -180 || bbox.getMaxX() == 180)) {
+      // touches dateline; -180 == 180, so also match points stored with the other sign
+      double otherX = bbox.getMinX() == -180 ? 180 : -180;
+      bq.add(rangeQuery(fieldNameX, bbox.getMinX(), bbox.getMaxX()), BooleanClause.Occur.SHOULD);
+      bq.add(rangeQuery(fieldNameX, otherX, otherX), BooleanClause.Occur.SHOULD);
+      bq.setMinimumNumberShouldMatch(1); // must match at least one of the SHOULD
     } else {
       bq.add(rangeQuery(fieldNameX, bbox.getMinX(), bbox.getMaxX()), MUST);
     }

Trade-offs

• Behaviour change: only boxes with an edge exactly on ±180 change, and they now also return opposite-sign points on that edge. For the world box the extra clause is redundant but harmless.
• Circles share makeWithin, so their bounding-box prefilter may now admit a point at the other-sign meridian; the distance check still decides, and the probed circles give the same answers as before.
• Cost: one more single-value range clause for boxes that touch the dateline; no benchmark was run. No index format or API change, and existing indexes need no rebuild.

What the checks validated

• Stock main a9779ef3c193 (gradle, scratch worktree, seed DEADBEEF): the repro fails 3 of 4 with assertions on and off; every upstream class that uses PointVectorStrategy (TestPointVectorStrategy, TestPortedSolr3, TestDistanceStrategy, TestQueryEqualsHashCode: 22 tests) passes; all of :lucene:spatial-extras:test (27 classes, 121 tests, 5 skipped) has only the repro's 3 failures.
• With the fix: the repro passes 4 of 4 with assertions on and off; the 22 closest-suite tests pass; all of :lucene:spatial-extras:test passes with 0 failures, with the same per-class counts as stock except the repro class; ecjLintMain, ecjLintTest and checkGoogleJavaFormat pass; the diff applies cleanly to a clean tree.
• Classpath runs with the patched class shadowed onto the main jars: this repro 4 of 4 (-ea, -da), the hunt's JUnit 2 of 2 and the independent reproducer's 4 of 4; the exhaustive grid drops from 420 to 0 mismatches per operation. The hunt's variant of the same fix also passed the all-strategies JUnit, the devil's-advocate probe (12 to 0) and the security probe (0 extra hits against the exact reference, 0 misses at ±180).

Treat a geo box with minX == -180 like a crossing box with ranges [-inf, maxX] or [180, +inf], and one with maxX == 180 like [-inf, -180] or [minX, +inf], reusing the two-SHOULD code. Not run.

Trade-offs

Same results, since no data lies beyond the world bounds (as the existing comment notes); a less obvious diff.

Normalize x in createIndexableFields. Not recommended; not run.

Trade-offs

Does not fix boxes ending at +180 (the eastern hemisphere would then miss every antimeridian point), so the query side still needs A; existing indexes would have to be rebuilt.

A javadoc sentence. Not recommended.

Trade-offs

Keeps the wrong results, contradicts SpatialOperation's definition, and to get correct results callers would have to rewrite every query box that touches the dateline (the workaround above), since spatial4j itself writes edges with both signs.

Method: semi-formal, bounded-exhaustive differential checking (hunt unit on spatial-extras, 2026-10-26, main ea57360912ed).

• A harness enumerated every distinct geo rectangle over longitudes {-180, -170, -90, 0, 90, 170, 180} and latitudes {-90, -45, 0, 45, 90} (570 rectangles, crossing and degenerate ones included) and queried each against all 35 grid points with the exact strategies of the module.
• Each answer was compared with two oracles: SpatialOperation.evaluate (spatial4j relate, the module's own test oracle) and an independent exact reference (closed intervals, -180 == 180).
• PointVectorStrategy showed 420 false negatives per operation out of 19,950 pairs, every one a point at x = ±180 against a non-crossing box edge of the other sign, and 0 other mismatches; spatial4j and the reference agreed on all of them.
• The finder read makeWithin, found the plain x range, wrote a public-API JUnit on the stock jar and a fix sketch that brought the grid to 0 mismatches. Re-run on main a9779ef3c193 for this doc: 420 stock, 0 with the fix.