[QGIS-Developer] Keeping OTB algorithm in qgis processing

Thu Feb 1 02:01:35 PST 2018

Hello,

Processing plugin allows to integrate other toolboxes. IIUC, this was one
of the features of it.
So when you say integration of so and so toolboxes are total mess, you
might think back.

Nobody had seen new changes to otb algs so all of your comments are on old
version.  Why so rush?
Okay, it easy to reject stating the same reason over and over again. I
understand that.
What happens at end, a processing plugin with zero providers?

Now the reason OTB had to maintain list of "supported" version is due the
fact that processing plugin does not allow to group parameters.
So the issue of a provider being total mess not fully related to provider
itself. If 90% of provider algorithm which you use, cannot be even
integrated into processing where will be the actual problem. I see a lot of
good changes in qgis processing and providers can greatly benefit from it
now.

All those people blindly rejecting this proposal should have waited for new
changes.
I mean, I just put a proposal to lower the burden as much as possible. And
all those issues raised by Alex, Nyall and others will be considered in the
new diff.
Once I prepare changes, you can reject it!. You are voting -1ss on old
plugin code something I consider a mess to work with for both teams.

My initial question was only to see if there are other issues than the
maintenance overhead?
By now, I conclude that only issue was maintenance overhead and I proposed
it can be solved.

On Thu, Feb 1, 2018 at 12:17 AM, Nyall Dawson <nyall.dawson at gmail.com>
wrote:

> 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
> _______________________________________________
> 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
>

-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180201/e4326783/attachment-0001.html>