[QGIS-Developer] Keeping OTB algorithm in qgis processing

[Nyall Dawson]

On 31 January 2018 at 20:23, Alexander Bruy <alexander.bruy at gmail.com> wrote:
> Another reason to remove providers is that algorithms descriptions
> were not updated and maintained. Even now both SAGA and GRASS
> providers are not updated to latest stable versions of the corresponding
> software.
>
> We just simply does not have enough resources to maintain more than
> 600 algorithms from GRASS and SAGA. Situation with OTB, was even
> worse, it requires special handling of the parameters.
>
> I still think that Processing should be in core with minimal set of algorithms
> (native and GDAL), all other providers should be plugins and installed by
> users. Ideally these providers also should be maintained by interested groups
> of devs/users, not by QGIS devs.

A big +1 to everything Alex said above, and a strong -1 to
reintroducing any of these providers back to master (and also a +1 to
shifting the SAGA provider to a non-default plugin).

My reasons:

- we have a very strong plugin infrastructure designed EXACTLY for
these use cases. Having these providers as separate plugins, free from
the QGIS release cycle makes a ton of sense. Plugins devs can then
push new versions of their providers whenever new versions of the
underlying libraries are available, and not be constrained by waiting
until the next QGIS release.

- years of experience has PROVEN that we do not have the capacity to
maintain these providers ourselves. Numerous developers have tried,
and just been swamped by the amount of work required to keep the
providers stable while the underlying libraries change. The QGIS team
is running at capacity just keeping QGIS maintained and stable - we
CANNOT take on this extra work.

- regardless of the approach taken, things just don't stay stable for
us. E.g. we tried to make the SAGA provider more stable by only
targeting the SAGA LTR release.... yet the SAGA upstream seem to have
abandoned the LTR, leaving it totally broken on newer build chains. I
cannot get SAGA LTR to run on my development platform (Fedora) as it
constantly segfaults. End result - even if I had the time to maintain
this provider, I would be totally unable to. (For this reason I think
SAGA should also be moved to a separate QGIS plugin, leaving on QGIS,
GDAL and GRASS provided in the default install. GDAL and GRASS
(mostly) are always available wherever QGIS is.).

- While QGIS 3.0 has introduced big changes for processing, these are
likely to be the last big changes processing providers will see for
the future. At least for the next 3-4 years (or lifetime of 3.x) the
API will be fixed. And even following that, I'd envision any breaks
introduced in 4.0 to be much less extreme. So while it's painful for
plugins to update their providers for 3.0, it's a one-time pain. In
contrast, expecting QGIS devs to follow the numerous underlying
library changes and version breaks for multiple 3rd party dependancies
is exhausting, ongoing work. It's much more sensible for someone
intimately familiar with those libraries to maintain a plugin which
closely tracks the library development and follow best-practice API
use for that library.


Nyall



>
> 2018-01-31 12:17 GMT+02:00 Victor Olaya <volayaf at gmail.com>:
>> The original idea was to have most providers removed...which included
>> R, GRASS and SAGA as well. Finally, only certain providers were
>> removed, mostly those that require dependencies not provided with QGIS
>> (LiDAR tools, R...and OTB)
>>
>> If maintaining the plugin is complicated and no work is done on that,
>> then definitely it is better to keep it as core. But we have to make
>> sure that the user knows that the provider by itself is useless, and
>> that OTB has to be installed separately. Otherwise, we will see
>> confusion and i think it will not be a good idea
>>
>> My 2 cents
>>
>> 2018-01-31 11:04 GMT+01:00 Paolo Cavallini <cavallini at faunalia.it>:
>>> Il 31/01/2018 09:50, Rashad Kanavath ha scritto:
>>>
>>>> Thanks Paolo,
>>>> Can you give a link to that discussion?
>>>
>>> I had a look to the archives, and I only found this:
>>> https://lists.osgeo.org/pipermail/qgis-developer/2017-May/048470.html
>>> Surely Victor and Alex can provide further details.
>>> All the best.
>>>
>>> --
>>> Paolo Cavallini - www.faunalia.eu
>>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>>> https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
>
>
>
> --
> Alexander Bruy
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer