Geo3dRectangleShape.getCrossesDateLine() tests "spans longitude 0" instead of "crosses the dateline", so PointVectorStrategy and BBoxStrategy return wrong hits

In the opt-in Geo3d spatial context (Geo3dSpatialContextFactory, @lucene.experimental), Geo3dRectangleShape.getCrossesDateLine() returns getMaxX() > 0 && getMinX() < 0 ("the box spans longitude 0") instead of minX > maxX ("the box crosses the dateline"), the definition in spatial4j's own RectangleImpl, which the same class's getWidth() follows. PointVectorStrategy and BBoxStrategy use the flag to decide whether minX..maxX wraps, so they miss documents in dateline boxes and circles near longitude 180 and match far-away documents for boxes around longitude 0; BBoxStrategy also writes the wrong flag into the index. No recorded run threw, and CheckIndex found the probe indexes clean. It came in with LUCENE-7951 in 7.1.0 (2017) and is in every release since and on main; the one-line fix return getMinX() > getMaxX(); passes every JUnit repro and the module's tests.

• Spatial context: spatial4j's SpatialContext builds and relates shapes. Geo3dSpatialContextFactory (opt-in, @lucene.experimental) makes one whose shapes wrap spatial3d (Geo3d) shapes. Its rectangles are Geo3dRectangleShape, and every Geo3d shape's getBoundingBox() is one too.
• Dateline box: a Rectangle keeps its west edge in minX and its east edge in maxX. A box that crosses the -180/180 meridian has minX > maxX: rect(170, -170, ...) is the 20 degrees from 170 eastwards to -170. getCrossesDateLine() says whether that is the case.
• PointVectorStrategy and BBoxStrategy: two non-default @lucene.experimental strategies. One indexes a point as two numbers (x, y), the other a box as four numbers plus a dateline flag, and both search with numeric range queries. They need the flag to know whether minX..maxX is one range or wraps around.

1. Geo3dRectangleShape.getCrossesDateLine() (Geo3dRectangleShape.java:152-155) returns getMaxX() > 0 && getMinX() < 0: true when the box straddles longitude 0, false for a box across the dateline. spatial4j's RectangleImpl returns minX > maxX.
2. The same class's getWidth() (:118-125) does wrap: it adds 360 when maxX - minX is negative, so 170..-170 is 20 degrees wide. Geo3dShapeFactory.rect (Geo3dShapeFactory.java:163-173) keeps minX > maxX for such a box, and Geo3dShape.getBoundingBox() (Geo3dShape.java:107-118) returns a Geo3dRectangleShape for every Geo3d shape.
3. PointVectorStrategy.makeWithin (PointVectorStrategy.java:209-222) builds two longitude ranges, x <= maxX OR x >= minX, when the flag is true, and one range minX <= x <= maxX otherwise. A circle query uses the circle's bounding box the same way and adds a distance check (:195-198).
4. BBoxStrategy writes the flag into the index as the xdl term T or F (BBoxStrategy.java:205-207), and its query builders branch on the query's flag (:299, :382, :542). A document with xdl=T is read as the two pieces [minX, 180] and [-180, maxX]. Intersects is "not disjoint" (:473-496).

• Query box 170..-170 (flag false): PointVectorStrategy searches x:[170.0 TO -170.0], an empty range, and finds nothing. The same happens for a circle around (180, 0), whose bounding box is 175..-175.
• Query box -10..10 (flag true): PointVectorStrategy searches x <= 10 OR x >= -10, every longitude, and matches every point in the latitude band.
• Indexed box 170..-170, stored with xdl=F: read as the empty range 170..-170, so BBoxStrategy misses it for a query inside it.
• Indexed box -10..10, stored with xdl=T: read as [-10, 180] plus [-180, 10], the whole longitude range, so it matches queries anywhere in its latitude band.
• The flag is wrong for every box that crosses the dateline (minX > maxX: 170..-170, but also 10..5 or 10..0, whose edges have the same sign), and for every other box whose west edge is below 0 and east edge above 0. Only boxes that do not cross the dateline and lie on one side of longitude 0 (an edge exactly at 0 included) get the right flag. The full-world box -180..180 changes too: true today, false with the fix (see the fix trade-offs).
• BBoxStrategy also gets IsWithin, Contains and IsDisjointTo wrong (security probe); IsEqualTo compares the four numbers and does not read the flag (BBoxStrategy.java:457-466).
• Other readers of the flag get the wrong value too: Lucene's HeatmapFacetCounter and BBoxOverlapRatioValueSource, and, in mixed use, spatial4j's own GeoCircle.relateRectanglePhase2 and JtsShapeFactory.getGeometryFrom. No wrong result was shown through them (a 32-case heatmap probe showed none), and none is claimed.

The default spatial4j context (SpatialContext.GEO) gives the "expected" column on main. Assertions on and off give the same results.

• Who is hit. Applications that pair Geo3d shapes with PointVectorStrategy or BBoxStrategy (both @lucene.experimental):
  • the Geo3d spatial context (Geo3dSpatialContextFactory, @lucene.experimental) with either strategy;
  • spatial3d shapes wrapped in the public Geo3dShape constructor under the default SpatialContext.GEO, the 7.0.x usage pattern: from 7.1.0 on their bounding box is a Geo3dRectangleShape, so BBoxStrategy indexes them with the wrong flag (follow-up bisection test).
• Not affected. RecursivePrefixTreeStrategy (it does not read the flag), shapes from spatial4j's own factory, and Lucene's core geo types (LatLonPoint, LatLonShape, XYShape, spatial3d's Geo3DPoint).
• Ordinary data. Within the pairing it is deterministic: any box over the dateline (Fiji, the Bering Sea) or across longitude 0 (a box around London, over western Europe or West Africa), as a query or as an indexed document, WKT ENVELOPE input included.
• Both directions. Missed documents (dateline boxes, circles near longitude 180) and extra documents (a box around longitude 0 matches everything in its latitude band: as a PointVectorStrategy query and as a BBoxStrategy document).
• How common, on random data (security probe: 2,000 random boxes and points in 9 segments, 1,500 random query boxes): BBoxStrategy Intersects was wrong on 1,474 of 1,500 queries and PointVectorStrategy Intersects on 857 of 1,500; every mismatch involved a box that spans longitude 0 or crosses the dateline. A second run with assertions off and a different seed gave similar counts (1,483 and 877); SPHERE and WGS84 gave identical counts. Half of the query boxes were chosen to span longitude 0 or cross the dateline, so the shares show the effect is frequent in this synthetic workload, not how often real data hits it.
• Cost side effect. A PointVectorStrategy circle of radius 1 at (0.3, 0.3) has a bounding box from -0.70 to 1.30 with the flag true, so its prefilter is the whole latitude band: on 100,000 points it distance-checks 20,118 candidates instead of 110 (about 5.5 ms instead of 0.2-0.3 ms on a loaded host). The answer stays right, and the cost stays below a legitimate world-sized circle (about 21 ms).
• Silent and persistent. No exception or hang in any recorded run, and CheckIndex found the probe indexes clean; other filter clauses and deletions still apply. But BBoxStrategy indexes the wrong xdl flag, so existing indexes stay wrong after a fix until they are reindexed (in the probe xdl=T was set on exactly the boxes that span longitude 0, and on no dateline box).
• How likely. Plausible rather than common: the pairing looks little used (no upstream test combines Geo3d with these strategies), and no public report was found for the nine years since 7.1.0.

# Lucene main 645d4fe14a20, assertions on (-ea), seed DEADBEEF: 1 test(s) run, 1 failed
    => java.lang.AssertionError: 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.junit.Assert.assertEquals(Assert.java:633)
       org.apache.lucene.spatial.spatial4j.TestGeo3dDatelineBoxQuery.testPointInsideDatelineBox(TestGeo3dDatelineBoxQuery.java:52)

• The class contradicts itself. getWidth() treats minX > maxX as a wrap, and Geo3d's own relate() puts (175, 0) inside 170..-170 and (100, 0) outside -10..10, while the flag says the opposite (independent reproducer, this doc's test, the diagram probe).
• Contract. spatial4j 0.8 Rectangle class javadoc: "In geospatial contexts, it may cross the international date line (-180 longitude) if getCrossesDateLine()"; getMinX() and getMaxX() are the left and right edges; the reference RectangleImpl.getCrossesDateLine() is minX > maxX. Lucene's BBoxStrategy javadoc: "a boolean to mark a dateline cross" (BBoxStrategy.java:63); the bbox package: "a flag to say if it crosses the dateline" (package-info.java:21). A box from -10 to 10 does not touch -180.
• History. In the PR commit that first added the class (lucene-solr#246, ea31e5ce0f, 2017-09-07; the PR's first commit, 3ba3dad6b7, adds only Geo3dAreaShape) getWidth() and getCrossesDateLine() shared the same minX < 0 && maxX > 0 test; commit cfbac2fb00 (2017-09-12) rewrote getWidth() to the wrap convention and left the flag unchanged. No review comment discusses it. Before 7.1.0, Geo3dShape.getBoundingBox() returned a spatial4j RectangleImpl with the right flag; 7.0.0 and 7.0.1 pass the version-portable test.
• Tests. No upstream test calls getCrossesDateLine() on a Geo3d rectangle or pairs a Geo3d context with PointVectorStrategy or BBoxStrategy; the Geo3d tests use RPT, SerializedDVStrategy (TestGeo3dRpt) or relate(), never these two strategies. No test, CHANGES or MIGRATE entry accepts the "spans longitude 0" meaning.

The strongest case for "intended" (an intended-behaviour checker): every class involved is @lucene.experimental; the Rectangle method javadoc gives no formula ("Only meaningful for geospatial contexts."); the Geo3d bridge was built for prefix-tree strategies, so Geo3d with BBoxStrategy or PointVectorStrategy may never have been a supported pairing; and the line has not changed since 2017 without anyone reporting it.

Why it fails: experimental status warns about API changes, not wrong answers; the class javadoc and Lucene's own BBoxStrategy docs define the meaning, and the class's own getWidth() follows it; neither strategy restricts its SpatialContext, and in the PR the reviewer said the Geo3d rectangle "could be used for a variety of purposes, notably a query for a rectangular map area"; age is not intent, and the PR history shows the sibling method was corrected and this one missed. Verdict: not intended, a defect (the adjudication and independent checks; the cross-model reviewer rated the intended-behaviour argument weak under both of its lenses).

One option was built and validated in a scratch worktree at a9779ef3c193 with gradle (JDK 25) and with the standalone runner against every repro (patched class shadowed). The other two were weighed and not built. Any fix needs a regression test (this doc's test is one) and a reindex note for BBoxStrategy users.

Change line 154 of Geo3dRectangleShape.java. It is the definition of spatial4j's RectangleImpl and the convention the class already uses in getWidth() and its factory. It fixes the query side and the index side of both strategies, and every other caller of the flag gets the Rectangle contract.

  @Override
  public boolean getCrossesDateLine() {
    return getMinX() > getMaxX();
  }

Trade-offs

• Smallest change, at the defect; the same change as the finder's fix.
• By code reading, the full-world box -180..180 (also the bounding box of any shape without a longitude bound) now reports false instead of true, the same as spatial4j's RectangleImpl; the module's tests pass.
• Documents indexed by BBoxStrategy before the fix keep their old xdl term (T on boxes that span longitude 0, F on dateline boxes) until reindexed: worth a CHANGES or MIGRATE line.

What the checks validated

• Gradle, scratch worktree at a9779ef3c193, seed DEADBEEF, this doc's test added: it fails 6 of 6 on stock main (assertions on and off) and passes 6 of 6 with the fix.
• ./gradlew :lucene:spatial-extras:check with the fix passes: 27 suites, 123 tests (the module's 117 plus the 6 new), 5 skipped, 0 failures, and the format, ecjLint and forbiddenApis checks. The suites include TestBBoxStrategy, TestPointVectorStrategy, TestGeo3d, TestGeo3dRpt, both Geo3d RectRelation tests and TestHeatmapFacetCounter.
• TestBBoxStrategy, TestPointVectorStrategy and TestGeo3d* 10 times with a random root seed and assertions off: 430 tests, 0 failures.
• Standalone, fix shadowed: this doc's test 6/6 (assertions on and off); earlier, by the hunt: the finder's 5/5, the independent reproducer's 5/5, the cross-model reviewer's 7/7 and 10/10, the devil's advocate's 8/8, the history test 5/5, the security probe with 0 wrong results (it exits 1 only on its own checks that the bug is still active, as expected with the fix), and the end-to-end differential with only 4 unrelated +-180 edge cases left.

PointVectorStrategy.makeWithin and BBoxStrategy (index and query side) would stop calling getCrossesDateLine().

Trade-offs

Touches five call sites in the two strategies (PointVectorStrategy.java:212; BBoxStrategy.java:206, :299, :382, :542) and leaves the Rectangle contract broken for every other caller (HeatmapFacetCounter, BBoxOverlapRatioValueSource, user code). Not recommended.

Let Geo3dShape.getBoundingBox() return a spatial4j RectangleImpl again, as before 7.1.0.

Trade-offs

Not sufficient: ctx.getShapeFactory().rect(...) and WKT ENVELOPE still build a Geo3dRectangleShape with the wrong flag, so dateline query boxes stay broken. The 7.0 bounding box was also buffered by 0.05 degrees (ROUNDOFF_ADJUSTMENT in 7.0.1's Geo3dShape), which C would have to decide on.

Method: semi-formal: a hypothesis formed by code reading while writing a model rule, then witnessed by model-based differential testing, in a hunt unit on the spatial4j bridge to spatial3d.

• While writing the bridge model's rule G2 (a Geo3d shape's bounding box, read through the Rectangle contract, must enclose every sampled member of the shape), the finder suspected the flag from the code.
• The harness Geo3dBridgeDiff then checked 10,000 random and boundary shapes (dateline, poles, degenerate and near-hemisphere boxes, tiny circles; SPHERE and WGS84; seed 5EED220): getCrossesDateLine() disagreed with minX > maxX on 3,693 bounding boxes, and 1,091 bounding boxes failed to enclose their own members when read through the flag.
• End to end, Geo3dStrategyDiff (300 documents and 150 queries per planet model, the spatial4j context as the oracle): PointVectorStrategy missed hits on 42 of 300 queries; BBoxStrategy Intersects missed hits on 265 of 300 and returned false hits on 220 of 300. With the one-line fix only 4 of its 900 BBoxStrategy queries (all Within or Contains, with an edge at -180) still differed, an unrelated representation issue.
• A public-API JUnit on the stock main jar confirmed it; the devil's advocate later added the PointVectorStrategy false positive for boxes around longitude 0, which the end-to-end harness had not counted.