|
From: | John Swensen |
Subject: | Re: GSoC '16 - Boolean Operations on Polygons : Merge Code to geometry Package |
Date: | Mon, 15 Aug 2016 08:47:53 -0700 |
Sorry, that is probably my fault. I guess I had missed this bug/patch. We had gone and looked at the splitPolygon and joinPolygon in the geometry package repository, but I don’t recall why we didn’t just repurpose those. We had discussed the usage of clipper vs Boost.Polygon vs Boost.Geometry vs one other library at the outset. We had seen an implementation of the polybool using Clipper, but there was some discussion about whether converting to 64 bit integer, performing the boolean operations, then converting back to floating point numbers was the correct approach. We had decided to us Boost.Geometry instead because of its ability to use float/double as the core representation, has emerging support for correcting self-intersections, and it very actively being maintained by a community of GIS professionals. Maybe we should have gotten permission/blessing from you guys as maintainers before heading in that direction full-force. poly2tri is a library I have used with great success in the past for doing triangulations of polygons with holes. I had seen that one of you was working on the polycut function, but because the poly2tri library has been around for so long, seems to have the majority of kinks and corner cases worked out, and it involved including a relatively small number of source files as a dependency, that it would be an ideal solution to implementing the poly2fv function. Sometimes I like to re-invent the wheel because I learn a lot about what is really going on under the hood, and other times I just want to use an algorithm that I know works well. This was one of those latter cases. I don’t think Amr has checked it into his repository yet, but one of the really great things he accomplished was to take all of the polygon tests from http://www.angusj.com/delphi/clipper.php and implement them to run in both Matlab and Octave. This allows us to compare performance between both Matlab and Octave, other non-Octave implementation, and the alternative Octave implementations that were in this Patch #9000. I apologize if we duplicated work unnecessarily. That was not our intent. I think Amr has done a pretty good job and any shortcomings are really my fault for not keeping tabs with you two better. John S. |
[Prev in Thread] | Current Thread | [Next in Thread] |