Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional endpoints to get more details about the data cube? #346

Open
m-mohr opened this issue Nov 23, 2020 · 2 comments
Open

Additional endpoints to get more details about the data cube? #346

m-mohr opened this issue Nov 23, 2020 · 2 comments
Labels
data discovery minor requires a minor-version (x.1.0 for example)
Milestone

Comments

@m-mohr
Copy link
Member

m-mohr commented Nov 23, 2020

Inspired from D34:

Meaningful metadata and collection naming: The users mentioned that meaningful metadata is crucial to effectively use openEO. > Especially the availability of data within the extents of a (irregular) time series has been pointed out as important information.

Would it make sense to get details on data cubes easily using a separate endpoints (e.g. GET /collections/:id/datacube), e.g. specifying values/extents for all/a subset of the dimensions and then get a full list of available dimension labels etc. Especially important for temporal I think, as the general metadata usually just lists the temporal extents, not distinct timestamps.

A different approach would be to use load_collection and debug...

Another comment from D34:

Several concerns are raised about data collections and backends. An interactive exploration of data collections and their availability across all back-ends is missing, which is a barrier for users.

@m-mohr m-mohr added data discovery minor requires a minor-version (x.1.0 for example) labels Nov 23, 2020
@m-mohr m-mohr added this to the future milestone Nov 23, 2020
@soxofaan
Copy link
Member

soxofaan commented Dec 1, 2020

another approach that would not need new API endpoint:

load_collection without temporal/spatial extent
dimension_labels(dimension="t")    result=True

pro:

  • does not need new API endpoint, just use standard processes
  • could also work on processed collections (e.g aggregate_temporal)

contra:

  • it doesn't look like collection metadata query
  • backend needs to be smart enough to just use metadata and avoid loading all the actual collection data

(related to Open-EO/openeo-processes#195)

@m-mohr
Copy link
Member Author

m-mohr commented Dec 1, 2020

That is basically the equivalent to "A different approach would be to use load_collection and debug...", but use dimension_labels instead of debug.

Additional contra:

  • I would expect that data discovery doesn't incur any costs, but sending it as a job would somehow imply that
  • You can't do it without credentials, which is making discovery harder than it needs to be

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
data discovery minor requires a minor-version (x.1.0 for example)
Projects
None yet
Development

No branches or pull requests

2 participants