[GRASS5] Initial window state

Glynn Clements glynn.clements at virgin.net
Thu Jul 18 12:22:30 EDT 2002


Roger Miller wrote:

> New GRASS users often report problems the first time the try to display a map 
> because the map either does not fall in the window region or the window 
> region is much larger than the active window.   I think this is an 
> acknowledged problem, but one that doesn't have a simple solution.
> 
> I've fixed this problem in my own installation.  My installation uses a 
> management program to coordinate some resources, but I think a similar 
> approach could be used to provide the same solution without using the manager.
> 
> The idea is that if the user takes no action to read or change the window 
> region before a map is displayed then the active window is defined by the 
> header data for the map that is displayed.
> 
> The process requires a persistent global flag that is initialized to 0 when a 
> session starts and is toggled to 1 when the active region has been read or 
> written by the user.  The gis environment is the only mechanism I can think 
> of that provides such a persistent global variable in a standard GRASS 
> installation.  If so, then the variable will have to be written to $GISRC 
> each time it is initialized or changed.
> 
> The active region is only read and modified by a small number of library 
> functions, particularly G_get_window and G_put_window.  These would need a 
> one line addition to set the initialization flag to 1 when they are invoked. 
> 
> The functions that display maps (d.rast, d.sites, d.vect.*) need to be 
> modified so that they check the state of the initialization flag.   If the 
> flag is not set then they need to set the active region from the header 
> information for the map they display.  Most of the code necessary for that is 
> already in the source for g.region.

Why only d.* commands? Many commands use the region settings.

If some kind of automatic region setting is necessary, it might be
better to do it from within e.g. G_open_cell_old(). But then, what if
a program queries the region before opening any maps? At least one
program (I forget which) queries the region before even calling
G_parser(), in order to initialise some defaults.

Also, the "region ... read by the user" test would have to be
implemented in g.region etc. Many programs call G_get_region() before
opening maps, so having the test in G_get_region() would nullify the
behaviour.

Personally, I think that this "solution" is going in the wrong
direction. I feel that GRASS needs less "magic" behaviour rather than
more. For interactive use, GRASS *needs* a UI, not lots of "useful for
interactive use" behaviour wedged into various places.

AFAICT, the main situation where users are tripped up by the region
mechanism is in importing rasters which lack georeferencing
information.

In this case, it's arguable that the imported raster should be
positioned within the current region, so that they don't get the
"blank screen" scenario. OTOH, if the map gets imported into almost
the right position, the user might forget to set the boundaries; by
importing to (0,0), it should be obvious that the position isn't
correct.

-- 
Glynn Clements <glynn.clements at virgin.net>



More information about the grass-dev mailing list