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

[David Finlayson]

Region definition and modification is a critical feature of a GIS (probably
THE distinguishing feature of a GIS over a drawing program). However it is
done, it should be simple to understand and there should be no surprises. I
favor an option panel that explicitly controls how regions are modified and
controlled during zooming and panning. Three obvious behaviors are:

- region defined manually (nothing ever ever changes this no matter what is
displayed on the screen)
- region matches display (cut region at nearest cell boundary)
- region matches display, dynamically redefine resolution to match set
number of rows and columns

There should be a check box that decides how the map display/region will be
linked. I like the option of unlinking them entirely (see first option
above) since for very large maps it is impossible to view them on a monitor
in full resolution. We wind up with exported images that downsample the data
and other weird behavior.

We should keep in mind that for survey purposes this feature is extremely
important. Introducing a half cell shift in the data set can introduce error
propagation problems that can render a higher-order survey unacceptable. It
also leads to undesirable aliasing artifacts when the new resolution doesn't
match the old in a sensible manner.


On 8/18/06, Glynn Clements <glynn at gclements.plus.com> wrote:
>
>
> Michael Barton wrote:
>
> > >> but most important: If you zoom in and make some action (for example
> > >> r.to.vect) it will affect ONLY on zoomed fragment
> >
> > IMPORTANT CLARIFICATION: Region zooming in the display generally ONLY
> > affects that display and related tools IN THAT DISPLAY. Most system wide
> > commands (e.g., r.to.vect) will respond to the current setting in the
> WIND
> > file, not the dynamic region setting in the display. This is because we
> are
> > trying to avoid having any particular display affect the system-wide
> WIND
> > file.
> >
> > So if you are running a system-wide command (i.e., not tied to a
> display,
> > its toolbar, or its layer tree) you need to make any desired region
> settings
> > via g.region. It doesn't matter whether g.region is run from the command
> > line or from a menu selection. Alternatively, you can display the region
> you
> > want, then select 'set WIND file from displayed region' from the menu
> button
> > on the display toolbar. If you just zoom interactively to somewhere in
> the
> > display without setting the WIND file, the region-related effects of a
> > system-wide command may not be what you want.
> >
> > We may want to think about this more. Would it be better for a
> system-wide
> > command to affect the region set by g.region or the region displayed in
> a
> > particular display? Which display? How to make sure it is what
> you  want?
>
> The display region certainly shouldn't be stored in the WIND file
> (unless the user specifically selects that option). Whether or not the
> display region should affect commands run from gis.m is a separate
> issue.
>
> Personally, I would say yes. At least, it definitely needs to be
> possible to run a command from gis.m using a region other than that
> stored in the WIND file. IMHO, the WIND file should be considered a
> "legacy" feature, i.e. retained solely for the purpose of backward
> compatibility.
>
> gis.m should either use the region of the "active" display, or have
> its own concept of "current region" distinct from the WIND file.
> AFAICT, the main issue with the former is choosing a useful notion of
> an "active" display.
>
> If each display window had its own copy of the menu bar, this would be
> simple; the active display for any command run from the menus would be
> the display to which the menu bar was attached.
>
> With a single menu bar, you would need some other way to select the
> active display. Using the WM focus isn't sensible, IMHO; depending
> upon the WM, switching from a display window to the window containing
> the menu bar using e.g. Alt-Tab may result in a different display
> window temporarily obtaining the focus.
>
> OTOH, if you don't use the region from an active display, but have a
> distinct "current region", there should be an option to indicate this
> on the display(s), so that the user isn't surprised when a
> newly-created map has different bounds and/or resoltion to the map
> they were just looking at.
>
> --
> Glynn Clements <glynn at gclements.plus.com>
>
> _______________________________________________
> grassuser mailing list
> grassuser at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grassuser
>



-- 
David Finlayson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20060820/a192b210/attachment.html