james-willis opened a new issue, #3322:
URL: https://github.com/apache/sedona/issues/3322
Probing `RS_ZonalStats` with LINESTRING rois on a 20x20 unit-pixel grid (the
GH-3118 `RasterizationTests` fixtures) against GDAL/rasterio ground truth shows
two line-specific behaviors in the rasterization path:
1. **`all_touched=true` is ignored for line geometries.** The count never
changes with the flag; cells that the segment's envelope touches but does not
cross are never included. GDAL/rasterio `all_touched=True` includes them.
| segment | default | all_touched (Sedona) | all_touched (GDAL/rasterio) |
|---|---|---|---|
| `LINESTRING (1.5 2.75, 10.5 7.25)` | 10 | 10 | 15 |
| `LINESTRING (0.75 1.25, 4.25 11.75)` | 11 | 11 | 15 |
| `LINESTRING (2.5 2.5, 9.5 9.5)` | 8 | 8 | 15 |
2. **The default (no `all_touched`) line rule burns every traversed cell.**
GDAL's default line rasterization uses the centre/diamond crossing rule, which
burns fewer: e.g. `LINESTRING (1.3 2.7, 8.6 11.4)` burns 17 cells in Sedona but
10 in GDAL/rasterio. (Corner-crossing segments mask this — their traversal and
diamond counts coincide, which is why the GH-3118 fixtures agree by default.)
Together these mean a line roi's zonal statistics differ from GDAL-based
engines in both flag positions. Surfaced by the SedonaDB↔Sedona Spark parity
suite (apache/sedona-db `integration/spark-parity`), where SedonaDB (GDAL
rasterizer) matches rasterio in all four regimes.
GH-3118's direction-independence itself holds in every probed case (forward
and reversed WKTs agree), as does the polygon path (the coastline fixture's
pinned 1738/1842 counts match exactly).
--
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]
