Collection enhancements

[dchandan]

• Adding ability to add collection level assets
• Adding collection assets to CMIP6_UofT
• Adding an end date to CMIP6_UofT's temporal extent for better rendering in STAC Browser

[fmigneault]

STAC Assets are usually intended for referencing to data or metadata directly relating to the data (eg: some configuration file to interpret it, alternate representations, spec-sheet of the satellite or the convention names of the attributes).

For contextual metadata around the item, such as the CMIP6 project and license, the links section seems more appropriate, using standard IANA relation types known even by non-STAC JSON parsers.

The feature (STAC Assets in Collections) is valid by itself, but the CMIP6 collection config should instead use links with the specific changes provided.

[fmigneault]

Can you show how 2500-01-01 makes it better for rendering?
The current one seems fine to me:

https://redoak.cs.toronto.edu/stac-browser/collections/CMIP6_UofT

If the final date of CMIP6 is unknown, it looks like the "until present" is ideal.

[dchandan]

The "until present" is not ideal because it's not true. The final date for CMIP6 data is known, the maximum a simulation in the archive goes up to is year 2500. When I originally had "null" I was expecting something like STAC browser to show an undetermined/open end date, not something wrong like "until present".

[fmigneault]

If this is a specific date imposed by CMIP6, then it is fine. I'm not familiar with that granular level of details about it.

[fmigneault]

This should be added in links with rel: license instead of assets:
https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md#license

[dchandan]

So, I took this from your example: https://hirondelle.crim.ca/stac/collections/EuroSAT-subset-train. You have license in assets. Is that wrong?

[fmigneault]

Yes. Looks like a misuse.

The license in links is specifically recommended by STAC (note that EuroSAT-subset-train uses both).
It is also commonly used, for example: https://planetarycomputer.microsoft.com/api/stac/v1/collections/landsat-c2-l2

[dchandan]

I've now updated the assets to links.

[fmigneault]

Seems more appropriate to use links with rel: about.
https://www.iana.org/assignments/link-relations/link-relations.xhtml

[dchandan]

Again it seemed from my examination of your implementation that you were using about like links in assets.

[dchandan]

@fmigneault was this a misuse too?

[fmigneault]

Yes. This should also be in links.

[huard]

Temporal extent is good for me.
Don't feel qualified to weigh in on the asset vs link discussion.

[fmigneault]

Recommended change, but not blocking.

[fmigneault]

typo "other" -> "otherwise" ?

I think it would make more sense to delegate all the checks to self.__make_collection_links to avoid spliting the logic in two places.
i.e.:

collection_links = self.__make_collection_links()  # called directly

def __make_collection_links(self):
    links = self._collection_info.pop("links", [])
    for link_name, link_info in self._collection_info["links"].items():
        links.append(pystac.Link(**link_info))
    return links

Same idea for "assets".

[dchandan]

Yeah, that's a good idea. Let me rearrange it that way.

[fmigneault]

Why use a dict instead of a list if the link name is dropped anyway?

[dchandan]

That's a good idea. Done.

[dchandan]

Merging, since it looks like we are good based on your earlier comment.