[GRASS-dev] External providers in QGIS

Wed Feb 7 06:25:15 PST 2018

On Wed, Feb 7, 2018 at 3:03 PM, Victor Olaya <volayaf at gmail.com> wrote:

> I dont think that it is possible to make it more generic. It's not only
> descriptors with only outputs and inputs. Each backend app has its own
> logic. GRASS needs outputs to be converted to its own format. SAGA accepts
> only SHP for vector layers and generates its own SDAT format for raster
> outputs. Parameters are also not passed in the same way to all apps. SAGA
> has extent parameters splitted in 4 params with bbox coordinates. Each
> provider has a different way of indicating a boolean value in the console
> call. In short, the logic must be there somehow, specific for the provider,
>

can you confirm that a GRASS input/output parameter can solve their issue?.
Still there is SAGA and other stuff. So generic provider is not something
QGIS team can do. But I would like to know about this on GRASS issue.

> What is the difference between maintaining a set of descriptor files (as
> you propose) and a set of descriptor files + a class extending
> GeoAlgorithmProvider with the logic (as it happens now)?. I think it is
> easier to have a solid provider class for OTB and then do not ever change
> it (assuming OTB syntax will never change), than having a generic provider,
> which looks rather unfeasible.
>
> Still OTB requires some changes in processing plugin to work. the old way
of twisting application only for QGIS must be avoided.
Without such a change there is no long-term existence even as plugin. Or
worse, it exists and will be broken.
QGIS must recognize such a behavior and avoid adding  burden on external
toolboxes' developer teams by asking for splitting applications. Be it OTB,
GRASS, SAGA whatever.

While I was at it, I saw there is less stuff to be managed and can be done
using a customwidgetwrapper for OTB. because a custom widget wrapper works
in a special way only for one provider.
Hence the idea of generic provider came up!.  In  case of GRASS its
input/output parameter, for OTB it is selection list parameter.

Thanks for your valuable feedback on this. I am sure an idea of generic
provider came up sometime during your work on processing plugin.
It tough and need more expert work and safe is to avoid it totally. I agree
on that part.

> As you say, there is the risk for dead code. In that case, i think it is
> much better to have the provider outside of QGIS core, as a plugin. There
> are dozens of dead plugins, and that is not nice, but it's kinda
> acceptable. Having dead code in QGIS it's a much bigger issue, and we must
> avoid that.
>
> Cheers
>
>
>
> 2018-02-07 14:41 GMT+01:00 Rashad Kanavath <mohammedrashadkm at gmail.com>:
>
>> Hello victor,
>>
>> Do you see a possibility of a generic processing provider?. One that can
>> read descriptor files and run algorithms!.
>> I see processing as a single plugin (included in QGIS or not). And if it
>> can avoid need to have sub-plugin managed by all those other development
>> team. That's even better!.
>> Whichever toolbox want to be integrated into processing plugin can
>> provide and maintain descriptor files individually. No QGIS developers need
>> to be involved.
>> This way, external toolboxes' team or qgis does not need to maintain/fix
>> qgis-<TOOLBOX>-provider-plugin.
>>
>> search -> download -> install plugin will be changed to configure
>> providers install location.
>> If needed QGIS can control list of available providers (just names).
>>
>> External tools' dev team needs to know something such as spec of
>> descriptor files, how to mention name of executable etc.
>> They don't need to know stuff like how qgis run a processing algorithm,
>> and things working of modeler, running with other algorithms.
>>
>> Anyway, this is just an idea and don't know what will be technically
>> challenging issues?
>>
>> The other way of putting processing plugin into core and providers
>> classified as external plugins can avoid maintenance on qgis.
>> But this "strategy" can result in dead code and users complaining on both
>> projects. Because, at some developers cannot manage project release + a
>> plugin for qgis, another plugin for matlab or whatever
>> Putting all stuff in qgis tree and taking no responsibility of providers
>> isn't good either.
>>
>> This way, each team takes part and result in better collaboration and
>> contribution.
>> As time goes, generic descriptor provider gets better and stronger.
>> Toolboxes are free to add, remove, modify their applications and users from
>> both community benefit best of both worlds.
>>
>>
>> On Wed, Feb 7, 2018 at 11:18 AM, Victor Olaya <volayaf at gmail.com> wrote:
>>
>>> I dont see the advantage in having providers in core. And if there is an
>>> advantage, it's clearly not in how easy it is going to be to maintain the
>>> plugin. 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? 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.
>>>
>>> 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 thought the idea was to not have core plugins and avoid them if
>>> possible. I don't see why we have to treat plugins that have Processing
>>> provider in a different way. Specially considering how easy it is to
>>> install a plugin in QGIS.
>>>
>>> Cheers
>>>
>>>
>>>
>>> 2018-02-06 18:57 GMT+01:00 Paolo Cavallini <cavallini at faunalia.it>:
>>>
>>>> Hi all,
>>>> following the discussion on qgis-dev ML:
>>>> https://lists.osgeo.org/pipermail/qgis-developer/2018-Januar
>>>> y/051701.html
>>>> it has been proposed to remove all external providers (namely OTB,
>>>> already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will
>>>> remain as QGIS cannot be built without). This raised a number of
>>>> concerns, so PSC decided not to rush removing them from the upcoming 3.0
>>>> release, and to open a wider discussions about this, involving all the
>>>> interested parties, to find an optimal solution.
>>>> If volunteers outside QGIS core team, ideally from the respective
>>>> backends, could take the maintenance of these providers, not much would
>>>> change for the end user. If not, this will mean effectively missing
>>>> hundreds of algs from QGIS.
>>>> I personally propose to reinstate the OTB plugin with Rashad (from OTB)
>>>> as maintainer.
>>>> QGIS.ORG will seek to support any decision made with funding where
>>>> possible.
>>>> Looking forward for your feedback.
>>>> 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
>>>>
>>>
>>>
>>
>>
>> --
>> Regards,
>>    Rashad
>>
>
>

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