Future direction

Rich Shepard rshepard at appl-ecosys.com
Tue Jan 11 12:30:01 EST 2000


On Tue, 11 Jan 2000, Bernhard Reiter wrote:

> > Angus Carr wrote:
> > > Based on one day's return comments, people on this list see the
> > > "arcviewization" of GRASS as a good possible thing.

> The tale is that a good programmer knows, when to start over again and
> put code aside. GRASS is a very useful and rich GIS tool, but I cannot
> see how it will ever be a simple mapping and visualisation tool.

  I read a bit of confusion here. The Microsoft-centric world started with
what we would consider GRASS to be: a GIS-engine used to enter, store,
manipulate, analyze and report on spatial data. That is, attributes related
to specific places on the Earth. The two fundamental questions are: What is
where? and Where is what? The strength of GRASS (like that of ARC/Info and
Idrisi) is data analyses. I, for one, do not want to lose this ability. As a
matter of fact, I'd like to see it strengthened in the vector-data area and
tie everything to the postgres RDBMS and the R statistical language. Most of
the applications relate to the natural world.

  In the Microsoft-centric world, MapInfo saw an opportunity for a different
spatial tool: desktop mapping. (Perhaps others were first; I neither know
nor care.) "Desktop mapping" was/is aimed at the business market and the
focus was on pretty displays (on screen or paper) with comparatively simple
and limited analyses. The end user was expected to purchase data (ideally,
from the desktop mapping software vendor), not generate them from scratch.
US Census Bureau data focusing on urban areas form the nexus of the
available data. ESRI saw the potential of this market (i.e., end-user
oriented rather than guru-user oriented) and entered with ARCview.

  I've not followed this discussion in depth (too much to do right now), but
I suggest that there is great value in taking GRASS in both directions. That
is, the core should be strenghened as a powerful analytic engine for all
sorts of data types while different UI modules be developed to hook on the
back end as needed.

  A MapInfo/ARCview type end-user UI would be the perfect front end to GRASS
in business applications. The command line and GUI interfaces can be
developed in parallel for those who need (or prefer) the increased power and
accessibility to functions.

  As for languages, I prefer C and gtk+ for the UI. I recognize that we need
something to make GRASS accepted by the Windows user, and I defer to those
of you with more expertise in this area. The UI for linux, solaris or
win9x/Nx/2x should be interchangable modules.

Enough from me,

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)         
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
 + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard at appl-ecosys.com




More information about the grass-user mailing list