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

[Saber Razmjooei]

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-bounces at lists.osgeo.org
[mailto:grass-dev-bounces at 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: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
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 



--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  benducke at fastmail.fm
_______________________________________________
grass-dev mailing list
grass-dev at 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.