The WFS fallback does not respect `featureinfoLayer`

[MattiasSp]

The featureinfoLayer config parameter on WMS, WMTS or AGS_TILE layers is not taken into account.

Example:

• A WMS layer that is published as a group layer by the WMS Service contains a polygon layer, a linestring layer and a point layer as sublayers.
• The polygon layer is also defined in the config and referenced by the WMS group layer as its featureinfoLayer.
• When clicking on the group layer with the MultiSelect plugin disabled, the featureinfoLayer is queried and its results are displayed correctly.
• When activating the MultiSelect plugin and clicking again, it tries to query a WFS version of the group layer instead of the layer referenced by featureinfoLayer.

{
  "name": "registerenhet_yta",
  "source": "qgis_lm",
  "title": "Fastighetsytor",
  "group": "none",
  "visible": false,
  "queryable": true,
  "type": "WMS",
  "geometry": "geom",
  "attributes": [{ "name": "fastighet", "title": "Fastighetsbeteckning: " }]
  },
  {
  "name": "registerenheter_alla",
  "source": "qgis_lm",
  "title": "Fastighetsindelning",
  "group": "grupp1",
  "visible": true,
  "queryable": true,
  "featureinfoLayer": "registerenhet_yta",
  "style": "registerenheter_alla",
  "type": "WMS",
  "format": "image/png"
},

I am aware of the (undocumented) alternativeLayers parameter, which also solves problem described above, but I think the featureinfoLayer should be respected as well.

Perhaps any featureinfoLayer parameters on layers could be merged into the MultiSelect alternativeLayers config on initialization?

[steff-o]

When I wrote the alternativeLayers handling it was to solve the problem with WMS when selection using a geometry. WMS has no endpoint for getting features by geometry, or even extent, so the old solution was to assume that there is a WFS service at the same adress, which works for Geoserver because even if the url contains the service (/geoserver/WMS/) the wfs request contains the service parameter (/geoserver/WMS?ows=WFS), which overrides the url part. That implementation resides in origo repo in getFeature.js and worked. But we used filters on the WMS layers and they were not applied to the WFS call. Instead of implementing that in Origo I added the alternativeLayers configuration to make it more explicit where to query. I also introduced the possibility to use only the WMS layer by making a "big click" by squeezing the map into a smaller frame so the featureInfo pixel would cover the desired area and return all features in the area. None of these methods supports Origo's configuration for featureInfoLayer for a couple of reasons:

1. In my mind there is a difference between featureinfo and select. Although I admit in Origo, they are pretty much the same. But I didn't want to mix configuration that is ment for featureInfo to be used in selection.
2. More of the implementation from Origo had to be duplicated in Multiselect to emulate the behavior of featureInfo
3. I wasn't aware of any reliable way of getting Origo's effective configuration from the plugin. Maybe just a layer.get('featureInfolayer') would have done it?
4. No one asked for it.

So much for history. The alternativeLayer and featureInfolayer could be merged as you suggest, but it won't work exactly the same as in featureInfo as alternativeLayer is not recursive, it is only one level. Also if the alternative layer is a WMS it will automatically be converted to a WFS call when Multiselect calls getFeature() in Origo. featureInfolayer in Origo only supports WMS (and WMST and AGS Map) as alternative layers and will use a WMS call to fetch features.

But if it works for you I won't object if you merge them if there is an explicit configuration for it that defaults to false. Not that I think that anyone uses featureInfoLayer for layers that are used with Multiselect, but if someone is doing it they may get a changed behavior.