[GRASS-dev] why d.vect.thematic won't run on WinGRASS - d.mon problem

In order for d.vect.thematic to run in the GUI (the only way it will work in WinGRASS), it has to start and stop the PNG monitor.

To do this, it has to run d.mon–i.e., d.mon start=png and d.mon stop=png.

However, d.mon will not run in WinGRASS, probably because it does not have x11. I am betting that d.mon ALWAYS checks for an x11 monitor when it attempts to do something. However, it doesn’t really need one if it is running the PNG monitor (or perhaps doing some other tasks that are not related to starting, stopping, or selecting xmons).

If this is correct, is there a way to disable this check so that d.mon can start and stop the PNG driver without checking for an xmon?

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

Michael Barton wrote:

In order for d.vect.thematic to run in the GUI (the only way it will
work in WinGRASS), it has to start and stop the PNG monitor.

To do this, it has to run d.mon--i.e., d.mon start=png and d.mon
stop=png.

However, d.mon will not run in WinGRASS, probably because it does not
have x11. I am betting that d.mon ALWAYS checks for an x11 monitor
when it attempts to do something.

Nope. d.mon doesn't work in WinGRASS because monitors don't work in
WinGRASS. This isn't due to the lack of X11 (which only affects
XDRIVER), but the lack of Unix-style sockets (by which, I mean sockets
which work with read() and write(), not necessarily Unix-domain
sockets).

I tried modifying the code to use TCP sockets, but I couldn't get it
to work. Well, using TCP sockets works on Unix, but the process of
converting the WinSock SOCKET to an fd which works with MSVCRT's
read() and write() didn't seem to work.

So, unless someone is willing to invest the effort to replicate the
communication between libraster and the drivers, monitors will remain
unavailable in the native WinGRASS version.

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.

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

On Jan 23, 2008, at 6:42 PM, Glynn Clements wrote:

Michael Barton wrote:

In order for d.vect.thematic to run in the GUI (the only way it will
work in WinGRASS), it has to start and stop the PNG monitor.

To do this, it has to run d.mon--i.e., d.mon start=png and d.mon
stop=png.

However, d.mon will not run in WinGRASS, probably because it does not
have x11. I am betting that d.mon ALWAYS checks for an x11 monitor
when it attempts to do something.

Nope. d.mon doesn't work in WinGRASS because monitors don't work in
WinGRASS. This isn't due to the lack of X11 (which only affects
XDRIVER), but the lack of Unix-style sockets (by which, I mean sockets
which work with read() and write(), not necessarily Unix-domain
sockets).

I tried modifying the code to use TCP sockets, but I couldn't get it
to work. Well, using TCP sockets works on Unix, but the process of
converting the WinSock SOCKET to an fd which works with MSVCRT's
read() and write() didn't seem to work.

So, unless someone is willing to invest the effort to replicate the
communication between libraster and the drivers, monitors will remain
unavailable in the native WinGRASS version.

I was afraid that you were going to say something like that

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.

If we want it to work with Windows, it will take considerably more coding. we have to set GRASS_RENDER_IMMEDIATE=TRUE, track all iterations of d.vect and use g.pnmcomp to composite them all. It might be possible to make use of existing TclTk code to do some of this, but I doubt it.

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 04:54, Michael Barton wrote:

On Jan 23, 2008, at 6:42 PM, Glynn Clements wrote:

Michael Barton wrote:

In order for d.vect.thematic to run in the GUI (the only way it will
work in WinGRASS), it has to start and stop the PNG monitor.

To do this, it has to run d.mon--i.e., d.mon start=png and d.mon
stop=png.

However, d.mon will not run in WinGRASS, probably because it does not
have x11. I am betting that d.mon ALWAYS checks for an x11 monitor
when it attempts to do something.

Nope. d.mon doesn't work in WinGRASS because monitors don't work in
WinGRASS. This isn't due to the lack of X11 (which only affects
XDRIVER), but the lack of Unix-style sockets (by which, I mean sockets
which work with read() and write(), not necessarily Unix-domain
sockets).

I tried modifying the code to use TCP sockets, but I couldn't get it
to work. Well, using TCP sockets works on Unix, but the process of
converting the WinSock SOCKET to an fd which works with MSVCRT's
read() and write() didn't seem to work.

So, unless someone is willing to invest the effort to replicate the
communication between libraster and the drivers, monitors will remain
unavailable in the native WinGRASS version.

I was afraid that you were going to say something like that

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.

Maybe it would be possible to use GRASS_RENDER_IMMEDIATE=TRUE to create the different layers and then g.pnmcomp them ?

If we want it to work with Windows, it will take considerably more coding. we have to set GRASS_RENDER_IMMEDIATE=TRUE, track all iterations of d.vect and use g.pnmcomp to composite them all. It might be possible to make use of existing TclTk code to do some of this, but I doubt it.

Actually, the best bet is to get the C-replacement of d.vect.thematic up and running. For area mapping, it is already in a fairly usable state (IMHO), the main drawback at this stage probably being the lack of automagic color choosing. I'll try to compile it in mingw and see if I can put a binary on the website. For the other objects (lines and points) this will have to wait until I find the time...

I guess I should probably put the current code into svn soon, so that others can more easily work with it...

Moritz

Moritz:

I guess I should probably put the current code into svn soon, so that
others can more easily work with it...

yes please.

Hamish

      ____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

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>