On Wed, Feb 7, 2018 at 7:07 PM, G. Allegri <gioha...@gmail.com> 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" <cavall...@faunalia.it> 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-develo...@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-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Regards, Rashad
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev