Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS
On Thu, Feb 15, 2018 at 6:22 PM, Anita Graser wrote: > > > On Sun, Feb 11, 2018 at 8:52 AM, Paolo Cavallini > wrote: > >> Il 10/02/2018 14:38, Anita Graser ha scritto: >> > Since Madeira is just around the corner, let's organize a round table >> > discussion on this issue. I've started a section here: >> > https://github.com/qgis/QGIS/wiki/DeveloperMeetingMadeira201 >> 8#future-of-processing-providers >> > Please add yourself to the list if you are interested in participating >> > on-site or remotely. We'll then try to find a time slot that works for >> > everyone. >> >> thanks Anita for setting it up. >> Please all interested parties add your name to the list. >> > > The currently suggested time is Feb 23rd 10:30 UTC+00. > > So far, we have six people signed up. Please get in touch if the time > doesn't work for someone. We should be able to find a slot that's possible > for all six. > > I'll try to join as well. Kind Regards, Johan ___ 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] [GRASS-dev] External providers in QGIS
On Sun, Feb 11, 2018 at 8:52 AM, Paolo Cavallini wrote: > Il 10/02/2018 14:38, Anita Graser ha scritto: > > Since Madeira is just around the corner, let's organize a round table > > discussion on this issue. I've started a section here: > > https://github.com/qgis/QGIS/wiki/DeveloperMeetingMadeira2018# > future-of-processing-providers > > Please add yourself to the list if you are interested in participating > > on-site or remotely. We'll then try to find a time slot that works for > > everyone. > > thanks Anita for setting it up. > Please all interested parties add your name to the list. > The currently suggested time is Feb 23rd 10:30 UTC+00. So far, we have six people signed up. Please get in touch if the time doesn't work for someone. We should be able to find a slot that's possible for all six. Regards, Anita ___ 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] [GRASS-dev] External providers in QGIS
Il 10/02/2018 14:38, Anita Graser ha scritto: > On Fri, Feb 9, 2018 at 11:01 AM, Richard > Duivenvoorde mailto:rdmaili...@duif.net>> wrote: > > Maybe at a hackfest, foss4g or other meeting it is good to come together > face to face so it is easier to actually SHOW each other the > bears/problems we see? > > > Since Madeira is just around the corner, let's organize a round table > discussion on this issue. I've started a section here: > > https://github.com/qgis/QGIS/wiki/DeveloperMeetingMadeira2018#future-of-processing-providers > > Please add yourself to the list if you are interested in participating > on-site or remotely. We'll then try to find a time slot that works for > everyone. thanks Anita for setting it up. Please all interested parties add your name to the list. 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@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] [GRASS-dev] External providers in QGIS
On Fri, Feb 9, 2018 at 11:01 AM, Richard Duivenvoorde wrote: > Maybe at a hackfest, foss4g or other meeting it is good to come together > face to face so it is easier to actually SHOW each other the > bears/problems we see? > Since Madeira is just around the corner, let's organize a round table discussion on this issue. I've started a section here: https://github.com/qgis/QGIS/wiki/DeveloperMeetingMadeira2018#future-of-processing-providers Please add yourself to the list if you are interested in participating on-site or remotely. We'll then try to find a time slot that works for everyone. Regards, Anita ___ 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] [GRASS-dev] External providers in QGIS
Dear Nyall and all, here are some of my thoughts mostly relating to GRASS GIS (although it may not express views of the whole GRASS GIS developer team). On Thu, Feb 8, 2018 at 8:55 PM, Nyall Dawson wrote: > > Here's the situation as I see it: > > > The past > --- > > We (the QGIS project) have struggled to keep a bunch of providers > stable and available with the base QGIS install, and the current > maintainers (Alex and Victor, others) have (understandably) struggled > with the burden of maintaining these alone and the time commitment > required to do so. Users have been frustrated by breakage which occurs > when the algorithms they depend on break due to changes in underlying > libraries for which the processing providers have not been adapted. > > Despite this, I'd say overall it's worked OK-ish up to now, but > definitely with lots of room for improvement. > > - > The goals > - > > I think everyone involved is in agreement that processing's strength > comes when there's many providers available and it's able to tie > together processes regardless of which provider or library they come > from. So I'd say our common goals are: > > 1. Encourage development of as many processing providers as possible > 2. Make it easy for developers to create and maintain these providers > 3. Make it easy for users to be able to use the providers > 4. Make everything stable and painfree for users > > Any disagreements? No? Good ;) > > So if we agree that those are the end goals, we should be using them > to drive this discussion. > > --- > The questions > --- > > The open, debatable questions are: > > - Which is the best approach for allowing easy maintenance of > providers (*regardless* of whether the provider is maintained by the > core QGIS team or a 3rd party)? Is it keeping the code in the master > codebase and locking to QGIS releases, or publishing via plugins and > having independent release schedules? Which approach will encourage > more active maintenance of these providers and share the burden of > this maintenance? One thing is where to keep the code, however I'm not sure what code are we talking about and I would like to talk about this first. I think that recent post by Moritz is bringing this up as well: https://lists.osgeo.org/pipermail/grass-dev/2018-February/087420.html As far as I know, QGIS Processing has a text file for each GRASS module describing its interface and maintenance of these takes time. However, every GRASS module can tell about itself when called with --interface-description parameter. If this is used, individual parameters don't need to be maintained and any, even user provided module can be executed in processing. The --interface-description parameter gives XML which would need to be converted or a new parameter, let's say --qgis-description, would need to be added for a QGIS-specific format, there is for example --script for GRASS GIS interface description for scripts. --qgis-description would need to be in GRASS GIS code base while the conversion can be anywhere. See emails from Rashad discussing a possible implementation with the --qgis-description way and the OTB way: https://lists.osgeo.org/pipermail/grass-dev/2018-February/087362.html https://lists.osgeo.org/pipermail/grass-dev/2018-February/087390.html The was discussed in the past and in fact, it is used in the QGIS GRASS plugin as Radim explains in this older email: https://lists.osgeo.org/pipermail/grass-dev/2015-March/074629.html However, it is not using the --interface-description XML only, but it is also using the qgm files to supply some additional information which means that this system still requires updates which are separate from the updates of GRASS modules. This can be avoided if the necessary information is updated upstream or sometimes even GRASS --interface-description format or the individual module descriptions are extended to include that what is needed by QGIS Processing. Here is a thread which disuses this issues although diverges into the following: https://lists.osgeo.org/pipermail/grass-dev/2015-September/076138.html One issue which is creating differences between QGIS Processing representation of the module and the GRASS one is the issue of advanced parameters. GRASS itself has mechanism to organize the parameters into groups and marks the required ones. This is of course something which is constantly being refined and it can be used and changed also for QGIS Processing as discussed in this 2015 post: https://lists.osgeo.org/pipermail/grass-dev/2015-December/078000.html Other issues besides the interface include list of GRASS modules usable and unusable in QGIS Processing, thematic tree of these modules, splitting modules and more. Many of these are discussed in this recent post: https://lists.osgeo.org/pipermail/grass-dev/2018-February/087388.html One of the issues is issue of formats (or import & export). Here
Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS
Il 09/02/2018 09:34, Rashad Kanavath ha scritto: > I am giving up on this contribution as it seems impossible to get small > changes like this. > Thanks for all your time. Hi Rashad, please be patient: bear with us, and we'll find the most efficient solution. In QGIS we have a very friendly environment, even when tech discussion may seem harsh and lengthy. I'm sure there is ample room for profitable cooperation. All the best, and thanks for your work. -- 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@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] [GRASS-dev] External providers in QGIS
> > I am giving up on this contribution as it seems impossible to get small > changes like this. > Thanks for all your time. The change is not small. It might have important consequences in other parts of Processing. I gave the PR a +1, probably without having analyzed it in detail. Alex and Nyall had some doubts and asked you questions. That's how it works. I guess you can understand that, even if you think the change is safe, others (in this case with a deeper understanding of the QGIS core code) might want to be sure of that. In the comments to the PR you replied with "That's your problem. fix it on your side." No, sorry, but it is not like that. If you submit a PR, there should be no need to fix anything after merging it. If it breaks something, you should provide a fix in the PR itself. Ideally, we should have tests that warn us about any possible break. Since we don't have them, we (the developers that take care of merging your PR) play that role and try to analyze what might happen if the PR is merged. That takes time, and in some cases discussion is needed. Please, show more respect in your comments. I suggest leaving the PR open and continue discussing it. It might be a good contribution to the Processing code and might make things easier for the OTB provider, but please understand that all changes must be carefully analyzed in case it's not clear that they are needed or are safe. Cheers. ___ 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] [GRASS-dev] External providers in QGIS
On 09-02-18 09:34, Rashad Kanavath wrote: > > > I am giving up on this contribution as it seems impossible to get small > changes like this. > Thanks for all your time. Hi Rashad, Thanks for your time. But I do think that you do not give enough credit to Alex et al here: https://github.com/qgis/QGIS/pull/6272#issuecomment-364368721 By telling us that "just because of you can't understand this simple stuff". I think we/Alex ask valid questions about the consequences for OTHER providers and QGIS and processing as a whole. While to you it is 'a simple PR'. QGIS devs feel responsible for the whole picture, and OTB provider is a part of the pack that have to fit in. Maybe at a hackfest, foss4g or other meeting it is good to come together face to face so it is easier to actually SHOW each other the bears/problems we see? Regards, Richard Duivenvoorde ___ 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] [GRASS-dev] External providers in QGIS
On Thu, Feb 8, 2018 at 5:51 PM, Paolo Cavallini wrote: > Il 08/02/2018 13:43, Rashad Kanavath ha scritto: > > > But aside all decision making stuff, can you check what is to be done in > > this PR? > > https://github.com/qgis/QGIS/pull/6272 > > It is something worthy a discussion and not a plugin or not. I was > > asking because QGIS 3 is near and diff is not that big. > > If there is something extra need to be done to get this merged, I would > > happy to hear about it. > > agreed, this is an important and urgent point. > please some qgis dev could check this? > thanks. > I am giving up on this contribution as it seems impossible to get small changes like this. Thanks for all your time. > -- > 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 > -- 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] [GRASS-dev] External providers in QGIS
On 9 February 2018 at 00:20, Moritz Lennert wrote: > On 08/02/18 15:08, Nikos Alexandris wrote: >> >> I guess, there are numerous cases like this one. What would, >> effectively, mean a removal of external providers (in this case GRASS >> GIS)? > > > Let's make it clear once and for all: noone is speaking about the complete > removal of external providers. The issue is where, how and by whom they > should be maintained, i.e. within the QGIS core code base, or as plugins. > Yes, this is a great point. I think this discussion has got sidetracked with some misunderstandings. Here's the situation as I see it: The past --- We (the QGIS project) have struggled to keep a bunch of providers stable and available with the base QGIS install, and the current maintainers (Alex and Victor, others) have (understandably) struggled with the burden of maintaining these alone and the time commitment required to do so. Users have been frustrated by breakage which occurs when the algorithms they depend on break due to changes in underlying libraries for which the processing providers have not been adapted. Despite this, I'd say overall it's worked OK-ish up to now, but definitely with lots of room for improvement. - The goals - I think everyone involved is in agreement that processing's strength comes when there's many providers available and it's able to tie together processes regardless of which provider or library they come from. So I'd say our common goals are: 1. Encourage development of as many processing providers as possible 2. Make it easy for developers to create and maintain these providers 3. Make it easy for users to be able to use the providers 4. Make everything stable and painfree for users Any disagreements? No? Good ;) So if we agree that those are the end goals, we should be using them to drive this discussion. --- The questions --- The open, debatable questions are: - Which is the best approach for allowing easy maintenance of providers (*regardless* of whether the provider is maintained by the core QGIS team or a 3rd party)? Is it keeping the code in the master codebase and locking to QGIS releases, or publishing via plugins and having independent release schedules? Which approach will encourage more active maintenance of these providers and share the burden of this maintenance? - Who should be responsible for maintaining the providers? Should maintenance be done by the QGIS core developer team or by 3rd parties? - How do we make these tools available for ALL interested users? How can we ensure that 3rd party dependencies are always available and have a consistent feature set, regardless of which platform the user is running? Does having the QGIS team or 3rd parties maintain the provider help make the tools more readily available? Does having the providers in master or plugins make the 3rd party dependencies more readily available or not? - How can we ensure that providers are well tested and don't break with changes in QGIS OR from 3rd party library updates? Does having the QGIS team or 3rd parties affect this stability? Does having the providers in master or plugins affect this stability? - Is it a core requirement that 3rd party providers are installed with EVERY QGIS install, or is it acceptable to require interested users to manually install the tools which they find useful? If the second option is preferred, then how can we ensure that users are aware of the availability of these tools? - Does it make it easier for everyone involved if we just delete all the python bindings for processing and only allow core, native, c++ algorithms, and merge all our codebases into a single unified QGIS+SAGA+GRASS+OTB+R mega package? (I joke... ;) This isn't an easy discussion, but please, let's keep the discussion civil, factual, and informed, and driven by the above goals. Nyall ___ 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] [GRASS-dev] External providers in QGIS
Il 08/02/2018 15:49, Nikos Alexandris ha scritto: > * Moritz Lennert [2018-02-08 15:20:14 > +0100]: > >> On 08/02/18 15:08, Nikos Alexandris wrote: >>> I guess, there are numerous cases like this one. What would, >>> effectively, mean a removal of external providers (in this case GRASS >>> GIS)? >> >> Let's make it clear once and for all: noone is speaking about the >> complete removal of external providers. The issue is where, how and by >> whom they should be maintained, i.e. within the QGIS core code base, >> or as plugins. > > > Thank you the heads-up Moritz. true, but removal from core would mean the external plugin has to be created, maintained, tested, and documented by someone. If this is missing, the external plugin simply wil not appear. This is what happened with R. Once a provider is out and unmaintained, it becomes less visible, and less likely to attract attention. The work to bring it back to life, with all the above, will be much higher than when in core, and increasing over time. 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@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] [GRASS-dev] External providers in QGIS
Il 08/02/2018 13:43, Rashad Kanavath ha scritto: > But aside all decision making stuff, can you check what is to be done in > this PR? > https://github.com/qgis/QGIS/pull/6272 > It is something worthy a discussion and not a plugin or not. I was > asking because QGIS 3 is near and diff is not that big. > If there is something extra need to be done to get this merged, I would > happy to hear about it. agreed, this is an important and urgent point. please some qgis dev could check this? thanks. -- 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@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] [GRASS-dev] External providers in QGIS
On Thu, Feb 8, 2018 at 11:32 AM, Victor Olaya wrote: > > >> >> OTB's proposed solution was that plugin or provider algorithm if >> activated can find otb installation. If not found, there is code which will >> download and install otb packages and configure it for users. >> > > I still don't see why this cannot be done if OTB provider is a separate > plugin. Users can install a plugin with the provider, and then that > provider can have the logic to automatically download OTB, install it, or > do whatever is needed in case OTB is not found already installed. > > I think is is good to educate our users a little bit. We are talking about > people that will be using complex algorithms for performing advanced > analysis. I guess we can expect that they can install a plugin themselves > and it is not a traumatic experience for them... Looks like installing a > separate plugin it's some sort of cruel chinese torture...when it takes > just 3 mouse clicks. > > I agree with Giovanni, there is no need to provide something that has > everything installed out-of the box. Also, take into account that reading > the files that contain the algorithm descriptions takes time (plus, there > might be some additional checks performed when populating the toolbox). > People not doing analysis should not have to suffer that extra loading > time... > QGIS increases no of algorithms for a provider. It is simple as that. OTB has less than 80 applications and coming to QGIS, it will be 100 or 150. (no interest to count them in qgis) And OTB was reading descriptor from xml which is going to be now csv like others. Given all that info, I won't be surprised if it takes more time in future because of new algorithms added to providers. If QGIS was reading proper way or even open to accepting fixes. The entire proposal/request to put back OTB was that decision was made on OLD code. when the update code is there, it has less problems. Based on concerns raised by other developers no matter if you can fix it, they can't be put back. This single point was fueling this and other threads. Also discussion wasn't started with "why no providers are included?". It was why some of them are removed even if there is an offer to help! I don't care enough to continue this discussion about plugin or not plugin. But aside all decision making stuff, can you check what is to be done in this PR? https://github.com/qgis/QGIS/pull/6272 It is something worthy a discussion and not a plugin or not. I was asking because QGIS 3 is near and diff is not that big. If there is something extra need to be done to get this merged, I would happy to hear about it. > About the R plugin not being available now...well, it's in a separate repo > and can be adapted to QGIS 3, packaged and published. No one has taken care > of that, it's true, but that only means we have no R support. If the R > provider was be in core, it would mean that we would have a dead or > malfunctioning provider being shipped with QGIS. That is a much worse > option. And I dont see why, if someone is willing to fix that R provider, > having it in core will make it easier. > > Cheers! > -- 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] [GRASS-dev] External providers in QGIS
> > OTB's proposed solution was that plugin or provider algorithm if activated > can find otb installation. If not found, there is code which will download > and install otb packages and configure it for users. > I still don't see why this cannot be done if OTB provider is a separate plugin. Users can install a plugin with the provider, and then that provider can have the logic to automatically download OTB, install it, or do whatever is needed in case OTB is not found already installed. I think is is good to educate our users a little bit. We are talking about people that will be using complex algorithms for performing advanced analysis. I guess we can expect that they can install a plugin themselves and it is not a traumatic experience for them... Looks like installing a separate plugin it's some sort of cruel chinese torture...when it takes just 3 mouse clicks. I agree with Giovanni, there is no need to provide something that has everything installed out-of the box. Also, take into account that reading the files that contain the algorithm descriptions takes time (plus, there might be some additional checks performed when populating the toolbox). People not doing analysis should not have to suffer that extra loading time... About the R plugin not being available now...well, it's in a separate repo and can be adapted to QGIS 3, packaged and published. No one has taken care of that, it's true, but that only means we have no R support. If the R provider was be in core, it would mean that we would have a dead or malfunctioning provider being shipped with QGIS. That is a much worse option. And I dont see why, if someone is willing to fix that R provider, having it in core will make it easier. Cheers! ___ 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] [GRASS-dev] External providers in QGIS
On Thu, Feb 8, 2018 at 10:15 AM, Stefan Blumentrath < stefan.blumentr...@nina.no> wrote: > Hi, > > Regarding the negative effect of algorithms getting lost I fully agree > with you Paolo. > > However, it might simplify the discussion if we try separate user > experience and development (and packaging) solutions as well as means and > ends... > > Aim should be to have the different back-ends available for user in a way > that is as straight forward as possible. From my point of view that > includes that possibly available providers are not hidden from users who > just install bare QGIS. If they want to activate them, but don`t have the > backends installed (and possibly a plugin) then they should get a notice > that they have to install them (and I don`t see a problem with installing > provider + plugin compared to just provider). > OTB's proposed solution was that plugin or provider algorithm if activated can find otb installation. If not found, there is code which will download and install otb packages and configure it for users. > And if that sort of user experience is guaranteed I - as a user - would > not care about where the code is maintained (in QGIS core, in the provider > core, or in a separate plugin). My impression is that Victors arguments for > an out-of-core solution are very valid, esp. given effects of the > independent release cycles of the backends and QGIS on packaging needs (at > least for the GRASS plugin). > The only difference I see is that additional packages would be needed for > a plugin solution. But that is probably not too bad or even an advantage... > > Finally, if there is interest in keeping the processing integration alive > (and it obviously is) having it in an independent repo should not be a show > stopper. Only negative effect I can see is that this produces additional > repos, where access rights have to be managed. But that should not be a > major issue either... > > Cheers > Stefan > > P.S.: Just a pity that this discussion starts after medspx just put down > all this work: > https://github.com/qgis/QGIS/pull/5603 > https://github.com/qgis/QGIS/pull/5968 > https://github.com/qgis/QGIS/pull/5426 > > -Original Message- > From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of > Paolo Cavallini > Sent: torsdag 8. februar 2018 09.04 > To: G. Allegri > Cc: qgis-developer ; > saga-gis-develo...@lists.sourceforge.net; grass-dev < > grass-...@lists.osgeo.org>; Victor Olaya > Subject: Re: [GRASS-dev] [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&geo=IT&q=qgis,arcgis > ___ > grass-dev mailing list > grass-...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > ___ > grass-dev mailing list > grass-...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- 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] [GRASS-dev] External providers in QGIS
What I ment is that, from my perspective, we shouldn't seek to make QGIS a do-it-all software by default, because the GIS/EO/RS/Data Analysis fields are so wide that, from that point of view, everything could go into QGIS and it would be an overwhelmin experience for users. Any generic sw I know offers extensions, plugins, for specialized use cases. From my experience a user prefers few tools that match their needs, instead of digging into a long list of (mostly) obscure algs... Anyway, I don't want to stress on this... Giovanni 2018-02-08 10:15 GMT+01:00 Stefan Blumentrath : > Hi, > > Regarding the negative effect of algorithms getting lost I fully agree > with you Paolo. > > However, it might simplify the discussion if we try separate user > experience and development (and packaging) solutions as well as means and > ends... > > Aim should be to have the different back-ends available for user in a way > that is as straight forward as possible. From my point of view that > includes that possibly available providers are not hidden from users who > just install bare QGIS. If they want to activate them, but don`t have the > backends installed (and possibly a plugin) then they should get a notice > that they have to install them (and I don`t see a problem with installing > provider + plugin compared to just provider). > > And if that sort of user experience is guaranteed I - as a user - would > not care about where the code is maintained (in QGIS core, in the provider > core, or in a separate plugin). My impression is that Victors arguments for > an out-of-core solution are very valid, esp. given effects of the > independent release cycles of the backends and QGIS on packaging needs (at > least for the GRASS plugin). > The only difference I see is that additional packages would be needed for > a plugin solution. But that is probably not too bad or even an advantage... > > Finally, if there is interest in keeping the processing integration alive > (and it obviously is) having it in an independent repo should not be a show > stopper. Only negative effect I can see is that this produces additional > repos, where access rights have to be managed. But that should not be a > major issue either... > > Cheers > Stefan > > P.S.: Just a pity that this discussion starts after medspx just put down > all this work: > https://github.com/qgis/QGIS/pull/5603 > https://github.com/qgis/QGIS/pull/5968 > https://github.com/qgis/QGIS/pull/5426 > > -Original Message- > From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of > Paolo Cavallini > Sent: torsdag 8. februar 2018 09.04 > To: G. Allegri > Cc: qgis-developer ; > saga-gis-develo...@lists.sourceforge.net; grass-dev < > grass-...@lists.osgeo.org>; Victor Olaya > Subject: Re: [GRASS-dev] [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&geo=IT&q=qgis,arcgis > ___ > grass-dev mailing list > grass-...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > ___ 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] [GRASS-dev] External providers in QGIS
Hi, Regarding the negative effect of algorithms getting lost I fully agree with you Paolo. However, it might simplify the discussion if we try separate user experience and development (and packaging) solutions as well as means and ends... Aim should be to have the different back-ends available for user in a way that is as straight forward as possible. From my point of view that includes that possibly available providers are not hidden from users who just install bare QGIS. If they want to activate them, but don`t have the backends installed (and possibly a plugin) then they should get a notice that they have to install them (and I don`t see a problem with installing provider + plugin compared to just provider). And if that sort of user experience is guaranteed I - as a user - would not care about where the code is maintained (in QGIS core, in the provider core, or in a separate plugin). My impression is that Victors arguments for an out-of-core solution are very valid, esp. given effects of the independent release cycles of the backends and QGIS on packaging needs (at least for the GRASS plugin). The only difference I see is that additional packages would be needed for a plugin solution. But that is probably not too bad or even an advantage... Finally, if there is interest in keeping the processing integration alive (and it obviously is) having it in an independent repo should not be a show stopper. Only negative effect I can see is that this produces additional repos, where access rights have to be managed. But that should not be a major issue either... Cheers Stefan P.S.: Just a pity that this discussion starts after medspx just put down all this work: https://github.com/qgis/QGIS/pull/5603 https://github.com/qgis/QGIS/pull/5968 https://github.com/qgis/QGIS/pull/5426 -Original Message- From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Paolo Cavallini Sent: torsdag 8. februar 2018 09.04 To: G. Allegri Cc: qgis-developer ; saga-gis-develo...@lists.sourceforge.net; grass-dev ; Victor Olaya Subject: Re: [GRASS-dev] [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&geo=IT&q=qgis,arcgis ___ grass-dev mailing list grass-...@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev ___ 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] [GRASS-dev] External providers in QGIS
On Wed, Feb 7, 2018 at 7:07 PM, G. Allegri wrote: > 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 > Do you have these toolboxes installed during training? OTB, SAGA, GRASS etc.. OTB is focused on remote sensing. Unless you have a training or course that area, your statistics on them being not needed is pretty unreliable. Don't you think? What QGIS uses to run a classification/segmentation algorithm without OTB and GRASS GIS. > - 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&geo=IT&q=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 > > > ___ > grass-dev mailing list > grass-...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- 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