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

Eric G. Miller egm2 at jps.net
Fri May 3 11:13:47 EDT 2002


On Fri, May 03, 2002 at 10:32:06AM -0400, Russell Nelson wrote:
> Glynn Clements writes:

>  > 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".
> 
> You're right.  They're not even going to play with it for that
> long. They're going to fiddle with it for fifteen minutes, then go get
> a purchase requisition for ARCInfo.  C'mon, get real.  It's not like
> you have no competition.  "GRASS sucks, but it's free" is not a very
> persuasive advertising slogan!
> 
> If you think I'm nutso, I was just talking to someone from the NPS who 
> makes cave drainage maps.  I asked if he used GRASS.  He said "We used 
> to, but now we use ARCInfo".

If you are under the mistaken impression that Arc/Info is easier than
GRASS, you haven't used Arc/Info.  There are a number of similarities
between the two.

There are several reasons most US gov't agencies use Arc/Info, not the
least of which has to do with file format compatibility and politics,
yes politics.  It is the US federal governments policy not to produce
software that competes with commercial software.  GRASS definitely was
in the category of competing with commercial software.

>  > 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.
> 
> Perhaps, then, GRASS is not well organized.  Rather than being a
> single body of code, perhaps it should be a standard, and set of
> programs?  Unix has a well-defined API and many programs run under
> Unix, and can interoperate with each other.

There are, what 200? different modules in GRASS.  Each is basically a
separate command/program that uses a common API (or set of API's).
There is a lot of "environment" or "state" info that programs need to be
able to access.  Anyway, the point is, there are only a few people
working on GRASS, on mostly on a part-time, sporadic basis.  Big changes
by one party to can have a huge impact on everyone else.  The API's for
GRASS have remained mostly stable for several years.

>  > 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.
> 
> Then maybe GRASS should use the GNU Readline library and explicitly
> hand the name completion list to the library?

GRASS doesn't implement it's own shell and commands are separate
programs, so Readline isn't a magic bullet for argument completion.
If you don't know the arguments: "GRASS> command help" prints a
summary.

-- 
Eric G. Miller <egm2 at jps.net>



More information about the grass-dev mailing list