[GRASS-user] replacement for d.mon in GRASS 7.0?

GRASS GRASS user
1

Does someone know how translate previous display commands into GRASS70, i.e. integrate a py-script that is called
"d.mon x1=start" (or similar) into GRASS70 doing these command:

#####start display in GRASS7.0
export GRASS_PNGFILE=map.bmp
d.erase
ximgview map.bmp &
export GRASS_PNG_MAPPED=TRUE

This would allow to run GRASS64-scripts on GRASS70 and for those you prefer direct output out of the script, just go on doing this as before. I tried to do so, but didn't manage to handle the "export" command in py. Maybe someone
of knows howto?

greetz, Patrick

>>> I just started using d.mon in combination with d.rast to quickly display
>>> a layer - but d.mon will be removed in 7.0. I assume there is a
>>> replacement for it, which I can use in 7.0? I do not assume, that I have
>>> to use GUI for display.

>> >> You can use wxpyimgview[1] to view the images.
>> >> [1] or wximgview or ximgview. ximgview is C/Xlib, wximgview is
>> C++/wxWidgets, wxpyimgview is Python/wxWidgets.
>> >> For this, you need:
>> >> export GRASS_PNGFILE=map.bmp
>> export GRASS_PNG_MAPPED=TRUE
>> >> Optionally:
>> >> export GRASS_NOTIFY='kill -USR1<pid>'
>> >> where<pid> is the PID of the {x,wx,wxpy}imgview process. This allows
>> you to set percent=0; the display will be redrawn whenever a display
>> command completes.

2

Patrick_schirmer wrote:

Does someone know how translate previous display commands into GRASS70,
i.e. integrate a py-script that is called
"d.mon x1=start" (or similar) into GRASS70 doing these command:

#####start display in GRASS7.0
export GRASS_PNGFILE=map.bmp
d.erase
ximgview map.bmp &
export GRASS_PNG_MAPPED=TRUE

It can't be done that way. A program (or script) cannot change the
environment of its parent (e.g. the shell). This is why "export" has
to be a shell built-in rather than a program.

You could write a *shell* script which is "source"d rather than
executed, or you could write a script which sets the environment
variables then spawns a new shell.

But the only way that a "d.mon" program could be made to work would be
to change the drivers to read the settings from $GISRC rather than the
environment.

However, environment variables are more convenient for scripts and the
GUI. Checking for environment variables first then $GISRC second would
satisfy both use cases, but could be confusing for the user, as the
$GISRC settings would be ignored if one of the environment variables
was set.

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

3

Hello Glynn,

Somehow I didn't your answer via email, I just found it at
http://permalink.gmane.org/gmane.comp.gis.grass.user/38530
I attached the text below.

Yes, I am sure, that I want to do the "if(B,C)" not e.g. "if(B,B,C)",
but anyhow...it doesn't work.... I tried the **options version, but also no success. It seems that there is a bug in 6.5.

I've WinGrass 6.5SVN (http://grass.ibiblio.org/grass65/binary/mswindows/native/README.html) installed. I unistalled it and reinstalled it but still the same error. Everything else is working so far.

Maybe someone can reproduce my error, or tell me what I am doing wrong.

I am somehow depend on the 6.5 as on version 7 the r.stream.* module seems not to be integrated.

Any suggestions how to proceed?

cheers
Johannes

Johannes Radinger wrote:

I am running GRASS GIS 6.5 and want to run a python script
including a mapcaluculator-expression of a simple formula:

A=if(B,C)

grass.mapcalc("$upstream_shreve = if(${upstream_part},${shreve})",
                  upstream_shreve = options['upstream_shreve'],
                  upstream_part = options['upstream_part'],
                  shreve = options['shreve'])

but that isn't working... I don't know whats excaclty the problem....

Are you sure you mean "if(B,C)" not e.g. "if(B,B,C)". The two argument
form returns the second argument if the first argument is nonzero and
zero if the the first argument is zero, i.e. "if(B,C,0)".

Other than that, the above should work; if it doesn't, that suggests a
bug somewhere (most of the Python code was written for 7.0 and
back-ported to 6.5; sometimes the code requires changes to work in
6.x).

Also, if your variable names exactly match the keys in the options
dictionary, you can just pass the entire dictionary using Python's
"**" syntax, i.e.:

grass.mapcalc("$upstream_shreve = if(${upstream_part},${shreve})", **options)

Any extra options will be ignored.

--
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

4

I'm trying to use ximgview for the first time but when I use this code:

export GRASS_PNGFILE=map.bmp
d.erase
ximgview map.bmp &
d.rast mde
d.vect countries type=boundary
export GRASS_PNG_MAPPED=TRUE

d.vect erases the mde raster map (the same with type=centroids). It
draws what it is supposed to draw but erasing (covering?) the previous
layer.

I made a mistake or is ximgview just for simple stuff?

Is there any possibility of keeping d.mon in grass 7.0 to support old
scripts?

Thanks

El mié, 02-02-2011 a las 09:56 +0000, Glynn Clements escribió:

Patrick_schirmer wrote:

> Does someone know how translate previous display commands into GRASS70,
> i.e. integrate a py-script that is called
> "d.mon x1=start" (or similar) into GRASS70 doing these command:
>
> #####start display in GRASS7.0
> export GRASS_PNGFILE=map.bmp
> d.erase
> ximgview map.bmp &
> export GRASS_PNG_MAPPED=TRUE

It can't be done that way. A program (or script) cannot change the
environment of its parent (e.g. the shell). This is why "export" has
to be a shell built-in rather than a program.

You could write a *shell* script which is "source"d rather than
executed, or you could write a script which sets the environment
variables then spawns a new shell.

But the only way that a "d.mon" program could be made to work would be
to change the drivers to read the settings from $GISRC rather than the
environment.

However, environment variables are more convenient for scripts and the
GUI. Checking for environment variables first then $GISRC second would
satisfy both use cases, but could be confusing for the user, as the
$GISRC settings would be ignored if one of the environment variables
was set.

5

alonso wrote:

I'm trying to use ximgview for the first time but when I use this code:

export GRASS_PNGFILE=map.bmp
d.erase
ximgview map.bmp &
d.rast mde
d.vect countries type=boundary
export GRASS_PNG_MAPPED=TRUE

d.vect erases the mde raster map (the same with type=centroids). It
draws what it is supposed to draw but erasing (covering?) the previous
layer.

I made a mistake or is ximgview just for simple stuff?

You need to set GRASS_PNG_READ=TRUE, but only once the image file
already exists, e.g.:

  export GRASS_PNGFILE=map.bmp
  export GRASS_PNG_MAPPED=TRUE
  d.erase
  export GRASS_PNG_READ=TRUE
  ximgview map.bmp &
  d.rast mde
  d.vect countries type=boundary
  ...

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

6

Ok. It works fine now thanks a lot.

Anyway this approach hasn't the flexibility and possibilities that
monitors had, like zoom, frames, queries (specially queries to several
maps with d.what.*).

I understand that python interface is an improvement, but I'd be happy
having d.mon in the all way in GRASS 7.

best wishes

Paco Alonso

El mar, 12-04-2011 a las 21:49 +0100, Glynn Clements escribió:

alonso wrote:

> I'm trying to use ximgview for the first time but when I use this code:
>
> export GRASS_PNGFILE=map.bmp
> d.erase
> ximgview map.bmp &
> d.rast mde
> d.vect countries type=boundary
> export GRASS_PNG_MAPPED=TRUE
>
> d.vect erases the mde raster map (the same with type=centroids). It
> draws what it is supposed to draw but erasing (covering?) the previous
> layer.
>
> I made a mistake or is ximgview just for simple stuff?

You need to set GRASS_PNG_READ=TRUE, but only once the image file
already exists, e.g.:

  export GRASS_PNGFILE=map.bmp
  export GRASS_PNG_MAPPED=TRUE
  d.erase
  export GRASS_PNG_READ=TRUE
  ximgview map.bmp &
  d.rast mde
  d.vect countries type=boundary
  ...

7

alonso wrote:

I understand that python interface is an improvement, but I'd be happy
having d.mon in the all way in GRASS 7.

as a debug tool and gift to power-users, what I have imagined in the past
is some sort of "wxgui-lite": command-line driven, based on wxPy, with no
status line at bottom or menu at top. Something less spartan than wximgview
but not by much. probably calling it "gui" at all would be wrong, and
maybe wximgview could be slightly enhanced? (not sure if that's wanted)

Only a right-click menu to change the cursor between pan, marquee zoom
(those two cursor modes also enable mouse wheel zooming), query {coord|
avail rast, vect sub menus}, measure, dump screenshot to png, and tick
box to put XOR'd background yellow 12pt "x,y" mouse position coords in
the bottom right.

It would watch for changes in the mapset's WIND file and auto-update on
change, like 'qiv --watch'. (ximgview's percent= takes a bit of tuning if
using remotely over a slow 'ssh -X' connection, so --watch is nicer there,
but not sure if that's portable [can `make` do that on MS Win?]).

just an idea to keep the semi-minimalist Fluxbox/XFCE crowd happy.

Hamish

8

Hi,

2011/4/13 alonso <alonsarp@um.es>:

Ok. It works fine now thanks a lot.

Anyway this approach hasn't the flexibility and possibilities that
monitors had, like zoom, frames, queries (specially queries to several
maps with d.what.*).

I understand that python interface is an improvement, but I'd be happy
having d.mon in the all way in GRASS 7.

there is no plan to introduce again Xmonitors, it would be a bad
decision. What is plan is to implement original d.mon in similar way
for wxGUI map displays. So you will start new wxGUI display window by
`d.mon wx0`, add new raster map by `d.rast elevation`. Zooming or
panning is implement in wxGUI displays.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa