Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wip/add landcover example #1

Conversation

abarciauskas-bgse
Copy link

@emmanuelmathot @vincentsarago @smohiudd it was proposed in the STAC sprint (see stac-extensions/web-map-links#19) that this composite meta-extension could solve the needs of the proposed render extension. I think this makes sense but there are a few concerns I have:

  1. communication - how do users of STAC and titiler know how to use this extension properly? It's still not entirely clear to me (as you will see in this PR) how to use this extension to satisfy the use case of rendering raster datasets via the titiler API.
  2. currently the composite extension is on the item level - I'm not sure we need to hydrate all items with these values so could it also be at the collection level?
  3. Right now the processing extension only allows for objects to be the value of the processing:expression and, as you see in this PR, what I think we need is a list.

@abarciauskas-bgse abarciauskas-bgse marked this pull request as draft September 26, 2023 20:28
@vincentsarago
Copy link

oh I forgot about this extension!

It seems a bit more complex than the render one but 👍

communication - how do users of STAC and titiler know how to use this extension properly? It's still not entirely clear to me (as you will see in this PR) how to use this extension to satisfy the use case of rendering raster datasets via the titiler API.

IMO, it's not up to titiler to know how to use this but to the client/user to construct URL correctly reusing the information.

currently the composite extension is on the item level - I'm not sure we need to hydrate all items with these values so could it also be at the collection level?

It would make sense to have this at collection level IMO

@abarciauskas-bgse
Copy link
Author

@emmanuelmathot options for expanding (or not) the processing spec to fit this use case:

  1. make processing:expression also accept a list, like I've done in this example
  2. create a new field for processing, perhaps processing:functions which accepts a list of key/value pairs with "name" for name of the function (i.e. rescale) and value (i.e. -1,1)
  3. use processing expression as-is where format is something generic but identifiable for dynamic tiling like render-params and then the expression is a query string rescale=-1,1&colormap=rdbu_r etc

I don't really like 3 since it doesn't make it easy to programmatically work with those values.

@abarciauskas-bgse
Copy link
Author

Closing in favor of stac-extensions/processing#28

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants