• Tidak ada hasil yang ditemukan

Change Requests | OGC

N/A
N/A
Protected

Academic year: 2017

Membagikan "Change Requests | OGC"

Copied!
2
0
0

Teks penuh

(1)

All Fields marked with

*

are mandatory.

Name:

*

Alexandre Robin

Organization:

*

Spot Image

Email:

*

[email protected]

Document

Name/Version:

*

Web Processing Service / 1.0.0

OGC Project

Document:

*

05-007r7

If this is a revision of a previous submission and you have a Change Request Number, then check here:

Enter the CR number here:

Enter the Revsion Number that you are revising here:

Title:

*

Divide in core and extension

Source:

*

Spot Image, UAH

Work item code:

Category:

*

Reason for

change:

*

Currently the WPS specification defines two ways to describe inputs and outputs. The first way is via a simple set of OWS Common

parameter objects and the second is via XML schema. WPS needs to adpapt better to other data models used in OGC. In particular it would be useful to use the SWE data models to define WPS inputs and outputs so that it can be easily connected to SWE services such as SOS, SPS and the future SAS/SES. When WPS is used to process coverage data, it would be useful that the input/output descriptors align with existing coverage metadata standards.

Summary of

change:

*

The requested change is to refactor the specification into core + extensions, so that it is possible to write extensions for different input/output encodings (similar to what was done in WCS). The core of the specification should address the behavioral model of WPS (i.e. the role of each operation, the general way the input/output structure and

(2)

semantics definition can be obtained by clients, how asynchronicity is handled, how notifications about processing status can be requested, etc...). The extensions however would focus on defining the exact syntax for describing and encoding input and output data.

Consequences if

not approved:

WPS will remain too generic and hardly interoperable (i.e. basically equivalent to a WSDL defined service). Making WPS adopt more specific encodings makes a much more robust and unambiguous description of inputs/outputs possible.

Clauses affected:

*

Overall redesign of the specification needed

Additional

Documents

affected:

Supporting

Documentation:

Comments:

Status:

Disposition:

Referensi

Dokumen terkait

semantics are to be communicated over the service. The following items should be addressed in an Application Profile. a) Identify information resource types that can be requested.

In addition, service requests and responses now allow additional parameters via extension elements (see SWE Service Model specification, work in progress and foreseen to be ready at

When time zone offsets are used in a temporal element of a client request, the server processing the request shall interpret temporal information with respect to the client’s

Specification Section number: 12..3.1 GetData normal response parameters. Criticality:

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be

Omitting this GridCRS thus requires output of exactly the offered coverage range values, at (some of) the offered grid points, so no interpolation is required to be performed by

This will indicate that a WFS must generate a GML document of the result set that conforms to the OpenGIS  Geography Markup Language Implementation Specification, version 3.1.1

Reason for change:  The WPS 1.0.0 specification does not provide any mechanism for querying the status of an asynchronous process, though the specification does require an