STAC + COG and dynamic tiling

[vincentsarago]

Min/Max zoom (high priority)

I'm trying to support as much as possible STAC in other dynamic tiling projects and IMO having the min/max zoom for asset would be really useful (right now I have to read the metadata or to get the max zoom from the gsd is present).

Datatype (low priority)

Having access to the datatype of the asset would also be useful, so we know if we need to apply any kind of rescaling

One band per asset (medium priority)

STAC is useful to host metadata for dataset that are stored as a one band per file (e.g landsat/sentinel) but from my knowledge, I think there is not a field in the specs that make it clear enough.

I'm sorry if this has already been discussed somewhere, or if those already exists :D

I'm happy to start a PR but I wasn't sure if this would be a new extension or some addition in other extensions.

[m-mohr]

1. Could https://github.com/radiantearth/stac-spec/tree/dev/extensions/tiled-assets help or be extended?
2. Probably a (new?) extension as the datatype doesn't seem search related. I'm also interested in this field. What exactly do you mean by data type though?
3. I don't understand this enough. Isn't that what eo:bands in the assets makes clear?

[vincentsarago]

Hi @m-mohr thanks for your answer.

1. Could https://github.com/radiantearth/stac-spec/tree/dev/extensions/tiled-assets help or be extended?

Why not, to be honest it will make some senses because Zooms are tied to a TMS

2. Probably a (new?) extension as the datatype doesn't seem search related. I'm also interested in this field. What exactly do you mean by data type though?

datatype to me is https://numpy.org/doc/stable/user/basics.types.html. Basically I'd love to know if each asset is in byte, float32.... the problem is then what convention to follow (C Type ?)

3. I don't understand this enough. Isn't that what eo:bands in the assets makes clear?

Sorry for not being clear, the problem I have is when I need to create tiles from an Item, it's not straight forward if I can merge assets together (if each assets are separate bands) or if each assets should be treated as separate.

In fact I got this. Because the specs are loose, you can have both band+product in the asset list. So as you mentioned, maybe really on item eo:bands is the best way.

[geospatial-jeff]

Let me start off by saying I'm a huge fan of STAC + COG. I think there is a lot to gain by creating interoperability between the two.

I'm a big proponent for having a simple cog extension which defines the fields mentioned by @vincentsarago (minzoom/maxzoom/datatype) so the client (or dynamic tiler in this case) can avoid reading the asset to get this metadata. I think this is similar to some aspects of the proj extension where it provides fields that aren't necessarily searchable but expose optimizations for clients which perform some sort of operation on the item (in this case dynamically rendering tiles). I think this could be as simple as defining a couple asset-level fields which may be attached to assets with a cog media type.

I also think that the tiled-assets extension would complement a cog extension nicely, as it lets the server describe the internal structure of the COG. That being said, I don't think the tiled-assets extension is sufficient on its own for COG-related use cases which is one of the big reasons I'd like to see a cog extension.

[cholmes]

Yeah, I agree it should be separate from tiled-assets, though they are clearly closely related. I'm +1 on it.

I'd say go ahead and move this to be a PR. I'm not totally sure that COG is the right name for the extension and which fields are the right scope - like are min/max useful for things other than cogs? But I think it may be easiest to have this discussion in a PR so we're not talking too abstract.

[m-mohr]

Yes, this all makes much sense. Thanks for clarifying. We probably need a more general name though as I'm seeing usecases other than cogs, too.

[cholmes]

@vincentsarago - I can take a crack at making a PR for this if you can write a quick summary of what to include:

• Min/max zoom - how do we specify this? Web mercator zoom levels? Tips to help people calculate this or recommendations on what to use?

• Datatype - happy to add this as an optional field, could you explain more of what options you'd see here?

• One band per asset - this would just be a true/false, to give a hint that the assets split up the bands, right?

[vincentsarago]

Min/max zoom - how do we specify this? Web mercator zoom levels? Tips to help people calculate this or recommendations on what to use?

I think Web Mercator is fine (and widely used/accepted). we have a helper function in rio-tiler to get those https://github.com/cogeotiff/rio-tiler/blob/master/rio_tiler/mercator.py#L64 (if we want to support other TMS we also have https://github.com/cogeotiff/rio-tiler-crs/blob/master/rio_tiler_crs/cogeo.py#L95-L126)

Datatype - happy to add this as an optional field, could you explain more of what options you'd see here?

IMO, datatype should reflect the data type ( as in Float, Int, Complex). This let the dynamic tiler/client know if we need to apply rescaling up front.

One band per asset - this would just be a true/false, to give a hint that the assets split up the bands, right?

Yes. That's in a ideal world but sadly I realized that STAC Items can have both (band per asset and other product). e.g the latest sentinel-2-cogs STAC has bands/asset and also some other product that are not to be merged with the other assets. I thins the eo: extension might be enough here and there might be no need to add a new property

[davidraleigh]

@vincentsarago your understanding of all this is far more advanced than mine. one of the things I noticed in your original notes was a quadkey field. Is that something you'd still be interested in? Sorry if this question no longer applies.

[cholmes]

One band per asset - this would just be a true/false, to give a hint that the assets split up the bands, right?

Yes. That's in a ideal world but sadly I realized that STAC Items can have both (band per asset and other product). e.g the latest sentinel-2-cogs STAC has bands/asset and also some other product that are not to be merged with the other assets. I thins the eo: extension might be enough here and there might be no need to add a new property

Ok. Would be good to verify that there's a way to do this with the EO extension. We can add things at the asset level now, so could have a field that just says if a given asset is multi-band or single band.

Hrm, actually that could perhaps be the solution, using the new Additional fields for assets. We could specify some sort of 'one band per asset' field, and it could be applied at the item level (if every asset is its own band) or used at the asset level. Will have to get the semantics right, but something like that could work.

[geospatial-jeff]

Would be good to verify that there's a way to do this with the EO extension

Since 1.0.0-beta.1 the asset level eo:bands member may contain the entire array. I can't find any implementation examples but in theory the number of bands per asset can be determined by the length of the eo:bands array.

[wallaceatearthling]

+1 for this. We have run into a use case with state-wide aerial imagery where it would be nice to have min max zoom to the tile renderer can decide whether it is worth pulling the asset and returning a tile.

[m-mohr]

Just discussed in the working session, we'd like these in more fine-granular issues if still of interest.

• Min/max zoom: This needs a new extension, but should be a separate issue. Maybe we can also just revive https://github.com/radiantearth/stac-spec/pull/879 but it needs someone to take over the lead.
• data_type: This will eventually become part of common metadata (migrating it over from the raster extension, will be part of #1213
• one band per asset: We're not sure, but isn't that an implementation thing how the files get constructed? Can't you read the bands array? Anyway, should likely be a separate issue as well.

Thanks.