petern48 opened a new issue, #481: URL: https://github.com/apache/sedona-db/issues/481
Yes, I think you're right. I found my exact conditional logic was allowing `XYM` cases to slip to the `ST_Equals()` assert to bypass the M dimension check, hence why the tests were passing. Seems like a breaking change is necessary to fix the API, considering the [dims argument is an int](https://github.com/georust/geos/blob/47afbad2483e489911ddb456417808340e9342c3/src/coord_seq.rs#L522). I also see that the `CoordSeq::new()` is buggy too, [it's implementation](https://github.com/georust/geos/blob/47afbad2483e489911ddb456417808340e9342c3/src/coord_seq.rs#L63-L65) uses the legacy `GEOSCoordSeq_create_r` function. Looking at a [git blame](https://github.com/libgeos/geos/blame/158c588566e08fd2f31f8c9e7ae069518e8264c5/capi/geos_c.h.in#L501-L511) at these lines in geos, I see `GEOSCoordSeq_create_r` is 18 years old and it takes a simple `int dims` param. while the `GEOSCoordSeq_createWithDimensions_r` function is only 9 months old, and it takes a separate `hasz` and `hasm` param, as desired. Would also need some breaking fixes to multiple enums in [enums.rs](https://github.com/georust/geos/blob/47afbad2483e489911ddb456417808340e9342c3/src/enums.rs#L6). Looks like none of geos-rust supports XYM and a lot of breaking changes would need to be made 😬 _Originally posted by @petern48 in https://github.com/apache/sedona-db/pull/476#discussion_r2658753239_ -- 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]
