Support virtual assets

[abarciauskas-bgse]

We (@emmanuelmathot @vincentsarago @smohiudd) have been discussing support for tiling parameters in STAC.

I think we are reaching consensus that we will store these parameters within a virtual asset. Note a virtual asset is still an asset but it typically does not exist and is passed to some service to be generated. The parameters for titiler would be stored in a virtual asset under either the compose prefix or the processing prefix. See this documentation for titiler in the composite extension.

My understanding is that there is interest to support processing of virtual assets in titiler so that, when a virtual asset exists, and is passed to the API as part of the assets=[] parameter, titiler would then look up the asset(s) and apply any parameters titiler expects (compose:*, processing:expression, raster:bands:nodata, unscale)

Questions:

1. Do we agree with the metadata approach or see any issues with it? I will add one or more example assets with all parameters.
2. Do we agree virtual assets should be supported by titiler
3. If (2) is yes, what should be the approach - a new path or query parameter? Presumably if parameters are passed in the URL they would override the virtual asset.

[abarciauskas-bgse]

One question I have, in working through an example, is with respect to the unscale parameter. If the scale and offset are set within the raster:bands object, would those values be applied by titiler or the scale and offset stored in the dataset metadata? I would assume the later but just want to be clear, because titiler accepts a boolean attribute unscale at this time which I understand "Applies internal Scale/Offset". I think, if the virtual asset is being used, then the unscaling process would use the parameters in the raster:bands object

[vincentsarago]

@abarciauskas-bgse thanks for starting this discussion.

My understanding is that there is interest to support processing of virtual assets in titiler so that, when a virtual asset exists, and is passed to the API as part of the assets=[] parameter

Q:

• How will titiler know which assets it can use?
• Are the parameters titiler friendly? is the specification strict about the parameters (so we can map from the spec to titiler internally)

titiler would then look up the asset(s) and apply any parameters titiler expects (compose:*, processing:expression, raster:bands:nodata, unscale)

This can be quite tricky because how the fastapi application is designed (with dependency injections). We did something in titiler-pgstac where we inject tilejson url for predefined layers https://github.com/stac-utils/titiler-pgstac/blob/main/titiler/pgstac/factory.py#L737-L779

Do we agree with the metadata approach or see any issues with it? I will add one or more example assets with all parameters.

I'm not sure to understand the metadata approach?

Do we agree virtual assets should be supported by titiler

I'm happy to help supporting this if it doesn't had too much custom code and if the approach can be generalized. I also believe that some of the implementation will go directly in rio-tiler.

One question I have, in working through an example, is with respect to the unscale parameter. If the scale and offset are set within the raster:bands object, would those values be applied by titiler or the scale and offset stored in the dataset metadata? I would assume the later but just want to be clear, because titiler accepts a boolean attribute unscale at this time which I understand "Applies internal Scale/Offset". I think, if the virtual asset is being used, then the unscaling process would use the parameters in the raster:bands object

That's also tricky, rio-tiler cannot accept external scale/offset (at the moment) which is why titiler only accept unscale (default to False) parameter to either apply the internal scale/offset or not. The raster:bands info should (IMO) reflect the internal metadata of the data, not something the people want to add to the data 🤷, same for the nodata parameter.

[abarciauskas-bgse]

Thanks @vincentsarago I think I understand most of this so I think the next steps are:

• Wait until https://github.com/stac-extensions/virtual-assets and https://github.com/stac-extensions/render are released so we know what specification to expect
• If we agree that titiler should support virtual assets, design the implementation. This should consider the dependency injections of the fastapi application.
  • We should assume we will not be changing anything about how titiler handles parameters like unscale

I'm discussing with @emmanuelmathot to find some time to iron out the extensions' specifications so hoping we can all meet then to address the implementation questions.