Support #3212

Connecting RSC catalogues to the INSPIRE geoportal

Added by Angelo Quaglia over 2 years ago. Updated over 1 year ago.

Status:FeedbackStart date:20 Apr 2018
Priority:NormalDue date:
Assignee:Angelo Quaglia% Done:


Target version:-
Submitting Organisation: Knowledge-Base relevant?:
Proactive:No Keyword #1:
Country: Keyword #2:
Originating UI: Keyword #3:


Dear Joni,

could you please provide the CSW endpoint details?

Best regards,


GeonetworkServiceTemplates.PNG (30.5 KB) Joni Kaitaranta, 18 May 2018 02:01 pm


Related issues

Copied from Geoportal Helpdesk - Support #3211: Connecting RSC catalogues to the INSPIRE geoportal Feedback 20 Apr 2018


#1 Updated by Joni Kaitaranta over 2 years ago

Entry page:

As you can see it is geonetwork implementation, and the records have passed the (old) INSPIRE validator. 

CSW GetCapabilities:

We have not been really using the CSW before (just the geonetwork UI), so might require some editing in our side, if you are pulling information from the getCapabilitites response. 

About filtering/keyword. Currently we have keyword "HOLAS2" specified for the datasets relevant to State of the Baltic Sea report, but it contains a bit more than just the indicators, so we should use something else for it. 

But for testing you could use the "HOLAS2" keyword for filtering the relevant datasets.


Let me know if you have questions,

Best regards,


#2 Updated by Angelo Quaglia over 2 years ago

  • Status changed from Assigned to Feedback

Dear Joni,

many thanks.

The first harvesting, technically, went very well.

Metadata quality is very high, so the first meter is almost off the scale.

However, only datasets were retrieved:

In INSPIRE, you need metadata also for View (WMS) and Download Services (WFS, Atom, etc.) and their capabilities must link to the datasets they serve.

It is because of that reason that the meter on the right is extremely low.


The harvesting was performed with the following parameters:









The harvesting report is available here:

Result of the interaction with the Discovery Service

Resources available for discovery: 169, Expected Resource Count: 169, Actual Resource Count : 169

Best regards,




#3 Updated by Joni Kaitaranta about 2 years ago



Thanks for the summary. Nice to see it went well in terms of dataset metadata. 


We have now created a service metadata based on the existing ISO template that there is in Geonetwork by default for our WMS (1.3.0) service that contains the indicator results (and also other datasets). It is here:


Is that something that would be fit for purpose? It simply contains the get capabilities address, where one can get layer list etc. 


Best regards,



#4 Updated by Angelo Quaglia about 2 years ago

Dear Joni,

in general you would need to go to:

and validate your service metadata there.

I did it for you, and the result is available here:


1) The most serious issue with the metadata is this one:

Unrecognized Spatial Data Service Type

<gco:LocalName codeSpace="">OGC:WMS</gco:LocalName>

in INSPIRE it has to be, for a View Service:

2) The first most serious with the View Service (WMS) is that the layers do not have the metadataURL element containing the link to the metadata of the dataset they portray.
3) The first most serious with the View Service (WMS) is that it is missing the INSPIRE Extended Capabilities.
Best regards,

#5 Updated by Joni Kaitaranta about 2 years ago

Dear Angelo,

Thanks for the swift reply. I have few questions in order to be able to solve the issues. 

It seems that the "Template for WMS service in ISO19139/119" which i used in Geonetwork for this test is not very well suited for this. Do you happen to know if there would be a template available for Geonetwork which we could apply to be used for this? (see attached where is the default template of service)


1) "Unrecognized Spatial Data Service Type"

Solution: Adding a tag of service type. Should be simple. Ideally this should be already correct in the template of the WMS service in Geonetwork. 

2) "Layers do not have the metadataURL element containing link to the metadata of dataset they portray".

Is this something that should be in the service metadata record? Not e.g. in the getCapabilities of the service? We have ~200 layers so this is quite big effort to add all these. 

3) "View service is missing the INSPIRE Extended Capabilities"

Should the INSPIRE Extended Capabilities be located in the GetCapabilities file or in the metadata record? 


Thanks in advance,


#6 Updated by Angelo Quaglia about 2 years ago

Dear Joni,

1) That is correct, but please note that since the multplicity of the <srv:serviceType> element is 1, you have to replace the value "OGC:WMS" with "view" which might not be understood by some non-INSPIRE clients



2) I am referring to the MetadataURL element nested inside the Layer element in the OGC WMS Capabilities document.

It has to point to the metadata records of the Spatial Data Set portrayed by the layer, for example:

<Layer queryable="1" opaque="0">



       <MetadataURL type="ISO19115:2003">


             <OnlineResource xlink:type="simple" xlink:href=";service=CSW&amp;version=2.0.2&amp;outputschema=;elementsetname=full&amp;Id=02799338-da67-4e2f-8606-4f24ffb20402"/>





However, INSPIRE also requires the so called "Coupled Resources" in the service metadata. The current implementation uses the operatesOn element in the ISO 19139 service metadata, but without the indication the layer name, so it is of limited use.


3) The INSPIRE Extended Capabilities resides in the OGC WMS Capabilities


You can find good examples of ISO 19139 View Service metadata here:*%20TO%20*%5D&fq=resourceType%3Aservice&fq=spatialDataServiceType%3Aview&fq=interoperabilityAspect%3ANETWORK_SERVICE_MATCHING_SERVICE_IS_AVAILABLE&q=*%3A*


You can find good examples of ISO 19139 View Services here:*%20TO%20*%5D&q=*%3A*



You can use the INSPIRE Geoportal Validator 2 to check your metadata and your services:


Best regards,




Technical Guidance documents are available

ISO 19139 for INSPIRE:


OGC WMS 1.3.0 for INSPIRE:


#7 Updated by Michael Lutz about 2 years ago

On the 1st issue raised by Angelo, the MD TG v2.0 says:

NOTE Since the value domain of this metadata element is restricted to the values defined in Part D3 and the multiplicity of the element is 1, it is not possible to provide a more detailed type for the service (e.g. OGC:WMS or OGC:WMTS for a view service). Such additional information can be provided in several ways in the metadata, e.g. using keywords, the srv:serviceTypeVersion element or the gmd:protocol element nested inside the gmd:transferOptions.

#8 Updated by Joni Kaitaranta over 1 year ago

Dear Angelo and all,


Coming back to this issue in advance of the online meeting tomorrow,  I looked into to implementing some improvements. Those are listed below, with some questions on recommendations on how to proceed. 


1) The service tag was added as required:

implemented now here:
- that part should be ok? 
2) To add MetadataURL elements and for the purpose of connecting a WMS to the geoportal I made a separate service which has fixed amount of layers (~100, assessment results from State of the baltic sea report).
GetCapabilities here: 
Some questions related to this: 
- As we are using ArcGIS server, i would have to follow this instruction on modifying the xml file and then republish the service with external capabilities file (the modified xml) to get metadataURLs there: 
Would this be the recommended way to add extended inspire elements to system generated getCapabilities file or do you have any good practices or recommendations for doing this rather than editing the xml manually? We don't have AGS for INSPIRE at hand. 
- Which WMS version should i add metadataURLs? All or is just 1.3.0 sufficient? 
Probably more questions to follow but it would be good to clarify these before i get going. 
Thanks and best regards,

#9 Updated by Angelo Quaglia over 1 year ago

Dear Joni,

1) Yes, the Spatial Data Service Type is now recognised correctly:

Spatial Data Service Type

View Service

but you might want to review this (disregard the errors reported for the layers):


2) That is OK but you might want to review this:


-the external capabilities file seems a valid approach to me especially since it is documented by ESRI. Of course, there will be a bit more maintenance on your side.


- the INSPIRE Geoportal looks first for WMS 1.3.0 - ISO19128 and stops there if it finds it.


Best regards,


Also available in: Atom PDF