[GRASS5] D.zoom behavior

GRASS GIS GRASS GIS developer
1

Glynn,

Thanks. Your email fixed the problem :wink:

I don't know what it was, but the changes to node_type are working fine now.
Possibly updating other execution commands to the new procedures did it.

I've run into another issue that is quite different. Not a huge problem but
interesting. It relates to the discussion over the behavior of d.zoom.

D.zoom operates in an xterm, going directly to using the left,center,right
mouse buttons to control a zoom in the current monitor, if you start it with
d.zoom [mapname] or run d.zoom without an argument if a map has been
displayed in the current monitor.

D.zoom goes to the tcltk gui if you run it without arguments and there is no
map displayed.

So far so good.

However, if you display a map with d.his or d.rgb, d.zoom with no argument
behaves as if there was no map displayed. That is, it goes to the tcltk gui.
I can't find any other display commands that behave this way.

All the rest (d.rast and d.vect, or based on these 2 commands) seem to
behave like the first way I described.

This is minor, but a bit odd. As you were talking about the behavior of
d.zoom a couple weeks back, I thought it might be worth reporting this.

Michael

On 9/11/04 4:05 PM, "Glynn Clements" <glynn.clements@virgin.net> wrote:

Michael Barton wrote:

I just discovered that your changes to proc Dm:node_type (in d.m.tcl) don't
work on my Mac. You suggested changes to this procedure to make it work with
earlier versions of tcltk. However, it doesn't work with tcltk 8.4 for x11
on my Mac. That is, it doesn't seem to return the correct item type. This
only seems to show up in when you do a query.

So, you are saying that the new version works normally, but not for
queries?

Note that Dm::node_type is called from a lot of places. If it returns
the wrong result, it won't just be queries which don't work. E.g. the
structure of the lower pane is determined by the result from
Dm::node_type.

It needs to know what type of
map you are querying to send you to to raster.tcl (with d.what.rast) or
vector.tcl (with d.what.vect).

I've been making a few other changes, like using your term, run, execute,
spawn procedures in the various subroutines called by d.m.tcl. This all
seems to work fine.

For the moment, I've rolled back to the original version of Dm:node_type. If
you can figure out what is problematic here, I'll put it in.

Not having a Mac, there's no way that I can figure out why the updated
version doesn't work on a Mac. Can you try adding some "puts" commands
to Dm::node_type, to see what's actually happening?

Also, can you send me your d.m.tcl file (a version which uses
"string match ..." which doesn't work for you)?

____________________
C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

2

Michael Barton wrote:

D.zoom operates in an xterm, going directly to using the left,center,right
mouse buttons to control a zoom in the current monitor, if you start it with
d.zoom [mapname] or run d.zoom without an argument if a map has been
displayed in the current monitor.

D.zoom goes to the tcltk gui if you run it without arguments and there is no
map displayed.

So far so good.

However, if you display a map with d.his or d.rgb, d.zoom with no argument
behaves as if there was no map displayed. That is, it goes to the tcltk gui.
I can't find any other display commands that behave this way.

All the rest (d.rast and d.vect, or based on these 2 commands) seem to
behave like the first way I described.

This is minor, but a bit odd. As you were talking about the behavior of
d.zoom a couple weeks back, I thought it might be worth reporting this.

This is essentially the problem which I was describing.

At startup, before it calls G_parser(), it connects to the monitor and
reads the lists of raster and vector maps which are current displayed
on the monitor. It then sets the "answers" fields of the rast= and
vector= options to these lists. Also, if no maps are displayed on the
monitor, it sets the "required" field of the rast= option, and
automatically activates the the -j flag).

It doesn't work in conjunction with d.rgb or d.his because these don't
register the maps with D_add_to_cell_list(). [This is arguably
correct; these programs don't directly display the rasters which they
read; they display data which is generated from them. Zooming the
individual rasters wouldn't produce the correct result.]

There are a number of problems here:

1. The argument-handling logic used by d.zoom is convoluted. And
wrong. E.g. if no maps are displayed, you have to specify rast=
(vector= doesn't suffice). If any vector maps are displayed, the
vector= option is initialised to this list, and "d.zoom rast=..." will
display the vector maps as well.

2. It doesn't recognise anything which isn't either a raster or vector
map, according to D_add_to_{cell,dig}_list(), e.g. displays generated
by d.rgb, d.his. However, if the -j flag is used, it will redraw these
maps by re-executing the commands which were set using
D_add_to_list().

Personally, I think that all of the argument-manipulation logic should
go. The rast= and vector= options should be initialised to NULL, and
the -j switch should be off. After G_parser has been called, it should
check that at least one of rast=, vector= or -j was given, and
generate an error if none are given. If -j was given, it should redraw
the display using the command list; otherwise it should draw the
specified raster and/or vector maps.

IOW, to obtain the existing behaviour when no arguments are given but
maps are displayed, you should have to use "d.zoom -j".

BTW, G_parser() also needs a --no-ui switch. The idea is that
tcltkgrass would always use this switch when running a command from a
dialog generated by --tcltk. If options are required, but the user
failed to specify any using the dialog, the program should generate an
error rather than displaying another dialog.

--
Glynn Clements <glynn.clements@virgin.net>

3

Glynn,

I agree with you overall. But in regards to #2 below, I would go even
further. D.zoom is described as an interactive way to change the region
extents. IMHO, this is what it should be. It should not be necessary to have
anything displayed in order to change the region extents in this way (It is
not necessary to have anything displayed in order to run g.region). IOW, you
should be able to open a monitor, display nothing, create a zoom box using
d.zoom, and change the region extents accordingly. Any *subsequently*
displayed map would use those extents. If anything *is* displayed, the
region change would be followed by a screen redraw of course.

There should be no error generated. d.zoom should always change the region
extents, but should only do a redraw if there is something to redraw.
(Although perhaps it does no harm to do a redraw even if there is nothing to
redraw?). How difficult would it be to have d.zoom work in this way?

Michael

On 9/12/04 6:19 AM, "Glynn Clements" <glynn.clements@virgin.net> wrote:

Michael Barton wrote:

D.zoom operates in an xterm, going directly to using the left,center,right
mouse buttons to control a zoom in the current monitor, if you start it with
d.zoom [mapname] or run d.zoom without an argument if a map has been
displayed in the current monitor.

D.zoom goes to the tcltk gui if you run it without arguments and there is no
map displayed.

So far so good.

However, if you display a map with d.his or d.rgb, d.zoom with no argument
behaves as if there was no map displayed. That is, it goes to the tcltk gui.
I can't find any other display commands that behave this way.

All the rest (d.rast and d.vect, or based on these 2 commands) seem to
behave like the first way I described.

This is minor, but a bit odd. As you were talking about the behavior of
d.zoom a couple weeks back, I thought it might be worth reporting this.

This is essentially the problem which I was describing.

At startup, before it calls G_parser(), it connects to the monitor and
reads the lists of raster and vector maps which are current displayed
on the monitor. It then sets the "answers" fields of the rast= and
vector= options to these lists. Also, if no maps are displayed on the
monitor, it sets the "required" field of the rast= option, and
automatically activates the the -j flag).

It doesn't work in conjunction with d.rgb or d.his because these don't
register the maps with D_add_to_cell_list(). [This is arguably
correct; these programs don't directly display the rasters which they
read; they display data which is generated from them. Zooming the
individual rasters wouldn't produce the correct result.]

There are a number of problems here:

1. The argument-handling logic used by d.zoom is convoluted. And
wrong. E.g. if no maps are displayed, you have to specify rast=
(vector= doesn't suffice). If any vector maps are displayed, the
vector= option is initialised to this list, and "d.zoom rast=..." will
display the vector maps as well.

2. It doesn't recognise anything which isn't either a raster or vector
map, according to D_add_to_{cell,dig}_list(), e.g. displays generated
by d.rgb, d.his. However, if the -j flag is used, it will redraw these
maps by re-executing the commands which were set using
D_add_to_list().

Personally, I think that all of the argument-manipulation logic should
go. The rast= and vector= options should be initialised to NULL, and
the -j switch should be off. After G_parser has been called, it should
check that at least one of rast=, vector= or -j was given, and
generate an error if none are given. If -j was given, it should redraw
the display using the command list; otherwise it should draw the
specified raster and/or vector maps.

IOW, to obtain the existing behaviour when no arguments are given but
maps are displayed, you should have to use "d.zoom -j".

BTW, G_parser() also needs a --no-ui switch. The idea is that
tcltkgrass would always use this switch when running a command from a
dialog generated by --tcltk. If options are required, but the user
failed to specify any using the dialog, the program should generate an
error rather than displaying another dialog.

____________________
C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

4

Michael Barton wrote:

I agree with you overall. But in regards to #2 below, I would go even
further. D.zoom is described as an interactive way to change the region
extents. IMHO, this is what it should be. It should not be necessary to have
anything displayed in order to change the region extents in this way (It is
not necessary to have anything displayed in order to run g.region). IOW, you
should be able to open a monitor, display nothing, create a zoom box using
d.zoom, and change the region extents accordingly. Any *subsequently*
displayed map would use those extents. If anything *is* displayed, the
region change would be followed by a screen redraw of course.

That would certainly work, although I suspect that it's likely to be
pointless. I can't imagine anyone wanting to set the region by marking
a rectangle on a blank window. When you use d.zoom, you invariably
select the corners by visual reference to what is displayed in the
window.

There should be no error generated. d.zoom should always change the region
extents, but should only do a redraw if there is something to redraw.
(Although perhaps it does no harm to do a redraw even if there is nothing to
redraw?). How difficult would it be to have d.zoom work in this way?

Trivial; it's just cleaning up existing functionality.

Actually, I'm wondering if there's even any point to having the rast=
and vector= options and the -j flag. It seems to me that it may as
well always zoom whatever is on the monitor (i.e. -j behaviour). If
you want to zoom a specific map, run d.rast/d.vect first.

--
Glynn Clements <glynn.clements@virgin.net>