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:
<br><br>- region defined manually (nothing ever ever changes this no matter what is displayed on the screen)<br>- region matches display (cut region at nearest cell boundary)<br>- region matches display, dynamically redefine resolution to match set number of rows and columns
<br><br>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.
<br><br>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.
<br><br><br><div><span class="gmail_quote">On 8/18/06, <b class="gmail_sendername">Glynn Clements</b> <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Michael Barton wrote:<br><br>> >> 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>><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><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 <<a href="mailto:glynn@gclements.plus.com">
glynn@gclements.plus.com</a>><br><br>_______________________________________________<br>grassuser mailing list<br><a href="mailto:grassuser@grass.itc.it">grassuser@grass.itc.it</a><br><a href="http://grass.itc.it/mailman/listinfo/grassuser">
http://grass.itc.it/mailman/listinfo/grassuser</a><br></blockquote></div><br><br clear="all"><br>-- <br>David Finlayson