Connecting RSC catalogues to the INSPIRE geoportal
|Status:||Feedback||Start date:||20 Apr 2018|
|Assignee:||Angelo Quaglia||% Done:|
|Submitting Organisation:||Knowledge-Base relevant?:|
|Originating UI:||Keyword #3:|
could you please provide the CSW endpoint details?
#1 Updated by Joni Kaitaranta over 2 years ago
As you can see it is geonetwork implementation, and the records have passed the (old) INSPIRE validator.
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,
#2 Updated by Angelo Quaglia over 2 years ago
- Status changed from Assigned to Feedback
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:
Resources available for discovery: 169, Expected Resource Count: 169, Actual Resource Count : 169
#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.
#4 Updated by Angelo Quaglia about 2 years ago
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
in INSPIRE it has to be, for a View Service:
#5 Updated by Joni Kaitaranta about 2 years ago
- File GeonetworkServiceTemplates.PNG added
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
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">
<OnlineResource xlink:type="simple" xlink:href="http://mapy.geoportal.gov.pl/wss/service/CSWINSP/guest/CSWStartup?request=GetRecordById&service=CSW&version=2.0.2&outputschema=http://www.isotc211.org/2005/gmd&elementsetname=full&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:
You can find good examples of ISO 19139 View Services here:
You can use the INSPIRE Geoportal Validator 2 to check your metadata and your services:
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:
#9 Updated by Angelo Quaglia over 1 year ago
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.