Additional implementations & experiments of modular OGC API workflows

[jerstlouis]

In the Modular OGC API Workflows project, we are developing specifications and prototype implementations of a simple and natural way to define client-driven processing chains connecting OGC API services.

Financial support for this project is being provided by GeoConnections, a national collaborative initiative led by Natural Resources Canada. GeoConnections supports the integration and use of the Canadian Geospatial Data Infrastructure (CGDI), an on-line resource that improves the sharing, access and use of open geospatial information.

We are developing this in active collaboration with the OGC API SWGs, OGC API - Processes in particular, and the main resulting specifications would become an extension to OGC API - Processes.

This extension provides the ability to chain nested processes, refer to external processes and collections accessible via OGC API standards, and trigger execution of processes through OGC API data delivery specifications such as OGC API - Features, Tiles, Maps and Coverages.

Additional information:

• Draft OpenAPI specifications
• OGC API - Processes issue
• Presentation to the Processes SWG at the last Members Meeting

Early implementations developed within the project include client-side support in GDAL and QGIS in a single unified driver, which in addition to OGC API - Features, Coverages, Tiles and Maps, also supports execution of modular workflows.

Participants in the project are also currently investigating the integration of ADES, JupyterLab, WCPS, DGGS, and looking at practical applications in the domains of Smart City/3D visualization and Earth Observation.

It would be great for further implementations to be developed and additional experiments conducted under the umbrella of the OGC Innovation Program, e.g. in the upcoming Testbed 17.

[ingosimonis]

thanks a lot for you input, @jerstlouis. I wonder if this topic is best located in a long-term project such as Testbed-17. I have the impression that - given you have already developed a draft spec - it would better into a Sprint, where we could experiment with the draft spec the first day and decide the second day how to move forward. Let's see what @ghobona and @ogcscotts think about it.

[jerstlouis]

@ingosimonis Thanks a lot Ingo. A Sprint might be the way to go. However my concern is that for most implementing this capability might require a lot more than a day. The vast number of different ways / combinations how different components can work together is also something that would justify a long term project, and it may also provide the glue enabling to bring together different threads and/or work packages.

Maybe @pvretano and @bpross-52n could also chime in.

[bpross-52n]

Having worked on this for a while now, I got the feeling that there is enough work / experimenting left to do for a long term project. I also see potential for cross thread / SWG activities. Just my two cents.

[ghobona]

The spec could benefit from both a sprint and a testbed thread. It takes sometime to find a sponsor for a testbed requirement, so perhaps while a sponsor is being sought, the SWG should:

• Propose a work item to be formally approved by the TC.
• Plan on using sprints to advance the spec.

[jerstlouis]

March 2022 Update

• OGC API - Processes - Part 3: Workflows and Chaining is a formal item of the Processes SWG charter
• Work is underway to improve the specifications
• In Joint OGC / OSGeo / ASF Code Sprint this week, Part 3 - Workflows & Chaining was highlighted again by multiple participants as an important Innovation Program activity to undertake in greater depth
• Some experimentation was done with Part 3 - Workflows and Chaining in OGC Testbed 17 - GeoDataCube API (see ER OGC document 21-027r4) work package. This experimentation was limited because it was a not a focus or explicit requirement of the task. Both collection input (Landsat data provided by a separate service as an input to a Machine Learning algorithm process) and collection output (OGC API - Maps request triggering process execution for area & resolution of interest) was implemented (by participants other than ourselves as well).
• It was clearly demonstrated that it can greatly facilitate how visualization clients can easily execute processes and retrieve results.
• The GDAL OGC API driver supporting it is another great example of this capability.

[jerstlouis]

November 2022 Update

• The specification has been significantly improved, now better reflecting the intended separation of conformance classes ( metanorma source, PDF, HTML )
• We still feel a Testbed task with specific client / server components deliverables would help encourage implementation and explore the possibilities enabled by the specification