jiayuasu opened a new pull request, #3251: URL: https://github.com/apache/sedona/pull/3251
## Did you read the Contributor Guide? - Yes, I have read the [Contributor Rules](https://sedona.apache.org/latest/community/rule/) and [Contributor Development Guide](https://sedona.apache.org/latest/community/develop/) ## Is this PR related to a ticket? - Yes, and the PR name follows the format `[GH-XXX] my subject`. Closes #3120 ## What changes were proposed in this PR? Line rasterization (`LINESTRING` geometries and polygon boundaries under `allTouched = true`) derived a segment's start and end cells with `floor()`, which assigns an endpoint lying exactly on a grid line to the half-open cell on its positive side even when the segment does not extend into that cell. Two symptoms: 1. **The reported one-pixel difference (#3120):** a pixel the geometry touches only at a single vertex point was burned, where GDAL (`rasterio.features.rasterize(all_touched=True)`) omits it. 2. **A runaway traversal (found while reproducing):** when a segment ends exactly on a lattice corner, the floor()-derived end cell sits diagonally off the traversal's path, so the termination check never fires and the walk burns an anti-diagonal streak of unrelated pixels across the raster until the step bound stops it. Two existing test expectations were silently asserting these streak artifacts. The fix biases the endpoint cells by the direction of travel: a coordinate exactly on a grid line resolves to the cell the segment actually occupies. Axes with no extent keep the half-open `floor()` convention, so segments lying exactly along a grid line burn the same cells as before (and as GDAL). This matches GDAL exactly at grid-line endpoints and keeps the traversal direction-independent. The one remaining divergence is a segment passing exactly through a lattice corner: GDAL burns one extra off-diagonal cell chosen by its slope-dependent internal x-major/y-major scan (and is internally inconsistent about it, as noted in #3120), while Sedona burns exactly the two cells the segment passes through. Updated test expectations, each cross-checked against rasterio 1.5.0: - `RasterConstructorsTest.testAsRasterWithRaster` (the actual #3120 repro: the polygon's vertex `(1.5, 1.5)` sits on a pixel corner of the 0.25-degree `test5.tiff` grid) — now matches GDAL except the corner cell GDAL burns through its scan-order quirk. - `RasterConstructorsTest.testAsRasterWithEmptyRaster` (polygon vertex on a row boundary) and the MultiPolygon case (diamond apexes on pixel corners, previously asserting streak artifacts) — both now match GDAL exactly. - `FunctionEditorsTest` polyline/geometry-collection cases (vertices on corners; one endpoint-on-column-boundary cell) — corner-point and streak cells removed. - `rasteralgebraTest`: the same polyline on a 5x5 grid, and the `RS_ZonalStats` all-touched count on `test5.tiff` (every polygon vertex is a multiple of the pixel size) drops 14667 → 14655, still direction-independent. ## How was this patch tested? - New unit tests in `RasterizationTests`: endpoint on a grid line (both directions), segment ending on a lattice corner (streak regression, both directions), V-apex on a corner, segments along grid lines, and the #3120 polygon — expectations hardcoded from rasterio output. - New cases in `python/tests/sql/test_rasterize_parity.py` comparing directly against `rasterio.features.rasterize` for grid-aligned vertices and corner apexes; the existing 100-case randomized parity fuzz is unaffected (general-position input never hits the degeneracy). - Full `common` suite, the `rasteralgebraTest` Scala suite (Spark 3.5 / Scala 2.12), and the rasterize parity pytest suite (Spark 3.4 shaded jar) all pass locally. ## Did this PR include necessary documentation updates? - Yes, I have updated the documentation. (`RS_AsRaster.md`: clarified what "touched" means for `allTouched` at single-point contacts.) -- 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]
