let's standardize sites

[Mark P. Line]

On 25 Jan 1994, Glenn C. Kroeger wrote:

> Mark Line writes:
> >For what it's worth, my vote would be for as little hard-wired into GRASS
> >site processing as possible, plus really clean interworking with the
> >platforms that were designed to handle application-dependent sets of
> >(non-spatial) attributes: RIM if necessary, awk if possible, for instance. 
> 
> Mark is right about the GRASS code, there is no call to make it process
> this extra information. However, the need to develop robust data formats is
> a separate question.

I don't see how data formats to be supported strategically by GRASS are a
_separate_ question from that of what to include in GRASS code. It seems
that the former is a part of the latter.

> If GRASS and OpenGIS are going to prosper they must accomodate the way that
> new users use computers!  While you and I can use awk, such tools are
> becoming anachronistic. My students want to suck the data into Wingz or
> Excel and run macros, not learn the ins and outs of awk syntax. More
> importantly, managers want to use data this way, and they sure as hell
> aren't going to screw around with awk.

I don't see what is anachronistic about awk & Co. It is a formal language,
which many users have been indoctrinated into abhoring. I also know by
whom (their corporate headquarters is near here). It is a simple fact of
user interface design that not every conceivable processing functionality
is equally amenable to a so-called "intuitive", point-and-click user
interface. Serious researchers, and students who want to become serious
researchers, should not be limited in their tools to those that are
amenable to easy integration with MS-Windows and Excel (for example).

That doesn't mean I'm against spreadsheets, of course. It's just one more
tool, about as old as awk & Co., and no more anachronistic.

> If one looks at the trend in commercial GIS, it is towards ease of use that
> simulates common desktop (read Windows and Mac) software and better and
> better interaction with common desktop productivity software.

That is probably correct. However, there are those of us who value
processing functionality over integration with one particular (relatively
computer-illiterate) user sector's idea of "ease of use". If you can find
a Windows-like user interface paradigm that matches the bandwidth of what
is doable in GRASS + shell + awk & Co., then tell us. I'll develop a GUI
for free using your idea. I'm not holding my breath, though. Until that
time, I see no point in limiting the useful functionality of GRASS &
associated tools to what seems reasonable to the less computer-literate.

Please do not misinterpret my statement as saying "GRASS is for computer
experts", which I don't believe or condone at all. What I'm saying is that
GRASS + shell + awk & co. has an *enormous* functionality bandwidth, and
that the bandwidth of the user interface to this functionality has to
match it, or else functionality is effectively lost.

> If you want to know what people want, look at what they spend money on. The
> problem with FREE (as opposed to OPEN) software is that it lacks this form
> of directed input.

Bad analogy, I think. Judging from market share, people want McDonald's
hamburgers. That doesn't mean that McDonald's hamburgers are the epitome
of haute cuisine, if you get my drift. There are those of us who prefer to
eat better than McDonald's hamburgers, even if it means we have to do our
own cooking sometimes.

> If we, the GRASS community, don't allow and encourage GRASS to grow in this
> direction as well, it will become a backwater and ultimately stagnate. I
> don't want to see this happen, the strengths of OpenGIS are too many to
> allow this. But that means we have to address ease of use issues. The
> attitude "let them use awk" is exactly what GRASS doesn't need.

GRASS should _grow_ in any direction that is useful to its users. What you
propose, though, seems to be putting a low-bandwidth user interface on top
of a high-bandwidth processing sytem, because certain (potential) users
are only prepared to use a low-bandwidth user interface. This line of
reasoning is incorrect, I think: if a particular user needs to have a
low-bandwidth user interface, then that user has no business using a
high-bandwidth processing system like GRASS, since he can't control it.

-- Mark

--------------------------------------------------------------------
Mark P. Line                       Phone: +1-206-733-6040
Open Pathways                        Fax: +1-206-733-6040
P.O. Box F                         Email: markline at henson.cc.wwu.edu
Bellingham, WA 98227-0296
--------------------------------------------------------------------