Find a workaround to hard coding index names and metadata in OGC service configuration

[jvanulde]

Currently we are hard coding the Elasticsearch index name and associated metadata for each scenario in the configuration:

resources:
    afm7p2_lrdmf_economic_loss_building:
        type: collection
        title: Economic loss buildings
        description: Economic consequences aggregated
        keywords:
            - earthquake
        links:
            - type: text/html
              rel: canonical
              title: information
              href: http://www.riskprofiler.ca/
              hreflang: en-US
        extents:
            spatial:
                bbox: [-180,-90,180,90]
                crs: http://www.opengis.net/def/crs/OGC/1.3/CRS84
            temporal:
                begin: 2020-08-06
                end: null  # or empty (either means open ended)
        providers:
            - type: feature
              name: Elasticsearch
              data: http://elasticsearch-opendrr:9200/afm7p2_lrdmf_economic_loss_building
              id_field: Sauid

This is difficult to manage and maintain. We need to find a place and mechanism to generate these "resources" dynamically.

[jvanulde]

I am clearing the milestone for now. We'll keep it in the backlog.

[jvanulde]

I wrote a quick script that generates the resources portion of the configuration for pygeoapi from ES indices. See: https://github.com/OpenDRR/opendrr-api/blob/gen-pygeoapi-config/python/gen-pygeoapi-config.py