[GRASSLIST:112] Re: Considering replacing ESRI

[Jack Varga]

To add to Roger's thoughts...

The two most critical decisions I believe you have to make are:

1.  What are the functional requirements of the geospatial end users?
2.  What applications are available to fulfill those requirements?

ESRI tools have come a long way in the 20 or so years they've had a 
commercial product.  Their latest architecture, for as modular and 
extensible as it is now, has entirely neglected a large contingency of 
their user base, the open architecture end-user, (i.e., *nix).  That 
WAS their platform previous to their latest COM+ architecture that Arc 
8.x is built upon.  That is IMO, unfortunate and will drive users that 
cherish the power of open architecture,(opposed to open source), to 
seek alternatives.  It is also a sad testament to the leverage Microsoft 
has on the world.  I further believe that the collective world will 
eventually chose the open path when they reach the fork in the road 
requiring them to make a decision, (as it sounds like your organization 
has in their sites), reqardless of what some (influential) capitalists 
will try to impose on everyone else.  (FTR, I too am a capitalist - 
for now - just not one of the influential ones with a greedy desire 
to get to the top, and knock everyone else off). 

Last thought, the most critical component of spatial analysis is 
maintained not in the application, but in the data.  With the emergence 
and continuing improvement to open source projects like PostGIS (GPL 
license - although it extends PostgreSQL which uses BSD license), you're 
safe and may want to consider going this route first eliminating 
the high licensing costs of ArcSDE and Oracle, while still using 
ArcView as the application until a more robust vector-based open 
source geospatial analysis tool becomes available. It will, its 
just a matter of time and colaboration.

-jv


Quoting Roger Miller <roger at spinn.net>:

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