grassp-list at amber.cecer.army.mil
Mon, 20 Jul 1992 18:33:07 PDT
> Regarding GRASS as a "toy" GIS. In my view the only difference between
> the GRASS "toy" and the rest of the options is 1) The color glossies
> distributed by a sales staff and 2) the price.
> See any of the various comparison articles and reviews. GIS world
> does an annual review. GRASS always looks pretty good!!
I second Jim's comments about the promotional aspects of GIS. Unfortunately,
those arguments aren't going to carry much weight with those arguing that
GRASS is a toy GIS. I offer the following specific points that are reasons
people sometimes say GRASS is a toy, and suggest a response.
1. GRASS doesn't (even) have a DBMS with it.
The nature of GRASS (or any full raster GIS) is that it does not
need a DBMS to provide attribute management, since the data model
is a geo-relational one to begin with. That is, phenomena are
described in terms of spatial location by their x,y position within
the cell file and in terms of attribute by their numerical value
within the cell file (ie raster). Reclass is in some ways a poor man's
DBMS supporting multiple attributes and aggregation, but in fact it
does so much more efficiently than a "real" DBMS.
No DBMS is required until you get to the point of handling complex
attributes for bounded objects (areas, lines). For these there are
options to use RIM or to link to external databases using the Arkansas
2. Raster data are imprecise (and produce ugly maps).
This isn't a GRASS problem, but rather a data model bias stemming
from days when raster data was of necessity of low resolution due
to I/O and storage limitations. (Vector data were more compact, but
at enormous computational expense.) Today, maps with 10 to 100 million
pixels/cells can be managed and processed. Unfortunately, the
Spearfish sample database, though extremely useful at demo-ing various
capabilities, is a product of that earlier age in some respects, and
reinforces the impression that only low-res data can be used.
Vector resolution is similarly limited by boundary capture methods
(vertices approximating a curve, arcs, splines, etc), and when you
enlarge vector maps enough, they show problems analogous to those
of raster maps. By the way, no one seems to know that GRASS can do
anything in the vector domain.
3. GRASS can't output decent looking maps.
This is like saying Autocad isn't any good at dynamic simulation -
you have to use the right tools for the job. GRASS is primarily
an analytical system. The output tools are for rendering on paper
the results of various analyses, not for cartographic production.
Related software like mapgen will give you all the cartographic
flexibility you want.
4. There aren't tools to do X, or they aren't any good.
First, a lot of systems include functions that someone wanted once
or which are designed to overcome some other limitation of the
software. A strict side-by-side comparison of number-of-commands
is meaningless in this context.
Second, many published checklists of necessary GIS features list
specific methods for performing an operation, not generic capabilities
which are needed for solving a problem. For example, they may cite
polygon overlay, when they really mean boolean combination.
Third, a side-by-side performance comparison using the best method
available in each of two or more systems is the only fair benchmark.
It's easy to bias such tests in favor of one approach otherwise.
[We are currently attempting to create such a benchmark. Extremely
preliminary results show GRASS better in many areas than some
competing systems. Complete results are scheduled for publication
in January 1993.]
Fourth, the accessibility of subroutine libraries means a knowledgable
programmer can implement any algorithm he/she wants (and many have!).
4. There's no support for GRASS.
The existence of this list should dispel that notion. Also, there
are some very capable consulting offices providing various types of
programming and application support in GRASS.
If there is one common theme to the complaints about GRASS, it is that they
are based on misinformation or lack of knowledge. If there is a theme to
some of the suggestions I have made, it is that GRASS's strength is in the
ability to link it to other software systems and tools, in a way that private
software companies like to talk about but almost no one does.
The newly formed Open GRASS Foundation has a long-term strategy to promote such
linkages with various systems and to encourage system developers to adhere to
open standards such as GRASS. This will not only improve GRASS-based
geoprocessing, it will broaden the base of support and interest in ensuring
its long-term viability. Much more on this later....