[Requests] OpenGIS Web Processing Service (RFPC 28) Response

Theodor Foerster foerster at itc.nl
Fri Feb 3 12:22:11 EST 2006

Dear committee,
The attachment of this email contains the pdf with this public comment
just in a printer and reader friendly version. Feel free to choose your

This public comment is the result of the research on the WPS done by the
generalization group at the ITC. We are utilizing the specification to
make our developed algorithms accessible to the public, by using this
service. In general we would like to point out, that the current service
is a good media to share results (in terms of developed algorithms)
within the research community. But there are some problems with the
specification itself. It contains until now some critical points, which
have to be fixed before we can optimally use the service. 
We would like to mention our WPS 0.4.0 prototype implementation, which
is running currently at:
Further information about this implementation is also available at:
Most issues pointed out below were also discussed with Peter Schut via
email during the last weeks.

1. Evaluator: Theodor Foerster, ITC Enschede NL, foerster at itc.nl,
www.itc.nl 2. Submission: OGC Request 28: Web Processing Service (WPS):
Request for Public Comments


 1. Specification Section number: GENERAL    
 2. Criticality: MAJOR: Establish a repository for well defined
standardized processes 
 3. Comments/justifications for changes: The WPS at this time is not
very capable in describing his operations in a semantic way. In order to
establish a geo spatial processing web the OGC should specify a
repository, which contains a hierarchy of processes. Each process is
well-defined by a description of input and output parameters. In the end
after specifying such repository with the standardized operations, it
will be an easy task for geo processing providers to refer to this
repository, when they are setting up their processes. Just think of a
routing process, which will be provided by ESRI and google at the same
time by just referring to the repository. In future such a repository
should be semantically enriched. The SWE WG had a similar problem and
are supposing to identify their phenomena by URNs, which point to GML
dictionary files.

 1. Specification Section number: GENERAL 
 2. Criticality: MAJOR: Use of OGC Web Notification Service (WNS) to
improve asynchronous service communication for ExecuteResponse 
 3. Comments/justifications for changes: Currently when the WPS stores
process results the client (service or end-user client), won't get
informed about that. The client has to check that for itself. This is
simply a restriction of using HTTP. 
However, the OGC provides a specialized service to deal with this
restriction. The Web Notification Service can be used to enable
asynchronous communication. The specification should be extended to this
issue in order to lead the Geo-Spatial Processing Web to the next level.
The client could choose between different communication-channels such as
email, short message or even a HTTP callback. In case of a service chain
a HTTP callback would improve the performance of such chains because the
requesting service would be just informed after processing the data. The
requesting service could be directly served with the process result or
with a link to the process result. This would also decrease the network
traffic for both participants to a minimum. This feature would also
increase the usability of such processing services for end-user clients.
The idea to use the WNS could also lead to a second communication
pattern, in which the WPS could ask the client for assistance by using
the WNS, if an error occurs while process execution. Such a two-way
communication pattern would also increase the performance of a WPS
because the data doesn't had to be loaded completely again. Also that
would give some transparency of processing to the user.
We claim that the adoption of the WNS in the WPS specification will lead
to a very new way of processing in the web, because of increased
processing performance and usability.

 1. Specification Section number: GENERAL  
 2. Criticality: MAJOR: Include server URL in the
 3. Comments/justifications for changes: Currently it is hard to reuse
ExecuteResponseDocuments, because you won't find any information about
the belonging WPS instance. By just adding a target URL to such
documents would be no problem. This actually is a not a big change of
the specification but leads perhaps to a new scenario of service usage. 
This approach is very interesting if you want to shift the Geospatial
Processing Web to the next stage. This stage would provide the discovery
and reuse of processes. Just think of searching process results through
google and learning from other process documents and perhaps reusing
them with different parameters but the same service!

 1. Specification Section number: Section 8.3.5 Capabilities document
 2. Criticality: MINOR: Power of OWS specification not fully utilized.
 3. Comments/justifications for changes: The specification should
provide a capabilities example, by using the full power of the OWS
specification to describe the WPS Operations. Mainly the complete
description of the ows:parameters of the WPS operations is missing.

 1. Specification Section number: Section 9.2.2 DescribeProcess request 
 2. Criticality: EDITORIAL: Delete the quotes in the request example 
 3. Comments/justifications for changes: To avoid confusion with people,
who are not familiar with HTTP GET KVP encoding, please delete the
quotes in the example request.

 1. Specification Section number: Section 9.2.2 & 9.2.3 DescribeProcess
 2. Criticality: MINOR: Identifier should be optional for compliance
issues with other OGC specifications (e.g. WFS, WCS).
 3. Comments/justifications for changes: To retrieve a process
description it is always necessary to request one or more specific
identifiers at this time. This rule is not compliant to the established
standards of OGC. The DescribeCoverage and the DescribeFeatureType
Operation make only use of an optional identifier parameter. I would
propose to change that in the WPS specification in such a way that if
the identifier parameter is missing or empty, the WPS returns a
description of all available processes. I got already a comment by
Arliss Whiteside on this issue. He claims, that the OWS Common RWG
considers a special well-defined value for the identifier parameter (for
instance ALLPROCESSES). This is also applicable. However, this issue
should be clearly defined in the next release of the specification.

 1. Specification Section number: Section 9.3 DescribeProcess operation
 2. Criticality: MAJOR: Role of ComplexValueReference in the
DescribeProcess undefined 
 3. Comments/justifications for changes: To execute a process on a WPS
it is possible to use the ComplexValueReference element as an
IOValueType. This element is actually not described in the
wpsDescribeProcess.xsd nor mentioned as mandatory support in the
specification itself. Such additional information is really necessary in
order to implement and use the WPS correctly.

 1. Specification Section number: Section 10.2.1 Execute request
 2. Criticality: MAJOR: Enable ComplexValueReference for HTTP POST 
 3. Comments/justifications for changes: The WPS provides a facility to
provide data to the service by just passing an URL in the
ComplexValueReference. We propose to extend this mechanism to support
HTTP POST. This mechanism would increase the support of chaining WPS
dramatically. The POST data could be simply included inside the
ComplexValueReference element. This is a straight forward approach and
does not need any big change in the specification. Other approaches like
migrating the functionality of the ComplexValueReference element to the
ComplexValue element, we would regret.

 1. Specification Section number: Section 10.3.1 Execute operation
 2. Criticality: MINOR: Include timestamp into ExecuteProcessDocuments 
 3. Comments/justifications for changes: Currently it is not possible to
compare two equal ExecuteResponseDocuments according time. This could be
of interest, if you want to track the changes according time. This is
not only interesting for debugging purposes, but also for discovery and
reuse of ExecuteResponseDocuments. We claim also that such additional
information would increase the transparency of processing service
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WPS Public Comment Theodor Foerster.pdf
Type: application/octet-stream
Size: 24697 bytes
Desc: WPS Public Comment Theodor Foerster.pdf
Url : https://mail.opengeospatial.org/mailman/private/requests/attachments/20060203/7e248b84/WPSPublicCommentTheodorFoerster-0001.obj

More information about the Requests mailing list