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

[Russell Nelson]

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.

-- 
--My blog is at angry-economist.russnelson.com  | Don't like poverty?
Crynwr sells support for free software  | PGPok | 
521 Pleasant Valley Rd. | +1 315-323-1241 cell  | Try economic freedom!
Potsdam, NY 13676-3213  | +1 212-202-2318 VOIP  |