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

[Benjamin Ducke]

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