Jeff D. Hamann jeff.hamann at forestinformatics.com
Mon Jan 26 15:00:39 EST 2004

I've been reading the current news on KerGIS this morning and I'm glad to
see the initiative regarding quality control and the addtional resources to
the underdeveloped and overworked GRASS developement pool. I've been wanting
to utilize GRASS (as well as contribute) for a couple of years now and (and
I'm not trying to gripe too much here and I'm not criticizing) it seems that
the goals are constantly shifting as well as feature creep regarding the
architecture. With all the development that has gone on in the last couple
of years, GRASS still cannot handle some of the most basic of vector and
database operations to satisfaction in a production environment. I think
GRASS can be an awsome GIS tool (and in lots of respects it *is* -- raster
and satellite processing mostly).

I read the news regarding KerGIS with great enthusiasm as I've wished for
such an event to happen for a couple of years. I think it just what the
doctor ordered for the code. No more gmake5, etc. Fixing and simplify and
remove optimizations! Yes, yes, yes...  I've been thinking about doing this
for a couple fo years now, but since I've got to continue to produce and
can't spend the time to do anything other create small supporting packages,
I've not had the chance. As it stands now, I'm not sure where to contribute.
There are *at least* three code streams for GRASS (5.0, 5.3 and 5.7 -- not
to mention 4.3) This seems to be the opposite of fix and simplify. And none
of them seem to include the capabilites I need. In order for 5.7 to work, I
need the code for 5.3. Why? Shouldn't all that new code simply go into 5.3?

If I could get everthing to compile on my BSD platform, I would use it
there. If I could get everything to compile on cygwin, I'd use it there. But
they don't. There's just too many switches and options for a simple (for

make --with-mysql
make install

to work (at least for the 5.0.3 source code). For the 5.7 source code, you
need 5.3 source code and the cygwin "weekly" binaries for 5.7 aren't availab
le. I've not seen a project with so much connection between code streams.

Almost all of my work is with vectors and the attributes, lots of attributes
of polygons (adjacency lists, unions, intersects, area calculations, and
attributes -- think FRAGSTATS woulodn't it be nice to have a version for
GRASS for people to build on). For my projects, I'm constantly moving files
between GRASS and Arc/Info and ArcView for projecting files across all sorts
of projections, datums and coordinate systems and I have yet to be able to
accomplish this in GRASS simply because I can't gdal/GRASS to work resulting
from some sort of goofy circular dependencies). My Database is MySQL and my
stats package is R (which seems to have be best model for development I've
seen so far). These are two great packages and the development process is
solid almost militant in nature. MySQL releases a couple of times per year
as does R and it seems GRASS has been limping along in the meantime. We need
help. Isn't there an institution that promotes the development of GRASS
where people can work on it full time? It seems that the overworked
developers are spread pretty thin and the project needs a small army of
people pushing on.

Okay, this seems a bit long winded so I'll shup now. And thanks for hearing
my pleas.

Thanks for the good work,

Jeff D. Hamann
Forest Informatics, Inc.
PO Box 1421
Corvallis, Oregon USA 97339-1421
(office) 541-754-1428
(cell) 541-740-5988
jeff.hamann at forestinformatics.com

More information about the grass-dev mailing list