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

[Russell Nelson]

Roger Miller writes:
 > 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.

You're assuming that a problem that affects new users once will not
cause them to give up in disgust and throw money at ESRI.  I hope it's 
not your intention that GRASS be "the software you run when you can't
afford anything good."

 > Most of what's below is not suited to the developers' list.

Sure it is.  You made grass work the way it does (or at least have
have not fixed these problems), and you need to hear about them.

 > > 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.

Exactly.  Reasonable defaults.

 > > 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.

Let me explain the problem that I'm trying to solve.  I want to reduce 
the learning curve.  I want early rewards.  I want a new grass user to 
be able to see her map by running three commands: "grass5, r.in.png
image, d.rast".  Apparently, if you actually set up a reasonable
region, and then import a map, it's not *in* the region you just
specified.

 > > 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.

Remember: you understand how GRASS works now.  A newbie understands
how grass *should* work.  A user makes a mental model of how things
work, and they quickly get frustrated if that mental model never
results in useful predictions.  And then they become a former user,
and GRASS hater.  "Yeah, I tried GRASS, fiddled with it for a couple
of hours, but never got it to do anything."

Running GRASS as it currently works results in newbie frustration, for 
no good reason that I can understand.

 > > 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'm asking for reasonable defaults.  If I load a georeferenced map
(e.g. GeoTIFF) into an empty location, is there any reason not to set
the default region to that of the map?  Maybe it's simply that
"location" is badly named, and should be instead called "dataset" or
"project" or "collection"?

See, here's what I was thinking when I first ran GRASS:

Hmmm...  It's asking me for a location.  That must mean the geographic
location of the data I'm going to load.  But I don't know that!  Why
can't it figure that out for me??  I can try guessing, but what if it
truncates the data that I load, so that it discards data outside the
box?  I don't want that.  I'd better set the box to be a little bigger
than what I need (herein insert a description of my difficulty in
setting the lat/lon region).

Okay, great, now I'm running GRASS!  Now what?  Oh, I see, I have to
import a raster.  r.in., hmmmm, there's no r.in.jpeg, although there's 
r.in.ppm and r.in.png.  No matter, I'll just save my jpeg in png
format and load it with r.in.png.

Hmmm....  It refuses to load the image, something about "Illegal
latitude for North".  At this point, I was completely hosed.  Couldn't 
do a damn thing.  I purged my grass database, rm -rf ~/.grassrc5, and
started again.

Not sure what I did differently, but I got an image loaded.
Unfortunately, the image was loaded at 0,0 and I was looking much
farther northwest than that when I ran d.rast on the image.

Does it help for you to understand what I was thinking, and what I was 
expecting?

 > 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.

My suggestion was based on a wrong conception of what the default
region was going to accomplish.  In fact, you don't need to set the
default region *at all* in order to load a map into a location.  And
setting it to anything but zero was the wrong thing to do.  I would
have had more success if I'd simply left it alone and accepted the
defaults.

Where did I go wrong?  It was in thinking that the default region was
somehow associated with setting a boundary box on any and all data
that I loaded.  If I'm the only person who was misled, then fine, it's
just a fluke.  Otherwise, *something* needs to be changed.  Perhaps
it's something as simple as NOT asking for the default region, but
instead setting it to the current defaults of (0,0,1,1), and
automagically setting it when a user loads the first map (or even
suggesting "You might want to set the default region using g.region
blahblahblah".)  It might be causing d.rast to emit a warning when the 
raster and the region do not overlap.

 > > 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?

I have no idea (newbie, remember?).  I'm not sure what happens now.
It might discard any data that doesn't overlap the current region.  Or 
it might load the data, but when you run d.rast on it, never show it
to you.

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

What would break to use a region of 0,0,1,1, and simply not ask for
a default region?

 > 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. 

tagged arguments are fine when the arguments are optional.  If the
arguments are required, they may as well be positional.  Seems to me
like the parser could easily be extended so that a command could tell
the parser "my first positional argument goes to input=, and my second 
goes to output=".

I could go into this whole rant about how people are used to
expressing ideas in sequence, but if you disagreed with me, read it
unable you would be to.

 > >     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?

When a newbie first loads a raster, that's the only raster he's going
to have.  That is not a "fairly bizarre instance".  From the newbie's
point of view, it's normal (everything a newbie does is normal).

 > Personally I think there's a lot more important issues.

I *did* point out that I'm not unwilling to submit patches.

 > > 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.
 > 
 > Absolutely not.  I think you misunderstand the role and structure of the 
 > GRASS database.

No, I'm not that kind of a newbie.  I'm a newbie who is completely
familiar with Unix, and databases and data structures.  I can see that 
different data is stored in different files.  What I'm asking for is
the ability to use the Unix shell's ability to expand a filename found 
in the current directory.  As long as we're going to have to type into 
a shell, we may as well work *with* the shell instead of against it.

 > 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.

What tool do I use to enter the raster name
This-is-the-historical-map-of-the-Potsam-Quad? without having to type
the whole thing?

 > 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.

Your impression is wrong.  I have 60 maps I want to splice together
and georeference.  I'm going to start with only one of them.  So far
I'm having no luck with the *real* data, because r.in.png complains
that I have too many colors when I ask for 16, and my X server
mysteriously crashes on an illegal instruction when I ask for 24.

I've tried loading a georeferenced tiff, and r.in.tiff segfaults, so I
tried loading a png which is created from just a portion of that tiff,
and W00 H00 I actually can see it (after wiping grassdata and
.grassrc5, and starting afresh).

Now, I'm the Vice President of the Open Source Initiative, so
drop-kicking GRASS and switching to something proprietary and usable
is not an option.  GRASS is my only option, so I've got to stick it
out.  That doesn't mean I'm going to suffer in silence or suffer
alone, though.

-- 
-russ nelson              http://russnelson.com | Okay, enough is enough!
Crynwr sells support for free software  | PGPok | Can we PLEASE all stop
521 Pleasant Valley Rd. | +1 315 268 1925 voice | using insecure Microsoft
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | email products???