[GRASS-dev] Re: windows binaries

Michael Barton michael.barton at asu.edu
Fri Nov 10 14:22:13 EST 2006


Glynn,

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

When a display is opened (run instance of mapcanvas.tcl) a generic file name
is generated from the PID for the graphic and alpha mask files: [display
PID].ppm and [display PID].pgm.

The GRASS environmental variable GRASS_PNGFILE is set to the *.ppm in the
procedure MapCanvas::driversettings

    set env(GRASS_PNGFILE) "$mapfile($mon)"

When a set of display layers for a display are processed, each layer
generates its own PID-based file names for the graphic and alpha mask files:
[layer-display PID].ppm and [layer-display PID].pgm.

When the d.* command for a particular layer is processed, it is rendered to
the generic PPM/PGM file in the procedure MapCanvas::runprograms in the
$MAPSET/.tmp/[current_subdir] directory.

Then the script commonlayer.tcl is called. This renames the PPM/PGM files to
the layer-specific PPM/PGM file names and adds these names to a compositing
list.

Back in mapcanvas.tcl, the procedure MapCanvas::composite then runs
g.pnmcomp, using the compositing list, creating the final graphic output
which is displayed in the canvas.

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.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Fri, 10 Nov 2006 10:13:17 +0000
> To: Michael Barton <michael.barton at asu.edu>
> Cc: Paul Kelly <paul-grass at stjohnspoint.co.uk>, Hamish
> <hamish_nospam at yahoo.com>, <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Re: windows binaries
> 
> 
> Michael Barton wrote:
> 
>> This latter idea would work much better with interaction with the TclTk GIS
>> Manager. 
>> 
>> The GIS Manager expects for each d.* command to create a single PPM/PGM
>> pair, whose name is based on the PID obtained at the start of the procedure
>> for each GIS layer. These are then inserted into g.pnmcomp at the end of the
>> stack of GIS layers.
>> 
>> d.vect.thematic is treated like any other d.* command. If it did it's own
>> compositing via g.pnmcomp, it would still be complicated to get this into
>> the normal GIS layer stack of PPM/PGM pairs because it is not easy to pass
>> file names from a bash script to a TclTk script (this an the issue with
>> legend creation).
> 
> Note that, with my suggested script changes, the final composited
> image ends up in the file specified by $GRASS_PNGFILE, so it should
> appear to behave like other d.* commands in that regard.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list