A zero-height Geo3D box spanning all longitudes rejects its own latitude on WGS84 and, on the sphere, can claim to contain areas just below it

GeoBBoxFactory.makeGeoBBox(planetModel, lat, lat, -PI, PI), a box whose top and bottom latitude are equal and which spans all longitudes, is the line of latitude lat; the factory builds a GeoDegenerateLatitudeZone for it. Its constructor builds the right plane for that line on the chosen planet model, and intersects, getBounds and outsideDistance use it (the center point is built on the planet model, on the line), but isWithin returns Math.abs(z - this.sinLatitude) < 1e-10. That is wrong twice: sin(lat) is the line's z only on the unit sphere, so on WGS84 the zone rejects the points on its own latitude, even its own getCenter() (at every latitude except the equator and within less than 1e-7 rad of ±35.2 degrees), and accepts another parallel (0.0108 degrees, about 1.2 km, away at 0.5 rad); and 1e-10 is 100 times geo3d's 1e-12 point-on-plane resolution (Plane.evaluateIsZero), which this zone's own intersection test and the sibling line shapes use, so on the sphere, the Geo3D spatial context's default, a rectangle whose top lies a sampled 1.5e-12 to 1.05e-10 rad below the line gets getRelationship = CONTAINS. On an ellipsoid that 1e-10 window sits around the wrong parallel instead, so there rectangles whose top lies at that parallel get CONTAINS.

Through the spatial-extras Geo3D spatial context that becomes WITHIN for whole prefix-tree cells: an Intersects query for rect(-180, 180, 45.000000001, 45.000000001) matched every indexed point between latitudes 10 and 40, while the same line over [-179, 179] matched none. The same line over a longitude range narrower by more than pi x 1e-12 rad at an end is a different class that tests the same plane with plane.evaluateIsZero and is correct. The line dates from the first geo3d release, 5.2.0 (2015); the fix is one line, return plane.evaluateIsZero(x, y, z);.

• Zero-height, full-width box: GeoBBoxFactory.makeGeoBBox(pm, L, L, -PI, PI), with top and bottom latitude equal (within pi x 1e-12 rad, or with sines within 1e-12, which near the poles lets in heights up to about 5.9e-7 rad) and longitudes -180..180 (each end within pi x 1e-12 rad). Geometrically it is the parallel of latitude L. The factory builds a GeoDegenerateLatitudeZone for it; the same line over a range narrower by more than that is a GeoWideDegenerateHorizontalLine or GeoDegenerateHorizontalLine.
• Planet model and plane: geo3d puts points on an ellipsoid such as WGS84 or on the unit sphere (SPHERE, the default of the spatial-extras Geo3D spatial context). A parallel is the horizontal plane z = sin(L) x magnitude(L). That equals sin(L) only on the sphere, at the equator (both are 0) and, on WGS84, at about 35.2 degrees, where the magnitude is 1.
• Resolution: geo3d decides "on the plane" with Vector.MINIMUM_RESOLUTION = 1e-12 (Plane.evaluateIsZero).
• Relationship: GeoArea.getRelationship(shape) answers CONTAINS (the area is inside the shape), WITHIN, OVERLAPS or DISJOINT. GeoBaseAreaShape decides it from a few sampled edge points plus one intersection test. The spatial-extras prefix tree uses it to decide whether a grid cell is entirely inside the query shape (WITHIN) or only touched.

1. GeoBBoxFactory.makeGeoBBox returns GeoDegenerateLatitudeZone for a full-width box with equal latitudes (GeoBBoxFactory.java:58-69, equality tests :145-154; a box narrowed by 3.1e-12 rad at each end is still this class, by 3.2e-12 it is not). Geo3DPoint.newBoxQuery (Geo3DPoint.java:145-155, through Geo3DUtil.fromBox, :173-189) and spatial4j rect in the Geo3D context (Geo3dShapeFactory.java:164-173) reach it.
2. The constructor builds plane = new Plane(planetModel, sinLatitude) (GeoDegenerateLatitudeZone.java:59), the plane z = sinLat x magnitude (Plane.java:88-91). The center/edge point (:61-62), intersects (:110-118), getBounds (:121-124) and outsideDistance (:144-147) use the planet model or this plane.
3. isWithin (:88-91) is return Math.abs(z - this.sinLatitude) < 1e-10;: the unit-sphere z, at a tolerance 100 times the 1e-12 resolution. The literal 1e-10 appears nowhere else in the geom package.
4. WGS84: at 0.5 rad a point on the latitude has z = 0.47959063 but sin(0.5) = 0.47942554 (difference 1.65e-4), so every point on the line, including the zone's own center, is rejected, and the parallel 0.0108 degrees (1.2 km) south is accepted. At 1.2 rad the difference is -1.68e-3, and the accepted parallel lies about 0.27 degrees north. CLARKE_1866 behaves the same. Only at the equator and within less than 1e-7 rad of ±35.2 degrees, where the ellipsoid's z equals sin(lat), does the zone accept its own latitude.
5. Sphere (the Geo3D spatial context's default): for a rectangle just below the line, the rectangle's one sampled edge point (its upper-left corner, GeoRectangle.java:183) passes the 1e-10 test, the line's center is outside the rectangle, and the 1e-12 intersection test finds no crossing, so GeoBaseAreaShape.getRelationship (GeoBaseAreaShape.java:102-133) returns CONTAINS. A gap probe at latitude 0.4: CONTAINS for the sampled gaps 1.5e-12 to 1.05e-10 rad (a finer sweep: 1.1e-12 to 1.08e-10, that is 1e-12 / cos(0.4) to 1e-10 / cos(0.4)), the correct OVERLAPS when touching (0 to 9e-13), DISJOINT at 2e-10; a rectangle above the line and the narrower line give OVERLAPS when touching and DISJOINT at every separated gap. On WGS84 and CLARKE_1866 those rectangles are DISJOINT (correct): the 1e-10 window sits around the wrong parallel, and rectangles whose top lies at that parallel (0.0147 degrees below the line at 0.4 rad, 0.0108 degrees at 0.5 rad) get CONTAINS instead; only at the equator and at 35.196 degrees, where the two parallels coincide, do the ellipsoids show the sphere's case.
6. Search: in the Geo3D context a grid cell is a Geo3dRectangleShape (QuadPrefixTree.java:335, Geo3dShapeFactory.java:164-173), so a cell is related to the query line through Geo3dShape.relate(Geo3dShape) (Geo3dShape.java:55-58, 77-79): the cell's getRelationship(line) of step 5, which Geo3dShape.relate maps from CONTAINS to WITHIN (Geo3dShape.java:70-71). All documents of a WITHIN cell are collected without a geometry check (IntersectsPrefixTreeQuery.java:70-75; CompositeSpatialStrategy's IntersectsRPTVerifyQuery.java:226-249), and at index time a WITHIN cell is stored as fully covered (FilterCellIterator.java:48-51). For the line at 45.000000001 degrees (1.75e-11 rad above 45), the 90 x 45 degree cells [-180, -90] x [0, 45] and [0, 90] x [0, 45] relate WITHIN it; for the [-179, 179] line they are DISJOINT.

• Who. Users of the optional lucene/spatial3d module who build a box with equal top and bottom latitude (or within the equality limit: about 3e-12 rad at most latitudes, up to about 5.9e-7 rad near the poles) over all 360 degrees of longitude, through GeoBBoxFactory, Geo3DPoint.newBoxQuery / newShapeQuery, or a spatial4j rect in the spatial-extras Geo3D spatial context (prefix-tree strategies, including CompositeSpatialStrategy). For example a "points on this parallel" query, or such a line indexed as a shape.
• Geometry API. On the ellipsoids (WGS84, CLARKE_1866) such a box rejects the points of the latitude it was built for, at every latitude except the equator and within less than 1e-7 rad of ±35.2 degrees, and accepts another parallel instead: 0.0108 degrees away at 0.5 rad, at most about 0.015 degrees at the sampled latitudes up to 40 degrees, 0.14 at 60, 0.27 at 1.2 rad, 0.73 at 80 and 2.85 at 86 degrees; from about 87 degrees up it accepts no point at all. Points away from both parallels are still rejected. On the sphere the points of the line are accepted, and so are points up to 1e-10 off its plane. Deterministic; no exception, with assertions on or off.
• Search. In a Geo3D prefix-tree field on the default sphere model, a zero-height, full-width query line whose latitude lies just above a coarse grid edge (by about 1e-12 / cos(lat) to 1e-10 / cos(lat) rad) matches whole cells below it: in the repro every point from 10 to 40 degrees. The prefix tree's grid approximation for this query is 2.25 degrees, far below these 5 to 35 degree errors. An indexed line of the same kind is stored as covering those cells, so it matches searches across the band below it (one such document matched 324 of 1,296 small probe searches). On WGS84 a round 45.000000001 has no effect; the trigger is a computed latitude whose accepted parallel lies just above a grid edge (22.5148379785 degrees for the 22.5-degree edge).
• Geo3DPoint queries. A point on the line decodes up to about 2.3e-10 off the plane (half of the 4.7e-10 encoding step), so a zero-height box rarely matches the points of its own latitude, with or without this bug. On WGS84 the full-width box matched them at none of 400 sampled latitudes and the narrower box at 4 (the repro picks such a latitude, 28.609289316492603 degrees: 0 of 35 points against 35 for the [-179, 179] box); on the sphere the full-width box matched them at 162 of 400 (its 1e-10 tolerance catches part of the rounding) and the narrower box at none.
• Default vs opt-in. Opt-in modules; the Geo3D spatial context defaults to the sphere model. GeoBBoxFactory, Geo3DPoint, Geo3dShape and RecursivePrefixTreeStrategy are @lucene.experimental.
• Scale. None: one shape, point or document triggers it, at any index size.
• Not affected. Boxes narrower than the full circle by more than pi x 1e-12 rad (other classes, correct), boxes taller than the equality limit, the membership of on-line points on the sphere and at the equator, and core LatLonPoint queries.
• How likely. Rare: the shape is unusual and the search-level effects need specially placed latitudes. No user 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 GeoDegenerateLatitudeZone: {planetmodel=PlanetModel.WGS84, lat=0.5(28.64788975654116)} to contain [lat=0.5, lon=1.0([X=0.4743231607827104, Y=0.7387145545857223, Z=0.47959063085955106])], got false
       org.junit.Assert.fail(Assert.java:89)
       org.junit.Assert.assertTrue(Assert.java:42)
       org.apache.lucene.spatial3d.geom.TestGeoZeroHeightFullLongitudeBox.testContainsPointOnItsLatitude(TestGeoZeroHeightFullLongitudeBox.java:27)

• The contracts. Membership.isWithin: "Check if a point is within this shape" (Membership.java:36-44). GeoBBoxFactory.makeGeoBBox: "@return a GeoBBox corresponding to what was specified." (GeoBBoxFactory.java:35). The class javadoc: "an area rectangle of one specific latitude with no longitude bounds" (GeoDegenerateLatitudeZone.java:24). Geo3DPoint.newBoxQuery: "@return query matching points within this box" (Geo3DPoint.java:142). GeoArea: CONTAINS is "The referenced shape CONTAINS this area" (GeoArea.java:34-35), to be returned when "this GeoArea is entirely within the shape" (GeoArea.java:47-49).
• The class contradicts itself. Its center/edge point, "A point on the world that's also on the zone" (GeoDegenerateLatitudeZone.java:38-39), fails its own isWithin on WGS84 and CLARKE_1866 at every tested latitude except the equator (it passes only there and within less than 1e-7 rad of ±35.2 degrees); its isWithin disagrees with its own plane-based intersects and bounds.
• Siblings. GeoWideDegenerateHorizontalLine, GeoDegenerateHorizontalLine, GeoDegenerateVerticalLine and GeoDegenerateLongitudeSlice all test their plane with plane.evaluateIsZero at 1e-12; the degenerate point compares coordinates at the same 1e-12; the literal 1e-10 occurs only here, with no comment.
• History points to an oversight. The line was written for the sphere-only first version of geo3d (April 2015, replacing an exact z == sinLatitude). The WGS84 change five weeks later (LUCENE-6487) moved this class's plane, center point, expand and intersects to the planet model and left isWithin.
• Precedents. Upstream fixed the analogous precision problem in the sibling GeoDegeneratePoint.isWithin as a bug (LUCENE-7967, #9016) and fixed degenerate-latitude box failures as bugs (LUCENE-10508 / #11544 in 9.2.0, LUCENE-10673 / #11708 in 9.4.0).
• Not an approximation. The search errors are 5 to 35 degrees against the prefix tree's 2.25-degree grid approximation for this query, and the same line over [-179, 179] matches nothing.
• Tests. No upstream test names the class. TestGeoBBox.testBBoxDegenerate builds one on the sphere (TestGeoBBox.java:38-46) but asserts through the polygon's isWithin, and passes with the fix; TestGeo3DPoint's random box test uses shape.isWithin as its own oracle, so it cannot see this.

The strongest case for "intended" (built by the intended-behaviour checker; cross-model reviews rated it weak, and the cross-model fact check of this doc rated it moderate, mainly for compatibility): GeoDegenerateLatitudeZone is package-private and @lucene.internal, and the public APIs that reach it are @lucene.experimental; the 1e-10 could be deliberate leniency for a shape with no area, and on the sphere it does let a zero-height Geo3DPoint box match the points of its latitude more often; a zero-height box is arguably ill-posed; prefix trees are approximate by design; the code is eleven years old and unreported; and the fix changes relationships, hits and the cells indexed for such shapes.

Why it fails: the public factory returns this class for any legal full-width box with equal latitudes, and @lucene.experimental permits API change, not wrong answers; no comment, javadoc or commit message explains the 1e-10; the leniency exists only for the full-width class and, apart from the equator and ±35.2 degrees, only on the sphere (the narrower box never had it); the zone's own intersects uses 1e-12, which is what produces the forbidden CONTAINS; the WGS84 rejection is a self-contradiction (the zone rejects its own center), not a tolerance choice; upstream has repeatedly fixed degenerate-box precision errors as bugs; and the false search matches are 5 to 35 degrees away against a 2.25-degree grid approximation, with the [-179, 179] control returning none.

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

Replace the body of GeoDegenerateLatitudeZone.isWithin (:88-91) with plane.evaluateIsZero(x, y, z). The plane's normal is (0, 0, 1), so this is |z + D| < 1e-12 with D from the planet model: the same z test, against the right z, at the resolution that the zone's intersects and every sibling use. It removes both symptoms: on WGS84 the points on the latitude are inside, and at latitude 0.4 on the sphere, WGS84 and CLARKE_1866 the gap probe gives DISJOINT for every gap of 1.5e-12 or more and the correct OVERLAPS for touching rectangles (near a pole a 1.5e-12 rad gap is less than 1e-12 in z, so DISJOINT starts at a wider gap there).

--- a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoDegenerateLatitudeZone.java
+++ b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoDegenerateLatitudeZone.java
@@ -87,7 +87,7 @@ class GeoDegenerateLatitudeZone extends GeoBaseBBox {
 
   @Override
   public boolean isWithin(final double x, final double y, final double z) {
-    return Math.abs(z - this.sinLatitude) < 1e-10;
+    return plane.evaluateIsZero(x, y, z);
   }

Trade-offs

• Tighter tolerance: points 1e-12 to 1e-10 off the plane are no longer accepted, which is what the narrower [-179, 179] line already does, so the two become consistent.
• Geo3DPoint results change: a full-width, zero-height Geo3DPoint.newBoxQuery then matches exactly what the narrower box matches. On WGS84 it gains the points of its latitude where they decode onto the plane (4 of 400 sampled latitudes, 0 before); on the sphere it loses the points of its latitude that decode 1e-12 to 1e-10 off the plane (matched at 162 of 400 sampled latitudes before, none after, like the narrower box). Matching such points reliably would need a tolerance tied to the encoding step for every box class, a separate change.
• Index change for prefix-tree shapes: no file format or API change, but an indexed zero-height, full-width line in a Geo3D prefix-tree field is no longer stored as covering whole cells (in the follow-up probe one such document matched 324 of 1,296 probe searches before the fix and 0 after). Existing indexes keep the old cells until those documents are reindexed; query-side results change as soon as the fixed code runs.
• The protected sinLatitude field stays; it is no longer read after construction.
• With the PR: add the two tests (or a case in TestGeoBBox plus one in TestGeo3dRpt) and a CHANGES entry under Bug Fixes.

What the checks validated

• Stock main a9779ef3c193 (gradle, seed DEADBEEF): the repro fails 3 of 3 with assertions on and off; the closest suites pass: TestGeoBBox (11 tests), TestGeo3DPoint (17, 2 skipped) and the other org.apache.lucene.spatial.spatial4j.* classes (21 tests, 4 skipped).
• With the fix: the repro passes 3 of 3 with assertions on and off; the same closest suites pass; all of :lucene:spatial3d:test (20 classes, 183 tests, 0 failures, 3 skipped) and all of :lucene:spatial-extras:test (27 classes, 118 tests, 0 failures, 5 skipped), both with the repro classes added, pass; ecjLintMain, ecjLintTest and checkGoogleJavaFormat pass for spatial3d, ecjLintTest and checkGoogleJavaFormat for spatial-extras; fix.diff applies cleanly to a clean tree.
• With the fix shadowed onto the main jars: the repro 3 of 3, the hunt's JUnits 3 of 3, the independent reproducer's 5 of 5 and the security probe's reach test pass; as a back-port, the version-adapted checks pass on 5.2.0 and 5.3.0.
• In the hunt: the spatial3d suite (181 tests, 0 failures) and the spatial-extras suite (117 tests, the same result as without the fix) on ea57360912ed.

Compare z with the plane's z (-plane.D) but keep the 1e-10 tolerance.

Trade-offs

Removes the WGS84 rejection but keeps the 1e-10 vs 1e-12 mismatch, so the false CONTAINS and the prefix-tree false matches stay, and move to just below the line on every planet model; it would also keep the sphere's partial Geo3DPoint leniency and extend it to the ellipsoids (from reading the code; not run).

Decide nesting from more than one sampled point per shape.

Trade-offs

That is the general nesting question of the separate tangent-shapes finding (LFV-378, an internal id; public context in #8990 / LUCENE-7941), a larger and riskier change; this case does not need it, because with option A touching rectangles already give OVERLAPS and separated ones DISJOINT.

GeoBBoxFactory could throw for such boxes or document them as unsupported. Workaround until a fix ships: narrow the longitude range by more than pi x 1e-12 rad at an end (for example to [-PI + 1e-9, PI - 1e-9]), which selects GeoWideDegenerateHorizontalLine (it contains (0.5, 1.0) on WGS84 and gives DISJOINT for the sphere rectangle); a narrowing of 3.1e-12 rad still selects the zone.

Trade-offs

Changes the public factory's contract for legal input, while the one-line fix already makes the class consistent with its siblings; the workaround leaves a 2e-9 rad sliver at the antimeridian.

Method: bounded-exhaustive translation validation on the stock jar (semi-formal tier), in a hunt unit on the geo3d bounding-box and solid families.

• One mode built every box of a 10,117-box lattice (zero-height, zero-width, wider than PI, polar and dateline-crossing boxes) on SPHERE and WGS84 through GeoBBoxFactory.makeGeoBBox and compared isWithin with the geometric box definition at about 1.1e8 lattice and edge points plus 124,762 points constructed on degenerate boxes. Its only robust membership violations were GeoDegenerateLatitudeZone on WGS84: 510 on-latitude points rejected.
• A second mode, run on separate build machines, checked 33.6 million area x shape relationship pairs and found 360 sphere pairs in which the zone built from latitudes 0.4 + 2e-12 and 0.4 was reported to CONTAIN rectangles and zones whose top latitude is 0.4.
• The cause was then read off the code, confirmed by a one-line fix that removes both, and turned into public-API JUnits on the stock main jars.
• Found 2026-10-26 on main a9779ef3c193; then checked by an independent reproducer, an intended-behaviour devil's advocate, reviews by a model from another family (OpenAI GPT-5.6, reading only), an adjudication, a history, prior-report and security follow-up, and a credibility audit.