[GRASS-user] what is jgrass

[Michael Barton]

Jerry

jgrass was started some years back, when GRASS had a pretty primitive GUI.
As best I can tell, it creates a GUI in JAVA and uses GRASS libraries to
carry out a limited suite of geospatial processing activities (mainly
hydrologic modeling). For a long time, jgrass was using the GRASS 5
libraries. I don't know if it has upgraded to GRASS 6 or not. As of a year
ago, jgrass merged into uDIG, and I don't know if it is still using GRASS
libraries as a geospatial analysis engine or not.

QGIS is basically an easy to use viewer for geospatial data. A couple years
ago, Radim Blazek--a former GRASS developer--joined the QGIS project. He has
made a number of GRASS processes available to QGIS through its plugin
architecture to give QGIS some nice analytical capabilities. QGIS is written
in C++ I think, and its GUI is done in QT.

There are also other projects that add a GUI interface to a selection of
GRASS routines (e.g. http://www.um.es/geograf/sigmur/wxgrass/wxGRASS.html --
not to be confused with the new GRASS project interface in wxPython).

GRASS, of course, is a very large, complex, and complete general-purpose GIS
for geospatial data management, processing, analysis, and visualization.
Because GRASS is open source and modular, it lends itself well to use in
other projects that have different and often more specific software goals.
That is an important part of what open source is about. GRASS uses GDAL and
PROJ4, for example.

It would be wonderful to have some of the talented people of these other
open source GIS projects contribute directly to GRASS (and there is in fact
communication between the main GRASS development team and people on most of
these other projects). But this is also one of the features of open
source--it's all volunteer. People working on any of these projects do so
because they are inspired to do so for some reason--creates a tool to help
them in their particular research or job, they really like working in a
specific platform, etc.

GRASS is written primarily in C, with many additional modules created as
BASH scripts that chain together C modules. The GUI needs to be something
that works well with C, is cross-platform, and relatively easy to work with.
TclTk (used for the default GUI) fits these criteria very well. We are in
the process of switching the GUI to wxPython, which also fits these criteria
and is an even richer GUI development platform. There is a talented team of
folks working on the wxPython GUI, so development is going quite fast.

Those of us working on the GRASS project, feel it is a worthwhile endeavor
to make ALL of GRASS available to users on as many platforms as possible,
and to make it as accessible to a wide range of users--from those who prefer
to work from the command line and script GRASS modules into custom solutions
to users who prefer a full GUI environment. It is a testament to the
long-term value of the GRASS project that it is also used in an array of
other open source software.

Cheers
Michael

On 9/16/07 7:16 PM, "Gerald Nelson" <gnelson at uiuc.edu> wrote:

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

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton