|
From: | Amr Mohamed |
Subject: | Re: GSoC '16 - Boolean Operations on Polygons : Merge Code to geometry Package |
Date: | Wed, 17 Aug 2016 06:46:53 +0000 |
Dear Juan, From: Juan Pablo Carbajal-2 [via Octave] <ml-node+address@hidden>
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. > 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 |
[Prev in Thread] | Current Thread | [Next in Thread] |