[QGIS-Developer] [GRASS-dev] External providers in QGIS

[G. Allegri]

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 <Stefan.Blumentrath at nina.no>:

> 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:grass-dev-bounces at lists.osgeo.org] On Behalf Of
> Paolo Cavallini
> Sent: torsdag 8. februar 2018 09.04
> To: G. Allegri <giohappy at gmail.com>
> Cc: qgis-developer <qgis-developer at lists.osgeo.org>;
> saga-gis-developer at lists.sourceforge.net; grass-dev <
> grass-dev at lists.osgeo.org>; Victor Olaya <volayaf at gmail.com>
> 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
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180208/ec219c10/attachment-0001.html>