[GRASS5] Re: [whinging about GRASS again]

cmbarton · January 31, 2005, 7:18am

Michael,

Thanks for passing this along. I'll try to respond to these issues. It may
be an opportunity to help explain some things to new users.

Perhaps others who have additional perspectives on GIS may want to add some.

From: Michael Tiemann <tiemann@redhat.com>
Date: Sat, 29 Jan 2005 20:28:02 -0500
To: <michael.barton@asu.edu>
Subject: [Fwd: whinging about GRASS again]

Here it is. I think Russ makes many very clear, cogent points.

M
?
From: Russell Nelson <nelson@crynwr.com>
Date: Sun, 23 Jan 2005 15:37:28 -0500
To: <grass5@grass.itc.it>
Subject: whinging about GRASS again

I tried GRASS 5.7 again. The last time I tried it was almost three
years ago, in May of 2002.

First, a question. Since you are trying the most current version of GRASS
(something I indeed recommend), why are you testing some version of 5.7 when
6.0.0 beta 1 has been released. Depending on which version of 5.7 you are
looking at, this could make an enormous difference in the functionality of
GRASS.

I know somewhat more about GIS than I did
the last time, but apparently not enough. I'm still off-put by the
barriers to entry to GRASS use. I never got over them last time.
GRASS has been unavailable to me the whole time. The problem that I
wanted to solve remains unsolved.

GRASS has been available and being improved in a variety of ways over that
time. However, that won't help limited knowledge of GIS. GRASS has a
reasonably difficult learning curve--less so than some other complex and
powerful analytical tools (e.g., R for statistics)--but it still requires
considerable effort. However, this is the case for the other GIS software
I've used. For that matter, this is the case with GIMP and Photoshop, and
with stat programs including my favorite (because of its UI) JMP. You can
open a file and do stuff with it, but it won't mean anything unless you
understand statistics.

This is not an excuse for a needlessly difficult user experience. Just an
observation that software tools for complex tasks tend to have a
considerable learning curve because it is necessary to learn the concepts
and methods of the analytical system in addition to the nuts and bolts of
using the software. Most people know how to read and write (even if poorly)
so they only need to understand how to work the software for using a word
processor (which has a number of odd UI quirks--from an objective point of
view--that we've simply become used to). Most people do not know anything
about hydrologic modeling, buffering, or projections for spatial data. It is
necessary to learn about these things in addition to simply learning how to
make the software work, making the whole process considerably more
difficult.

IMHO, GRASS is no harder (nor any easier) to learn than other GIS software
I've encountered--including MapInfo, ArcView/ArcGIS, and Idrisi. This
doesn't yet get at the issues you raise below, but needs to be kept in mind.

You still need to be an expert to use GRASS. The GRASS tutorials
don't help, because the problem is not that people can't learn to use
GRASS, the problem is that they shouldn't HAVE TO be an expert to use
it. The GRASS GUI front-ends don't help, because the problems with
GRASS are in the middle of GRASS, not at the edges.

In many respects, I agree with the first and last sentence here. What I said
above speaks directly to that. I'm not sure about the second, however. Can
someone make a word processor that can be used by someone who can neither
read nor write? Or a spreadsheet for someone who does not have an
understanding of math?

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

The trouble with GRASS is that, at its core, its defaults are all
wrong.

First, you have to set a projection BEFORE you load any data. That's
backwards. There should be a default projection into which all loaded
data is projected. If you load a raster UTM map into a lat/lon
projection, then it should be reprojected. Or else perhaps the
initial projection should be "None", and when you load something, that
becomes the default projection.

The second sentence is mistaken and I suspect that most people who use GIS
enough to understand the importance of projections would disagree with the
third sentence--regardless of how appealing and commonsensical it might seem
to people who don't use GIS.

Unlike ArcView, for example, you don't 'set' the projection in GRASS at all.
You can't. Furthermore, as far as I know, there is no projection information
stored internally with GRASS files that can be used to indicate their
projection (neither do ArcView shapefiles). This has some advantages and
disadvantages in terms of file storage and manipulation. Nevertheless, it is
critical that projection parameters for all maps that are going to be used
together be the same. GRASS handles this critical necessity by assuming that
all files within a "location" have the same projection
parameters--parameters that the user sets when a location is created.

So is this a good idea? In MapInfo you must set the projection parameters
for a viewing session and you can set a default set in case you don't want
to set them each time. All maps will be automatically reprojected into this
projection as they are displayed. In ArcView, you can do something similar,
but only if you have physically stored the shape file in latlon format (I
think ArcGIS is a bit more flexible in this regard). In both cases, this
only works for vector files, where the computational overhead to transform
the display is modest. In neither case is this done for raster files
(MapInfo still doesn't really work with raster files like ArcView and
GRASS). If you were to do this with raster files, then hundreds of
thousands--perhaps millions--of pixels would have to to recomputed each time
you displayed the map. ArcView doesn't even do raster reprojection; you need
a third part extension to do this--and it takes a long time. This would make
for extremely slow displays even with today's computers. GRASS is heavily
invested in raster GIS where it excels in modeling and image analysis. There
is a much faster response by not doing this kind of reprojection on the fly.
However, GRASS does do automatic interpolation of raster displays to the
current resolution for better display. A more pertinent question, perhaps,
is whether GRASS files should be redesigned to include a metadata header
that includes projection information. This then could be used by the display
module. However, you still need to know what a map projection is to make
sure that multiple maps overlay correctly. In ArcView (which does not embed
projection information in its files) it is possible to overlay a shapefile
stored in UTM NAD 27 over a shapfile stored in UTM NAD 83 and have no way of
knowing that you are doing it--and suffering unknown errors of 100m or more.
You CAN fool GRASS too, but it is harder.

Second, you have to set a region BEFORE you load any data. That's
just stupid. Who has any idea what your region should be without
first loading the data. Whenever you load data (raster or vector), it
should *set* your region to encompass the entirety of the data that
you load. If you DO NOT want to do that (and I can see where you
might not), THEN you would use an option.

This seems like a very straightforward idea. I noticed that you proposed
submitting some kind of change to the GRASS CVS to implement this. However,
there are some complications here also. First you DON'T have to set the
region before you display data (GRASS and other GIS programs don't "load"
data like spreadsheet, they display GIS files stored on disk. This seems a
small, but critical difference. But see below). When you create a "location"
to store your GIS files, you are asked to define a default region. You don't
HAVE to do this (you can just put 0 and 1 in the extents in fact), but it is
a good idea. This becomes the default 'window on the world' you look through
when you display GIS data. Of course, you can change this window on the
world (i.e., the region) in many ways--specifying coordinates, making it
match the extents of a map (as you suggest), or by drawing a box with a
mouse. When you next open GRASS, it will automatically use the region you
defined in your last session. MapInfo works this way and it is very handy.

ArcView works the way you suggest. It creates a window on the world that
matches the extents of the first map you display. This is occasionally
handy, but usually annoying while you wait for it to display the entire map
before you can zoom back to the place of interest. Of course you can save a
workspace file with the zoom setting you want. You can save a workspace in
GRASS too. So if we were to switch to the ArcView way of displaying to a map
extents initially I could live with it. But I would miss the GRASS/MapInfo
method.

A zoom to extents command (g.region vect=[mapname] or g.region
rast=[mapname]) could be issued in the GIS Manager when the first time a map
is listed for display, but I suspect that most users would find that a real
pain. Perhaps a better compromise would be to add a flag to d.vect and
d.rast to have them optionally set the region to the map extents if the flag
is enabled. Then you could have it both ways.

Third, when you load a dataset (raster or vector), the default should
be to display it. Again, there should be an option to not display,
but the default should be the sensible thing. It's a principle of
user interaction that an action should be followed by a response.
When an action causes no response, people think they did something
wrong. If you flip a light switch, and you see no change, you think
that the light is burned out, or that you flipped the wrong switch, or
that you didn't actually flip the switch.

As I noted before, GRASS does not load a file, it displays it. And when a
display command is issued the file is displayed immediately. D.vect
[mapname] or d.rast [mapname] will display [mapname] in the current display
window. I suspect what you are thinking of is how maps are listed and
displayed in the GIS Manager (formerly Display Manager) interface. Maps can
be listed and arranged to be displayed; displaying the overlaid set of maps
is a separate button. This is very much like ArcView/ArcGIS that "loads"
maps for display with the display checkbox unchecked. When you check it, the
maps are displayed. The GIS Manager could easily redisplay the maps in the
list every time a new map is added. Of course, this slows things down a lot
when you have a complex set of maps to display--and redisplay each time you
add one to the set or rearrange them. On the other hand, it would be nicer
for new users with one or a very few maps. The display check boxes could
probably initiate the display, as they do in ArcView if others want that.
However, it is often nice also to be able to arrange maps before displaying.

The thing that is very annoying about displaying maps in GRASS is the need
to have a display window open prior to displaying a map. As I understand it,
this is a result of using the somewhat dated xdriver for display. The TclTk
GIS Manager gets around this by issuing a d.mon command prior to the display
commands to make sure there is a window to display in. If you use d.vect or
d.rast directly however, you need to have a window open AND selected. It is
nice to have the option of multiple display windows, but having to
explicitly open and select a window before displaying is a pain. Perhaps
d.vect and d.rast could be modified to check to see if a window is open and
selected, and open one if not.

Before going on, I'd like to suggest thinking a bit outside the box. We have
all become accustomed to an interface of windows, mouse activated pull-down
menus, and dialog boxes to set options. In this sense, GRASS is very
standard and this probably helps the learning curve at the very beginning.
By now, everyone using a computer knows what to do with a pull-down menu
even if they don't know what the menu does. However, an interface initially
designed commercially to manage Macintosh files, word processors, and
spreadsheets may not be the best one to manage complex spatial data. Is
there a better way? I don't know. What about something that has thumbnails
of maps that you can stack, rearrange and group? Maybe you could even form
the map thumbnails into equations to do map algebra. Then you could resize
the stacks or equation results dynamically to see it. Maybe you could
resize them in 3 dimensions if you wanted to do something NVIZ like. Anyway
enough for this aside.

Fourth, the data organization of GRASS is completely non-Unixy. It's
incredibly clumsy to try to use ordinary Unix commands to manipulate
GRASS files. Yes, GRASS has its own file manipulations commands, but
that's just wrong.

The GRASS file manipulation commands and very useful for a variety of
reasons, but I agree with your first sentence.

Unix has subdirectories into which a set of
related files can be placed. The GRASS organization of putting
related files into different folders organized by the type of the file
is wrong. It's just wrong. Different file types have different file
extensions. foo.c, foo.o, and foo are how you organize a program; not
src/foo.c, object/foo.o, and executable/foo.

This is the way that vectors ARE organized in GRASS 5.7 on up. Rasters are
still organized the old way. A few months ago, Markus Neteler suggested
re-organizing raster structure along the same lines. I think it is a GREAT
idea. However, many others were reluctant to do so because of backward
compatibility with large investment in GIS data. However, if you think this
is bad, you should see ESRI grid files. At least with GRASS you can actually
move the files using OS level file management commands. This is not possible
with ESRI grid files, with part of the information embedded in a single
/info directories and the rest distributed among various grid directories.

Fifty, nobody runs GRASS on a shared machine anymore. They just
don't. If you want to work on something, it's going to be in a
subdirectory. Introducing unfamiliar ideas like "database",
"location", and "mapset" (I'm just reading these off the very first
GRASS screen) is not a way to endear yourself to someone new to GRASS.

Like 'coverage', 'theme', and 'view' are any more transparent terminology???
Actually research teams DO exist and DO access GRASS spatial data from
shared data servers. Interdisciplinary research teams are being STRONGLY
encouraged by national funding for the sciences at present. GRASS is the
only GIS with a data structure that is set up to work with teams. ArcView is
a nightmare if you want to share data. Beyond that, the location/mapset
structure is the way that GRASS handles projections (as discussed above) and
these names seem pretty straightforward. The "database" or even worse
"GISDBASE" could perhaps be better renamed the 'GRASS data directory'

Sixth, the command options of GRASS are completely non-Unixy. If I'm
going to load a raster using g.in.gdal, I should be able to say
"g.in.gdal filename". Since the current set of parameters are all
tagged parameters, it should be a no-brainer to add positional
parameters.

Many (most?) GRASS commands with simple arguments DO work this way. You can
use d.vect [mapname] or d.vect map=[mapname] to display a map. R.in.gdal
requires at least input and output map arguments, and can take quite a few
more. I don't know if it will take r.in.gdal [inmap] [outmap], but it might.

And while you're at it, change "foo=bar" to "-foo bar",
please. If you don't have single-character options, you don't need
"--" for options. A single dash is fine.

GRASS started out as a UNIX program, but is now designed to run on may
platforms--more than any other GIS. As a Mac user (who does use the
terminal), I find foo=bar easier to follow than -foo bar; I think most other
new users would too. Note that it is the same amount of typing. Also, GRASS
uses the dash for flags, which is pretty unixy.

v.command foo=bar -x

Seventh, the command prompt of GRASS is all TOO Unixy.

Huh??

If you type
"help", you get the shell's help.

If you type a command with the -h switch, you get the command usage.
If you type a command without arguments, you get an autogenerated GUI
dialog. There is a help button on each of these that takes you to a nice
html page of the manual for the command.
If you type g.manual you'll get an html formatted help for the entire
program opened in your current browser.

This is pretty flexible, combining both unix-like help and features more
like the online help of commercial programs.

However, we could really use people to help update and improve these manual
pages, and other GRASS documentation like the tutorial and FAQ. This is
something even non-programmers can do.

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

Actually I like to do shell scripts. Perhaps I'm silly, but they work very
well. For people without much programming experience, they are a GREAT way
to customize GRASS. It is easy to make a reasonably nice UI from shell
scripts in GRASS too.

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

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

It would work like this:

from grass import r, d, v

display = d.monitor()
map = r.in.gdal("stlawrencecounty.jpg")
schooldistricts = v.in.ogr("schooldistricts.shp")
display.add(map)
display.add(schooldistricts)

Then you'd see, on the display, a raster map of St. Lawrence County,
overlayed by a set of vectors which are the school districts.

Uh it is pretty easy to do this using GRASS commands in a shell script, Perl
script, or Python script. The following 5 commands (same number as you have)
in script run from within GRASS would do exactly what you want.

r.in.gdal input=stlawrencecounty.jpg output=map
v.in.ogr dsn=[path to schooldistricts.shp] output=schooldistricts/
layer=schooldistricts
d.mon x0
d.rast map
d.vect schooldistricts

If you want to run this outside the GRASS environment, you can access the
grass libraries to do so.

It's late and I guess I'll leave the rest of the more ranty comments below
for others to answer. A lot of the GRASS structure and organization is there
for good reasons. However, other aspects have just been inherited and may
even be problematic. GRASS can definitely be improved. The changes from 5.0
to 6.0 are substantial and show the potential of the software. However, this
has been done with a very small community of very dedicated developers. To
have more improvements requires more user contribution to GRASS development.
This can empower users to help create better software that they use on a
daily basis. This is why I became involved a year ago. You are doing the
right thing by offering to help making improvements to the program. However,
you also need to get sufficiently involved in the project and learn enough
GIS in order to suggest changes that can both benefit the existing user
community and encourage new users as well.

Michael

Finally, I (obviously) think that GRASS needs a lot of changes. I
realize that every GRASS user has invested substantial time in
learning how to use GRASS. These users will resist these changes.
Probably most GRASS developers are, in the grand tradition of open
source, first and foremost GRASS users. So my hopes of having my
suggestions accepted are low. The last time I made similar
suggestions several years ago, instead of people saying "yes, those
are good suggestions", people said "if that's all you want to do,
GRASS is the wrong package". I agree! If all you want to do is use
GRASS, GRASS is the wrong package.

I think that, for GRASS to achieve a larger user base (and
consequently larger developer base), it needs changes which will piss
off all current grass users. GRASS needs to be completely refactored
into a completely different kind of GIS system. I think that, instead
of trying to improve GRASS, it would be better to treat GRASS as the
ruins of a GIS package, to be scavenged over for useful bits of code.
In that manner, GRASS development could continue unimpeded, while the
(insert name here) package could move forward without having to worry
about backwards compatibility with current user training.

Am I completely kooky here? Am I saying anything obviously stupid?
Is there some technical requirement for GRASS to be hard to use that I
fail to comprehend? Does anybody else feel the same way that I do?
Or have they all left to go work on QGIS and Thuban? I recognize that
I'm suggesting huge amounts of work, but the reward is large as well.

Imagine: an open source GIS package that was both capable AND usable!

--
--My blog is at angry-economist.russnelson.com | Freedom means allowing
Crynwr sells support for free software | PGPok | people to do things the
521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are
Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs.

____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

Russell_Nelson · January 31, 2005, 4:30pm

Michael Barton writes:
> > I tried GRASS 5.7 again. The last time I tried it was almost three
> > years ago, in May of 2002.
>
> First, a question. Since you are trying the most current version of GRASS
> (something I indeed recommend), why are you testing some version of 5.7 when
> 6.0.0 beta 1 has been released. Depending on which version of 5.7 you are
> looking at, this could make an enormous difference in the functionality of
> GRASS.

Because that's what Fedora has packaged. When somebody says "GRASS is
the open source GIS program", and they install the GRASS package,
that's what they'll get.

> time. However, that won't help limited knowledge of GIS.

That's the "Barbie says GIS is hard!" excuse.

> This is not an excuse for a needlessly difficult user experience.

I'm glad we agree.

> IMHO, GRASS is no harder (nor any easier) to learn than other GIS software
> I've encountered--including MapInfo, ArcView/ArcGIS, and Idrisi. This
> doesn't yet get at the issues you raise below, but needs to be kept in mind.

No, you're saying "Everything else sucks, so it's okay for GRASS to
suck too." GRASS is not competing just against other GIS packages.
It's also competing against not using GIS at all. If GRASS is so hard
to use that it turns people off to using GIS, GRASS has failed them.

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

I hope that your answer is "yes". That's my answer.

> When you create a "location" to store your GIS files, you are asked
> to define a default region. You don't HAVE to do this (you can just
> put 0 and 1 in the extents in fact), but it is a good idea.

Then that is what GRASS should do.

> GRASS handles this critical necessity by assuming that all files
> within a "location" have the same projection parameters--parameters
> that the user sets when a location is created.

Let's look at how this plays out. Take a user with a GPS track and a
GeoTIFF. They want to plot the track on the map. This should be easy
in GRASS, right? Load the GeoTIFF as a raster, load the GPS track as
a vector, and plot the vector on the raster. This should be easy.
It's not. GRASS should make the easy trivial, the difficult easy, and
the impossible possible. Instead, it makes the easy difficult and the
impossible easy.

Here's one way the learning curve could be flattened:

First, don't ask for a location. Use $HOME/.grass. Second, when they
import something into $HOME/.grass, look at its bounding box. If it's
0,0 through (say) 2048,2048, then it's an xy projection. If it's
45,-75 through 44,-74, it's lat/lon. If it's howevermany hundred
thousand by howevermany million, it's UTM. Prompt them for the
projection, and use the inferred value as the default. That's now the
projection for everything in $HOME/.grass.

Does this create trouble down the road? Yes, it does. It makes the
learning curve steeper ... later, when the user understands more.
That has the effect of making the learning curve flatter.

> > Third, when you load a dataset (raster or vector), the default should
> > be to display it.
>
> As I noted before, GRASS does not load a file, it displays it.

Sorry to confuse. By "load" I mean "import into a GRASS location".

> This is the way that vectors ARE organized in GRASS 5.7 on up. Rasters are
> still organized the old way. A few months ago, Markus Neteler suggested
> re-organizing raster structure along the same lines. I think it is a GREAT
> idea.

Excellent.

> However, many others were reluctant to do so because of backward
> compatibility with large investment in GIS data.

It's just renaming.

> Actually research teams DO exist and DO access GRASS spatial data from
> shared data servers. Interdisciplinary research teams are being STRONGLY
> encouraged by national funding for the sciences at present. GRASS is the
> only GIS with a data structure that is set up to work with teams.

Good for GRASS! I'm not suggesting that GRASS should lose any
capability. It's the learning curve that's the problem.

> This is pretty flexible, combining both unix-like help and features more
> like the online help of commercial programs.

Fair enough.

> However, this has been done with a very small community of very
> dedicated developers. To have more improvements requires more user
> contribution to GRASS development.

It also requires more GRASS users. That requires a less steep
learning curve. I agree that there is a lot to know about GIS. GRASS
can do a better job of tolerating GIS naivete.

I think that 90% of my complaints are caused by the GRASS shell. I'll
bet that if I spend some time looking at it, I'll find some
improvements that can be made.

Mark_P_Line · January 31, 2005, 6:12pm

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

Mark_P_Line · January 31, 2005, 9:24pm

Russell Nelson said:

Michael Barton writes:

First, a question. Since you are trying the most current version of
GRASS (something I indeed recommend), why are you testing some version
of 5.7 when 6.0.0 beta 1 has been released. Depending on which version
of 5.7 you are looking at, this could make an enormous difference in the
functionality of GRASS.

Because that's what Fedora has packaged. When somebody says "GRASS is
the open source GIS program", and they install the GRASS package,
that's what they'll get.

Sorry, there's no such thing as "the GRASS package".

Here's one way the learning curve could be flattened:

First, don't ask for a location. Use $HOME/.grass.

What do you call it on Windows and Mac systems?
How do you share locations among several users?

Second, when they import something into $HOME/.grass, look at its
bounding box. If it's 0,0 through (say) 2048,2048, then it's an xy
projection. If it's 45,-75 through 44,-74, it's lat/lon. If it's
howevermany hundred thousand by howevermany million, it's UTM.

If you believe that there's a solid algorithm for automatically generating
a useful DEFAULT_WIND for a map or set of maps that are about to be
imported into a location, code it up and contribute it. If it works, there
might be users besides yourself who'd like to use it.

> However, many others were reluctant to do so because of backward
> compatibility with large investment in GIS data.

It's just renaming.

Renaming of symbols upon which downstream client software depends is a
backward compatibility issue. Even if what you're doing seems completely
innocuous, it's not innocuous if it breaks an interface contract that
other components in the greater environment have relied upon. That comes
with the territory when you're dealing with software-in-the-large.

"I think I'll rebuild my Linux kernel with fork() renamed to spoon().
Surely that won't cause any problems, since all I've done is rename one
little symbol." See the problem?

However, this has been done with a very small community of very
dedicated developers. To have more improvements requires more user
contribution to GRASS development.

It also requires more GRASS users.

Why does GRASS require more users?

GRASS can do a better job of tolerating GIS naivete.

Why would it want to do that?

GRASS is not and never has been a desktop mapping application for
Heathcliff Xavier Thurston Vanderbilt III, maritime division manager for
Ocean Shipping International, Inc. who doesn't know a projection from a
chinchilla but who needs to see where the SS LeaksRUs is currently located
on a world map on his computer screen.

GRASS is a spatial analysis and visualization application for John Miller,
principal investigator for the federal fisheries laboratory who's picked
up a project for assessing the return distribution of tagged coho salmon
in south Alaska rivers.

The John Millers of the world use GRASS daily more or less without
complaint, and enjoy every new version that comes down the pike with even
more useful functionality.

The Cliff Vanderbilts of the world don't even dust their own monitors, and
certainly GRASS is not for them. There are plenty of products out there
for this type of user, and they're likely to just go out and buy one of
them.

There's no need for the GRASS development community to waste its time
morphing GRASS from something that gives John Miller the latest in
algorithmic wherewithal into something that gives Cliff Vanderbilt
something to click at in between morning tennis and afternoon golf.

I think that 90% of my complaints are caused by the GRASS shell. I'll
bet that if I spend some time looking at it, I'll find some
improvements that can be made.

Of course. Anybody can do that. But can you design and code the
improvements and make them stick?

-- Mark

Mark P. Line
Polymathix
San Antonio, TX

Markus_Neteler1 · January 31, 2005, 10:08pm

On Mon, Jan 31, 2005 at 11:30:55AM -0500, Russell Nelson wrote:

Michael Barton writes:
> > I tried GRASS 5.7 again. The last time I tried it was almost three
> > years ago, in May of 2002.
>
> First, a question. Since you are trying the most current version of GRASS
> (something I indeed recommend), why are you testing some version of 5.7 when
> 6.0.0 beta 1 has been released. Depending on which version of 5.7 you are
> looking at, this could make an enormous difference in the functionality of
> GRASS.

Because that's what Fedora has packaged. When somebody says "GRASS is
the open source GIS program", and they install the GRASS package,
that's what they'll get.

It depends on the distribution. For SuSe 9.1 the latest GRASS is
available as RPM, also for Debian. Mandrake I don't know at time.

If a distro provides an older version of GRASS, we cannot do much.
The download page refers to locations where to get GRASS 6.0.0beta1
precompiled:

http://grass.itc.it/download/index.php

If possible, please report on the latest release, perhaps a
few or even more problems have been already solved.

Markus

Cefn_Hoile · January 31, 2005, 11:39pm

I'd like to offer my support to Russell's suggestion. I'm not going to get into a flame war about whether I'm properly qualified to comment, but just so you know where I'm coming from.

* I'm a programmer
* I'm a naive GRASS user (a week ago I had hardly touched GIS)

Last week I set myself the project to view two GIS files overlaid one on the other in some rendering tool. I want to explore my local area for good paragliding sites. I therefore need to bring together elevation data, roads, and possibly land use data, and be able to explore a 3d map produced from these data to find south facing slopes.

After getting hold of the appropriate datasets, I looked for a long time on the web to find a suitable rendering tool, and NViz seemed to incorporate the key features. It also ran on the Mac, so I started on my learning curve with GRASS to get to a 3d rendering. At that stage, I considered GRASS to be a package, since I acquired it as a single collection, although I recognise the distinction, Michael.

The primary value which the GRASS toolset offers me in this respect is that it understands a range of standards and can translate these into an internal representation which is consistent. Then I should be able to get my DTED to work with my E00 lines describing roads, all in one navigable 2d or 3d rendering.

I had a lot of patience for GRASS since I could see from the tutorials and demonstration data sets that my preferred end result (a navigable 3d surface) was straightforward once you had a properly imported data set for GRASS to read.

Let us just say that I spent a long time messing around with it, reading all kinds of tutorials even before I could confirm to my satisfaction that the GRASS toolset could properly interpret the data I had, let alone render it. I still can't get the roads to render properly, but I now have the elevation data rendering.

Doing things which I thought were practically unambiguous (starting with an empty project, and attempting to import data files to populate it) turned out to need some secret tricks to get them to do what I expected.

I may in the future develop my understanding of GIS tools further. I work for a telco, and there is an increasing adoption of GIS for planning, forecasting and operations, although I am not working in those fields at the moment.

However, my continuing with GRASS, and discovering more about its power, depended crucially on me being able to do an apparently really simple thing, using really simple steps. My first several experiences suggested that it was an impossible hill to climb.

Although there are a set of simple steps to facilitate it, a lot of understanding of GRASS and how it was built was required to understand what these simple steps were. If I had been presented with a 'dummies new project from GIS file' process. I would have been a much happier user. I am now beginning to recognise the power of the underlying approach, but I came damn close to throwing in the towel after the 20th failed import.

The need to specify a region I ran headlong into, leading to lots of blank screens. That was of course after I worked out that a display had to be launched and targeted, and after checking practically every checkbox and text entry of every menu option to see what I could possibly be doing wrong.

I understand totally the importance of the composition of individual tools which are self-contained, efficient, and can be combined together to build the kind of complex GIS operations which hardball GIS users need.

However, I can't help thinking that some default behaviour of the UI tool could be made more intuitive, especially where people are executing operations which don't make sense for well-qualified users to execute at all (importing files with no intersection with your current region, launching a rendering when there is no display).

The question is, could a straightforward modification of the UI tool be made to solve this problem, without threatening the generality of the toolset.

How about a wizard in the main menu which takes a file and renders it, creating a new project with the display range drawn from the file itself? With a project loaded, the same wizard menu item could allow you to import a new file to the same project, and provide you with the option to either, keep the region the same, or set the region according to the limits of the new file.

From there (with a well-structured initial project and mapset targeted), GRASS users should be able to move forward learning the full range of capabilities with individual operations.

I appreciate what Michael has said about there being complex interactions between elements, which make the suggestion to change each program in the toolset to add this behaviour a little too complex.

However, couldn't a dummies operation be allowed into the main menu of the UI tool, where those playing hardball, at worse, could ignore it.

I'm sorry not to be sufficiently familiar with GIS or GRASS to be able to help with building such a wizard, but maybe Russell's enthusiasm will propel him to build one

Cefn
http://cefn.com

On 31 Jan 2005, at 18:12, Mark P. Line wrote:

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

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

Mark_P_Line · February 1, 2005, 12:43am

Cefn Hoile said:

* I'm a naive GRASS user (a week ago I had hardly touched GIS)

Last week I set myself the project to view two GIS files overlaid one
on the other in some rendering tool. I want to explore my local area
for good paragliding sites. I therefore need to bring together
elevation data, roads, and possibly land use data, and be able to
explore a 3d map produced from these data to find south facing slopes.

[snip]

The primary value which the GRASS toolset offers me in this respect is
that it understands a range of standards and can translate these into
an internal representation which is consistent. Then I should be able
to get my DTED to work with my E00 lines describing roads, all in one
navigable 2d or 3d rendering.

I don't know of any GIS in the world that has as one of its requirements
the ability to support a user with no prior knowledge of GIS who wants to
merge disparate spatial data sources into a commonly projected database.

Let us just say that I spent a long time messing around with it,
reading all kinds of tutorials even before I could confirm to my
satisfaction that the GRASS toolset could properly interpret the data I
had, let alone render it. I still can't get the roads to render
properly, but I now have the elevation data rendering.

Have you asked for help on the GRASS users list?

However, my continuing with GRASS, and discovering more about its
power, depended crucially on me being able to do an apparently really
simple thing, using really simple steps. My first several experiences
suggested that it was an impossible hill to climb.

What you wanted to do was only apparently simple. When I taught GIS to
geography grad students, they would not have learned how to do what you're
wanting to do by the end of the semester, although they would have been
able to do the analysis you're envisioning if I'd provided them with a
clean database ready to go.

The need to specify a region I ran headlong into, leading to lots of
blank screens. That was of course after I worked out that a display had
to be launched and targeted, and after checking practically every
checkbox and text entry of every menu option to see what I could
possibly be doing wrong.

Did you ask questions on the GRASS user list along the way and fail to get
usable answers? The things you mention are very common newbie problems
that almost anybody could have helped you through.

In the greater scheme of things, I would not find it advantageous for the
GRASS development community to prioritize precious workhours on writing
tutorials for a handful of casual lay users at the expense of updating the
manpages for thousands of university and governmental researchers who use
GRASS every day in their work.

Of course, you yourself might be just the right person to write a tutorial
for users with no knowledge of GIS -- in which case you'd be more than
welcome to write and contribute it.

How about a wizard in the main menu which takes a file and renders it,
creating a new project with the display range drawn from the file
itself? With a project loaded, the same wizard menu item could allow
you to import a new file to the same project, and provide you with the
option to either, keep the region the same, or set the region according
to the limits of the new file.

That doesn't sound too hard. It could be done in Python, perl, Tcl or
bash, perhaps, since it doesn't really involve any new functionality --
just a new way to get a location started.

Would you like to code it up and contribute it? Maybe there are lots of
potential users out there who would like to use a wizard like that the
first time around.

I'm sorry not to be sufficiently familiar with GIS or GRASS to be able
to help with building such a wizard, but maybe Russell's enthusiasm
will propel him to build one

Oh. Well, there's the rub, then.

The GRASS development community is tiny and overworked in comparison to
the size of the software (currently a little over 400K lines of C in the
6.0.0beta1 source tree, not counting header files and ancillary source
material). Because the user base does not include very many people with no
background in GIS, most of the developers' time will almost certainly have
to be spent doing things that generate the most benefit for current users.

I understand the catch-22 situation that that implies: Unless more is done
to support walk-in users, the user base never *will* include very many of
them. It all boils down to what kinds of user GRASS was and is being
developed to support, and I think that's already been addressed several
times in this thread.

-- Mark

Mark P. Line
Polymathix
San Antonio, TX

cmbarton · February 1, 2005, 12:44am

Cefn

A lot of good ideas here. I've been pushing for a much better UI for the
past year, after using GRASS for awhile and realizing that much of its power
was unavailable to many users (as you have observed, only it was much worse,
with only half of the commands in the GUI). When I realized that I could do
something to move that along, I volunteered to do so. With major
contributions from some of the other folks on the development team (like
making all commands pop up an autogenerated GUI dialog and Radim's GRASS 5.7
display manager), I managed to get the UI from where it was with 5.0.1 to
where it is now. That is, a reasonably functional and integrated UI that
actually includes all of the GRASS commands. BUT it could be much better.
What we have now finally exposes all of GRASS to the user without accessing
the command line. This can be a jumping off point for the next generation of
UI.

Radim is proposing to move from TclTk to QT. Others have mentioned redoing
the UI in GTK. It would be great if people with more programming expertise
than me could also be a part of this effort. Markus, Radim, and the few
others who contribute to the code that actually makes GRASS tick really have
their hands full. With additional folks working on the UI in a coordinated
way, I'm sure we could have a slicker and easier to use piece of software. I
would very much like to see this. However there needs to be some kind of
overarching vision of what actually can make a complex piece of software
like this easier to use for the people who use it on a regular basis as well
as first time users. A wizard such as you describe would be helpful and
should be doable within TclTk or another interface development environment.

Another thing that would really help everybody, but especially new
users--and can be done by non-programmers--is to improve the massive
documentation. Outside of the manual pages, much has not kept up with the
rapid changes from GRASS 5 to 6. I know that Markus is working on a new
GRASS tutorial, but there is a lot to do. I know he has asked many times for
help with the html pages docs. I've seen some suggestions go across the
list, but we need people who can actually improve the pages rather than tell
Markus how they ought to be improved. A tutorial for novices would be a
GREAT idea. I'd love to point students and colleagues to such a place and
say, 'this can get you started'. Markus added a help page to the opening
screen of GRASS that is a very basic bit of information of this sort. This
would have helped you if you knew to hit the help button at the very
beginning. Check it out and see how it can be improved and expanded. Just
some ideas.

For those who just want to display maps (including overlaying different
spatial data sets) and are unconcerned with analysis, I'd also recommend
taking a look at a few other projects that are ongoing, especially, qGIS,
Thuban, and JUMPGIS.

Cheers,
Michael

______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Cefn Hoile <grass.itc.it@cefn.com>
Date: Mon, 31 Jan 2005 23:39:52 +0000
To: grass devel <grass5@grass.itc.it>
Subject: Re: [GRASS5] Re: [Fwd: whinging about GRASS again]

I'd like to offer my support to Russell's suggestion. I'm not going to
get into a flame war about whether I'm properly qualified to comment,
but just so you know where I'm coming from.

* I'm a programmer
* I'm a naive GRASS user (a week ago I had hardly touched GIS)

Last week I set myself the project to view two GIS files overlaid one
on the other in some rendering tool. I want to explore my local area
for good paragliding sites. I therefore need to bring together
elevation data, roads, and possibly land use data, and be able to
explore a 3d map produced from these data to find south facing slopes.

After getting hold of the appropriate datasets, I looked for a long
time on the web to find a suitable rendering tool, and NViz seemed to
incorporate the key features. It also ran on the Mac, so I started on
my learning curve with GRASS to get to a 3d rendering. At that stage, I
considered GRASS to be a package, since I acquired it as a single
collection, although I recognise the distinction, Michael.

The primary value which the GRASS toolset offers me in this respect is
that it understands a range of standards and can translate these into
an internal representation which is consistent. Then I should be able
to get my DTED to work with my E00 lines describing roads, all in one
navigable 2d or 3d rendering.

I had a lot of patience for GRASS since I could see from the tutorials
and demonstration data sets that my preferred end result (a navigable
3d surface) was straightforward once you had a properly imported data
set for GRASS to read.

Let us just say that I spent a long time messing around with it,
reading all kinds of tutorials even before I could confirm to my
satisfaction that the GRASS toolset could properly interpret the data I
had, let alone render it. I still can't get the roads to render
properly, but I now have the elevation data rendering.

Doing things which I thought were practically unambiguous (starting
with an empty project, and attempting to import data files to populate
it) turned out to need some secret tricks to get them to do what I
expected.

I may in the future develop my understanding of GIS tools further. I
work for a telco, and there is an increasing adoption of GIS for
planning, forecasting and operations, although I am not working in
those fields at the moment.

However, my continuing with GRASS, and discovering more about its
power, depended crucially on me being able to do an apparently really
simple thing, using really simple steps. My first several experiences
suggested that it was an impossible hill to climb.

Although there are a set of simple steps to facilitate it, a lot of
understanding of GRASS and how it was built was required to understand
what these simple steps were. If I had been presented with a 'dummies
new project from GIS file' process. I would have been a much happier
user. I am now beginning to recognise the power of the underlying
approach, but I came damn close to throwing in the towel after the 20th
failed import.

The need to specify a region I ran headlong into, leading to lots of
blank screens. That was of course after I worked out that a display had
to be launched and targeted, and after checking practically every
checkbox and text entry of every menu option to see what I could
possibly be doing wrong.

I understand totally the importance of the composition of individual
tools which are self-contained, efficient, and can be combined together
to build the kind of complex GIS operations which hardball GIS users
need.

However, I can't help thinking that some default behaviour of the UI
tool could be made more intuitive, especially where people are
executing operations which don't make sense for well-qualified users to
execute at all (importing files with no intersection with your current
region, launching a rendering when there is no display).

The question is, could a straightforward modification of the UI tool be
made to solve this problem, without threatening the generality of the
toolset.

How about a wizard in the main menu which takes a file and renders it,
creating a new project with the display range drawn from the file
itself? With a project loaded, the same wizard menu item could allow
you to import a new file to the same project, and provide you with the
option to either, keep the region the same, or set the region according
to the limits of the new file.

From there (with a well-structured initial project and mapset
targeted), GRASS users should be able to move forward learning the full
range of capabilities with individual operations.

I appreciate what Michael has said about there being complex
interactions between elements, which make the suggestion to change each
program in the toolset to add this behaviour a little too complex.

However, couldn't a dummies operation be allowed into the main menu of
the UI tool, where those playing hardball, at worse, could ignore it.

I'm sorry not to be sufficiently familiar with GIS or GRASS to be able
to help with building such a wizard, but maybe Russell's enthusiasm
will propel him to build one

Cefn
http://cefn.com

On 31 Jan 2005, at 18:12, Mark P. Line wrote:

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

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

Russell_Nelson · February 1, 2005, 3:50am

Mark P. Line writes:
> Russell Nelson said:
> > Because that's what Fedora has packaged. When somebody says "GRASS is
> > the open source GIS program", and they install the GRASS package,
> > that's what they'll get.
>
> Sorry, there's no such thing as "the GRASS package".

[nelson@desk nelson]$ rpm -q grass
grass-5.7.0-1.fdr.2
[nelson@desk nelson]$

> > Here's one way the learning curve could be flattened:
> >
> > First, don't ask for a location. Use $HOME/.grass.
>
> What do you call it on Windows and Mac systems?

I dunno. I expect that there is a reasonable default on both
systems. "My Documents\GRASS" for Windows perhaps?

> How do you share locations among several users?

That's not likely to be the first thing you do. If it is, then the
person who is sharing the data with you will be able to tell you how
to access it.

> Renaming of symbols upon which downstream client software depends is a
> backward compatibility issue.

How many other programs besides the ones shipped with GRASS understand
GRASS's file hierarchy? I acknowledge the general case of the problem
you describe.

> Why does GRASS require more users?

Everyone agrees that GRASS has a steep learning curve of its own,
independent on the GIS learning curve. Consequently, there must be
many people who would like to do GIS analysis using GRASS, but have
not gotten past the learning curve.

Russell_Nelson · February 1, 2005, 3:58am

Mark P. Line writes:
> I understand the catch-22 situation that that implies: Unless more is done
> to support walk-in users, the user base never *will* include very many of
> them. It all boils down to what kinds of user GRASS was and is being
> developed to support, and I think that's already been addressed several
> times in this thread.

I think you're right.

Russell_Nelson · February 1, 2005, 5:38am

Mark P. Line writes:
> 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 the "Everybody gets taught ARCinfo, so if they find GRASS
hard, it's their teacher's fault" excuse.

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

"Open source constraints"? Public domain software is open source
software. Open Source comes under many licenses; not just the GPL.
See http://opensource.org/licenses/ .

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

Yes, that is my concern. Glynn Clements has already said "your
proposal wasn't feasible. Nothing has changed since then."

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

No, that's not it. It's not that they didn't like my solution. It's
that they didn't like my problem. No solution can satisfy a
non-problem. GRASS developers acknowledge that GRASS is hard to use
on one hand, but they also say that fixing that problem is not a
priority for them.

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

In other words, "if that's all you want to do, GRASS is the wrong
package." See what I mean?

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

I must wax philosophical. I believe, as an item of faith, that life
is too short to spend it writing software for just yourself.
Consequently, when I write software, I want as many people to benefit
from it as possible. That's why I'm the President of the Open Source
Initiative. Helping people to benefit from open source is a priority
for me.

I have many years of experience in using computers. When I run across
a piece of software which appears to solve a problem for me, and which
I cannot figure out how to use, I conclude that the software is at
fault. Many people do not do this. If they cannot run GRASS, they
conclude that the problem lies with them, not the software. It's
almost as if GRASS's motto is:

GRASS: Making GIS Harder Than It Needs To Be For Twenty Years.

I rail similarly at BIND. The domain name system is not so very hard
to understand. BIND makes it harder by combining the function of DNS
caching and DNS authoritative serving. It uses a funky zone file
format. It uses default parameters that don't make any sense. If
you're used to BIND, you won't see the problem. BIND is great.

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

I think the solution is just as you suggested: to create a front-end
which is helpful. Doesn't require any changes to 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.

This is the "GIS is hard, so it's okay if GRASS is harder" excuse.

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

This is the "but lots of people are using GRASS every day" excuse.

Anecdotal evidence: I saw a presentation by the NPS on water flow in
Mammoth Cave. Me: "Nice maps; did you use GRASS?" NPS: "No,
ARCview. We used to use GRASS, but .... we switched."

Paolo_Cavallini · February 1, 2005, 7:08am

A suggestion to make things easier for a newby: in the startup screen, the way
EPSG codes are selected could be improved (e.g. with a pull-down menu, or
something similar); also, perhaps presenting the user with a default choice,
while it does not make much sense for real GIS users, could make like easier
for the curious. Finally, a button "How to set up a location?" with the very
basics might be useful.
All the best.
pc

At 01:44, martedì 1 febbraio 2005, Michael Barton has probably written:

Cefn

--
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it www.faunalia.com
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

cmbarton · February 1, 2005, 7:42am

I don't know much about EPSG codes, but think that it would be a very long
list (I don't use them, but I'm sure they are useful to those who do).
However, there IS now a button (it says HELP) at the very first screen that
takes you to a page that describes the basics of how to set up a location,
get your data into GRASS, etc.

For discussions of the UI, it would be helpful if all were talking about the
same UI. I see that Russell was looking at 5.7.0. This is about 9 months old
and has a rather different UI than 6.0.0 beta 1. This is a consequence of
this being the development release and pretty rapid development. Not that
the 6.0.0 UI couldn't be improved, but it is different from 5.7.0. And both
are different from the interface in 5.4--though all are in TclTk.

Cheers,
Michael
____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

From: Paolo Cavallini <cavallini@faunalia.it>
Organization: Faunalia
Reply-To: <cavallini@faunalia.it>
Date: Tue, 1 Feb 2005 08:08:30 +0100
To: <grass5@grass.itc.it>
Subject: Re: [GRASS5] Re: [Fwd: whinging about GRASS again]

A suggestion to make things easier for a newby: in the startup screen, the way
EPSG codes are selected could be improved (e.g. with a pull-down menu, or
something similar); also, perhaps presenting the user with a default choice,
while it does not make much sense for real GIS users, could make like easier
for the curious. Finally, a button "How to set up a location?" with the very
basics might be useful.
All the best.
pc

At 01:44, martedì 1 febbraio 2005, Michael Barton has probably written:

Cefn

--
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it www.faunalia.com
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

Mark_P_Line · February 1, 2005, 7:53am

Russell Nelson said:

Mark P. Line writes:
> Russell Nelson said:
> > Because that's what Fedora has packaged. When somebody says "GRASS
is
> > the open source GIS program", and they install the GRASS package,
> > that's what they'll get.
>
> Sorry, there's no such thing as "the GRASS package".

[nelson@desk nelson]$ rpm -q grass
grass-5.7.0-1.fdr.2
[nelson@desk nelson]$

Yes. That is ***a*** GRASS package that is installed on a particular
system. There is no sense in which that is ***the*** GRASS package that
"they" get whenever "they" install GRASS.

> > Here's one way the learning curve could be flattened:
> >
> > First, don't ask for a location. Use $HOME/.grass.
>
> What do you call it on Windows and Mac systems?

I dunno. I expect that there is a reasonable default on both
systems. "My Documents\GRASS" for Windows perhaps?

There's nobody but you designing this proposed enhancement. If you don't
know, then nobody does. When your design is complete, maybe you can find
some people to help you code it.

> How do you share locations among several users?

That's not likely to be the first thing you do. If it is, then the
person who is sharing the data with you will be able to tell you how
to access it.

In any shop I run, that will absolutely be the first thing any new user
does who comes online with the platform.

> Renaming of symbols upon which downstream client software depends is a
> backward compatibility issue.

How many other programs besides the ones shipped with GRASS understand
GRASS's file hierarchy? I acknowledge the general case of the problem
you describe.

That's hard to say. How many programs besides the ones shipped with the
Linux kernel call fork()?

There are a number of systems that have been made to interoperate with
GRASS. CD-ROM's have been produced and sold which contain mountable GRASS
locations.

In any event, even just the internal compatibility issues (current users'
scripts that would break when they upgraded to the nomenclaturally
beautified version) are sufficient to warrant severe caution when renaming
any interface symbols.

> Why does GRASS require more users?

Everyone agrees that GRASS has a steep learning curve of its own,
independent on the GIS learning curve. Consequently, there must be
many people who would like to do GIS analysis using GRASS, but have
not gotten past the learning curve.

That tells me that there are people not currently using GRASS. I already
knew that, and that was not my question.

My question was why you think GRASS requires more users than it already has.

-- Mark

Mark P. Line
Polymathix
San Antonio, TX

H_B · February 1, 2005, 8:23am

[mix of replies here..]

Russell:

Because that's what Fedora has packaged.

There's little anyone here can do about that, except get 6beta2 ready
and hope the redhat people pick it up.

> When you create a "location" to store your GIS files, you are asked
> to define a default region. You don't HAVE to do this (you can just
> put 0 and 1 in the extents in fact), but it is a good idea.

Then that is what GRASS should do.

A note could be added that "non-critical - you can change these later".
(Of course we need to make the default region overwritable first
A GUI (click Next..) for all of this will happen one day. bit by bit...

Second, when they
import something into $HOME/.grass, look at its bounding box. If it's
0,0 through (say) 2048,2048, then it's an xy projection. If it's
45,-75 through 44,-74, it's lat/lon. If it's howevermany hundred
thousand by howevermany million, it's UTM. Prompt them for the
projection, and use the inferred value as the default. That's now the
projection for everything in $HOME/.grass.

So what if the user is in Europe or Asia? XY or Lat-lon?
I'm in New Zealand, we use a couple different howevermany million
projections here and a couple of different map datums; UTM isn't used
much if at all.

The very important point is this: it is much better to make no choice
at all rather than to start making incorrect assumptions. This way the
user knows where the error is and what question has to be answered.
It's a very important and well demonstrated point. Many disasters.

with respect to setting locations automatically from GeoTIFFs by
default: I've got a CD here with about 50 important maps, all with
bogus/incorrect metadata. I don't think this is so unusual, upstream
data sources of specialist items often have less than perfect quality
control. Just in my one case yes, but the problem exists, and a new user
is never going to be able to know what to trust..
I am reminded of Excel vs. Matlab in taking an average of a series of
data points. Excel will take the average irregardless of the number of
NaN cells; Matlab will cough blood and make you explicitly tell it
that's what you really really want to do. Ease of use vs. imposed
correctness isn't always a bad thing.

[reorganizing GRASS raster directory structure planned for the future]

It's just renaming.

no, it is resorting files in a non-backwards compatible way. I guess you
could leave a trail of symlinks but that's even messier.
This will happen one day.

> Renaming of symbols upon which downstream client software depends is
> a backward compatibility issue.

How many other programs besides the ones shipped with GRASS understand
GRASS's file hierarchy? I acknowledge the general case of the problem
you describe.

gdal->qgis for one.
lots of homebrew scripts for two.
anyway -- this will happen one day and the world will adapt.

re the GRASS prompt "too UNIXy".
would you prefer
PS1='GRASS:\W > '
?

re using shell scripts to automate grass modules.
For me this along with openness of the source are the two most
important features GRASS has. I'm often running scripts
controlling thousands of model runs 24 hours a day on a custom
code base.... nothing else can come close to doing that.

Re "what a pile of shit, let's start over from the CERL code".
Thierry Laronde has already started this with his KerGIS:
http://www.kergis.com/

Thuban & QGIS are not really competition to GRASS, as they are more
cartography packages (sounds like what you are really looking for) while
GRASS is more focused on analysis and modelling.
QGIS works quite well as a GUI front end for GRASS by the way.

Anecdotal evidence: I saw a presentation by the NPS on water flow in
Mammoth Cave. Me: "Nice maps; did you use GRASS?" NPS: "No,
ARCview. We used to use GRASS, but .... we switched."

not to hide my head in the sand but correlation does not predicate
causality .. staff turnover & lack of motivation to retrain is usually
a biggie, even if the old system worked better if you knew how to use
it properly.

If you want nice maps, use GRASS->GMT.
(or ps.map if you want to learn & tweak [that one's at the heart of
this issue: d.m's print menu as a front end for ps.map])

GRASS developers acknowledge that GRASS is hard to use
on one hand, but they also say that fixing that problem is not a
priority for them.

Speaking for myself, I get paid to run models and make maps, not make
nice GUIs for other people (nothing against other people, but they
don't give me money). My priority is to get GRASS to do what I want it
to do, and to a point where I can publish and others can reproduce my
results without being a C programmer or a diviner. If someone like
Michael Barton can come along and fix up the GUI or someone like Radim
Blazek can help write a new one, or someone like Lorenzo Moretti can do
an amazing job packaging it, then great. Just not me.
[yes, I understand ease of use != GUI, just verbally...]

n.b. installation used to be "the hardest step" after which everything
became easier. Seems we've moved on down the road.

Mark:

Why does GRASS require more users?

more users mean a more diverse base & more bug squashing, good thing.
compromising core features to do so, bad thing. (*cough* gnome 2.4)

Mark:

GRASS is not really intended for use by naive users.

everyone has to start out from zero at some point. The learning curve is
steep, but we shouldn't grease it.

Mark:

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,

yeah, we do that:
http://grass.ibiblio.org/platforms/grasshandheld.html

Mark:

GRASS is not and never has been a desktop mapping application for
Heathcliff Xavier Thurston Vanderbilt III, maritime division manager
for Ocean Shipping International, Inc. who doesn't know a projection
from a chinchilla but who needs to see where the SS LeaksRUs is
currently located on a world map on his computer screen.

a) I don't believe we've met.
b) crap, I'm in the wrong place.

[well I'm no Mr.Vanderbilt but I've been to his air-boat shed once.]

I think the answer is: be consistent and concise and let there be a
logic to it. ease of use flows from that.

... anyway back to spending the finite energy fixing things.

regards,
Hamish

Mark_P_Line · February 1, 2005, 8:29am

Russell Nelson said:

Mark P. Line writes:
> 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 the "Everybody gets taught ARCinfo, so if they find GRASS
hard, it's their teacher's fault" excuse.

It is not an excuse. It is an explanation, and one that holds up well in
my experience.

I've ignored all the rest of your "excuse" excuses, because they're all
instances of the "I have no cogent rebuttal" excuse.

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

"Open source constraints"? Public domain software is open source
software. Open Source comes under many licenses; not just the GPL.
See http://opensource.org/licenses/ .

Public domain software is not placed under *any* license of any kind.

Open Source software is software which complies with the Open Source
Definition which is also found at opensource.org. The criteria for
compliance contained in that Definition are constraints on software that
would otherwise be in the public domain.

So the statement that "public domain software is open source software" is
incorrect.

(The statement that "open source software is in the public domain" is also
incorrect, but nobody here has said that.)

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

Yes, that is my concern. Glynn Clements has already said "your
proposal wasn't feasible. Nothing has changed since then."

Then he's probably right. Why is that a problem?

In other words, "if that's all you want to do, GRASS is the wrong
package." See what I mean?

I believe everybody here sees what you mean. In what way is it not the
case that, if that's all you want to do, GRASS is the wrong package?

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

I must wax philosophical. I believe, as an item of faith, that life
is too short to spend it writing software for just yourself.
Consequently, when I write software, I want as many people to benefit
from it as possible. That's why I'm the President of the Open Source
Initiative. Helping people to benefit from open source is a priority
for me.

For software that you write, it's your prerogative to pursue an infinitely
large user base if you wish.

In the case of GRASS, it's up to the GRASS community to decide the user
demographics that it wants to pursue. It's not up to the President of the
Open Source Initiative. Right?

In any event, this is not about people writing software just for
themselves. There are orders of magnitude more non-developer users of
GRASS than there are developers.

I have many years of experience in using computers.

Okay. We'll try to keep up with you as best we can.

I think the solution is just as you suggested: to create a front-end
which is helpful. Doesn't require any changes to GRASS.

Okay. Are we going to move this thread along to the topic of everything
that you find inadequate in the QGIS approach, then?

-- Mark

Mark P. Line
Polymathix
San Antonio, TX

Mark_P_Line · February 1, 2005, 9:06am

Hamish said:

Mark:

Why does GRASS require more users?

more users mean a more diverse base & more bug squashing, good thing.
compromising core features to do so, bad thing. (*cough* gnome 2.4)

Uh huh.

Nothing has so far changed the feeling I had back in 4.1 days: The GRASS
community can be self-supporting only to the extent that the ratio of
supporters to supportees doesn't get out of hand. And unless somebody has
a large staff of bored tech writers they haven't told us about, the
self-support model is the only one that's going to fly in the foreseeable
future.

Mark:

GRASS is not really intended for use by naive users.

everyone has to start out from zero at some point. The learning curve is
steep, but we shouldn't grease it.

By "naive" I mean not only GRASS-naive but also GIS-naive. I wouldn't
throw a full-blown SAP general ledger system at a user who doesn't know
the first thing about bookkeeping. As that user, I wouldn't want to fuss
with the huge SAP system until I was an adequately versatile bean-counter.

-- Mark

Mark P. Line
Polymathix
San Antonio, TX

mlennert · February 1, 2005, 9:27am

On Tue, February 1, 2005 0:39, Cefn Hoile said:

Last week I set myself the project to view two GIS files overlaid one
on the other in some rendering tool. I want to explore my local area
for good paragliding sites. I therefore need to bring together
elevation data, roads, and possibly land use data, and be able to
explore a 3d map produced from these data to find south facing slopes.

[snip]

I had a lot of patience for GRASS since I could see from the tutorials
and demonstration data sets that my preferred end result (a navigable
3d surface) was straightforward once you had a properly imported data
set for GRASS to read.

Let us just say that I spent a long time messing around with it,
reading all kinds of tutorials even before I could confirm to my
satisfaction that the GRASS toolset could properly interpret the data I
had, let alone render it. I still can't get the roads to render
properly, but I now have the elevation data rendering.

Doing things which I thought were practically unambiguous (starting
with an empty project, and attempting to import data files to populate
it) turned out to need some secret tricks to get them to do what I
expected.

[snip]

Although there are a set of simple steps to facilitate it, a lot of
understanding of GRASS and how it was built was required to understand
what these simple steps were. If I had been presented with a 'dummies
new project from GIS file' process. I would have been a much happier
user. I am now beginning to recognise the power of the underlying
approach, but I came damn close to throwing in the towel after the 20th
failed import.

The need to specify a region I ran headlong into, leading to lots of
blank screens. That was of course after I worked out that a display had
to be launched and targeted, and after checking practically every
checkbox and text entry of every menu option to see what I could
possibly be doing wrong.

Could you (and others) explain what in

http://grass.itc.it/gdp/grass5tutor/HTML_en/c274.html
and especially
http://grass.itc.it/gdp/grass5tutor/HTML_en/c274.html#withunknowngeoref

is missing to get you going (except for the lack of mention of v.in.ogr) ?
Only by giving us feedback on the documentation and its lacks can we improve it.
If this page and the next seem alright, but just need updating to 6.0 than I
volunteer to do that, but only if I get feedback from users telling me that
this would be useful

How about a wizard in the main menu which takes a file and renders it,
creating a new project with the display range drawn from the file
itself? With a project loaded, the same wizard menu item could allow
you to import a new file to the same project, and provide you with the
option to either, keep the region the same, or set the region according
to the limits of the new file.

I would support this. It shouldn't be too hard to add a button to the start-up
screen "create new location from existing file", by creating a temp x,y
location, using v.in.ogr/r.in.gdal with the location= option and then launch
GRASS in the new location.

I've tried to look into this, but I don't have the time to get into the tcl/tk
logic, so I abandoned it...

Moritz

Radim_Blazek · February 1, 2005, 9:31am

Russell Nelson wrote:

No, that's not it. It's not that they didn't like my solution. It's
that they didn't like my problem. No solution can satisfy a
non-problem.

Not at all! The problem is evident. We just don't like the solution. You say "The trouble with GRASS is that, at its core ..." and you want to change the core, which can break everything.

Cefn Hoile wrote:
| The question is, could a straightforward modification of the UI tool be
| made to solve this problem, without threatening the generality of the
| toolset.

Exactly.

Russell Nelson wrote:

I think the solution is just as you suggested: to create a front-end
which is helpful. Doesn't require any changes to GRASS.

This sounds much more reasonable than changing the core.

> GRASS developers acknowledge that GRASS is hard to use
> on one hand, but they also say that fixing that problem is not a
> priority for them.

It WAS not the priority for me until last year. There were serious problems in GRASS vectors in 5.x. Do you know, that you can lose vector attributes immediately after import to 5.x? Because we also use GRASS for work, we needed something more reliable first. Now it is time to work on UI.

About the subject itself:
To start with GRASS without an existing location is realy painful.
I think that at least 2 improvements can be done:

1) We can create a list of predefined locations (name + description + projection + datum + region) which can be selected in startup screen instead of that terrible "Create location from EPSG"

2) The possibility to create a new GRASS location can be added to QGIS. The advantage of QGIS is, that a user can open and view imported files without GRASS. In GRASS it can take very long time until you see something and that is probably the most frustrating moment. Once the map is opened in QGIS, we know at least the region but possibly also the projections, because it can be defined in nice GUI in QGIS:
http://mpa.itc.it/radim/qgis/projection.png

Radim

Thierry_Laronde · February 1, 2005, 12:02pm

On Tue, Feb 01, 2005 at 09:23:06PM +1300, Hamish wrote:

Re "what a pile of shit, let's start over from the CERL code".
Thierry Laronde has already started this with his KerGIS:
http://www.kergis.com/

Yes, and there are lessons related to this thread to learn:

1) Remind that this is _unfortunately_ open source software: one has not
the excuse to say "if only I had the code, I will show you how to do". I
was not satisfied. I told it. So I code it.
I do not "buy" the trend: "let's talk about the freedom after the
twelveth free beer". Libre software is a lesson about freedom that is
effort: one has the ability to buy software whether by contributing good
code matching the whole design or by giving someone money in exchange
for the efforts needed to adapt the software. There is not on the one
side users that have all rights, and on the other side developers that
have all the duties.

2) GRASS is a great piece of software, still alive that is evolving but
that must keep what makes its strengths: this Unix like organization,
small dedicated programs, scripting abilities and so on.
The core shall not be messed up due to user interfaces wandering.

3) Once the core is rock solid, there is the ability to build whatever
user interface matches the user need. The trend now (and it is quite
logical) is to have dedicated interfaces allowing users to do their job
in a straightforward way. GRASS/KerGIS, because of this user interface
agnosticism is decried now, but it is this very feature that makes it
the core component of the future GIS software.

4) Part of the mess happened because GRASS was orphaned when it was
engaged in major changes (on the vectorial part, leading to a fuzzy
organization of the sources). It is normal, and what the code shows is
not the superficial mess, but the rock solid foundations.

5) The core team of the CERL was a handful (but dedicated to this one
task). So it is indeed possible to do it. To take alone the whole
sources of GRASS and work from that seems silly. But I'm silly, so this
was a task for me. This means that there can not be an excuse such as:
"I can't do that alone" since somebody has done it.

6) My hope is that, when I will have achieved the demonstration of what
I have in mind, the GRASS family will reconcile because there will be
two implementations to compare. Two facts. There can be more facts...

There are undoubtedly good
things in the GPL GRASS 6.x, and there are undoubtedly good people in
the GPL GRASS community. But I did not agree with the priorities, nor
did I agree with how to manage users requests. For me there are two
cases (I'm binary) and only two: user can ask for some doable thing
because he will pay for (contract); or user/developer can ask about a
design to see if it can fit with the engineering goals and then can
submit patches. Wishes are only accepted from advanced users I do know
and from which I do appreciate the feedback.
If a user wants to use the software for fun, he can do
it as long as his fun is not my hell. If a user wants to make money with
the software he can do it as long as what he sells is _his_ work; if he
wants the money but would prefer the work to be done by developers
"in the free spirit", I'm afraid I will not quite agree.

Cheers,
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.org/ | http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C