[Qgis-developer] QGIS Processing Framework

[Julien Malik]

Hello,

I have the same opinion as Martin and Paolo.
 From our point of view, WPS services would just be another place to 
wrap our modules.

Anyway, I agree with the fact that there shall be a lot of ideas to get 
inspiration from, so that :
- WPS services can be integrated in the Qgis framework out of the box
- Any Qgis processing modules can be wrapped in a future "Qgis WPS 
server" (?)
- We can reuse all the good ideas from the WPS standard



Le 29/04/2011 10:45, Soeren Gebbert a écrit :
> 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
>>