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

[Glynn Clements]

Eric G. Miller wrote:

> > > 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/
> > >        ---------
> > 
> > OK; a lot of people (myself included) wouldn't call that a "polygon". 
> > Further, a lot of people automatically read "polygon" as "convex
> > polygon", as many graphics APIs are limited to such.
> 
> Understand, but this is a real world requirement for *any* GIS that does
> vectors.

I can understand that there may be a need for handling arbitrary
vector "shapes", but those needs may well go beyond just drawing the
shapes.

> I think your being a little too pessimistic here.  The OpenGL scenario
> has several issues not present in a 2d representation.

OpenGL also assumes that polygons are planar, which basically reduces
the problem to 2d:

1. Project the polygon onto a 2d plane.
2. Compute which edges need to be split and where
3. perform the actual interpolation using the 3d coordinates.

It's part 2 that's hard, and that's a 2d problem.

> Also, I'm sure
> there was considerable concern about the speed of the implementation,
> since GL is used in games and such where the image needs to change
> rapidly (less of a concern here).

Not really. 

1. Because the GLU tessellator is just a library which uses the
lower-level GL polygon facilities, you would typically call the GLU
tessellation functions while constructing a display list. The display
list would comprise the individual convex polygons, so you wouldn't
necessarily have to continually re-tessellate the polygon.

2. OpenGL isn't just for games. Mesa possibly more so, as its primary
focus has tended to be with software rendering. In any case, I'm
fairly sure that they would have settled for a slow tessellator in
preference to no tessellator.

3. Game developers normally circumvent the entire problem by ensuring
that the source data is built entirely from convex polygons. 
Furthermore, it's quite common to use just triangles, as even the most
geometrically illiterate 3d modeller simply cannot create a non-convex
triangle.

> Besides, I *know* this problem is solvable (even if I don't have the
> solution yet).

I know that it's solvable (SGI have a working GLU 1.2 tessellator). I
also know that it's not a five-minute job.

> The weak solution would be just to rasterize all of
> the fill areas in a seperate buffer and then "overlay" that on the
> current display buffer.  I considered that approach for d.area but
> haven't yet tried it to see if it's faster for large data sets (I
> assumed not).

If d.area converts to rasters, the HTMLMAP driver isn't likely to be
much use.

More generally, rasterisation reduces the information content. 
Presumably there are other vector operations which should be able to
handle shapes which aren't convex polygons.

-- 
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'