<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 8, 2018 at 11:32 AM, Victor Olaya <span dir="ltr"><<a href="mailto:volayaf@gmail.com" target="_blank">volayaf@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote><div> </div></span><div>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.</div></div></div></div></blockquote><div><br></div></span><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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...</div></div></div></div></blockquote><div><br></div><div>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)</div><div> And OTB was reading descriptor from xml which is going to be now csv like others. </div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div>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!</div><div><br></div><div>I don't care enough to continue this discussion about plugin or not plugin.<br></div><div><br></div><div>But aside all decision making stuff, can you check what is to be done in this PR?</div><div><a href="https://github.com/qgis/QGIS/pull/6272">https://github.com/qgis/QGIS/pull/6272</a><br></div><div>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.</div><div>If there is something extra need to be done to get this merged, I would happy to hear about it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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.</div><div><br></div><div>Cheers! </div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div><font face="arial, helvetica, sans-serif">Regards,<br>   Rashad</font></div></div>
</div></div>