[GRASS5] Initial window state

GRASS GRASS developer
1

Folks,

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.

That's most of the work, but there are two additional changes that I know of
that need to be made. The code for mon.select calls D_setup(). That call
needs to be removed, because D_setup reads the active window and would
otherwise cause the initialization flag to be set before any map is
displayed. D.rast and d.vect call D_setup themselves, so removing the call
from mon.select doesn't change their behavior. D.sites does not call D_setup
and I found it necessary to add a call to D_setup to the main program in
d.sites. I also removed several statements from the d.sites main code that
appear to at least partially duplicate the function of D_setup.

I have not tested d.vect.* or any of the image modules. I expect that if
necessary they will take the same simple changes that worked on d.rast,
d.vect and d.sites. If changes are not made then those modules probably
won't be broken, they will just continue to work as they do now.

So far I've found the capability to be useful for more than just beginners.
It may be possible to invoke that initialization behavior more frequently
(like each time a monitor is started) and to save on the times it is
necessary to run g.region.

Roger Miller

2

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@virgin.net>

3

Thanks for responding, Glynn.

Glynn Clements wrote:

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

This is a start-up problem that has (to my knowledge) only been reported
for the display.

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.

With the changes I described the region is still initialized as it is now
based on the contents of the WIND file, but the initialization flag is unset.
Any module that accesses the region setting (which I think covers most user
modules) will set the initialization flag. Once the flag is set GRASS will
work exactly as it does now.

The region is set from the file header data only if the region data have
not been accessed before a file is displayed. In most cases that means
that the region is set from the file data only if the map display is the
first operation performed in a session.

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.

The behavior *should* be nullified in that case. If any analysis is
performed using the initial region then the display modules should not
automatically reset the region from the file header. If the region were
reset it could produce misleading results. The analysis would have been
performed for a region different from the region that is displayed.

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.

This helps solve a widespread complaint. I don't think that fixing
complaints is the wrong way to go.

GRASS has a UI and that UI that requires frequent, repetitive execution of
several user commands. I would hope to reduce the amount of annoying and
cumbersome repetition. None of this is "magic". It's an attempt to
create a more evolved system behavior.

I agree that this isn't the best way to do things. Unless GRASS has a
persistent central manager then the system behavior has to be built up
bit by bit in a fairly disorganized fashion. I don't think that's a good
way to do it, and that's why I use a manager program. The manager
centralizes the system and makes a lot of further developments look
relatively easy.

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

I get blank screen behavior in a number of different ways, but that
behavior is a fairly minor problem to an experienced user. I think the
main case where the blank screen result is a problem is when a new user is
forced to set the map region when they first start GRASS. Most people
probably don't know the area they need to cover and they don't have any basis
for understanding the significance of the initial region settings. Often the
user's initial window settings are incorrect or just useless and the first
map they try to display produces a blank screen. When that happens
GRASS looks broken; in fact one could say that GRASS *is* broken because
it lets that happen.

If the region can be set from a map, then the startup procedure can be
rewritten so that a new user doesn't have to provide useful settings.
Reasonable defaults can be used instead.

Roger Miller

4

On Friday 19 July 2002 01:02 am, Roger Miller wrote:

I get blank screen behavior in a number of different ways, but that
behavior is a fairly minor problem to an experienced user. I think the
main case where the blank screen result is a problem is when a new user is
forced to set the map region when they first start GRASS. Most people
probably don't know the area they need to cover and they don't have any
basis for understanding the significance of the initial region settings.
Often the user's initial window settings are incorrect or just useless and
the first map they try to display produces a blank screen. When that
happens GRASS looks broken; in fact one could say that GRASS *is* broken
because it lets that happen.

What about warning:

d.rast map=x

WARNING: Map 'x' is outside the current region, try 'g.region rast=x'

Radim

5

On Friday 19 July 2002 01:41, Radim Blazek wrote:

What about warning:
> d.rast map=x

WARNING: Map 'x' is outside the current region, try 'g.region rast=x'

Radim,

I think that's at least a step in the right direction and probably a good
addition to d.rast, d.vect.* and d.sites.

Even though I do like this idea, I would prefer to go the next step. By
itself this idea identifies a problem without actually solving it. Solving
the problem for the specific case of initialization would require very little
more work. In fact, I think that adding just the initialization check might
take less code and I'm sure it would impose less startup overhead.

I think users -- new users in particular -- would probably prefer to have
GRASS fix the problem itself rather than requiring them to perform a second
command then repeating their first command just to get an image displayed.

Roger Miller

6

On Fri, Jul 19, 2002 at 05:29:24AM -0600, Roger Miller wrote:

On Friday 19 July 2002 01:41, Radim Blazek wrote:

> What about warning:
> > d.rast map=x
>
> WARNING: Map 'x' is outside the current region, try 'g.region rast=x'

Radim,

I think that's at least a step in the right direction and probably a good
addition to d.rast, d.vect.* and d.sites.

Even though I do like this idea, I would prefer to go the next step. By
itself this idea identifies a problem without actually solving it. Solving
the problem for the specific case of initialization would require very little
more work. In fact, I think that adding just the initialization check might
take less code and I'm sure it would impose less startup overhead.

I think users -- new users in particular -- would probably prefer to have
GRASS fix the problem itself rather than requiring them to perform a second
command then repeating their first command just to get an image displayed.

As a user, I found GRASS very difficult to get going with, and one of the reasons was the region settings. However, I also found that GRASS was the only program that forced me to think about regions and projections, and I like that. Before, I used ArcView and created maps without ever thinking about the (sometimes quite important) issue of projection. Therefore, I find the way GRASS does things quite important on a pedagogical level, and would find it regrettable if GRASS let the user ignore some of the most fundamental questions in cartography.

But I do sympathize with the idea of not "scaring" new users away. In that sense I like Radim's idea.

Moritz

7

On Sunday 21 July 2002 06:19, Moritz Lennert wrote:

Moritz Lennert wrote:

As a user, I found GRASS very difficult to get going with, and one of the
reasons was the region settings. However, I also found that GRASS was the
only program that forced me to think about regions and projections, and I
like that. Before, I used ArcView and created maps without ever thinking
about the (sometimes quite important) issue of projection. Therefore, I
find the way GRASS does things quite important on a pedagogical level, and
would find it regrettable if GRASS let the user ignore some of the most
fundamental questions in cartography.

I don't think that either Radim's proposal or mine would get around the user
having to think through the projection. I don't propose creating a new
location or mapset from the header data and Radim didn't mention a check
against the projection, though that would be possible.

Roger Miller