[Qgis-developer] GRASS & QGIS: the future

Bernhard Ströbl bernhard.stroebl at jena.de
Thu Mar 27 04:12:15 PDT 2014


Hi Paolo,

my QGIS/GRASS usage is as follows:
1) To process in GRASS I I do neither use the plugin nor processing but 
"native" GRASS
2) I use the plugin to visualize the results, especially together with 
data in other formats (shp, raster) which I otherwise had to import into 
GRASS
3) I use processing but not with GRASS processes.

So I would propose a third way which negotiates between the two ways 
porposed by you:
* upgrade processing and reduce the plugin to those features not covered 
by processing (visualization, digitizing ...)

IMHO if someone wants fast processing with GRASS modules he should do it 
in GRASS, if automation is needed a shell script is the way to go, so no 
need to change processing in the proposed way (no export/import if 
consecutive GRASS operations), though this would be nice to have, of 
course :)
If there are many persons out there that use processing for consecutive 
GRASS processes and think this is too slow and are not capable of doing 
it in GRASS, please step forward!

my 2 cents

Bernhard

Am 27.03.2014 11:18, schrieb Paolo Cavallini:
> Hi all.
> I learned during dinner that GRASS7 RC1 is due very soon. This opens the
> issue of its functioning in QGIS. IMHO:
>
> * the qgis-grass-plugin might stop working (this has to be tested)
> * some of the module options will be different
> * new modules will not be available in QGIS.
>
> I think we can deal with this in several ways:
>
> * dropping the plugin, and concentrate the work on Processing
> * upgrading both the plugin and Processing.
>
> In the first case, we have two major issues:
>
> * upgrading Processing GRASS modules
> * changing the current Processing behaviour, avoiding the import-export
> phase when piping consecutive GRASS commands; this makes GRASS modules
> slower than the equivalent commands of other backends.
>
> While the first issue can be solved easily by a couple of people in a
> few days, the second one is more tricky, and requires hard coding skills.
> In addition, we'll no longer be able to edit GRASS vectors directly.
>
> In the second case, we'll have more work, and a not-so-nice duplication.
>
> I would like to have an open discussion on this, avoiding things to just
> happen, with the possible negative consequences.
>
> All the best.
>



__________ Information from ESET Security, version of virus signature database 9601 (20140327) __________

The message was checked by ESET Security.

    part000.txt - is OK

http://www.eset.com




More information about the Qgis-developer mailing list