[GRASS-dev] Re: windows binaries

Michael Barton michael.barton at asu.edu
Sat Nov 11 13:46:25 EST 2006

Perhaps I'm missing something, but as I understood the proposed changes to
the script itself, the file names are generated in the bash script.

Other d.* commands do not generate their own output file names and paths
(nor do they have any way to do so because they are determined by a GRASS
environmental variable).

For all other d.* commands used in the GIS Manager, the file names and paths
are generated by TclTk modules (i.e., TclTk sets the environmental
variable), which then tracks the files for compositing.

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: Sat, 11 Nov 2006 10:13:14 +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:
>> 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>

More information about the grass-dev mailing list