[GRASS-user] Region definition in Grass 6.1 (and 6.1 cvs)

[Glynn Clements]

Michael Barton wrote:

> >>> - region matches display (cut region at nearest cell boundary)
> >> 
> >> Region for non-display modules matches the region set for rendering a map to
> >> the current display. This is pretty much how things work in normal mode if
> >> run from the GIS Manager menus.
> > 
> > The problem is that, when you have multiple displays, it's likely to
> > be unclear as to which one determines the region used by non-display
> > commands.
> 
> The fundamental issue is that in GRASS, the region setting constrains the
> actions of modules that modify maps. This is different from at least some
> other programs and can be either very useful or an annoyance (depending on
> the time of day). The 2nd issue is that zooming/unzooming and panning in the
> display requires changing the region extents.
> 
> Given that the display is setting the extents but should not set the
> resolution (see below), the question is whether interactively
> zooming/panning in the display should also set the region extents for
> non-display commands or not. Having an option to turn this on or off is
> desirable, but seems difficult to code given the underlying architecture (or
> at least seems difficult on a Monday morning).

Coding isn't really a problem. The main problem is deciding how it
should work from the user's perspective, especially the issue of
*which* display determines the region for other commands.

> > Also, requiring the region to match one of the displays is problematic
> > if you are working at a relatively high resolution. You don't want to
> > have to force the displays to operate at that resolution simply
> > because you cannot make a command use a resolution which doesn't match
> > a display.
> 
> For best performance, the display resolution should work the way Cedric set
> up explore mode--that is it should always produce a constant number of
> pixels that is proportional to the display size.
> 
> But this should have nothing to do with the resolution used by GIS modules
> that perform actions on maps. This resolution should be set explicitly by
> the user.

Maybe.

If you're generating maps at a particularly low resolution (e.g. 
because the process is relatively slow and you want to perform many
"trial" operations to find suitable parameters), you may well want to
view the source map(s) as they will actually be used.

OTOH, if you're displaying the maps at a significant reduction (i.e. 
the map size in cells is much larger than the display), one of the two
scalings (raster -> region, region -> display) should probably be 1:1,
with all of the scaling performed by the other transformation
(probably the raster -> region conversion, as that reduces the size of
the data earlier than using the region -> display conversion).

> Again, coding this so that the display changes the region resolution for
> itself but for nothing else seems complicated to implement, though
> desirable.

Changing the region (both bounds and resolution) for the display
without affecting other commands is trivial enough. Using the
display's region with a different resolution is more complex, mainly
due to alignment issues if the display resolution isn't an integer
multiple of the resolution to be used for commands.

Also, it would be desirable to allow the size of the canvas (and thus
the rendered images) to differ from the size of its window.

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