[I] RS_AsRaster segment clipping drops crossings and loses grid-line sidedness [sedona]

["jiayuasu (via GitHub)" <gi...@apache.org>]

jiayuasu opened a new issue, #3255:
URL: https://github.com/apache/sedona/issues/3255

   ## Expected behavior
   
   LineString segments, and polygon-boundary segments when `allTouched = true`, should be rasterized whenever their intersection with the raster window has positive length, regardless of whether either original endpoint is inside the window. Reversing a segment should produce the same band.
   
   Segments that are disjoint from the window, or that only touch it at one corner point, should burn no cells. A segment clipped to a window edge should retain the exact side of nearby internal pixel grid lines.
   
   ## Actual behavior
   
   `Rasterization.clipSegmentToRasterBounds` returns `null` whenever both endpoints are outside the raster extent. This drops valid segments that cross the raster from one side to another.
   
   The current one-endpoint clipping path also stores an interpolated endpoint as ordinary `double` coordinates. If the unconstrained coordinate rounds onto an internal grid line, rasterization can select the wrong adjacent cell even though the segment remains strictly on one side of that line inside the raster.
   
   ## Steps to reproduce
   
   On a 6 x 6 north-up unit raster, this horizontal line crosses all six columns but both endpoints are outside:
   
   ```sql
   SELECT RS_BandAsArray(
     RS_AsRaster(
       ST_GeomFromWKT('LINESTRING (-1 2.5, 7 2.5)'),
       RS_MakeEmptyRaster(1, 'B', 6, 6, 0.0, 6.0, 1.0, -1.0, 0.0, 0.0, 0),
       'B', true, 1.0, 0.0, false),
     1);
   ```
   
   Expected: all six cells in zero-based row 3 are `1`.
   
   Actual: every cell is `0`.
   
   A secondary clipping case demonstrates loss of endpoint sidedness:
   
   ```sql
   SELECT RS_BandAsArray(
     RS_AsRaster(
       ST_GeomFromWKT('LINESTRING (-1 3.0000000000000004, 1 3.0)'),
       RS_MakeEmptyRaster(1, 'B', 6, 6, 0.0, 6.0, 1.0, -1.0, 0.0, 0.0, 0),
       'B', true, 1.0, 0.0, false),
     1);
   ```
   
   Within the raster, the nondegenerate part of this line is strictly above `y = 3`, except at its final endpoint. It should therefore burn `(row 2, column 0)`. The clipped coordinate rounds to `y = 3`, and Sedona instead burns `(row 3, column 0)`. Reversing the input must preserve the correct result.
   
   ## Root cause
   
   The clipper has three related numerical/topological limitations:
   
   1. It treats "both endpoints outside" as equivalent to "no intersection."
   2. It returns only rounded coordinates, losing whether an interpolated coordinate is exactly on, just below, or just above an internal grid line.
   3. Once both-outside crossings are admitted, direct differences such as `x2 - x1` can overflow for valid finite endpoints such as `-1e308` and `1e308`.
   
   ## Acceptance criteria
   
   - A nondegenerate segment with a positive-length window intersection is rasterized even when both source endpoints are outside.
   - Disjoint and parallel-outside segments burn nothing.
   - Corner-only tangencies burn nothing; boundary-coincident positive-length segments retain the established half-open side.
   - Clipped endpoints preserve the side of internal grid lines, including exact, `Math.nextDown`, and `Math.nextUp` cases on both axes.
   - Forward and reversed segments produce identical bands.
   - An originally degenerate in-bounds LineString is distinguished from a nondegenerate segment collapsed to a tangent point by clipping.
   - Clipping valid finite endpoints does not produce NaN-driven omissions or traversal streaks. Include horizontal and vertical `+/-1e308` crossings, or explicitly validate and document a smaller supported coordinate range.
   - Tests use an independent exact-rational segment/window oracle. The oracle must not exclude intersections near grid lines.
   - The replacement adds no arbitrary-precision or per-segment helper allocations on the ordinary finite-coordinate path; any exact fallback is limited to unresolved or overflow-prone cases.
   
   ## Related work
   
   - #3118 replaced fixed-step sampling with exact cell traversal, but did not change segment clipping.
   - #3120 and #3251 address endpoint-cell selection after coordinates are already in pixel space; #3251 deliberately leaves clipping unchanged.
   
   ## Settings
   
   - Sedona version: PR #3251 head `72d9cc26541` / `2.0.0-SNAPSHOT` (the both-outside crossing omission also reproduces on current `master`)
   - API type: SQL and Java
   - JRE: 17
   - Environment: local development checkout
   
   I searched open and closed issues and did not find a duplicate.
   


-- 
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: issues-unsubscribe@sedona.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] RS_AsRaster segment clipping drops crossings and loses grid-line sidedness [sedona]

["jiayuasu (via GitHub)" <gi...@apache.org>]

jiayuasu commented on issue #3255:
URL: https://github.com/apache/sedona/issues/3255#issuecomment-5286793993

   Related numerical-policy follow-up: #3256. That issue should build on this clipper work so synthetic clipped endpoints can carry explicit boundary/side provenance instead of being reclassified from rounded coordinates.
   


-- 
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: issues-unsubscribe@sedona.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] RS_AsRaster segment clipping drops crossings and loses grid-line sidedness [sedona]

["jiayuasu (via GitHub)" <gi...@apache.org>]

jiayuasu commented on issue #3255:
URL: https://github.com/apache/sedona/issues/3255#issuecomment-5488887251

   Thanks. First of all, I think this is a pretty hard and impactful ticket and might not be good for new contributors. I think you should work on other unresolved tickets.
   
   But if you insist, carrying side provenance is the right direction, and I don’t want to narrow this to only removing the early return.
   The existing parametric code handles the simple crossing, but deleting that return is not sufficient: parallel-outside axes need explicit rejection.
   
   Please plan to support all finite endpoints, including ±1e308. The clip result should carry per-endpoint, per-axis side provenance through endpoint-cell selection and effective traversal direction. 
   
   Just a heads up, given the complexity of this ticket, even if you create a PR, I might not accept it or might need to take over and refactor it.


-- 
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: issues-unsubscribe@sedona.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] RS_AsRaster segment clipping drops crossings and loses grid-line sidedness [sedona]

["minhpham1810 (via GitHub)" <gi...@apache.org>]

minhpham1810 commented on issue #3255:
URL: https://github.com/apache/sedona/issues/3255#issuecomment-5471583173

   I'd like to work on this issue. Two of the three causes look like straightforward fixes: the null short-circuit when both endpoints are outside should just be removed (the parametric clip below it already handles crossings fine), and the dx = x2 - x1 overflow for extreme coordinates needs a guard. About the third one, recovering which side of an internal grid line a clipped/interpolated endpoint really falls on, I think means having the clipper return that side info directly (e.g. via an orientation predicate) instead of rounding to a double and losing it, but that changes the return type so wanted your take first.
   
   Questions: does carrying side provenance through the clip result sound right, or keep this narrower? Do we need real ±1e308 support or is a documented smaller coordinate range fine? And for degenerate-vs-clipped-to-a-point LineStrings, explicit flag or filter before clipping?


-- 
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: issues-unsubscribe@sedona.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] RS_AsRaster segment clipping drops crossings and loses grid-line sidedness [sedona]

["minhpham1810 (via GitHub)" <gi...@apache.org>]

minhpham1810 commented on issue #3255:
URL: https://github.com/apache/sedona/issues/3255#issuecomment-5496625750

   @jiayuasu sure thing, I can redirect to other issues while slowly getting to know this one. Thanks for the heads up.


-- 
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: issues-unsubscribe@sedona.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org