[GRASS-dev] Re: windows binaries

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

It does except for the name and location. Currently, there are standards for
naming (based on pid) and file location (.tmp directory within the current
mapset) standards that get set prior to running each d.* command so that
when the image is rendered it is in a predictable format and location.
Because d.vect.thematic is a bash script, it becomes more complicated. There
somehow needs to be communication between the bash script and TclTk script
on this. I don't think is impossible, but needs to be worked out somehow.
I'll take a look and get back with the specifics of the information that
needs to be passed.

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