james-willis opened a new issue, #1235: URL: https://github.com/apache/sedona-db/issues/1235
`RS_RasterToWorldCoord`/`X`/`Y` and `RS_WorldToRasterCoord`/`X`/`Y` treat pixel coordinates as **0-based**, while Sedona Spark (following PostGIS) is **1-based**. Every result is exactly one pixel off, including extrapolation outside the grid. On the standard parity grid (origin (100, 500), 2x3 pixels): | query | SedonaDB | Sedona Spark | |---|---|---| | `RS_RasterToWorldCoordX(rast, 1, 1)` | 102 | 100 | | `RS_RasterToWorldCoordY(rast, 1, 1)` | 497 | 500 | | `RS_WorldToRasterCoordX(rast, 100, 500)` | 0 | 1 | | `RS_WorldToRasterCoordY(rast, 100, 500)` | 0 | 1 | | `RS_WorldToRasterCoordX(rast, 90, 505)` | -5 | -4 | Meanwhile `RS_PixelAsPoint`/`Centroid`/`Polygon` are **1-based in both engines** (`RS_PixelAsPoint(rast, 1, 1)` → `POINT (100 500)` on both) — so SedonaDB is also internally inconsistent between its coordinate mappers and its pixel-geometry functions. Neither kernel documents a basis choice (`rs_rastercoordinate.rs`, `rs_worldcoordinate.rs`). Surfaced by the `integration/spark-parity` suite; the coordinate-mapper modules xfail-catalog this divergence referencing this issue. Proposal: align the mappers to 1-based (Spark/PostGIS convention, and consistent with `RS_PixelAs*`), or document 0-basing loudly if it is deliberate. -- 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]
