[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
> <or not.  Is there solid interest of the SAGA or GRASS team to adopt the
>> 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