Feedback on STAC implementation (raster + vector data)

[nirzaree-cfpt]

Hi folks,
We recently implemented STAC specs on our datasets CoRE Stack, which have both raster and vector data.

Wanted feedback from folks on our implementation, and if we could do better for any of the aspects.

While we understand that STAC specs aren't meant for vector data types, we wanted a single place for all of the data to be discovered which is why we have currently implemented the specification for all of our data, which includes vector data.

We have some country scale data (raster, vector both), and some at administrative sub-district level data (or tehsil/taluka as it is called locally). We have therefore built 2 separate catalogs (one for country level data, and one for subdistrict level). However raster and vector items are both present within the catalogs.

Thanks in advance. Looking forward to learning from the community.

[gadomski]

Thanks for sharing! Another good place to share would be the STAC Index, which had links to lots of other catalogs and APIs, as well as software tools and other related projects.

I don't have time to do a detailed review, but I paged through things and have a couple of comments/suggestions that you can take or leave.

• The top-level delineation into country-scale and Teshil-scale makes sense to me 👍🏼
• In the country-scale catalog, the items don't appear to have country scale-geometries, e.g. https://stac.core-stack.org/PanIndiaCatalogs/hydrological_boundaries/microwatershed_boundaries_v1_vector/microwatershed_boundaries_v1_vector.json. I wonder if those item geometries were created from the first feature in the underlying source data?
• STAC is extremely flexible, so the choices you made for layout are totally valid. Another layout strategy would have been to create catalogs for each type of data (e.g. "Catchments", "Drought frequency" etc) and have one item per each area (Teshil, district). This would allow folks first find what type of data they want, then filter items that intersect their area of interest (e.g. if their study area crosses multiple administrative areas).

[jsignell]

It's more common to use the layout pattern that @gadomski is describing of having each collection represent one type of data and then have the items within that collection cover different areas. Having that layout makes it easier to make use of collection-level item-assets and summaries since the items within the collection are more homogeneous.

[nirzaree-cfpt]

@gadomski : Thanks a lot Pete for your response. :)
Yes indeed in the country scale data, the geometry is coming from the first item in the collection. We need to figure out how to make the country scale boundary visible properly.

Yes we do plan to segregate data by type, however in some cases we would still end up with both types of data (raster and vector) for the same layer type. Wondering if that would be ok, especially from STAC API standpoint.

Also one of the unique aspects of the datasets we have implemented STAC on, is that we are making various kinds of data available for an area (a subdistrict in this case),so I am also wondering if we segregated the data by type, then how could folks access the various different types of data available for the region of interest (once we enable the STAC API).

Thanks a lot!

[gadomski]

Yes we do plan to segregate data by type, however in some cases we would still end up with both types of data (raster and vector) for the same layer type. Wondering if that would be ok, especially from STAC API standpoint.

Raster and vector assets should be distinguishable by their media type, so if they have the same spatial and temporal extents, it's appropriate to put them on the same STAC item.

so I am also wondering if we segregated the data by type, then how could folks access the various different types of data available for the region of interest (once we enable the STAC API).

This could be handled by a custom property, which users could then use for search via the filter extension. Options include:

• Teshil, district, and subdistrict codes
• Resolution information (for raster data)

As a made-up example, let's say you included the following two attributes on your STAC items: core:district and core:subdistrict. You could then do a STAC search like this (provided you have a STAC API):

items = search("https://stac-api.core-stack.org", filter="\"core:district\"='foo'", collections=["bar"])

If you wanted only district-level items, but not subdistrict items, the filter would be (("core:district" = 'foo') AND ("core:subdistrict" IS NULL)).

[Nirzaree]

Thanks a lot @gadomski.

Raster and vector assets should be distinguishable by their media type, so if they have the same spatial and temporal extents, it's appropriate to put them on the same STAC item.

We were thinking to have them in the same catalog but not in the same item, as in my understanding and item can contain only a single data (along with its accompanying files). But interesting that you suggest to put the data under the same item. I will look more into this.

This could be handled by a custom property, which users could then use for search via the filter extension. Options include:

Teshil, district, and subdistrict codes
Resolution information (for raster data)
As a made-up example, let's say you included the following two attributes on your STAC items: core:district and core:subdistrict. You could then do a STAC search like this (provided you have a STAC API):

This sounds good. Will try it out. Thanks.