[Qgis-developer] [GRASS-dev] 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 Qgis-developer
mailing list