BBoxStrategy's overlap-ratio score counts only one of the two overlaps of two dateline-crossing boxes, so the score is too low

BBoxStrategy.makeOverlapRatioValueSource scores a document by how much its box overlaps the query box, with the documented formula intersectionArea / queryArea * p + intersectionArea / targetArea * (1 - p). A box that crosses the dateline covers the whole longitude circle except one gap. When the query box and the document box both cross the dateline, their latitudes overlap and their gaps are strictly separated (disjoint and not touching), each box covers the other's gap and the two boxes overlap twice: once across the dateline and once on the far side of the globe (this needs their widths to add up to more than 360°, but that alone is not enough). The both-cross branch of BBoxOverlapRatioValueSource.score computes the width as min(maxX) - max(minX) + 360, which is only the piece across the dateline. Query rect(10, -170, -10, 10) and document rect(170, 20, -10, 10) share 170..-170 (20°) and 10..20 (10°), but the score uses a width of 20 instead of 30: 0.10317460317460317 instead of 0.15476190476190477 at p = 0.5. The same pair moved 30° west, so only the document crosses, scores 0.15476190476190477. Sorting by the value puts a worse match first. BBoxStrategy's spatial predicates and the index are unaffected; a filter an application builds on this score is affected. This defect only ever lowers the score and does not throw. Confirmed on main and on every release run (15, from 4.10.0, the class's first release, to 10.5.2); every release tag read has the line. Fix: add the second piece in the both-cross branch (+9 lines, validated).

• BBoxStrategy (lucene/spatial-extras, @lucene.experimental): indexes a spatial4j rectangle as four coordinates plus a dateline flag. makeQuery matches documents; makeOverlapRatioValueSource(queryBox, p) returns a DoubleValuesSource for ranking, sorting or boosting by overlap.
• Overlap ratio: the class javadoc defines intersectionArea as "the area of the intersection between the query and target envelopes", queryRatio = intersectionArea / queryArea, targetRatio = intersectionArea / targetArea, and score = queryRatio * p + targetRatio * (1 - p) (BBoxOverlapRatioValueSource.java:28-48). Areas are width x height in degrees.
• Dateline-crossing box: spatial4j rect(minX, maxX, minY, maxY) with minX > maxX covers [minX, 180] + [-180, maxX]. Its uncovered gap is (maxX, minX).

1. makeOverlapRatioValueSource builds new BBoxOverlapRatioValueSource(makeShapeValueSource(), ctx.isGeo(), queryBox, p, 0.0) (BBoxStrategy.java:232-235). For each document, the value source reads the document's box from doc values and calls score.
2. score (BBoxOverlapRatioValueSource.java:146-265) computes the intersection height, then the width. When both boxes cross or both do not (:163), it takes left = max(a.minX, b.minX) and right = min(a.maxX, b.maxX) (:165-166). For both crossing it sets width = right - left + 360 (:180-181): the arc from left east across the dateline to right.
3. If the two gaps are strictly separated (touching gaps leave a second piece of width 0) and the latitudes overlap, each box also covers the arc between the gaps, away from the dateline: [a.minX, b.maxX] when b.maxX > a.minX, or [b.minX, a.maxX] when a.maxX > b.minX (at most one holds). That arc is never added.
4. When only one box crosses (:183-203), the code adds a west and an east piece (:189-195), so the same geometry moved off the dateline is scored in full.
5. Every later step is non-decreasing in the width (calcArea, :268-270; the ratios, :208-232; the convex combination, :236-238), so this defect only ever lowers the score. explain() prints the same short width (:249).

• Who is hit. Users of makeOverlapRatioValueSource (or BBoxOverlapRatioValueSource directly) in a geo context. BBoxStrategy is in the opt-in spatial-extras module and is @lucene.experimental. Within that API nothing special is needed: the default spatial4j SpatialContext.GEO, BBoxStrategy's default field type, the default codec and a plain IndexWriterConfig (executed: a probe with new IndexWriterConfig() on main, assertions on and off, gives the same value). Downstream, Solr's BBoxField exposes the class as score=overlapRatio ("a relevancy sort/boost"), and geo-catalogue software asks for that score; Elasticsearch and OpenSearch do not use it (read-only code search, not run).
• What it takes. Both boxes cross the dateline, their latitudes overlap and their uncovered gaps are strictly separated (disjoint and not touching). That needs their widths to add up to more than 360° (necessary, not sufficient): for example a map view wider than half the globe centred on the Pacific, against a near-global dataset extent that also wraps. Deterministic, the same with assertions on and off.
• What goes wrong. The document's score, sort value and explanation are too low by the dropped piece's share, so it ranks below worse matches. For ordinary boxes at p = 0.5 the deficits shown here are 0.052 (the example) and 0.146 (the independent reproducer's pair). The largest deficit on the hunt's probe grid, 0.69 (0.069 instead of 0.759), is a degenerate pair: two zero-height boxes (horizontal lines at latitude -90, scored as a ratio of widths) at p = 0.
• Not affected. Which documents BBoxStrategy's spatial predicates match: BBoxStrategy.makeQuery never uses this value source (executed: the Intersects query still matches). A filter that an application builds on this score is affected (executed: with a threshold of 0.12 on the example pair, a positive filter drops the document and a deny rule lets it through). Also not affected: the index, deletions, and other documents' scores (a document's value depends only on its own box and the query box). This defect does not throw and cannot push a score above its exact value (so not above 1); the work per document does not change.
• How likely. Rare: two crossing boxes that together span more than 360° are uncommon, and no prior report was found in the documented searches, 12 years after 4.10.0.

# Lucene main 645d4fe14a20, assertions on (-ea), seed DEADBEEF: 1 test(s) run, 1 failed
    => java.lang.AssertionError: overlap ratio, intersection 30 x 20 expected:<0.15476190476190477> but was:<0.10317460317460317>
       org.junit.Assert.fail(Assert.java:89)
       org.junit.Assert.failNotEquals(Assert.java:835)
       org.junit.Assert.assertEquals(Assert.java:555)
       org.apache.lucene.spatial.bbox.TestBBoxOverlapRatioBothCrossDateline.testTwoPieceOverlap(TestBBoxOverlapRatioBothCrossDateline.java:51)

• The contract. BBoxOverlapRatioValueSource.java:35-48 defines intersectionArea as the intersection's area and the score from it; the constructor documents isGeo as "True if ctx.isGeo() and thus dateline issues should be attended to" (:85).
• The sibling branch and its test. When one box crosses, the code sums a west and an east piece (:183-203). TestBBoxStrategy#testOverlapRatio, case "wrap", expects 0.2794117 (TestBBoxStrategy.java:258-259): query [0, 40] against document rect(30, 10) overlaps in [30, 40] + [0, 10] = 20°, so 800/1600 x 0.5 + 800/13600 x 0.5.
• Rotation invariance. The same pair scores 0.15476 moved 30° west and 0.10317 in place; a credibility audit's metamorphic test, which uses no hand-computed value, fails the same way and passes with the fix.
• The computed width means nothing else. 20 is neither the true overlap (30) nor the width of either enclosing envelope (180 or 210).
• No test pins the current value. Swept over all its (SHIFT, nudge) combinations, the upstream "wrap" case reaches the both-cross branch only twice, both times with a second piece of width 0; stock and fixed code agree there.
• History. The line is a leftover of the 2012 port (LUCENE-4175, width = right + 360.0 - left in the unreleased AreaSimilarity). LUCENE-5714/5779 (2014) rewrote the one-crossing branch to sum both pieces and kept this one; their threads describe the work as fixing "a variety of dateline related bugs when computing intersection width & height" (#6841). None of the 35 comments on #5247, #6776 and #6841 discusses two crossing boxes that overlap twice.

The strongest case for intended behaviour (the hunt's intended-behaviour checker; a read-only cross-model reviewer, OpenAI GPT-5.6, which did not run code, rated it weak): the class is an @lucene.experimental relevance heuristic whose javadoc says it works "as envelope on envelope (rect on rect) overlays rather than complex polygon on complex polygon overlays" (:25-26), so "the intersection between the query and target envelopes" could mean one envelope rather than a two-piece region; the formula was already in Lucene's 2012 port, and the class says it was "Originally based on" Geoportal's SpatialRankingValueSource (:61-63); areas are planar degrees anyway (// TODO option to compute geodetic area, :81); the trigger is unusual; and no prior report was found in 12 years.

Why it fails: the same method already counts a two-piece overlap in full when one box crosses, and the upstream "wrap" assertion depends on it, so the single-envelope reading contradicts the class's own code and test. Under that reading the answer would be an envelope 180° or 210° wide, not 20°. The javadoc says dateline issues are attended to in geo mode, yet the result depends on where the dateline falls. The origin is no argument for keeping the formula: the same javadoc says Lucene's version was "modified quite a bit" and that Geoportal's algorithm "had dateline bugs" (:63-65). The planar approximation is applied consistently elsewhere and is not what goes wrong here.

Option A was applied in a scratch worktree at a9779ef3c193 and run through gradle (seed DEADBEEF), and checked with the same class shadowed onto the main jars; the hunt's equivalent version also cleared its exhaustive checks. B, C and D were not run.

After width = right - left + 360; (the piece across the dateline), add b.maxX - a.minX when it is positive and a.maxX - b.minX when it is positive. For two crossing boxes (a.maxX < a.minX, b.maxX < b.minX) both cannot hold, since together they would give b.maxX > b.maxX. The added arc lies between the two gaps, disjoint from the dateline piece. When the gaps overlap, neither term is positive and the result is unchanged.

         } else { // both cross
+          // the overlap that contains the dateline
           width = right - left + 360;
+          // the two boxes can also overlap away from the dateline, when each one covers the gap the
+          // other leaves (at most one of these two terms is positive)
+          if (b.getMaxX() > a.getMinX()) {
+            width += b.getMaxX() - a.getMinX();
+          }
+          if (a.getMaxX() > b.getMinX()) {
+            width += a.getMaxX() - b.getMinX();
+          }
         }

Trade-offs

• Behaviour change: only pairs where both boxes cross the dateline and their gaps are disjoint score higher, up to the exact value; every other pair keeps its score, so rankings change only for those documents.
• Cost: two comparisons per document that reaches this branch; no benchmark was run. No format or API change.

What the checks validated

• Stock main a9779ef3c193 (gradle, seed DEADBEEF): the repro fails 2 of 3 with assertions on and off (the control passes); TestBBoxStrategy passes (12 tests, 1 skipped by its own @Ignore; testOverlapRatio with the "wrap" case runs); all of :lucene:spatial-extras:test: 120 tests, the repro's 2 failures, 5 skipped.
• With the fix: the repro passes 3 of 3 with assertions on and off; TestBBoxStrategy passes; all of :lucene:spatial-extras:test (120 tests, 5 skipped, the repro class included) passes with 0 failures; ecjLintMain, ecjLintTest and checkGoogleJavaFormat pass for spatial-extras; fix.diff applies cleanly to a clean tree.
• With the fixed class shadowed onto the main jars (classpath runner): 3 of 3 pass with -ea and -da.
• The hunt's equivalent fix (two one-line ifs) took the exhaustive check from 154,000 mismatches to 0 (12,400,200 checks) and the security probe's undercount counter from 67,200 to 0 (that probe's own two assertions expect the bug, so on the fixed code they fail by design; its counters read under=0, over=0), kept the upstream "wrap" assertion passing, and, applied to the 4.10.0 class, made the 4.10.0 port pass.

width = 360 - gapA - gapB + overlap(gapA, gapB), with gap = minX - maxX: everything except what either box leaves uncovered.

Trade-offs

Not run in Lucene. Algebraically the same width as A, but not bit for bit: in double arithmetic it rounds differently, also for pairs A leaves unchanged (a seeded sample of 1,000,000 random both-cross pairs: 285,412 widths differed from A's, 168,407 of them one-piece pairs whose stock value A keeps exactly, by at most 1.1e-13 degrees). It needs its own interval-overlap code and its own tests.

Treat each box as one or two longitude intervals and sum the pairwise overlaps, replacing the three-way case analysis.

Trade-offs

Not run. Simpler to reason about, but it rewrites the tested one-crossing branch and the "both adjacent to dateline" special case (:170-173), so it needs more review.

Say in the javadoc that, when both boxes cross the dateline, only the overlap across the dateline is counted.

Trade-offs

Not recommended. Keeps the wrong rankings and the dependence on where the dateline falls.

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

• A harness built 1,245 distinct geo boxes (longitudes from {-180, -170, -100, -90, 0, 10, 90, 100, 170, 180}, latitudes from {-90, -10, 0, 10, 90}) and scored every ordered pair with BBoxOverlapRatioValueSource for queryTargetProportion {0, 0.25, 0.5, 1} and minSideLength {0, 0.1}, with assertions on and off.
• The reference was an independent evaluation of the class-javadoc formula, with the intersection measured as arcs on the longitude circle.
• 154,000 of 12,400,200 checks disagreed, all two-piece intersections (counted by the harness); 0 NaN, 0 scores outside [0, 1], 0 assertion failures. With the fix sketch, which changes only the both-cross branch, 0 disagreed, so every mismatch was a pair of two crossing boxes; a later probe through the public indexing path, over the same boxes and proportions with the default minimum side length 0, counts that directly: 0 undercounts outside both-cross, 0 overcounts.
• The finder then wrote a JUnit on the public indexing path (after a first cross-model review objected to a repro that called the protected score() directly) and confirmed the failure on main, 10.5.2 and 9.12.3.