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 > _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
