[I] Spatial join planner: index ST_Intersects / ST_Contains on Box3D inputs [sedona]

["jiayuasu (via GitHub)" <gi...@apache.org>]

jiayuasu opened a new issue, #3031:
URL: https://github.com/apache/sedona/issues/3031

   Follow-up to the Box3D Phase 1 epic ([#2973](https://github.com/apache/sedona/issues/2973)) and PR [#3028](https://github.com/apache/sedona/pull/3028).
   
   Today, `ST_Intersects` / `ST_Contains` over two Box3D columns are explicitly short-circuited in `JoinQueryDetector` (`hasBox3DInput` returns true → planning returns `None`), so the join falls back to row-by-row evaluation — O(n × m) cross product with the scalar predicate. This issue wires Box3D-on-Box3D joins into the indexed path.
   
   ## Approach
   
   Reuse the existing 2D R-tree partitioner / index pipeline by projecting each Box3D to its XY footprint, and re-evaluate the Z axis per candidate via the original predicate carried as an extra condition. No new index type, no new partitioner.
   
   Concretely:
   
   1. **`JoinQueryDetector`** — replace the two Box3D `None` short-circuits with `JoinQueryDetection` constructions analogous to the Box2D arms:
      - `SpatialPredicate.INTERSECTS` for the 2D R-tree pass on both `ST_Intersects` and `ST_Contains` over Box3D (the R-tree filter cares about XY containment relations only when X/Y is *enough*; for Box3D the predicate has to recheck regardless).
      - Fold the original `ST_Intersects` / `ST_Contains` expression back into `extraCondition` (ANDed with any existing post-filter) so the executor's per-pair refine in `TraitJoinQueryExec.scala:137-142` re-checks all three axes via the scalar Box3D predicate.
   2. **`TraitJoinQueryBase.shapeToGeometry`** — add a `Box3DUDT` case that materialises the XY footprint as a JTS rectangle (`Constructors.polygonFromEnvelope(xmin, ymin, xmax, ymax)`). Validates ordered bounds on all three axes (`xmin <= xmax`, `ymin <= ymax`, `zmin <= zmax`) so inverted-bound input throws the same `IllegalArgumentException` raised by `Predicates.box3dIntersects` / `box3dContains`.
   3. **Tests** — Box3D-on-Box3D join with mixed Z overlap to confirm: (a) candidate set is the XY-footprint filtering, (b) final output correctly excludes pairs that overlap in XY but not Z, (c) broadcast index join, range join, and broadcast hint pathways all work, (d) inverted-bound Z bounds throw rather than silently mis-prune.
   
   ## Cost note
   
   Per-candidate refine cost is six double reads + six comparisons + two `Box3D` allocations — the Box3D `UserDefinedType.deserialize` is six `getDouble` calls on an `InternalRow`. Carrying the parsed Box3D in `userData` (the `GeographyJoinShape` precedent) was considered but skipped: Geography needs that because S2 deserialise is expensive; Box3D doesn't.
   
   ## Out of scope
   
   - Box3D ↔ Box3D distance join (`ST_3DDWithin` is not yet planner-wired — separate follow-up; same XY-projection trick will apply).
   - True 3D R-tree (deferred until a workload demands tighter pruning on Z).


-- 
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: issues-unsubscribe@sedona.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Spatial join planner: index ST_Intersects / ST_Contains on Box3D inputs [sedona]

["jiayuasu (via GitHub)" <gi...@apache.org>]

jiayuasu closed issue #3031: Spatial join planner: index ST_Intersects / ST_Contains on Box3D inputs
URL: https://github.com/apache/sedona/issues/3031


-- 
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: issues-unsubscribe@sedona.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org