Re: [Plplot-devel] [Bug] Plmap omits lines at the left hand side ofthe map

[Alan W. I. <ir...@be...>]

On 2017-09-30 02:39+0100 p.d...@gm... 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 <ai...@us...>
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
__________________________