jiayuasu opened a new pull request, #3194:
URL: https://github.com/apache/sedona/pull/3194

   Closes #3153.
   
   ## What changed
   
   - Compare raster predicate operands directly when neither side has a CRS.
   - Throw a stable error when exactly one operand has a CRS instead of 
assuming WGS84.
   - Preserve the existing direct-comparison and transformation behavior when 
both operands have a CRS.
   - Make range and broadcast raster joins defer CRS-presence validation to 
scalar refinement so coarse index pruning cannot hide the error.
   - Keep `RS_DWithin` CRS behavior unchanged.
   - Update predicate documentation and add raster-geometry and raster-raster 
regression coverage.
   
   ## Why
   
   Raster inputs read from GeoParquet now carry CRS metadata. Treating a 
missing CRS on the other operand as WGS84 can silently compare incompatible 
coordinates. Requiring both operands to either define a CRS or omit it makes 
the behavior explicit and consistent.
   
   ## User impact
   
   `RS_Intersects`, `RS_Contains`, and `RS_Within` now report:
   
   ```text
   Raster predicates require both operands to have a CRS or neither operand to 
have a CRS
   ```
   
   when exactly one operand has a CRS. Calls where neither operand has a CRS 
continue to work by comparing their coordinates directly.
   
   ## Validation
   
   - `mvn -pl common -Dtest=RasterPredicatesTest test` — 30 tests passed
   - `mvn -pl spark/common -Dscala=2.12 -Dspark=3.4 -DskipTests test-compile`
   - `mvn -o -pl spark/common -Dscala=2.12 -Dspark=3.4 
-Dsuites=org.apache.spark.sql.sedona_sql.strategy.join.JoinedGeometryRasterTest,org.apache.sedona.sql.RasterJoinSuite
 scalatest:test` — 65 tests passed
   


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