Federation of collections

[soxofaan]

The aggregator combines multiple back-ends, each of which support different collections, as exposed by their respective GET /collections listings.

The aggregator's /collections currently returns the union of the collections.
Duplicates (same collection id on different back-ends) are currently removed from the union however.

This ticket is for tracking questions and concerns about the strategy of merging collection listings

[jdries]

isn't this at least partially solved by the effort on harmonizing collections and allowing to specify a preferred backend in load_collection?

[soxofaan]

yes that's part of this issue

[soxofaan]

FYI: since f1bfb44 (sept 2021) the aggregator's /collections will also return collections present on multiple back-ends.
The basic merging of metadata is there, but there are still some todo's left, for example from AggregatorCollectionCatalog._merge_collection_metadata:

        # TODO: better merging of title and description?
        # TODO: smarter version maximum?
        # TODO: .. "various" if multiple licenses apply ... links to the license texts SHOULD be added,
        # TODO  cube_dimensions = getter.get("cube:dimensions") ...
        # TODO merge existing summaries?
        # TODO: assets ?

[soxofaan]

I think this is a good first issue for @JeroenVerstraelen to dive in the implementation of openeo-aggregator

[soxofaan]

https://github.com/openEOPlatform/architecture-docs/issues/260 also lists a couple of TODO's for collection metadata merging:

Metadata that is not copied/merged correctley:

• crs object is missing
• assets object is missing
• sci:citation object is missing
• summaries object only has provider:backend (Follow up of https://github.com/openEOPlatform/architecture-docs/issues/259)
• type object is missing

[jdries]

issue was done some time ago, but not closed, closing now!