I recently had the eye-opening experience of working in a team with two other
consulting firms, two universities and a state agency all working on an
interstate lawsuit. I worked with GRASS and Postgres, while all of the other
parties used ArcInfo and/or ArcView.
One of my first tasks was to dissect a large body of GIS data that was
exported from ArcInfo coverages by a US government agency. For managing and
analysing the large coverages, GRASS performed better than ArcInfo and much
better than ArcView. Most parties who tried working with the data failed to
get anywhere in the analysis and they ultimately had to make decisions with
little understanding of the data. GRASS gave us a much better understanding
of the data. At that time and through the following year GRASS allowed us to
make cost-effective use of the data. It was a plus for our client.
More recently in the same work an unexpected scheduling change cut in half the
time we had to complete a terrain analysis. Working with GRASS we were able
to complete the entire analysis to a level that exceeded our experts'
requirements and well within the deadline. One of our cooperators tried
performing the same analysis using ArcInfo and ArcView installations at two
different facilities. Their effort stopped after the first step in the
analysis because ArcView crashed two computers before it produced any results.
By the time they got things working we already had results in hand.
GRASS has a long way to go before most people in the consulting fields or
govenment planning agencies see it as a realistic alternative to ArcInfo or
ArcView. There are a number of problems getting GRASS the recognition that it
deserves. Without that recognition is will be difficult to convert existing
ESRI installations to GRASS or to make new GRASS installations where ESRI
products are an alternative.
Technically, I see a few problems in the comparison:
Most GRASS analytical tools are raster-based. The resolution and precision of
those analyses are scale-dependent. The vector-based tools provided by the
ESRI products can resolve detail and provide precision that are not dependent
on scale. For instance, in a GIS coverage that spans 10's of thousands of
square miles ArcInfo can accurately represent (e.g.) canals that are only a
few feet across. As a practical matter, GRASS's raster tools cannot do the
same thing. In my experience this is a capability of the vector-based tools
that is unnecessary and frequently abused, but it is still seen as an
advantage for the ESRI products.
ESRI offers a polished product with complete support at a pretty high price.
GRASS is not a polished product. It doesn't have many critical bugs left but
there are capabilities missing, planned features that aren't yet implimented
and software included in the GRASS source package that doesn't work. GRASS
has no licensing fees, but third-party support for GRASS is hard to find.
Large-scale GRASS installations need to be supported internally by one or more
people on staff who have a knowledge of GIS and the ability to modify and
debug C code and shell scripts.
GRASS tools are usually very conservative in their use of system resources.
That lets GRASS work on computers that are too underpowered to do the same
analysis with ESRI products. It also makes the analysis slow and inefficient.
GRASS's built-in database capabilities are poor -- they are not at all
competitive with ArcInfo. GRASS can interface with full-featured database
servers (Postgres, for instance) but the interface is cumbersome and incomplete.
I'm sure that a lot of agencies and companies that are currently working with
ESRI products could get the same jobs done with less money by switching to
GRASS and a freely-available database product. The real problem is to
convince decision-makers that GRASS can get the job done and save money.
Roger Miller