james-willis opened a new issue, #3323: URL: https://github.com/apache/sedona/issues/3323
When a raster predicate must compare across CRSs, the raster's footprint appears to be reprojected using its corner vertices only. Reprojection bends straight footprint edges into curves, so the corner-to-corner chords under-cover the true extent — dramatically so for polar rasters, where the chords miss most of the cap. Repro: a 20x20 EPSG:3413 raster with extent (-1e6, -1e6, 1e6, 1e6) (a 2000 km square on the north pole), queried with EPSG:4326 points that transform to well inside the square: | point (4326) | in EPSG:3413 | truly inside? | RS_Intersects | |---|---|---|---| | `POINT(45 82)` | (867972, 0) | yes | **false** | | `POINT(180 85)` | (-383228, 383228) | yes | **false** | | `POINT(0 85)` | (383228, -383228) | yes | **false** | | `POINT(90 85)` | (383228, 383228) | yes | **false** (also via RS_Contains) | | `POINT(0 60)` | (2349829, -2349829) | no | false ✓ | `POINT(45 82)` sits on the +x axis at 87% of the half-width — nowhere near an edge curve subtlety — yet reads false; the four corners transform to lon/lat points near latitude 77-78, and everything poleward of their chords is lost. Densifying each footprint edge before reprojecting (a handful of interior points per edge) makes the reprojected footprint follow the curve; SedonaDB's `integration/spark-parity` suite (where this surfaced) shows its densified footprint matching the exact point-in-square truth on every probed case. Related, observed while probing: `RS_Within(polar_raster, pole-spanning 4326 polygon)` throws rather than answering — the pole/antimeridian degeneracy in flat lon/lat space. -- 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]
