<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 7, 2018 at 7:07 PM, G. Allegri <span dir="ltr"><<a href="mailto:giohappy@gmail.com" target="_blank">giohappy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">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:<div dir="auto"><br></div><div dir="auto">- 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</div></div></blockquote><div><br></div><div>Do you have these toolboxes installed during training? OTB, SAGA, GRASS etc.. </div><div>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?</div><div>What QGIS uses to run a classification/segmentation algorithm without OTB and GRASS GIS. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">- 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.</div><div dir="auto">Anyway we would have the plugins for GRASS and SAGA, in case...</div><div dir="auto"><br></div><div dir="auto">- 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.</div><div dir="auto"><br></div><div dir="auto">I appreciate a lot the work from Richard, I hope this discussion is not understood as to belittle its effort!</div><div dir="auto"><br></div><div dir="auto">my 2 cents...</div><div dir="auto">Giovanni</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">Il 7 feb 2018 18:25, "Paolo Cavallini" <<a href="mailto:cavallini@faunalia.it" target="_blank">cavallini@faunalia.it</a>> ha scritto:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Il 07/02/2018 11:18, Victor Olaya ha scritto:<br>
> I dont see the advantage in having providers in core.<br>
<br>
I see the following:<br>
* tests (already available in our infrastructure)<br>
* translations<br>
* more exposure<br>
* documentation<br>
<br>
> And if there is an<br>
> advantage, it's clearly not in how easy it is going to be to maintain<br>
> the plugin.<br>
<br>
until now it has been maintained somehow; if more resources are needed,<br>
we can find a way<br>
<br>
> If the people responsible of a given backend (like OTB) are<br>
> going to maintain it (which makes sense), why putting it in core where<br>
> they don't have write access?<br>
<br>
why not granting them write access?<br>
<br>
> Better in a separate repo. Also, they can<br>
> release whenever there are changes, without having to wait for a new<br>
> release. That way, the plugin will always be in sync with new releases<br>
> of the backend app.<br>
<br>
this is certainly true; AFAICT OTB people has proposed a solution<br>
<br>
> If we put them in core...why putting only this big ones (which in some<br>
> cases require installing external apps manually by the user), and not<br>
> put other plugins that exist and contain Processing providers? <br>
<br>
I'd be in favour of adding anything important for users.<br>
<br>
Thanks for your thoughts.<br>
<br>
When in Madeira we can have a discussion about this. It would be good if<br>
all interested parties could meet, locally and remotely.<br>
<br>
All the best.<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/trainin<wbr>g.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=qgis<wbr>,arcgis</a><br></div></div>
______________________________<wbr>_________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/qgis-developer</a></blockquote></div></div>
<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></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>