In the gvSIG CE project, we had to make the same type of decisions and came to our own conclusions.
Allow me to summarize our reasoning, maybe it will be useful for the QGIS project, as well: 1. The number one cause of irritations among novice users is having to set up a GRASS mapset and having to understand how GRASS data management works. 2. The number two cause of irritations are the effects of importing vector data with bad topology into a GRASS mapset. 3. The original QGIS plugin does nothing to alleviate (1). No plug-in, however cleverly designed, can do anything about (2): garbage in, garbage out. 4. GRASS "power users" gain very little (if anything) from running GRASS through a host GIS, such as QGIS or gvSIG. But they do lose functionality, such as the d.* family of modules. Therefore, we gave up trying to design a plug-in for advanced users. We assume that such users will use GRASS through its native CLI and/or native GUI. The resulting design of the original SEXTANTE-GRASS interface (which is now also mirrored in the Python re-write that became QGIS' Processing) addresses users that either don't care much for GRASS' CLI capabilities and internal data management, or are willing to switch to native GRASS as needed. If you want to change this and address another type of user, then you will need to re-examine the entire design of the current SEXTANTE/Processing approach, which is to use only temporary mapsets and perform data import/export every time a GRASS module is run. You can optimize the I/O performance of Processing by using r.external to directly access raster input maps. But there is little you can do about vector data with the current design, as GRASS needs to build its own topological data structures (and rebuild them every time you run a GRASS module on non-topological input!). In any case, I do not think that it is worth maintaining the original QGIS plugin, since it is neither very well suited for novice nor advanced users, IMHO. Best, Ben On 27/03/14 14:38, Blumentrath, Stefan wrote: > 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 > -- Dr. Benjamin Ducke, M.A. {*} Geospatial Consultant {*} GIS Developer bendu...@fastmail.fm _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev