[GRASS-dev] Re: windows binaries

[Glynn Clements]

Michael Barton wrote:

> Here is an overview of the compositing and display routines in which
> d.vect.thematic needs to be embedded.

[snip]

> So d.vect.thematic has to be rendered to the generic file name: [display
> PID].ppm and [display PID].pgm in $MAPSET/.tmp/[current_subdir]. It also
> needs to generate a proper layer file name: [layer-display PID].ppm and
> [layer-display PID].pgm. I think the most critical thing is to get the
> proper generic file name from mapcanvas.tcl. It needs to know the number of
> the display in which it will be rendered to do this. It then needs to
> generate a PID and display number based layer file name to commonlayer.tcl.

You're over-complicating matters.

d.vect.thematic just needs to behave like any other d.* command, in
spite of being a bash script.

When a d.* command is run with $GRASS_RENDER_IMMEDIATE = TRUE, it
generates a PPM/PGM pair with dimensions $GRASS_WIDTH * $GRASS_HEIGHT,
with the PPM file named $GRASS_PNGFILE and the PGM file named
${GRASS_PNGFILE%.ppm}.pgm (i.e. $GRASS_PNGFILE with the .ppm suffix
replaced by .pgm).

That is what my suggested changes to d.vect.thematic would achieve. 

When direct rendering is enabled, the images produced by each d.*
command are renamed (by inserting a unique number before the .ppm/.pgm
suffix). At the end of the script, d.vect.thematic itself runs
g.pnmcomp to overlay the various images to create a single PPM/PGM
pair.

All that gis.m knows is that it ran d.vect.thematic and ended up with
a PPM/PGM pair with the requested filenames and dimensions. It neither
knows nor needs to know anything about the process by which the images
were generated.

-- 
Glynn Clements <glynn at gclements.plus.com>