On 2017-09-30 02:39+0100 p.d.rosenb...@gmail.com wrote:
Sent from my Windows 10 phone
From: Alan W. Irwin
Sent: 29 September 2017 20:31
To: Phil Rosenberg
Cc: Mark de Wever; plplot-dev
For those who may now how plfill works a bit better than me, something
that is supported by shapefiles, but currently not by plmap, is holes.
A polygon in a shapefile consists of multiple parts and clockwise
parts are filled whereas anticlockwise parts are holes. Is this
something we can do relatively easily with plfill or is it not really
doable?
I don't think that such a major change to plfill would be a good idea.
For example, calls to plsurf3d (example 8) and plshades (example 16)
end up at the lowest level as many different calls to plfill where
presumably some end up as anti-clockwise fills and some end up
as clockwise fills in difficult-to-predict ways.
I didn't mean to suggest changing plfill behaviour, just wondered if there was
some way already to do this.
Therefore, would it be possible for you to honor this shapefile
convention by simply not calling plfill from inside the plmap*
routines whenever they run into an anticlockwise part and by
changing our DocBook documentation of those routines appropriately?
I don't think this works as we have to not render the holes in the
first instance. E.g imagine an island with a lake. We want to fill
just the land, it the lake. This would be a clockwise polygon for the
island and an anticlockwise one for the lake. I think the only way to
do this would be to convert the polygon with its holes to a single
polygon, kind of like a c shape outline but with the ends of the c
touching to make it like an o.
Hi Phil:
It sounds like you are asking if we have the ability to fill a simple
(i.e. non self-intersecting, see
<https://en.wikipedia.org/wiki/Simple_polygon>) polygon A
everywhere other than where it intersects with a simple polygon B.
(For your example A would be the polygon describing the island
outline, and B would be the polygon describing the lake outline within
that island.)
If I have described that "not-intersect" case correctly, then the
answer to your question is we do not currently have the ability to
solve that problem. Which is another example of the truism
that dealing with fill issues always seems to be difficult.
However, that described problem could be solved
with logic rather similar to that needed for solving the general
problem of filling the intersection of two simple polygons. And we
already do have that capability almost entirely implemented
with the fill_intersection_polygon
routine in src/plfill.c that I implemented back in 2009. That logic
was compiled only if the USE_FILL_INTERSECTION_POLYGON macro is
#defined, and the last commit message that mentioned
USE_FILL_INTERSECTION_POLYGON is as follows:
commit b8be9fcf8de6f5263bdd356a8745ba5878fc3036
Author: Alan W. Irwin <air...@users.sourceforge.net>
Date: Mon Dec 28 17:41:45 2009 +0000
Fix cases where split 1/split 2 encompasses all/none of the polygon 2
vertices. This -DUSE_FILL_INTERSECTION_POLYGON=ON change finally gives good
results for the first four pages of example 25, if the clip limits are
shifted around to avoid the case (not implemented yet) where polygon
crossings occur at vertices.
So it appears I have the basic recursive algorithm working correctly, but
there are some details (e.g., polygon crossings at vertices) still to be
implemented.
However, I think that is near the last commit where
I worked on fill_intersection_polygon, because if I recall correctly
if that logic was used for the large number of plfill calls we
generate with our standard examples 8 and 16, I ran into bugs in the
PL_NEAR_* logic. Therefore, I "temporarily" suspended working on that
logic and never got back to it.
However, two years ago (see your posts with the subject line "Bug in
notcrossed() function of plfill.c" you discovered that our ordinary
fill logic (used when USE_FILL_INTERSECTION_POLYGON is not #defined)
also sometimes fails because of a PL_NEAR_PARALLEL bug. I have been
putting off solving that bug (although it is certainly on my ToDo list
for this release cycle). However, once that is solved, and the case of
polygon crossings at vertices solved, then it is certainly possible
that fill_intersection_polygon would just work as designed for all our
examples.
Of course, getting this all straightened out is going to take some
substantial time. So for now, I think you should ignore this shapelib
"hole" convention in the plmap routines while documenting this
limitation as well. But after the current PL_NEAR_PARALLEL bug is
definitively fixed, you might want to take a look at the
fill_intersection_polygon routine again to see whether you think it is
worth reviving and modifying for the "not-intersect" case that appears
to sometimes be important for shapelib maps.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
