Make a new STAC example with less config

[jisantuc]

Currently the configuring the stac-example requires starting the application with a new config any time you want to visualize another collection. It would be nice if instead we could consume the collections list endpoint and figure out what to visualize from there. I think that could cut down a lot of the config size, and then you could drive "where do collections live" with a STAC_API_HOST env var and be close to done -- at least if just want the easiest thing -- instead of having to repeat configuration blocks for every collection you want to visualize.

[pomadchin]

Sounds like a nice configuration improvement. In some cases there can be a need just to visualize all collections that are available. In this case it would be enough to provide the STAC_API_HOST and the ASSET_NAME.

This would require to add an extra configuration type.

[pomadchin]

Talked to @jisantuc, assets_id can also be an extra endpoint param.

[pomadchin]

Just for more context, really the OGC LayerId is a tuple (collection.id, asset.id).
To workaround the limitation of queries bounded by OGC standards and complexity of adding user defined params we can make an endpoint and provide a "fixed" collectionId or assetId:

1. /collectionId/wms?request=getCapabilities
2. /assetId/wms?request=getCapabilities

• In the first case "OGC Layers" would be asets within a single collection. So each assets would be able to represent a displayable layer.
• In the second case "OGC Layers" would be collections that have a specified asset.

I got a sense that 1. is preferable here.

[jisantuc]

I got a sense that 1. is preferable here.

I preferred it at first because it matched how I was thinking about things, but meaningful asset names would make 2 pretty nice too. Like if I have a NIR800 asset name and I'm consistent with how I name things in different places, then it would be cool I guess to see all the collections that have any items with that asset available.