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

[Carl Worth]

On May 2, Helena Mitasova wrote:
 > Russell has a good point of view for the very first time user

I agree. I've wrestled with several of the exact same problems.

I still dislike everything involved with creating a new
location/region before starting in with the data.

 > with the improvements in r.in.gdal. (Russ use r.in.gdal instead of
 > r.in.tiff).

Oh? Does r.in.gdal do everything that r.in.riff and r.in.jpg do? If
so, why don't we drop some duplicate code away, (eg. leave r.in.tiff
merely as a symlink to r.in.gdal or some such)?

There's certainly no use in having two different implementations of
the same functionality.

 > For example the issue of adapting the region to displayed map (as Carl has
 > mentioned
 > before) would drive you crazy if you are doing some modeling using a larger
 > number of
 > maps with different extent and resolutions and you need to preview those
 > maps, so that kind of behavior
 > should be optional and not default

Actually Helena, perhaps I was misunderstood.

I do not think that display commands should change the region. (There
is a problem that Russ and I both hit as new users doing d.rast and
not being able to figure out why nothing appeared. Maybe if a display
command is given a map which is entirely outside the current region a
useful message could be generated informing the user what happened and
what could be done to fix it?).

What I have proposed is disassociating monitor regions from the
concept of a "current region".

Each monitor must necessarily have a region associated with it,
(describing the extents of what actually appears within the
monitor). Currently, the monitor's region is the same as "The
Region". This is broken IMHO as it makes it almost impossible to
successfully go back and forth between multiple monitors viewing
different areas.

So, what I think we need is per-monitor regions.

Additionally, I think that wherever possible commands should be made
to operate without any specific region established by the user. This
would eliminate the need for the user to even specify a region in
order to start using GRASS.

Then, if a particular command must have a region that it cannot
compute from its input, then that command could request that the user
specify a region and explain how to do it.

-Carl

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