grass4.0 performance

[Kenn Gardels]

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

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