Lesson plan

Web Processing Service

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 it 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.

Back to article

Article summary

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 it 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.

Key claims

  1. release date: 2015 — source: Wikipedia · confidence 0.95
  2. release date: 2007 — source: Wikipedia · confidence 0.95
  3. release date: 2005 — source: Wikipedia · confidence 0.95

Discussion questions

  1. Summarise the article in your own words. Which single claim would you verify first, and why?
  2. The record states that the release date is "2015". What evidence would count against this claim?
  3. The record states that the release date is "2007". What evidence would count against this claim?
  4. The record states that the release date is "2005". What evidence would count against this claim?
  5. Which claim in this article is most likely to be revised as the sources update? How would you check its current status?
  6. If two sources disagreed about one of these facts, what would you need in order to trust one over the other?

Bibliography

  1. Wikipedia https://en.wikipedia.org/w/index.php?oldid=1371177275

Key claims and bibliography are generated from the same tracked claims and sources as the article page.