Skip to content

CollectionMetadata -> CubeMetadata? #464

Closed

Description

@soxofaan

# TODO: "CollectionMetadata" is also used as "cube metadata" where the link to original collection
# might be lost (if any). Better separation between rich EO raster collection metadata and
# essential cube metadata? E.g.: also thing of vector cubes.

"CollectionMetadata" got its name when data cubes where still called "ImageCollection" (instead of "DataCube"). But now that is getting a bit confusing: in openEO, "collections" is the source data one loads with load_collection, while "cubes" are the intermediate data structure one works with. So "CollectionMetadata" should better be called "CubeMetadata".

Also, CollectionMetadata contains some specific dimension metadata parsing logic (cube:dimensions/eo:bands), which is closely tied to the STAC description of collections. I think it would be better to separate this from the essential cube metadata logic.

Activity

  1. soxofaan commented on Aug 24, 2023

    @soxofaan
    MemberAuthor

    I think we should change it to:

    • CubeMetadata: just the bare metadata essentials for a data cube: interface to interact with the cube dimensions and their labels (if available), maybe some resolution info too. Methods allow to construct a new CubeMetadata instance from an existing one (e.g. reduce_dimension eliminates a dimension)
    • CollectionMetadata (subclass of CubeMetadata): interface to interact with all original collection (STAC) metadata. Calling a "process" like reduce_dimension produces a CubeMetadata

    By making CollectionMetadata a subclass of CubeMetadata we can stay backward compatible I think, because the interface of CollectionMetadata would not really change

  2. jdries commented on Aug 24, 2023

    @jdries
    Collaborator

    ok, makes sense!

  3. soxofaan commented on Oct 27, 2023

    @soxofaan
    MemberAuthor

    Another reason for better abstraction: load_stac should produce a data cube with metadata (#425) , but that is not the same as collection metadata.

  4. added a commit that references this issue on Feb 23, 2024
  5. linked a pull request that will close this issueIssue464 cube metadata #541on Feb 23, 2024
  6. VictorVerhaert commented on Feb 23, 2024

    @VictorVerhaert
    Contributor

    def _clone_and_update(
    self, metadata: dict = None, dimensions: List[Dimension] = None, **kwargs
    ) -> CubeMetadata: # python >= 3.11: -> Self to be more correct for subclasses
    """Create a new instance (of same class) with copied/updated fields."""
    # TODO: do we want to keep the type the same or force it to be CubeMetadata?
    # this method is e.g. used by reduce_dimension, which should return a CubeMetadata
    # If adjusted, name should be changed to e.g. _create_updated
    # Alternative is to use an optional argument to specify the class to use
    cls = type(self)
    if dimensions == None:
    dimensions = self._dimensions
    return cls(metadata=metadata or self._orig_metadata, dimensions=dimensions, **kwargs)

    Currently functionality does not change due to this function.
    As this function checks the type and returns an object of the same class, functions like reduce_dimension (who use this function to update a metadata object) will still return a CollectionMetadata object if that was the original object.

    Changing this to return a CubeMetadata changes functionality and fails some existing tests.

    An alternative is to provide an optional argument to set the expected returned class, however this feels more like a quick fix and might be confusing in the future.

  7. added 2 commits that reference this issue on Feb 28, 2024
  8. added a commit that references this issue on Feb 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions