james-willis opened a new pull request, #3113:
URL: https://github.com/apache/sedona/pull/3113

   ## 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 #3111
   
   ## What changes were proposed in this PR?
   
   `Rasterization.computeScanlineIntersections` computed edge x-intercepts as 
`p1X + ((p1Y - y) / slope)`, dividing a pixel-space Δy by a world-space slope. 
On square north-up pixels the missing factor `-scaleY/scaleX` equals 1 so the 
result is coincidentally correct, but on any raster whose pixels are not square 
in world units the intercepts land in the wrong place and pixels whose centers 
are inside the polygon are dropped (or near-edge pixels selected 
asymmetrically). This PR converts the pixel Δy to world units and the resulting 
world Δx back to pixels, keeping the intercept in pixel space for any pixel 
aspect ratio.
   
   ## How was this patch tested?
   
   - New `testAsRasterWithNonSquarePixels` covering the centroid rule, 
`allTouched`, a polygon with a diagonal-edged interior ring, and a bottom-up 
grid, all on 2x3-world-unit pixels. Expected matrices are produced by GDAL 
(`rasterio.features.rasterize`) on the same grids. The test was written first 
and fails on master (the dropped center-inside pixels from #3111).
   - Full `common` module suite passes (1146 tests, 0 failures): existing 
square-pixel expectations are bit-identical before and after the fix.
   - A 300-case fuzz comparing `RasterConstructors.asRaster` against 
`rasterio.features.rasterize` over random polygons on random anisotropic 
north-up and south-up grids: centroid-rule mismatches go from 187/214 cases 
before the fix to 0/214 after. (The `allTouched` boundary path, which 
rasterizes ring segments with Bresenham rather than scanlines, retains a small 
pre-existing divergence from GDAL — 24/86 fuzz cases by 1-2 boundary pixels, 
down from 32/86 — which is a separate issue.)
   
   ## Did this PR include necessary documentation updates?
   
   - No, this PR does not affect any public API so no need to change the 
documentation.
   


-- 
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]

Reply via email to