GeoBBox.expand stops a widened longitude edge at ±180° instead of crossing the dateline, so buffered Geo3D boxes miss the strip just past it

GeoBBox.expand(angle) grows a geo3d box by moving each edge out by angle. Geo3d boxes may cross the dateline (left longitude > right longitude), and expand widens such a box across it correctly. But when an edge that does not yet cross the dateline is moved past ±π, expand passes the unwrapped value (for example 3.0 + 0.3 = 3.3) to GeoBBoxFactory.makeGeoBBox, which clamps any right longitude above π to π and any left longitude below -π to -π. The grown box stops at exactly 180° and silently leaves out the strip beyond it. All 13 GeoBBox classes with a longitude range share the code, on every planet model. In spatial-extras, Geo3dRectangleShape.getBuffered is expand, and spatial4j's WKT reader calls getBuffered for BUFFER(...), so in the opt-in Geo3D spatial context Intersects(BUFFER(ENVELOPE(172, 178, 4, -4), 4)) covers 168° to 180° instead of 168° to -178° and misses a document at (-179.5, 1): 0 hits instead of 1. For a positive angle the grown box still contains the original box. Present since geo3d's first check-in, so in every release from 5.2.0 to 10.6.0 (10.6.0 by reading) and main; the Geo3D BUFFER path since 7.1.0. Fix: in each expand, wrap the moved longitudes into [-π, π] after the existing whole-world check.

• geo3d box (GeoBBox, spatial3d): a shape bounded by two latitudes and two longitudes, in radians (π = 180°). GeoBBoxFactory.makeGeoBBox(planetModel, topLat, bottomLat, leftLon, rightLon) picks one of 18 classes (GeoRectangle, GeoWideRectangle, slices, degenerate lines and points, latitude zones, GeoWorld). When leftLon > rightLon the box crosses the dateline (the ±180° meridian).
• expand(angle): "Expand box by specified angle" (GeoBBox.java:27-33): move each edge out by angle.
• Geo3D spatial context (spatial-extras): Geo3dSpatialContextFactory, an opt-in spatial4j context whose shapes are geo3d shapes (default planet model: sphere). A spatial4j rectangle in it is a Geo3dRectangleShape, and its getBuffered(d) is expand(d in radians). spatial4j's WKT reader turns BUFFER(shape, d) into shape.getBuffered(d), and SpatialArgsParser reads query strings with that reader.

1. GeoRectangle.expand (GeoRectangle.java:211-227) computes newLeftLon = leftLon - angle and newRightLon = rightLon + angle. Only a span that reaches the whole world is special-cased (:221-224). The values go to the factory unwrapped.
2. GeoBBoxFactory.makeGeoBBox (GeoBBoxFactory.java:37-57) clamps leftLon < -π to -π and rightLon > π to π (:52-57), as it clamps latitudes at the poles (:46-51). So 3.3 becomes π: the part past the dateline is cut off.
3. Given wrapped bounds (leftLon > rightLon) the same factory builds a crossing box (extent += 2π, :79-82). That is why a box that already crosses the dateline is widened across it: its moved edge, for example -π + 0.301, is in range.
4. The same pattern is in all 13 classes with a longitude range: GeoRectangle, GeoNorthRectangle, GeoSouthRectangle, GeoWideRectangle, GeoWideNorthRectangle, GeoWideSouthRectangle, GeoLongitudeSlice, GeoWideLongitudeSlice, GeoDegenerateHorizontalLine, GeoWideDegenerateHorizontalLine, GeoDegenerateVerticalLine, GeoDegenerateLongitudeSlice and GeoDegeneratePoint (which also lacks the whole-world check). GeoWorld and the four latitude zones have no longitude bounds.
5. Geo3dRectangleShape.getBuffered is shape.expand(distance * DEGREES_TO_RADIANS) (Geo3dRectangleShape.java:169-173), the only caller of expand in Lucene's main sources. Other Geo3D shapes do not reach it: Geo3dShape.getBuffered throws UnsupportedOperationException (Geo3dShape.java:141-143) and points buffer to circles (Geo3dPointShape.java:72). So the affected WKT form is BUFFER(ENVELOPE(...), d), in a query string or in an indexed document shape.

Nothing is corrupted. For a positive angle the grown box contains the original box (0 failures in 38.5 million containment checks), and a document indexed as BUFFER(ENVELOPE(...)) is stored as the well-formed, clamped box. The defect is that the box is too small on the dateline side.

• Who is exposed. Applications that call the @lucene.experimental GeoBBox.expand directly, and applications on spatial-extras with the opt-in, @lucene.experimental Geo3D context that buffer a rectangle: spatial4j Rectangle.getBuffered, or WKT BUFFER(ENVELOPE(...), d) in a query string or an indexed document. Solr exposes the context as spatialContextFactory="Geo3D" and documents WKT BUFFER (read from Solr's source and reference guide, not run). A code search found no use of the Geo3D context in Elasticsearch or OpenSearch.
• What it takes. A box whose edge lies within the buffer angle of ±180° and that does not already cross the dateline. Then it is deterministic: no scale, no randomness, the same with assertions on and off, on the sphere (the Geo3D default) and WGS84. Data near the antimeridian (Fiji, the Aleutians, Chukotka) is ordinary.
• What goes wrong. The buffered shape is too small on the dateline side. Intersects(BUFFER(...)) misses documents there (0 hits instead of 1), and predicates that match more when the shape is smaller over-match: MUST_NOT Intersects(BUFFER(...)), IsDisjointTo(BUFFER(...)), Contains(BUFFER(...)), and IsWithin for a document indexed as a buffered envelope. A probe of 100 comparisons over four strategies (serialized doc values, a geohash prefix tree, and composite strategies with geohash and S2 grids) and both planet models gave 44 wrong answers on main and 10.5.2, and 0 with the fix.
• No error, nothing corrupted. No exception anywhere; the grown box still contains the original, and indexed buffered shapes are stored as well-formed clamped boxes.
• Not affected. Geo3DPoint queries, core geo (LatLonPoint, LatLonShape), the plain spatial4j geo context, and buffers away from ±180°.
• How likely. Rare: the experimental API or the opt-in Geo3D context, plus a buffered rectangle near the antimeridian. Buffered envelopes are an uncommon WKT form, and no report was found in the eleven years since 5.2.0.

# Lucene main 645d4fe14a20, assertions on (-ea), seed DEADBEEF: 1 test(s) run, 1 failed
    => java.lang.AssertionError: expected the box to reach lon 3.3 - 2 PI and contain [lat=-0.1, lon=-3.083185307179586([X=-0.9933074600910722, Y=-0.05808251585497932, Z=-0.09983341664682815])], but was GeoRectangle: {planetmodel=PlanetModel.SPHERE, toplat=0.3(17.188733853924695), bottomlat=-1.0853981633974483(-62.188733853924695), leftlon=2.2(126.05071492878113), rightlon=3.141592653589793(180.0)}
       org.junit.Assert.fail(Assert.java:89)
       org.junit.Assert.assertTrue(Assert.java:42)
       org.apache.lucene.spatial3d.geom.TestGeoBBoxExpandAcrossDateline.testExpandRightBoundAcrossDateline(TestGeoBBoxExpandAcrossDateline.java:28)

• The contract. GeoBBox.expand: "Expand box by specified angle. @param angle is the angle amount to expand the GeoBBox by." (GeoBBox.java:27-33).
• The upstream test. TestGeoBBox.testBBoxExpand (TestGeoBBox.java:123-145) checks every edge after expand(0.1): a point 0.05 past it is inside, 0.15 past it is outside. Its only case is commented "Standard normal Rect box, not crossing dateline" (:126); no test covers expand near the dateline.
• Longitude is cyclic everywhere else in geo3d. The factory builds dateline-crossing boxes (GeoBBoxFactory.java:79-82), expand widens a crossing box straight across the dateline, and every expand except GeoDegeneratePoint's special-cases a span that reaches the whole world (GeoRectangle.java:221-224), which only makes sense if longitude wraps.
• The continuity pair. [2.5, -π + 0.001] and [2.5, π - 0.001], two boxes 0.002 rad apart, grow east by 0.3 and 0.001 rad under expand(0.3). A deliberate saturation rule would not depend on which side of the seam an edge sits.
• spatial4j's own geo buffer wraps. Geo3dRectangleShape implements spatial4j's Rectangle.getBuffered. In a geo context, spatial4j 0.8's RectangleImpl.getBuffered normalizes both moved longitudes with DistanceUtils.normLonDEG, and it clamps to the world bounds only in a non-geo context. The Geo3D context is a geo context (spatial4j's factory defaults to geo = true, and the Geo3D factory does not change it).
• Lucene's own geo buffer wraps too. WithinPrefixTreeQuery.bufferShape (spatial-extras, WithinPrefixTreeQuery.java:112-150) grows a shape's bounding box by a distance and, in a geo context, wraps both moved longitudes with DistanceUtils.normLonDEG (:126-140); it clamps only in a non-geo context (:141-147).
• Nothing documents a clamp. No javadoc, CHANGES entry, MIGRATE note, test or code comment says that expanded boxes stop at ±180°.
• History. The unwrapped bounds and the clamp both came with the first geo3d check-in (LUCENE-6196, 2015); its discussion, now #7258, never mentions expanding across the dateline.

The strongest works-as-designed case (the hunt's intended-behaviour checker and a cross-model reviewer, rated moderate): the clamp looks purpose-built for expand. makeGeoBBox clamps exactly the four overflows that expand can produce, and no other in-tree caller was found to pass an out-of-range longitude (180 * DEGREES_TO_RADIANS is exactly Math.PI), while the constructors reject everything else out of range ("Accepts only values ... lon: -PI -> PI", GeoRectangle.java:91); expand and the clamp arrived together; the javadoc is one line and the API is @lucene.experimental; spatial4j's Shape.getBuffered contract is loose ("some shapes might buffer differently ... the returned shape should contain the current shape", which the clamped box satisfies); and the patch note of LUCENE-7951 (#9000), which added getBuffered, says "BUFFER: The Satial4j [sic] buffer extension is partially supported."

Why it fails: the continuity pair shows the result is not a consistent rule. Saturating at a limit makes sense for latitude at the poles, not for longitude, which has no edge. testBBoxExpand states the widening semantics, and spatial4j's own geo buffer and Lucene's WithinPrefixTreeQuery.bufferShape both wrap across the dateline. And "partially supported" most plausibly refers to the Geo3D shapes other than points and rectangles, whose getBuffered throws (Geo3dShape.java:141-143); nobody in #9000 mentions the dateline.

Option A was applied in a scratch worktree at a9779ef3c193 and run through gradle (seed DEADBEEF), and checked against every hunt repro with the same classes shadowed onto the main jars; B, C and D were not run.

In all 13 expand methods, after the whole-world check, add if (newLeftLon < -π) newLeftLon += 2π; and if (newRightLon > π) newRightLon -= 2π;. GeoDegeneratePoint.expand also gets the whole-world check (2 * angle >= 2π gives the full longitude range); without it, wrapping would turn a buffer of more than half the world into a small box. Only expand knows the box's span: after the whole-world check the new span is below 2π, so a bound past ±π wraps exactly once, and the factory then builds a dateline-crossing box, as it already does for boxes that cross. Latitude handling and the factory are unchanged.

     if (currentLonSpan + 2.0 * angle >= Math.PI * 2.0) {
       newLeftLon = -Math.PI;
       newRightLon = Math.PI;
     }
+    // The moved longitude bounds wrap across the dateline (the factory would clamp them to +-PI)
+    if (newLeftLon < -Math.PI) {
+      newLeftLon += Math.PI * 2.0;
+    }
+    if (newRightLon > Math.PI) {
+      newRightLon -= Math.PI * 2.0;
+    }
     return GeoBBoxFactory.makeGeoBBox(

Trade-offs

• Behaviour change: boxes expanded near the dateline become larger (they now cross it), so buffered queries match more near ±180° and negated predicates match less. Results whose moved edges stay within ±180° are unchanged.
• A second, separate change: the new GeoDegeneratePoint whole-world check makes a point expanded by an angle of at least π the full longitude range, where stock clamps one edge and (except at longitude 0) returns a range short of the world. No test in the fix covers it; it deserves its own test and a note.
• Duplication: the same 7 lines in 13 classes (see option B).
• Cost: two comparisons per expand (three in GeoDegeneratePoint); no benchmark was run. Validated for positive, finite angles only; negative, NaN and infinite angles were not tested. No format or API change.

What the checks validated

• Stock main a9779ef3c193 (gradle, seed DEADBEEF): the repro fails 3 of 5 and 1 of 4 with assertions on and off; TestGeoBBox (11 tests) and the spatial4j Geo3D suites (TestGeo3d, TestGeo3dRpt, TestGeo3dShape*: 21 tests, 4 skipped) pass.
• With the fix: the repro passes 9 of 9 with assertions on and off; all of :lucene:spatial3d:test (186 tests, 3 skipped) and :lucene:spatial-extras:test (121 tests, 5 skipped), repro classes included, pass with 0 failures, and per class the counts equal a stock run of both modules except the two repro classes; ecjLintMain, ecjLintTest and checkGoogleJavaFormat pass for spatial3d, and ecjLintTest and checkGoogleJavaFormat for spatial-extras (whose main sources the fix does not touch); the diff applies cleanly to a clean tree.
• With the same 13 classes shadowed onto the main jars: this repro 9 of 9; the hunt's independent reproducer 12 of 12 (including the 23,040-check sweep), the continuity and WKT probes, the downstream probe (0 of 100 comparisons wrong, from 44) and the lattice check (0 longitude-widening violations, from 11,446).

Move "whole-world check, then wrap" into one package-private helper (for example next to makeGeoBBox) that the 13 expand methods call with their unwrapped bounds and current span.

Trade-offs

Not run. Same behaviour as A with one place to maintain; a larger diff that touches every expand.

Replace the two longitude clamps in the factory with a wrap.

Trade-offs

Not recommended; not run. The factory sees two numbers, not the span, so it cannot tell an edge moved past the dateline from a range slightly wider than the world, and it is a public entry point, so wrapping there would change the result for any external caller that passes out-of-range longitudes (no in-tree caller other than expand was found to do so). It changes behaviour for every caller, not only expand.

Say in the expand and getBuffered javadoc that expanded boxes stop at ±180°.

Trade-offs

Not recommended. Keeps the wrong results and the jump between boxes on either side of the seam.

Method: semi-formal, bounded-exhaustive checking against exact semantics (hunt unit on spatial3d box and solid families, 2026-10-26, main a9779ef3c193).

• A harness enumerated a lattice of 10,117 boxes (67 latitude pairs x 151 longitude pairs) through GeoBBoxFactory.makeGeoBBox on the sphere and WGS84, expanded each by 0.001, 0.1 and 0.5 rad, and checked two properties of the result against exact geometry: it contains the original box (38,549,892 checks, 0 failures), and a point half the angle past each latitude and longitude edge is inside it (705,366 latitude and 675,904 longitude checks).
• 11,446 longitude checks failed; the finder reports that all are boxes whose moved edge passes ±π, across every class. 1,566 latitude checks also failed, all at pole points: a separate, untriaged observation that the fix does not change.
• The finder found the root cause (unwrapped bounds into the clamping factory) by reading the code, wrote public-API JUnits for spatial3d and spatial-extras, and with the fix sketch shadowed the longitude failures went to 0.
• An independent reproducer then found the end-to-end query path (SpatialArgsParser -> WKT BUFFER -> getBuffered -> expand) and its 0-instead-of-1 result.