[GRASS-dev] [Qgis-developer] GRASS & QGIS: the future

Blumentrath, Stefan Stefan.Blumentrath at nina.no
Thu Mar 27 06:38:52 PDT 2014


That sounds very reasonable to me.

Proper GDAL/OGR handling for GRASS 7 would be very nice in any case (see http://trac.osgeo.org/gdal/ticket/2953).

As for a "GRASS data browser", I think, a plugin would be required with regards to user friendliness, because one needs to know what files to access from a GRASS data base when using GDAL.

I also understand that at some point in time one will have to use GRASS directly in order to access full functionality (e.g. ortho-rectification, nviz, mapswipe, animation and stuff), which makes the way Moritz suggests maybe even more reasonable...

Cheers
Stefan
 



-----Original Message-----
From: Moritz Lennert [mailto:mlennert at club.worldonline.be] 
Sent: 27. mars 2014 13:36
To: Blumentrath, Stefan
Cc: Paolo Cavallini; Nathan Woodrow; qgis-developer; grass-dev
Subject: Re: [GRASS-dev] [Qgis-developer] GRASS & QGIS: the future

I'm not much of a QGIS-as-GRASS-frontend user, either, but from a general point of view I also think that duplication is a problem and that the current way to go in QGIS is the processing framework. So;

On 27/03/14 12:49, Blumentrath, Stefan wrote:
> I understand well the point; however, the plugin has additional functions, e.g.:
> * a grass shell

couldn't this be implemented within the processing environment ?

> * a grass data browser

If we are talking about accessing GRASS data for loading into QGIS, wouldn't it be a better idea to improve the GDAL/OGR handling in order to be able to load GRASS data just like any other data format ?

> * a grass digitizing environment.

Maybe this could be split out into a specific plugin ?

Moritz


More information about the grass-dev mailing list