[GRASS-dev] discussion: replacing ps.map

[tlaronde at polynum.com]

On Wed, Mar 28, 2007 at 11:18:55PM +0100, Glynn Clements wrote:
> 
> tlaronde at polynum.com wrote:
> 
> > By using the legacy RASTERLIB now called DRAWLIB in KerGIS. [..]
> > [..]
> > In this sense, it is not difficult to implement a psdriver.
> 
> It isn't difficult to implement, but it won't necessarily be of much
> use given the existing API.
> 
> The main issue is the use of "pixels" for coordinates.

Well, for KerGIS the big plan is to let the DRAWLIB handle whatever is
related to a viewport (yes, this will be a change in the API, but in 
KerGIS the situation is simplified, since there are less d.* modules,
and since the legacy modules haven't been extended with very involved
"acrobatics" around the legacy RASTERLIB---see below for an example).

The modules will call the DRAWLIB in true coordinates (but using the
region, for vector the region constraint, to select previously what
shall be drawn and what not; but final clipping will be done in
DRAWLIB), and the DRAWLIB making the viewport
projection (one can even imagine that using libproj4 will allow
v.digit(1) for example to display graphics not in the north orientation,
but in whatever orientation is defined by the user). Then the graphical 
elements will be passed to the drivers in viewport coordinates. And the
drivers are responsabile for rasterization if they have to (the
functions will exist in a dedicated library so that they can be shared,
but the rasterization will definitively not be made neither in the d.*
module, nor in the RASTERLIB before communication to the
monitors/drivers).

There are also elements that are strictly viewport ones (say the use of
the viewport for "menus" as an example) or a dual nature (labels for
example, whose insertion point can be given in true coordinates, but
height is typically in viewport coordinates---called pixels, or points
for hardcopy) while symbols can be rendered wether in true size or in
a fixed viewport size.

So there will be two kinds of functions: ones with true coordinates,
others directly in viewport for non geographical but viewport
manipulations.

> 
> There is also a fair amount of code which makes certain assumptions
> about the end results of certain drawing operations. E.g. the default
> mechanism used by d.vect to render filled polygons is to use
> G_plot_polygon() to render a series of horizontal lines.

I have not this kind of problem in KerGIS since this was not in d.vect
but in d.area IIRC, and I have dropped it since it was not a correct use
of the DRAWLIB (the d.* shall not do rasterization; this belongs to the
drivers if there is a need to do so).

> 
> Also, rasters are scaled by the client to the desired dimensions in
> pixels, with the scaled data being sent to the driver, which renders
> it without further scaling.
> 
> I have changed this in the current CVS version; the drivers now
> provide a scaled-raster operation, which is more suitable for a
> PostScript driver.
> 
> I have also added higher-level interfaces to most of the drawing
> primitives (lib/display/draw2.c), but it will be a lot of work to
> migrate the modules away from the lower-level R_* functions.

As explain above, I have not as much of a problem, since I have more
simple d.* modules, and since I have not released officially 1.0 yet,
this means that I do not care about compatibility (but in this area, I
think there is not much of code built around DRAWLIB (RASTERLIB) so this
is an implementation detail that should not affect users).
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C