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 <[email protected]>: > 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:[email protected]] On Behalf Of > Paolo Cavallini > Sent: torsdag 8. februar 2018 09.04 > To: G. Allegri <[email protected]> > Cc: qgis-developer <[email protected]>; > [email protected]; grass-dev < > [email protected]>; Victor Olaya <[email protected]> > 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 > [email protected] > https://lists.osgeo.org/mailman/listinfo/grass-dev >
_______________________________________________ grass-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-dev
