Open abarciauskas-bgse opened 11 months ago
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
@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:
titiler
know which assets it can use? 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.
Thanks @vincentsarago I think I understand most of this so I think the next steps are:
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.
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 theprocessing
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: