[GRASS5] Re: KerGIS

[Markus Neteler]

On Mon, Jan 26, 2004 at 12:00:39PM -0800, Jeff D. Hamann wrote:
> 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).

Did you ever try GRASS 5.7? If you refer to 4.x, 5.0-5.3: yes, vector
management is poor. But 5.7 is quite different. We would be glad to
hear comments why you (dis)like 5.7.

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

Again 5.7: No more Gmakefile. Since 2001/2002 (can't remember precisely).

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

Several developers prefer to work on 5.3 - even if things should have
been already merged into 5.7.

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

No. Because then people would complain that backward compatibility is not there.
Indeed 5.3 should go into 5.7 while undergoing a code cleanup. But there
is not too much interest in that IMHO.
As long as the developers base for 5.7 is so small, we will have to live
with that odd "merge" problem. It's way to much work for "2.5 people" to
also merge 5.3 changes into 5.7 in case the code were replicated there.

> If I could get everthing to compile on my BSD platform, I would use it
> there.

5.7 was reported to compile successfully on FreeBSD. Did you try?
Then: I didn't see any error reports for BSD.

> If I could get everything to compile on cygwin, I'd use it there. But
> they don't. 

You could simply download precompiled version from the grass.itc.it web
site (Linux, Cygwin, MacOSX soon).

> There's just too many switches and options for a simple (for
> example)
> 
> ./configure
> 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.
> Why?

Because there aren't enough people to sort out this problem. 
If it helped, we could merge the code into 5.7. But then I expect
a major desaster:  5.3 will receive changes and some developers
regularly ignore to update the relevant files in 5.7 as well.
I try to hunt for those files, but it's not that easy.

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

We are using gdal/GRASS daily - what's the problem on which platform?

> My Database is MySQL and my
> stats package is R (which seems to have be best model for development I've
> seen so far).

Yes, because R has x times so many developers.

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

So you are welcome to participate. There are plenty of things to do.

> Okay, this seems a bit long winded so I'll shup now. And thanks for hearing
> my pleas.
> 
> Thanks for the good work,
> Jeff.

Markus