james-willis opened a new issue, #1076: URL: https://github.com/apache/sedona-db/issues/1076
The raster–vector join reprojects the raster's four corners into the geometry operand's CRS and connects them with straight chords (the convex-hull footprint). Known limitations of this cross-CRS approximation: - No edge densification. Reprojection turns straight edges into curves; a 4-corner hull under-/over-covers along them. Densifying each edge (~10 points is common, e.g. reusing the `st_segmentize` logic, with shared utilities moved to sedona-geometry) — or comparing in a geography with a meter tolerance — would be more accurate. - Frame divergence from the scalar kernel. The join compares in the geometry operand's CRS; the scalar `RS_Intersects` kernel compares in the raster's CRS. The same predicate can therefore return different rows depending on whether the spatial-join optimizer fires. Same-CRS is exact and matches. - Antimeridian over-coverage. A raster whose reprojected extent crosses ±180° yields a chord through longitude 0 and a globe-spanning bounding box, causing spurious matches on the far side. (Non-finite reprojected corners are handled defensively in the join so they yield no match rather than garbage.) This tracks the SedonaDB side. The Sedona (Spark) side: <PAIR_URL>. -- 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]
