Re: GSoC '16 - Boolean Operations on Polygons : Merge Code to geometry Package

[Juan Pablo Carbajal]

On Mon, Aug 15, 2016 at 10:55 PM, John Swensen <address@hidden> wrote:
>
> On Aug 15, 2016, at 1:32 PM, Juan Pablo Carbajal <address@hidden>
> wrote:
>
> On Mon, Aug 15, 2016 at 8:57 PM, John Swensen <address@hidden> wrote:
>
>
> On Aug 15, 2016, at 11:31 AM, PhilipNienhuis <address@hidden> wrote:
>
> John,
>
> It wasn't my intention  to blame anyone :-)  I just made the observation
> that apparently some duplicate work has been done due to less than optimal
> communications. From my side setting insufficient priority (due to lack of
> time) is also to "blame"; probably the same goes for JuanPi. Well, that is
> how it goes with volunteer projects.
>
> However, the not-to-be-ignored upside of that is that we now have choice; we
> can select the best solutions/implementations or make a combination of the
> best ones.
>
> I agree with what you wrote about polytri - AFAICS Matlab also suggests to
> use poly2fv rather than polycut. I just "made" polycut.m because I already
> had a similar implementation lying around. Initially I didn't even know
> about the existence of polycut in TMW's mapping toolbox, I just found that
> the use of branch cuts was one way of properly drawing of (nested) polygons
> with holes and initially my sub-function for that job was called
> "optimize_branch_cuts" (it is in shapedraw.m in the mapping package).
>
> A remaining question for me is how to interpolate clipped Z-values. In my
> work I often have "3D"-planes (e.g., polygons of semi-3D tiles of geological
> strata) that I want to visualize in 3D views. I know that clipperlib can do
> it using callbacks.
> In a more general sense, unlike Matlab's mapping toolbox I'd like all
> polygon functions in the mapping package  to be able to handle semi-3D
> polygons (i.e.,polygons with different Z-values for each vertex). Most of
> what I have made already does so.
>
> OK, as far as I'm concerned to be continued later this week,
>
> Philip
>
>
>
> --
> View this message in context:
> http://octave.1599824.n4.nabble.com/GSoC-16-Boolean-Operations-on-Polygons-Merge-Code-to-geometry-Package-tp4679083p4679230.html
> Sent from the Octave - Maintainers mailing list archive at Nabble.com.
>
>
> I think that the Z-values for the vertices might be pretty simple with the
> Boost.Geometry solution. We can define the point model in any manner we want
> internally for use by the Boost algorithms. This could easily be adapted to
> include a Z-value. However, what you would probably need to give us is a
> specified algorithm for how to determine the Z-value of the output vertices
> of an operation, based on the Z-values of the inputs.
>
> For example, if you are doing a difference between two polygons A and B as
> A-B, can you assume that all the vertices of A have the same Z-value and all
> the vertices of B have the same Z-value? Should the output of the A-B
> operation have the Z-values of A, the Z-valuse of B, or the average of the
> Z-values of A and B? I think that once the logic of how resultant Z-values
> are determined that the implementation should be pretty straightforward,
> even if it is don’t as a “post” step after the Boost.Geometry polygon
> operation.
>
> The nice thing about using the Z-values is that we can just modify the
> various functions we have made (polyjoin, polysplit, poly2fv, polybool) so
> that they have an optional third parameter and will only include Z-values in
> the output if it included Z-values for the input.
>
> John
>
>
> Hi all,
>
> I think there is no sad thing about redundant functions. We should
> sort out whether we remove some of them or we make a frontend function
> to select them according to user's needs.
> Is poly2tri hosted somewhere (upstream)? if yes, then it is better to
> provide instructions to install it rather than to repack it inside
> geometry.
>
> Let see how fast we can merge all this neat work.
>
>
> Unfortunately there are no packages for poly2tri in any of the major
> distributions. The project code was originally developed on code.google.com,
> which is now defunct. The original author transferred the repository to his
> Github account at https://github.com/greenm01. There haven’t been any
> updates in a couple of years on the main repository and a few on a branch at
> https://github.com/jhasse/poly2tri/commits/master that doesn’t some const
> parameter modifications, which I assume might allow the compile to optimize
> a little bit more.
>
> We had included the source in the repository because it is only 12 files,
> but if you think we should pull it from Github as part of the build process,
> that is fine also.
>
If the project is abandoned I guess we can ship it with geometry.
However I would include it inside the src folder.

> Amr is working right now on making the configure check the version of
> Boost.Geometry that is available. His repository currently has the necessary
> Boost header files (Geometry is a header-only library) in his repository. He
> is working to just use the system Boost. The reason we are checking the
> Boost.Geometry version is:
> a) If the version is < 1.60, then the self-intersection correction is not
> supported
> b) If the version is > 1.60, we then will check if the dissolve algorithm is
> included in the library (currently not available in 1.60 or 1.61, but
> planned for some future release)
> c) If the version is > 1.60 and the dissolve algorithm isn’t in the system
> Boost.Geometry, include the dissolve.h and dissolver.h files that are part
> of the package. These have been extracted from the Boost.Geometry repository
> (but are not part of the release tarballs). I guess they don’t think the
> dissolve algorithm is robust enough yet, but we haven’t seen any problems in
> all our test cases.
>
> John S.