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

[Michael Barton]

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton




> From: David Finlayson <david.p.finlayson at gmail.com>
> Date: Sun, 20 Aug 2006 23:56:00 -0700
> To: Glynn Clements <glynn at gclements.plus.com>
> Cc: Michael Barton <michael.barton at asu.edu>, <grassuser at grass.itc.it>
> Subject: Re: [GRASS-user] Region definition in Grass 6.1 (and 6.1 cvs)
> 
> 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)

Do you mean the region for non-display commands? In order to put an image
into a canvas, you need to set the region (or at least a temporary/dynamic
region) and render the map to an image file that can be displayed in the
canvas. If you zoom in or out, you must reset this region and re-render the
map to a new image file for display. So this probably means changing the
region for display does not affect the region settings used by other,
non-display modules.

This is what happens now if you start/run any module from the command line

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

> - region matches display, dynamically redefine resolution to match set number
> of rows and columns

This is what happens in Œexplore mode¹--i.e., when the fill display with map
button is toggled.

> 
> 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 <mailto: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/20060821/bd2eda98/attachment.html