Skip to content
This repository has been archived by the owner on May 10, 2021. It is now read-only.

Latest commit

 

History

History
28 lines (22 loc) · 2.96 KB

lessonsAndNextSteps.adoc

File metadata and controls

28 lines (22 loc) · 2.96 KB

Immediate Lessons and Next Steps

Immediate Lessons

  • There is need to improve discovery of resources (e.g. landing pages) across multiple deployments. The binding aspects also need to be considered, for example potentially using actionable links. We need some form of harmonization on link relation types.

  • When the SWGs are defining the APIs they should define the default behavior. OWS needed several parameters to retrieve a resource, however for OGC APIs they should be designed to allow default behavior when params are not present.

  • The participants therefore recommended that implementers of code generating tools should make enhancements to address some of those shortcomings, for example support for dynamic resources and enabling semantic awareness to provide context to API components. There is also a fundamental limit in the specifications. This could potentially be addressed through support for templatedRef OAI/OpenAPI-Specification#2453

  • There is a need to enable paging of collections. For example, it is possible that some implementations of OGC API - Processes could have hundreds of processes. This needs to be addressed in the OGC API - Common - Part 2: Geospatial Data extension. This is also related to Principle 11 of the Guidelines https://github.com/opengeospatial/OGC-Web-API-Guidelines

  • There may also need to be a mechanism to group collections (i.e. a collection of collections). opengeospatial/ogcapi-common#11

Next Steps for the innovation side

  • We need more experimentation on styles and coverages. Including how styles can be used to render/filter coverages.

  • We need more experimentation on tiled coverages (i.e. OGC API - Coverages and OGC API - Tiles integration).

  • More experimentation is needed on workflows in relation to the OGC API - Processes - Part 3 : Workflows.

  • Further development of the DGGS API, including work on client applications and visualization

  • There is a need to advance OGC APIs and other OGC standards to enable the cataloguing and discovery of models (e.g. AI/Machine Learning models). We need to explore how to sufficiently describe the models.

  • The implications of OpenAPI 3.1, JSON Schema and Webhooks need to be examined and path towards transition identified.

  • Themes, trees, nesting, and other strategies need to be explored. This is needed because data providers often have thousands of datasets that they need to manage or publish.

  • Some integration of the MapML format concept with the OGC API offerings, for example into the HTML representation of features, to enhance the spatial indexing of HTML

Next Steps for the standards side

  • Associations in catalogues need to considered.

  • Enhancement of the Link Relations Register.

  • Landing page of landing pages could be standardised

  • Searchable collections in OGC APIs (including the collections of collections)

  • Where appropriate, clarification that GeoJSON is the default JSON encoding for OGC API - Features and OGC API - Records