[GRASS-dev] windows binaries

GRASS GIS GRASS GIS developer
1

Hello Paul,

Are you planning on publishing wingrass binaries at any point ? And could you maybe post details of all you did to compile wingrass (which other packages have to be installed, which configure flags, etc) ?

As I said, I will have a bit more time in the near future and am more than willing to help with wingrass.

For our needs here I will at one point have to attack the challenge of rewriting d.vect.thematic in C, but maybe we should make the current GRASS version work reasonably well before going for that.

Please tell me what you think would be a priority for me to work on.

Thanks !

Moritz

2

Hello Moritz

On Tue, 7 Nov 2006, Moritz Lennert wrote:

Hello Paul,

Are you planning on publishing wingrass binaries at any point ? And could you

I guess I would if I think it's working well enough. If I got it to a stage where there was one zip file you could unzip anywhere, and an easy-to-edit Windows batch/command file to put a few paths into and save somewhere, I would consider that working well enough!

maybe post details of all you did to compile wingrass (which other packages have to be installed, which configure flags, etc) ?

OK don't have much time to say now but basically I followed Glynn's instructions posted to the list a week or two ago, with the difference that I was able to get shared libraries working OK. I haven't tried relocating anything or installing it on a different machine, or one wiithout Msys - that's a big challenge. You need to install Mingw and Msys to give you the build environment, and then you run configure and make from within there. But once compiled you don't need to run GRASS from within the Msys environment. There are a few places in the source code where the assumption "Msys == Windows" has been made in the past and it's so tedious tracking them down!

I compiled and installed xdr lib, zlib and png lib in the Mingw lib/include directories. Used proj-4.5.0 and GDAL CVS from 2006-10-29 - the latest stable version of GDAL didn't work. I can't find any notes of my configure options from compiling those so I guess they weren't too important.

Apart from Glynn's list I also installed Activestate Tcl. It seemed like a genuine native Windows Tcl version with no Cygwin or Msys influences so I thought it would be a good robust test. My configure options were:
./configure --prefix=c:/grass --bindir=c:/grass/bin \
--with-includes=/c/grass/include --with-libs=/c/grass/lib --with-cxx \
--without-jpeg --without-tiff --without-postgres --without-opengl \
--without-fftw --without-x --enable-x11=no --enable-shared=yes \
--with-tcltk-includes=/c/tcl/include --with-tcltk-libs=/c/tcl/bin

As I said, I will have a bit more time in the near future and am more than willing to help with wingrass.

For our needs here I will at one point have to attack the challenge of rewriting d.vect.thematic in C, but maybe we should make the current GRASS version work reasonably well before going for that.

Didn't I read that d.vect.thematic needs the PNG driver to work. Have to confess that I'm not sure what it does - could it use ps.map? Anyway it won't be working on Windows in the near future so would be worthwhile I'm sure.

Please tell me what you think would be a priority for me to work on.

I guess when people start using the native Windows they will mostly be doing it from the GUI and when things go wrong the error messages won't be entirely obvious. So it might be a good idea to investigate as much as possible from the command line whether most modules are working normally. Maybe the test suite could be useful. I came across loads of issues just while testing a few of my favourite modules. Look out for strange things like text strings apparently over-writing each other - caused by extraneous carriage return characters read in from text lines with \r\n line-endings. And pathnames and when the windows-style with backslashes absolutely has to be used is another useful thing to look out for. Trying to run things from a cmd.exe prompt rather than /bin/sh is probably helpful for looking out for native Windows issues.

Paul

3

Paul Kelly wrote:

Didn't I read that d.vect.thematic needs the PNG driver to work. Have
to confess that I'm not sure what it does - could it use ps.map?

d.graph would be an easier path I think.

Hamish

4

Disclaimer: I only see a fragment of the entire post, and might
misunderstand.

D.vect.thematic does not require any particular driver. It uses d.vect
(iterated over different theme values) to render the final map.

This is why it can work with either an xmonitor or a TclTk canvas (the
latter via the PNG driver and immediate rendering mode.)

D.vect.thematic should become a C-module like d.vect.chart. But since I
don't know C I simply wish.

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: Hamish <hamish_nospam@yahoo.com>
Date: Wed, 8 Nov 2006 16:05:19 +1300
To: Paul Kelly <paul-grass@stjohnspoint.co.uk>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: windows binaries

Paul Kelly wrote:

Didn't I read that d.vect.thematic needs the PNG driver to work. Have
to confess that I'm not sure what it does - could it use ps.map?

d.graph would be an easier path I think.

Hamish

5

Michael Barton wrote:

Disclaimer: I only see a fragment of the entire post, and might
misunderstand.

D.vect.thematic does not require any particular driver. It uses d.vect
(iterated over different theme values) to render the final map.

This is why it can work with either an xmonitor or a TclTk canvas (the
latter via the PNG driver and immediate rendering mode.)

It won't work in immediate rendering mode since, as you say, it calls d.vect several times and in immediate rendering mode each call creates a new map from scratch, thus losing the overlaying of the different classes. This is why, in order to make it work with gis.m, it is (as far as I know) the only module using the PNG driver, and not immediate rendering. However, the PNG driver is not available in wingrass.

D.vect.thematic should become a C-module like d.vect.chart. But since I
don't know C I simply wish.

It is high on my priority list as it will be a convincing argument for my colleagues if I can present them a nice module for thematic mapping.

Up to now, I was thinking neither in terms of ps.map, nor in terms of d.graph, but rather in terms of direct access to rendering. In my current understanding this means finding out how d.vect works in detail and applying that to d.vect.thematic.

But maybe using do_poly() and do_color() from d.graph might be another solution, but I will have to look at these in detail to understand.

I think I will try to quite quickly draw up a description of what I am aiming for and then ask y'all to advise me at how to do it.

Moritz

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: Hamish <hamish_nospam@yahoo.com>
Date: Wed, 8 Nov 2006 16:05:19 +1300
To: Paul Kelly <paul-grass@stjohnspoint.co.uk>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: windows binaries

Paul Kelly wrote:

Didn't I read that d.vect.thematic needs the PNG driver to work. Have
to confess that I'm not sure what it does - could it use ps.map?

d.graph would be an easier path I think.

Hamish

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

6

Moritz,

I looked at the script and you are indeed correct. I guess I'd forgotten
about this. Why is the PNG driver not available in wingrass when immediate
rendering works (AFAIK using the same underlying driver code and the PNG
driver)? I could rewrite d.vect.thematic as a TclTk module, but am reluctant
to do so because it would make it unavailable to people not using the TclTk
GUI--and make it more work to port to a new GUI platform.

I very much appreciate your efforts to start a C version. I won't be able to
advise you on coding, but might be able to offer some more general advice.

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

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

From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Wed, 08 Nov 2006 16:05:14 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Hamish <hamish_nospam@yahoo.com>, Paul Kelly
<paul-grass@stjohnspoint.co.uk>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: windows binaries

Michael Barton wrote:

Disclaimer: I only see a fragment of the entire post, and might
misunderstand.

D.vect.thematic does not require any particular driver. It uses d.vect
(iterated over different theme values) to render the final map.

This is why it can work with either an xmonitor or a TclTk canvas (the
latter via the PNG driver and immediate rendering mode.)

It won't work in immediate rendering mode since, as you say, it calls
d.vect several times and in immediate rendering mode each call creates a
new map from scratch, thus losing the overlaying of the different
classes. This is why, in order to make it work with gis.m, it is (as far
as I know) the only module using the PNG driver, and not immediate
rendering. However, the PNG driver is not available in wingrass.

D.vect.thematic should become a C-module like d.vect.chart. But since I
don't know C I simply wish.

It is high on my priority list as it will be a convincing argument for
my colleagues if I can present them a nice module for thematic mapping.

Up to now, I was thinking neither in terms of ps.map, nor in terms of
d.graph, but rather in terms of direct access to rendering. In my
current understanding this means finding out how d.vect works in detail
and applying that to d.vect.thematic.

But maybe using do_poly() and do_color() from d.graph might be another
solution, but I will have to look at these in detail to understand.

I think I will try to quite quickly draw up a description of what I am
aiming for and then ask y'all to advise me at how to do it.

Moritz

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: Hamish <hamish_nospam@yahoo.com>
Date: Wed, 8 Nov 2006 16:05:19 +1300
To: Paul Kelly <paul-grass@stjohnspoint.co.uk>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: windows binaries

Paul Kelly wrote:

Didn't I read that d.vect.thematic needs the PNG driver to work. Have
to confess that I'm not sure what it does - could it use ps.map?

d.graph would be an easier path I think.

Hamish

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

7

Michael Barton wrote:

Moritz,

I looked at the script and you are indeed correct. I guess I'd forgotten
about this. Why is the PNG driver not available in wingrass when immediate
rendering works (AFAIK using the same underlying driver code and the PNG
driver)?

Direct rendering does not use the PNG monitor driver which uses UNIX sockets, but renders directly. AFAIU, in MS Windows we don't have the UNIX sockets that the monitors depend on.

I could rewrite d.vect.thematic as a TclTk module, but am reluctant
to do so because it would make it unavailable to people not using the TclTk
GUI--and make it more work to port to a new GUI platform.

I agree.

I very much appreciate your efforts to start a C version. I won't be able to
advise you on coding, but might be able to offer some more general advice.

Thanks.

Moritz

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

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

From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Wed, 08 Nov 2006 16:05:14 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Hamish <hamish_nospam@yahoo.com>, Paul Kelly
<paul-grass@stjohnspoint.co.uk>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: windows binaries

Michael Barton wrote:

Disclaimer: I only see a fragment of the entire post, and might
misunderstand.

D.vect.thematic does not require any particular driver. It uses d.vect
(iterated over different theme values) to render the final map.

This is why it can work with either an xmonitor or a TclTk canvas (the
latter via the PNG driver and immediate rendering mode.)

It won't work in immediate rendering mode since, as you say, it calls
d.vect several times and in immediate rendering mode each call creates a
new map from scratch, thus losing the overlaying of the different
classes. This is why, in order to make it work with gis.m, it is (as far
as I know) the only module using the PNG driver, and not immediate
rendering. However, the PNG driver is not available in wingrass.

D.vect.thematic should become a C-module like d.vect.chart. But since I
don't know C I simply wish.

It is high on my priority list as it will be a convincing argument for
my colleagues if I can present them a nice module for thematic mapping.

Up to now, I was thinking neither in terms of ps.map, nor in terms of
d.graph, but rather in terms of direct access to rendering. In my
current understanding this means finding out how d.vect works in detail
and applying that to d.vect.thematic.

But maybe using do_poly() and do_color() from d.graph might be another
solution, but I will have to look at these in detail to understand.

I think I will try to quite quickly draw up a description of what I am
aiming for and then ask y'all to advise me at how to do it.

Moritz

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: Hamish <hamish_nospam@yahoo.com>
Date: Wed, 8 Nov 2006 16:05:19 +1300
To: Paul Kelly <paul-grass@stjohnspoint.co.uk>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: windows binaries

Paul Kelly wrote:

Didn't I read that d.vect.thematic needs the PNG driver to work. Have
to confess that I'm not sure what it does - could it use ps.map?

d.graph would be an easier path I think.

Hamish

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

8

Michael Barton wrote:

Moritz,

I looked at the script and you are indeed correct. I guess I'd forgotten
about this. Why is the PNG driver not available in wingrass when immediate
rendering works (AFAIK using the same underlying driver code and the PNG
driver)? I could rewrite d.vect.thematic as a TclTk module, but am reluctant
to do so because it would make it unavailable to people not using the TclTk
GUI--and make it more work to port to a new GUI platform.

The following text is copied from one of my replies in the thread
"lib/pngdriver Mingw compile error".

  The main problem with monitors on Windows is the use of fork().
  
  "d.mon start=..." runs mon.start using system(). mon.start starts the
  driver using execl(), so the driver takes over the mon.start process.
  The driver initialises itself then goes into the background by
  fork()ing and having the parent exit. At that point, the system() call
  in d.mon returns, and d.mon then runs mon.select (unless you used the
  -s switch).
  
  This all works because the system("mon.select ...") doesn't return
  until the driver has initialised itself and (the child version) is
  listening on the socket.
  
  On Windows, there are several problems with this:
  
  1. Native Windows doesn't have fork() or execl().
  
  2. Cygwin's versions didn't work correctly for this purpose on
  Win95/98/ME.
  
  3. Cygwin's versions won't work on any version of Windows for the
  libW11 driver, as the child process doesn't inherit the various
  Windows GUI objects created by the parent (cf X11, where the the only
  system object is the connection to the X server).
  
  4. Replacing the execl() with spawnl(_P_DETACH,...) and having the
  driver run in the foreground eliminates the above issues, but the
  result is that system("mon.start ...") returns before the driver has
  initialised itself, so the subsequent mon.select fails.
  
  To make the monitor startup work correctly on Windows, we either need
  to add some kind of signalling mechanism, or add code to mon.start
  which polls the driver until its ready to accept connections.
  
  That still leaves one more problem:
  
  5. Native windows doesn't support PF_LOCAL (Unix-domain) sockets.
  
  > b) try and get some simple monitor view window working that reads the
  > output from the PNG driver
  
  All of the above issues except #3 apply to all drivers, not just the X
  driver (or W11 driver). Using direct rendering will suffice for simple
  cases, but you can't combine multiple commands. Also, both the PNG
  driver and direct rendering have the limiation that modules which use
  the mouse won't work.

IOW, the way that display drivers work relies upon several
Unix-specific features. Porting them to Windows would be a fair amount
of work, the utility of which is debatable given that most modules
with direct rendering.

--
Glynn Clements <glynn@gclements.plus.com>

9

Moritz Lennert wrote:

> Disclaimer: I only see a fragment of the entire post, and might
> misunderstand.
>
> D.vect.thematic does not require any particular driver. It uses d.vect
> (iterated over different theme values) to render the final map.
>
> This is why it can work with either an xmonitor or a TclTk canvas (the
> latter via the PNG driver and immediate rendering mode.)

It won't work in immediate rendering mode since, as you say, it calls
d.vect several times and in immediate rendering mode each call creates a
new map from scratch, thus losing the overlaying of the different
classes.

Could it easily be modified to work with direct rendering? I.e. make
multiple calls to d.vect, each generating a separate PPM/PGM pair,
then using g.composite to generate the final result?

--
Glynn Clements <glynn@gclements.plus.com>

10

From: Glynn Clements <glynn@gclements.plus.com>
Date: Thu, 9 Nov 2006 07:18:04 +0000
To: Moritz Lennert <mlennert@club.worldonline.be>
Cc: Michael Barton <michael.barton@asu.edu>, Paul Kelly
<paul-grass@stjohnspoint.co.uk>, Hamish <hamish_nospam@yahoo.com>,
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: windows binaries

Moritz Lennert wrote:

Disclaimer: I only see a fragment of the entire post, and might
misunderstand.

D.vect.thematic does not require any particular driver. It uses d.vect
(iterated over different theme values) to render the final map.

This is why it can work with either an xmonitor or a TclTk canvas (the
latter via the PNG driver and immediate rendering mode.)

It won't work in immediate rendering mode since, as you say, it calls
d.vect several times and in immediate rendering mode each call creates a
new map from scratch, thus losing the overlaying of the different
classes.

Could it easily be modified to work with direct rendering? I.e. make
multiple calls to d.vect, each generating a separate PPM/PGM pair,
then using g.composite to generate the final result?

--
Glynn Clements <glynn@gclements.plus.com>

I don't know. The problem is that this is being done in a BASH script,
outside the environment set up to handle such compositing in TclTk. I'll see
if it's doable without an enormous rewrite.

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

11

Michael Barton wrote:

>>> Disclaimer: I only see a fragment of the entire post, and might
>>> misunderstand.
>>>
>>> D.vect.thematic does not require any particular driver. It uses d.vect
>>> (iterated over different theme values) to render the final map.
>>>
>>> This is why it can work with either an xmonitor or a TclTk canvas (the
>>> latter via the PNG driver and immediate rendering mode.)
>>
>> It won't work in immediate rendering mode since, as you say, it calls
>> d.vect several times and in immediate rendering mode each call creates a
>> new map from scratch, thus losing the overlaying of the different
>> classes.
>
> Could it easily be modified to work with direct rendering? I.e. make
> multiple calls to d.vect, each generating a separate PPM/PGM pair,
> then using g.composite to generate the final result?

I don't know. The problem is that this is being done in a BASH script,
outside the environment set up to handle such compositing in TclTk. I'll see
if it's doable without an enormous rewrite.

AFAICT, the necessary changes would be:

1. At the start of the script:

if [ $GRASS_RENDER_IMMEDIATE = TRUE ] ; then
  imgbase=${GRASS_PNGFILE%.ppm}
fi

2. After each d.* command:

if [ $GRASS_RENDER_IMMEDIATE = TRUE ] ; then
  mv $imgbase.ppm $imgbase.$num.ppm # each image needs a different number
  if [ $GRASS_TRANSPARENT = TRUE ] ; then
    mv $imgbase.pgm $imgbase.$num.pgm
  fi
fi

3. At the end of the script:

if [ $GRASS_RENDER_IMMEDIATE = TRUE ] ; then
  if [ $GRASS_TRANSPARENT = TRUE ] ; then
    g.pnmcomp \
  output=$imgbase.ppm \
  width=$GRASS_WIDTH \
  height=$GRASS_HEIGHT \
  input=$imgbase.1.ppm,$imgbase.2.ppm \
  mask=$imgbase.1.pgm,$imgbase.2.pgm
  else
    g.pnmcomp \
  output=$imgbase.ppm \
  width=$GRASS_WIDTH \
  height=$GRASS_HEIGHT \
  input=$imgbase.1.ppm,$imgbase.2.ppm
  fi
fi

However:

1. I need to extend g.pnmcomp to allow it to output an alpha (mask)
channel.

2. It will fail if $GRASS_PNGFILE ends in .png rather than .ppm. There
isn't a compositing utility for PNG files.

Here's an idea: if direct rendering had an option to initialise the
framebuffer from an image file (or PPM/PGM pair), building up an image
by having multiple d.* commands render on top of each other would
work, in the same way that it does with persistent drivers.

--
Glynn Clements <glynn@gclements.plus.com>

12

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).

This approach might make other interesting effects possible.

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

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

From: Glynn Clements <glynn@gclements.plus.com>
Date: Thu, 9 Nov 2006 22:19:32 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: Moritz Lennert <mlennert@club.worldonline.be>, Paul Kelly
<paul-grass@stjohnspoint.co.uk>, Hamish <hamish_nospam@yahoo.com>,
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: windows binaries

Here's an idea: if direct rendering had an option to initialise the
framebuffer from an image file (or PPM/PGM pair), building up an image
by having multiple d.* commands render on top of each other would
work, in the same way that it does with persistent drivers.

13

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@gclements.plus.com>

14

Glynn Clements wrote:

1. I need to extend g.pnmcomp to allow it to output an alpha (mask)
channel.

Done. The outmask= option will write the alpha channel as a PGM file.

BTW, I had to modify gis.m's mapcanvas.tcl to use output= rather than
out=, as the latter is now ambiguous.

--
Glynn Clements <glynn@gclements.plus.com>

15

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
__________________________________________
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@gclements.plus.com>
Date: Fri, 10 Nov 2006 10:13:17 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: Paul Kelly <paul-grass@stjohnspoint.co.uk>, Hamish
<hamish_nospam@yahoo.com>, <grass-dev@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@gclements.plus.com>

16

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@gclements.plus.com>
Date: Fri, 10 Nov 2006 10:13:17 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: Paul Kelly <paul-grass@stjohnspoint.co.uk>, Hamish
<hamish_nospam@yahoo.com>, <grass-dev@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@gclements.plus.com>

17

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@gclements.plus.com>

18

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@gclements.plus.com>
Date: Sat, 11 Nov 2006 10:13:14 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: Paul Kelly <paul-grass@stjohnspoint.co.uk>, Hamish
<hamish_nospam@yahoo.com>, <grass-dev@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@gclements.plus.com>

19

Michael Barton wrote:

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.

The script generates the filenames for the intermediate files (the
ones produced by the individual d.* commands within the script). The
final step is to use g.pnmcomp to overlay the intermediate files, with
the output to $GRASS_PNGFILE.

The end result is that the script behaves like any other d.* command.
You set GRASS_PNGFILE (etc) and run it; when it's finished, you have
the images where you asked for them.

I really don't see how I can explain it any more clearly than that. I
don't even see what was unclear about the original suggestion:

From: Glynn Clements <glynn@gclements.plus.com>
Subject: Re: [GRASS-dev] Re: windows binaries
Date: Thu, 9 Nov 2006 22:19:32 +0000
Message-ID: <17747.43380.785380.210356@cerise.gclements.plus.com>

AFAICT, the necessary changes would be:

1. At the start of the script:

if [ $GRASS_RENDER_IMMEDIATE = TRUE ] ; then
  imgbase=${GRASS_PNGFILE%.ppm}
fi

This makes a note of the base filename ($GRASS_PNGFILE, with the .ppm
suffix removed). This will be used for intermediate files, so that
they use the same directory, retain the PID, etc. Also, this makes it
easier to refer to both the .ppm and .pgm files.

2. After each d.* command:

if [ $GRASS_RENDER_IMMEDIATE = TRUE ] ; then
  mv $imgbase.ppm $imgbase.$num.ppm # each image needs a different number
  if [ $GRASS_TRANSPARENT = TRUE ] ; then
    mv $imgbase.pgm $imgbase.$num.pgm
  fi
fi

d.* commands write their output to $GRASS_PNGFILE (and the
corresponding .pgm file if transparency is enabled). The above moves
them out of the way so that they don't get clobbered by subsequent d.*
commands.

Note: $imgbase.ppm is equal to $GRASS_PNGFILE, as $imgbase is just
$GRASS_PNGFILE with the .ppm suffix removed (step 1 above).

3. At the end of the script:

if [ $GRASS_RENDER_IMMEDIATE = TRUE ] ; then
  if [ $GRASS_TRANSPARENT = TRUE ] ; then
    g.pnmcomp \
  output=$imgbase.ppm \
  width=$GRASS_WIDTH \
  height=$GRASS_HEIGHT \
  input=$imgbase.1.ppm,$imgbase.2.ppm \
  mask=$imgbase.1.pgm,$imgbase.2.pgm
  else
    g.pnmcomp \
  output=$imgbase.ppm \
  width=$GRASS_WIDTH \
  height=$GRASS_HEIGHT \
  input=$imgbase.1.ppm,$imgbase.2.ppm
  fi
fi

This overlays the intermediate files, with the result going to
$GRASS_PNGFILE.

It needs a slight modification: the transparent case needs:

  outmask=$imgbase.pgm \

added.

Also, the intermediate files should be deleted at this point.

--
Glynn Clements <glynn@gclements.plus.com>

20

OK. I think I get it. Sorry about being dense.

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@gclements.plus.com>
Date: Sat, 11 Nov 2006 20:22:47 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: Paul Kelly <paul-grass@stjohnspoint.co.uk>, Hamish
<hamish_nospam@yahoo.com>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: windows binaries

Michael Barton wrote:

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.

The script generates the filenames for the intermediate files (the
ones produced by the individual d.* commands within the script). The
final step is to use g.pnmcomp to overlay the intermediate files, with
the output to $GRASS_PNGFILE.

The end result is that the script behaves like any other d.* command.
You set GRASS_PNGFILE (etc) and run it; when it's finished, you have
the images where you asked for them.

I really don't see how I can explain it any more clearly than that. I
don't even see what was unclear about the original suggestion:

From: Glynn Clements <glynn@gclements.plus.com>
Subject: Re: [GRASS-dev] Re: windows binaries
Date: Thu, 9 Nov 2006 22:19:32 +0000
Message-ID: <17747.43380.785380.210356@cerise.gclements.plus.com>

AFAICT, the necessary changes would be:

1. At the start of the script:

if [ $GRASS_RENDER_IMMEDIATE = TRUE ] ; then
  imgbase=${GRASS_PNGFILE%.ppm}
fi

This makes a note of the base filename ($GRASS_PNGFILE, with the .ppm
suffix removed). This will be used for intermediate files, so that
they use the same directory, retain the PID, etc. Also, this makes it
easier to refer to both the .ppm and .pgm files.

2. After each d.* command:

if [ $GRASS_RENDER_IMMEDIATE = TRUE ] ; then
  mv $imgbase.ppm $imgbase.$num.ppm # each image needs a different number
  if [ $GRASS_TRANSPARENT = TRUE ] ; then
    mv $imgbase.pgm $imgbase.$num.pgm
  fi
fi

d.* commands write their output to $GRASS_PNGFILE (and the
corresponding .pgm file if transparency is enabled). The above moves
them out of the way so that they don't get clobbered by subsequent d.*
commands.

Note: $imgbase.ppm is equal to $GRASS_PNGFILE, as $imgbase is just
$GRASS_PNGFILE with the .ppm suffix removed (step 1 above).

3. At the end of the script:

if [ $GRASS_RENDER_IMMEDIATE = TRUE ] ; then
  if [ $GRASS_TRANSPARENT = TRUE ] ; then
    g.pnmcomp \
output=$imgbase.ppm \
width=$GRASS_WIDTH \
height=$GRASS_HEIGHT \
input=$imgbase.1.ppm,$imgbase.2.ppm \
mask=$imgbase.1.pgm,$imgbase.2.pgm
  else
    g.pnmcomp \
output=$imgbase.ppm \
width=$GRASS_WIDTH \
height=$GRASS_HEIGHT \
input=$imgbase.1.ppm,$imgbase.2.ppm
  fi
fi

This overlays the intermediate files, with the result going to
$GRASS_PNGFILE.

It needs a slight modification: the transparent case needs:

outmask=$imgbase.pgm \

added.

Also, the intermediate files should be deleted at this point.

--
Glynn Clements <glynn@gclements.plus.com>