Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GeoSpatial geoWithin query including the north pole in its results #6849

Closed
takameyer opened this issue Aug 1, 2023 · 3 comments
Closed
Assignees

Comments

@takameyer
Copy link
Contributor

Expected results

When running our GeoSpatial tests the north pole point (0.01, 89.9) is included in our results set, even when it is outside of the described container.

Actual Results

The north pole point should not be included in the results.

Steps & Code to Reproduce

The following realm query:

location geoWithin geoBox([-90.23, -80.25], [85.24, 88.0]) SORT(id ASC)

ran on a realm containing the north pole point:

[0.01, 89.9]

will return the north pole point in it's results, which it shouldn't

Core version

Core version: ?

@kiburtse
Copy link
Contributor

kiburtse commented Aug 1, 2023

Interesting case... We do convert the box into the polygon every time but without additional conditions. So for resulting geoPolygon([-90.23, -80.25], [-90.23, 88.0], [85.24, 88.0], [85.24, -80.25], [85.24, 88.0]) interior should be on the left side of edges - in this case including this point [0.01, 89.9] because it's on the left side of the edge [[-90.23, 88.0], [85.24, 88.0]]? This assumed that it follows geodesic from -90.23 to 0 to 85.24. Not sure if this is expected. Weird part that every combination of coordinates for example box ([-90.23, -80.25], [85.24, 88.0]): ([85.24, 88.0], [-90.23, -80.25]), ([-90.23, 88.0], [85.24, -80.25]), ([85.24, -80.25], [-90.23, 88.0]) lead to the same internal representation of a S2Loop after normalization. So, for example, points like [0.01, 89.9], [-50, -25], [50, 25] are always in the result of a query on such boxes.

We also do try to check mongodb results to properly match the behaviour. Although, not extensively so. Should verify what server will return for this case. @takameyer have you tried the same type of query in mongodb?

@takameyer
Copy link
Contributor Author

@kiburtse honestly, I have no experience with this feature and just tried to do a core upgrade an noticed that the tests failed. With a small amount of logging I found out this result. I would have to do a some ramping up to really get into this. As far as I am concerned, if this is an expected result, or a result so on the edge that we can pragmatically live with it, then I would just tweak the tests for this to past and write a note.

@kiburtse kiburtse self-assigned this Aug 2, 2023
@kiburtse
Copy link
Contributor

kiburtse commented Aug 2, 2023

So yeah, this works as designed. MongoDB returns the same results, so remote query does the same thing. Actually, even results are expected. Just for reference: all 4 possible GeoBox combinations will produce the same polygon, because in the end these are the same points. It's just that the direction of the loop in resulting polygon will be either clock-wise or ccw. But mentioned normalization will invert the order to always produce smaller polygon. That's just simpler from user's perspective to not care about how to construct the box. The only consequence is that you can't have a box covering more that the half of the whole surface. But it's the same with polygons. Btw, the point [0.01, 89.93], for example, will be outside in your example

@kiburtse kiburtse closed this as completed Aug 2, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 21, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants