Map view WMS query syntax doesn't match standard

[KoalaGeo]

Describe the bug

Our service metadata has online resource, such as: https://map.bgs.ac.uk/arcgis/services/GeoIndex_Onshore/boreholes/MapServer/WmsServer?service=WMS&request=GetCapabilities which works directly in the map tab, but GN can't add it to the map if using the "add service layer to map button"

To Reproduce Steps to reproduce the behavior:

1. Click add to map from record https://metadata.bgs.ac.uk/geonetwork/srv/eng/catalog.search#/metadata/a028c1bb-594a-4837-e044-0003ba9b0d98)
2. See error - map doesn't load.

Expected behavior WMS should be displayed in map

Screenshots

&

Desktop (please complete the following information):

• Browser: Chrome
• GeoNetwork Version: 3.12.2
• Server Application: Offical Docker image

[jahow]

The problem is that your metadata describes the WMS layer name like so:

<gmd:name>
  <gco:CharacterString>BGS Detailed Bedrock and Superficial geology (OGC WxS INSPIRE)</gco:CharacterString>
</gmd:name>

But when you look at the WMS capabilities document, this layer name does not appear anywhere.

A valid layer name would for example be GeoIndex.Boreholes.theme.

I'm closing this issue at it does not seem related to your metadata, don't hesitate to comment or add information and we can open it again.

[nmtoken]

The harvested metadata (ISO 19139) is:

BGS Detailed Bedrock and Superficial geology (OGC WxS INSPIRE)

The title given to the service (not any layer) is:

`

BGS Detailed Bedrock and Superficial geology (OGC WxS INSPIRE) ` In https://metadata.bgs.ac.uk/geonetwork/srv/eng/catalog.search#/metadata/a028c1bb-594a-4837-e044-0003ba9b0d98 **Downloads and links** are all to the service, either the endpoint, or different versions of GetCapabilities, not any layer.

[KoalaGeo]

@jahow we've tested again.

If we include a resource name on the service it breaks

This works:

<gmd:CI_OnlineResource>
  <gmd:linkage>
    <gmd:URL>https://map.bgs.ac.uk/arcgis/services/GeoIndex_GSNI/GSNI_Hydrogeology/MapServer/WMSServer? 
     request=GetCapabilities&service=WMS</gmd:URL>
  </gmd:linkage>
  <gmd:protocol>
    <gco:CharacterString>OGC:WMS-1.3.0-http-get-capabilities</gco:CharacterString>
  </gmd:protocol>
  <gmd:description>
    <gco:CharacterString>Hydrogeology Layers</gco:CharacterString>
  </gmd:description>
</gmd:CI_OnlineResource>

Click Add service layer to map =

If we complete the resource name:

<gmd:CI_OnlineResource>
          <gmd:linkage>
                        <gmd:URL>https://map.bgs.ac.uk/arcgis/services/GeoIndex_GSNI/GSNI_Hydrogeology/MapServer/WMSServer?request=GetCapabilities&amp;service=WMS</gmd:URL>
           </gmd:linkage>
            <gmd:protocol>
                        <gco:CharacterString>OGC:WMS-1.3.0-http-get-capabilities</gco:CharacterString>
            </gmd:protocol>
            <gmd:name>
                        <gco:CharacterString>Hydrogeology Layers</gco:CharacterString>
            </gmd:name>
             <gmd:description>
                        <gco:CharacterString>Hydrogeology Layers</gco:CharacterString>
             </gmd:description>
</gmd:CI_OnlineResource>

it fails

[jahow]

This makes sense because Hydrogeology Layers is not a valid layer name in the aforementioned GetCapabilities document.

In GeoNetwork the <gmd:name> element is expected to hold a valid WMS layer name.

PS: as of now, the GetCapabilities document is unreachable

[josegar74]

Afaik, these protocols should be managed as services, ignoring the gmd:name to display the layer selector in the map viewer:

https://github.com/geonetwork/core-geonetwork/blob/a9478cef237258897311d931b066177756d143bb/web-ui/src/main/resources/catalog/views/default/config.js#L116-L121

At least that was the initial purpose to distinguish them from these others:

https://github.com/geonetwork/core-geonetwork/blob/a9478cef237258897311d931b066177756d143bb/web-ui/src/main/resources/catalog/views/default/config.js#L108-L115

Maybe some code change has broken this behaviour.

[nmtoken]

Seems an odd expectation though because the resource being described is a service GetCapabilities response, not a layer in the service; if it were the stem for a GetMap request then layer name might be appropriate.

In the INSPIRE technical guidance (Technical Guidelines for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007) for a WFS GetFeature we have as an example:

<gmd:name> 
    <gco:CharacterString>WFS GetFeature request for downloading the data set</gco:CharacterString> 
</gmd:name>

and not the name of the feature type

[jahow]

Thanks all for the clarifications! Indeed, this makes sense to me: the protocol should indicate that we're looking at a service description and not an individual layer in there. So, it looks like there was a regression on that front.

If someone from your organization could come up with a fix that would be highly appreciated; then other people will do their best to review it.

[KoalaGeo]

@jahow we'll (@rachelheaven & @nmtoken ) have a go when we roll over to the next FY