<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 8, 2018 at 10:15 AM, Stefan Blumentrath <span dir="ltr"><<a href="mailto:Stefan.Blumentrath@nina.no" target="_blank">Stefan.Blumentrath@nina.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Regarding the negative effect of algorithms getting lost I fully agree with you Paolo.<br>
<br>
However, it might simplify the discussion if we try separate user experience and development (and packaging) solutions as well as means and ends...<br>
<br>
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).<br></blockquote><div> </div><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><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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).<br>
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...<br>
<br>
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...<br>
<br>
Cheers<br>
Stefan<br>
<br>
P.S.: Just a pity that this discussion starts after medspx just put down all this work:<br>
<a href="https://github.com/qgis/QGIS/pull/5603" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/<wbr>pull/5603</a><br>
<a href="https://github.com/qgis/QGIS/pull/5968" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/<wbr>pull/5968</a><br>
<a href="https://github.com/qgis/QGIS/pull/5426" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/<wbr>pull/5426</a><br>
<div class="HOEnZb"><div class="h5"><br>
-----Original Message-----<br>
From: grass-dev [mailto:<a href="mailto:grass-dev-bounces@lists.osgeo.org">grass-dev-bounces@<wbr>lists.osgeo.org</a>] On Behalf Of Paolo Cavallini<br>
Sent: torsdag 8. februar 2018 09.04<br>
To: G. Allegri <<a href="mailto:giohappy@gmail.com">giohappy@gmail.com</a>><br>
Cc: qgis-developer <<a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.<wbr>org</a>>; <a href="mailto:saga-gis-developer@lists.sourceforge.net">saga-gis-developer@lists.<wbr>sourceforge.net</a>; grass-dev <<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a>>; Victor Olaya <<a href="mailto:volayaf@gmail.com">volayaf@gmail.com</a>><br>
Subject: Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS<br>
<br>
Hi all,<br>
I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable for serious, comprehensive GIS analysis work. Full stop.<br>
Missing one specific alg, even if not used daily, means having to switch to other software.<br>
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.<br>
I think we have to be extra cautious on this ground.<br>
All the best.<br>
<br>
Il 07/02/2018 19:07, G. Allegri ha scritto:<br>
<br>
> - from my experience - comprising years of feedbacks from the courses<br>
> I teach - the most frequently used algs are available within the GDAL<br>
> and QGIS algs list<br>
><br>
> - a few generic and widely used algs are from GRASS and SAGA. We would<br>
> miss them - out of the box - but it could also be an opportunity to<br>
> port them. For examples v.to.points, transects, profiles.<br>
> Anyway we would have the plugins for GRASS and SAGA, in case...<br>
><br>
> - specific algs are for specialized users. Here I think plugins are<br>
> best suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added<br>
> to the list, consistently with the others approach.<br>
><br>
> I appreciate a lot the work from Richard, I hope this discussion is<br>
> not understood as to belittle its effort!<br>
<br>
--<br>
Paolo Cavallini - <a href="http://www.faunalia.eu" rel="noreferrer" target="_blank">www.faunalia.eu</a><br>
QGIS & PostGIS courses: <a href="http://www.faunalia.eu/training.html" rel="noreferrer" target="_blank">http://www.faunalia.eu/<wbr>training.html</a><br>
<a href="https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis" rel="noreferrer" target="_blank">https://www.google.com/trends/<wbr>explore?date=all&geo=IT&q=<wbr>qgis,arcgis</a><br>
______________________________<wbr>_________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/grass-dev</a><br>
______________________________<wbr>_________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/grass-dev</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div><font face="arial, helvetica, sans-serif">Regards,<br>   Rashad</font></div></div>
</div></div>