[GRASS5] Rethinking regions (was: Re: Grass GUI)

[Carl Worth]

I'd like to open up a discussion about region handling within GRASS.

To give my thoughts a bit of context, I'll include some discussion
from Roger Miller and Glynn Clements below.

In my, (admittedly limited), experience with GRASS, I have found the
default behavior of the region to be confusing and frustrating. It
could be, I'm simply doing things wrong, but this is what my
experience has been. Here are some of the problems I have run into:

* Many modules automatically clip their behavior according to the
  region. This has confused me on several occasions. For example,
  zoomed in on a map in the monitor, my newly imported sites data was
  not appearing with d.sites. I tried a quick s.out.ascii and got no
  output. I spent time trying to figure out why my import had failed,
  (which it had not). I had to examine the actual GRASS database to
  realize that my sites data was there, but that s.out.ascii was
  simply clipping it, (since, as it turned out, I was simply zoomed in
  on the wrong area of my map).

* Several modules do not clip their behavior according to the
  region. It's been hard for me to predict what the behavior of any
  given module will be.

* The monitors do not maintain their own region, but instead share a
  single region. This makes it very hard to use multiple monitors
  effectively. Switching back and forth between monitors requires
  carefully saving and restoring the region between each switch to
  avoid bizarre results, (like drawing multiple layers on top of each
  other at different scales and offsets).

* It's onerous for me as a user to always keep track of what the
  current region is, (this is complicated by the fact that drawing
  commands such as d.zoom can modify the current region, and with
  multiple monitors it is not obvious which one, if any, reflects a
  view of the current region). This is a particular severe problem,
  since if the region is too limited, commands may be clipping and
  throwing away information with the user being aware of
  it. Naturally, unintentional loss of information is never a good
  thing.

Do other people have similar problems or are there good solutions that
I am just missing?

As for a solution, having a region for the monitors makes sense. But,
each monitor should maintain its own region independent of all
others. All commands affecting the monitor should naturally be clipped
by the monitor's region.

Beyond that, is there really a need to have a "current region" for
non-display commands? I would be much more comfortable providing
explicit input if I wanted a command to clip its behavior in one way
or another.

What to other, more experienced, GRASS users and developers think?

-Carl

On Feb 17, Roger Miller wrote:
 > On Sunday 17 February 2002 18:06, Glynn Clements wrote:
 > > >
 > > > The proposal isn't intended to allow multiple simultaneous access to a
 > > > single mapset.  It is intended to allow a single user to use multiple
 > > > monitors to access two or more mapsets within one session, and to use two
 > > > or more different window settings simultaneously, even while working in
 > > > one mapset.
 > >
 > > So, basically you're suggesting that "d.mon select=..." should
 > > automatically switch the region?
 >
 > I'm not suggesting any change to any module.  If the region associated with a 
 > newly selected monitor is different from the region that was associated with 
 > a previously selected monitor then the region will be changed by
 > the manager.
 >
 > > This might be a good idea for interactive sessions which are primarily
 > > used for displaying data, but probably isn't so good for other uses.
 > > Personally, I'm not too keen on the idea of the r.* commands using a
 > > different region depending upon which monitor (and which frame) is
 > > current.
 > 
 > I haven't had any problem with the r.* commands working well.  The biggest 
 > problem I am aware of comes from not always being able to tell which monitor 
 > is selected.

-- 
Carl Worth                                        
USC Information Sciences Institute                 cworth at east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203		  703-812-3725