Spike: Why and how to combine eoAPI and Stacture/Terravis to fulfil BB requirements

[j08lue]

The Data Access BB needs to provide STAC API + WMTS as well as other OGC API services, namely OGC API Coverages, perhaps OGC API Maps.

To fulfil these requirements, we plan to combine two libraries:

1. eoAPI (DevSeed-maintained) with PgSTAC and TiTiler for WMTS and STAC query based mosaics,
2. Stacture+Terravis (EOX-maintained) for OGC API Coverages.

Fundamental organizational questions - meeting notes from 17th of June 2024

Overview of Stacture / Terravis (Fabian)

1. Stacture provides
2. OpenSearch standard API - for legacy support
3. STAC API
4. OpenEO and GeoDataCube interface? (needed for Data Cube Access BB)
5. Stacture connects to
6. PyCSW
7. STAC FastAPI
8. Stacture adds
9. STAC extension information, where needed -
   1. Virtual assets
   2. Classification
   3. Render parameters
10. Terravis implements workflows (DAGs) for example for virtual assets or applying classifications

Principles of combining eoAPI and stacture/terravis

1. Provide same pattern of integration (config + deployment) for users
2. Each library provides their set of endpoints - we keep things separate but combine at the app or API Gateway level (Tyke, e.g. conformance classes)
3. Use same API syntax
4. Ensure that both sets of services support e.g. the same set of virtual assets - support for those graphs / configs can be implemented in TiTiler, too

Why not implement OGC API Coverages in eoAPI, too?

OGC API Coverages is pretty complex and has not yet been considered for integration into eoAPI, which has a focus on STAC query -> WMTS. Due to the complexity, it is best provided in a dedicated piece of infrastructure.

Next steps: Documentation and Q2 Work Order

Add documentation

1. Why have we chosen this architecture?
2. Strengths and differences of the libraries
3. Benefits of making both libraries available in the building block
4. Pattern of integration

@j08lue to start document / docs branch, @constantinius to contribute

Draft Q2 Work Order

1. Epic: Rough sketch of Data Access BB building and deploying in EOEPCA V&V environment
2. Create task breakdown and estimate sub-tasks
3. Feature development and maturity improvements of libraries

• Q2 Work Order - Data Access - July-September #50

@j08lue to start document for collaboration with @constantinius, @jonas-eberle, and teams

[j08lue]

Rough sketch after the last meeting:

[j08lue]

Integration on the infrastructure level: Nested Helm chart architecture, similar to https://github.com/EOEPCA/helm-charts-dev/blob/develop/charts/rm-user-workspace/Chart.yaml