[GRASS-user] what is jgrass

[Andrea Antonello]

Dear list,
Some of the answers given to that post are right, I will try not to
repeat everything already said, but I feel it is very important to let
you guys know why we from the JGrass team started all this (and are
going on happier than ever in this), which seems for some of you a
reinventing the wheel, but I can tell you that this is not what is
happening.

JGrass started back some year ago as a project that wanted to get a
userfriendly and portable GUI for GRASS. We needed GRASS to be easily
portable, which at that time it wasn't :)
So we started in java and put our about 40 modules related to
hydro-geomorphology into that. As Moritz states in his email, things
turned out different than expected and we were never able to gain new
developers, never able to build up a developing community, which made
JGrass fall in deep depression. 
At that point resources had been put into JGrass and the business of
some engineer (I'm one of those) here in Italy was depending on JGrass
(and yes, Italian politics is much more complicated than others,
whenever we have one regular :)).

So we decided to somehow reinvent the wheel in java for some of the
basic GIS tools and the raster format in order to be able to run JGrass
for hydro-geomorphology also without a big-GRASS-father installation.

Inside JGrass every non-interactive GRASS command can be executed and
we try to keep GRASS compatibility where possible. So nothing is going
to be rewritten. Also the difficult things are left to GRASS, since too
many new GISSes are growing, but when it comes to thing like
reproject properly I trust only in GRASS.

The fact however is that we sold already two JGrass adaptions to public
administrations here, where GRASS would never have been a choice, so I
think we were right in our decision to make a less powerful, but more
userfriendly GRASS. 

In the last moves of the GRASS community I see a direction towards the
establishment of a GRASS library. That is very good for all the projects
like JGrass and QGis and for this we give many many thank to the GRASS
community, of which I always felt to be part of. The power of the GRASS
library is built on years and years of knowledge and I don't think that
some free GIS project will ever gain that power (and why should it
want?), but when it comes to GUI and userfriendlyness, more factors come
into the game and the decisions and choices are even based on the place
you live... and here we are back to politics :)

So I will go on in JGrass, developing algorithms in java since it takes
me a third of the times it took me when I used to program in C and
go on to migrate JGrass into UDig, in order to join a bit different
worlds, since it is also my feeling that too many different projects
do same things :).

I hope this somehow gave an answer to your mail,
Warmest regards,
Andrea




__________________________________________________________________

I saw a recent post that included a reference to jgrass, which I had
never heard of, so I went to the jgrass website, downloaded the manual,
and spent about 3 minutes browsing it. One thing that struck me is the
question of why is there both a jgrass version, written for
cross-platform use, and the new efforts to make 'regular' grass (the
6.3 version we use around here on linux) run on windows and the mac.
And for that matter there is qgis out there, which also has its own gui
and uses grass code to do some gis things. From afar, it seems like
there are some really talented, and incredibly dedicated, people out
there who are kind of reinventing the same wheel.

Are there some politics I don't know about (it seems like an important
part of these efforts is happening in Italy. Are Italian politics even
more complicated than other politics?), are there really important
differences among these efforts, is it just the nature of OS
development efforts, or some combination of all of the above.

I hope noone is offended by these remarks. I watch the list traffic for
6.3 users and developers and am amazed by the way some very bright
people, who might not ever have been in the same room together,
collaborate productively. I'm just wondering late on a Sunday evening
if there are ways to make this effort more efficient. As spatial data
become ever more available, and processing costs continue to fall
rapidly, open source tools for both exports and the masses become ever
more valuable.

Regards,
Jerry
Gerald Nelson
Professor, Dept. of Agricultural and Consumer Economics
University of Illinois, Urbana-Champaign
office: 217-333-6465 
cell: 217-390-7888
315 Mumford Hall
1301 W. Gregory
Urbana, IL 61801