Should Catalog also have an extent?

[philvarner]

This question derives from:

• https://github.com/radiantearth/stac-api-spec/issues/366

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

[jjrom]

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]

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 https://github.com/radiantearth/stac-api-spec/issues/366 where there may be a all_items collection that is the set of all items in the catalog.

[philvarner]

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]

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 https://github.com/radiantearth/stac-api-spec/issues/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]

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]

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