Display hierarchical/category layers from layer tree when importing remote layers

[ridoo]

(Perhaps this is better located at geonode-mapstore-client -- I can transfer it to that repo, if you agree)

Is your feature request related to a problem? Please describe. When adding layers from a remote WMS which provides a hierarchical layer tree, only those layers which can be imported are displayed. Parent layers for example are not importable and therefore not displayed. However, a layer hierarchy has a meaning which cannot be grasped during the layer import.

Take this WMS providing high water risks in German North-Rhine Westphalia:

<Layer>
  <Title>Hochwasser Gefahrenkarte</Title>
  <Abstract>Hochwassergefahrenkarten informieren über die mögliche Au ...</<Abstract>>

  <!-- ... --> 

  <Layer queryable="1">
    <Title>Niedrige Wahrscheinlichkeit (> HQ500)</Title>
    <Abstract>Niedrige Wahrscheinlichkeit (> HQ500)</Abstract>
  
    <!-- ... --> 
  
    <Layer queryable="1">
      <Name>3</Name>
      <Title>Überschwemmungsgrenze der Gebiete ohne technischen Hochwasserschutz</Title>
      <Abstract>Überschwemmungsgrenze der Gebiete ohne technischen Hochwasserschutz</Abstract>
    
      <!-- ... --> 
  
  <Layer queryable="1">
    <Title>Mittlere Wahrscheinlichkeit (HQ100)</Title>
    <Abstract>Mittlere Wahrscheinlichkeit (HQ100)</Abstract>
    
    
    <!-- ... --> 
    
    <Layer queryable="1">     
      <Name>8</Name>
      <Title>Überschwemmungsgrenze der Gebiete ohne technischen Hochwasserschutz</Title>
      <Abstract>Überschwemmungsgrenze der Gebiete ohne technischen Hochwasserschutz</Abstract>
      
      
      <!-- ... --> 
      
</Layer>

Without their parents Niedrige Wahrscheinlichkeit (> HQ500) (Low probability (>HQ500)) Mittlere Wahrscheinlichkeit (HQ100) (Mid probability (>HQ500)) the importable layers 3 and 8 cannot be differentiated (they have same name and abstract).

Describe the solution you'd like During importing layers from a remote service, the structure of the layer tree should be reflected. It would be good to see the layer name and abstract which helps to decide which layer to import (so that it can be renamed later).

Describe alternatives you've considered The import list could at least show abstract as a tooltip to get a quick understanding about each layer. However, this would not solve the problem for the WMS above as the abstract does not differ neither. Here only a structural view would help to differentiate the layers.

Additional context

• https://development.demo.geonode.org/catalogue/#/map/590
• Here is another example: Riskmap for flooded areas
  • Missing category layers:
• Notable section about Name vs Title in the WMS Spec

  7.2.4.6.3 Name If, and only if, a layer has a <Name>, then it is a map layer that can be requested by using that Name in the LAYERS parameter of a GetMap request. A Layer that contains a <Name> element is referred to as a “named layer” in this International Standard. If the layer has a Title but no Name, then that layer is only a category title for all the layers nested within. A server that advertises a Layer containing a Name element shall be able to accept that Name as the value of LAYERS argument in a GetMap request and return the corresponding map. A client shall not attempt to request a layer that has a Title but no Name.

[giohappy]

@ridoo This feature is under discussion with some of our clients. Hopefully, there will be something in that direction in the future. The ability to have the group layers also managed a single resource, and have the option to use them in bulk (as MS group of layers) inside maps is also part of the discussion.

If you have plans to work on this let's discuss it.

[ridoo]

@giohappy This was something which popped up when preparing a litte workshop. No plans how to handle this right now. However, I thought to raise this issue before forgetting about it.

[gannebamm]

This could be interesseting and needed for an upcoming project at Thünen. Thanks for drafting the idea @ridoo. I will discuss this with the projects stakeholders in one of our next meetings.