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

[Philip Nienhuis]

John Swensen 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.

<sorry for a bit of delay in answering>

My interest is mainly in clipping polygons ("AND"). Other boolean 
operations are less of interest for me, although I think that the basic 
principles of what I want are similar.

The polygons I work with contain Z-value attributes that can differ for 
each individual vertex. Those "Z"-values need not be coordinates like X 
or Y (but sometimes are). To me they're just values of some property 
that varies over the subject polygon.

What I needed up till now, and AFAICS for foreseeable future, is a 
simple linear interpolation of (one or more) Z-values between subject 
polygon vertices along the side connecting those subject polygon 
vertices - i.e., interpolated Z-value(s) for each "new" vertex resulting 
from polygon clipping operations.
So in case of some clipping polygon that zig-zags e.g. ten times between 
two subject polygon vertices, ten new vertices are created each of one 
would need Z-values linearly interpolated between the Z-values of the 
original subject polygon.

Thinking more about it, what would really be useful is rather a relative 
value (0 - 1, or 0 - 100 %) for the distance of such a new vertex from 
one subject polygon vertex to the other subject polygon vertex, e.g. in 
clockwise direction. That way I can more easily work with e.g. Z-values 
that depend on yet other factors, e.g., change in time.

Is what I wrote is clear enough?

Philip