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

Clemens Portele portele at interactive-instruments.de
Sat Feb 4 05:15:25 EST 2006


Part A is to be completed once per evaluator per comment submission.  Please
iterate over Part B as needed.

PART A
------

1. Evaluator:
Clemens Portele, interactive instruments GmbH
portele at interactive-instruments.de


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


PART B
------

1. Specification Section number: GENERAL
2. Criticality: MAJOR
3. Comments/justifications for changes:
Since a number of other OGC specifications or discussion papers specify
service interfaces that could be classified as processing services (if local
datasets are brought back as mentioned in future work this seems to include
in fact most OWS), it would be important to have a strategy and guidance
when a processing service should be specified as a seperate specification or
specified as a WPS application profile. The concern is that if this is not
done, it will lead to confusion.


1. Specification Section number: GENERAL, Foreword
2. Criticality: MAJOR
3. Comments/justifications for changes:
The foreword mentions a renaming from "geoprocessing service" to "processing
service". No rationale for the name change is provided, but my general
feeling is that OGC should rather concentrate on geoprocessing services
instead of general processing services. OGC should avoid developing (or
duplicating) general IT specifications whenever possible.
Indeed the scope states that this specification "can be used to describe and
web-enable any sort of *geospatial* process" (emphasis mine).
Therefore, I would propose to reverse the name change (while keeping WPS as
the acronym).
Related to this is that the content of the specification does not seem to be
really "geo-specific". It should be clarified how the WPS specification
specifically addresses the issue of *geospatial* processes as stated in the
scope.


1. Specification Section number: GENERAL
2. Criticality: MAJOR
3. Comments/justifications for changes:
The document is surprisingly quiet about service chaining aspects. Using,
for example, other WxS instances as input always seemed to me to be an
essential characteristc of a Web (Geo)processing Service and I remember that
this was previously presented as a feature of the WPS. However, this aspect
is not mentioned or discussed in the current draft as far as I can see. The
scope only mentions "data inputs".
The only mention I have found is in the example:
 <Input>
  <ows:Identifier>InputPolygon</ows:Identifier>
  <ows:Title>Playground area</ows:Title>
  <ComplexValueReference ows:reference="http://foo.bar/some_WFS_request.xml"
schema="http://foo.bar/gml_polygon_schema.xsd" />
 </Input>
However, without knowning the XML and XSD files, this does not seem to a
good example as a WFS returns features and not polygons.
It is also not clear to me, if chaining can work over multiple steps (and
whether this is within scope or not), eg where a WPS accesses a WPS which
accesses a WCS or WFS.
Therefore:
- The scope should clarify that "data inputs" includes access to OGC Web
Services, too.
- Add a clause specifying how WPS can and shall be used in service chains.


1. Specification Section number: Scope
2. Criticality: MINOR
3. Comments/justifications for changes:
It is stated that "To achieve interoperability, each process must be
specified in a separate document, which might be called an Application
Profile of this specification." This language does not seem appropriate for
a scope statement. Proposal: "To achieve interoperability, each process has
to be specified in an Application Profile of this specification."


1. Specification Section number: Scope and several other clauses
2. Criticality: MINOR
3. Comments/justifications for changes:
References to GDAS do not seem to be appropriate for an OGC specification as
it seems to be a specification used in the Canadian SDI only (unlike GeoTIFF
or GML). Remove references to GDAS (and CGDI) from all normative parts of
the document.


1. Specification Section number: 3
2. Criticality: MINOR
3. Comments/justifications for changes:
19105 is typically not listed in the normative references. Unless there is a
specific reason, it should be removed and perhaps moved to the glossary.


1. Specification Section number: 5.3
2. Criticality: MINOR
3. Comments/justifications for changes:
05-008 states in its scope: "Rather than continuing to repeat this material
in each such Implementation Specification, each specification should
normatively reference each relevant part of this document." However, the
document elects not to follow this recommendation, which should be
reconsidered.
Note that there seems to be inconsistency as it is stated in Clasue 6: "Many
of these interface aspects that are common with other OWSs are thus
specified in the OpenGIS® Web Services Common Implementation Specification
[OGC 05-008]. Many of these common aspects are normatively referenced
herein, instead of being repeated in this specification."


1. Specification Section number: Table 23
2. Criticality: QUESTION
3. Comments/justifications for changes:
What is the meaning of a default UoM since many different measure types will
often be used (length, area, speed, weight, etc)? Shouldn't this be one
default per type?
Related: The examples contain defaultUOM values which are not URIs (e.g.
"meters").


1. Specification Section number: Annex A
2. Criticality: QUESTION
3. Comments/justifications for changes:
Annex A states that "An abstract test suite is not provided in this version
of this Implementation Specification." Is this planned for the next release
(it is not listed under future work)? If not provided, should this annex be
removed (and clause 2 be adapted)?




More information about the Requests mailing list