[GRASS-user] [GRASS-dev] Keeping GRASS/OTB/... algorithm in qgis processing

[Stefan Blumentrath]

Hi,

In general I would say that both sides (QGIS – GRASS) benefit from an integration like Processing or the GRASS plugin. QGIS gains algorithms, GRASS gains user base. And for the future, Rashads and Moritz proposal make indeed a lot of sense!

The text descriptor files have been a real pain for maintaining interfaces for GRASS integration in Processing as well as the GRASS plugin. In addition, they make usage of AddOns practically impossible for most of the QGIS users.

However, for QGIS (and this is true for both integrations), the module UI was deliberately simplified by hiding / removing “advanced” option or splitting modules into “sub-types”. In addition not all modules could be meaningful added to the two QGIS integrations (e.g. temporal modules in Processing). And finally, some require extra work on the QGIS side (like r.mapcalc).

So, I would assume that a --qgis-descriptor solution would be most appropriate. But that would still require additional work (beyond implementing a parser solution) if the principles for the GRASS module UI in QGIS should stay as it is, like:

-          Tagging options and flags as advanced or basic/main/common (could be an opportunity to consolidate terminology in the module UI in GRASS as well)

-          Deciding which modules to use / exclude from QGIS (and how to mark them)

-          …
Maybe also Ondrejs work could be useful here : https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI ?

Cheers
Stefan



From: grass-dev [mailto:grass-dev-bounces at lists.osgeo.org] On Behalf Of Rashad Kanavath
Sent: mandag 5. februar 2018 17.06
To: Moritz Lennert <mlennert at club.worldonline.be>
Cc: grass-user at lists.osgeo.org; grass-dev at lists.osgeo.org; Helmut Kudrnovsky <hellik at web.de>
Subject: Re: [GRASS-dev] [GRASS-user] Keeping GRASS/OTB/... algorithm in qgis processing



On Mon, Feb 5, 2018 at 2:49 PM, Moritz Lennert <mlennert at club.worldonline.be<mailto:mlennert at club.worldonline.be>> wrote:
On 05/02/18 13:51, Helmut Kudrnovsky wrote:
Von: "Moritz Lennert"
I don't know how difficult it would be to create such algorithm
descriptions automagically.
    https://github.com/qgis/QGIS/search?p=1&q=processing+grass&type=&utf8=%E2%9C%93

AFAIU there are some general python scripts to provide it in processing:

e.g.
python/plugins/processing/algs/grass7/Grass7AlgorithmProvider.py

No, this is the provider itself, not a tool to create the descriptions.

and there are a lot of txt files providing the module interface

e.g
python/plugins/processing/algs/grass7/description/r.out.png.txt
r.out.png
Export a GRASS raster map as a non-georeferenced PNG image
Raster (r.*)
QgsProcessingParameterRasterLayer|input|Input raster|None|False
QgsProcessingParameterNumber|compression|Compression level of PNG file (0 = none, 1 = fastest, 9 = best)|QgsProcessingParameterNumber.Integer|6|True|0|9

and other files

My question was whether it would be possible to create these description files more or less automagically.

I think the python scripts for more complex operations have to be created manually.

IIUC (from rapid reading of the threads on the qgis-developer list), Rashad's suggestion was to keep the *AlgorithmProvider code in the QGIS code base, but to possibly move the creation of the description and script files to a plugin managed outside QGIS core, possibly by the respective external software teams.

Yes. your are right on track! the idea is external tools (processing providers) manage descriptor files in a format requested by qgis processing.
I see already name-of-grass-module --interface-descriptor which gives an xml for GRASS gui.
what qgis want is a csv in a specific format. The contents of qgis descriptor seems much less compared to --interface-descriptor.
Correct me if I am wrong, --interface-descriptor is available in all grass modules. So maybe a --qgis can do the work.

This has some advantages.
* GRASS developers are free to fix parameter name, parameter description, list of modules(add and remove) changes without affecting qgis.
* grass 7.5 has 10 modules and grass 7.9 can have 15 and same QGIS will work.
* QGIS will not need to maintain these files and keep updating/adding new modules with their release process. whatever is generated from a grass build/install have better integration with qgis
* Finally this descriptors for qgis are generated with a makefile target that allows users and packagers to include it.
* QGIS can use multiple version of grass by changing install prefix because descriptors are *always* found in a directory relative to install prefix.

QGIS provider will be like:
I picked a descriptor file
parse and make the ui,
take input and execute whatever program the descriptor is to run.

QGIS already manages parsing of parameters and running them. So for providers who wish to be integrated in qgis will deal with a descriptor file and things go fine.

Having a single interface to launch all or most of toolboxes (willing to contribute descriptor with installation) can have same way of execution. At that point, QGIS should consider
adding some generic code in provider and avoid plugins for such toolboxes.




Moritz

_______________________________________________
grass-dev mailing list
grass-dev at lists.osgeo.org<mailto:grass-dev at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/grass-dev



--
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20180205/2754def5/attachment-0001.html>