On Jan 24, 2008, at 2:54 AM, grass-dev-request@lists.osgeo.org wrote:
Date: Thu, 24 Jan 2008 10:53:51 +0000
From: Glynn Clements <glynn@gclements.plus.com>
Subject: Re: [GRASS-dev] why d.vect.thematic won't run on WinGRASS -
d.mon problem
To: Michael Barton <michael.barton@asu.edu>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Message-ID: <18328.28223.869808.987628@cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii
Michael Barton wrote:
If you just want d.vect.thematic to work with WinGRASS, changing it to
use GRASS_RENDER_IMMEDIATE=TRUE instead of "d.mon start=PNG" would
probably be less work than getting monitors working.
In fact, we recently had to change d.vect.thematic to set
GRASS_RENDER_IMMEDIATE=FALSE so that it's multiple iterations of
d.vect would composite in the PNG monitor and then be output as a PNG
to the GUI.
You can use GRASS_PNG_READ=TRUE to have it read an existing file at
startup, rather than starting with a blank "screen". That way, each
command will overlay the output from previous commands.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn,
This sounds like it might be a way out of this dilemma. Can you explain this setting a it more? Also, once all the commands are overlayed is there someway to get them to output to a PNG or PNM so that the GUI can pick it up--since we can't do it with d.mon stop=PNG?
Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>
On 24/01/08 16:07, Michael Barton wrote:
On Jan 24, 2008, at 2:54 AM, grass-dev-request@lists.osgeo.org wrote:
Date: Thu, 24 Jan 2008 10:53:51 +0000
From: Glynn Clements <glynn@gclements.plus.com>
Subject: Re: [GRASS-dev] why d.vect.thematic won't run on WinGRASS -
d.mon problem
To: Michael Barton <michael.barton@asu.edu>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Message-ID: <18328.28223.869808.987628@cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii
Michael Barton wrote:
If you just want d.vect.thematic to work with WinGRASS, changing it to
use GRASS_RENDER_IMMEDIATE=TRUE instead of "d.mon start=PNG" would
probably be less work than getting monitors working.
In fact, we recently had to change d.vect.thematic to set
GRASS_RENDER_IMMEDIATE=FALSE so that it's multiple iterations of
d.vect would composite in the PNG monitor and then be output as a PNG
to the GUI.
You can use GRASS_PNG_READ=TRUE to have it read an existing file at
startup, rather than starting with a blank "screen". That way, each
command will overlay the output from previous commands.
--Glynn Clements <glynn@gclements.plus.com>
Glynn,
This sounds like it might be a way out of this dilemma. Can you explain this setting a it more? Also, once all the commands are overlayed is there someway to get them to output to a PNG or PNM so that the GUI can pick it up--since we can't do it with d.mon stop=PNG?
GRASS_RENDER_IMMEDIATE=TRUE always outputs a PNG or PNM file (depending on the setting of GRASS_PNGFILE. As the manual on the PNG env variables says: if you set GRASS_PNG_READ to "TRUE", "the PNG driver will initialize the image from the contents of $GRASS_PNGFILE", i.e. it will read the contents of $GRASS_PNGFILE and adds the results of your drawing command to it. The output thus still is $GRASS_PNGFILE.
Moritz
Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
So it builds the PNG as it goes, and then the TclTk GUI could grab the completed composite when it's done?
This sounds almost too good to be true.
Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>
On Jan 24, 2008, at 8:24 AM, Moritz Lennert wrote:
On 24/01/08 16:07, Michael Barton wrote:
On Jan 24, 2008, at 2:54 AM, grass-dev-request@lists.osgeo.org wrote:
Date: Thu, 24 Jan 2008 10:53:51 +0000
From: Glynn Clements <glynn@gclements.plus.com>
Subject: Re: [GRASS-dev] why d.vect.thematic won't run on WinGRASS -
d.mon problem
To: Michael Barton <michael.barton@asu.edu>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Message-ID: <18328.28223.869808.987628@cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii
Michael Barton wrote:
If you just want d.vect.thematic to work with WinGRASS, changing it to
use GRASS_RENDER_IMMEDIATE=TRUE instead of "d.mon start=PNG" would
probably be less work than getting monitors working.
In fact, we recently had to change d.vect.thematic to set
GRASS_RENDER_IMMEDIATE=FALSE so that it's multiple iterations of
d.vect would composite in the PNG monitor and then be output as a PNG
to the GUI.
You can use GRASS_PNG_READ=TRUE to have it read an existing file at
startup, rather than starting with a blank "screen". That way, each
command will overlay the output from previous commands.
--Glynn Clements <glynn@gclements.plus.com>
Glynn,
This sounds like it might be a way out of this dilemma. Can you explain this setting a it more? Also, once all the commands are overlayed is there someway to get them to output to a PNG or PNM so that the GUI can pick it up--since we can't do it with d.mon stop=PNG?
GRASS_RENDER_IMMEDIATE=TRUE always outputs a PNG or PNM file (depending on the setting of GRASS_PNGFILE. As the manual on the PNG env variables says: if you set GRASS_PNG_READ to "TRUE", "the PNG driver will initialize the image from the contents of $GRASS_PNGFILE", i.e. it will read the contents of $GRASS_PNGFILE and adds the results of your drawing command to it. The output thus still is $GRASS_PNGFILE.
Moritz
Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
grass-dev Info Page
On 24/01/08 16:30, Michael Barton wrote:
So it builds the PNG as it goes, and then the TclTk GUI could grab the completed composite when it's done?
That's how I understand the docs. Just watch out to set GRASS_PNG_READ back to FALSE after d.vect.thematic finishes...
This sounds almost too good to be true.
Glynn is too good to be true 
Moritz
I'm going to try this as soon as I can steal a bit of time. I'm somewhat uncertain how to get the initial PNG for GRASS_PNG_READ.
I can create a dummy temp map using r.mapcalc and then save it to a PNG using r.out.png. But I need to make sure that it's background is transparent so that the final composite can overlay whatever is in the map display. Any suggestion for how I do that?
Michael
______________________________
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Jan 24, 2008, at 8:40 AM, Moritz Lennert wrote:
On 24/01/08 16:30, Michael Barton wrote:
So it builds the PNG as it goes, and then the TclTk GUI could grab the completed composite when it's done?
That's how I understand the docs. Just watch out to set GRASS_PNG_READ back to FALSE after d.vect.thematic finishes...
This sounds almost too good to be true.
Glynn is too good to be true 
Moritz
Michael Barton wrote:
I'm going to try this as soon as I can steal a bit of time. I'm
somewhat uncertain how to get the initial PNG for GRASS_PNG_READ.
I can create a dummy temp map using r.mapcalc and then save it to a
PNG using r.out.png. But I need to make sure that it's background is
transparent so that the final composite can overlay whatever is in the
map display. Any suggestion for how I do that?
You don't actually need to create an initial image; if the file
doesn't exist, any GRASS_PNG_READ=TRUE setting will be silently
ignored. If the file does exist, the dimensions and depth must match
the values of $GRASS_WIDTH, $GRASS_HEIGHT and $GRASS_TRUECOLOR.
You can create a blank image with "d.frame -e" or "d.erase -f". If
GRASS_TRANSPARENT=TRUE, the image will be transparent, otherwise it
will be filled with $GRASS_BACKGROUNDCOLOR. This works both with
direct rendering and the PNG driver. Note that "d.erase" alone is
equivalent to "d.erase color=white". There isn't any way to clear a
portion of the screen to transparent, only the entire screen.
--
Glynn Clements <glynn@gclements.plus.com>
Does d.erase work if there are no monitors?
Michael
______________________________
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Jan 24, 2008, at 3:07 PM, Glynn Clements wrote:
Michael Barton wrote:
I'm going to try this as soon as I can steal a bit of time. I'm
somewhat uncertain how to get the initial PNG for GRASS_PNG_READ.
I can create a dummy temp map using r.mapcalc and then save it to a
PNG using r.out.png. But I need to make sure that it's background is
transparent so that the final composite can overlay whatever is in the
map display. Any suggestion for how I do that?
You don't actually need to create an initial image; if the file
doesn't exist, any GRASS_PNG_READ=TRUE setting will be silently
ignored. If the file does exist, the dimensions and depth must match
the values of $GRASS_WIDTH, $GRASS_HEIGHT and $GRASS_TRUECOLOR.
You can create a blank image with "d.frame -e" or "d.erase -f". If
GRASS_TRANSPARENT=TRUE, the image will be transparent, otherwise it
will be filled with $GRASS_BACKGROUNDCOLOR. This works both with
direct rendering and the PNG driver. Note that "d.erase" alone is
equivalent to "d.erase color=white". There isn't any way to clear a
portion of the screen to transparent, only the entire screen.
--
Glynn Clements <glynn@gclements.plus.com>
Michael Barton wrote:
Does d.erase work if there are no monitors?
It works with direct rendering.
d.erase just fills a rectangle in a specific colour. "d.erase -e" is
different in that it uses the R_erase() function (as does
"d.frame -e"), which corresponds to the ERASE opcode.
The PNG driver library (used by both the standalone driver and direct
rendering) responds to this opcode by clearing the image, making it
transparent if GRASS_TRANSPARENT=TRUE.
The only program which fundamentally doesn't work with direct
rendering is d.mon.
A few other programs aren't much use with direct rendering as they
rely upon operations which aren't implemented.
The main issue with direct rendering is that there is no persistence
between commands. This makes d.font useless, and d.frame mostly
useless ("d.frame -e" works to erase the screen, but you can't create
persistent frames).
Obviously, mouse interaction doesn't work, but that's also true of the
PNG driver (and all drivers except XDRIVER). Panels (the ability to
save and restore regions of the screen) don't work with either the PNG
driver or direct rendering, but they're only ever used in conjunction
with mouse interaction.
--
Glynn Clements <glynn@gclements.plus.com>