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

[Rashad Kanavath]

rface module=
> m.odule.name format=qgis" which can take the general (or generalized)
> --interface-description and transform it to what the processing adapter
> tool needs (or it can be just part of the adapter).
>
>
>
>> 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
>>
>
> We already have the sections and also required parameters marked (in GUI),
> so the question is why it is not enough. Perhaps just fixing that is enough
> (for example description for each group). But of course if we say that the
> requirement for QGIS alg is that there is less than 5 options and no flags,
> then we need some additional system.
>
>
>> (could be an opportunity to consolidate terminology in the module UI in
>> GRASS as well)
>>
>
> I think one of the challenges brought up in the past was GRASS terminology
> versus QGIS terminology. We don't have a comparison table for that, but we
> have one for ArcGIS [1] and there are some obvious things like "vector map"
> versus "vector layer" and than GRASS' "layer of vector map".
>
> I can see 3 solutions: 1) ignore the differences, 2) come up with
> different names (I think we have been there already), or 3) have a special
> description field which is QGIS-friendly or OGC glossary compliant if
> needed.
>
> [1] https://grasswiki.osgeo.org/wiki/Terminology_comparison_betw
> een_ArcGIS_and_GRASS_GIS
>
>
>> -  Deciding which modules to use / exclude from QGIS (and how to
>> mark them)
>>
>
> We have the "toolbox" mechanism to populate things in wxGUI, so the files
> can be reused to create algorithm tree for QGIS. One needs to add the
> modules there explicitly and then additionally find addons, but we do that
> for wxGUI now.
>
>
>> -  …
>>
>> Maybe also Ondrejs work could be useful here :
>> https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI ?
>>
>
>
> Yes, for the QGIS GRASS plugin. I'm not sure how much the plugin is part
> of this discussion. Not long ago, Radim worked on it a lot. Ondrej's work
> is aimed at what the C++ plugin is aimed at and what wxGUI is aimed at -
> i.e. it's a Qt interface to GRASS which could be used in GRASS or as QGIS
> plugin. I don't think it is useful for the processing part, but it is a
> good prototype to start from. Currently it misses a lot of features, it is
> basically limited reimplementation of gui/.../forms.py. There is also some
> raster rendering work from Soeren which is parallel to the C++/C part of
> the QGIS GRASS plugin.
>
> Best,
> Vaclav
>
>
>>
>>
>> Cheers
>>
>> Stefan
>>
>>
>>
>>
>>
>>
>>
>> *From:* grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] *On Behalf
>> Of *Rashad Kanavath
>> *Sent:* mandag 5. februar 2018 17.06
>> *To:* Moritz Lennert <mlenn...@club.worldonline.be>
>> *Cc:* grass-u...@lists.osgeo.org; grass-dev@lists.osgeo.org; Helmut
>> Kudrnovsky <hel...@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 <
>> mlenn...@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=processing+grass
>> ==%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 

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

[Vaclav Petras]

or the QGIS GRASS plugin. I'm not sure how much the plugin is part of
this discussion. Not long ago, Radim worked on it a lot. Ondrej's work is
aimed at what the C++ plugin is aimed at and what wxGUI is aimed at - i.e.
it's a Qt interface to GRASS which could be used in GRASS or as QGIS
plugin. I don't think it is useful for the processing part, but it is a
good prototype to start from. Currently it misses a lot of features, it is
basically limited reimplementation of gui/.../forms.py. There is also some
raster rendering work from Soeren which is parallel to the C++/C part of
the QGIS GRASS plugin.

Best,
Vaclav


>
>
> Cheers
>
> Stefan
>
>
>
>
>
>
>
> *From:* grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] *On Behalf
> Of *Rashad Kanavath
> *Sent:* mandag 5. februar 2018 17.06
> *To:* Moritz Lennert <mlenn...@club.worldonline.be>
> *Cc:* grass-u...@lists.osgeo.org; grass-dev@lists.osgeo.org; Helmut
> Kudrnovsky <hel...@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 <
> mlenn...@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=processing+grass
> ==%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@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
>
>
>
> --
>
> Regards,
>Rashad
>
> ___
> grass-user mailing list
> grass-u...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] 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-boun...@lists.osgeo.org] On Behalf Of Rashad 
Kanavath
Sent: mandag 5. februar 2018 17.06
To: Moritz Lennert <mlenn...@club.worldonline.be>
Cc: grass-u...@lists.osgeo.org; grass-dev@lists.osgeo.org; Helmut Kudrnovsky 
<hel...@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 
<mlenn...@club.worldonline.be<mailto:mlenn...@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=processing+grass==%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 

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

[Moritz Lennert]

On 05/02/18 17:06, Rashad Kanavath wrote:



On Mon, Feb 5, 2018 at 2:49 PM, Moritz Lennert 
> 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=processing+grass==%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.


Yes, this is what I was aiming at.



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.


Thanks for the explanation / confirmation, Rashad.

Now, the question is whether this is in line with the ideas of the QGIS 
developers...


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Rashad Kanavath]

On Mon, Feb 5, 2018 at 2:49 PM, Moritz Lennert  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=processing+grass
>> ==%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@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Regards,
   Rashad
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Moritz Lennert]

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=processing+grass==%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.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Helmut Kudrnovsky]

>I don't know how difficult it would be to create such algorithm
>descriptions automagically.
 
 for a better overview:

processing module description:

https://github.com/qgis/QGIS/tree/9fb386ac60f5e3155294b712ed064ad97eba3226/python/plugins/processing/algs/grass7/description

and related python helper scripts for more complex GRASS modules:

https://github.com/qgis/QGIS/tree/9fb386ac60f5e3155294b712ed064ad97eba3226/python/plugins/processing/algs/grass7/ext

Helmut

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Helmut Kudrnovsky]

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=processing+grass==%E2%9C%93

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

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

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

kind regards
Helmut

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Moritz Lennert]

On 05/02/18 12:40, Helmut Kudrnovsky wrote:

Dear GRASS GIS community,

herewith I may bring a discussion on QGIS dev ML about how to proceed with
maintaining GRASS, OTB and other algorithms in qgis processing to your
attention.

http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Keeping-OTB-algorithm-in-qgis-processing-td5352056.html

it seems that a shared attempt may be needed for a long-term, sustainable
solution.

citing here my post in that thread:
https://lists.osgeo.org/pipermail/qgis-developer/2018-February/051892.html

---

Otherwise if we don't care and just want to enable others to have QGIS
intgration, they'll have to adopt the plugins.  That might work better if

there

is real interest.  But I think they usally prefer their tools to be used in
their own environment and don't care that much about whether it works in

QGIS

providers?  Otherwise I guess they'll sooner or later will die.


quickly screened the GRASS MLs, I can't find any entry that the GRASS
community was ever asked if there could be e.g. a shared attempt for an
automatization to create/maintain the plugin code.

Looking at the new OSGeo website:

*Desktop Applications*

-QGIS Desktop
-GRASS GIS

*Geospatial Libraries*

-Orfeo ToolBox
-GDAL/OGR

*Meta CRS Initiative*

-PROJ4

Most of the software mentioned in this thread are projects under the common
umbrella of OSGeo.

An option may be to ask that OSGeo plays a more proactive role in helping to
coordinate and supporting (technically/financally/...) such inter-project
challenges.

I will forward a short summary of this thread to the GRASS community.
--

contributions of ideas/support/technical solutions/... are very welcome.


The debate is about whether the access to outside tools (i.e. the 
'providers') should be kept within the QGIS core code, or whether this 
should be externalized to plugins, with the hope that others (the 
respective software teams ? users ?) take over the maintenance of these 
plugins.


GRASS seems to be seen as something of a border case, also because of 
the existing tight (C++ level) linkage between the two through the grass 
plugin.


One suggestion coming from Rashad (OTB team) seems to be to leave the 
core part of the providers in the QGIS core code (in the idea that that 
would ensure that they would be kept up to date together with the core 
code), but to leave it up to the respective teams to provide the 
algorithm descriptions. But I didn't have the feeling that the QGIS team 
was up to that...


I don't know how difficult it would be to create such algorithm 
descriptions automagically.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev