Add ST_Relate implementation using GEOS#691
Conversation
petern48
left a comment
There was a problem hiding this comment.
I know you're still working on this, but I figured I'd leave a bit of hints to help guide you along the way.
There was a problem hiding this comment.
It looks like you've deleted many files in the submodules, presumably accidentally. This is causing CI failures. Could you revert these deletions?
Don't be afraid to ask if you need help with figuring out how to undo this.
There was a problem hiding this comment.
let me see... and will surely get back if some help is needed
|
|
||
| executor.finish(Arc::new(builder.finish())) | ||
| } | ||
| } |
There was a problem hiding this comment.
In addition to the actual rust implementation. We're going to need to add Rust tests in this file as well as python integration tests. You can take a look at this example PR (#288) to guide you if you'd like.
There was a problem hiding this comment.
oki, let me check
There was a problem hiding this comment.
We are still missing rust and python tests. Both of these are very important to have before we merge. The example PR has examples of these as well.
The rust tests should exist in this file, starting with:
#[cfg(test)]
mod tests {The new python tests for st_relate should go in test_predicates.py (since st_relate is a predicate). Make sure to read my comment (#288 (comment)) about how to iterate on developing Python integration tests
There was a problem hiding this comment.
Thanks for the guidance! I’ll add the Rust tests in the module using #[cfg(test)] mod tests {} and implement the Python tests for st_relate in test_predicates.py, following the approach in #288.
6e098db to
760ac4c
Compare
43722df to
c6623a4
Compare
718eb17 to
cedfd67
Compare
5dad3ab to
5136544
Compare
357366b to
c5f171e
Compare
5fc9681 to
9646893
Compare
c867b56 to
40d256e
Compare
1a330ef to
4b467fc
Compare
be0152e to
156993f
Compare
|
Thanks for the suggestions! I have reverted the submodule changes and aligned the implementation with the structure used in PR #288 as recommended. All CI checks are now passing and the PR should be ready for review/merge. |
| crate::st_xyzm::st_y_udf, | ||
| crate::st_xyzm::st_z_udf, | ||
| crate::st_zmflag::st_zmflag_udf, | ||
| crate::st_relate::st_relate_udf, |
There was a problem hiding this comment.
nit: let's place this in alphabetical order too
|
|
||
| executor.finish(Arc::new(builder.finish())) | ||
| } | ||
| } |
There was a problem hiding this comment.
We are still missing rust and python tests. Both of these are very important to have before we merge. The example PR has examples of these as well.
The rust tests should exist in this file, starting with:
#[cfg(test)]
mod tests {The new python tests for st_relate should go in test_predicates.py (since st_relate is a predicate). Make sure to read my comment (#288 (comment)) about how to iterate on developing Python integration tests
bd9f15e to
64359d7
Compare
7f4b79d to
e178a68
Compare
|
I noticed your recent commits fixing formatting. I strongly suggest you set up the I also updated the example PR to explicitly call this out, since I guess it's easy for people to not read through the entire contributing guide linked. |
| f"SELECT ST_Overlaps({geom_or_null(geom1)}, {geom_or_null(geom2)})", | ||
| f"SELECT ST_Relate({geom_or_null(geom1)}, {geom_or_null(geom2)})", |
There was a problem hiding this comment.
Please don't delete existing tests. There should be no red diffs (deletions) in this file.
(sorry i know it's in draft, but I figured I'd call this out since I'm here anyways)
There was a problem hiding this comment.
No issues at all, thank you for highlighting..
|
Also you can ignore the |
|
I’ve ensured that all 13 predicate functions are now present in |
petern48
left a comment
There was a problem hiding this comment.
this is looking great! we're nearing there
| # These cases demonstrates the weirdness of ST_Contains: | ||
| # Both POINT(0 0) and GEOMETRYCOLLECTION (POINT (0 0)) contains POINT (0 0), | ||
| # but GEOMETRYCOLLECTION (POINT (0 0), LINESTRING (0 0, 1 1)) does not contain POINT (0 0). | ||
| # See https://lin-ear-th-inking.blogspot.com/2007/06/subtleties-of-ogc-covers-spatial.html |
There was a problem hiding this comment.
let's not delete this comment either.
| "POLYGON ((0 0, 2 0, 2 2, 0 2, 0 0))", | ||
| "POLYGON ((1 1, 3 1, 3 3, 1 3, 1 1))", | ||
| "212101212", | ||
| ), |
There was a problem hiding this comment.
I'd like to add some more edge cases. (We are usually more comprehensive for the Python tests, since they are very concise to write)
Could we add the following test cases? (These are just the inputs, you need to add the expected output values. I find the easiest way is to just run the tests, and copy-paste the outputs that come out. If both our sedonaDB implementation and PostGIS agree, we're good!)
If you come up with any other interesting edge cases, you're welcome to add them too.
("POINT (0 0)", "LINESTRING (0 0, 1 1)")
("LINESTRING (0 0, 2 2)", "LINESTRING (1 1, 3 3)")
("GEOMETRYCOLLECTION (POINT (0 0), LINESTRING (0 0,1 1))", "POINT (0 0)")
(
"POLYGON ((0 0, 2 0, 2 2, 0 2, 0 0))",
"POLYGON ((2 0, 4 0, 4 2, 2 2, 2 0))"
) # touching polygons
(
"POLYGON ((0 0, 4 0, 4 4, 0 4, 0 0))",
"POLYGON ((1 1, 2 1, 2 2, 1 2, 1 1))"
) # polygon containment
(
"POLYGON ((0 0,6 0,6 6,0 6,0 0),(2 2,4 2,4 4,2 4,2 2))",
"POINT (1 1)"
) # point in a polygon hole
There was a problem hiding this comment.
Thanks for the suggestion! I’ll add these edge cases to the Python tests and determine the expected outputs by comparing SedonaDB and PostGIS results.
Co-authored-by: Peter Nguyen <petern0408@gmail.com>
This PR implements the
ST_Relatefunction using the GEOSrelateoperation to compute the DE-9IM (Dimensionally Extended 9-Intersection Model) relationship between two geometries. The implementation integrates with the existing GEOS execution framework in Sedona and returns the resulting DE-9IM intersection matrix as a UTF-8 text string. The changes include adding the GEOS kernel implementation insedona-geos,creating the corresponding scalar UDF wrapper insedona-functions,and registering the function so it can be used through the SQL interface. This enables users to evaluate spatial relationships between geometries and obtain the DE-9IM matrix representation directly. This work addresses issue #539 and is part of the broader implementation tracked in #174.