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:mlenn...@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 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
