[GRASS5] [bug #242] (grass) R_polygon_abs() seems to ignore islands

[Eric G. Miller]

On Thu, May 03, 2001 at 12:09:08AM +0100, Glynn Clements wrote:
> 
> Eric G. Miller wrote:
> 
> > > XDRIVER24 uses XFillPolygon's "Complex" mode, which should handle
> > > self-intersecting polygons. However, there is a choice of two filling
> > > rules: EvenOdd and WindingRule. From the XChangeGC manpage:
> > 
> > Yes, I played with them, they aren't the problem.
> > 
> > Problem is, there's no protocol for drawing polygons with holes.  That
> > is, the inner "holes" of the polygon should mask out the drawing of the
> > outer polygon.  I fooled around with d.area to create something of a
> > work around, but it isn't a very good implementation.  This capability
> > needs to exist in the drivers so they can implement it however is best
> > for their "device".  Built vector areas have the holes identified, so
> > it's at least partially a matter of passing this data to the driver for
> > appropriate behavior.
> 
> So, the issue is that the drivers can only draw "polygons", leaving no
> simple way to fill arbitrary "paths" like PostScript can?

I'm not sure what you mean.  We're only talking the context of filling
an area defined by a polygon, but allowing a portion of the filled area
to be masked (so it retains whatever was already there).  Like:

  ------
  \xxxxx\___________
   |xxxxxxxxxxxxxxxx|
   \x-------xxxxxxx/
    \x\     \xxxxx/
     \x\_____\xxx/
      \xxxxxxxxx/
       ---------

What I did with d.area is connect every inner "hole" with the outer
polygon via the shortest pair of colinear line segments I could make
from existing vertices.  It's rather a slow process though, especially
when the polygons are very large.  Also, I think there are cases where
it will produce poor results since it doesn't check if the shortest path
between a hole and the outside crosses another hole.

> In which case, this isn't likely to get fixed any time soon; even
> lifting Mesa's GLU-1.2 tesselator won't help. We would need the
> equivalent of the GLU-1.3 tesselator; given that Mesa's current stance
> is "use SGI's GLU library", I'm not expecting a GPL'd version to
> become available any time soon.

No idea about such things...

-- 
Eric G. Miller <egm2 at jps.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'