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

[Glynn Clements]

Russell Nelson wrote:

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

You can see it in one command: "display image.png" (replace "display"
with your preferred image viewer).

If all that you are going to do is import an image then look at it,
GRASS is the wrong package. GRASS isn't an image viewer, and it isn't
a cartographic package. It's primary function is analysis, and the
"boilerplate" involved in setting-up is trival compared to (intended)
typical usage.

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

The kind of user for which GRASS is likely to be the right solution is
probably not going to evaluate it by "fiddling with it for a couple of
hours".

When it comes to the simplicity-vs-functionality tradeoff, GRASS leans
more heavily towards the functionality end of the scale than is the
norm these days. Sure, simplicity is important; but reliability,
flexibility and functionality are more important, IMHO.

BTW, I'm not suggesting that GRASS is particuarly excellent on those
aspects either. There is a lot of code (comparable to XFree86), much
of which has rough edges, and only around a dozen developers (of
varying degrees of activity). 

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

Yes; the default region is explicitly chosen by the user. Same for the
current region. The only time that the current region is changed is if
the user decides to change it.

If the user wants to change the region to match a particular map, they
can use e.g. "g.region rast=map".

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

Tags have a mnemonic value which positions lack. The case where you
have one "input" and one "output" parameter isn't sufficiently common
to make it a special case. Many commands have either multiple outputs,
multiple inputs, or a choice as to the form of the input.

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

Not necessarily; the user may well have access to pre-existing maps,
installed by their co-workers, tutor, or even the default GRASS
installation.

> That is not a "fairly bizarre instance".  From the newbie's
> point of view, it's normal (everything a newbie does is normal).

"Bizarre" is a subjective term, but having exactly one raster map
available is objectively an unusual situation. Sufficiently unusual
that it's not worth adding special-case code for.

There's also the consistency issue. IMHO, it's preferable for an
option to always be required than for it to almost always be required. 

It's one thing if an option is required or not depending upon other
options (i.e. you have to specify either "foo=..." or "bar=..."), but
introducing a dependency upon environment (e.g. how many raster maps
are in the current location) complicates the general case to simplify
a special case.

>  > Personally I think there's a lot more important issues.
> 
> I *did* point out that I'm not unwilling to submit patches.

The adding code isn't just about whether the code is available. One of
GRASS' main problems is the sheer volume of code present, given the
small number of active developers. Any increase in quantity or
complexity has to be justified.

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

The same problem applies to anything which accepts "names" as input. 
Having tab completion would be nice, but it isn't the one-and-only
factor in determining the structure of the database.

-- 
Glynn Clements <glynn.clements at virgin.net>