Re: [QGIS-Developer] External providers in QGIS
Hi Rashad Thanks so much for your email below….sometimes things are not always easy to figure out, especially as QGIS gets bigger and more complex. We will really value your contribution as we move forward … and we will try to come up with a solution that works well for everyone. Best regards Tim > On 20 Feb 2018, at 13:09, Rashad Kanavath <rashad.kanav...@c-s.fr> wrote: > > Hello, > > Sorry for the misunderstanding about my last mail, I didn't want to > be disrespectful. I would like to continue the discussion about this > contribution. > > We will push this contribution and try to answer to all > questions, comments or issues about it. We will submit with my colleagues in > few days the QEP to have a strong basis for the discussion about this PR. > Thanks for setting up discussion on external providers at QGIS developer > meeting. > I had also registered to this discussion in github page. > I hope that we can continue to work together in a constructive spirit on this > issue. > > -- > Thanks, > Rashad > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer — Tim Sutton Co-founder: Kartoza Project chair: QGIS.org Visit http://kartoza.com <http://kartoza.com/> to find out about open source: Desktop GIS programming services Geospatial web development GIS Training Consulting Services Skype: timlinux IRC: timlinux on #qgis at freenode.net signature.asc Description: Message signed with OpenPGP ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] External providers in QGIS
Hello, Sorry for the misunderstanding about my last mail, I didn't want to be disrespectful. I would like to continue the discussion about this contribution. We will push this contribution and try to answer to all questions, comments or issues about it. We will submit with my colleagues in few days the QEP to have a strong basis for the discussion about this PR. Thanks for setting up discussion on external providers at QGIS developer meeting. I had also registered to this discussion in github page. I hope that we can continue to work together in a constructive spirit on this issue. -- Thanks, Rashad ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] External providers in QGIS
Il 08/02/2018 10:31, Rashad Kanavath ha scritto: > I don't know what these developers are going to do with a bugfix after a > new release. That's some kind of mystery unsolved to me. we are doing regular point releases, an approach which has proven very successful IMHO > I hope there will be zero bugs after releases. I hope you are joking :) 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=IT=qgis,arcgis ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] External providers in QGIS
On Wed, Feb 7, 2018 at 6:25 PM, Paolo Cavalliniwrote: > 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? > That would still need users *waiting* for QGIS release for fix in algo is what I understood from other parts of discussion. I don't know what these developers are going to do with a bugfix after a new release. That's some kind of mystery unsolved to me. I hope there will be zero bugs after releases. > > > 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=IT=qgis,arcgis > -- Regards, Rashad ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] External providers in QGIS
Hi all, I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable for serious, comprehensive GIS analysis work. Full stop. Missing one specific alg, even if not used daily, means having to switch to other software. We have already removed R provider: even if used by a tiny minority, and certainly not perfect, the previous situation was better than the current one, without the option of using R from QGIS. I think we have to be extra cautious on this ground. All the best. Il 07/02/2018 19:07, G. Allegri ha scritto: > - 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! -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html https://www.google.com/trends/explore?date=all=IT=qgis,arcgis ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] External providers in QGIS
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... Giovanni Il 7 feb 2018 18:25, "Paolo Cavallini"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=IT=qgis,arcgis > ___ > QGIS-Developer mailing list > QGIS-Developer@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@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] External providers in QGIS
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=IT=qgis,arcgis ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] External providers in QGIS
On Wed, Feb 7, 2018 at 3:03 PM, Victor Olayawrote: > I dont think that it is possible to make it more generic. It's not only > descriptors with only outputs and inputs. Each backend app has its own > logic. GRASS needs outputs to be converted to its own format. SAGA accepts > only SHP for vector layers and generates its own SDAT format for raster > outputs. Parameters are also not passed in the same way to all apps. SAGA > has extent parameters splitted in 4 params with bbox coordinates. Each > provider has a different way of indicating a boolean value in the console > call. In short, the logic must be there somehow, specific for the provider, > can you confirm that a GRASS input/output parameter can solve their issue?. Still there is SAGA and other stuff. So generic provider is not something QGIS team can do. But I would like to know about this on GRASS issue. > What is the difference between maintaining a set of descriptor files (as > you propose) and a set of descriptor files + a class extending > GeoAlgorithmProvider with the logic (as it happens now)?. I think it is > easier to have a solid provider class for OTB and then do not ever change > it (assuming OTB syntax will never change), than having a generic provider, > which looks rather unfeasible. > > Still OTB requires some changes in processing plugin to work. the old way of twisting application only for QGIS must be avoided. Without such a change there is no long-term existence even as plugin. Or worse, it exists and will be broken. QGIS must recognize such a behavior and avoid adding burden on external toolboxes' developer teams by asking for splitting applications. Be it OTB, GRASS, SAGA whatever. While I was at it, I saw there is less stuff to be managed and can be done using a customwidgetwrapper for OTB. because a custom widget wrapper works in a special way only for one provider. Hence the idea of generic provider came up!. In case of GRASS its input/output parameter, for OTB it is selection list parameter. Thanks for your valuable feedback on this. I am sure an idea of generic provider came up sometime during your work on processing plugin. It tough and need more expert work and safe is to avoid it totally. I agree on that part. > As you say, there is the risk for dead code. In that case, i think it is > much better to have the provider outside of QGIS core, as a plugin. There > are dozens of dead plugins, and that is not nice, but it's kinda > acceptable. Having dead code in QGIS it's a much bigger issue, and we must > avoid that. > > Cheers > > > > 2018-02-07 14:41 GMT+01:00 Rashad Kanavath : > >> Hello victor, >> >> Do you see a possibility of a generic processing provider?. One that can >> read descriptor files and run algorithms!. >> I see processing as a single plugin (included in QGIS or not). And if it >> can avoid need to have sub-plugin managed by all those other development >> team. That's even better!. >> Whichever toolbox want to be integrated into processing plugin can >> provide and maintain descriptor files individually. No QGIS developers need >> to be involved. >> This way, external toolboxes' team or qgis does not need to maintain/fix >> qgis--provider-plugin. >> >> search -> download -> install plugin will be changed to configure >> providers install location. >> If needed QGIS can control list of available providers (just names). >> >> External tools' dev team needs to know something such as spec of >> descriptor files, how to mention name of executable etc. >> They don't need to know stuff like how qgis run a processing algorithm, >> and things working of modeler, running with other algorithms. >> >> Anyway, this is just an idea and don't know what will be technically >> challenging issues? >> >> The other way of putting processing plugin into core and providers >> classified as external plugins can avoid maintenance on qgis. >> But this "strategy" can result in dead code and users complaining on both >> projects. Because, at some developers cannot manage project release + a >> plugin for qgis, another plugin for matlab or whatever >> Putting all stuff in qgis tree and taking no responsibility of providers >> isn't good either. >> >> This way, each team takes part and result in better collaboration and >> contribution. >> As time goes, generic descriptor provider gets better and stronger. >> Toolboxes are free to add, remove, modify their applications and users from >> both community benefit best of both worlds. >> >> >> On Wed, Feb 7, 2018 at 11:18 AM, Victor Olaya wrote: >> >>> I dont see the advantage in having providers in core. And if there is an >>> advantage, it's clearly not in how easy it is going to be to maintain the >>> plugin. 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? Better in a separate repo. Also,
Re: [QGIS-Developer] External providers in QGIS
I dont think that it is possible to make it more generic. It's not only descriptors with only outputs and inputs. Each backend app has its own logic. GRASS needs outputs to be converted to its own format. SAGA accepts only SHP for vector layers and generates its own SDAT format for raster outputs. Parameters are also not passed in the same way to all apps. SAGA has extent parameters splitted in 4 params with bbox coordinates. Each provider has a different way of indicating a boolean value in the console call. In short, the logic must be there somehow, specific for the provider, What is the difference between maintaining a set of descriptor files (as you propose) and a set of descriptor files + a class extending GeoAlgorithmProvider with the logic (as it happens now)?. I think it is easier to have a solid provider class for OTB and then do not ever change it (assuming OTB syntax will never change), than having a generic provider, which looks rather unfeasible. As you say, there is the risk for dead code. In that case, i think it is much better to have the provider outside of QGIS core, as a plugin. There are dozens of dead plugins, and that is not nice, but it's kinda acceptable. Having dead code in QGIS it's a much bigger issue, and we must avoid that. Cheers 2018-02-07 14:41 GMT+01:00 Rashad Kanavath: > Hello victor, > > Do you see a possibility of a generic processing provider?. One that can > read descriptor files and run algorithms!. > I see processing as a single plugin (included in QGIS or not). And if it > can avoid need to have sub-plugin managed by all those other development > team. That's even better!. > Whichever toolbox want to be integrated into processing plugin can provide > and maintain descriptor files individually. No QGIS developers need to be > involved. > This way, external toolboxes' team or qgis does not need to maintain/fix > qgis--provider-plugin. > > search -> download -> install plugin will be changed to configure > providers install location. > If needed QGIS can control list of available providers (just names). > > External tools' dev team needs to know something such as spec of > descriptor files, how to mention name of executable etc. > They don't need to know stuff like how qgis run a processing algorithm, > and things working of modeler, running with other algorithms. > > Anyway, this is just an idea and don't know what will be technically > challenging issues? > > The other way of putting processing plugin into core and providers > classified as external plugins can avoid maintenance on qgis. > But this "strategy" can result in dead code and users complaining on both > projects. Because, at some developers cannot manage project release + a > plugin for qgis, another plugin for matlab or whatever > Putting all stuff in qgis tree and taking no responsibility of providers > isn't good either. > > This way, each team takes part and result in better collaboration and > contribution. > As time goes, generic descriptor provider gets better and stronger. > Toolboxes are free to add, remove, modify their applications and users from > both community benefit best of both worlds. > > > On Wed, Feb 7, 2018 at 11:18 AM, Victor Olaya wrote: > >> I dont see the advantage in having providers in core. And if there is an >> advantage, it's clearly not in how easy it is going to be to maintain the >> plugin. 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? 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. >> >> 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 thought the idea was to not have core plugins and avoid them if >> possible. I don't see why we have to treat plugins that have Processing >> provider in a different way. Specially considering how easy it is to >> install a plugin in QGIS. >> >> Cheers >> >> >> >> 2018-02-06 18:57 GMT+01:00 Paolo Cavallini : >> >>> Hi all, >>> following the discussion on qgis-dev ML: >>> https://lists.osgeo.org/pipermail/qgis-developer/2018-Januar >>> y/051701.html >>> it has been proposed to remove all external providers (namely OTB, >>> already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will >>> remain as QGIS cannot be built without). This raised a number of >>> concerns, so PSC decided not to rush removing them from the upcoming 3.0 >>> release, and to open a wider discussions about this, involving all the >>> interested parties, to find an optimal solution. >>> If volunteers outside QGIS core team, ideally from the
Re: [QGIS-Developer] External providers in QGIS
Hi Rashad, 2018-02-07 15:41 GMT+02:00 Rashad Kanavath: > Do you see a possibility of a generic processing provider?. One that can > read descriptor files and run algorithms!. This is possible in the ideal world of ponies and rainbows. In real world we need to deal with different types of the inputs, with different representation of the same thing in the different programs, different logics. -- Alexander Bruy ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] External providers in QGIS
Hello victor, Do you see a possibility of a generic processing provider?. One that can read descriptor files and run algorithms!. I see processing as a single plugin (included in QGIS or not). And if it can avoid need to have sub-plugin managed by all those other development team. That's even better!. Whichever toolbox want to be integrated into processing plugin can provide and maintain descriptor files individually. No QGIS developers need to be involved. This way, external toolboxes' team or qgis does not need to maintain/fix qgis--provider-plugin. search -> download -> install plugin will be changed to configure providers install location. If needed QGIS can control list of available providers (just names). External tools' dev team needs to know something such as spec of descriptor files, how to mention name of executable etc. They don't need to know stuff like how qgis run a processing algorithm, and things working of modeler, running with other algorithms. Anyway, this is just an idea and don't know what will be technically challenging issues? The other way of putting processing plugin into core and providers classified as external plugins can avoid maintenance on qgis. But this "strategy" can result in dead code and users complaining on both projects. Because, at some developers cannot manage project release + a plugin for qgis, another plugin for matlab or whatever Putting all stuff in qgis tree and taking no responsibility of providers isn't good either. This way, each team takes part and result in better collaboration and contribution. As time goes, generic descriptor provider gets better and stronger. Toolboxes are free to add, remove, modify their applications and users from both community benefit best of both worlds. On Wed, Feb 7, 2018 at 11:18 AM, Victor Olayawrote: > I dont see the advantage in having providers in core. And if there is an > advantage, it's clearly not in how easy it is going to be to maintain the > plugin. 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? 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. > > 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 thought the idea was to not have core plugins and avoid them if > possible. I don't see why we have to treat plugins that have Processing > provider in a different way. Specially considering how easy it is to > install a plugin in QGIS. > > Cheers > > > > 2018-02-06 18:57 GMT+01:00 Paolo Cavallini : > >> Hi all, >> following the discussion on qgis-dev ML: >> https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html >> it has been proposed to remove all external providers (namely OTB, >> already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will >> remain as QGIS cannot be built without). This raised a number of >> concerns, so PSC decided not to rush removing them from the upcoming 3.0 >> release, and to open a wider discussions about this, involving all the >> interested parties, to find an optimal solution. >> If volunteers outside QGIS core team, ideally from the respective >> backends, could take the maintenance of these providers, not much would >> change for the end user. If not, this will mean effectively missing >> hundreds of algs from QGIS. >> I personally propose to reinstate the OTB plugin with Rashad (from OTB) >> as maintainer. >> QGIS.ORG will seek to support any decision made with funding where >> possible. >> Looking forward for your feedback. >> 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=IT=qgis,arcgis >> > > -- Regards, Rashad ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] External providers in QGIS
I dont see the advantage in having providers in core. And if there is an advantage, it's clearly not in how easy it is going to be to maintain the plugin. 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? 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. 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 thought the idea was to not have core plugins and avoid them if possible. I don't see why we have to treat plugins that have Processing provider in a different way. Specially considering how easy it is to install a plugin in QGIS. Cheers 2018-02-06 18:57 GMT+01:00 Paolo Cavallini: > Hi all, > following the discussion on qgis-dev ML: > https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html > it has been proposed to remove all external providers (namely OTB, > already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will > remain as QGIS cannot be built without). This raised a number of > concerns, so PSC decided not to rush removing them from the upcoming 3.0 > release, and to open a wider discussions about this, involving all the > interested parties, to find an optimal solution. > If volunteers outside QGIS core team, ideally from the respective > backends, could take the maintenance of these providers, not much would > change for the end user. If not, this will mean effectively missing > hundreds of algs from QGIS. > I personally propose to reinstate the OTB plugin with Rashad (from OTB) > as maintainer. > QGIS.ORG will seek to support any decision made with funding where > possible. > Looking forward for your feedback. > 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=IT=qgis,arcgis > ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] External providers in QGIS
Hi all, following the discussion on qgis-dev ML: https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html it has been proposed to remove all external providers (namely OTB, already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will remain as QGIS cannot be built without). This raised a number of concerns, so PSC decided not to rush removing them from the upcoming 3.0 release, and to open a wider discussions about this, involving all the interested parties, to find an optimal solution. If volunteers outside QGIS core team, ideally from the respective backends, could take the maintenance of these providers, not much would change for the end user. If not, this will mean effectively missing hundreds of algs from QGIS. I personally propose to reinstate the OTB plugin with Rashad (from OTB) as maintainer. QGIS.ORG will seek to support any decision made with funding where possible. Looking forward for your feedback. 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=IT=qgis,arcgis ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer