-
Notifications
You must be signed in to change notification settings - Fork 20
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
Intersection Bug #8
Comments
Thanks for the report. Unfortunately I must warn that I can't promise when I'll be able to investigate it, as it's purely a hobby project of mine, and one I haven't much personal uses for currently, so not actively pursued. That said, I'm occasionally trying to attend to it, when I find enough time and motivation. Please note I'm certainly grateful for your report, and that you cared to include the picture. I'm also updating the README now, to make it clear that the library has known bugs, unfortunately, which I haven't been able to squash easily for the time being. |
No worries, totally understand. Thanks for updating the readme and replying to the issue so promptly! |
Is the winding order correct for both polygons? I think if one clockwise and the other is counterclockwise, or they are both winding in the wrong direction (although I don't remember which is the correct direction), that may cause the problem. |
I seem to believe that winding should be irrelevant for the algorithm; although as I believe I wrote elsewhere, I can't really say I 100% understand all of its details (otherwise I could probably resolve the #3, which might have a chance of resolving this one too [or not]). |
I've added a test in #10. It doesn't return an empty polygon, but it also doesn't exactly return the inner polygon as expected. |
Hey guys. Did anyone manage to get to the bottom of this ? Or perhaps have an idea for alternative solutions ? |
We ended up using https://github.com/paulsmith/gogeos instead, along with the command line tool http://www.gdal.org/ogr2ogr.html to get the files into the appropriate format. |
@carmandrew I haven't checked out the library yet but I think your polygon definitions are in clockwise order. In many libraries the points need to be CCW (i.e., the polygon vertices need to be positively oriented) |
…vel#8) Modify the snapping algorithm to: * Avoid snapping if the intersection point is equivalent to an existing endpoint. * Prefer snapping to an endpoint in the middle of the 4 endpoint candidates. * Increase the tolerance to cover more cases. This improves robustness against floating imprecision.
I'm using this library to determine which ZIP codes are within a given area. Unfortunately, it seems to be incorrectly calculating INTERSECTION some of the time. Here is an example:
For reference on a map, these polygons look like:
The intersection should be the entire inner polygon, however it returns an empty intersection.
The text was updated successfully, but these errors were encountered: