Hi all, Here is my wish list:
- To be able to access GRASS data within QGIS. Similar to PostGIS and other GDAL/OGR data sources, it should be up to users to create GRASS geodatabase/location/mapsets. QGIS will be able to simply add layers for viewing and editing - Having access to GRASS shell. It will be a very handy shortcut to run GRASS modules without the need to open GRASS. GRASS modules which are available in Processing toolbox can use the same UI. Otherwise, user has to run it in shell. - Simple import data to the mapsets...similar approach as drag-n-drop for PostGIS databases. Right-click and save as... in QGIS does a great work for Export. In summary, Processing toolbox should be a good one-stop for one-off use of a specific GRASS module. But if a user wants to dig more, GRASS already offers all that. For those who have already got their GRASS set up, they should be able to view and edit their data in QGIS with the added benefit of having access to shell. Some of the stuff can be ported to plugin(s) as mentioned by others: e.g. creating location/mapsets, setting region from qgis canvas or other qgis layers, etc. Cheers, Saber -----Original Message----- From: grass-dev-boun...@lists.osgeo.org [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Benjamin Ducke Sent: 27 March 2014 14:31 To: grass-dev Subject: Re: [GRASS-dev] [Qgis-developer] GRASS & QGIS: the future 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 -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Whilst reasonable care has been taken to avoid virus transmission, no responsibility for viruses is taken and it is your responsibility to carry out such checks as you feel appropriate. If this email contains a quote or offer to sell products, carry out work or perform services then our standard terms and conditions (which can be found at http://www.lutraconsulting.co.uk/downloads/Lutra%20Consulting%20Standard%20Terms%20and%20Conditions.pdf shall apply unless explicitly stated otherwise. Saber Razmjooei and Peter Wells trading as Lutra Consulting. _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev