Merge concepts of the proposed render extension

[abarciauskas-bgse]

The render extension has been proposed and we should either merge them or be clear about the purposes of each.

Both the render and web-map-links address the need to support visualizing raster data. web-map-links addresses this by defining link types for different visualization (or tiling) APIs. web-map-links supports parameters used to render raster data into image tiles via parameters included in href strings (I assume, I haven't seen an example that does this yet). The render extension, since it is mostly referring to dynamic tiling, overlaps with the xyz, wmts and proposed OGC-Tiles but explicitly includes those render parameters as part of its schema, which is separate from links.

I wonder if these 2 specs could be merged. From what I can tell web-map-links focuses on what API servers are available to render the data and render focuses on what parameters to pass to those servers. Would it make sense to merge these two specs?

A few options:

1. Add a titiler link type which includes those titiler parameters
2. Since titiler implements xyz, wmts and ogc tiles, than render parameters should be part of the spec for all of those link types
3. We keep the render extension separate, but presumably if some collection/item includes a link to a titiler instance in links, it would also include the render extension. And perhaps the render extension could grow in scope to consider the use cases of parameters which needs to be handled by the other tiling services.

@m-mohr @smohiudd @vincentsarago

[m-mohr]

As discussed on the STAC sprint this is related to this extension, but it will eventually be more capabale once templates links are defined by OGC. And then there's also the processing and composite extension that seem to do similar things. A combination of these extensions may replace the render extension.

[vincentsarago]

Just to be clear, the render template is not a link, I think the goal of the render extension is to give hint about how an assets or set of assets can be rendered, without giving much information about a possible tiling service (meaning that the render information can be used by any client (tiling services or scripts)

[abarciauskas-bgse]

@vincentsarago I think the composite extension can handle what the render extension is trying to achieve and I think the goal is to limit the number of extensions if possible to reduce the need to duplicate information across fields and increase adoption, so if we can appropriately modify or leverage an existing extension to meet our needs we should do so.

If I understand correctly, there are 2 things being proposed:

1. Use template-d links (@m-mohr suggested this as potentially superceding the current web-map-links but I can't find the OGC information about it) for tiling APIs to publish the existence of a service which supports a collection or item
2. Use the composite extension (which combines the use of virtual:assets, raster:bands, and processing:expression) to address the need to store tiling parameters in metadata