GeoExactCircle outside distance never measures the slice end points, so points due north or south of an exact circle on WGS84 can get +Infinity

GeoCircleFactory.makeExactGeoCircle builds a circle on an ellipsoid out of flat slices that meet at their end points. GeoExactCircle.outsideDistance takes the minimum, over the slices, of the distance to the slice's plane bounded to the slice's own sector, and never measures the end points. When the nearest edge point of an outside point is such a joint, the point's foot on each of the two neighbouring slice planes can land just past the joint, outside that slice's sector; then both return +Infinity and the minimum is +Infinity or the distance to a slice on the far side of the circle. On WGS84 two joints always sit due north and due south of the centre: for the exact circle at (0.3, 0.2) with radius 0.1 (about 637 km) and accuracy 1e-6, a point 0.11 due north gets +Infinity instead of at most 0.009558 (the shape's own edge point), and so do the other five points tested due north or south of this circle, in all five plane-based distance styles, while the same point 0.0005 (about 3 km) east gets 0.009559, within 4e-9 of its edge point. In a sweep of WGS84 and CLARKE_1866 circles of radius 0.01 to 0.4, every check on the centre's meridian gave +Infinity; at radius 0.001 some did not. Near other joints the far side can win (0.2504 instead of 0.0501), and on the unit sphere a circle of radius 1e-4 gives 0.0012 instead of 0.001 for a point due west. Only applications that call the experimental geom API directly are hit; no Lucene query, sort or module computes an outside distance on an exact circle. The defect is as old as the class (LUCENE-7970, 7.1.0); adding the stored end points to the minimum, as GeoConvexPolygon does with its vertices, closes the gap, with all of lucene/spatial3d passing; outside distances on an ellipsoid stay approximate.

• Exact circle: GeoCircleFactory.makeExactGeoCircle(planetModel, lat, lon, radius, accuracy) returns a GeoExactCircle, "the most accurate shape to represent a circle in non-spherical planets". It approximates the circle by slices: each slice is a plane through three points of the true circle, bounded to its sector (the wedge between its two end points, seen from the centre) by two sided planes through the centre. Slices are split until every plane is within accuracy of the circle.
• Joint: an end point shared by two neighbouring slices. The slices start as north -> east -> south and south -> west -> north, so on WGS84 and on the sphere the north and south points are always joints. The repro's circle has 8 slices with joints at bearings 0, 45, 90, ..., 315 degrees.
• Outside distance: GeoOutsideDistance.computeOutsideDistance(style, point), "the distance from a point to the closest outside edge", 0.0 inside. Radii and ARC distances are in planet units, about radians: 0.1 is about 637 km on Earth.

1. GeoBaseMembershipShape.computeOutsideDistance returns 0.0 inside, else outsideDistance (GeoBaseMembershipShape.java:46-53).
2. GeoExactCircle.outsideDistance (GeoExactCircle.java:245-258) returns the minimum over the slices of distanceStyle.computeDistance(planetModel, slice.circlePlane, x, y, z, slice.plane1, slice.plane2): the plane distance, bounded to the slice's sector. No end point is measured.
3. For ARC that is Plane.arcDistance (Plane.java:600-636): intersect the slice plane with the plane through the point perpendicular to it, keep the intersection points that meet all bounds, else +Infinity.
4. Think of the slices as the sides of a polygon. For a point beyond a corner, the nearest boundary point is the corner, and the foot on each of the two sides that meet there lies past the corner, outside that side. Each side declines, and the corner is never asked. For q 0.11 due north, all 8 slices find intersection points and none is inside its sector; on the two slices that meet at the north joint the near foot (0.00955806 away) fails the bound through the joint by 6.85e-6, a geometric miss, not rounding. The joint is 0.009558 away. A joint as the nearest edge point is not enough on its own: a foot that misses by less than the 1e-12 tolerance is kept (the independent reproducer found 5 of 6 sphere joint cases wrong), and at radius 0.001 on WGS84 some meridian points get finite values.
5. If the perpendicular plane meets a slice on the far side inside its sector, that distance wins: about the offset plus twice the radius. On the sphere a small circle lies in one plane, so the slice planes nearly coincide and the near foot misses its bound only by rounding (about 3e-12 to 4e-12): for q 0.001 west of a 1e-4 circle, the two slices at the west joint return +Infinity and the two eastern ones 0.0012.
6. The class stores each slice's end points (notableEdgePoints, GeoExactCircle.java:437-454) and uses them in getBounds (:306-316) and intersects (:277-304), but not here. GeoConvexPolygon.outsideDistance adds its vertices (GeoConvexPolygon.java:511-528) and GeoRectangle.outsideDistance its four corners (GeoRectangle.java:325-347).

On WGS84 and CLARKE_1866, meridian points outside the circle got +Infinity in every check at radius 0.01 to 0.4 (64 to 2,548 km), and in 28 of 48 per model at radius 0.001; around bearings 0 and 180 the +Infinity wedge is about +/-0.004 degrees wide for a point 0.01 outside a 637 km circle, +/-0.015 at 0.05 and +/-0.0225 at 0.1 (slightly narrower around 180). On the sphere only some very small circles at an exact joint bearing are hit: the finder's sweep found them at its radii 1e-5 and 1e-4, none at 1e-6 or at 1e-3 and above, and another sweep none at 3e-5.

• Who. Applications that build a circle with GeoCircleFactory.makeExactGeoCircle and call computeOutsideDistance on it themselves, for example to rank or filter points by their distance to a circular area. The Geo3DDocValuesField outside-distance sorts build standard circles (Geo3DUtil.fromDistance -> makeGeoCircle, Geo3DUtil.java:160), and spatial-extras builds exact circles (Geo3dShapeFactory.java:188-194) but never calls computeOutsideDistance.
• Effect. A point just beyond the circle's north or south edge can look infinitely far away; near some other joints it looks about twice the radius too far. No exception, with assertions on or off; query-time arithmetic only, nothing is written and no hit set changes.
• Default vs opt-in. The optional lucene/spatial3d module and its @lucene.experimental geom API. Within it no special setting: WGS84 and CLARKE_1866 are hit at every accuracy tested (1e-4 and 1e-6 in the audit sweep; 1e-4 to 1e-8, by factors of 10, for the repro's circle in a fact-check probe), the sphere only for very small circles.
• Scale. None: one point, deterministic.
• How likely. Rare for arbitrary data (3 to 21 of 72,001 bearings for a 637 km circle at accuracy 1e-6, 73 at 1e-4), but likely for a hand-written "point due north" check (every one at radius 0.01 to 0.4 in the audit sweep). No public report in the 9 years since 7.1.0.
• Could widen. Open issue #9623 (LUCENE-8577) proposes exact circles for Geo3DPoint distance queries. The query itself uses membership only (Geo3DPoint.java:122-129), but if the change were made in the shared Geo3DUtil.fromDistance, Geo3DDocValuesField.newOutsideDistanceSort (Geo3DDocValuesField.java:249-258) would reach this bug.
• Workaround. A standard circle (GeoCircleFactory.makeGeoCircle) has no slices and so no joints: with the same centre and radius it gave a finite 0.05 where the exact circle gave +Infinity in a cross-model check (not tried as a workaround beyond that). It is a less exact shape on an ellipsoid, and below about 50 km it hits LFV-274. A caller cannot add the joints itself: getEdgePoints exposes only one edge point (GeoExactCircle.java:193).
• Related findings (separate reports, other fix sites): LFV-274 (on an ellipsoid, circles smaller than about 50 km, standard and exact, get +Infinity and somewhat larger ones finite values that are too large, because the perpendicular plane in Plane.arcDistance misses the circle or meets it at the wrong points; narrow fix in GeoStandardCircle; this fix also makes its small exact-circle +Infinity values finite, though not exact), and two other outside-distance defects in sibling shapes: LFV-782 (the outside distance to a polar box ignores the pole, a missing candidate point as here) and LFV-735 (GeoStandardPath measures its end caps to the end point instead of the cap edge).

# Lucene main 645d4fe14a20, assertions on (-ea), seed DEADBEEF: 1 test(s) run, 1 failed
    => java.lang.AssertionError: expected:<0.009558> but was:<Infinity>
       org.junit.Assert.fail(Assert.java:89)
       org.junit.Assert.failNotEquals(Assert.java:835)
       org.junit.Assert.assertEquals(Assert.java:555)
       org.junit.Assert.assertEquals(Assert.java:685)
       org.apache.lucene.spatial3d.geom.TestGeoExactCircleOutsideDistance.testPointDueNorthOfCentre(TestGeoExactCircleOutsideDistance.java:27)

• The contract. GeoOutsideDistance: "Implemented by Geo3D shapes that can compute the distance from a point to the closest outside edge." and "A return value of 0.0 should be returned for points inside of the shape." (GeoOutsideDistance.java:19-21, :31-33). +Infinity is documented only for the internal distance of points outside (GeoDistance.java:28-36).
• The factory's promise. "the most accurate shape to represent a circle in non-spherical planets", with the accuracy "the maximum linear distance between any point on the surface circle and planes that describe the circle" (GeoCircleFactory.java:49-57). That accuracy bounds how far the planes are from the circle, not the output of computeOutsideDistance, but +Infinity or twice the radius is something the shape's geometry does not explain.
• The class's own geometry. notableEdgePoints holds every slice's end points and getBounds and intersects use them; only outsideDistance leaves them out.
• Precedent in the same class. LUCENE-8057 (#9105): 9776e1f4a0a "getBounds() for exact circle did not include segment endpoints.", listed under bug fixes (lucene/CHANGES.txt:7753).
• Siblings. GeoConvexPolygon and GeoRectangle, built from the same bounded plane distances, add their vertices or corners to the minimum.
• Tests. No upstream test asserts an outside distance on an exact circle, so nothing pins the current values; the circle assertions in lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/TestGeoCircle.java:66-72 use a standard circle and expect the finite distance to the nearest edge.

The strongest case for "intended" (built by the intended-behaviour checker; rated weak by the cross-model reviews, the independent reproducer and the adjudication): the geom API is @lucene.experimental; GeoExactCircle is package-private and documented as an approximation by sectors; +Infinity is Plane's established "not in bounds" result; GeoOutsideDistance never literally promises a finite value; and in LUCENE-7970 (#9019, 2017-09-23) the geo3d maintainer wrote "GeoOutsideDistance we can't really do at the moment".

Why it fails: the interface promises the distance to the closest edge, and a joint is a point of that edge; the class implements outsideDistance and, 3 km from the joint, is within 4e-9 of the edge distance, so this is a missing case, not a design; +Infinity and +2r are not approximation errors at accuracy 1e-6; the 2017 remark was about an earlier inner/outer-plane design and came two days before the committed design, which implements outside distance; and the maintainers fixed the same end-point gap in getBounds as a bug. Expect a maintainer to say the API is experimental and rarely used, and that the fix changes existing values and adds two point distances per slice: that bears on priority, not validity.

Option A was applied in a scratch worktree at a9779ef3c193 and run through gradle (seed DEADBEEF); B, C and D were not run.

In GeoExactCircle.outsideDistance (:245-258), inside the loop over the slices, also take the minimum of distanceStyle.computeDistance(endPoint, x, y, z) over slice.notableEdgePoints. The boundary is the union of the slice arcs, each closed by its two end points; for an outside point the nearest boundary point is inside some arc or an end point. The bounded plane distance covers the first case (on the sphere; on an ellipsoid only approximately, see the trade-offs and LFV-274), and this adds the second. It uses the same computeDistance(GeoPoint, x, y, z) as the polygon vertices, so every distance style works; the end points lie on the circle, so the change can only lower a value, to the distance of a real edge point.

--- a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoExactCircle.java
+++ b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoExactCircle.java
@@ -253,6 +253,14 @@ class GeoExactCircle extends GeoBaseCircle {
       if (distance < outsideDistance) {
         outsideDistance = distance;
       }
+      // The closest edge point can be a slice end point, where two slices meet; the bounded plane
+      // distance of neither slice reaches it.
+      for (final GeoPoint endPoint : slice.notableEdgePoints) {
+        final double endPointDistance = distanceStyle.computeDistance(endPoint, x, y, z);
+        if (endPointDistance < outsideDistance) {
+          outsideDistance = endPointDistance;
+        }
+      }
     }
     return outsideDistance;
   }

Trade-offs

• Cost and compatibility: two extra point distances per slice and call (each joint is measured twice, once per neighbouring slice); no benchmark was run. No API, format or index change, but observable values change: results that are +Infinity or the far side today become finite and smaller. A value changes only where an end point is closer than every foot the slices keep: the joint cases and, on small ellipsoid circles, LFV-274's no-intersection cases at any bearing (with the end points the finder's WGS84 sweep has no +Infinity left).
• No precision claim: it does not make outside distances on an ellipsoid exact. Away from the joints the bounded plane distance can still exceed the shape's own edge distance on WGS84 (circles at (0.3, 0.2), points 1e-4 to 0.1 outside): by up to 9.5e-6 for the repro's circle (r 0.1), up to 1.6e-4 for a 64 km circle (r 0.01), and at r 0.001 up to 5.3e-4, or 7.1e-4 where the perpendicular plane meets no slice. That is Plane.arcDistance's foot on an ellipsoid (LFV-274's family), not the plane approximation and not this bug; the finder's WGS84 sweep with the end points still has 30,085 finite violations of its bound in 322,675 checks, 9,000 of them where the perpendicular plane meets no slice.
• With the PR: add the repro (or a joint case in TestGeoExactCircle, which has no outside-distance test yet) and a CHANGES entry.

What the checks validated

• Stock main a9779ef3c193 (gradle, seed DEADBEEF): the repro fails 2 of 3 with assertions on and off; TestGeoExactCircle (14 tests) and TestGeoCircle (7) pass.
• With the fix: the repro passes 3 of 3 with assertions on and off; TestGeoExactCircle and TestGeoCircle pass; all of :lucene:spatial3d:test with the repro class added passes (20 classes, 184 tests, 0 failures, 3 skipped); ecjLintMain, ecjLintTest and checkGoogleJavaFormat pass for spatial3d; fix.diff applies cleanly to a clean tree.
• With the fix shadowed onto the main jars (classpath runner, -da): the repro 3 of 3 (also -ea), the independent reproducer's JUnit 3 of 3 and the cross-model stage's five-style JUnit 4 of 4 pass (2 of 3 and 3 of 4 fail without it).
• In the hunt, with the same logic: 41 upstream tests (TestGeoExactCircle, TestGeoCircle, TestRandomGeoShapeRelationship, TestGeo3DPoint) pass. The joint sweep (1,701 exact circles on stock) was re-run with the end points on its 567 sphere and 567 WGS84 circles (CLARKE_1866 was not re-run): the sphere goes from 945 violations to 0 in 188,037 checks, and WGS84 from 56,469 +Infinity values in 322,675 checks to none, with 30,085 finite violations left (see the trade-offs). The +Infinity count includes small-radius cases of LFV-274's mechanism (not re-run independently).

Measure only endPoint1 of each slice. Every joint is the endPoint1 of exactly one slice: the first two slices start at opposite cardinal points (north and south on WGS84 and the sphere, GeoExactCircle.java:119-135; east and west when zScaling > xyScaling, :103-118), each one's endPoint2 is the other's endPoint1, and each split keeps the parent's endPoint1 for its first half and gives the middle point to the second half as endPoint1 (:169-189).

Trade-offs

Half the extra work, but it relies on that construction invariant and treats notableEdgePoints differently from getBounds and intersects (from reading the code; not run).

Say in makeExactGeoCircle or GeoExactCircle that outside distances near slice joints may be +Infinity.

Trade-offs

Cheaper to review and a defensible choice for an experimental API with no in-tree caller, but it leaves an unbounded error for legal input when an eight-line fix exists, keeps the result at odds with the closest-edge contract, and callers cannot tell where the joints are.

Accept feet slightly outside the sector.

Trade-offs

Hides the sphere's rounding case (misses of about 1e-12), but on WGS84 the miss is geometric and grows with the point's distance outside (6.85e-6 at 0.0096, 3.82e-5 at 0.0995 in the audit probe): those two points would need tolerances far above rounding that grow with the distance (no tolerance variant was run).

Method: bounded-exhaustive translation validation on the stock jar (semi-formal tier), in a hunt unit on geo3d distance functions against a reference.

• The unit's harness compared the circle family's distances with a reference and flagged exact-circle outside distances equal to the reference plus 2r on SPHERE and +Infinity on WGS84.
• A joint enumerator then built 1,701 exact circles (3 planet models x 7 latitudes x 3 longitudes x 9 radii x 3 accuracies) and checked the slice-joint bearings (all of them for circles with fewer than 32 joints; otherwise every (n/16)-th joint, 16 to 24 of them, plus the joints nearest the four cardinal bearings) +/- {0, 1e-9, 1e-7, 1e-5, 1e-3} and 36 generic bearings at 5 outside offsets each, against an upper bound from the shape's own isWithin. A per-slice classifier showed that the perpendicular plane does meet each slice plane but the foot misses the slice's sector bounds.
• With the slice end points added in the harness: SPHERE from 945 violations to 0 in 188,037 checks, WGS84 from 56,469 +Infinity values in 322,675 checks to none. The WGS84 count includes small-radius cases of LFV-274's no-intersection mechanism, which the end points also make finite. 30,085 finite WGS84 violations remain, 9,000 of them where the perpendicular plane meets no slice: they come from the plane distance on an ellipsoid (LFV-274's family), not from the joints. CLARKE_1866 was not re-run with the end points.
• Found 2026-10-27 on main a9779ef3c193 and reduced to a public-API JUnit; then checked by an independent reproducer, an intended-behaviour devil's advocate, reviews by a model from another family (OpenAI GPT-5.6), an adjudication, a history, prior-report and security follow-up, and a credibility audit.