/ogcapi-records

Public repo for CAT4.0 work

Primary LanguageHTMLOtherNOASSERTION

⚠️ The OGC API - Records specification is still a work in progress. Please be aware that the specification document that is in this repository is not yet in a state that could be useful to anyone who has not been attending the bi-weekly standards working group (SWG) meetings and/or who is not actively working on the document. The SWG is working diligently to update the specification so please refer back to this readme periodically for any status updates. What we think we have consensus on so far are the following:

  1. The API will be similar to the OGC API - Features API with some extended query capabilities.
  2. The recommended encoding of a catalogue record will be GeoJSON to take advantage of the available tooling and make STAC alignment easier.
  3. There will be an endpoint to retrieve the set of queryables (i.e. the properties that may be used to construct a filter).
  4. The content model of a record will be made up of a set of "core" queryables (i.e. a set of mandatory properties that every record must have; stuff like id, type, title, modified, rights, license, etc.) and then any other properties that a domain of practice (e.g. EO, STAC, etc.) might want to add.

There have been discussions on a number of other topics too (see the issues on github) but nothing concrete yet.

OGC API - Records

Overview

OGC API - Records provides discovery and access to metadata about geospatial data and services.

OGC API standards define modular API building blocks to spatially enable Web APIs in a consistent way. OpenAPI is used to define the reusable API building blocks.

GET /collections/myCatalogue/items

Lists all the metadata records in the catalogue.

GET /collections/myCatalogue/items?bbox=160.6,-55.95,-170,-25.89

Lists all the metadata records that describe objects in the New Zealand economic zone.

The response format is determined using standard HTTP content negotiation.

Data is returned in pageable chunks, with each response containing a next link pointing to the next set of response records. The core specification supports a basic set of filters roughly analogous to the OpenSearch and OGC OpenSearch Geo (https://portal.opengeospatial.org/files/?artifact_id=56866) query parameters.

GET /collections/myCatalogue/items/{recordId}

Returns a specific metadata record.

Using the standard

A draft of the OGC API - Records standard is available:

  • T.B.D.

Those who want to just see the endpoints and responses can explore the generic OpenAPI definition on SwaggerHub:

  • T.B.D.

There have been several implementations of the draft standard, though they are still getting up to compliance with the first draft release:

Communication

Join the mailing list or chat at https://gitter.im/opengeospatial/ogcapi-records

Most all work on the specification takes place in GitHub issues, so browse there to get a good idea of what is happening, as well as past decisions.

Additional Information

Also a non-normative document, the "OGC API - Records User's Guide", is planned.

The current expectation is to have a stable version of the Core specification in 2020. We want to wait for sufficient implementation feedback, mature implementations including a test suite, results from OGC testbeds and experience with draft extensions first.

Contributing

The contributor understands that any contributions, if accepted by the OGC Membership and ISO/TC 211, shall be incorporated into OGC and ISO/TC 211 standards documents and that all copyright and intellectual property shall be vested to the OGC.

The OGC API Records Standards Working Group (SWG) is the group at OGC responsible for the stewardship of the standard, but is working to do as much work in public as possible.

Pull Requests from contributors are welcomed. However, please note that by sending a Pull Request or Commit to this GitHub repository, you are agreeing to the terms in the Observer Agreement https://portal.ogc.org/files/?artifact_id=92169

Nightly Build

The latest drafts of each standard in this repository are built daily (based on the configuration contained in the asciidoctor.json file):