differences between QGIS and GRASS [was :Re: [GRASS-user] [Fwd: update of the training manual]]

[Moritz Lennert]

On 17/12/06 17:37, Gerald Nelson wrote:
> Is there some place on the web that discusses the differences between
> QGIS and Grass? 

Not that I know of. Maybe the content of this mail could become the 
basis of a FAQ...

> I haven't done any extensive research on this but it
> appears that QGIS is more about display and a GUI, and perhaps
> windows compatibility.

I don't know about the last point, but for the rest, you are correct. 
QGIS is mainly a viewer and map builder, although it also allows you to 
create new vector maps. In a certain way, it is more of an application 
framework which offers basic functionalities which you can then enhance 
through plugins.

One of such plugins is the GRASS plugin which gives you access to GRASS 
through QGIS, thus allowing you to use the somewhat easier interface of 
QGIS to access the power of GRASS. This plugin allows you to very easily 
build a custom interface to GRASS as you can chose the GRASS commands 
you want the user to see.

> There seems to be a lot of overlap in
> functionality. 

There is not much overlap between "pure" QGIS and GRASS, except for 
basic operations such as zooming, panning, etc.

The GRASS plugin to QGIS integrates GRASS into the QGIS framework, so 
there is obviously a lot of overlap. ;-)

> My guess is that there are many relatively new users
> of open source GIS software that would like some discussion on why
> the two.

The two are different programs, with different objectives and different 
histories.

GRASS is a very old GIS with very advanced features for raster and 
vector analysis. QGIS is a fairly new project (although already quite 
advanced) which in its basic state, as mentioned above, is mostly a 
viewer and map builder, but which can be enhanced through plugins, of 
which one is a plugin giving it access to the wonderful world of GRASS.

Actually, there regularly has been a debate within the GRASS community 
about whether we should abandon the development of a native GRASS GUI 
and rather maintain GRASS as a sort of library + command line modules 
and let the user then chose between other existing 'GUIs' such as QGIS, 
JGRASS, etc (without wanting to reduce these programs to simple GUIs).

The decision was made that GRASS should keep its own native GUI which in 
the current stable release is the tcltk-based GIS Manager and which in 
the future will be a wxpython-based GUI which is already in development.

I hope this answers you question.

Moritz