[GRASS-dev] Re: windows binaries

[Michael Barton]

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
__________________________________________
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>