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

[Glynn Clements]

Request Tracker wrote:

> Subject: R_polygon_abs() seems to ignore islands
> 
> - Vector:
>   R_polygon_abs() seems to ignore islands. Correct?
> 
>   Comment from Eric Miller:
>    While skimming through the BUG list, there's a report about
>    R_Polygon_abs() ignoring islands.  A little investigation would show this
>    to be correct.  However, each display driver must implement this
>    individually, and I only looked at the XDRIVER24 version.

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:

       The fill-rule defines what pixels are inside (drawn) for
       paths given in XFillPolygon requests and can be set to
       EvenOddRule or WindingRule.  For EvenOddRule, a point is
       inside if an infinite ray with the point as origin crosses
       the path an odd number of times.  For WindingRule, a point
       is inside if an infinite ray with the point as origin
       crosses an unequal number of clockwise and counterclock­
       wise directed path segments.  A clockwise directed path
       segment is one that crosses the ray from left to right as
       observed from the point.  A counterclockwise segment is
       one that crosses the ray from right to left as observed
       from the point.  The case where a directed line segment is
       coincident with the ray is uninteresting because you can
       simply choose a different ray that is not coincident with
       a segment.

The CELL driver only supports convex polygons.

The PNG driver uses gdImageFilledPolygon(); I don't know what that
supports.

The HTMLMAP driver cleans up the polygons, removes any polygon which
is completely enclosed by another polygon (treating polygons as
convex), then writes out the results as HTML <AREA ...> tags. The
interpretation will be whatever HTML defines it to be.

In short, if you want anything but convex polygons to work generally,
we're going to need a polygon tessellator. IIRC, Mesa implements the
GLU 1.2 tessellator, so we could lift that.

>    Anyway,  the code is real simple and does not do anything other than draw
>    a filled polygon based on supplied display coordinates and the already   
>    set fill color.  Presumably it is up to the caller to handle
>    islands/holes. However, this is probably not a simple task when drawing a
>    filled polygon cover over other layers.  Perhaps what is wanted is a high
>    level vector drawing command such as some of the commands in the
>    partially functional DISPLAYLIB???  I don't know X well enough to know if
>    it has a way to handle holes in it's polygon drawing routines.
>    A little more context for the BUG report seems in order since this really
>    doesn't seem to be a "bug", but a shortcoming.

All that progmangrass50.pdf says is:

    int
    R_polygon_abs (int *x, int *y,int num)

    The num absolute positions in the x and y arrays outline a closed
    polygon which is filled with the current color. The current position
    is left updated to the position of the last point.

So, it basically comes down to what it means by "polygon".

Is there any context (within GRASS) where "polygon" has a more precise
definition?

-- 
Glynn Clements <glynn.clements at virgin.net>

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