Support STAC spec version 1.1.0

[jsignell]

At some point in the near future version 1.1.0 of the STAC spec will be released. PRs are still being merged in, but the current list of high-profile changes is at: https://github.com/radiantearth/stac-spec/blob/v1.1.0-release/CHANGELOG.md

These are the changes that I think will need to be made in pystac (in the order they appear in the stac-spec changelog):

• Update STAC_VERSION to v1.1.0 #1427
• make bands core instead of being within the eo and raster extensions (WIP PR Add bands #1238)
• Move keywords up out of collections into common metadata #1376
• Fix docstring for license to indicate that it supports other as an option and no longer supports proprietary and various. #1377
• Move roles up out of Assets and Providers and into common metadata #1378
• Add collection as a relation type #1379
• Deprecate item_assets extension and move into collection core #1380
• Add file:// protocol to self links that currently don't have a protocol #1347
• In common metadata: validate that if a description is provided it is not empty #1381
• Ensure that APIs have trailing slashes and files do not (not sure this one requires any action)
• Treat start_datetime and end_datetime as inclusive bounds #1382
• item.geometry cannot be a GeometryCollection (not sure this one requires any action)
• Update pystac migrate for STAC spec 1.1.0 #1383

[jsignell]

Note: I ended up making a milestone for this and making all the items into individual tickets.

[gadomski]

@jsignell I'm starting work on v1.1.0 support, and I think I'd like to get rid of the milestone and only use this ticket to track v1.1.0 issues. My reasoning is that some of these issues can be solved without breaking pystac (e.g. #1379) and others are breaking (e.g. changing the docstring for #1377 will inherently "move" pystac to v1.1.0). We'll also eventually need to update DEFAULT_STAC_VERSION which will be breaking as well.

Tl;dr: I'm proposing closing the STAC spec version 1.0.0 milestone in favor of this tracking issue, and instead opening a v1.11 milestone to go along with the existing v2.0 milestone.

[jsignell]

I'm proposing closing the STAC spec version 1.0.0 milestone in favor of this tracking issue, and instead opening a v1.11 milestone to go along with the existing v2.0 milestone.

That plan sounds good to me! I felt a little wierd making a milestone that wasn't necessarily tied to a release.

[gadomski]

Ok, I've got things sorted into three milestones (I added one):

• I'd like to cut v1.11 soon-ish to get it out before we start in earnest on STAC v1.1 work
• v1.12 is the (hopefully) non-breaking STAC v1.1 changes
• v2.0 gets us home

[hrodmn]

Hi! I am working on a stactools package and am considering using pystac>=1.12 but I want to be able to write items/collections that are compliant with STAC v1.0.0. I found the set_stac_version function but that doesn't seem to do much besides set the stac_version property in the items/collections that I create. Is it incumbent upon me to add the newly absorbed extensions (e.g. item-assets, raster) manually if I want to create items/collections that are compliant with v1.0.0?

[gadomski]

Is it incumbent upon me to add the newly absorbed extensions (e.g. item-assets, raster) manually if I want to create items/collections that are compliant with v1.0.0?

All the same functionality that was available pre-v1.12 is still there, meaning you can still write eo:bands, raster:bands, etc using the extension interface. There's nothing "non-compliant" about writing item_assets or bands directly on a v1.0.0 item (STAC allows for arbitrary additional fields), it's more a question of whether tooling will understand it.