[I] RS_AsRaster rasterizes the original geometry after a CRS-aware intersection check [sedona]

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

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

   ## Problem
   
   `RS_AsRaster` can validate an intersection in one coordinate system and then rasterize the geometry in another.
   
   When the geometry and reference raster have different known CRSs, `Rasterization.rasterize` calls `RasterPredicates.rsIntersects(raster, geom)`. That predicate transforms the operands for the intersection test, but the transformed geometry is not returned to the caller. `Rasterization.rasterize` then passes the original geometry to `rasterizeGeomExtent` and `rasterizeGeometry`, which interpret its coordinates in the reference raster's coordinate space.
   
   As a result, the intersection check can succeed while rasterization burns no pixels, burns the wrong pixels, or fails while calculating a geometry-based output extent.
   
   This is independent of the missing-CRS policy discussed in #3153: it occurs when both operands have explicit, valid, but different CRSs.
   
   ## Reproducer
   
   The following regression test should pass because the two geometries describe the same polygon:
   
   ```java
   GridCoverage2D raster =
       RasterConstructors.makeEmptyRaster(1, 5, 5, 0, 5, 1, -1, 0, 0, 4326);
   
   Geometry geometry4326 =
       Constructors.geomFromWKT(
           "POLYGON ((1.2 1.2, 1.2 2.8, 2.8 2.8, 2.8 1.2, 1.2 1.2))",
           4326);
   
   Geometry geometry3857 =
       FunctionsGeoTools.transform(geometry4326, "EPSG:4326", "EPSG:3857");
   geometry3857.setSRID(3857);
   
   GridCoverage2D expected =
       RasterConstructors.asRaster(geometry4326, raster, "d", false, 7, 0d, false);
   GridCoverage2D actual =
       RasterConstructors.asRaster(geometry3857, raster, "d", false, 7, 0d, false);
   
   assertArrayEquals(
       MapAlgebra.bandAsArray(expected, 1),
       MapAlgebra.bandAsArray(actual, 1),
       0d);
   ```
   
   On the current implementation, the CRS-aware intersection succeeds, but `rasterizeGeomExtent` receives the EPSG:3857 coordinates and compares them directly with the EPSG:4326 raster extent.
   
   ## Expected behavior
   
   CRS-equivalent geometries should produce the same rasterized pixels regardless of which supported source CRS they use.
   
   ## Suggested fix
   
   Resolve/default the operand CRSs using the existing raster CRS policy, transform the geometry into the reference raster's coordinate space once, and use that transformed geometry consistently for:
   
   1. Intersection validation.
   2. Geometry extent calculation.
   3. Pixel rasterization.
   
   A regression test should compare the output from an EPSG:4326 geometry with the output from its EPSG:3857 transformation, as above.
   


-- 
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 rasterizes the original geometry after a CRS-aware intersection check [sedona]

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

jiayuasu closed issue #3216: RS_AsRaster rasterizes the original geometry after a CRS-aware intersection check
URL: https://github.com/apache/sedona/issues/3216


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