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

loop.Normalize() not working as expected? #369

Open
paro- opened this issue Jun 28, 2024 · 7 comments
Open

loop.Normalize() not working as expected? #369

paro- opened this issue Jun 28, 2024 · 7 comments

Comments

@paro-
Copy link

paro- commented Jun 28, 2024

Hi,

I've got this loop that I'm not sure Normalize() works as expected on (sorry, it's huge).

At the end of the snippet there are instructions to build the loop and with the questions.
The script was run by building a recent s2geometry (0.11.0) and pip installing it.

Note that with the simple pip install s2geometry (0.9.0) it works as expected (areas are equal).

loop

Thank you for your time,
Best regards,
Paul

@smcallis
Copy link
Collaborator

I'm not sure who maintains the pip build of S2 (it's not us). You'll likely have to ask there :(

@paro-
Copy link
Author

paro- commented Jul 1, 2024

Even regardless of the diff between the pip build (0.9.0) and github (0.11.1), do you confirm that github results are as expected?
Is it normal to find an area diff between a loop and its reverse when they're both normalized?
For the record I'm running this on hundreds of loops and the diff only rarely shows.
And this is actually why I'm computing the reverse loops in the first place, it's because I can't trust Normalize() to yield loops that are all on the same orientation, so I compute loop & reverse loop and select the one with the smallest area, but it's slow...
Good day,
Paul

@smcallis
Copy link
Collaborator

smcallis commented Jul 1, 2024

Our bindings don't even expose S2Loop so I can't test directly. If you can reproduce in C++ I can debug it though.

@paro-
Copy link
Author

paro- commented Jul 2, 2024

I found a more manageable example (with 2k vertices instead of 12k), you can slap this example in the test suite to investigate.
Thank you for your time,
Paul

@paro-
Copy link
Author

paro- commented Jul 3, 2024

FYI I git checkout a4dddf4, when the fork happened, and at that commit the test passes (the GetRectBound().Area() match, if that is indeed to be expected).

@smcallis
Copy link
Collaborator

Sorry for the delay but I dug into this further. The problem is the loop has duplicate vertices at the start and end (you don't have to close them manually). Having those duplicate vertices breaks the containment check which determines whether the loop contains S2::Origin() or not. If I remove them it seems to work fine.

If you don't know the provenance of your loops, then either running them through S2Builder to make them valid or checking with IsValid is advisable:

E0722 08:37:30.493461 2250940 s2loop.cc:168] Edge 1 is degenerate (duplicate vertex)

@paro-
Copy link
Author

paro- commented Jul 23, 2024

Ok thank you for your help, will try to use S2Builder or remove the start & end vertices.
Closing this atm, will reopen if tests don't prove successful.
Good day,
Paul

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants