Skip to content
This repository has been archived by the owner on Apr 2, 2022. It is now read-only.

Add test for Intersects predicate #5

Merged
merged 2 commits into from
Mar 4, 2021
Merged

Conversation

rmanoka
Copy link
Contributor

@rmanoka rmanoka commented Mar 2, 2021

Requires changes to wkt; I'm currently using a fork with the changes (support for POINT EMPTY, and LINEARRING). There are a few test cases where the geometry seems to be in some sort of a base64 format. Not sure how we should parse that.

All the parsed tests pass for hull, centroid, and intersects.

@rmanoka rmanoka requested a review from michaelkirk March 2, 2021 06:08
Copy link
Member

@michaelkirk michaelkirk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a few test cases where the geometry seems to be in some sort of a base64 format

Maybe WKB?

Requires changes to wkt; I'm currently using a fork with the changes (support for POINT EMPTY, and LINEARRING).

I saw the PR for POINT EMPTY do you plan to make one for the LINNEARRING support as well? I'm anticipating incorporating jts-test-runner into the geo test suite pretty soon, and feel a little strange about having the geo test suite rely on a forked version of the WKT dep.

src/input.rs Outdated
pub cases: Vec<Case>,
}

#[derive(Debug, Deserialize)]
pub(crate) struct Case {
#[serde(default)]
pub(crate) desc: String,
// `a` seems to always be a WKT geometry, but until we can handle `POINT EMPTY` this
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment can go away now

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a few tests that don't have a desc for some reason! Didn't want them to fail at parsing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I misread your comment (on the comment). Will remove it.

@michaelkirk
Copy link
Member

Nice work on this! I just want to understand your plan for WKT, but otherwise LGTM!

@rmanoka
Copy link
Contributor Author

rmanoka commented Mar 2, 2021

Maybe WKB?

Yeah, that was my guess too. There seems to be a rust-wkb crate, but what's confusing is there seems to be no flag that explains that the input is to be read as wkb. Let's address it in a future PR.

I saw the PR for POINT EMPTY do you plan to make one for the LINNEARRING support as well? I'm anticipating incorporating jts-test-runner into the geo test suite pretty soon, and feel a little strange about having the geo test suite rely on a forked version of the WKT dep.

Yeah, the fork has some minimal support for rings, but wanted to discuss the issue further in the wkt repo before creating a PR. I do want to eventually move to using the standard repo. My priority was to support more traits in the tests, and then add the finishing touches.

@michaelkirk
Copy link
Member

Yeah, that was my guess too. There seems to be a rust-wkb crate, but what's confusing is there seems to be no flag that explains that the input is to be read as wkb. Let's address it in a future PR.

Yeah, totally happy to iterate on this.

Yeah, the fork has some minimal support for rings, but wanted to discuss the issue further in the wkt repo before creating a PR. I do want to eventually move to using the standard repo. My priority was to support more traits in the tests, and then add the finishing touches.

In case you hadn't already noticed, I'm attempting to incorporate an earlier rev of this crate into geo as part of georust/geo#629, so if we merge this PR which requires a forked WKT, until that WKT fork gets upstreamed/released, we won't be able to update the jts-test-runner rev of geo.

That's fine with me for now - especially since this seems to be coming along pretty quickly, I just wanted to make sure we're on the same page.

@michaelkirk
Copy link
Member

Yeah, that was my guess too. There seems to be a rust-wkb crate, but what's confusing is there seems to be no flag that explains that the input is to be read as wkb. Let's address it in a future PR.

https://github.com/georust/geozero also has support for WKB. Even though I've used and contributed a couple times to that crate, I confess I don't completely grok it yet - it's sort of it's own universe, but seems very powerful.

@rmanoka
Copy link
Contributor Author

rmanoka commented Mar 2, 2021

In case you hadn't already noticed, I'm attempting to incorporate an earlier rev of this crate into geo as part of georust/geo#629, so if we merge this PR which requires a forked WKT, until that WKT fork gets upstreamed/released, we won't be able to update the jts-test-runner rev of geo.

I'm totally okay with anyway you choose to bring these eventually into geo CI. Just wanted to test the current geo::Intersects implementation before trying out Bentley-Ottman ideas on it.

https://github.com/georust/geozero also has support for WKB. Even though I've used and contributed a couple times to that crate, I confess I don't completely grok it yet - it's sort of it's own universe, but seems very powerful.

Nice! geozero is indeed quite powerful in that it's zero-copy!

@michaelkirk michaelkirk merged commit 49b0d5e into master Mar 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants