[GRASS-dev] [QGIS-Developer] External providers in QGIS

G. Allegri giohappy at gmail.com
Wed Feb 7 10:07:24 PST 2018

I'm much more in favour for out of core providers, for the same reasons
reported by Victor. Having only GDAL and QGIS algorithms in core will
reduce the number of available algorithms out of the box, but:

- from my experience - comprising years of feedbacks from the courses I
teach - the most frequently used algs are available within the GDAL and
QGIS algs list

- a few generic and widely used algs are from GRASS and SAGA. We would miss
them - out of the box - but it could also be an opportunity to port them.
For examples v.to.points, transects, profiles.
Anyway we would have the plugins for GRASS and SAGA, in case...

- specific algs are for specialized users. Here I think plugins are best
suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added to the
list, consistently with the others approach.

I appreciate a lot the work from Richard, I hope this discussion is not
understood as to belittle its effort!

my 2 cents...

Il 7 feb 2018 18:25, "Paolo Cavallini" <cavallini at faunalia.it> ha scritto:

> Il 07/02/2018 11:18, Victor Olaya ha scritto:
> > I dont see the advantage in having providers in core.
> I see the following:
> * tests (already available in our infrastructure)
> * translations
> * more exposure
> * documentation
> > And if there is an
> > advantage, it's clearly not in how easy it is going to be to maintain
> > the plugin.
> until now it has been maintained somehow; if more resources are needed,
> we can find a way
> > If the people responsible of a given backend (like OTB) are
> > going to maintain it (which makes sense), why putting it in core where
> > they don't have write access?
> why not granting them write access?
> > Better in a separate repo. Also, they can
> > release whenever there are changes, without having to wait for a new
> > release. That way, the plugin will always be in sync with new releases
> > of the backend app.
> this is certainly true; AFAICT OTB people has proposed a solution
> > If we put them in core...why putting only this big ones (which in some
> > cases require installing external apps manually by the user), and not
> > put other plugins that exist and contain Processing providers?
> I'd be in favour of adding anything important for users.
> Thanks for your thoughts.
> When in Madeira we can have a discussion about this. It would be good if
> all interested parties could meet, locally and remotely.
> 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
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180207/dcce1978/attachment.html>

More information about the grass-dev mailing list