@ycespb + @jjrom - I think you have it mostly right. A collection is a catalog, with additional metadata. And features belong to a catalog, that describes its metadata. Catalogs mostly just let you group as you'd like, in a lighterweight way.
The place where they are very useful is in the 'browse' and 'crawl' contexts. People coming to your stac catalog and just clicking down to relevant interests. Or search engines spidering the whole catalog.
It's much harder to navigate down when you hit an 'items' endpoint, that just lets you search or page through.
But they're designed to be a flexible concept that can be used for a variety of groupings. They c an group at the top, before you go into collections. Or within a collection they can help you browse down.
Right now the intersection between catalogs and OAFeat is confusing for sure though. I'm working on a proposal for a 'browse' endpoint that would try to provide clarity. Or it could be a better best practices document.
@cholmes - is it forbidden to have href with query parameters inside links with rel="child" (in a Catalog object) ? Is it planned to update the UML model to show where the rel="items" fits and whether both rel="item" and rel="items" both have different meanings ? In OAFeat only rel="items" exists. In the UML model only rel="item" appears.
No, not forbidden to have href with query parameters inside the rel=child. Indeed I like the approach I think you're getting at - the items/ location has the canonical STAC Item, and the browse catalogs define their leaf nodes by just linking.
The alternate approach I like is that the browse hierarchy is your canonical, and then in your items responses each one has a rel="canonical" pointing at the browse hierarchy.
That is a good idea on updating the UML model. Will try to do it when I get to creating a proposal / best practices.
Though actually, the UML model is really just the core STAC content model. items/ is actually an API thing.
(we decided yesterday for going to STAC 1.0 we are going to break out stac api into a separate repo and have different versioning, and likely a bit slower to 1.0)
But yes, it all needs more clarity, and making sure the UML reflects it is a good point.
@cholmes and this "browse hierarchy" seems typically not to appear or is not expected to appear in the OpenAPI description as you do get very many different paths to items below /stac (I was looking at the landsat catalog example with the path/row hierarchy...)?
@cholmes It would be very useful to determine at the /stac endpoint if a "rel=child" is a "regular" catalog or a "collection" catalog without having to resolve the link. Would you think an additional property in the link (like "subtype=collection" or whatever) be appropriate ?
@ycespb - yeah, stac api implementors haven't taken the idea much, which is why I need to try to make it clearer. I think defining the core separately may help some.
@jjrom that does seem useful. I can envision situations where it might be hard for someone to construct that ahead of time, so maybe start it as an optional thing. But seems sensible to make at least put in the spec a way to do that for implementors who want to.
@jjrom - you want to make a PR on the spec? Can discuss it there. It's probably just a line or two in the catalog spec (or maybe the collection spec?)
@jjrom, why not using the existing "type" attribute with the JSON media type and appending "profile="..." with the profile URI something identifying a STAC Catalog object or SAT collection object ?
@ycespb Yes that's a good idea !
@cholmes@ycespb I'm not familiar with mime-type profile - what do you suggest for the catalog/collection URI ?
@aaime how are you going to advertise the queryables?
@rouault checked, other versions of the WFS protocol would behave the same I think... the issue is that we first test if the two envelopes intersect, and they do, and then do a full intersection test with JTS, polygon vs polygon, apparently the empty polygon coming out of the empty envelope is not topologically intersecting, according to JTS
I guess I can try to expand the bbox a tiny bit, minimum delta that would make one of the ordinates different than the other in the floating point encoding
seems a bit of a gray area... @rouault are you doing the bbox like that to do a sort of "featureinfo"?
@ycespb Hum...not sure from the example it looks quite cryptic. I would really have a simple stuff like what we have for COG i.e. "profile:cloud-optimized" in the mimeType. Would "profile:stac-collection" not valid ? It will not be an official mime-type but at least it's meaningful within the stac spec
@aaime Yes, I generally like to try the "what is at my place" kind of test query. This is far from being critical. I remember having that kind of issue with ElasticSearch or MongoDB and changed the client to do a small rectangle