-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Fix issue in rhumb arc polylines #8787
Conversation
Thanks for the pull request @dennisadams!
Reviewers, don't forget to make sure that:
|
Thanks again for your contribution @dennisadams! No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy? I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with |
Thanks for the PR @dennisadams. I won't have time to review this before the June release on Monday, but I'll be sure to review this for the July release. |
Thanks @hpinkos! |
Thanks for this fix @dennisadams! And thanks for your detailed explanation of the root cause in #8464. That made this really easy to review. I just added a unit test, and I'll merge this as soon as CI passes |
Fixes #8464 .
See my comment over there explaining the issue and the solution.
The issue is actually in all rhumb-arc polylines. This should crush your sancastle with a
normalized result is not a number
error:As I wrote in that comment, I think a better solution would be to compute the number of points for each segment only once and pass it over to
generateCartesianRhumbArc
. However, I was a bit hesitant to make such a change, because that would break the similarity togenerateCartesianArc
.Ideally, I think both
generateCartesianArc
andgenerateCartesianRhumbArc
can do with some refactoring, for your consideration.