[GRASS5] A naive opinion on how grass *should* work

[Carl Worth]

On May 3, Glynn Clements wrote:
 > > 1) don't ask for a default region.  If a program needs one, it should
 > >    say "Please set the region that this program should write to using g.region".
 > 
 > But *most* programs need a region. The region concept is so pervasive
 > that it just isn't worth complicating the majority of programs to
 > allow for the possibility of there not being a current region. 
 > Especially when all that it would achieve would be to allow newbies to
 > defer learning about the region for a minute or two.

I don't agree with this.

Most vector modules have no use whatsoever for a region.

Most raster modules do use the region, but in most cases, it would be
suitable for these modules to just operate based on the input provided
to them, (extents determined by the union of maps, and resolution
determined by maximum).

I know that experienced GRASS users will say, "But that would bloat my
data! I want to be able to specify a default region to control what
happens!". To which I say, yes, set the region as you want it. But
there really is no reason that I can see that a user *must* set a
default region for the majority of GRASS commands.

Similarly, there are some modules that are currently discarding data
based on the default region. This caused me no end of confusion as a
new GRASS user. I wrestled with the same problem Russell has. "How do
I make suer my region is big enough? When I import data, will it clip
my data according to my region? I know my data is already
georeferenced, but I don't know the details of the file format to be
able to dig into it manually and figure out its extents in advance to
create a region -- besides, that's the computer's job and not
mine. So, what do I do? I'd better make the region huge and the
resolution extremely precise just to be safe..."

This chain of thought led me to do things that were much less optimal
in terms of storage/processing power required than if I could just
GRASS to deal with extents/resolutions based on what it is given and
not destroy information unless I specifically requested that, (eg. by
setting a default "clip_region" or some such).

Also, the current sharing of one region for separate purposes,
(eg. determining raster generation resolution, determining monitor
viewing parameters, clipping the output of modules), is extremely
problematic. I've zoomed in on a monitor to see something in more
detail, then been baffled when I couldn't get s.out.ascii to give any
output when it had been working previously.

Again, the principles should be:

	Provide sane defaults for everything.

	Don't require the user to provide more information than is
	truly necessary to get the job done. The job might not be done
	in the most optimal fashion, but rely on the sane defaults,
	(see above), to still be able to function with less user
	input.

	Never destroy information without the user explicitly
	requesting it.

-Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                 cworth at east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203		  703-812-3725