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

[Glynn Clements]

Carl Worth wrote:

> 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.

One point: virtually all raster (r.*) commands will generate output
maps which correspond to the current region. The main exception is for
importers (r.in.*), which normally use parameters from the imported
file.

> * 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).

This is a specific instance of a more general problem, i.e. that GRASS
doesn't yet have a worthwhile interactive user interface.

> * 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.

All commands which generate raster maps need a region. The region
determines the number of rows/columns in the output map, and the
geographic coordinates of each cell.

For the case where there is a single input map, it would be possible
to use that map's settings, although that would require explicitly
generating a new clipped and/or resampled map if you didn't want to
use the map's settings. And what if there are several input maps? Use
their union? Or intersection? What about the resolution?

It's quite common to either operate on a subset of a map's extent, or
to use a resolution which differs from that of the source map. Having
to explicitly clip and/or resample source maps could be quite a
nuisance.

Operations on vector and site maps don't absolutely require a region,
as the data is inherently finite.

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