The OGC API - Records Standard specifies several deployment patterns for accessing and maintaining geospatial asset catalogs.

The Records API Crawlable Catalog pattern involves creating static metadata files along with the data, in a web accessible location such as an Amazon S3 bucket. At the top-level, there should be a file to provide information about the catalog, including links to navigate through the metadata records.

Although providing only visibility and navigation, a crawlable catalog can be implemented relatively quickly and can provide quick return on investment for use cases such as organizing directories full of files such as a repository of Earth Observation (EO) images.

An implementation of the Records API Searchable Catalog pattern supports accessing collection level metadata and the individual metadata records. However, unlike the crawlable catalog, this pattern enables clients to filter the response with query parameters. This searching capability requires the metadata to be stored in a SQL or NoSQL database that can provide the querying functionality. As such, a simple setup using files on a web accessible folder is no longer possible.

Bellow are some real-life examples of querying patterns that can be used in a searchable catalog.

The /collections endpoint is also defined in other OGC API Standards, such as OGC API - Features and OGC API - Coverages.

The Local Resources catalog pattern extends other OGC APIs endpoints to behave like catalogs, enabling querying functionality. For instance, this query filters a feature collection by bounding box:

curl -X 'GET' \
'https://emotional.byteroad.net/collections/hex350_grid_obesity_1920/items?bbox=-0.078921,51.473444,-0.063901,51.478062' \
-H 'accept: application/geo+json'

Other OGC API endpoints that can be repurposed as catalogs include processes and coverage scenes.

You can read more about the OGC API - Records Standard on the editor's draft and follow/participate (in) its development on the Standard's GitHub repository .