-
Notifications
You must be signed in to change notification settings - Fork 120
Sutdent project ideas
PyWPS is one of the oldest implementations of the OGC WPS standard on the server side, written in the Python programming language.
Through time, the (geo-)Python environment has changed a lot which led the development team to rewrite PyWPS from scratch, resulting in the 4.0.0 release in late 2016.
We would like to offer several ideas, that intend to extend the current functionality provided by PyWPS. We are aware that users seek these new functionalities. Each of the ideas listed below provide the contents for BSc and MSc thesis and to the Google Summer of Code (GSoC).
For more details on these projects ideas, or on the PyWPS project itself, please join our mailing list.
PyWPS has to store the resulting data files somewhere. Currently, simple file storage is implemented - all resulting files are stored to a pre-defined output directory on the server. In the future, we shall support more sophisticated methods of data storage, for instance, to a database.
This includes raster, vector and other output data. They need to be effectively stored, together with their metadata, for later usage (e.g. deleting old files, usage statistics, etc.)
Mentor name: Jorge de Jesus (jorge.mendesdejesus wur nl)
Required skills: Python, PostgreSQL and PostGIS intermediate user, awaraness of OGC OWS services
PyWPS has to store the resulting data files somewhere. Currently, simple file storage is implemented - all resulting files are stored to a pre-defined output directory on the server. In the future, we shall support more sophisticated methods of data storage, for instance, to a database.
This includes raster, vector and other output data. They need to be effectively stored, together with their metadata, for later usage (e.g. deleting old files, usage statistics, etc.)
Mentor name: Jorge de Jesus (jorge.mendesdejesus wur nl)
Required skills: Python, SQLite intermediate user, awareness of OGC OWS services
PyWPS has to store the resulting data files somewhere. Currently, simple file storage is implemented - all resulting files are stored to a pre-defined output directory on the server. In the future, PyWPS shall support more sophisticated methods of data storage, like external cloud services.
Several services are in place - proprietary(-cloud) (Dropbox, Google Drive, Box, etc.) or standards(-protocols)-oriented (FTP, SFTP, WEBDAV, ...).
Mentor name: Jachym Cepicky, jachym.cepicky gmail com
Required skills: Python intermediate coder, awareness of OGC OWS services
The OGC WPS 1.0.0 Standard and its best-practice document enable the publication of OGC OWS services for its results. Naturally that would be OGC WCS and WFS (and WMS). PyWPS will never provide such functionality by itself, but it will use external services.
We would like to implement support for MapServer, to be used for output data serving, via OGC services. This should be done using a standard MapServer Mapfile configuration.
As part of MapServer OWS publishing, if a metadata document is available, PyWPS can publish directly to CSW given the CSW Transaction operation. Deeper integration with pycsw is also possible, considering that pycsw is also a Python implementation.
Having a rich publishing workflow to data and metadata services from PyWPS makes this workflow really attractive to so many downstream possibilities (GeoNode, QGIS) either directly in Python or via WPS proper.
Mentor name: Jonas Eberle, jonas.eberle gmx de and Luís de Sousa, luis.de.sousa protonmail ch
Required skills: Python intermediate coder with user experience in MapServer, awareness of pycsw and OGC Web services,
The OGC WPS 1.0.0 Standard and its best-practice document enable the publication of OGC OWS services for its results. Naturally that would be OGC WCS and WFS (and WMS). PyWPS will never provide such functionality by itself, but it will use external services.
We would like to implement support for GeoServer, to be used for output data serving, via OGC services. This should be done using the Geoserver REST interface
Mentor name: Jachym Cepicky, jachym.cepicky gmail com
Required skills: Python intermediate coder with experience in REST APIs, GeoServer user is advantage, awareness of OGC OWS services
The OGC WPS 1.0.0 Standard and its best-practice document enable the publication of OGC OWS services for its results. Naturally that would be OGC WCS and WFS (and WMS). PyWPS will never provide such functionality by itself, but it will use external services.
We would like to implement support for QGIS MapServer, to be used for output data serving, via OGC services.
Mentor name: Jachym Cepicky, jachym.cepicky gmail com
Required skills: Python intermediate coder with experience with QGIS, awareness of OGC OWS services
Chaining geo processing services based on OGC WPS Standard can be achieved in different ways based on the complexity of the application. Indeed there are existing possibilities mainly for SOAP-based web services in general (Taverna, BPEL), but in most cases a lot of effort needs to be invested to implement such services and process chains.
A good enhancement of PyWPS would be the integration of chaining geo processing services either published as a further process or defined by an input parameter (e.g., XML-based definition for process chaining). Following features could / should be included (further ideas are welcome):
- Status updating of parent process (=process of process chain),
- Provide access to results of subprocess, even if chain is still running,
- If/else conditions and for loops based on output values of subprocess,
- Logical data transfer if subprocesses are on the same machine (no unnecessary copy of data)
Mentor name: Jonas Eberle, jonas.eberle gmx de
Required skills: Python intermediate coder with experience XML and lxml, awareness of OGC OWS services
Providing operational running processing services requires often a tool to list executed processes with their current status to have an overview about usage and possible errors. Users and administrators could easily view a process log file, if generated from the process, and further information about the executed processes. Furthermore process actions - like an easy way to restart or delete an executed process - could be very helpful for the process management. An administration part could extend PyWPS to make it more user-friendly in creating services and changing settings.
The administration part could include:
- Create services, change settings of services
- Add new processes (e.g., provide a template process for further manual adjustments)
- Change process settings
- User management (?)
The process management part could include:
- List executed processes with their status (e.g., running, failed, succeeded)
- View process details (e.g., inputs, outputs, log file)
- Provide process actions (e.g., restart, delete)
- further ideas are welcome
PyWPS supports the OGC Web Processing Service 1.0.0. We would like to add support for the newer version of this standard. A stepwise approach is to be taken:
- XML parsing against the WPS 2.0 schema.
- Implement replies to those request that are common to WPS 1.0.
- Implement the new requests and request arguments introduced by WPS 2.0 (except
PauseandResume). - Implement the
PauseandResumerequests.
Required skills: Python intermediate coder with experience in XML and lxml, awareness of OGC OWS services.
Mentors names: Luís de Sousa, luis.de.sousa protonmail ch and Jachym Cepicky, jachym.cepicky gmail com