add-layer (from wms) should be postponed until capabilities has loaded

[pvgenuchten]

Some wms servers unfortunately are quite slow in returning response to getcapabilities

If a user tries to add a layer while capabilities is still loading, an error is shown:

Wait a few seconds and try again, it works fine

suggestion would be to disable the panel until capabilities has loaded (now only the spinner is shown)

---

this problem also occurs when layers are loaded by default (via workbench configuration), terria tries to add them while capabilities is still loading, causing the same error

---

An example of a slow capabilities is: https://gaez-services.fao.org/server/services/LR/ImageServer/WMSServer?request=GetCapabilities&service=WMS

[nf-s]

Hi @pvgenuchten

You shouldn't be able to add a WMS layer until GetCapabilities has finished loading.

Can you please share your catalog/init JSON file and/or the process you took to get the error?

Thanks
Nick

[pvgenuchten]

There are 2 scenario's in which this error occurs

• a config includes a wms-group with some predefined members, in catalogue open the wms-group, and directly click the first member (while the getcapabilities is still running), see gaez.zip
• if i load a config (or shared map) which has a wms-layer enabled via workbench configuration, see this shared map, with terria running at localhost:80

error displayed is 'Could not load the Web Map Service (WMS) GetCapabilities document because the catalog item does not have a url', but my impression is that it is related to gecapabilites not finished loading

[pvgenuchten]

The shared map in second bullet may actually be another problem, I just noticed that the share map link does not include a reference to the wms, it refers to a map config having that url, maybe that is somehow related to the error.

Because if i try this shared map it works fine

[nf-s]

Oh I see. Yes I agree, members shouldn't show until the group has finished loading. Because you have defined manual wms items, Terria won't have "merged" them with items generated by the GetCapabilities response - so until it finishes loading they will be incomplete.

I made an issue to capture this

• Groups should not show members in the Data Catalog until loading is finished #6867

We generally discourage use of members in "dynamic" groups like wms-group, as it can result in "stub"/incomplete items - for example if a WMS server were to unpublish a layer, or if a network error were to occur, you would be left with an incomplete WMS item (in the same way as you found before loading had finished).

What are you trying to achieve by manually defining wms-group members? There are a few other properties which may be useful - for example:

flatten

True to flatten the layers into a single list; false to use the layer hierarchy.

excludeMembers

An array of strings of excluded group and item names (or ids).

itemPropertiesByIds

Sets traits on group member items by model ID.

For example - this will override the name of a GAEZ/LR:Dominant Soil and exclude GAEZ/LR:AEZ Classification (33 Classes)

 {
  "catalog": [
    {
      "id": "GAEZ",
      "type": "wms-group",
      "name": "GAEZ",
      "url": "https://gaez-services.fao.org/server/services/LR/ImageServer/WMSServer?request=GetCapabilities&service=WMS",
      "itemProperties": {
        "rectangle": {
          "west": -180,
          "south": -90,
          "east": 180,
          "north": 90
        }
      },
      "excludeMembers": [
        "GAEZ/LR:AEZ Classification (33 Classes)"
      ],
      "itemPropertiesByIds": [
        {
          "ids": [
            "GAEZ/LR:Dominant Soil"
          ],
          "itemProperties": {
            "name": "Some overridden name"
          }
        }
      ]
    }
  ]
}

I believe your second issue is similar to the first - I made an issue to capture this as well

• Items in init workbench should load parent groups #6868

As for resolving your problem in the short-term - it would probably be easiest to just fully define any member that you put inside your wms-group (eg include url, layers, etc).

[nf-s]

Generally speaking Terria can be a bit funky when you start mixing "dynamic" groups and manually defined members - ideally it would be handled much better 🙂
We try to avoid doing it in our maps

[nf-s]

@pvgenuchten I am going to move this into a GitHub discussion, I think I have captured your issues in those two bug tickets. Please let me know otherwise. Thanks!

[pvgenuchten]

Useful comment, the excludemembers could work for me, going to try that, thanx