RS_AsRaster segment clipping drops crossings and loses grid-line sidedness

[jiayuasu]

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:

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:

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

• Line rasterization uses fixed-step sampling instead of exact cell traversal, dropping boundary pixels (allTouched and LINESTRING) #3118 replaced fixed-step sampling with exact cell traversal, but did not change segment clipping.
• allTouched/line rasterization can burn a corner-touched pixel at grid-aligned vertices (differs from GDAL by one pixel) #3120 and [GH-3120] Fix rasterization at grid-aligned endpoints #3251 address endpoint-cell selection after coordinates are already in pixel space; [GH-3120] Fix rasterization at grid-aligned endpoints #3251 deliberately leaves clipping unchanged.

Settings

• Sedona version: PR [GH-3120] Fix rasterization at grid-aligned endpoints #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.

[jiayuasu]

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.

[minhpham1810]

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?

[jiayuasu]

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.

[minhpham1810]

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