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

[Rashad Kanavath]

On Wed, Feb 7, 2018 at 7:07 PM, G. Allegri <giohappy at 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" <cavallini at 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-Developer at 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 at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180208/9e01a3d5/attachment-0001.html>