[GRASS5] Re: [Fwd: whinging about GRASS again]

[Mark P. Line]

MB> = Michael Barton
RN> = Russell Nelson


MB> The critical question is can GIS software be made more useable for
MB> people who understand GIS but are not GIS professionals?

There is of course an enormous sub-industry that believes that the answer
is "yes" for at least a significant fraction of GIS functionality. It
generally goes under the buzzword "desktop mapping", and google will find
lots of examples (good, bad and ugly) for anybody who's interested.


MB> The thing that is very annoying about displaying maps in GRASS is the
MB> need to have a display window open prior to displaying a map.
MB> [snip]
MB> Perhaps d.vect and d.rast could be modified to check to see if a window
MB> is open and selected, and open one if not.

Or alternatively, wrap a monolithic GUI around GRASS that is able to run a
GRASS display driver against one of its internal widgets.


MB> However, an interface initially designed commercially to manage
MB> Macintosh files, word processors, and spreadsheets may not be the best
MB> one to manage complex spatial data. Is there a better way?

I've always been partial to a paradigm known as "visual programming". To
construct a dataflow (equivalent to writing a script in non-visual
languages), you drag little boxes onto a canvas, with each box
representing either a data source (like a map), a data sink (like a d.rast
process or an output file) or a data filter (which takes one or more
inputs from other boxes and produces one or more outputs to other boxes).
By dragging arrows from one box to another, you construct a dataflow
between the boxes. Temporary files or pipes for intermediate results can
be handled invisibly by the visual programming engine.

There's a pretty solid example of a visual programming interface for image
processing in Khoros. (It's called something else and is no longer
maintained by Khoral, but google will find it for you.) Googling for
"visual programming" or "visual programming language" will find a lot
about the paradigm itself.

Building an interface like this for GRASS would not be particularly hard,
since most of the hairy coding is already available in libraries.


RN> Fifty, nobody runs GRASS on a shared machine anymore.  They just
RN> don't.

I was wondering about where to find current user demographics and platform
seat statistics for GRASS. Where did you find them?


RN> The concept of GRASS is that you'll
RN> use shell scripts to automate GRASS.  That's silly.  Nobody writes
RN> shell scripts anymore unless they really really have to.

MB> Actually I like to do shell scripts. Perhaps I'm silly, but they work
MB> very well.

Actually, I think the concept of GRASS is *not* that you'll use shell
scripts to automate GRASS. That was the concept in the 1980's, though.
Today, the concept is that you'll use any scripting language you like
(Python, Perl or a shell like bash) to automate GRASS if you want to
automate GRASS.


RN> It would be
RN> much much easier for people to learn enough Python to automate GRASS,
RN> and present GRASS to them as Python modules.

MB> My understanding is that you CAN use GRASS from Python and Perl. So you
MB> have a choice of scripting environments

Right. I don't know why you couldn't use GRASS from Python, perl, PHP,
tcl, Ruby, bash, csh, ksh or sh. (There are more masochistic options as
well.)


RN> It would work like this:
RN>
RN> from grass import r, d, v
RN>
RN> display = d.monitor()
RN> map = r.in.gdal("stlawrencecounty.jpg")
RN> schooldistricts = v.in.ogr("schooldistricts.shp")
RN> display.add(map)
RN> display.add(schooldistricts)
RN>
RN> Then you'd see, on the display, a raster map of St. Lawrence County,
RN> overlayed by a set of vectors which are the school districts.

MB> Uh it is pretty easy to do this using GRASS commands in a shell script,
MB> Perl script, or Python script. The following 5 commands (same number as
MB> you have) in script run from within GRASS would do exactly what you
MB> want.
MB>
MB> r.in.gdal input=stlawrencecounty.jpg output=map
MB> v.in.ogr dsn=[path to schooldistricts.shp] output=schooldistricts/
MB> layer=schooldistricts
MB> d.mon x0
MB> d.rast map
MB> d.vect schooldistricts

If it's user-friendliness for casual, naive users that we want, then
clearly both examples are way too geeky. What you'd need would be
something like this:

"Show me the school districts over an image of St. Lawrence County."

Even this would not be undoable, if the demand was there. But like I said
earlier and Michael has reinforced, GRASS is not really intended for use
by naive users.


MB> A lot of the GRASS structure and organization is there for good
MB> reasons. However, other aspects have just been inherited and may even
MB> be problematic. GRASS can definitely be improved. The changes from
MB> 5.0 to 6.0 are substantial and show the potential of the software.

Absolutely. My first involvement with GRASS was when I ported GRASS 3.0 to
a Xenix/SCO Unix derivative, back when the Earth was still cooling. Over
the last ten years since CERL started its go-slow, the mostly unpaid,
mostly volunteer, mostly overworked GRASS development community has taken
a wooden wall telephone with a hand-cranked generator and added touchtone
functionality and state-of-the art voice quality. (They were also able to
lose the crank.) If there are complaints that it is not small enough to
fit in your shirt pocket and that it doesn't have a little LCD screen for
displaying web pages, then I guess I have to laugh. *shrug*


MB> You are doing the
MB> right thing by offering to help making improvements to the program.
MB> However, you also need to get sufficiently involved in the project and
MB> learn enough GIS in order to suggest changes that can both benefit the
MB> existing user community and encourage new users as well.

In all fairness, I can empathize with Russell even though I might disagree
about specific ideas for changing GRASS. It remains rather more difficult
than necessary for non-GIS-techies to learn enough GIS to use the tools
intelligently. Part of the problem lies in the way some providers of
proprietary GIS attempt to sell their particular user interface paradigm
as the be-all and end-all of GIS. This extends all the way down into
almost any recent GIS textbook you care to look at. When confronted with
something that looks and works differently than the system they trained
on, users are often either confused or convinced that the tool has a
broken user interface.

This is a sign of the continued immaturity of the GIS industry. (Compared
to, say, the relational database industry.) Anything we can do in the
GRASS community to support increasing compliance with OGR-like standards
will have the greatest leverage that I can see towards maturation of the
industry. (Relational database theory was academic vaporware until SQL was
invented and implemented. The enormous intellectual output of the OGC
needs to be turned into software, and then evolved as necessary.)


RN> Finally, I (obviously) think that GRASS needs a lot of changes.  I
RN> realize that every GRASS user has invested substantial time in
RN> learning how to use GRASS.  These users will resist these changes.
RN> Probably most GRASS developers are, in the grand tradition of open
RN> source, first and foremost GRASS users.
RN> So my hopes of having my suggestions accepted are low.

First, GRASS has no grand tradition of open source in the GPL sense of
open source. GRASS used to be in the public domain, and has only
(relatively) recently been placed under open source constraints.

Second, I'm not really sure that most GRASS developers are first and
foremost GRASS users. Most of the developers I'm seeing are spending way
too much time contributing to GRASS development to be considered anything
other than GRASS developers.

Third, I'm not sure what "accepted" means in the last sentence.

If it means that you're concerned that your code might not find its way
into future releases of GRASS, then I think you can rest assured that your
code will be evaluated on its merits. As pointed out earlier, GRASS has
undergone enormous change during its 20-year evolution, most of which has
been since the withdrawal of CERL. So I see no evidence that the current
GRASS development community is unamenable to change of any kind.

If it means that you're concerned that you might not get help coding your
suggested changes, then all I can say is that your ideas would live to
live on the miles-long wish list and be evaluated and prioritized on their
merits, just like all the other ideas on the wish list. The active
developers seem to be spread pretty thin these days.


RN> The last time I made similar
RN> suggestions several years ago, instead of people saying "yes, those
RN> are good suggestions", people said "if that's all you want to do,
RN> GRASS is the wrong package".

One possible reason is that if they had said "yes, those are good
suggestions", they would have been misleading you -- even if the straight
answer is sometimes painful to hear. Presumably, they knew a lot more
about GRASS and GIS than you did, were using that experience to evaluate
your suggestions, and were concerned about precious GRASS development
resources being prioritized for changes that were either not thought-out
yet or not as urgent as other tasks on the queue.


RN> I agree!  If all you want to do is use
RN> GRASS, GRASS is the wrong package.

I think the point is that you should select software that does what you
need, not decide up front that you're going to find a way, no matter how
circuitous, to use software XYZ to meet your needs come Hell, high water
or the tax man.


RN> I think that, for GRASS to achieve a larger user base (and
RN> consequently larger developer base), it needs changes which will piss
RN> off all current grass users.

Does GRASS need a larger user base? You're assuming that the size of the
developer base is a function of the size of the user base. But a quick
check of SourceForge projects would show that it is not: Lots of projects
have more developers than GRASS, with the same number of users as
developers because they're the same people.

GRASS does need more developers, but only to the extent that scalable
processes for collaboration are in place. I doubt that there is a need for
50 people committing to gislib.


RN> GRASS needs to be completely refactored into a completely different
RN> kind of GIS system.

Design it, and look for people to help you code it. What's the problem? If
your system can compete well with the old GRASS, users will flock to yours
in droves. (Swarm to yours in flocks? Drive to yours in trucks?)

If you're proposing that you need to be put in charge of a major redesign
for GRASS 7.0, I don't think I'd hold my breath. :)


RN> I think that, instead
RN> of trying to improve GRASS, it would be better to treat GRASS as the
RN> ruins of a GIS package, to be scavenged over for useful bits of code.
RN> In that manner, GRASS development could continue unimpeded, while the
RN> (insert name here) package could move forward without having to worry
RN> about backwards compatibility with current user training.

It has always been the case that GRASS code has been scavenged for useful
bits, even by the providers of very well-known commercial products.

What is preventing you from starting to design the (insert name here)
package and then building it, using pieces of GRASS or any other open
source code you can find as you see fit?


RN> Am I completely kooky here?  Am I saying anything obviously stupid?

There is nothing stupid at all in what you say. I just think you might be
in the wrong venue. The GRASS development community is not going to stop
developing GRASS, and it's not going to start evolving the design of GRASS
to fit one person's vision -- even if that one person has decades of
experience in GIS.

So rather than trying to stop the moving train here, you might be better
served by founding a SourceForge project for your vision and proceeding
with your plan.


RN> Is there some technical requirement for GRASS to be hard to use that I
RN> fail to comprehend?  Does anybody else feel the same way that I do?

GRASS is hard to use in the same way that MySQL is hard to use. People who
need what MySQL does and can't substitute something else for it will learn
how to use MySQL. People who need what GRASS does and can't substitute
something else for it will learn how to use GRASS.

In any event, I don't think GRASS is hard to use. I think GRASS is hard to
learn, just like every other GIS I've ever seen.


RN> Or have they all left to go work on QGIS and Thuban?  I recognize that
RN> I'm suggesting huge amounts of work, but the reward is large as well.
RN>
RN> Imagine: an open source GIS package that was both capable AND usable!

There used to be tens of thousands of people who used GRASS every day. Has
that dwindled to just a handful while I wasn't looking?


-- Mark

Mark P. Line
Polymathix
San Antonio, TX