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

[Roger Miller]

On Thursday 02 May 2002 09:18, Russell Nelson wrote:

> Okay, I will cheerfully label the following as a completely naive
> opinion on how grass *should* work from the point of a newbie.  If I
> am saying something totally wrong or stupid, please say so.  If you
> want to say "Hey, great ideas, Russ.  Here's your CVS login, go for
> it!", that's a legitimate response as well.

I agree completely that this is a naive opinion.  That doesn't mean it's 
wrong.  I went through some of this when I first started and from the number 
of very similar comments we get I have to conclude that pretty much every new 
user runs into the same difficulty.

Our main problem is how to fix the start-up problems without losing or 
over-complicating functions that may be difficult to set up, but which are 
important, easy-to-use tools for a more experienced user.  Our other problem 
is how we should prioritize a problem that effects new users once and not 
again when we have other problems to work out that effect all users all the 
time.

Most of what's below is not suited to the developers' list.  This is 
cross-posted to the user's list and non-programmng follow up should be posted 
there.

> First, its ridiculous to have to set the region just to run grass.
> Completely unnecessary.  Maybe some commands need to have a default
> region.  If so, they can say "Please run g.region first".

A lot (most ?) commands need a region, so this suggestion would probably 
cause the majority of the GRASS modules to bail out.  It would be annoying in 
no time.  Just the same, there should be some reasonable default behavior 
when a region is not set.  I think that's something that can be fixed.

> Second, images that are not georeferenced should *always* be imported
> into an x,y projection, and d.rast should show the entire image by
> default.

You *always* have the option of importing non-georeferenced images into an XY 
location, but that isn't generally necessary or useful.  I don't see much 
reason to force that behavior.  Moreover, it wouldn't be reasonable to force 
that behavior on imported vector or sites files.  GRASS doesn't have much of 
a way to determine when those files are georeferenced and when they're not.  
I think we can reasonably expect the user to provide that information.

> Third, when a map is georeferenced, *then* it goes into a location.

Georeferencing a bitmap should move it to a different database location?  
Regardless of how it becomes georeferenced?   I think again that this is the 
responsibility of the user.

> Third, no, wait, Fourth, the scope of a location should be determined
> by the data stored in that location.  Since all such data is
> georeferenced (see "Third"), the bounds of the data set the scope of
> the location, not vice-versa.

I'm not sure what you mean by "scope of the location."  I think you mean the 
default region, but you might mean some kind of automatically set current 
region.  As near as I can tell, I think that would be a bad idea.  Let me 
give an example.

I have a database location named "Panhandle" in an albers equal area 
projection.  The location includes one file imported from the national atlas 
of the US.  With your suggestion this location would have a "scope" that 
covered the entire continental US.  The purpose of the location is to allow 
me to work with a ground water model centered over the northern Texas 
panhandle area so that I can work over details of the model within an area 
that is no bigger than 15 miles by 25 miles.

Anything that resets my region to the continental US would be annoying at 
best.  As is, I have a region defined for my local area, another region 
defined (with a different resolution) for a larger sub-regional area and 
another region (the default region) that covers the whole area of the model.  
I have no need for any kind of "scope" that covers the continental US.

I think a lot of us work with data from variable scales and locations, so a 
lot of us probably would react the same way.

> In other words, grass should be more approachable.  I should be able
> to go to a GIS clearinghouse (such as the New York State one at
> Cornell), download a georeferenced map, run grass5 (for the first
> time!) and be able to do this and have it work:

That's an achievable goal.  I'd like to see it happen and as Helena pointed 
out it is actually possible to do that now with r.in.gdal.  But we have 
problems.   You only need that capability once per project.  So what happens 
if you import a map that doesn't fit the current region?  Does GRASS create a 
new database location?  A new mapset in the current location?  You could end 
up with an entirely different database location for each map you import.  I 
don't think you want to do that, and it certainly isn't the way that GRASS 
was intended to work.

I don't think we want default behavior that would create a new location or 
even a new mapset for every imported map that doesn't agree with the current 
location or region.  It might be reasonable to provide an option to create a 
new location or region based on the information in the map, but the header 
information may not contain all the necessary data (information on the 
projection, in particular).  Some other source of information will generally 
be needed.

> grass5
>
>     yeah, I know, grass currently insists upon setting up a database.
>     While that's arguably a good idea, so are defaults.  If ~/.grassrc
>     does not exist, then create ~/grass.  If that directory already
>     exists, then create ~/grass1 (etc).  And put that into ~/.grassrc
>     as the default directory.
>
>     Yeah, I know, grass currently insists on wanting to know the
>     default region.  See "First".

GRASS does need to have and use a more comprehensive set of reasonable 
defaults.

> r.in.tiff /tmp/O44075.tiff
>
>     yeah, I know, r.in.tiff expects tagged arguments rather than
>     positional.  Why should I have to type input=foo and output=bar,
>     when 99.99 times out of a hundred, the first argument is *always*
>     the input and the second argument is *always* the output?

I think all of the user modules use the same parser.  That has good side 
effects (simple programming, consistent interface) and some bad side effects 
(not much individual flexibility).  In general the first argument is *not* 
input and the second argument is *not* output. 

>     Yeah, I know, r.in.tiff expects an output name as well.  What's
>     wrong with
>
> d.rast
>
>     Yeah, I know, d.rast wants a filename.  If there's only one raster
>     filename, why bother prompting for it?

We should program in an exception for the fairly bizarre instance of a mapset 
with only one raster file?  Personally I think there's a lot more important 
issues.

>     Yeah, I know, d.rast knows that I should run d.mon first.  In the
>     usual case, given the X11 window system, shouldn't d.rast simply start
>     up x0 if it's not running already?  Reasonable defaults make the
>     newbie's life much easier.

That sounds workable.

> And another thing: when I go into a location, grass should change my
> current directory to be that of the location.  And all of my datasets
> should have an empty filename there, e.g. r.O44075.  That way, I can
> say "d.rast r.<tab>", and bash's filename completion makes my life
> easier.  Yeah, I know, that's not something a newbie would think of.
> I'm so used to filename completion, though, that not having it is
> painful.

Absolutely not.  I think you misunderstand the role and structure of the 
GRASS database.   Ideally once the database is set up you should never have 
to worry about where the database is or how it's structured.  GRASS provides 
tools to access and manage the data base and those are what you should be 
using, not shell tricks and not unix utilities.

That said, I think the GRASS database structure needs a little work.

> Yes, I know that GIS is complicated, and there's a lot to know.  But
> at least you can do your best to have a learning curve that goes like

I get the impression that you entered into GRASS without a project, only a 
simple example problem -- an unreferenced tiff file that you wanted to view.  
That would make startup a little more difficult, because if that's your goal 
then all of the GIS details seem annoying and unnecessary.  If you actually 
have a project, with data that needs to be stored and served then GRASS' 
setup requirements are more understandable and the learning curve might look 
a little different.


Roger Miller