Copilot commented on code in PR #2863:
URL: https://github.com/apache/sedona/pull/2863#discussion_r3144476452
##########
common/src/main/java/org/apache/sedona/common/utils/S2Utils.java:
##########
@@ -107,13 +107,252 @@ public static Polygon toJTSPolygon(S2CellId cellId) {
return new GeometryFactory().createPolygon(coords);
}
+ /**
+ * Convert a JTS planar geometry into an S2Region whose lat/lng projection
is guaranteed to
+ * contain the input geometry.
+ *
+ * <p>Why a buffer is needed: Sedona geometries are planar — an edge between
two vertices is a
+ * straight line in (lng, lat) space — but S2 connects the same vertices
with a great-circle arc
+ * on the sphere. The two interpretations agree at the vertices but diverge
along the edges (e.g.
+ * the great-circle arc between two points at the same northern latitude
bulges northward, leaving
+ * the parallel that would form the planar chord). If we hand the JTS
vertices to S2 directly, the
+ * spherical polygon's interior is *smaller* than the planar polygon's
interior along
+ * non-meridional edges, so the S2 covering misses thin slivers of the
original planar polygon
+ * (see GH-2857).
+ *
+ * <p>To compensate, we JTS-buffer the input by an upper bound on the
worst-case great-circle
+ * deviation before converting to S2. A side effect for {@link LineString}
inputs is that the
+ * buffer turns the line into a polygon corridor; downstream callers
therefore see cells in a thin
+ * strip around the line rather than only cells the line geometrically
traverses.
+ */
public static S2Region toS2Region(Geometry geom) throws
IllegalArgumentException {
+ if (!(geom instanceof Polygon) && !(geom instanceof LineString)) {
+ throw new IllegalArgumentException(
+ "only Polygon or LineString (including LinearRing) types can be
converted to S2Region");
+ }
+ // JTS planar buffer doesn't understand antimeridian crossing — for inputs
that
+ // straddle the antimeridian, buffering produces a polygon that goes the
wrong way
+ // around the globe and explodes the S2 covering. Detect antimeridian
crossing
+ // per-edge (any edge with |Δlng| > 180° must wrap) rather than via the
envelope:
+ // the envelope-width heuristic also fires for wide non-straddling
polygons (e.g.
+ // a polygon spanning -100° to +100°), which would incorrectly skip the
buffer and
+ // reintroduce the GH-2857 miscoverage along their long non-meridional
edges.
Review Comment:
The comment here says the per-edge antimeridian check avoids false positives
for wide non-straddling polygons like one spanning -100° to +100°, but the
current predicate (`|Δlng| > 180°` on any edge) will still return true for a
direct edge from -100° to +100° (|Δlng|=200). Either tighten the detection to
only treat *actual* dateline-straddling edges as antimeridian-crossing (or
require longitudes to be normalized and document that), or update this
comment/example so it matches the behavior.
```suggestion
// using the current per-edge longitude-jump test in
crossesAntimeridian(geom),
// rather than an envelope-width heuristic: envelope width alone can
misclassify
// broad geometries as antimeridian-spanning and incorrectly skip the
buffer,
// reintroducing the GH-2857 miscoverage along long non-meridional edges.
```
##########
common/src/test/java/org/apache/sedona/common/FunctionsTest.java:
##########
@@ -1081,6 +1081,181 @@ public void testS2ToGeom() {
assertTrue(polygons[100].intersects(target));
}
+ @Test
+ public void testS2CoverageContainsInput() throws ParseException {
+ String wkt =
+ "POLYGON ((-102.060778 39.9999603, -102.0535384 40.0119065, -101.98532
40.0122906, "
+ + "-95.30829 40.009008, -95.2456364 39.9564784, -95.1982467
39.9455019, "
+ + "-95.1964657 39.9113444, -95.1460439 39.9142017, -95.1316877
39.8855881, "
+ + "-95.087643 39.8717975, -95.0389987 39.8749063, -95.0146232
39.9088422, "
+ + "-94.9403146 39.906409, -94.9183761 39.8846514, -94.9329504
39.8578468, "
+ + "-94.8824331 39.8409102, -94.8675709 39.8227528, -94.878404
39.787242, "
+ + "-94.9266292 39.7786779, -94.9070076 39.7679231, -94.8631596
39.779774, "
+ + "-94.8497103 39.7604914, -94.8545514 39.7397163, -94.8985678
39.7150641, "
+ + "-94.9584897 39.7331377, -94.9637588 39.6814526, -95.0187723
39.6615712, "
+ + "-95.0456083 39.6252182, -95.0430365 39.5826542, -95.0650104
39.5677387, "
+ + "-95.0985514 39.570063, -95.1012286 39.5462821, -95.0459187
39.5064755, "
+ + "-95.0320969 39.4709074, -94.976457 39.4475392, -94.9362514
39.3964717, "
+ + "-94.8781205 39.3949417, -94.8733156 39.3663291, -94.9014695
39.3495654, "
+ + "-94.8963639 39.3135051, -94.8237994 39.2609956, -94.8194328
39.2178517, "
+ + "-94.7789019 39.214907, -94.7398645 39.1789812, -94.6785238
39.1931279, "
+ + "-94.6533801 39.1816662, -94.6517728 39.1640754, -94.605515
39.1696807, "
+ + "-94.5791896 39.1504025, -94.5983384 39.1134256, -94.6095667
36.9948123, "
+ + "-102.045765 36.9847897, -102.060778 39.9999603))";
+ Geometry input = geomFromWKT(wkt, 0);
+ Long[] cellIds = Functions.s2CellIDs(input, 12);
+ Geometry[] polygons =
+
Functions.s2ToGeom(Arrays.stream(cellIds).mapToLong(Long::longValue).toArray());
+ Geometry coverage = Functions.union(polygons);
+ if (!coverage.covers(input)) {
+ // The union above is unavoidable for an exact containment check; we
additionally
+ // skip the (expensive, ~50k-cell) difference on the happy path and only
compute it
+ // on failure to surface a useful diagnostic.
+ Geometry uncovered = input.difference(coverage);
+ double uncoveredArea = uncovered.getArea();
+ fail(
+ String.format(
+ "Coverage does not contain input. Missing %.8f deg^2 (%.6f%%)",
+ uncoveredArea, (uncoveredArea / input.getArea()) * 100.0));
+ }
+ }
+
+ @Test
+ public void testS2CoverageContainsLineString() throws ParseException {
+ // Long east-west line at mid-latitude. The great-circle arc bulges
poleward of the JTS
+ // chord, so before the buffer fix the cells along the parallel were
missed in the middle.
+ Geometry line = geomFromWKT("LINESTRING (-102 37, -94 37)", 0);
+ Long[] cellIds = Functions.s2CellIDs(line, 12);
+ Geometry[] cells =
+
Functions.s2ToGeom(Arrays.stream(cellIds).mapToLong(Long::longValue).toArray());
+ Geometry coverage = Functions.union(cells);
+ assertTrue(
+ "S2 cell coverage of LineString does not contain the line itself.",
coverage.covers(line));
+ }
+
+ @Test
+ public void testS2CoverageContainsMultiPolygon() throws ParseException {
+ // Two disjoint polygons, both at mid-northern latitude with long
east-west edges.
+ String wkt =
+ "MULTIPOLYGON ("
+ + "((-102 37, -94 37, -94 40, -102 40, -102 37)),"
+ + "((-90 50, -80 50, -80 53, -90 53, -90 50)))";
+ Geometry input = geomFromWKT(wkt, 0);
+ Long[] cellIds = Functions.s2CellIDs(input, 10);
+ Geometry[] cells =
+
Functions.s2ToGeom(Arrays.stream(cellIds).mapToLong(Long::longValue).toArray());
+ Geometry coverage = Functions.union(cells);
+ assertTrue(
+ "S2 cell coverage does not contain every member of the MultiPolygon.",
+ coverage.covers(input));
+ }
+
+ @Test
+ public void testS2CoverageContainsMultiLineString() throws ParseException {
+ // Three disjoint multi-segment lines: northern hemisphere, southern
hemisphere, and a
+ // diagonal climb. Each is decomposed and buffered independently before S2
covering.
+ String wkt =
+ "MULTILINESTRING ("
+ + "(-102 37, -98 37, -94 37),"
+ + "(-90 -42, -85 -42, -80 -42),"
+ + "(-100 50, -95 55, -90 60))";
+ Geometry input = geomFromWKT(wkt, 0);
+ Long[] cellIds = Functions.s2CellIDs(input, 10);
+ Geometry[] cells =
+
Functions.s2ToGeom(Arrays.stream(cellIds).mapToLong(Long::longValue).toArray());
+ Geometry coverage = Functions.union(cells);
+ assertTrue(
+ "S2 cell coverage does not contain every member of the
MultiLineString.",
+ coverage.covers(input));
+ }
+
+ @Test
+ public void testS2CoverageContainsGeometryCollection() throws ParseException
{
+ String wkt =
+ "GEOMETRYCOLLECTION ("
+ + "POLYGON ((-102 37, -94 37, -94 40, -102 40, -102 37)),"
+ + "LINESTRING (10 60, 20 60, 30 60))";
+ Geometry input = geomFromWKT(wkt, 0);
+ Long[] cellIds = Functions.s2CellIDs(input, 10);
+ Geometry[] cells =
+
Functions.s2ToGeom(Arrays.stream(cellIds).mapToLong(Long::longValue).toArray());
+ Geometry coverage = Functions.union(cells);
+ assertTrue(
+ "S2 cell coverage does not contain every member of the
GeometryCollection.",
+ coverage.covers(input));
+ }
+
+ @Test
+ public void testS2CoverageContainsPolygonWithHole() throws ParseException {
+ // Outer ring at mid-latitude with long east-west edges; an inner hole.
Both rings need
+ // their great-circle bulge accounted for so the buffer applies to
interior rings too.
+ String wkt =
+ "POLYGON ("
+ + "(-102 37, -94 37, -94 40, -102 40, -102 37),"
+ + "(-100 38, -96 38, -96 39, -100 39, -100 38))";
+ Geometry input = geomFromWKT(wkt, 0);
+ Long[] cellIds = Functions.s2CellIDs(input, 12);
+ Geometry[] cells =
+
Functions.s2ToGeom(Arrays.stream(cellIds).mapToLong(Long::longValue).toArray());
+ Geometry coverage = Functions.union(cells);
+ assertTrue("S2 cell coverage does not contain a polygon with a hole.",
coverage.covers(input));
+ }
+
+ @Test
+ public void testS2CoverageContainsAntimeridianLine() throws ParseException {
+ // Edge crossing the antimeridian. The naive chord midpoint (a.x+b.x)/2
would land at
+ // 0° longitude — the opposite side of the planet — and produce a ~180°
bogus deviation.
+ // Verify that the buffer stays small (so we don't blow up the cell count)
and that the
+ // returned cells still cover the line.
+ Geometry line = geomFromWKT("LINESTRING (179 5, -179 5)", 0);
+ Long[] cellIds = Functions.s2CellIDs(line, 12);
+ Geometry[] cells =
+
Functions.s2ToGeom(Arrays.stream(cellIds).mapToLong(Long::longValue).toArray());
+ Geometry coverage = Functions.union(cells);
+ // Sanity check: a 2°-long edge near the equator at level 12 should not
produce
+ // millions of cells. If antimeridian chord-midpoint handling is wrong the
buffer
+ // explodes by ~180° and the cell count would be enormous.
+ assertTrue(
+ "Antimeridian-spanning line produced too many cells (chord midpoint
likely wrong): "
+ + cellIds.length,
+ cellIds.length < 5000);
+ assertTrue(
+ "S2 cell coverage of antimeridian-spanning LineString does not contain
the line.",
+ coverage.covers(line));
+ }
+
+ @Test
+ public void testS2CoverageContainsWideNonAntimeridianPolygon() throws
ParseException {
+ // Polygon spanning >180° in longitude but NOT crossing the antimeridian
(every edge has
+ // |Δlng| < 180°). An envelope-width-based antimeridian heuristic would
incorrectly skip
+ // the buffer here and reintroduce GH-2857 miscoverage along the long
east-west edges;
+ // the per-edge heuristic correctly leaves the buffer on.
+ String wkt = "POLYGON ((-100 30, 100 30, 100 50, -100 50, -100 30))";
Review Comment:
In this test, the WKT `POLYGON ((-100 30, 100 30, ...))` includes an edge
with |Δlng| = 200 (> 180). With the current `crossesAntimeridian`
implementation (|Δlng| > 180 per edge), this polygon will be classified as
antimeridian-crossing and the buffer will be skipped, contradicting the comment
that it is “NOT crossing the antimeridian” and that the per-edge heuristic
“leaves the buffer on”. Consider rewriting the WKT to keep the envelope width >
180 while ensuring every edge has |Δlng| < 180 (e.g., add intermediate
vertices), so the test actually exercises the intended non-antimeridian-wide
case.
```suggestion
String wkt =
"POLYGON ((-100 30, -10 30, 100 30, 100 50, 10 50, -100 50, -100
30))";
```
##########
common/src/main/java/org/apache/sedona/common/utils/S2Utils.java:
##########
@@ -107,13 +107,252 @@ public static Polygon toJTSPolygon(S2CellId cellId) {
return new GeometryFactory().createPolygon(coords);
}
+ /**
+ * Convert a JTS planar geometry into an S2Region whose lat/lng projection
is guaranteed to
+ * contain the input geometry.
+ *
+ * <p>Why a buffer is needed: Sedona geometries are planar — an edge between
two vertices is a
+ * straight line in (lng, lat) space — but S2 connects the same vertices
with a great-circle arc
+ * on the sphere. The two interpretations agree at the vertices but diverge
along the edges (e.g.
+ * the great-circle arc between two points at the same northern latitude
bulges northward, leaving
+ * the parallel that would form the planar chord). If we hand the JTS
vertices to S2 directly, the
+ * spherical polygon's interior is *smaller* than the planar polygon's
interior along
+ * non-meridional edges, so the S2 covering misses thin slivers of the
original planar polygon
+ * (see GH-2857).
+ *
+ * <p>To compensate, we JTS-buffer the input by an upper bound on the
worst-case great-circle
+ * deviation before converting to S2. A side effect for {@link LineString}
inputs is that the
+ * buffer turns the line into a polygon corridor; downstream callers
therefore see cells in a thin
+ * strip around the line rather than only cells the line geometrically
traverses.
+ */
public static S2Region toS2Region(Geometry geom) throws
IllegalArgumentException {
+ if (!(geom instanceof Polygon) && !(geom instanceof LineString)) {
+ throw new IllegalArgumentException(
+ "only Polygon or LineString (including LinearRing) types can be
converted to S2Region");
+ }
+ // JTS planar buffer doesn't understand antimeridian crossing — for inputs
that
+ // straddle the antimeridian, buffering produces a polygon that goes the
wrong way
+ // around the globe and explodes the S2 covering. Detect antimeridian
crossing
+ // per-edge (any edge with |Δlng| > 180° must wrap) rather than via the
envelope:
+ // the envelope-width heuristic also fires for wide non-straddling
polygons (e.g.
+ // a polygon spanning -100° to +100°), which would incorrectly skip the
buffer and
+ // reintroduce the GH-2857 miscoverage along their long non-meridional
edges.
+ boolean spansAntimeridian = crossesAntimeridian(geom);
+ double eps = spansAntimeridian ? 0.0 : arcChordBufferDegrees(geom);
+ Geometry buffered = (eps > 0) ? geom.buffer(eps) : geom;
+ if (buffered instanceof Polygon) {
+ return S2Utils.toS2Polygon((Polygon) buffered);
+ } else if (buffered instanceof LineString) {
+ // Only reachable when eps == 0 (e.g. a single-point degenerate line).
Normal lines
+ // become Polygon corridors after buffer and are handled above.
+ return S2Utils.toS2PolyLine((LineString) buffered);
+ } else if (buffered instanceof MultiPolygon && buffered.getNumGeometries()
> 0) {
+ // JTS buffer of self-touching geometries can collapse to MultiPolygon.
Build a single
+ // S2Polygon containing every component's loops so the resulting region
still contains
+ // every part of the buffered geometry; dropping components would
silently break the
+ // containment guarantee for the discarded shells.
+ List<S2Loop> loops = new ArrayList<>();
+ for (int i = 0; i < buffered.getNumGeometries(); i++) {
+ Polygon p = (Polygon) buffered.getGeometryN(i);
+ loops.add(toS2Loop(p.getExteriorRing()));
+ for (int j = 0; j < p.getNumInteriorRing(); j++) {
+ loops.add(toS2Loop(p.getInteriorRingN(j)));
+ }
+ }
+ return new S2Polygon(loops);
+ }
+ throw new IllegalArgumentException(
+ "only Polygon or LineString (including LinearRing) types can be
converted to S2Region");
+ }
+
+ /**
+ * Compute the JTS buffer amount (in degrees) needed so that the spherical
interpretation of the
+ * buffered geometry fully contains the original planar geometry.
+ *
+ * <p>The buffer must be at least as large as the largest great-circle/chord
deviation among the
+ * edges that S2 will eventually see. Polygons and lines need different
bounds because JTS buffer
+ * affects their edges differently:
+ *
+ * <ul>
+ * <li><b>Polygon</b>: each existing edge is offset perpendicularly in
place; corners get
+ * rounded into many short arcs, but no edge is dramatically
lengthened. The buffered
+ * polygon's edges therefore have ~the same length as the originals,
so the original
+ * polygon's per-edge deviation is a tight upper bound on what the
buffered polygon's edges
+ * will exhibit. We use {@link #ringMaxDeviationDegrees}.
+ * <li><b>LineString</b>: buffering produces a corridor whose long
top/bottom edges span the
+ * line's full envelope — far longer than any individual segment when
consecutive segments
+ * are collinear (JTS often simplifies them away). Per-segment
deviation severely
+ * under-bounds the corridor's actual edge deviation. We bound by
virtual edges across the
+ * envelope via {@link #envelopeDeviationDegrees}.
+ * </ul>
+ *
+ * <p>The 1.5× safety multiplier absorbs numerical error and the small
additional deviation the
+ * buffered polygon's own (slightly different) edges introduce on top of the
bound.
+ */
+ private static double arcChordBufferDegrees(Geometry geom) {
+ double maxDev = 0.0;
if (geom instanceof Polygon) {
- return S2Utils.toS2Polygon((Polygon) geom);
+ Polygon poly = (Polygon) geom;
+ maxDev = Math.max(maxDev,
ringMaxDeviationDegrees(poly.getExteriorRing().getCoordinates()));
+ for (int i = 0; i < poly.getNumInteriorRing(); i++) {
+ maxDev =
+ Math.max(maxDev,
ringMaxDeviationDegrees(poly.getInteriorRingN(i).getCoordinates()));
+ }
} else if (geom instanceof LineString) {
- return S2Utils.toS2PolyLine((LineString) geom);
+ maxDev = envelopeDeviationDegrees(geom);
}
- throw new IllegalArgumentException(
- "only object of Polygon, LinearRing, LineString type can be converted
to S2Region");
+ return maxDev * 1.5;
+ }
+
+ /**
+ * Conservative deviation upper bound for a geometry, derived from its
bounding envelope rather
+ * than its actual edges.
+ *
+ * <p>Used for {@link LineString} inputs because, after JTS buffer, the
corridor's long edges are
+ * not the line's segments — they connect the line's extreme endpoints (or
close to it). To bound
+ * them we probe three virtual edges across the envelope:
+ *
+ * <ul>
+ * <li>The two diagonals (SW–NE and NW–SE) — diagonal great-circle arcs
deviate more than
+ * east-west arcs of the same Δλ at high latitudes, and a buffered
corridor's long edges can
+ * run in either direction depending on the line's orientation.
+ * <li>The worst-case east-west edge at whichever latitude (top or bottom
of the envelope) has
+ * the larger absolute value — east-west arcs bulge poleward, so the
deviation grows with
+ * |latitude|, and an envelope-spanning east-west arc is what a
horizontal collinear line
+ * would buffer into.
+ * </ul>
+ *
+ * <p>The max across these three bounds the deviation any corridor edge
could plausibly exhibit.
+ * This deliberately over-bounds zigzag lines whose actual corridor edges
are short; the
+ * alternative (per-segment analysis) silently fails on collinear inputs.
+ */
+ private static double envelopeDeviationDegrees(Geometry geom) {
+ Envelope env = geom.getEnvelopeInternal();
+ if (env.isNull()) {
+ return 0.0;
+ }
+ if (crossesAntimeridian(geom)) {
+ // JTS envelopes don't understand antimeridian crossing — a line from
(179, y) to
+ // (-179, y) reports a 358°-wide envelope even though the actual edge is
2° long. The
+ // envelope-corner virtual edges would then describe a
near-globe-spanning chord and
+ // produce a meaninglessly huge deviation. For such inputs, fall back to
per-segment
+ // analysis, which works directly off the actual edges and is correct
regardless of
+ // antimeridian crossings.
+ return ringMaxDeviationDegrees(geom.getCoordinates());
+ }
+ Coordinate sw = new Coordinate(env.getMinX(), env.getMinY());
+ Coordinate se = new Coordinate(env.getMaxX(), env.getMinY());
+ Coordinate ne = new Coordinate(env.getMaxX(), env.getMaxY());
+ Coordinate nw = new Coordinate(env.getMinX(), env.getMaxY());
+ // For the east-west probe, pick whichever latitude band of the envelope
is further from
+ // the equator — that's where same-Δλ great-circle arcs deviate most from
the chord.
+ double signedLat =
+ Math.abs(env.getMinY()) > Math.abs(env.getMaxY()) ? env.getMinY() :
env.getMaxY();
+ Coordinate ewWest = new Coordinate(env.getMinX(), signedLat);
+ Coordinate ewEast = new Coordinate(env.getMaxX(), signedLat);
+ double max = edgeDeviationDegrees(sw, ne);
+ max = Math.max(max, edgeDeviationDegrees(nw, se));
+ max = Math.max(max, edgeDeviationDegrees(ewWest, ewEast));
+ return max;
+ }
+
+ /**
+ * Detect whether {@code geom} crosses the antimeridian by walking its edges
and checking whether
+ * any has an absolute longitudinal delta greater than 180°. An edge from
(179°, y) to (-179°, y)
+ * is 2° long going across the antimeridian but 358° in raw lng deltas, so
|Δlng| > 180° is a
+ * reliable per-edge antimeridian indicator. Using the actual edges (not the
envelope width)
+ * avoids false positives for wide non-straddling polygons like one spanning
-100° to +100°.
+ */
+ private static boolean crossesAntimeridian(Geometry geom) {
+ if (geom instanceof Polygon) {
+ Polygon poly = (Polygon) geom;
+ if (ringCrossesAntimeridian(poly.getExteriorRing().getCoordinates())) {
+ return true;
+ }
+ for (int i = 0; i < poly.getNumInteriorRing(); i++) {
+ if
(ringCrossesAntimeridian(poly.getInteriorRingN(i).getCoordinates())) {
+ return true;
+ }
+ }
+ return false;
+ } else if (geom instanceof LineString) {
+ return ringCrossesAntimeridian(geom.getCoordinates());
+ }
+ return false;
+ }
+
+ private static boolean ringCrossesAntimeridian(Coordinate[] coords) {
+ for (int i = 0; i < coords.length - 1; i++) {
+ if (Math.abs(coords[i + 1].x - coords[i].x) > 180.0) {
+ return true;
+ }
+ }
+ return false;
+ }
+
+ /**
+ * Per-edge deviation bound for a ring/path: walk consecutive vertex pairs
and return the largest
+ * single-edge great-circle/chord deviation. Used for polygon rings
(exterior and interior), where
+ * buffering preserves edge lengths and per-edge analysis is tight.
+ */
+ private static double ringMaxDeviationDegrees(Coordinate[] coords) {
+ double maxDev = 0.0;
+ for (int i = 0; i < coords.length - 1; i++) {
+ double dev = edgeDeviationDegrees(coords[i], coords[i + 1]);
+ if (dev > maxDev) {
+ maxDev = dev;
+ }
+ }
+ return maxDev;
+ }
+
+ /**
+ * Primitive deviation for a single edge: the (lng, lat) distance between
the planar chord
+ * midpoint and the great-circle arc midpoint.
+ *
+ * <p>Why the midpoint: a great-circle arc between two points is symmetric
about its midpoint, and
+ * the (lng, lat) deviation from the chord is maximized there. So the
midpoint deviation equals
+ * the maximum deviation along the edge — there's no need to sample multiple
points.
+ *
+ * <p>The great-circle midpoint is computed by averaging the two endpoint
S2Points (unit vectors
+ * on the sphere) and renormalizing — a standard spherical-midpoint trick.
The chord midpoint is
+ * the plain Euclidean mean of the (lng, lat) coordinates.
Review Comment:
The Javadoc says the chord midpoint is the plain Euclidean mean of (lng,
lat), but the implementation intentionally wraps the longitude delta into
[-180, 180] before averaging to handle antimeridian-spanning edges. Please
update the comment to reflect the wrapped-longitude midpoint logic so readers
don’t assume it’s a simple `(a.x + b.x)/2`.
```suggestion
* computed in (lng, lat) space by averaging latitude directly and
averaging longitude using the
* wrapped delta in [-180, 180] so antimeridian-spanning edges use the
shorter longitudinal span
* rather than a naive {@code (a.x + b.x) / 2}.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
