[Octave-patch-tracker] [patch #9000] Polgon functions for geometry/mapping package

[Philip Nienhuis]

Follow-up Comment #2, patch #9000 (project octave):

@Juanpi

Is it worth the trouble incorporating polyclip etc now that a GSOC polybool
will happen this summer?
I'd be flattered :-) if you do and I think it is cool, but maybe a next
geometry package would need some changes. -Or- we can have both polyclip
(Clipper) and polybool (Boost:Geometry) living next to each other - I like the
statement "What is wrong with choice?"
(A.: maintainability but IMO that is a subjective thing)


To answer your questions:

polyclip is called in drwpatch to assess which subpolygons are holes; type
"help polyclip", you'll see that if it is called with one argument (just the
subject polygons) it returns 1s for "hole" (clockwise) subpolygons and 0s for
counterclockwise subpolygons.

So a new ispolycw.m function could simply be a wrapper for polyclip(). I do
not know which is fastest: 
- the ispolycw.m already shown in the maintainers ML:
http://octave.1599824.n4.nabble.com/GSoC-16-Sample-implementation-for-ispolycw-function-tc4675763.html
https://ideone.com/w6WFzB (binary so probably fast)

- a wrapper function around polygonArea() as I suggested there, 

- or a wrapper around polyclip.


drwpatch's "varargin" are not holes arguments but drawing arguments conveyed
1:1 to patch().  So drwpatch has to find out which subpolygons are holes. This
is stated in a comment as well.
The thing that isn't in comments is that drwpatch accepts one compound polygon
comprising several sets of outer + inner polygons; so it uses polyclip to find
out which inner polygons (holes) belong to which outer polygon (i.e.,
distinguish the sets) and process those sets one after the other. This way it
can draw polygons with holes that are nested.
polyclip can return a compound polygon comprising several sets of subpolygons
whose outer polygons may or may not be connected. drwpatch was designed to
handle this easily.


Checking for installed packages: if you absorb the functions into geometry the
OF geometry check isn't required. It's your pick as maintainer :-)  But if
they go into e.g., mapping I'd rather (1) politely inform the user of the
issue and (2) if at all possible try to follow an alternative route or even
skip the "special effects".


As to your example code: drwpatch assumes the subpolygons are closed. Adding
the first vertex to the end of each subpolygon gives the correct picture.

p  = [0 0; 0 1; 1 1; 1 0; 0 0]; %ccw
ph = p + [1.2 0];
# add hole
ph(end+1,:) = nan;
ph          = [ph; ([0 0; 1 0; 1 1; 0 1; 0 0]-[0.5 0.5])*0.5+[1.7 0.5]];
po = optimize_branch_cuts(ph);
patch (po(:,1), po(:,2))


Hmmm, maybe checks are required for each subpolygon to be a closed polygon.
Note that polyclip should also be capable of clipping polylines rather than
polygons. So I'd need to find out which functions need such checks.
I have little time until somewhere next week for diving into additional checks
like this.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?9000>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/