paleolimbot commented on issue #3153: URL: https://github.com/apache/sedona/issues/3153#issuecomment-5166459852
The CRS comparison issue seems orthogonal to the implicit treating of a None CRS as lon/lat. Lon/Lat is not a likely CRS for a raster and so this will usually be masking an error. For vector, it is functionally difficult to get a column with a None CRS (when it's missing this is usually an error in internal CRS propagation). This behaviour is probably never used intentionally (and if it is, it is trivially fixable with a ST_SetSRID). CRS comparison in a join is indeed a problem. Probably the best solution here is to validate that all geometries on the build side have the same CRS, which can be done on the way in when building the join (this is also an issue for Sedona's regular spatial join, not limited to RS_Intersects). SedonaDB doesn't support joins for item level CRS yet, so probably our best solution is to force the build side to be the geometry, where we can prove identical CRS at planning time (or where it's more likely all items have the same CRS). For RS_Intersects, you could also force the index to be constructed in lon/lat space, since that is the spirit of the comparison. Or if we want to keep existing behaviour, make a new function RS_DWithin (this would let a user set some tolerance to account for any error due to reprojection). -- 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]
