This article includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. Please help improve this article by introducing more precise citations. (September 2013) (Learn how and when to remove this message)

The OGC Web Processing Service (WPS) Interface Standard provides rules for standardizing inputs and outputs (requests and responses) for invoking geospatial processing services, such as polygon overlay, as a web service. The WPS standard defines how a client can request the execution of a process, and how the output from the process is handled. It defines an interface that facilitates the publishing of geospatial processes and clients’ discovery of and binding to those processes. The data required by the WPS can be delivered across a network or they can be available at the server. WPS can describe any calculation (i.e. process) including all of its inputs and outputs, and trigger its execution as a web service. WPS supports simultaneous exposure of processes via HTTP GET, HTTP POST, and SOAP, thus allowing the client to choose the most appropriate interface mechanism. The specific processes served up by a WPS implementation are defined by the owner of that implementation. Although WPS was designed to work with spatially referenced data, it can be used with any kind of data.

WPS makes it possible to publish, find, and bind to processes in a standardized and thus interoperable fashion. Theoretically, it is transport/platform neutral (like SOAP), but in practice it has only been specified for HTTP.

WPS defines three operations:

1. GetCapabilities returns service-level metadata
2. DescribeProcess returns a description of a process including its inputs and outputs
3. Execute returns the output(s) of a process

WPS operations are invoked by submitting XML or URL-encoded requests to an Online Resource URL. When requesting an Execute operation the HTTP request identifies the inputs, the name of process to be executed, and the form of output to be provided.

WPS has the following properties:

1. Inputs can be web-accessible URLs or embedded in the request.
2. Outputs can be stored as web-accessible URLs or embedded in the response.
3. For a single output such as a GIF image, WPS can return the output directly, without any XML wrapper.
4. It supports multiple input and output formats.
5. It supports long-running processes.
6. It supports SOAP and WSDL.

A WPS is usually not invoked directly. More often, it is invoked by a client application that provides the user with interactive controls. This client application may or may not be web-based.

WPS version 2.0 was released in 2015. Previous version 1.0.0 was released to the public in June 2007. Version 0.4.0 was released as an OGC Request for Public Comment in 2005 and implemented by several early adopters.

• WPS Simple
• Web Feature Service
• Web Map Service

• OpenGIS Web Processing Service (WPS) Standard, Version 1.0.0
• WPS resources at geoprocessing.info
• OSGeo Evaluation of WPS 0.4.0
• OGC WPS Interoperability Experiment press release
• OGC WPS Request for Public Comments
• deegree Open source Java implementation (WPS 0.4.0 & WPS 1.0.0) with example processes
• WPSint Open source Java implementation of WPS 0.4.0 (includes a generic client)
• PyWPS Open source Python implementation of WPS 1.0.0
• ZOO Project WPS implementation of WPS 1.0.0
• WPS.NET Open source .NET implementation of WPS 1.0.0
• QGIS WPS client
• OGC-Services.NET - Free List of OGC Services (New Services can be added manually)
• OpenLayers Contains WPS Parser
• Process Server Service throughout Maricopa County