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

[Juan Pablo Carbajal]

On Wed, Aug 17, 2016 at 8:46 AM, AMR_KELEG <address@hidden> wrote:
> Dear Juan,
>
> I can easily move the include directory from the root path of the package to
> the src directory.
> Will this be more convenient to you?
>
> Amr
>
> ________________________________
> From: Juan Pablo Carbajal-2 [via Octave] <ml-node+[hidden email]>
> Sent: Tuesday, August 16, 2016 12:23 PM
> To: AMR_KELEG
> Subject: Re: GSoC '16 - Boolean Operations on Polygons : Merge Code to
> geometry Package
>
> On Mon, Aug 15, 2016 at 10:55 PM, John Swensen <[hidden email]> wrote:
>
>>
>> On Aug 15, 2016, at 1:32 PM, Juan Pablo Carbajal <[hidden email]>
>> wrote:
>>
>> On Mon, Aug 15, 2016 at 8:57 PM, John Swensen <[hidden email]> wrote:
>>
>>
>> On Aug 15, 2016, at 11:31 AM, PhilipNienhuis <[hidden email]> 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.
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://octave.1599824.n4.nabble.com/GSoC-16-Boolean-Operations-on-Polygons-Merge-Code-to-geometry-Package-tp4679083p4679247.html
> To unsubscribe from GSoC '16 - Boolean Operations on Polygons : Merge Code
> to geometry Package, click here.
> NAML
>
> ________________________________
> View this message in context: Re: GSoC '16 - Boolean Operations on Polygons
> : Merge Code to geometry Package
>
> Sent from the Octave - Maintainers mailing list archive at Nabble.com.

That will be great. It is an orderly package structure, src contains
source files.