opengeospatial/ogcapi-environmental-data-retrieval

Changes to API-Common Part: 2 Collections (GeoData)

chris-little opened this issue · 0 comments

Do we want or need to change OGC API-EDR Part 1: Core V1.2 to follow the proposed approach to managing the OpenAPI building blocks used in Tiles, Maps, Coverages, DGGS, Processes and now being adopted for Common - Part 2?
See this issue: opengeospatial/ogcapi-common#302 and this presentation to the Architecture DWG in February 2022: [https://portal.ogc.org/files/?artifact_id=100240](https:// portal.ogc.org/files/?artifact_id=100240)
The individual Web API building blocks are organized as sub-directories of an openapi/ directory:
- openapi/schemas/
- openapi/responses/
- openapi/parameters
- openapi/paths/
And within these directories, are organized by OGC API standard parts e.g.,:
-openapi/schemas/common-core/ (for schemas defined by Common - Part 1)
-openapi/schemas/common-geodata/ (for schemas defined by Common - Part 2)
-openapi/schemas/maps-core/ (for schemas defined by Maps - Part 1)
This facilitates synchronizing these building blocks between different standards, especially between Common and the others.
In the openapi/ directory there is an example OpenAPI definition that includes these building blocks, which produces a valid OpenAPI document. That document can be bundled with the swagger-cli tool (see also its GitHub repository)