Closed chris-little closed 1 year ago
Some more information: OGC has a policy for re-usable "building blocks" at various levels of granularity to improve interoperability, registered in the OGC register of building blocks.
The building blocks are organised in these folders: • geo: geospatial building blocks • ogc-utils: Utility building blocks that are used in OGC API's but are not inherently geospatial. They were created to ensure consistency within OGC API's where there was not a clear mainstream standard, and in line with best practices of the web and could be replaced, e.g. by building blocks specified in an IETF RFC or similar, if and when available. API's built with the geo building blocks do not need to use these, but they provide a nice default option that OGC-focused tools will understand. • unstable: These building blocks are not yet stable or mature. They may be extracted from core OGC API standards that have not yet been fully approved, or they may also be new ideas that are not yet in a standard.
Each building block is an AsciiDoc document, whose name follows the convention: PREFIX-NAME.adoc. The prefix is parameter
, in the case of parameters, header
in the case of headers, and encoding
(e.g.: JSON) in the case of data types or resources. This is an example of a building block
In addition, please register the building block in the register.json
This provides information about the item, using an extension of the ISO19135 schema.
All contributions welcomed, as pull requests to this repository
@m-burgoyne suggested that we could register generic data queries, as at https://labs.metoffice.gov.uk/edr/collections/global_pop_density as a valid building block too. See the spec at https://opengeospatial.github.io/ogcna-auto-review/19-086r6.html#col-data_queries
I have created a Pull Request in the Building Blocks repo, so at least the proposed EDR blocks are named. OGC staff suggested what a full description of a building block should look like:
here's a straw man:
OGC Staff have refactored the Building Blocks Register and there are entries from API-EDR and CoverageJSON following the above structure, as well as API-Features. I need to add the missing CoverageJSON Domain objects. Please explore the API-EDR entries and improve! Can we close this issue now?
Agreed at EDR API SWG 92, 2023-01-26
OGC has requested that "building blocks" be registered, initially manually, into the new OGC registry infrastructure. I propose that the initial API EDR blocks be:
parameter-name
of the queried collection quantity and its definition, attributes, etc.Other blocks or patterns could be BBOX (2/3/n-D), CRS in WKT, CRS in JSON, etc, perhaps from other APIs that are consistent with our definitions.
Thoughts?