Define the Open Data Cube Ecosystem

[caitlinadams]

The Open Data Cube project now has many components that can be valuable on their own, or in conjunction with an ODC deployment.

To complete this card, we should

• Identify and list all of our components (e.g. core, stats, stac, geo)
• Write a plain language description for all of our components
• Write simple user stories to help people decide which components are relevant to them
• Develop an easily-interpretable diagram showing the relations between components
• Update our documentation to include these new elements

[caitlinadams]

From Rob

1. odc-stac and odc-geo already has a low barrier of entry. Perhaps this is an ideal first case to tackle and improve.
2. datacube-core is involved if you want to deal with your own data. This requires data prep and indexing (much more complex interaction of other repos)
3. services like ows and explorer
4. template for jupyterlab on

There are some others, statistician, alchemist, etc. for bulk processing.

Two levels of deployment: desktop and cloud/kubernetes. We have hinted at how to do full deployment, but not described it fully. How would we want to tackle it further -- template, high-level documentation. Deployment is kept up to date by GA and CSIRO -- serves as an example. Issues with security and authorisation that have to be tackled on an individual level.

[Kirill888]

I have shared these before, but worthwhile listing them here I think:

• https://odc-stac-demo.netlify.app/
• https://odc-geo.readthedocs.io/en/latest/migration.html

It's worth mentioning that odc-geo is independent of odc-stac or datacube, even if you are using rioxarray or stackstac to create your xarray datasets you can still access .odc.geobox and other features that having geobox enables (saving to COG, plotting on a map, reproject).