<HTML>
<HEAD>
<TITLE>Re: [GRASS-user] Region definition in Grass 6.1 (and 6.1 cvs)</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
__________________________________________<BR>
Michael Barton, Professor of Anthropology<BR>
School of Human Evolution & Social Change <BR>
Center for Social Dynamics & Complexity<BR>
Arizona State University<BR>
<BR>
phone: 480-965-6213<BR>
fax: 480-965-7671<BR>
www: <a href="http://www.public.asu.edu/~cmbarton">http://www.public.asu.edu/~cmbarton</a> <BR>
<BR>
<BR>
<BR>
<BR>
<FONT COLOR="#0000FF">> From: David Finlayson <david.p.finlayson@gmail.com><BR>
> Date: Sun, 20 Aug 2006 23:56:00 -0700<BR>
> To: Glynn Clements <glynn@gclements.plus.com><BR>
> Cc: Michael Barton <michael.barton@asu.edu>, <grassuser@grass.itc.it><BR>
> Subject: Re: [GRASS-user] Region definition in Grass 6.1 (and 6.1 cvs)<BR>
> <BR>
> Region definition and modification is a critical feature of a GIS (probably <BR>
> THE distinguishing feature of a GIS over a drawing program). However it is <BR>
> done, it should be simple to understand and there should be no surprises. I <BR>
> favor an option panel that explicitly controls how regions are modified and <BR>
> controlled during zooming and panning. Three obvious behaviors are: <BR>
> <BR>
> - region defined manually (nothing ever ever changes this no matter what is <BR>
> displayed on the screen)<BR>
<BR>
</FONT>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.<BR>
<BR>
This is what happens now if you start/run any module from the command line<BR>
<FONT COLOR="#0000FF"><BR>
> - region matches display (cut region at nearest cell boundary)<BR>
<BR>
</FONT>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.<BR>
<FONT COLOR="#0000FF"><BR>
> - region matches display, dynamically redefine resolution to match set number <BR>
> of rows and columns <BR>
<BR>
</FONT>This is what happens in ‘explore mode’--i.e., when the fill display with map button is toggled.<BR>
<FONT COLOR="#0000FF"><BR>
> <BR>
> There should be a check box that decides how the map display/region will be <BR>
> linked. I like the option of unlinking them entirely (see first option above) <BR>
> since for very large maps it is impossible to view them on a monitor in full <BR>
> resolution. We wind up with exported images that downsample the data and other <BR>
> weird behavior. <BR>
> <BR>
> We should keep in mind that for survey purposes this feature is extremely <BR>
> important. Introducing a half cell shift in the data set can introduce error <BR>
> propagation problems that can render a higher-order survey unacceptable. It <BR>
> also leads to undesirable aliasing artifacts when the new resolution doesn't <BR>
> match the old in a sensible manner. <BR>
> <BR>
> <BR>
> On 8/18/06, Glynn Clements <glynn@gclements.plus.com> wrote:<BR>
</FONT><FONT COLOR="#008000">>> <BR>
>> Michael Barton wrote:<BR>
>> <BR>
</FONT><FONT COLOR="#800080">>>>>> but most important: If you zoom in and make some action (for example<BR>
>>>>> r.to.vect) it will affect ONLY on zoomed fragment<BR>
</FONT><FONT COLOR="#FF0000">>>> <BR>
>>> IMPORTANT CLARIFICATION: Region zooming in the display generally ONLY <BR>
>>> affects that display and related tools IN THAT DISPLAY. Most system wide<BR>
>>> commands (e.g., r.to.vect) will respond to the current setting in the WIND<BR>
>>> file, not the dynamic region setting in the display. This is because we are <BR>
>>> trying to avoid having any particular display affect the system-wide WIND<BR>
>>> file.<BR>
>>> <BR>
>>> So if you are running a system-wide command (i.e., not tied to a display,<BR>
>>> its toolbar, or its layer tree) you need to make any desired region settings <BR>
>>> via g.region. It doesn't matter whether g.region is run from the command<BR>
>>> line or from a menu selection. Alternatively, you can display the region you<BR>
>>> want, then select 'set WIND file from displayed region' from the menu button <BR>
>>> on the display toolbar. If you just zoom interactively to somewhere in the<BR>
>>> display without setting the WIND file, the region-related effects of a<BR>
>>> system-wide command may not be what you want.<BR>
>>> <BR>
>>> We may want to think about this more. Would it be better for a system-wide<BR>
>>> command to affect the region set by g.region or the region displayed in a<BR>
>>> particular display? Which display? How to make sure it is what you want? <BR>
</FONT><FONT COLOR="#008000">>> <BR>
>> The display region certainly shouldn't be stored in the WIND file<BR>
>> (unless the user specifically selects that option). Whether or not the<BR>
>> display region should affect commands run from gis.m is a separate<BR>
>> issue.<BR>
>> <BR>
>> Personally, I would say yes. At least, it definitely needs to be<BR>
>> possible to run a command from gis.m using a region other than that<BR>
>> stored in the WIND file. IMHO, the WIND file should be considered a<BR>
>> "legacy" feature, i.e. retained solely for the purpose of backward<BR>
>> compatibility.<BR>
>> <BR>
>> gis.m should either use the region of the "active" display, or have<BR>
>> its own concept of "current region" distinct from the WIND file. <BR>
>> AFAICT, the main issue with the former is choosing a useful notion of<BR>
>> an "active" display.<BR>
>> <BR>
>> If each display window had its own copy of the menu bar, this would be<BR>
>> simple; the active display for any command run from the menus would be <BR>
>> the display to which the menu bar was attached.<BR>
>> <BR>
>> With a single menu bar, you would need some other way to select the<BR>
>> active display. Using the WM focus isn't sensible, IMHO; depending<BR>
>> upon the WM, switching from a display window to the window containing <BR>
>> the menu bar using e.g. Alt-Tab may result in a different display<BR>
>> window temporarily obtaining the focus.<BR>
>> <BR>
>> OTOH, if you don't use the region from an active display, but have a<BR>
>> distinct "current region", there should be an option to indicate this <BR>
>> on the display(s), so that the user isn't surprised when a<BR>
>> newly-created map has different bounds and/or resoltion to the map<BR>
>> they were just looking at.<BR>
>> <BR>
>> --<BR>
>> Glynn Clements < glynn@gclements.plus.com <a href="mailto:glynn@gclements.plus.com"><mailto:glynn@gclements.plus.com></a> ><BR>
>> <BR>
>> _______________________________________________<BR>
>> grassuser mailing list<BR>
>> grassuser@grass.itc.it<BR>
>> <a href="http://grass.itc.it/mailman/listinfo/grassuser">http://grass.itc.it/mailman/listinfo/grassuser</a><BR>
</FONT><FONT COLOR="#0000FF">> <BR>
> <BR>
> <BR>
> -- <BR>
> David Finlayson<BR>
</FONT></SPAN></FONT>
</BODY>
</HTML>