A Geo3D distance query with a radius of a few centimetres can match every point on the planet: a 1.24 cm Geo3DPoint.newDistanceQuery matches its centre's antipode

Geo3DPoint.newDistanceQuery returns a "query matching points within this distance". On WGS84, with a radius between about 2e-5 m (below that the circle becomes a single point) and about 20 cm, some calls instead build a circle that contains its own antipode: the whole planet minus a speck around the centre (below about 1 mm, minus a patch of up to a few hundred metres), and the query silently matches every indexed point outside it: a 1.24 cm query matches a document at the centre's antipode, about 20,000 km away. Below 10 cm this happens to up to about a quarter of the calls, about half throw one of two existing exceptions ("Couldn't construct circle plane, probably too small?" or "Couldn't construct intersection point, probably circle too small?"), and the rest are correct; above 12 cm it gets rare, and the largest failing radius found is 19.6 cm (an observed maximum, not a proven bound).

The cause: GeoStandardCircle cuts the planet with a plane through two rim points and lets SidedPlane take the inside from the sign of evaluate(center). The centre is only about r^2/2 from that plane (1.9e-18 here), about a hundred times below the spacing of doubles near the plane's offset (2.2e-16), and only an exact 0.0 is rejected. The same cutoff angles fail on PlanetModel.SPHERE, through GeoCircleFactory.makeGeoCircle, and through spatial-extras' default spherical Geo3D context. Present since geo3d's first release (5.2.0; newDistanceQuery since 6.1.0) up to 10.6.0 and main. A small fix takes the side from the sign of normal . center instead; it passes the repro and the spatial3d tests. It removes the far-side matches; it does not make centimetre circles centimetre-accurate.

1. Geo3DPoint.newDistanceQuery (Geo3DPoint.java:122-130) calls Geo3DUtil.fromDistance (Geo3DUtil.java:152-162), which turns the radius into an angle (radius / mean planet radius, :159) and calls GeoCircleFactory.makeGeoCircle (GeoCircleFactory.java:38-47): below MINIMUM_ANGULAR_RESOLUTION (Vector.java:29, pi x 1e-12 rad, about 2e-5 m on Earth) a GeoDegeneratePoint, otherwise a GeoStandardCircle.
2. GeoStandardCircle takes two rim points at latitude +/- the cutoff angle (GeoStandardCircle.java:69-90) and builds the plane through them (:100-102) with SidedPlane.constructNormalizedPerpendicularSidedPlane(center, normalPlane, upperPoint, lowerPoint) (SidedPlane.java:211-226), which ends in new SidedPlane(center, n, D); a null result becomes "Couldn't construct circle plane, probably too small?" (GeoStandardCircle.java:103-111).
3. SidedPlane(Vector p, Vector v, double D) (SidedPlane.java:183-190):

   sigNum = Math.signum(evaluate(p));          // p is the circle's centre
   if (sigNum == 0.0) {                         // only an exact zero is rejected
     throw new IllegalArgumentException("Cannot determine sidedness because check point is on plane.");
   }

1. The sign is noise. In exact arithmetic evaluate(center) is about r^2/2 in size for a cutoff angle r, with the sign of n . center. For the repro (1.24 cm, r = 1.945e-9 rad) that is 1.9e-18, while doubles near the plane offset D = 1.0010804326724039 are 2.2e-16 apart. The computed value is +2.220446049250313E-16 (one step), and an exact (BigDecimal) evaluation of the rounded plane at the rounded centre gives +2.18e-16: the rounded plane itself has the centre on the wrong side. sign(n . center) is -1, so the cap is on the negative side, but sigNum is +1.
2. Wrong sign, (almost) the whole planet. isWithin (GeoStandardCircle.java:175-181, SidedPlane.java:300-309) counts anything within 1e-12 of the plane as inside and otherwise compares signs with sigNum. With the wrong sign it accepts every point off the cap and every cap point within the band. The repro's cap is only about 1.9e-18 deep, so the shape is the whole planet, and its bounds (GeoStandardCircle.java:218-226) cover the planet too, so the index's box test filters nothing. The same holds for every sampled wrong-sided circle from about 1 mm up. Below about 1 mm the rounding of the two rim points, only 2r apart, also tilts the plane (SidedPlane.java:216-218 builds the normal from their difference), the real cap can be deeper than the band, and many such circles leave out a patch near the centre (the numbers below).
3. Many tiny circles round evaluate(center) to exactly 0.0 and get the clean exception (6,077 in the WGS84 sweep below); 510 more fail a second guard, "Couldn't construct intersection point, probably circle too small?" (GeoStandardCircle.java:112-118); the rest get a noisy sign, right or wrong. r^2/2 is 0.8 of a rounding step at 12 cm and 2 steps at 19 cm, so failures thin out above 12 cm.

• The repro circle (WGS84, 1.24 cm): contains its centre, points 10 m, 1 km and 0.5 rad away, and its antipode; bounds x, y in [-1.0011, 1.0011], z in [-0.9978, 0.9978], the whole planet. A 0.1 m circle at the same centre also contains its antipode; 0.5 m, 1 m, 10 m and 1 km are correct. On SPHERE the same cutoff angle fails the same way; there newDistanceQuery reads its radius argument as the angle in radians (SPHERE's mean radius is 1.0, PlanetModel.java:31, :142).
• Sweep, 20,000 random WGS84 circles, radii log-uniform from 1e-5 m to 10 m: 2,587 contain their own antipode. Per decade (exception "circle plane" / exception "intersection point" / correct / contains its antipode): 1e-5 to 1e-4 m 1,112 / 2 / 641 / 585; 1e-4 to 1e-3 m 1,632 / 9 / 852 / 819; 1e-3 to 1e-2 m 1,635 / 95 / 829 / 753; 1e-2 to 1e-1 m 1,562 / 376 / 1,006 / 420; 0.1 to 1 m 136 / 28 / 3,205 / 10; 1 to 10 m 0 / 0 / 3,292 / 0. The other 1,001 radii, all below the 2e-5 m threshold, became a GeoDegeneratePoint, a third outcome without an exception. The circles that contain their antipode are as many as those whose sigNum differs from sign(n . center) (2,587 each); a fact check's own probe matched the two circle by circle (19,004 of 19,004 WGS84 and 21,899 of 21,899 SPHERE circles). SPHERE, same cutoff angles: 3,059.
• The upper end: 711 of 200,000 random WGS84 circles from 0.10 to 0.30 m contain their antipode, 27 of them above 0.15 m, the largest 0.1889 m (2.96e-8 rad); 173 of 400,000 from 0.15 to 0.20 m; 0 of 400,000 each from 0.20 to 0.30 m and 0.30 to 0.60 m. Public-API WGS84 queries of 15.4, 16.2 and 17.9 cm each match a document at the centre's antipode. A second fact check sampled 4,000,000 WGS84 circles from 0.185 to 0.30 m: 4 contain their antipode, none at 0.20 m or more; the largest, a 19.63 cm (3.08e-8 rad) newDistanceQuery centred at (14.514881155433457, 48.76857350643001), matches a document at the antipode; with the fix, 0. The largest failing radius is an observed maximum on one platform, not a proven bound.
• What a wrong-sided circle leaves out: the repro circle leaves out nothing (0 of 2,000,000 random planet points and 0 of 200,000 points from 1.2e-5 m to 12 km around the centre are outside). Over 200,000 random circles per model from 2.1e-5 to 0.2 m, every wrong-sided circle from 1 mm up has its whole cap within the 1e-12 band; below 1 mm many leave out their deepest cap point and a patch around it (WGS84: 7,442 of 8,708 wrong-sided circles below 0.1 mm, patches up to about 360 m; 3,664 of 12,700 from 0.1 to 1 mm, up to about 77 m). Through the public API a 2.53e-5 m query matches its centre and its antipode but not a document 566 m away.
• End to end: 200 fixed centres with a 1 cm newDistanceQuery on a 162-document world grid: 36 queries match all 162 documents, 109 throw, 55 are correct; 1 km controls match nothing. On a 20,001-document index the repro circle and a 10 cm circle match all 20,000 far documents.

• Who. Users of the opt-in spatial3d module (Geo3DPoint and the geom classes are @lucene.experimental) that build circles with a cutoff angle between about 3e-12 and 3.1e-8 rad: Geo3DPoint.newDistanceQuery on WGS84 with a radius of about 2e-5 m to 20 cm; the same call on SPHERE with an angle argument in that range (SPHERE's mean radius is 1.0, so the argument is read as radians); GeoCircleFactory.makeGeoCircle directly; and spatial-extras with a spherical Geo3D context, which is Geo3dSpatialContextFactory's default (Geo3dShapeFactory.circle uses makeGeoCircle for a sphere and the unaffected makeExactGeoCircle otherwise). The follow-up's reach probe saw 565 of 2,400 tiny query circles in a spherical spatial-extras context match documents 1,000 km or more away, and 0 of 2,400 with a WGS84 context.
• What goes wrong. A positive distance filter silently matches every document with a point in the field (below about 1 mm, every one outside a patch of up to a few hundred metres near the centre). No exception, default codec and IndexWriterConfig, assertions on or off; every tested index (1, 3, 162 and 20,001 documents) had all its far documents matched. Other clauses of the same query still apply; as a MUST_NOT clause the circle hides everything.
• What stays right. No circle failed in the sampled 20 to 60 cm ranges (400,000 per range and model), and the 0.5 m, 1 m, 10 m and 1 km controls are correct; the tiny radii that throw fail loudly. Correctly sided tiny circles still have a separate precision limit: everything within 1e-12 of the plane counts as inside, so below about 1.4e-6 rad (9 m) a circle behaves roughly like a 9 m circle, and below about 1 mm the tilted plane lets sampled circles reach points up to about 520 m away (about 570 m with the fix).
• How likely. Rare. It needs a radius below 20 cm; in our judgement real distance filters are usually far larger (no usage data was collected). Failures above 12 cm are rare, about half of the calls below 10 cm fail loudly, and no user report was found in the eleven years since 5.2.0. A plausible trigger is an "items at this exact spot" lookup with a millimetre radius.

Same package as Lucene's spatial3d tests (the file carries the Apache license header). Keep the radius to the last digit: whether a given tiny circle comes out inverted depends on rounding. The test has no randomness of its own; the seed only picks the test framework's settings, and seeds DEADBEEF and 5EED1234 (5 iterations) give the same result. The same test is the suggested regression test (with a fail-hard fix it must also accept an IllegalArgumentException).

Only Linux aarch64 was run. Java's + - * / and Math.sqrt are exactly specified, but Math.sin and Math.cos may differ by an ulp on another platform, so the exact set of failing radii is not guaranteed to be the same everywhere. An earlier fact check found that the 8 sin/cos values this circle uses equal StrictMath's; the indexed antipode also goes through GeoPoint's Math.sin and Math.cos (GeoPoint.java:111), which that check did not cover.

cp $REPRO/org/apache/lucene/spatial3d/TestGeo3DTinyRadiusMatchesWholeWorld.java \
   $LUCENE/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/
cd $LUCENE && ./gradlew :lucene:spatial3d:test --tests org.apache.lucene.spatial3d.TestGeo3DTinyRadiusMatchesWholeWorld \
  -Ptests.seed=DEADBEEF -Ptests.asserts=true
# same failure with -Ptests.asserts=false

# lines 65-71 of (private working file), verbatim (main 645d4fe14a20, -Ptests.seed=DEADBEEF, -Ptests.asserts=true)
TestGeo3DTinyRadiusMatchesWholeWorld > testTinyRadiusDoesNotMatchAntipode FAILED
    java.lang.AssertionError: hits for the antipode expected:<0> but was:<1>
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:C7AA9D74D46BEEDB]:0)
        at junit@4.13.2/org.junit.Assert.fail(Assert.java:89)
        at junit@4.13.2/org.junit.Assert.failNotEquals(Assert.java:835)
        at junit@4.13.2/org.junit.Assert.assertEquals(Assert.java:647)
        at org.apache.lucene.spatial3d.TestGeo3DTinyRadiusMatchesWholeWorld.testTinyRadiusDoesNotMatchAntipode(TestGeo3DTinyRadiusMatchesWholeWorld.java:43)

# standalone runner: the same assertion on main and on the 10.6.0, 10.5.2 and 9.12.3 jars, -ea and -da
# with the fix: 1 test, 0 failures (assertions on and off)

• The contract. Geo3DPoint.java:110-121: "Create a query for matching points within the specified distance of the supplied location"; the radius is the "maximum distance from the center in meters: must be non-negative and finite"; "@return query matching points within this distance"; "@throws IllegalArgumentException if ... radius is invalid". The only accuracy caveat is "if PlanetModel#WGS84 is used, the query is approximate and may have up to 0.5% error" (:112-113); the bug also happens on SPHERE, and the error here is the whole planet.
• The code's own answers for too-small circles are a point or an exception: GeoCircleFactory.java:43-45 returns a GeoDegeneratePoint (CHANGES, LUCENE-6798: "Geo3d now models degenerate (too tiny) circles as a single point"), GeoStandardCircle.java:103-111 throws "probably too small", and TestGeo3DPoint.java:898-903 catches that exception with "angle is too small; try again". GeoExactCircle.java:401 rejects a plane with the antipode inside ("Plane is bogus, we cannot build the circle", added for #9128).
• History. In #7655 (LUCENE-6597, 2015) geo3d's author, Karl Wright (DaddyWri), wrote that accepting a null circle plane "would represent a whole-world circle, not a zero-world circle". In #7817 (LUCENE-6759) they proposed to "throw an IllegalArgumentException whenever the math falls apart" for tiny circles, and Michael McCandless (mikemccand) agreed; that is the guard this bug slips past. The searches found no test, CHANGES entry or comment that accepts a tiny circle containing its antipode.
• Legal input. A finite, non-negative radius; upstream TestGeoCircle.java:136-139 builds a 1.7e-8 rad circle ("Eleventh BKD discovered failure") as ordinary input.
• Why tests miss it. Upstream random circles draw the angle uniformly from [0, pi/2] (TestGeo3DPoint.java:896), so the window below about 3.1e-8 rad is hit with probability about 2e-8 per circle, and the random shape tests use shape.isWithin as their own oracle, so a backwards shape agrees with itself.

The strongest case (built by the intended-behaviour verifier; the adjudication and the reading-only cross-model review weighed the same points): geo3d is @lucene.experimental and approximate; the maintainers know that plane math loses accuracy for tiny shapes (#7690 / LUCENE-6632: circle planes are "less accurate the smaller the circle"); the 1e-12 band already makes caps below 9 m inexact; a centimetre circle is below the library's real resolution (geo3d's author in 2015: hardly anyone "except for missile designers" needs centimetre resolution); and open #9623 already proposes moving newDistanceQuery to GeoExactCircle.

Why it fails: a few metres of imprecision is a precision limit, containing the antipode is not. The maintainers fixed earlier tiny-circle failures instead of accepting them, chose to throw rather than return wrong shapes, and ruled out "whole world" for degenerate circles; @lucene.experimental permits API changes, not wrong answers; the 0.5% note is about ellipsoid distance and the bug reproduces on SPHERE; #9623 is an open 2018 accuracy proposal that never mentions small radii, and would still leave makeGeoCircle and spatial-extras' spherical context affected. Verdict: a defect (adjudication: confirmed, high confidence).

One fix was validated with gradle; two alternatives that follow the 2015 "fail hard" decision were not run.

The hunt's fix, with its code comment re-wrapped for google-java-format: in the GeoStandardCircle constructor, compare SidedPlane's sigNum with sign(n . center) and use the reversing copy constructor SidedPlane(SidedPlane) (SidedPlane.java:34-37) when they differ. On a sphere the exact evaluate(center) = (n . center)(1 - cos r) has the sign of n . center for any cutoff in (0, pi); on WGS84 the normal was at most 0.19 degrees from the centre direction over the circles built from 300,000 random radii of 2.1e-5 to 0.6 m, and no sweep found a disagreement (sampled evidence, not a proof for every WGS84 circle). |n . center| is about 1, far above rounding error. Where the signs agree nothing changes; the exact-zero case still throws.

final SidedPlane plane =
    SidedPlane.constructNormalizedPerpendicularSidedPlane(
        center, normalPlane, upperPoint, lowerPoint);
// SidedPlane takes the inside from the sign of evaluate(center). For a small cutoff angle
// the centre is only ~cutoff^2/2 from the plane, far below the rounding error of the plane,
// so that sign is noise. The cap is always on the side the plane normal points to relative
// to the centre, so take the side from the sign of normal . center instead.
if (plane != null
    && Math.signum(plane.x * center.x + plane.y * center.y + plane.z * center.z)
        != plane.sigNum) {
  this.circlePlane = new SidedPlane(plane);
} else {
  this.circlePlane = plane;
}

Trade-offs

• About half of the tiny radii still throw the existing exception, and correctly sided tiny circles keep the separate 9 m precision band; below about 1 mm the formerly inverted circles become circles that reach points up to about 570 m away (sampled).
• Single-point GeoStandardPath end caps build the same kind of plane and are not covered; the finder's width sweep saw them contain their antipode and, for some widths, a NullPointerException while building the path (GeoStandardPath.java:187-189 uses onlyEndpoint.circlePlane without a null check). Neither has a minimal test of its own: a follow-up with its own test.
• Cost: one dot product per circle construction, nothing per document. No benchmark run.

What the checks validated

• Gradle, scratch worktree of 645d4fe14a20, the diff applied with git apply: stock + test fails; with the fix the whole :lucene:spatial3d:test suite, minimal test included, passes with assertions on (182 tests, 0 failures, 3 skipped as @Nightly), and the minimal test also passes with assertions off.
• Standalone: the test passes with -ea and -da. The 20,000-circle sweeps give 0 circles containing their antipode on WGS84 and SPHERE, with every exception count unchanged; the upper-end sweeps (0.10 to 0.60 m, both models) give 0.
• Earlier runs: :lucene:spatial3d:check -x test (google-java-format, ecjLint, forbiddenApis) passes with this file, and spatial-extras' four Geo3D test classes (21 tests, 4 skipped as @Nightly) pass with the same code in the hunt's comment wrapping; an independent verifier's 1,785-circle scan (0 fail open, exceptions unchanged) and the follow-up's reach probes pass with it.
• What this shows: the far-side matches are gone in every run and sweep and the exceptions are unchanged. It does not show centimetre accuracy, and it is no proof for every WGS84 circle.

After building the plane, throw the existing exception when circlePlane.isWithin(-center.x, -center.y, -center.z), the check GeoExactCircle got for #9128.

Trade-offs

Matches the 2015 "throw whenever the math falls apart" decision, but turns the fail-open quarter into exceptions, so about three quarters of tiny radii would throw; the regression test must then accept an IllegalArgumentException. It may also reject near-whole-world circles whose antipode lies inside the 1e-12 band; untested.

Make GeoCircleFactory.makeGeoCircle (GeoCircleFactory.java:43) return a GeoDegeneratePoint up to the end of the window.

Trade-offs

The threshold must clear about 3.1e-8 rad (a 19.6 cm WGS84 circle still contains its antipode); every query between 2e-5 m and about 20 cm then becomes a point that matches only within 1e-12 per coordinate (a few micrometres), and upstream TestGeoCircle builds a 1.7e-8 rad circle.

The finder's first attempt.

Trade-offs

Breaks upstream TestGeoCircle.testCircleBounds (1 of 7 tests fails), which builds a 1.7e-8 rad circle.

• Harness. A randomized metamorphic harness built for the spatial3d hunt unit ran 480,000 trials comparing shape membership with an independent exact sphere reference. It flagged GeoStandardPath shapes 1e-9 to 1e-8 rad wide whose isWithin accepted points about 1 rad away.
• Reduction by hand. Single-point paths, then GeoStandardCircle (a width sweep), then SidedPlane's side test, then an end-to-end newDistanceQuery over a world grid of documents, then the JUnit test.
• Then an independent reproducer, a reading-only cross-model review (an independent reviewer from another model family, OpenAI GPT-5.6), a devil's-advocate verifier and an adjudication. The first signal came from randomized testing, so the finding counts as non-formal.