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

Moritz Neun neun at geo.unizh.ch
Fri Feb 3 10:19:59 EST 2006


PART A
------

1. Evaluator:

Moritz Neun
Department of Geography, GIS Division, University of Zurich, Switzerland
neun at geo.unizh.ch
www.geo.unizh.ch/~neun/


2. Submission: OGC Request 28: Web Processing Service (WPS): Request for 
public comments



PART B
------

Specification Section number: GENERAL
Criticality: EDITORIAL
Comments/justifications for changes: COMMENTS

We have been experimenting on our own now for more than a year with web 
services for the execution of generalization algorithms. In [1] we show 
a classification of services and a first prototype for a generalization 
processing service called WebGen which is based on SOAP. Our proposal 
includes one or more central registry servers which are responsible for 
the listing of available services (GetCapabilities) and for the 
deployment of the service descriptions (DescribeProcess). See for more 
detail in [2] where this technique is proposed to be used to share 
algorithms in research, e.g. for enhancing comparability and making the 
reuse of existing algorithms easier. Although our web services were 
mainly intended for generalization the concepts are also applicable for 
Web Processing Services in general.

In general we make a distinction between the two service concepts 
middleware and standalone service (research platform). While the 
middleware is merely intended for the access of generalized data from 
e.g. WFS through such a middleware service, the standalone service gets 
the data from the service user who would e.g. upload the data directly 
to the server. The WPS specification seems to be a hybrid between those 
two concepts.

In [3] first thoughts about not only using standard geo-data (which can 
be expressed by e.g. GML) were presented. The intention was to have web 
services offering e.g. supporting data-structures such as triangulations 
or hierarchies. This goes beyond the abilities of e.g. the proposed 
buffering service which in fact has simple features as input and output.



Specification Section number: GENERAL
Criticality: MAJOR
Comments/justifications for changes: COMMENTS

The WPS specification is much too unspecific and open. Thus I don’t see 
it as a real standard, it’s merely a proposal how one could develop a 
web service for processing geographic data. This specification does 
neither define the data format nor the data schema or semantics. 
Consequently, accessing a WPS is very difficult, because the client has 
to be capable of so many different data formats. Thus a generic client 
program which could be used for accessing WPSes is probably almost 
unimaginable and the publish-find-bind concept of web services does not 
apply for WPS. But most of the geo operators have quite similar input 
and output requirements. Looking at vector data, as we use in our work 
on generalization algorithms and services, the map objects to process 
consist usually of a geometry which is a simple feature and a couple of 
attributes. Thus for most Web Processing Services a more standardized 
(structurally, and semantically) data format could be used. For most of 
the standard generalization algorithms we looked at in our WebGen 
project [2] this was completely sufficient. The more specific data 
formats [3] can still be left more open.

The WPS DescribeProcess does not include any geospatial specifics. Thus 
there is no advantage over e.g. WSDL. The WebGen prototype basically 
uses the WSDL concept and extends it with the ability to define the data 
schema (geometries and attributes) supported by the processing service. 
Thus the WebGen client program can take care of sending the data in the 
right schema. The data is then coded directly onto the SOAP 
communication as GML fragments. This is very straightforward and creates 
less overhead.

The WPS GetCapabilities functionality is not sufficient as it lists only 
the available services on one server. Thus for the retrieval of a 
specific service the server address must be known. The service discovery 
has to be done by the user e.g. in a web-browser and can not be included 
in the process. So, again the publish-find-bind rule of web services is 
not fulfilled as there are no yellow-pages (e.g. UDDI) where all 
services are registered. The WebGen prototype includes a registry server 
(can also be distributed for backup) where all services are registered, 
see [1] and [2]. This server holds the descriptions of the services and 
their endpoints where they can be reached. Every service provider just 
has to enter his/her service into this database. With this concept we 
try to fulfill the publish-find-bind concept, where mostly generic 
client programs can retrieve the services from the registry and demand 
the right data from the user.

Concluding the general comments I am absolutely in favor of a standard 
for Web Processing Services, but the proposed specification is far too 
open and is missing much geospatial relevance. With our WebGen prototype 
we defined a simpler, more generic and straightforward solution but with 
similar concepts (except the registry server). This could provide some 
improvements to the current WPS specification no matter which protocols 
are used.



REFERENCES
------

[1] Burghardt, D., M. Neun and R. Weibel. 2005. Generalization Services 
on the Web – A Classification and an Initial Prototype Implementation. 
Proc. American Congress on Surveying and Mapping, Auto-Carto 2005, Las 
Vegas, USA. http://www.acsm.net/cagis/Burghardt.pdf

[2] Neun M. and D. Burghardt. 2005. Web Services for an Open 
Generalisation Research Platform. Proc. 8th ICA WORKSHOP on 
Generalisation and Multiple Representation, A Coruña, Spain. 
http://www.geo.unizh.ch/~neun/publications/icaworkshop2005_neun_v2.pdf

[3] Neun M., D. Burghardt and R. Weibel. 2006. Spatial structures as 
generalisation support services. Proc. Joint ISPRS Workshop Workshop on 
Multiple Representation and Interoperability of Spatial Data, February 
22-24, Hannover, Germany. 
http://www.ikg.uni-hannover.de/isprs/workshop2006/Paper/6005/2-isprs_workshop2006_neun_r2.pdf



More information about the Requests mailing list