Let's get started by installing and learning the basics of WPS. We'll start by installing the plugin and noticing changes in the web administration interface within GeoServer. You'll learn about the WPS standard and basic structure, and finally, we'll look at a simple WPS request.
WPS is an interface standard, similar to WMS and WFS; however, the data output by WPS is dynamically created by a process or set of processes run by the WPS server; in our case, GeoServer. Like WFS, a request can be sent synchronously or asynchronously via HTTP POST or HTTP GET. The WPS standard defines the format of the expected input and output of the processes it interfaces with, so the data that you send in needs to match the expected data format of the service.
An example of this could be a buffer process that takes, as an input, a geographical coordinate expressed as JSON, and produces a polygon overlay that is perhaps produced as GML, and then that is displayed on a map in a web app, as shown in the following diagram:
First we need to install the WPS plugin with GeoServer, as this capability is not available in GeoServer without the plugin. The way that you do that is the same as for other plugins and GeoServer. You go to the released download page (http://geoserver.org/release/stable/), and the Extensions section is at the bottom. You download the WPS services zip archive, and expand it, and then pull it into the WEB-INF plugins directory. WPS can be used with HTTP GET and HTTP POST.
The following is an HTTP GET WPS request:
http://localhost:8080/geoserver/ows?service=wps&version=1.0.0&request=GetCapabilities
After we've installed the WPS plugin, we can now send a WPS request to GeoServer, and, through this URL, we're using the get capabilities operation within WPS which, like WFS or WMS, just gives us an XML representation of all of the processes that the WPS server supports.
And you can see, here we have many processes, such as this envelope process, which you may recognize from other GIS packages you might have used, as shown in the following code snippet:
<wps:Process wps:processVersion="1.0.0">
<ows:Identifier>geo:envelope</ows:Identifier>
<ows:Title>Envelope</ows:Title>
<ows:Abstract>
Returns the smallest bounding box polygon that contains a geometry.
For a point geometry, returns the same point.
</ows:Abstract>
</wps:Process>
Here's a polygon extraction process, as shown in the following code snippet, and these are namespaces that correspond to the underlying code that's used to create the WPS service:
<wps:Process wps:processVersion="1.0.0">
<ows:Identifier>ras:PolygonExtraction</ows:Identifier>
<ows:Title>Polygon Extraction</ows:Title>
<ows:Abstract>
Extracts vector polygons from a raster, based on regions which are
equal or in given ranges
</ows:Abstract>
</wps:Process>
This is created before we install the plugin. It's more or less outside of our control, unless we want to do coding in Java, I guess. So, there are some different namespaces here, such as ras:PolygonExtraction, vec:VectorZonalStatistics, and so on. These are not something you'll be modifying, really, but it's good to know that there are different operations within different namespaces in WPS.
After we've installed the WPS plugin, we also have some additional options in our GeoServer instance. This process status is connected to WPS. We have a WPS Settings area, and a Security area, and in our Demos we now have the ability to create requests with a WPS request builder and Demo requests.
Just a word about WPS syntax: the syntax, similarly to when we were using WFS and WMS, is defined on a specification, and you can get the details of the specification if you go through the documentation. Open Geospatial (http://docs.opengeospatial.org/is/14-065/14-065.html#15) is the best place to look for that. You can see that this execution type request (WPS GetCapabilities request), as shown in the following diagram, will be the main operation that we'll be using to run different kinds of processes:
The processes are those geometric operations that we noticed, and they get a capabilities document response. And you'll get a better example of how an execute operation is defined in the WPS XML, but I will mention that you'll see the identifier or come up a lot, which can be used to identify a process or identify a reference, which will be usually some kind of external data. We'll also see some kind of XML about the response and how to format that.
So, let's take a look at a simple WPMS, or WPS request, through the Demo requests area of GeoServer. We've used this in the past with WFST, and we have these WPS options now, after installing WPS, as shown in the following screenshot:
Let's try to check out a WPS request. The following code will be sent as a HTTP POST request via the following XML:
<?xml version="1.0" encoding="UTF-8"?><wps:Execute version="1.0.0" service="WPS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.opengis.net/wps/1.0.0" xmlns:wfs="http://www.opengis.net/wfs" xmlns:wps="http://www.opengis.net/wps/1.0.0" xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc" xmlns:wcs="http://www.opengis.net/wcs/1.1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd">
<ows:Identifier>gs:Aggregate</ows:Identifier>
<wps:DataInputs>
<wps:Input>
<ows:Identifier>features</ows:Identifier>
<wps:Reference mimeType="text/xml"
xlink:href="http://geoserver/wfs" method="POST">
<wps:Body>
<wfs:GetFeature service="WFS" version="1.0.0"
outputFormat="GML2"
xmlns:sf="http://www.openplans.org/spearfish">
<wfs:Query typeName="topp:states"/>
</wfs:GetFeature>
</wps:Body>
</wps:Reference>
</wps:Input>
<wps:Input>
<ows:Identifier>aggregationAttribute</ows:Identifier>
<wps:Data>
<wps:LiteralData>PERSONS</wps:LiteralData>
</wps:Data>
</wps:Input>
<wps:Input>
<ows:Identifier>function</ows:Identifier>
<wps:Data>
<wps:LiteralData>Count</wps:LiteralData>
</wps:Data>
</wps:Input>
<wps:Input>
<ows:Identifier>function</ows:Identifier>
<wps:Data>
<wps:LiteralData>Average</wps:LiteralData>
</wps:Data>
</wps:Input>
<wps:Input>
<ows:Identifier>function</ows:Identifier>
<wps:Data>
<wps:LiteralData>Sum</wps:LiteralData>
</wps:Data>
</wps:Input>
<wps:Input>
<ows:Identifier>function</ows:Identifier>
<wps:Data>
<wps:LiteralData>Min</wps:LiteralData>
</wps:Data>
</wps:Input>
<wps:Input>
<ows:Identifier>function</ows:Identifier>
<wps:Data>
<wps:LiteralData>Max</wps:LiteralData>
</wps:Data>
</wps:Input>
<wps:Input>
<ows:Identifier>singlePass</ows:Identifier>
<wps:Data>
<wps:LiteralData>false</wps:LiteralData>
</wps:Data>
</wps:Input>
</wps:DataInputs>
<wps:ResponseForm>
<wps:RawDataOutput mimeType="application/json">
<ows:Identifier>result</ows:Identifier>
</wps:RawDataOutput>
</wps:ResponseForm>
</wps:Execute>
You can see Identifier identifying the Aggregate operation or process, and gs is the namespace. This just means that this is a GeoServer-specific WPS process, and there will be some features that are given as input into this process. In this case, the features are coming from the WFS service on the GeoServer, and there are a couple of other parameters that are defined here in input and identifier areas, along with literal data. Here you can see the output format; the raw data output will be expressed as JSON. So now, if we Submit this request, in return we will get the aggregation results expressed in JSON, which is as follows:
This is aggregating some information about states and population. So now, you've seen a simple WPS request. In the next section, you'll see how to create a WPS request with a request builder.
