OGC API - Processes SWG
Pross, Benjamin (52°North Spatial Information Research GmbH) - Group Chair,
Cauchy, Arnaud (Airbus Defence & Space) - Vice Chair,
Tillman, Stan (Hexagon) - Vice Chair
The purpose of this Standards Working Group is to:
· Develop and maintain an OGC API - Processes core standard.
· Develop and maintain extensions of the OGC API - Processes standard as identified in section 4 (Scope).
· Maintain the WPS standard.
The formal proposed name of the new multi-part standard is "OGC API - Processes". The short name “Processes API” may also be used to refer to this effort in the charter and work products.
In April 2019, Gartner projected that the worldwide public cloud services market would grow from $182.4 billion in 2018 to total $331.2 billion by 2022. OGC API - Processes, like its predecessor (WPS), provides a standardized mechanism so that computational geospatial processes can be deployed and offered as services within Cloud Computing environments. Such capabilities have been demonstrated in OGC initiatives such as Testbed-14 and the Routing Pilot Pilot. In addition to the growth in the Cloud Computing market, the growth in the microservices market is also expected to provide opportunities for OGC API - Processes.
OGC API - Processes will offer organizations the opportunity to web-enable geospatial software libraries and utilities that, up until now, had only been available as standalone desktop products. Use of OpenAPI in OGC API - Processes will enable the wider API-developer community to integrate geospatial capabilities into their solutions with greater ease.
In the OGC, the use of OpenAPI has provided a standard framework for describing and sharing API definitions. The concept of a Processes API was demonstrated in various OGC Innovation Program initiatives.
The OGC API - Processes SWG will build on those preliminary efforts to more fully develop and document a Processes API candidate standard that will provide a web based, common, and consistent interface to services that aligns with the current architecture of the Web and the W3C Spatial Data on the Web Best Practices.
The OGC API - Processes SWG will develop a Processes API candidate standard which is informed by emerging OGC API best practices and prior API standards work (e.g., OGC API - Features) to define core API functions of GET, PUT, PATCH, POST, DELETE applied to processes as resources. The Processes API will also document metadata requirements for processes to enhance discovery and execution of processes.
· Architecture: The OGC API - Processes standard will specify an implementation standard aligned with prior work in the OGC for processes and Web APIs. The proposed standard will define API building blocks for processes in Web API. OGC API - Processes will be consistent with HTTP and HTTPS.
· Encodings: The first version of the Processes API will support JSON and HTML as encodings for descriptions of process resources in the API. The JSON encoding will be mandatory but other encodings may be used as well. The HTTP focus is designed to support the use of multiple formats and defines rules about how servers can return the encoding that the client can best handle (“content negotiation”).
· Information model: The Processes API standard will be defined using OpenAPI 3.0 and OGC API best practices. The information model will consider recommendations from recent and current OGC Innovation Program initiatives such as Testbeds, Pilots, Sprints and others.
· Modularization: OGC API - Processes - Part 1: Core will define a basic set of capabilities organized in multiple conformance classes building on each other. The minimal conformance class will specify a simple interface to access metadata about processes that is sufficient for interfaces to perform web functions with the processes. Additional conformance classes will define additional capabilities based on the requirements and requirements classes defined in the core to meet the needs of use cases that require such capabilities.
· Reuse: The use of unique Processes API resources or components will be minimized and, where available, existing industry-standards or patterns that are commonly used by developers will be used instead. The most important example for this is the use of an OpenAPI definition instead of OGC-specific "Capabilities" documents. The Processes API will also use OGC API - Common components to the maximum extent practicable.
Extensions may be proposed and addressed in revisions to this charter. The primary goal of the Processes API SWG is to develop the core of "OGC API - Processes" as quickly as possible and work on extensions after that, driven by community interest. An important aspect is to ensure that implementing the standard will lead to efficient implementations, happy developers of both server and client components, and satisfied users of such components.
Before finalizing parts of the future versions of the "OGC API - Processes", completion of goals should be verified:
· Working implementations of all capabilities must be available and tested.
· Implementation feedback must be taken into account.
A consequence of this verification is that the period between the availability of what is considered a mature draft and the finalization of the candidate standard may be longer than in the past, depending on the availability of evidence about the suitability of the candidate standard based on implementations. Developers should be encouraged as early as possible to implement the draft API specification and provide feedback. An aspect of this is providing public access to drafts from the beginning. To this end, the SWG intends to use a public GitHub repository in the development of this standard as this is the environment many developers are familiar with and use on a daily basis.
3.1 Statement of relationship of planned work to the current OGC standards baseline
This proposed standard is intended to be a major component of the OGC API framework. The proposed standard will take advantage of Web API patterns identified in OGC API standards (e.g., OGC API – Features) and other ongoing API efforts (e.g. OGC API - Common development in OWS Common SWG) to better align with current and emerging IT practices. The Processes API provides a means for sharing process resources.
3.2 What is Out of Scope?
Standards are important for interoperability. At the same time, it is important that standards only state requirements that are important for a significantly large group of users. Proposals for new parts of OGC API - Processes or change requests to existing parts must identify the user group that will benefit from the proposal and for each proposed conformance class. Otherwise the proposal will be considered out-of-scope.
OGC API - Processes is envisioned to be a modular, multi-part standard. Extensions and profiles not identified as in scope in the previous section will require a revision to the SWG charter prior to commencement of work. If a community has a need to develop a profile, the profile should be specified and governed by that community.
The basic resources described in OGC API - Processes are processes. The Processes API describes the interface and execution of processes.
3.3 Specific Contribution of Existing Work as a Starting Point
The starting point for the work will be the draft document that is currently on the proposed SWG’s repository (https://github.com/opengeospatial/wps-rest-binding). This charter recognises the prior work done by the Web Processing Service (WPS) SWG. Upon approval of this Charter, the Web Processing Service (WPS) SWG will be renamed to the OGC API - Processes SWG and responsibility for OGC API - Processes shall be transferred to the proposed OGC API - Processes SWG.
The work shall also be informed by the following specifications and by recommendations found in:
· OGC/W3C Spatial Data Working Group on the Web Best Practices (https://www.w3.org/TR/sdw-bp/);
· OGC Geospatial API White Paper [OGC 16-019r4];
· OGC API - Features - Part 1: Core standard, [OGC 17-069r3].
Each of these documents recommends an emphasis on resource-oriented APIs in future OGC standards development including use of tools such as OpenAPI.
4.1 Initial Deliverables
The following deliverables will result from the work of this SWG:
· A final version of the "OGC API - Processes - Part 1: Core" document for submission to the TC;
· Identification of at least three prototype implementations of the core based on the standard — although more would be preferred; and
· Zero or more additional extensions as time and community interest permits.
Part 1 will cover basic capabilities to GET, PUT, PATCH, POST, and DELETE processes and define process metadata. Capabilities for richer process interfaces or extension for unique geospatial resource considerations will be specified in additional parts.
The targeted start date is in July 2020 or once charter is approved. Formal approval of the core Processes API is envisaged to take place nearer December 2020.
4.2 Additional SWG Tasks
To be completed as SWG takes on new tasks.
✓ RAND-Royalty Free. RAND for fee
· Geospatial resource providers.
· Developers implementing services, including microservices.
· Cloud computing providers
· Users of geospatial resources.
· Big Data providers
The Workflow DWG will review the proof-of-concept at https://github.com/opengeospatial/wps-rest-binding and this SWG charter. A statement of endorsement is anticipated at the June 2020 Virtual OGC Members' meeting.
a. Similar or Applicable Standards Work (OGC and Elsewhere).
The following standards work may be applicable to the work of the proposed SWG:
· 17-069, OGC API - Features
· 14-065, OGC Web Processing Service (WPS) standard
Additionally, the proposed SWG will monitor other OGC API work ongoing in various Standards and Innovation Program activities.
b. Details of the First Meeting
The first meeting of the SWG will be within four weeks of approval of the SWG.
c. Projected On-going Meeting Schedule
The work of this SWG will be carried out primarily on GitHub and via email, conference calls, with potential face-to-face meetings at OGC TC meetings as agreed to by the SWG members. The teleconference calls will be scheduled as needed and posted to the OGC portal. Voting on Processes API content will be limited to SWG members only.