paleolimbot commented on PR #1108: URL: https://github.com/apache/sedona-db/pull/1108#issuecomment-5173275172
> I think the round trip example is contrived and I'm not worried about it. How about this one: `SELECT ST_Intersects(some_col, ST_Transform(other_col, ST_SRID(some_col)) FROM foofy`. I think it's pretty reasonable somebody might want to align the sides of an ST_Intersects call (particularly when dealing with item-level CRSes). > Maybe ST_SetSRID or ST_Intersects should be the one that rejects null CRS/SRID instead. Maybe, although there is precedent for our current behaviour (Sedona and PostGIS accept and propagate nulls with SQL semantics). > I'm imagining users who want to filter on the presence of a CRS with a SRID, so they can get rid of SRID-less rows (CRSes with no SRID) On the day we're asked for that feature we can always add a function (maybe `ST_TrySRID()`, or `TRY(ST_SRID())` if we support Try before that, or more directly `ST_HasSRID()`). I am not sure we'll be asked for that feature but I can see wanting to find problematic rows when dealing with systems that can't register CRS <-> SRID mappings. If we print out the start of the offending CRS in the error it could be filtered by value. -- 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]
