huan233usc opened a new pull request, #17174:
URL: https://github.com/apache/iceberg/pull/17174
> [!IMPORTANT]
> Draft / proof-of-concept. Standalone off `main` (does not depend on the
geometry
> bounding-box work). Not intended to merge as-is — it computes a box
in-test to
> demonstrate the approach and validate the consumer side.
## Why
A `geography` bounding box cannot be the planar min/max of the WKB vertices,
for two
reasons:
1. **Latitude** — an edge is a great-circle arc, which can reach a higher
latitude than
either endpoint (it bulges poleward). A vertex-only box can therefore
*fail to
contain* the geography.
2. **Longitude** — longitude is periodic, so the tight covering box for data
near the
date line crosses the antimeridian: its western bound is numerically
**greater** than
its eastern bound (the spec's wraparound convention, "match if x ≥ xmin
OR x ≤ xmax").
This PoC shows a minimal spherical bounding-box kernel that handles both,
and that the
resulting box prunes files correctly through the existing (already-merged)
`GeospatialPredicateEvaluators`, which understands wraparound boxes.
## What it shows
`TestGeographyBoundsSkippingPoc`:
- **Latitude bulge:** an edge from `(0°, 60°N)` to `(90°, 60°N)` yields a
box whose top is
**≈67.79°N** (via the great-circle vertex test), not the 60°N a planar
fold would give —
so the box actually covers the arc.
- **Antimeridian wraparound → skipping:** a geography near the date line
(longitudes 170°
and −170°) yields a covering longitude interval `xmin=170 > xmax=−170` (a
20° band across
±180). Through
`GeospatialPredicateEvaluators.create(GEOGRAPHY).intersects(...)`:
- a query near the date line (`179°..180°`) → **kept** (correctly
overlaps);
- a query on the prime meridian (`0°..10°`) → **skipped**.
A naive planar box `[−170, 170]` would be a 340° band that could not skip
the prime-
meridian query.
## What is still missing for production (not in this PoC)
1. A geography bbox **producer** in the Parquet metrics writer (this PoC
computes the box
in-test).
2. A **spatial predicate** in the `Expression` API to carry a query window —
today
`SparkV2Filters` and the `Expression.Operation` enum have no spatial op,
and geo types
have no `Comparator`, so no filter can bind to a geo column.
3. Wiring the bbox intersection into `InclusiveMetricsEvaluator` /
`ManifestReader` for
automatic file pruning.
Opening as a draft to anchor the geography-bounds design (spherical latitude
+ antimeridian
longitude) and the pruning-side discussion.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
