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

Should Catalog also have an extent? #1210

Closed
philvarner opened this issue Jan 17, 2023 · 6 comments
Closed

Should Catalog also have an extent? #1210

philvarner opened this issue Jan 17, 2023 · 6 comments

Comments

@philvarner
Copy link
Collaborator

This question derives from:

It seems to me that having a Catalog extent would be useful, so I'm bringing it up as a discussion question here.

@jjrom
Copy link
Contributor

jjrom commented Jan 17, 2023

Having an OPTIONAL extent in a Catalog could be useful. However setting the extent to REQUIRED would break implementations that deliver dynamic catalogs.

For instance in resto every search request is converted to a dynamic catalog endpoint, e.g. search on "France". Since 1) any search parameters combination can be exposed as a catalog and 2) the STAC endpoint is continuously updated with new items, the only way to provide the Catalog extent is to compute it "on the fly" which would dramatically downgrade the response time of the API to a point that would make it unusable imho.

@emmanuelmathot
Copy link
Collaborator

The boundary between catalog and collection is getting thinner and probably confusing. I do not see the point of having 2 entities with the same functions.
IMHO, We should keep the spec catalog as simple as possible and strictly be a global (e.g. root) or subset (e.g. userspace, dynamic endpoint as in resto) container with multiple children catalogs or collections and API capabilities and conformance.
The spec collections should be enriched with sub-collections capabilities (e.g. sentinel-2 -> sentinel-2-l1c).
It would allow a practical answer to radiantearth/stac-api-spec#366 where there may be a all_items collection that is the set of all items in the catalog.

@philvarner
Copy link
Collaborator Author

Having an OPTIONAL extent in a Catalog could be useful. However setting the extent to REQUIRED would break implementations that deliver dynamic catalogs.

Yes, it would definitely be optional.

@m-mohr
Copy link
Collaborator

m-mohr commented Feb 6, 2023

I don't see the benefit of adding it and agree with @emmanuelmathot. Catalog is meant to be very slim and if you want more make it a Collection. In principle you could just add the extent though and it just behaves as a non-standardized extension, some tooling might be able to read it nevertheless.

The usecase in radiantearth/stac-api-spec#366 got broken by introducing the type field, I guess? Previously I also sometimes used collections as landing page, but I assume the API now requires the Catalog type? Maybe we can allow Catalog or Collection as Landing page type?

@philvarner
Copy link
Collaborator Author

Yes, the Landing Page is a Catalog. I don't like the idea of allowing either, but I'll need to think about the specific reasons more.

@m-mohr m-mohr added this to the 1.1 milestone Jul 11, 2023
@m-mohr
Copy link
Collaborator

m-mohr commented Sep 26, 2023

No, as discussed on the STAC sprint. This may be a change in the API to allow Collections as the landing page.

@m-mohr m-mohr closed this as not planned Won't fix, can't repro, duplicate, stale Sep 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants