feat: Implement ST_Relate using `geos`

[petern48]

Implement ST_Relate: https://postgis.net/docs/ST_Relate.html

text ST_Relate(geometry geomA, geometry geomB);

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

text ST_Relate(geometry geomA, geometry geomB, integer boundaryNodeRule);

[petern48]

@Mehak3010, answering your questions from this comment: #174 (comment) here to pull out the conversation to a separate issue.

geos has a convenient relate() method we can use. Hopefully, implementing this will be as simple as calling that.
https://github.com/georust/geos/blob/f7566bdef3052201e71052756ebb73c6c9e03056/src/geometry.rs#L533-L538

1. Which geometry combinations should be supported in the initial version (e.g., Point–Polygon, Polygon–Polygon)?

Generally, we aim to support all combinations of all different types, or at least match what PostGIS supports. I'm optimistic this will happen automatically if we use geos's relate() method I mentioned above.

2. Should the function return a full DE-9IM relation matrix string, or do you prefer a simplified/partial implementation for v1?

So there's three different function headers that PostGIS ST_Relate() supports according to the docs:

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

text ST_Relate(geometry geomA, geometry geomB);

text ST_Relate(geometry geomA, geometry geomB, integer boundaryNodeRule);

I think any individual PR should add full support for a function header. It's okay to implement just one of these three (in fact, I'd personally prefer that) in the PR, but it should be fully (not partially) support all cases for that function (e.g. point-polygon, polygon-polygon, etc). The other versions of ST_Relate could be implemented as separate PRs.

3. Are there existing geometry kernels or utilities in SedonaDB that you recommend reusing for this logic?

I wrote a fairly in-depth PR in the past to guide a contributor to implementing a ST_ function using a geos method. Check it out: #288

4. Any preferences around performance optimizations or test coverage for this function?

Don't worry about perf optimizations. Check out a previous geos PR (e.g. the one I put above) for an example of test coverage. We need them both at the rust and python level.

[Mehak3010]

@petern48 Thanks for the detailed explanation and for creating the separate issue — that helps a lot.

Before starting any implementation, I just wanted to align on the version to begin with. My current thought is to start with the simplest variant, ST_Relate(geometry, geometry) → text, and leave the other overloads for later.

Since you’ve looked into this already, I’d really appreciate your advice on whether this sounds like the right place to start, or if you’d recommend a different variant for the first pass.

Not jumping into a PR yet — just want to make sure the direction makes sense first. Thanks!

[petern48]

My current thought is to start with the simplest variant, ST_Relate(geometry, geometry) → text, and leave the other overloads for later.

Yes, that sounds good to me! The relate() function in the geos library matches that variant (they both take two geoms as input two and return a string), so I think it should be as simple as calling it. This would be a good first variant to start with. Feel free to go ahead and work on it.

fn relate<G: Geom>(&self, other: &G) -> GResult<String> {

ST_Relate(geometry, geometry) → text

[Mehak3010]

@petern48 Following up on our earlier discussion — now that the first ST_Relate implementation is merged, would you like me to proceed with the remaining two variants, or is the current implementation enough for now?

[petern48]

Sure! You're more than welcome to implement additional variants as well! In general, we're interested in implementing all variants that PostGIS provides. I'd suggest doing one variant per PR.

In case it's helpful, here's an example PR (#241) that added an additional variant to the st_buffer function. The PR is likely more complex than what ST_Relate will look like (so don't worry too much about the nitty details), but you can see how to implement an additional kernel with a different set of argument types and register it for an existing function.

[Mehak3010]

@petern48 I’ve raised a separate PR (#741) for the boolean variant of ST_Relate. Would appreciate your review!

[Mehak3010]

I’m planning to work on the third variant of ST_Relate:
ST_Relate(geometry, geometry, integer boundaryNodeRule).

Before proceeding further, I wanted to check if there are any preferred approaches or considerations for implementing this, especially since boundary node rule support doesn’t seem to be directly exposed in the current GEOS Rust bindings.

Happy to explore lower-level bindings if needed, @petern48 would appreciate any suggestions!

[Mehak3010]

@petern48 I explored the third variant of ST_Relate with the boundaryNodeRule parameter.

From what I can see, the current GEOS Rust bindings only expose relate and relate_pattern, and I wasn’t able to find support for a boundary node rule variant. Implementing this would likely require going through lower-level GEOS FFI with manual context and memory handling.

Before proceeding further, I wanted to check if this variant is expected to be implemented at this stage, or if we should consider it out of scope for now.

Happy to explore the FFI approach if that’s the intended direction — would appreciate your suggestion!

[petern48]

I'd say the ideal solution is to add a new method upstream in the geos-rust repo, and then use that in sedona-db. That's definitely more friction. It not only involves implementing the code and tests for the geos-rust bindings, but also waiting for their reviewers to respond to your PR, and possibly waiting for a release, etc. Also note, this is likely the least commonly used variant (I'm definitely not familiar with it, for example)

I'd say if you're just looking for ways to contribute (rather than needing this particular function personally), I'd recommend picking other functions from the umbrella issue: #174 since I'm sure there will be more functions with less friction.

Though if you feel strongly about it. You can give it a shot! I would just caution that it's less likely to land as quickly as other methods.

[Mehak3010]

Got it, that makes sense — thanks for the guidance!

I’ll skip the boundaryNodeRule variant for now and focus on other functions from #174 that are more straightforward to implement.