[GRASS-user] "Automatic" redraw of map display in 6.4 when underlying raster changes?

GRASS GRASS user
1

Hi

I am looking for a way to automatically redraw a map if the underlying raster map is changing.

Background: I am running a spatial simulation, and would like to see open a few graphics monitors (or similar)to follow how certain maps are changing over time. Is there a way of doing this?

At the moment I am using d.mon and d.rast but these are static and not refresh when the underlying raster is changing. TO make it even more interesting: I am doing some steps of the simulation in R and only write the results back to the GRASS database.

If it is not possible in 6.x, will it be possible in 7?

Any ideas welcome,

Rainer

–
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax (F): +33 - (0)9 58 10 27 44

Fax (D): +49 - (0)3 21 21 25 22 44

email: Rainer@krugs.de

Skype: RMkrug

2

Rainer M Krug wrote:

I am looking for a way to automatically redraw a map if the underlying
raster map is changing.

Background: I am running a spatial simulation, and would like to see open a
few graphics monitors (or similar)to follow how certain maps are changing
over time. Is there a way of doing this?

At the moment I am using d.mon and d.rast but these are static and not
refresh when the underlying raster is changing. TO make it even more
interesting: I am doing some steps of the simulation in R and only write the
results back to the GRASS database.

If it is not possible in 6.x, will it be possible in 7?

GRASS doesn't have any mechanism to obtain notifications when maps
change. You will need to have your code provide such notifications.

Monitoring the filesystem is likely to be unreliable, as there's no
straightforward way to determine when files are in a consistent state.

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

3

On Wed, Oct 5, 2011 at 5:10 PM, Rainer M Krug <r.m.krug@gmail.com> wrote:

Hi

I am looking for a way to automatically redraw a map if the underlying
raster map is changing.

Background: I am running a spatial simulation, and would like to see open a
few graphics monitors (or similar)to follow how certain maps are changing
over time. Is there a way of doing this?

At the moment I am using d.mon and d.rast but these are static and not
refresh when the underlying raster is changing. TO make it even more
interesting: I am doing some steps of the simulation in R and only write the
results back to the GRASS database.

You could try d.erase; d.rast every time a raster has changed. That
should refresh the raster. If d.mon and d.rast are currently called in
a script and not manually, inserting d.erase at appropriate places
before d.rast could help.

Markus M

4

On Wed, Oct 5, 2011 at 11:31 PM, Glynn Clements <glynn@gclements.plus.com> wrote:

Rainer M Krug wrote:

I am looking for a way to automatically redraw a map if the underlying
raster map is changing.

Background: I am running a spatial simulation, and would like to see open a
few graphics monitors (or similar)to follow how certain maps are changing
over time. Is there a way of doing this?

At the moment I am using d.mon and d.rast but these are static and not
refresh when the underlying raster is changing. TO make it even more
interesting: I am doing some steps of the simulation in R and only write the
results back to the GRASS database.

If it is not possible in 6.x, will it be possible in 7?

GRASS doesn’t have any mechanism to obtain notifications when maps
change. You will need to have your code provide such notifications.

Thanks - I thought that much, but I wanted to make sure.
As I am scripting GRASS from R, this should not be to difficult - just add the notifications to the functions which can modify grass layers(execGRASS, writeRAST6, writeVECT6) and then react on these notifications.

Monitoring the filesystem is likely to be unreliable, as there’s no
straightforward way to determine when files are in a consistent state.

Thanks for pointing this out and saving me some work - otherwise I might have chosen that path…

Cheers,

Rainer

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

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

–
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax (F): +33 - (0)9 58 10 27 44

Fax (D): +49 - (0)3 21 21 25 22 44

email: Rainer@krugs.de

Skype: RMkrug

5

On Thu, Oct 6, 2011 at 8:19 AM, Markus Metz <markus.metz.giswork@googlemail.com> wrote:

On Wed, Oct 5, 2011 at 5:10 PM, Rainer M Krug <r.m.krug@gmail.com> wrote:

Hi

I am looking for a way to automatically redraw a map if the underlying
raster map is changing.

Background: I am running a spatial simulation, and would like to see open a
few graphics monitors (or similar)to follow how certain maps are changing
over time. Is there a way of doing this?

At the moment I am using d.mon and d.rast but these are static and not
refresh when the underlying raster is changing. TO make it even more
interesting: I am doing some steps of the simulation in R and only write the
results back to the GRASS database.

You could try d.erase; d.rast every time a raster has changed. That
should refresh the raster. If d.mon and d.rast are currently called in
a script and not manually, inserting d.erase at appropriate places
before d.rast could help.

That is true - haven’t looked at d.erase yet

Thanks,

Rainer

Markus M

–
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax (F): +33 - (0)9 58 10 27 44

Fax (D): +49 - (0)3 21 21 25 22 44

email: Rainer@krugs.de

Skype: RMkrug

6

On Thu, Oct 6, 2011 at 9:21 AM, Rainer M Krug <r.m.krug@gmail.com> wrote:

On Thu, Oct 6, 2011 at 8:19 AM, Markus Metz

...

You could try d.erase; d.rast every time a raster has changed. That
should refresh the raster. If d.mon and d.rast are currently called in
a script and not manually, inserting d.erase at appropriate places
before d.rast could help.

That is true - haven't looked at d.erase yet

d.redraw is even nicer...

Markus

7

Hi,

2011/10/6 Markus Metz <markus.metz.giswork@googlemail.com>:

I am looking for a way to automatically redraw a map if the underlying
raster map is changing.

wxGUI is doing something similar checking commands which were finished [1].

Martin

[1] http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/gui_modules/menuform.py#L631

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

8

On Thu, Oct 6, 2011 at 11:25 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Thu, Oct 6, 2011 at 9:21 AM, Rainer M Krug <r.m.krug@gmail.com> wrote:

On Thu, Oct 6, 2011 at 8:19 AM, Markus Metz

…

You could try d.erase; d.rast every time a raster has changed. That
should refresh the raster. If d.mon and d.rast are currently called in
a script and not manually, inserting d.erase at appropriate places
before d.rast could help.

That is true - haven’t looked at d.erase yet

d.redraw is even nicer…

Agreed - and I guess a bit faster…

Thanks.

Markus

–
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax (F): +33 - (0)9 58 10 27 44

Fax (D): +49 - (0)3 21 21 25 22 44

email: Rainer@krugs.de

Skype: RMkrug

9

On Thu, Oct 6, 2011 at 11:36 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2011/10/6 Markus Metz <markus.metz.giswork@googlemail.com>:

I am looking for a way to automatically redraw a map if the underlying
raster map is changing.

wxGUI is doing something similar checking commands which were finished [1].

Martin

[1] http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/gui_modules/menuform.py#L631

Interesting - but I guess it will not be to easy to use this event.

It would be really nice, if one could define a script (in a environment variable) which will be always executed if this event occurs. This could then easily be used to instruct an external viewer to e.g. redraw.

Rainer

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

–
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax (F): +33 - (0)9 58 10 27 44

Fax (D): +49 - (0)3 21 21 25 22 44

email: Rainer@krugs.de

Skype: RMkrug

10

2011/10/6 Rainer M Krug <r.m.krug@gmail.com>:

It would be really nice, if one could define a script (in a environment
variable) which will be always executed if this event occurs. This could
then easily be used to instruct an external viewer to e.g. redraw.

possible solution would be to modify file defined by PROMPT_COMMAND.

* check if any monitor is running `d.mon -p`
* check command and monitor content (if output map is drawn in the
monitor - d.mon -c), run `d.redraw` if desired

It would be probably quite easy to implement in G7.

Martin

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

11

On Thu, Oct 6, 2011 at 12:09 PM, Martin Landa <landa.martin@gmail.com> wrote:

2011/10/6 Rainer M Krug <r.m.krug@gmail.com>:

It would be really nice, if one could define a script (in a environment
variable) which will be always executed if this event occurs. This could
then easily be used to instruct an external viewer to e.g. redraw.

possible solution would be to modify file defined by PROMPT_COMMAND.

  • check if any monitor is running d.mon -p
  • check command and monitor content (if output map is drawn in the
    monitor - d.mon -c), run d.redraw if desired

Sounds very interesting.

It would be probably quite easy to implement in G7.

I just looked at grass 6.4 and it is working there as well - but I guess that $PROMT_COMMAND is not executed when I script GRASS from e.g. R.

I’ll look at it,

Rainer

Martin

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

–
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax (F): +33 - (0)9 58 10 27 44

Fax (D): +49 - (0)3 21 21 25 22 44

email: Rainer@krugs.de

Skype: RMkrug

12

Rainer:

It would be really nice, if one could define a script
(in a environment variable) which will be always executed
if this event occurs. This could then easily be used to
instruct an external viewer to e.g. redraw.

what kind of external viewer?

why not just put d.redraw inside the loop?

see also grass7 addons d.mon script (not the new fancy one in
trunk) for `qiv` autoupdate when the composited display file
changes.

Hamish

13

On Thu, Oct 6, 2011 at 2:16 PM, Hamish <hamish_b@yahoo.com> wrote:

Rainer:

It would be really nice, if one could define a script
(in a environment variable) which will be always executed
if this event occurs. This could then easily be used to
instruct an external viewer to e.g. redraw.

what kind of external viewer?

e.g. a GRASS instance, as the simulation is not locking the actual mapset.

why not just put d.redraw inside the loop?

Because that would take time, and would not always be needed.
I am running my simulations (written in R and using GRASS) for testing and debugging purposes on a laptop, and if they are working, I send them, for final simulation to a hpc cluster. The reason why I would like to have an external viewer is to simply “look into the simulation” while I am debugging, and not having to change anything when I send it to the cluster. OK - a debug option is included, but I am reluctant to put the viewer into the simulation.

Effectively, I was thinking about e.g. a GRASS instance which is displaying the layer “aliens” in the workspace ASM and automatically updates when the layer is updated from the simulation. So I could even look into a simulation running on the cluster, without having to interfere with the simulation.

see also grass7 addons d.mon script (not the new fancy one in
trunk) for qiv autoupdate when the composited display file
changes.

I will - thanks. Could you point me to a website?

Cheers,

Rainer

Hamish

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

–
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax (F): +33 - (0)9 58 10 27 44

Fax (D): +49 - (0)3 21 21 25 22 44

email: Rainer@krugs.de

Skype: RMkrug

14

Rainer M Krug wrote:

> Monitoring the filesystem is likely to be unreliable, as there's no
> straightforward way to determine when files are in a consistent state.

Thanks for pointing this out and saving me some work - otherwise I might
have chosen that path...

Also, doing this at the library level would have similar issues,
albeit less severe.

E.g. when a module finishes writing the actual raster data (i.e.
G_close_cell() or Rast_close()), often the next thing it does is to
write metadata (categories, colour table, history). There is no
specific "event" which signals that the output raster is "complete".

Generating notifications on "close" operations would ensure that
individual files are consistent, but that doesn't mean that the raster
as a whole is consistent.

This is something that has been discussed in the past, but without
resolution. Improvements in this area are certainly desirable; e.g.
reading a map in another mapset relies upon luck, as there is no
mechanism to ensure that the owner of that mapset isn't modifying the
map in question at the time. Unfortunately, the issues are complex,
making it hard to decide what should be done, let alone doing it.

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

15

On Fri, Oct 7, 2011 at 5:22 AM, Glynn Clements <glynn@gclements.plus.com> wrote:

Rainer M Krug wrote:

Monitoring the filesystem is likely to be unreliable, as there’s no
straightforward way to determine when files are in a consistent state.

Thanks for pointing this out and saving me some work - otherwise I might
have chosen that path…

Also, doing this at the library level would have similar issues,
albeit less severe.

E.g. when a module finishes writing the actual raster data (i.e.
G_close_cell() or Rast_close()), often the next thing it does is to
write metadata (categories, colour table, history). There is no
specific “event” which signals that the output raster is “complete”.

Generating notifications on “close” operations would ensure that
individual files are consistent, but that doesn’t mean that the raster
as a whole is consistent.

This is something that has been discussed in the past, but without
resolution. Improvements in this area are certainly desirable; e.g.
reading a map in another mapset relies upon luck, as there is no
mechanism to ensure that the owner of that mapset isn’t modifying the
map in question at the time. Unfortunately, the issues are complex,
making it hard to decide what should be done, let alone doing it.

Thanks a lot for all your input - I think I will put in a mechanism in the model (i.e. writing a file when a layer has been updated ) which I can react on from an external viewer / application.

Cheers,

Rainer

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

–
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax (F): +33 - (0)9 58 10 27 44

Fax (D): +49 - (0)3 21 21 25 22 44

email: Rainer@krugs.de

Skype: RMkrug