[GRASS5] Fw: d.area progress report...

[Glynn Clements]

Eric G. Miller wrote:

> > Very simply, from last point of area to first of isle and from last of isle 
> > back to last of area. But I have tested only with simple data and some
> > problems may occure later. But in that case I would prefer improvement of
> > G_plot_polygon. You can see the code in d.vect / g51. (And test in grass51)
> 
> Yea.  I think you got lucky.  Try it with non-convex polygons with little
> holes spread around in nooks and crannies.  Also, don't draw unlabeled
> areas, they'll mask the outcome.
> 
> I'm thinking G_plot_polygon, or a derivative, could be modified and either
> present a three part interface as previously described or a single function
> that can take **xs, **ys, and *n for inputs.  It would have to process the
> edges of each ring (finding the scanline intersections), before moving on
> to do the point sort and generating the fill start/stop extents.
> 
> What I don't understand is why any of these functions are in libgis.  IMHO,
> they should all be in the display library

G_plot_polygon() isn't restricted to displaying polygons on a monitor. 
It's "output" is generated by calling the "move" and "cont" functions
which were previously registered with G_setup_plot(). It could just as
easily be used to "draw" into an array, or into a raster map layer.

> (and the display and raster libes should be merged).

The raster library is a low-level interface to the monitor protocol. 
Most of the functions simply send their parameters to the monitor,
preceded by an "opcode". The only non-trivial files are:

1. Raster.c, due to R_raster(), which analyses the data then calls
R_raster_char() (if all of the data can be represented as bytes) or
R_raster_int() (otherwise).

2. parse_mon.c, for R_parse_monitorcap() and supporting functions.

3. io.c, for socket/FIFO connection setup, termination and locking,
and the low-level I/O primitives (_send_*, _get_*).

The display library provides an application-level interface, e.g.
automatic scaling according to screen size.

Ultimately I would like to scrap the existing raster library and
monitor protocol altogether, and replace them with something more
flexible (e.g. floating-point geometric coordinates rather than
integer pixel indices, coordinate transformations, etc; IOW, something
more like PostScript or OpenGL).

The display library would initially need to be retained for backwards
compatibility.

> One problem encountered is there's more than one method used for
> world/screen coordinate mappings, and they aren't consistent.

That is certainly undesirable.

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