Architectural Overview

The modern paradigm that the Open Data Cube (ODC) operates under is the Cloud Native Geospatial concept, where data is available over vast areas and via HTTP, generally from Cloud Optimised GeoTIFFs (COGs). COGs, coupled with SpatioTemporal Asset Catalog metadata is being used by Digital Earth Australia, Digital Earth Africa, Element 84’s Sentinel-2 COGs, USGS’s Landsat Collection 2, Planet and a wide range of other organisations.

The ODC can index from STAC, although this process is not fully integrated, it is done in production. An example of this is captured in these Sentinel-2 Indexing notes. And in addition to indexing from STAC, Datacube Explorer can present ODC metadata as STAC documents, through a STAC API.

The key design constraint that the ODC currently has is it’s reliance on a direct PostgreSQL connection, so one should consider how others in their team will access the database that they are indexing into.

In general, any data format that can be read by RasterIO (GDAL, fundamentally), can be indexed into the ODC, so long as it can be described by ODC metadata.

This section of the documentation describes the structure of the ODC and the key components that make up an implementation, as well as the ecosystem around it.

Fig. 2 Datacube-core vs odc-stac

Metadata Conceptual Diagram

This is a conceptual diagram of the contents of an ODC database. The database schema that implements these concepts in a particular database will vary depending on the choice of index driver.

Fig. 3 Conceptual model of ODC metadata.