feat: add ST_Relate(geometry, geometry, text) boolean variant

[Mehak3010]

Adds the boolean overload of ST_Relate:

boolean ST_Relate(geometry geomA, geometry geomB, text intersectionMatrixPattern)

This allows checking if two geometries satisfy a given DE-9IM pattern, complementing the existing text-returning variant.

• Uses GEOS relate_pattern
• Includes tests for pattern matching and null handling
  This work addresses issue feat: Implement ST_Relate using geos #539 and is part of the broader implementation tracked in ossue epic: st function coverage #174 .

[Mehak3010]

@petern48 CI checks are all passing now. The PR #174 is ready for review — let me know if any changes are needed.

[petern48]

Looks like a good start. There are still a few things missing:

• Add Python integration tests. You can start by using the same test cases as the Python tests added by your previous st_relate PR (except inverted) + including some cases that evaluate to False.

• Update the docs (docs/reference/sql/st_relate.qmd) with this new syntax. You can take a look at st_buffer.qmd for an example of how to write docs for a function with multiple kernels.

• Minor nit. Could you link the issue in your PR description? You can just put something like "part of #ISSUE."

At a quick skim, things look good so far. I'll take a more thorough look once these are in place.

[Mehak3010]

@petern48 Thanks for the feedback! I’ve added the Python integration tests (including false cases), updated the docs with the new syntax, and linked the issue in the PR description.
All CI checks are passing now — ready for further review.

[petern48]

Looking great. I have a bit more feedback about testing, but I think this should be ready afterwards.

[Mehak3010]

@petern48 Added the suggested cases — included point-in-polygon-hole, linestring, and geometry collection cases, along with additional False cases for better coverage.
Let me know if anything else should be added!

[petern48]

Looks like I made a small mistake in my previous suggestion which led to those test failures. Let's bring those test cases back, but I explained how to get them to pass.

[Mehak3010]

@petern48 Thanks for the clarification! I’ve reverted the NULL handling change (now passing actual NULL), re-added the removed test case, and kept all suggested edge cases. Everything should now align with the expected behavior — ready for review.

[petern48]

See #741 (comment)

[Mehak3010]

Thanks for the detailed review and helpful suggestions! I’ve addressed all the changes across tests, docs, and implementation.

[petern48]

Thanks!

[paleolimbot]

Thanks @petern48 and @Mehak3010!

[Mehak3010]

Thanks @petern48, really appreciate the support and guidance throughout!

Also, building on this work, I’m exploring a proposal around extending boolean spatial predicates and improving API consistency in Sedona. Would love to hear any suggestions or directions if you have in mind. @paleolimbot, @petern48

[petern48]

I’m exploring a proposal around extending boolean spatial predicates and improving API consistency in Sedona.

Sorry, I don't quite follow. Do you mean adding new predicates or improving existing ones? From the knowledge, I don't know of any further improvements we could make to existing boolean predicates (they already follow proper API consistency). I also don't know of any more predicates to newly introduce.

[Mehak3010]

Thanks for the clarification!

I’ll take a closer look and try to identify concrete examples (if any) where behavior could be improved or made more consistent across SQL and Python.

If everything is already aligned as expected, I’ll focus on understanding the current design better and look into other areas where boolean predicate usability or coverage could be extended.