stac-vrt

stac-vrt copied to clipboard

Right now build_vrt just takes a List[Dict]. The proper type is something like stac-pydantic or pystac's ItemCollection. Should we require / accept either of those instead of or in addition to a list?

I think accepting an item collection is the best choice. I don't think VRT creation would require anything outside of the items themselves, so the additional top-level fields provided by item collections might not be super useful to your use case. But the interoperability of being able to create a VRT from an item collection is quite valuable.

This is especially relevant for API use case where you could potentially use this library to create a VRT from the output of a GET /collections/{collectionId}/items, GET /search, or POST /search query, exposing the VRT as another top-level link on the item collection.

This is something that i'd love to implement as a third party API extension in arturo-stac-api, as a VRT is really just a virtual mosaic of the items returned by that query packaged up in a nice lightweight format that GDAL can understand.

Thanks Jeff!

This is something that i'd love to implement as a third party API extension in arturo-stac-api, as a VRT is really just a virtual mosaic of the items returned by that query packaged up in a nice lightweight format that GDAL can understand.

We (Rob and I) put together something like that. It was end endpoint /vrt that took a full ItemCollection in the request body and returned the vrt. It'd also be nice to somehow tack this onto the /search/ and /collections/{collectionId}/items endpoints to get back a VRT in the first place, which avoids sending ItemCollection from the server to the client, just for the client to send it back to the /vrt endpoint.

I'll check on getting that added into arturo-stac-api.

Thanks for opening up discussion on these things and putting together stac-vrt @TomAugspurger ! I just wanted to link to some discussion I think is relevant here. If I understand correctly the most flexible input would be an ItemCollection JSON string conforming to https://github.com/radiantearth/stac-api-spec/tree/master/fragments/itemcollection ?

I've been trying to use pystac to facilitate extracting info from STAC, which I find to be a nicer way than dealing with a lot of nested dictionary syntax. But it's unclear to me if pystac is the best way to work with search outputs https://github.com/stac-utils/pystac/issues/256#issuecomment-765663796 due to the fact ItemCollections are not a core stac thing but rather a stac api thing.

I guess you could also have a static STAC catalog you want to build a VRT from, but it does seem like most workflows will start with a library like sat-search as you illustrate in your example...

Right, I also think most uses of stac-vrt will come from search results.

Expecting an ItemCollection rather than a plain list would mostly just be for quality of life stuff (in stac-vrt, which isn't a big deal, and maybe for some static type checking).

This is great addition, thanks @TomAugspurger .

I agree with the thoughts here. I see an ItemCollection as the main entity that most downstream applications would consume, as it's the result of a search. One could argue you might want to create a VRT from a single Item, like if you wanted to combine different spectral bands into one file (e.g., create a visual RGB image from the different files), and you could support that if only to immediately create an ItemCollection from the single Item.

I'd like to see ItemCollection implemented in PySTAC for not only this reason, see https://github.com/radiantearth/stac-spec/issues/1046