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

[Rashad Kanavath]

On Mon, Feb 5, 2018 at 2:49 PM, Moritz Lennert <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)|QgsProcessingParameterNu
>> mber.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
> 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/1bd07b6e/attachment.html>