[Qgis-developer] QGIS Processing Framework

[Soeren Gebbert]

Hello Martin,

...
> I agree that all these are very good reasons for having WPS support in
> QGIS. It makes sense in a lot of use cases. Still I do not think we
> should concentrate exclusively on WPS services for processing for
> several reasons:
> - the community creates lots of handy plugins, many of them are used
> for processing. It is not just SAGA, OTB, GRASS or OSSIM that could
> use the framework - we are speaking about many more possible modules
> that probably will never be implemented as WPS services.
> - WPS servers are IMHO not really widespread yet(?). Surely you can
> install your own on a local computer but I don't think that an average
> user is able to manage it with few clicks. And not everyone has access
> to a fast server in basement.

IMHO installing a WPS server with different back-ends is no magic. The
web server, the WPS server and the back-ends can be bundled and
installed as easy as QGIS with all its plugins and libraries and third
party dependencies. This is technically no problem and IMHO the
52North guys are able to provide such an out of the box solution.

> - usability matters - a lot of work can be done by only editing few
> parameters and running the process, but there are plenty of cases
> where more interactivity is desired as mentioned also by Julien and
> Camilo: that could be a complex dependency between input parameters or
> a possibility for interactive picking of points from map canvas.

With WPS you can chain very complex processes with complex
dependencies, the interface description is in this case very powerful.
You are indeed totally right that its not possible to have interaction
with in principle state-less WPS processes. But you can have
interaction between processes with the intermediate generated results
in a process chain. This is a question of how to design process chains
with interaction and how specialized the available processes are.

>
> The reasons above make me believe that we shouldn't depend exclusively
> on WPS. In my vision WPS should be simply another provider of
> processing modules next to SAGA, OTB or various other smaller plugins.
> WPS itself simply cannot deliver the rich user interface that we would
> like to provide.

This is a good point. Maybe you can use the WPS specification as the
base technology and extend it with additional features which will not
break compatibility. Then you will use an OGC standard and you will be
able to integrate WPS processes out of the box in the much more
powerful framework with the possibility of chaining any kind of
processes?

You will still need wrapper for each software you want to integrate to
wrap there interface into the abstract QGIS process framework. So the
design of a really powerful abstract process framework providing
interaction and stuff is a lot of work and needs plenty of knowledge
about all the software which might be integrated as processes in QGIS.
To get an idea of the amount of work: Several very intelligent people
have designed the WPS specification and they needed several years to
version 1.0.0.

My main concern is the manpower which is needed to implement AND
maintain such a framework as well as the wrapper and binding for other
software packages. For example the GRASS GIS integration in QGIS. If
there is nobody in the GRASS GIS or QGIS community who is willingly to
take responsibility and time to maintain, update and extend it, it
will be unusable in the future or it will depend on an obsolete or
buggy GRASS GIS version.

I am absolutely not against a cool abstract process framework in QGIS,
but i would like to bring some IMHO important considerations into
discussion.

Best regards
Soeren

>
>
> Regards
> Martin
>