`makeRecipDistanceValueSource` measures geo boxes wider than 180 degrees the short way round, so edge scores fall below ~0.1 (0.0082 at 340 degrees wide)

SpatialStrategy.makeRecipDistanceValueSource(queryShape) returns zScaling / (d + zScaling), and its javadoc says zScaling is "one tenth the distance to the farthest edge from the center", so scores are 1 at the centre and "as low as ~0.1 at its furthest edges". The code takes one tenth of half the distance between the bounding box's corners (minX, minY) and (maxX, maxY). In a geo context that is a great-circle distance, which always takes the shorter way round the globe; for a box wider than 180 degrees the shorter way runs outside the box, across the dateline, so a box W degrees wide gets the zScaling of a box 360 - W wide.

For rect(-170, 170, -10, 10) zScaling is 1.41 instead of 17.0 and the edge point (170, 0) scores 0.0082 instead of 0.091; for the band rect(-180, 180, -5, 5) it is 0.5 and 0.0028, on every strategy with a distance source (PointVector, BBox, SerializedDV and both prefix-tree strategies; the method is final, so they share the zScaling). Nothing fails and the hits do not change, but any combined score over-weights distance. The code is unchanged since the method was added in 4.0.0 (2012); LUCENE-4550 (4.2.0) fixed the identical computation in SpatialArgs.calcDistanceFromErrPct and left this copy. A guarded fix that changes only geo shapes wider than 180 degrees passes the repro and the module's tests.

• SpatialStrategy.java:126-132 (javadoc): "The formula is zScaling/(d + zScaling) where 'd' is the distance and 'zScaling' is one tenth the distance to the farthest edge from the center. Thus the scores will be 1 for indexed points at the center of the query shape and as low as ~0.1 at its furthest edges."
• :133 the method is public final, so every strategy shares its zScaling; the distance comes from each strategy's makeDistanceValueSource (:143), which CompositeSpatialStrategy and NumberRangePrefixTreeStrategy do not support (they throw). The class is @lucene.experimental (:53; :51: "however it is quite stable").
• :134-141 diagonalDist = distance from corner A = (minX, minY) to corner B = (maxX, maxY) of queryShape.getBoundingBox(); distToEdge = diagonalDist * 0.5.
• :142-144 c = distToEdge * 0.1, wrapped as ReciprocalDoubleValuesSource(c, distance from the centre), which returns c / (d + c) (util/ReciprocalDoubleValuesSource.java:61-63).

• Plane (non-geo context): half the diagonal is the centre-to-corner distance, the farthest point of a box: the javadoc holds.
• Geo box up to 180 degrees wide: the great circle from A to B stays within the box's longitudes; half of it is 0.45 to 1.00 of the distance to the farthest edge point: 1.00 near the equator, lower for high-latitude boxes, whose corner geodesic bulges towards the pole (10x10 at latitude 60: 0.983; 60x20 at latitude 60: 0.863; rect(-60, 60, 40, 80): 0.668; lowest 0.447 in a grid of 13,319 boxes 10 to 180 degrees wide). Every edge score in that grid stays inside the upstream tolerance (lowest 0.043).
• Geo box wider than 180 degrees: the great circle from A to B takes the shorter way, through the longitudes outside the box: the 360 - W degree gap. For rect(-170, 170, -10, 10), A = (-170, -10) and B = (170, 10) are 28.2 degrees apart, so zScaling = 0.1 x 28.2 / 2 = 1.41: exactly the value of the 20-degree box rect(-10, 10, -10, 10). For a full-longitude band A and B are on the same meridian and only the height counts (10 degrees for 5 S to 5 N; about 7e-16 for the equator line rect(-180, 180, 0, 0)).

Score at the shape's farthest edge (documented 0.0909; the upstream test tolerance is 0.10 +- 0.09). A full-longitude rectangle wraps around the globe, so its only edges are its two latitude lines.

Bold rows are outside the tolerance. A grid of 1016 generated shapes on four strategies found 124 generated shapes (91 distinct rectangles) outside it, all 340 to 360 degrees wide; that grid sampled no widths between 270 and 340, and a finer sweep finds thin boxes outside the tolerance from about 327 degrees wide (see Why it matters).

• Who. Opt-in spatial-extras scoring API; no other Lucene code calls it. Downstream, Solr's spatial field types expose it as score=recipDistance (read, not run).
• What changes. Only the size of the recip values. The value stays monotone in distance, so the hit set and a sort by the value alone are unchanged. A combined score changes: with FunctionScoreQuery.boostByValue on the band, "far" (inner score 10, at 170 degrees) scores 0.0293 and "near" (inner score 1, at 10 degrees) 0.0476, so near ranks first; with the documented zScaling far ranks first (0.933 against 0.636).
• How far off. Outside the upstream tolerance (0.01 to 0.19) for thin boxes from about 327 degrees wide up to 360: the first width out of it is 327 to 333 at the equator (heights 0 to 20), 333 to 341 at latitude 30 (heights 0 to 20) and 336 to 343 at latitude 60 (heights 0 to 10); boxes 40 degrees tall, or 20 at latitude 60, never left it in that sweep. Below those widths, low but inside it (200: 0.074; 270: 0.033); rect(-165, 165, -5, 5), 330 wide, already scores 0.0095. Circles whose bounding box spans all longitudes (they contain a pole) get 0.50 to 0.96 of the documented zScaling, inside the tolerance.
• Not affected in practice. Non-geo contexts. Geo shapes whose bounding box is at most 180 degrees wide stay inside the tolerance, although high-latitude ones get as little as 0.45 of the documented zScaling (edge scores down to 0.043 in a 13,319-box grid); the fix does not change them.
• Likelihood. Rare, since most geo queries are much narrower; when it happens it is silent.

# Lucene main 645d4fe14a20, assertions on (-ea), seed DEADBEEF: 1 test(s) run, 1 failed
    => java.lang.AssertionError: score at the furthest edge expected:<0.1> but was:<0.00822938792500614>
       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.TestRecipDistanceBoxWiderThan180.testScoreAtFurthestEdge(TestRecipDistanceBoxWiderThan180.java:53)

• Explicit, unqualified contract. SpatialStrategy.java:126-132 states the formula, what zScaling is and the resulting ~0.1 edge score; it has no exception for geo contexts or wide shapes, and the method accepts any Shape.
• Stated intent. LUCENE-4208 (#5280), which added the method: "'c' is roughly 1/10th of the distance to the query shape edge", and "how quickly the score curve slides ... doesn't vary based on the overall query shape; I think it should". The shape-relative scale is the point of the method.
• The half-diagonal is a proxy. On a plane it is the centre-to-corner distance; for geo boxes up to 180 degrees wide it is 0.45-1.00 of the distance to the farthest edge, always inside the upstream tolerance in a 13,319-box grid. It collapses once the box is wider than 180 degrees, because the shorter corner geodesic then runs through the 360 - W degrees of longitude outside the box instead of through the box's own W.
• Precedent. LUCENE-4550 (#5616, 6ba9d0b6418, 4.2.0, by the same author) replaced this exact computation in SpatialArgs.calcDistanceFromErrPct: "If the shape presented is extremely wide, > 180 degrees, then the internal calculations in SpatialArgs.calcDistanceFromErrPct(...) will wrongly measure the shape's size as having width < 180 degrees ... I am flagging this as "minor", but a bug nonetheless." Its issue and patch never mention this method.
• Tests. TestSpatialArgs asserts that makeRectangle(-180, 180, 0, 0) is 180 degrees from its centre to its corner: a full-longitude rectangle is a normal shape for the module. The only test of this method, TestDistanceStrategy.testRecipScore, uses a circle of radius 4.27 degrees, too small to reach the problem.

The strongest case for "intended": the API is @lucene.experimental, "~0.1" signals a heuristic and the upstream tolerance is wide; in LUCENE-4550 the same maintainer called shapes wider than 180 degrees "unrealistic shape sizes" and said the report came from "someone using lucene-spatial incorrectly"; and for the full-longitude band one can argue that its edges are the 5 S and 5 N lines, 5 degrees from the centre, which gives exactly the code's 0.5. And in LUCENE-4208 the author first proposed c as "1/10th the distance to the nearest query shape edge" (2012-09-12); under that reading the 340-degree box would get about 1.0, close to the code's 1.41.

Why it fails: the 340-degree box has real east and west edges 165.9 to 170 degrees from its centre, so the documented zScaling is 16.6 to 17.0 under any reading, against 1.41, a factor of 12. Even for the band the javadoc's second sentence fails: (180, 5) is on its north edge and scores 0.0028. Two days after the "nearest edge" comment the author proposed the "farthest edge" javadoc that was committed (2012-09-14), and under it both shapes score far below "~0.1 at its furthest edges". And the same maintainer called the identical computation "a bug nonetheless" and fixed it. A committer may still rate it minor, as LUCENE-4550 was, or prefer a javadoc qualification.

One fix was built and validated through gradle; a variant and the hunt's earlier sketch were compared with a probe over 21 shapes.

In makeRecipDistanceValueSource, when ctx.isGeo() and the bounding box is wider than 180 degrees, take distToEdge from the circle's radius, or else from the centre's distance to the farthest bounding-box corner; keep the half-diagonal otherwise. For a box wider than 180 degrees the corners lie on its edges, and a full-longitude box's corners lie on its two latitude lines, its only edges; a circle's farthest edge is its radius. The guard is exactly the condition under which the shorter corner geodesic runs through the 360 - W degrees of longitude outside the box instead of through the box's own W; on the 21 probe shapes the result matches the intended scale (0.976-1.000), which is not a proof for every shape.

diff --git a/lucene/spatial-extras/src/java/org/apache/lucene/spatial/SpatialStrategy.java b/lucene/spatial-extras/src/java/org/apache/lucene/spatial/SpatialStrategy.java
index 903547b18bc..3afb307d3e6 100644
--- a/lucene/spatial-extras/src/java/org/apache/lucene/spatial/SpatialStrategy.java
+++ b/lucene/spatial-extras/src/java/org/apache/lucene/spatial/SpatialStrategy.java
@@ -22,6 +22,7 @@ import org.apache.lucene.search.Query;
 import org.apache.lucene.spatial.query.SpatialArgs;
 import org.apache.lucene.spatial.util.ReciprocalDoubleValuesSource;
 import org.locationtech.spatial4j.context.SpatialContext;
+import org.locationtech.spatial4j.shape.Circle;
 import org.locationtech.spatial4j.shape.Point;
 import org.locationtech.spatial4j.shape.Rectangle;
 import org.locationtech.spatial4j.shape.Shape;
@@ -132,18 +133,39 @@ public abstract class SpatialStrategy {
    */
   public final DoubleValuesSource makeRecipDistanceValueSource(Shape queryShape) {
     Rectangle bbox = queryShape.getBoundingBox();
-    double diagonalDist =
-        ctx.getDistCalc()
-            .distance(
-                ctx.getShapeFactory().pointXY(bbox.getMinX(), bbox.getMinY()),
-                bbox.getMaxX(),
-                bbox.getMaxY());
-    double distToEdge = diagonalDist * 0.5;
+    Point center = queryShape.getCenter();
+    double distToEdge;
+    if (ctx.isGeo() && bbox.getWidth() > 180) {
+      // Half the distance between two opposite corners would go the short way around the globe,
+      // so measure from the center instead.
+      distToEdge =
+          queryShape instanceof Circle circle
+              ? circle.getRadius()
+              : farthestCornerDistance(bbox, center);
+    } else {
+      double diagonalDist =
+          ctx.getDistCalc()
+              .distance(
+                  ctx.getShapeFactory().pointXY(bbox.getMinX(), bbox.getMinY()),
+                  bbox.getMaxX(),
+                  bbox.getMaxY());
+      distToEdge = diagonalDist * 0.5;
+    }
     float c = (float) distToEdge * 0.1f; // one tenth
-    DoubleValuesSource distance = makeDistanceValueSource(queryShape.getCenter(), 1.0);
+    DoubleValuesSource distance = makeDistanceValueSource(center, 1.0);
     return new ReciprocalDoubleValuesSource(c, distance);
   }
 
+  private double farthestCornerDistance(Rectangle bbox, Point center) {
+    double max = 0;
+    for (double x : new double[] {bbox.getMinX(), bbox.getMaxX()}) {
+      for (double y : new double[] {bbox.getMinY(), bbox.getMaxY()}) {
+        max = Math.max(max, ctx.getDistCalc().distance(center, x, y));
+      }
+    }
+    return max;
+  }
+
   @Override
   public String toString() {
     return getClass().getSimpleName() + " field:" + fieldName + " ctx=" + ctx;

Trade-offs

• No change for non-geo contexts or for any shape whose bounding box is at most 180 degrees wide: identical zScaling for all 7 such probe shapes (small circles, high-latitude boxes) and identical output for all 13,319 boxes of a fact-check grid, including high-latitude boxes whose corner geodesic bulges out of the box.
• Wide geo shapes change, by design: wide boxes go from 0 to 0.99 of the documented zScaling to 0.976-1.000; circles that contain a pole from 0.50-0.96 to 1.000.
• A step at 180 degrees: the 180-degree rect(-90, 90, 80, 90) keeps zScaling 0.5 (about 0.45 of the documented value), while the 180.0001-degree rect(-90.00005, 90.00005, 80, 90) gets 1.117.
• Full-longitude boxes are measured to their latitude edges, so a point beyond the farthest edge (for example (180, 0) inside rect(-180, 180, -85, 85), 180 degrees away while the edges are at most 95) scores below 0.1 (0.050), as "farthest edge" implies.
• Other wide shapes (polygons, collections) are approximated by their bounding-box corners, which can lie far outside the shape; no polygon was tested, and neither was the Geo3d context. Cost: up to four distance computations once per query, only for affected non-circle shapes (none for circles); no API, index or format change.

What the checks validated

• gradle, clean worktree at a9779ef3c193 (2026-10-28): stock, the repro fails 2 of 4 with assertions on and off; with the fix it passes 4 of 4 with assertions on and off. TestDistanceStrategy, TestSpatialArgs and TestPortedSolr3 pass before and after (18 tests). All of :lucene:spatial-extras:test with the repro class added passes (27 classes, 121 tests, 0 failures, 5 skipped). ecjLintMain, ecjLintTest and checkGoogleJavaFormat pass; fix.diff applies cleanly to a clean tree.
• classpath runner, fix shadowed onto the main jars: this doc's JUnit 4 of 4 (-ea and -da); the hunt's JUnit 3 of 3, including the boostByValue order (3 of 3 fail without it); the independent reproducer's JUnit 3 of 3.
• probe over 21 shapes: identical zScaling to stock for all 7 shapes up to 180 degrees wide; 0.976-1.000 of the documented zScaling for all 14 wider ones (boxes, bands, hemispheres, pole circles).

zScaling = 0.1 x the largest distance from the centre to the bounding box's corners and edge midpoints, with no width guard.

Trade-offs

• Fixes every box (the hunt's 1016 shapes: 0 out of tolerance, not independently re-run; its pole circles came close: r = 45 at (0, 60) scores 0.189 with it), but changes ordinary shapes too (10x10 at latitude 60: +1.75%; 60x20 at latitude 60: +16%); a downstream test pins recip-distance scores at 1e-3 (read, not run).
• Over-corrects circles that contain a pole: their bounding box reaches round the far side of the pole, so the circle r = 6 at (0, 85) gets zScaling 1.6 instead of 0.6 and edge score 0.21, and r = 1.1 at (0, 89) 0.22, both above the tolerance; this doc's pole control fails with it (1 of 4).

Consistent with SpatialArgs.calcDistanceFromErrPct.

Trade-offs

That rule deliberately takes the nearer corner (for precision), so it would still under-measure some wide shapes (by hand: the northern hemisphere rect(-180, 180, 0, 90) would stay at 4.5 instead of 13.5), and it shifts ordinary geo shapes slightly too.

Say that zScaling is estimated from the bounding-box diagonal and is too small for geo shapes wider than 180 degrees.

Trade-offs

Cheapest and defensible for an experimental API, but the scores of those queries stay wrong when a small guarded fix exists; LUCENE-4550 chose the code fix for the same computation.

• Lead (code reading). The hunt's planning step read SpatialStrategy.java:127-144 and named the lead: zScaling from half the corner-to-corner distance, the short way round on a sphere, too small for boxes wider than 180 degrees. So it is not a blind discovery.
• Quantified (translation validation on a bounded grid). The finder generated 1016 query shapes (rectangles with centres at latitudes 0, +-60, +-89 and longitudes 0, +-179.5, 180, widths 1, 10, 90, 179, 180, 181, 200, 270, 340, 359 and 360 including dateline-crossing ones, heights 0 to 180; circles with radii 0.5 to 179), indexed the centre and the farthest boundary point with PointVector, BBox, SerializedDV and RecursivePrefixTree strategies on the stock jar, and compared the scores against an independent great-circle reference (haversine and atan2 forms cross-checked). 124 generated shapes (91 distinct rectangles) were outside the upstream tolerance on every strategy, all at the sampled widths 340, 359 and 360.
• Witnessed by a public-API JUnit, then reproduced independently (see the checks).