Using Web Processing Service¶
The webserver acts as a boker and proxy for all Web Processing Services integrated in the platform. He gathers all GetCapabilities of all WPS registered and returns this as an aggregated GetCapabilities response. The response is conform to the WPS standard defined by OGC (http://schemas.opengis.net/wps/1.0.0).
GetCapabilities¶
The portal API exposes a GetCapabilites service, describing all Web Processing Services accessible by the current logged user.
GET <portal_baseurl>/t2api/wps/WebProcessingService?service=wps&request=GetCapabilities
DescribeProcess¶
At next level the portal API exposes a DescribeProcess service, describing a given WPS service.
GET <portal_baseurl>/t2api/wps/WebProcessingService?service=wps&request=DescribeProcess&version=<serviceVersion>&identifier=<service_identifier>
Execute¶
Finally, the portal API implements the Execute service, requesting the execution of a job for a given WPS service.
POST <portal_baseurl>/t2api/wps/WebProcessingService?service=wps&request=Execute&version=<serviceVersion>&identifier=<service_identifier>
Altough depending on the WPS implementation, if the WPS provider follows correctly the guideline descried here the Execute Response shall return a statusLocation URL that can be polled to query the status of the execution.
Once completed the same URL shall return all the information to retrieve the results.
RetrieveResults¶
The portal API will return the results received from the proxy WPS Execute Response. It will analyze the outputs to provide with an OpenSearch service to query and get results in a standard way.
OpenSearch Description Document¶
If the analysis of the results allows it, the response contains one Output element identified result_osd with a Reference URL pointing to an OpenSearch Description.