[GRASS-dev] Re: [GRASS-CVS] michael: grass6/lib/init gis_set.tcl, 1.24, 1.25

[Michael Tiemann]

Glynn,

I appreciate tremendously all the great work you have been doing for
GRASS, except on one point...

On Tue, 2006-07-18 at 08:25 +0100, Glynn Clements wrote:
> Michael Barton wrote:
> 
> > My concern is not with the terminology per se. There is still a considerable
> > lack of consistency in terminology from one GIS platform to another. GRASS
> > terminology is a little obtuse, but not excessively so. The concepts are
> > pretty straightforward once you learn them.

I fundamentally agree with Michael here.

> > My concern is that the way the startup works, a user must confront and
> > understand GRASS-specific terms--ones used in no other GIS--before he or she
> > can even start the program. People I introduce to GRASS always find that a
> > big stumbling block. This complaint about the startup has come across the
> > user list regularly too.

I find this everywhere I travel, and even find myself stumbling on the
problem.  I don't use GRASS every day, but I want to be able to use it
every now and again without feeling lost and baffled.  When I use it for
a weekend, I think to myself "hey, I've got it!  Now I'm not going to
forget it."  Three months later, I've forgotten it.  This is not only
frustrating to me, but makes it very difficult for me to be a GRASS
ambassador to other business people who would benefit tremendously from
being able to map their business data and ideas to geographic reference
points or regions.

So here is where I disagree with you:

> I'm not so sure.
> 
> I don't believe that GRASS will ever be the kind of package which can
> be used without reading any documentation, and I don't consider this
> to be a defect.

Would you be willing to maintain that opinion as part of a silent
minority?

> A user isn't going to be able to do anything useful with GRASS without
> having first read some documentation, so it doesn't really matter
> whether they have to read the documentation before they get to the
> startup screen or afterwards.

I know a lot of people who are far more motivated to read documentation
when they have evidence that they really are this >< close to attacking
their real problem.  If they have to read a lot of documentation before
getting a map loaded, it requires them to believe (1) they can find the
map they need, (2) they can get it loaded, (3) they can do the analysis
they want.  That's a lot of doubt to carry while reading documentation.

Here's an example.  I have a theory that US democracy (as I define it)
is weakened (as I define it) when US congressional districts are redrawn
(as required by the US constitution) to be less, rather than more,
convex (which is left to the courts and the incumbent representatives in
charge of drawing the maps).  To test this theory, I need to look at
congressional district maps and find which ones are becoming less and
less convex over time.  I have no idea how to do this, but I can start
attacking the problem by selecting stories I believe correlate to
"stronger" or "weaker" democratic activity and attribute that to the
relevant districts, then I can see whether such attribution shows a
visual correlation.  If I start to see a correlation, I can learn how to
order districts based on convexity and then actively search for
validating or repudiating evidence of the theory.

To get going, I type into Google "us congressional district map" and two
clicks later I'm at http://nationalatlas.gov/atlasftp.html#cgd109p .
Now, with GRASS as it is, I'm pretty sure I have the right map
somewhere, but I not at all sure I can begin my demographic analysis of
democracy.  I don't know if GRASS supports these formats.  I don't know
whether I can load these things correctly.  I don't know what kind of
processing I need to do to load or begin working on these maps.  If
GRASS lowered the barrier to all these issues, I'd be much more likely
to engage the documentation to solve my problem at hand.  As it is, I
feel I need to do a lot of work, on an uncertain foundation, just to get
to square one.  I am sure that many people feel this way.

> If a user is looking for a simple package which they can use without
> reading any documentation, it's probably better if they realise sooner
> rather than later that GRASS isn't such a package.

I believe that GRASS /can/ be such a package, or can be the basis of
such a package (such as QGIS).  But don't if we keep convincing
ourselves that GIS should be left to the experts.

M