Dynamic Layer configuration - Wegue format

[justb4]

The current way to configure Layers is to define these in the Wegue config file like static/app-conf.json.

But there are scenario's where a remote server provides an API Endpoint that supplies a "Layer List". OGC Standard examples are WMS Capabilities documents. The GeoExt.tree.WMSCapabilitiesLoader is an example of a client that expands this to Layer objects.

And with the new OGC REST API an OpenAPI Feature "Collections" as a JSON doc, see example here.

These should be addressed in separate issues. The issue here suggests a more direct approach and format: as Wegue Layers are already JSON nodes, a remote endpoint (or local file under e.g. static) could provide an array of Wegue Layer definitions like:

[
    {
      "type": "VECTOR",
      "lid": "dutch_windmills",
      "name": "Dutch Windmills",
      "url": "https://demo.pygeoapi.io/master/collections/dutch_windmills/items",
      "formatConfig": {
        "dataProjection": "EPSG:4326"
       },
      "format": "GeoJSON",
      "visible": true,
      "selectable": true,
      "style": {
        "iconUrl": "https://someiconserver.io/windmill2.png",
        "anchor": [0.5, 37],
        "anchorXUnits": "fraction",
        "anchorYUnits": "pixels"
      }
    },
    {
      "type": "VECTOR",
      "lid": "dutch_castles",
.
.
]

Such a Wegue Layer Def could be defined as a special Layer type with the endpoint URL and possibly some other parameters. Something at minimum:

    {
      "type": "OSM",
      "lid": "osm-bg",
      "name": "OSM",
      "isBaseLayer": true,
      "visible": true,
      "displayInLayerList": false
    },
    {
      "type": "WEGUELAYERCOLLECTION",
      "url": "https://some.server.io/api/layer_list"
    },

[chrismayer]

So, thanks for this @justb4. One general question: Is this all about "divide and conquer", so that we separate the mapLayers from the application config? Or is the main motivation the preparation of embedding remote endpoints as you described for OGC REST API an OpenAPI Feature? Are there any other advantages? What bothers me is the fact that you can declare single layers directly in the app-config's mapLayers and inject others by a defining this special layer type. This might be confusing somehow, IMHO. But maybe I oversee something here.

[justb4]

@chrismayer : thanks for reaction. The requirement came from a real-world project where Vector data is managed within a CMS and unlocked via HTTP endpoints each providing a single GeoJSON Feature Collection. The "Collection of Collections" (like Capabilities) is defined in a single endpoint that returns an array of Wegue Layer JSON definitions. Now one could argue that it would be better to use an OGC standard like WFS or better OGC API Features ("WFS3"), but then you would also have define/manage Styles, icons and other resources within the Wegue frontend app, in a somehow generic fashion (as users can add new Layers/icons in CMS). Now all these can be managed in the CMS.

The other use-case is a local "LayerList" JSON file as static resource. This could help with app managers to separate the main config from a Layer list, having that list maybe created via other tools/transformations. One example I saw in the Wegue FOSSGIS 2020 presentation is the "QGIS2Wegue QGIS Plugin" by @JakobMiksch . Maybe it can be useful there.

The mechanism within Wegue (need async fetching/axios), getting layer-list can be factored out later to support OGC Capabilities endpoints for WMS, WFS and WFS3, and why not ;-) ArcGIS Online endpoints...Did something similar in the past with GeoExt/GXP/Heron, even generate a LayerTree. Big issue was with WFS how to deal with Layer styling...

[chrismayer]

Thanks for the clarification @justb4. Makes things much clearer. From my side we can introduce a dynamic layer configuration. Since it is backwards compatible no existing configs have to be changed. I'll have a look at your PR #113