View Service WMS validator too strict: harmonized layer names should not be mandatory

[thijsbrentjens]

The View Service WMS validator seems to be too strict when testing layer names. It tests on harmonized layer names, but this is not mandatory for each layer. For example: if the WMS is offering as-is data only (which is still allowed). Or if the WMS offers harmonized data in some layers and as-is data in other layers (the TG does not require a View Service to offer harmonized data exclusively as far as I can see).

Take for example this WMS:

https://geodata.nationaalgeoregister.nl/cbsprovincies/wms?&request=GetCapabilities&service=WMS

To help us investigate the issue, you may want to include:

• [x] a description of the steps to reproduce your issue:

  1. go to http://staging-inspire-validator.eu-west-1.elasticbeanstalk.com/etf-webapp/
  2. use View Service > WMS tests
  3. enter: https://geodata.nationaalgeoregister.nl/cbsprovincies/wms?&request=GetCapabilities&service=WMS as a service
  4. start tests and see the report, GetCapabilities > at39-getcapabilities-layer-name

• [x] the name of the Test that failed or better: change the Level of Detail in the Report by clicking on All Details, then scroll down to the failed test and copy the Link on the right-hand side of the Assertion URI http://staging-inspire-validator.eu-west-1.elasticbeanstalk.com/etf-webapp/v2/TestRuns/EID7257bed0-09e6-447a-88c1-f72b4003fba4.html?lang=nl#EID53c10ea9-016a-1000-297b-3d4837ad3225 TestStep ID: EID738051b8-6344-42be-8315-6fbc69f52575

• [x] the URL of your service / the file you have uploaded or referenced (as an attachment).

https://geodata.nationaalgeoregister.nl/cbsprovincies/wms?&request=GetCapabilities&service=WMS

[thijsbrentjens]

Related: https://github.com/inspire-eu-validation/view-service/blob/review-ats-tg_3.11/iso-19128/at39-getcapabilities-layer-name.md But this might need a change then too

[inakidiazdecerio]

Dear @thijsbrentjens,

Thanks for reporting the issue.

We are going to discuss the solution in the next subgroup meeting and see if the test could be relaxed.

Best regards.

[MarieLambois]

I agree that this test is too strict. 1 - Thijs is rigth that there is no obligation to provide only those layer names. 2 - Moreover I have always thougth that those mandatory layer names are not user friendly at all. The user that aggregates several datasets have several layers with all the same names; Not easy to distinguish.

[alitka]

I also agree that this test is too strict. In the german GDI-DE Testsuite we implement an exception for this kind of test (for both WMS Version):

Every layer at "/wms:Capability/wms:Layer", except for the root layer, musthave a wms:Name element, specifying a name for the layer.

<ctl:test name="INSPIRE_VS.ISDSS.Layer.name">
--
<ctl:param name="GetCapabilities.document"/>
<ctl:assertion>Every layer at &quot;/wms:Capability/wms:Layer&quot;, 
except for the root layer, must have a wms:Name element, 
specifying a name for the layer.</ctl:assertion>
<ctl:comment>Implements implementation rules 39</ctl:comment>
<ctl:code>
<xsl:for-each 
select="$GetCapabilities.document//wms:Capability/wms:Layer/descendant::wms:Layer">
<xsl:choose>
<xsl:when test="./wms:Name = ''">
<ctl:message>WARNING: The layer with title &quot;<xsl:value-of select="./wms:Title" />&quot; 
does have a wms:Name element at &quot;/wms:Capability/wms:Layer[wms:title='<xsl:value-of 
select="./wms:Title" />']&quot;, which however was empty.</ctl:message>
<ctl:warning />
</xsl:when>
<xsl:when test="./wms:Name" />
<xsl:otherwise>
<ctl:message>FAILURE: The layer with title &quot;<xsl:value-of select="./wms:Title" />&quot; 
does not have a wms:Name element at &quot;/wms:Capability/wms:Layer[wms:title='<xsl:value-of 
select="./wms:Title" />']&quot;. Please provide a name for this layer.</ctl:message>
<ctl:fail />
</xsl:otherwise>
</xsl:choose>
</xsl:for-each>
</ctl:code>
</ctl:test>

[michellutz]

I think the issue is not with the test but with the requirement in the TG for View Services.

The NS IRs simply require a Name (Description: Harmonised name of the layer) parameter as part of the layer metadata response parameters in a Get View Service Metadata response.

The TGs say in TG requirement 39: Name shall be mapped with the element. The harmonised name of a layer shall comply with the Layer requirements of the [INS DS, Article 14].

However, this requirement does not originate in the NS IRs, but in the IR-ISDSS, even if the only way to check this requirement, is through the view service.

I just noted that the data ATSs actually already include a specific part on portrayal requirements, where the conformance target is the view service, e.g. https://github.com/inspire-eu-validation/data-au/tree/3.1/au-portrayal

But I think these tests have not been implemented in the ETS. I think adding these tests as a conformance class to the ETS for view services would be the cleanest way (similar to the way that this is being done for the metadata requirements for interoperability (based on requirements in the IR-ISDSS).

[thijsbrentjens]

@michellutz what I meant: there may be other layers in a WMS, that are not harmonized. For example a WMS offering all mandatory harmonised layers and some other layers of the same dataset (e.g. grouped layers). Is such a mixture of Layers not allowed per the TG or the IR? In other words: do you mean that a WMS is allowd to exclusively offer harmonised layers (following all requirements from the IR etc)?

The latter could have quite some consequences and may require some extra explanation to dataproviders I think.

[bgsmase]

We use group layers to provide the harmonised layer with other names for layers inside.

https://themes.jrc.ec.europa.eu/discussion/view/13952/layer-naming

[MarcoMinghini]

2017.4 meeting 2019-05-22

Following @michellutz's comment, it is agreed to have 2 conformance classes, in order to:

1. relax the requirement for View Services, i.e. check that a Layer Name element is provided
2. implement a requirement that checks for the harmonization of layer names, in accordance to the IR on ISDSS.

[Kate-Lyndegaard]

Hi, Can you please tell me what the current status of this issue is? We are receiving errors for our INSPIRE Planned Land Use WMS services.

Reproduction steps:

1. Go to http://staging-inspire-validator.eu-west-1.elasticbeanstalk.com/
2. use View Service > WMS tests
3. Enter https://test.haleconnect.de/ows/services/org.304.2f9d3927-24cc-4faa-bdf5-fa324e54b9de_wms/org.304.f511ac5f-8c17-4883-914b-146c238a2ed4?SERVICE=WMS&REQUEST=GetCapabilities&VERSION=1.3.0 as a service
4. Start test and see the report, GetCapabilities > at39-getcapabilities-layer-name Error: The following layers do not have a correct name according with the harmonised layer names given in the INSPIRE collection: 'org.304.f511ac5f-8c17-4883-914b-146c238a2ed4_bp_planRaster'.

The WMS contains a vector layer named LU.SpatialPlan and a raster layer which contains associated data (a georeferenced PDF of the plan). Given the scenario, what layer name would be acceptable for the raster layer?

[josemasensio]

Dear @Kate-Lyndegaard @thijsbrentjens,

Thank you for your message. We are modifying the test to add an assertion on it. This assertion will check if a manual review is required when a non-harmonised layer is reported.

We will come back to you when the solution is deployed on the staging instance.

Thank you and best regards.

[carlospzurita]

Dears @Kate-Lyndegaard @thijsbrentjens We have deployed the solution in the staging instance . Can you please check if the issue is solved?

Thank you.

[Kate-Lyndegaard]

Dear @carlospzurita,

Thank you very much! I can confirm that the issue is solved for my service.

[iuriemaxim]

I think it is a mistake to implement this into production.

View services are Network Services. ISDSS are not regulated by Network Services regulations.

Only Network Services are regulated by Network Services regulation. Tests implementented in the validator for the WMS are implemented based on Network Services Regulations.

ISDSS should not comply with the Network Service requlations as they are not network services.

@MarcoMinghini @michellutz

Therefore now the Network Services tests were relaxed for non-Network Services, which is not correct, unless the TG for SDS would be changed.

Please see below two pictures from SDS TG available at https://inspire.ec.europa.eu/id/document/tg/sds

I raised the issue regarding the SDS understandig which I do not like at all, but as it is now the TG, the proposed implementation would not be correct according to the SDS TG.

Only Network Services should be checked against view and download TGs that are for Network Services not for Invocable Spatial Data Services, that are based on other regulation.

Conformance Class is for View Services, therefore for Network Services, therefore should comply with Network Services regulations and TGs.

ISDSS should not be validated against the conformance classes that are for network services.

Therefore please revert to previous implementation.

Separate instances should exist for WMS/WFS, one for Network Services, that should be tested against conformance class for View/Download services and another WMS instance for ISDSS that should not be tested against those conformance classes that exist for Network Services.

Also it may be the case that one service comply to both NS and ISDSS TGs, but this case is not covered by the TG for SDS. I think would be just up to the data provider to declare in the metadata if that service is a NS or an ISDSS.

Iurie

[fabiovin]

Dear Iurie,

thank you for your analysis, I think using the abbreviation ISDSS you are referring to Spatial Data Services that are not Network Service, it is right?

Because the abbreviation ISDSS stands for "Interoperability of spatial data sets and services". So, it is used for referring to the related implementing rule: [INS ISDSS] Commission Regulation (EU) No 1089/2010 of 23 November 2010 Implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services and its amendments.

The solution implemented for this issue regards the Network Service - WMS and it relaxes the test related to the Implementation Requirement 39. If the WMS contains only harmonised layer names the test passes otherwise it passes with a manual check.

Do you think this is not correct?

[iuriemaxim]

Indeed trough ISDSS I refer to those SDS services that should be compliant with ISDSS IRs and TGs and that are not Network Services, so should not comply with IRs and TGs for Network Services.

I assume that WMS can be used for both services that comply either with NS IRs/TGs, either with ISDSS IRs/TGs.

Therefore, the question is if tose WMS services that need the rules to be relaxed, arent them services that should comply with ISDSS IRs/TGs and should not comply with NS IRs/TGs?

Arent the validations for View services conformamce class writen only for Network Services as those are view services according to ISDSS TG?

If those services are not Network services, why the validations for network services should be relaxed for allowing services that should comply with ISDSS IRs/TGs to be valid against conformance classes for Network Services?

I agree that ISDSS TG introduce confusions as an TG that was initially writen by having data in mind was trasnformed into a TG for services. Probably separate TGs should exist for services and data, as some services are compiant and data is not compliant and viceversa.

It is also quite strange that invicable SDS that were at the begining WPS become something else and that the ISDSS TG is mentioning that services are either regulated by NS or by ISDSS. What about those services that comply with both NS and ISDSS?

[iuriemaxim]

Maybe one solution would be to input the URL of the metadata of the service rater than the request to the WMs service

If the service would be declared in the metadata that is a Network Service, than it should comply with the rule and an error should be triggered if the name of the lyer is not compliant.

If the metadata of the service ondicates that the service is not an Network service (by usong the value “other”) then errors will be still trigered but the user would br informed that his service should not comply with Network Service TGs.

[iuriemaxim]

The scenario would be the following:

A data provider is sharing some maps trough a WMS. It does not matter what the WMS serves as the layer names will not be automatically checked and the portrayal of the layer will not checked. The only validation that is required would be to pass the OGC tests for WMS.

Would that WMS service be considered a Network Service? Should the tests be relaxed in such a way that a data provider would be able to serve anything via WMS? If layer name could be anything, what other tests exist that are indicating that the WMS is really an INSPIRE view service?

The validator is already used also by data users in order to see if the services provided by data providers are providing what it should be provided. Otherwise, by eliminating this test with the layer names, there will be no tool for data integrators, to see how many of the WMS are really INSPIRE ones and what services can be used to integrate EU data and which are just out of the scope of INSPIRE or are serving something else than what is required. If such test will be missing, then everything should be inspected manually.

As Internet is full of information and data, it comes more and more important not just to retrieve some information or data, but to retrieve good reliable data and information. Thats why standards are made. If these standards are relaxed to such a degree that any WMS would pass the automatic test, why standards are needed?

A similar scenario for ATOM:

A data provider is serving some PDFs compressed as a ZIP file within an ATOM service. Would that ATOM service be considered a Network Service as it will pass all the tests? Should the tests be relaxed or be already too relaxed to allow data providers to share anything trough ATOM? There were requests to add PDFs and PNG files as spatial data formats.

Hope this clarifies the situation, as I just see day by day how the validator is becoming more and more permissive, to such a degree that anything can be provided and such spatial data cant be integrated at the EU level or exchanged between EU member states. Many of the examples provided for relaxing the tests are indicating that those services are covering national needs and they comply with each country needs.

Iurie

[iuriemaxim]

In relation with the WMS service mentioned by @thijsbrentjens the layer names are:

cbsprovincies:bevolkingsdichtheid_inwoners_per_km2 cbsprovincies:ziekenhuisopnamen_klinisch_per_10000_inwoners

Neither the prefix of the layer names are indicating to which INSPIRE data theme is corresponding the feature type.

Neither the layers are following the rules to have DOT as a separator.

So is this a view service for an INSPIRE dataset?

Looking in the metadata of the dataset (that has wrongly encoded the data themes by using GEMET), the prefixes should be hh, su or pd, so the layer names should start with hh., su., or pd. Neither these were used.

I see no reason why the data provider could not comply with the Requirements from the Technical Guidelines.

[iuriemaxim]

@carlospzurita Please revert to the previous implementation and test the layer names.

[MarieLambois]

@iuriemaxim If you take the example from @Kate-Lyndegaard above the use case is clear. There is one harmonised layer with an harmonised layer name and one non harmonised because it is raster data so is not concerned by INSPIRE. Sometimes WMS can serve both INSPIRE dataset and non INSPIRE dataset. It is fully in the spirit favoured in INSPIRE currently not to have the INSPIRE infrastructured as something separate but to have it integrated with the data provider. In the European regulations, nothing prevent you from using your INSPIRE Network view service for something else. My experienced showed me that it is even rather common. If nationally you have additional constraint you can still add some tests in you validator instance.

(Also as a side answer to "It is also quite strange that invicable SDS that were at the begining WPS become something else and that the ISDSS TG is mentioning that services are either regulated by NS or by ISDSS. What about those services that comply with both NS and ISDSS?" you are mixing invocable service and invoke service I think. Invoke service finally appeared as not really useful at the end in the INSPIRE infrastructure. )

[iuriemaxim]

@MarieLambois

I just thought that the relaxation was required for services that should be conformant with ISSDS (those that are just invocable), but now I understand that the relaxation was required to validate non-INSPIRE services.

I did not took into account that INSPIRE infrastructure was built to serve non-INSPIRE datasets and services and therefore the INSPIRE validator should be relaxed in such a way to allow non-INSPIRE services and datasets to pass the tests.

But if so, at least they should be advertised in the metadata files as being non-INSPIRE services and datasets. INTERNET has a lot of resources. However it is difficult to find what you need. Now it become more ant more difficult to use INSPIRE infrastructure in order to find INSPIRE datasets and INSPIRE services. If this was the scope, than at least the IRs and TGs should be relaxed also.

My understanding is that if a services or is advertised that it is compliant with a certain regulation and guidelines, than it should be compliant to it. But I never thought that a data provider should advertise an dataset or service as beeing compliant with a certain INSPIRE Regulation and Technical Guideline, but actually to be a non-INSPIRE service.

It is not to difficult to have two WMS services, one INSPIRE compliant and another one just non INSPIRE compliant.

I am not sure that Web Processing Services are not useful. A position paper and a TG is found right here: https://inspire.ec.europa.eu/Technical-Guidelines2/Spatial-Data-Services/580. But for this a separate issue can be opened. Use of the word invoke with another meaning had a certain scope that unfortunately created confusion. So indeed I am confused, but lets first clarify why the validator should be relaxed to validate non-INSPIRE services.

[TDesjardins]

The test also fails when using group layers without a harmonized name. That means that layers can't be grouped for a WMS query because there are no harmonized name for group layers. Maybe it is better to check if at least one layer exists with a harmonized name than checking all layers.

[iuriemaxim]

@TDesjardins How does it looks a WMS request to view a certain layer from a group layer? Does it include the name of the layer group or not? Can you please provide an example of such a request?

[TDesjardins]

@iuriemaxim If you query a sub layer you only need the name of the sub layer not the one of the group layer.

The origin question is if it is forbidden/allowed to provide additional layers to the harmonized ones. Thijs Brentjens asked this question already:

what I meant: there may be other layers in a WMS, that are not harmonized. For example a WMS offering all mandatory harmonised layers and some other layers of the same dataset (e.g. grouped layers). Is such a mixture of Layers not allowed per the TG or the IR? In other words: do you mean that a WMS is allowd to exclusively offer harmonised layers (following all requirements from the IR etc)?

[iuriemaxim]

@TDesjardins If the name of the group layer is not part of the request then it is enough just not to check the group layers name, but only the names of the layers. I do nor think that the proposed solution to check only one layer name or not to check any layer name could be a solution that will ensure interoperability. Most probably if the group layer is not part of the request, the validator could skip the validation of the group layers names. But I do not think that to skip the validation of the layer names should be allowed according to the requirements for view services. INSPIRE infrastructure is not just for humans, but especially for machine-to-machine interaction. So harmonisation is important, otherwise it will not be possible to create applications based on INSPIRE services,

[iuriemaxim]

what I meant: there may be other layers in a WMS, that are not harmonized. For example a WMS offering all mandatory harmonised layers and some other layers of the same dataset (e.g. grouped layers). Is such a mixture of Layers not allowed per the TG or the IR? In other words: do you mean that a WMS is allowd to exclusively offer harmonised layers (following all requirements from the IR etc)?

Yes If the WMS is declared as being an INSPIRE view service, then it should comply with INSPIRE View TG.

Othervise, it can be declared as "other" service, that is not a Network service. Those WMS services should not comply with Conformance Class: View Service - WMS. The conformance class is not for WMS, but for View Services (Network services).

Those WMS that were not designed according to TG for view services, are not network services, so they are Invocable SDS, which by 10 December 2021 should be interoperable, or harmonised (where practical).

"All invocable spatial data services shall be conformant with Annexes VI and (where practicable) VII of Commission Regulation (EU) No 1089/2010 as amended by Regulation (EU) No 1312/2014 of 10 December 2014 (...) as regards interoperability of spatial data services"

[TDesjardins]

@TDesjardins If the name of the group layer is not part of the request then it is enough just not to check the group layers name, but only the names of the layers.

Agree. I think this is a good solution as long as there are no harmonized names for group layers.

I do nor think that the proposed solution to check only one layer name or not to check any layer name could be a solution that will ensure interoperability.

Fully agree, furthermore checking only one layer doesn't have a value.

Most probably if the group layer is not part of the request, the validator could skip the validation of the group layers names. But I do not think that to skip the validation of the layer names should be allowed according to the requirements for view services.

Agree!

INSPIRE infrastructure is not just for humans, but especially for machine-to-machine interaction. So harmonisation is important, otherwise it will not be possible to create applications based on INSPIRE services,

That's clear! It's especially for machine-to-machine interaction.

Thanks @iuriemaxim !

[iuriemaxim]

However it is interesting the post of @bgsmase related to group layers

We use group layers to provide the harmonised layer with other names for layers inside.

https://themes.jrc.ec.europa.eu/discussion/view/13952/layer-naming

[iuriemaxim]

@TDesjardins Please provide a link to the GetCapabilities of the WMS in order to see if the groups of layers are advertised in the GetCapabilities as a layer or as a group of layers. I searched in the WMS standard for the word ”group” with no luck.

[TDesjardins]

Simply said a group layer is a layer that contains other layers. If this layer has a name element you can query it. The result of the query then also contains the child layers.

From OpenGIS® Web Map Server Implementation Specification Version 1.3.0

Conceptually, each Layer is a distinct entity. However, as a means of classifying and organizing layers, and as a means of reducing the size of the service metadata, a single parent Layer may enclose any number of additional layers, which may be hierarchically nested as desired.

See also TG for View Services 4.2.3.3.4.11 CATEGORY LAYER

[iuriemaxim]

@TDesjardins Than if the validator cant see that a certain layer is a group of layer, it will check all the layers, including groups of layers. So names of the groups of layers should be harmonised as well. or they should not exist.

[iuriemaxim]

@carlospzurita As this is marked as "discution", but taking into consideration what was discovered within the issue https://github.com/INSPIRE-MIF/helpdesk-validator/issues/491 (Some basic questions about layers for Protected Sites theme - naming, type in WMS service), please let us know if this relaxation was actually implemented in the staging environment as it appears to be and any layer name is passing for any data theme.

[doemming]

• A reason why an INSPIRE-compliant WMS may not have harmonized layer names at all is that it provides only origin datasets.
• A reason why a harmonized layer can have sublayers that are not harmonized is that they are provided for additional use cases outside of INSPIRE. Both of these should be valid. Currently I see that the updated test on the staging system supports both variants, while the production system does not. Since this topic is still marked as discussion, I would like to provide this feedback and vote to move the current behaviour from staging to production.

[iuriemaxim]

@deoemming I understand your point. However if a WMS service is validated agains INSPIRE TG, then it should be reported as being valid against that TG if it meets all the requiremets stated in the TG. If a data provider creates a WMS that is provided for additional cases outside of INSPIRE, than there is no obligation for that WMS to be INSPIRE compliant. Of course it is fine to use two WMS endpoints, one that is used for being registered in the INSPIRE Geoportal and another one that is should not be registered in the INSPIRE Geoportal. European Users that are using services that are indexed in the EU Inspire Geoportal are expecting that those services to be valid against the INSPIRE TGs. If they are not valid against the INSPIRE TGs, than the users that are consuming those services should know that the service is not valid and here is the validator that indicates this. If the INSPIRE Services that are indexed in the EU INSPIRE Geoportal are not made according to TGs and if the validator is not indicating to users that the services are not made according to TGs, than the european users of those services cant to do much to properly consume those services. Harmonisation is crucial in order for users to be able to consume european data and to be able to merge data and services from multiple EU member states. If those services are used also for the national scope, then data providers should split the scope, as INSPIRE is for European users and for ensuring interoperability between Member States. Othervise why the TGs were writen and why rules exist if they could be avoided trough relaxation. We should remember what is the meaning of the INSPIRE letters and what it is stated in the INSPIRE Directive.

[akuckartz]

@doemming Are these WMS with sublayers that are not harmonized INSPIRE compliant?

[iuriemaxim]

I will try to give an example from our day to day life.

All of us go to supermarkets to buy food. There are certain food regulations that should be fullfiled by all food products, let say simillar to the OGC standards. However there are certain food products that are BIO and besides the OGC standards, they fulfill some other standards as well, simillar to INSPIRE standards.

Always the BIO products are labeled for consumers to know that they are BIO and are indicating trough labels the authority who certified that they are BIO (validator).

Even more, the BIO products are exposed in a separate place in the store, in order for the users to be easier to go directly there and to pick them (EU Geoportal).

Now imagine what you and other coleagues are asking:

1. You have some products that are almost BIO, but no authority is certifying them that they are BIO, as they are just almost BIO.
2. You want to expose the BIO products altoghether with all the other almost-BIO products.
3. You wany to relax the rules that are applied to BIO products, because there are many consumers that are interested in almost-BIO and non-BIO products and you want to keep them in your store. As a consequence, is asked to be no difference between BIO and non-BIO/almost-BIO products, and to put a pseudo-BIO label on both BIO and almost-BIO products (because standard is relaxed).

Now a consumer enters in the store (could be even online) and is looking for BIO Milk. If he have somebody to ask, then proably somebody would tell him that some products are BIO and some other are almost-BIO, and if he wants BIO Milk, he need to test by himself all the milk products, to see which one is BIO. But in online store he has nobody to ask, so he is looking at pictures of 20 milk products trying to figure if that milk is BIO or not.

After 10 minutes, the consumer is not able to figure if that store sells or not BIO Milk, or which milk is BIO and which one is not.

Lukily, the consumer has the choice to go to another online store which is well known for seling only BIO products. It takes him no more than 1 minute to identify the BIO milk products that has certain specific characteristics, by searching trough Metadata, view all these products and finaly pick one of them and leaving with it from the store.

Now, it is probably clear that if the European INSPIRE Geoportal will store BIO, almost-BIO and non-BIO products, then at least the consumer should have the tools to identify which are BIO and which are not.

If somone is selling packed products, like a bax that contains both BIO and non-BIO products, then that one could not be marked as beeing a BIO product.

Thats why is important not to pack BIO and non-BIO products toghether in the same bax. Imagine to buy a Christmas gift pack with BIO products, but some of them are not BIO, and still on the box is written "BIO products".

The relexation is required for the view services, those services that allows an user to see pictures of each milk products, in order to decide which milk is satisfing his demand, to clarify if he should pick it or not from the shelf.

[iuriemaxim]

@doemming Are these WMS with sublayers that are not harmonized INSPIRE compliant?

Neither OGC, neither INSPIRE defines the therm "sublayers". There are only layers. And there are styles applied to these layers.

Looking at the initial topic in the thread that points to https://geodata.nationaalgeoregister.nl/cbsprovincies/wms?&request=GetCapabilities&service=WMS service, neither the layers and neither the stiles are harmonised.

The WMS service is exposing a layer that has the non-harmonised name "cbsprovincies2012". Most probably this layer is of great interest for certain users from a certain country, but at least for an european user, the layer is meaningless, not understandable and a user could hardly guess to which INSPIRE data theme is related.

Those that traveled for example to China, Japan or other countries that are using alphabets that are not based on Latin letters or simmilar, most probably know that is even difficult to pick cow milk from a store, as it may be soy milk or almond milk. Actually there are more chances to pick soy milk than cow milk. Same is with the "cbsprovincies2012" layer for people outside that specific EU member state. And thats why INSPIRE Directive exist for harmonsing spatial data among member states in order to allow a european user to consume data from any other EU country.

So first of all the Validator should check if the resource is understabdable/usable by european users, so if it is harmonised. As the "cbsprovincies2012" layer name is not harmonised, a european user is not able to understand nothing from that layer exposed trough the view service, neither to use that resource. It may be a very useful resource for some users in that specific country, but this is not the case for european users. And INSPIRE is for EU users.

Therefore it would be a good solution to keep two national geoportals:

• one that serves the national users (which should not be INSPIRE compliant, but which can be almost INSPIRE compliant) and
• one that serves EU users and which is indexed in the INSPIRE Geoportal (which should be INSPIRE compliant).

If there will be EU users interested to access data that serves national users, they should go to the national geoportal, not to the national INSPIRE geoportal.

With the current technology is quite easy to index metadata from several national geoportals if a user needs data from different national geoportals that are not serving INSPIRE datasets or which are not fully INSPIRE Compliant.

But the EU INSPIRE Geoportal should provide access for EU users to EU INSPIRE services and datsets and if they are not INSPIRE compliant, than the user should know this, not only from the declaration made by the data provider within the metadata.

The Validator is the only authorithy to determine if a dataset and service is INSPIRE compliant or not. If it says that is compliant, than an EU user understands that is harmonised and can be understood and used. As it is proposed, the "authority" says that the service is compliant, but in reality an EU user cant do nothing with the data served by that service, because it is unable to understand. And this is valid for both humans that cant understand to much and even more for machines, that cant understand anything. And INSPIRE is more designed for machine-to-machine information exchange and this is becoming more and more the current trend due to many reasons.

[doemming]

@iuriemaxim, thank you very much for your detailed explanations.

I can understand your point of view and I would also like to emphasize that I think we totally agree that consumers and providers of INSPIRE services need clear guidance on what is compliant and what is not. That is why the discussion on details is so valuable.

I will use the abbrevations INS-NS and INS-DS as defined in the related TG in the following.

Let me explain my perspective:

According to Article 1 of the INSPIRE Directive, "Inspire shall build upon infrastructures for spatial information established and operated by the Member States". In this sense, we should avoid, if possible, setting up different endpoints for INSPIRE and other use cases. I brought Figure 2 (ogc/inspire puzzle) to the TG once to illustrate this idea for the OGC context.

Good architectural rules create interoperability for multiple use cases without interfering with each other.

The concept of harmonized level name is one such mechanism that creates interoperability for INS-DS use cases, because from a collection of arbitrary layers, consumers can - by evaluating whether a layer name is harmonized or not - uniquely identify (and possibly filter) those layers that are provided in compliance with IR-DS. Users can always consume harmonized layers only if they wish without interfering with the others.

The confusion we have currently is caused by the fact that the current test confirms interoperability with both regulations (INS-NS and INS-DS) only, while in practice there are services on the one hand, are compliant only with INS-NS and on the other services that are complient with both. This clearly does not fit.

If you look closely at the requirements in the TG, you will see that it is possible to distinguish which requirements arise from INS-DS. E.g. Req#39 and several others explicitly refer to the INS-DS regulation.

Tests are so important because they provide clarity where the standards leave room for interpretation.

Resolving the presented conflict by an update of the current production test is absolutely necessary as it currenty refuses to confirm conformance to INS-NS. Note that the TG explicitly targets on INS-NS (see introduction, first sentence).

A clean solution to solve with this type of problem is to define separate conformance classes like this: Combine the tests/requirements that confirm conformance to INS-NS into one mandatory conformance class. Group the other tests/requirements that confirm conformance with INS-DS into another optional conformance class that will be executed on harmonized layers only.

Services that pass the first class only should declare conformance to INS-NS in their metadata. Services that in addition pass the second class shall declare their conformance to INS-DS.

@akuckartz

Are these WMS with sublayers that are not harmonized INSPIRE compliant?

These WMS can be fully compliant with INS-NS. Please note that a provider may still be obliged to provide INS-DS compliant services/layers, but this depends on other things.

[fabiovin]

Dear all,

thank you for your valuable comments.

We think that the decision took some time ago whose solution is already implemented in staging, i.e. - if the WMS contains only harmonised layer names the test passes otherwise it passes with a manual check -, is the most appropriate.

There are other reasons in support of this decision, in addition to those already expressed in previous comments, for example:

• For spatial data theme “Population Distribution and Demography” no layers are defined by IR, so any layer can be defined by data providers.

• For the spatial data theme “Area Management / Restriction / Regulation Zones and Reporting Units” the layers required by IR are all those following the rule AM.<'CodeListValue'> and the related codelist is ZoneTypeCode (https://inspire.ec.europa.eu/codelist/ZoneTypeCode) which is an “open” codelist. So, data providers may define additional values for this codelist and then provide the related WMS layers.

Considering these cases, we cannot limit the check of the WMS layers only to those defined by IR and available in the INSPIRE Registry.

I hope this can clarify the decision to relax the test.

[iuriemaxim]

Dear @doemming I understand the point. However the example provided by @thijsbrentjens

, namely https://geodata.nationaalgeoregister.nl/cbsprovincies/wms?&request=GetCapabilities&service=WMS

does not include both harmonised and non-harmonised layers. Therefore for a user searching in the INSPIRE Validator and using the INSPIRE Validator it is a process of searching in thousands of services in order to find few that can be used. I still remember Yahoo and Altavista search engines.

But definitely tour explanation is very good and comprehensive, just that the implementation was not made according to it. I included a separate post on INS-DS and INS-NS below.

@fabiovin As the test passes with a manual test, is not really a solution for users that are searching for INSPIRE services created according to INS-DS TG. Of course they will find 99% non harmonised layers by parsing thousands of services and only 1% would be usable. Of course that if sharing any data and services, including the ones that are not compliant to the INSPIRE TG is the scope of INSPIRE, than the validator is inline with this. But if the scope is to create standards in order for EU Member states to share and consolidate data at European level, than the proposed implementation is not helping at all.

This is simmilar to the fact that we agree to share numbers with decimal point as separator, but still if someone provide numbers like texts ">10.1", the validator still will not give an error and we agree that they should be manually checked even if they obey the rule. People that know IT, will know that ">10.1" cant be considered a number and cant be stored as a number in a database, but many people will just see that ">10.1" is a number, so the rule can be relaxed. I worked with biologists that submitted to EC numbers in XML files such as "10-20", "less than 10" or even "unknown". What will then do the IT people which thought that the standard that was published will be respected ?

So unfortunately I cant agree with @fabiovin with the decision that contradicts the TG. If the TG is wrong, at least modify the TG, but we should know which is the standard in order to base ourselves on something.

The fact that "Inspire shall build upon infrastructures for spatial information established and operated by the Member States", this can be done even if two instances are created. And I do not think that this should allow us to interpret that if our national infrastructure shares data as shapefiles trough an FTP server, than this is it, and INSPIRE should live with this and all validator rules should be relaxed because the existing infrastructure offers just shapefiles. Also the sentence "Inspire shall build upon infrastructures for spatial information established and operated by the Member States" is not indicating that the EXISTING infrastructure should be used. The sentence is actually mentioning that INSPIRE is a shared infrastructure accross Member States, or more exactly across data providers from Member States. I think therefore that the sentenece is just taken from the context.

@fabiovin If realy there is a point that non-harmonised layers should pass the test, here I agree with @doemming that separate conformance classes can be created. This is just to find a compromise as still the TG requirements will not be met. At least users should be able to validate the services (and I mean not their services, but services that exist in INSPIRE Geoportal) against the TG, or against a relaxed test was required by some users in order not to change their infrastructure. Me as data consumer, I prefer to find usefull data that comply to rules, rather than have access to a search engine that provides thusands of data and services with few of them being of interest for an european user. Maybe they are usefull for that particular country, but as they are not harmonised they are of zero interest to a user from another country.

If we are creating an European Infrastructure just because there is an obligation and we are not looking at the data quality and at the european user cases, than the entire infrastructure role becomes useless. It will just serve users from a specific country to find resources from that specific country, but will not serve european users to seach european data, neither will allow users to aggregate data at the european level. I still think that the second letter from EU acronim has a point here.

Related to INS-NS and INS-DS as raised by @doemming, here is another big issue that was subject of many topics in the validator and questions without an answer, as the INS-DS IRs from 2010 as later changed in 2014 is not covering only data, but also services (SDSs). It played also with invoke vs invocable therms and create a huge confusion. Finally if I understand well the scope is to create harmonised datasets according to INS-DS served by services that are fulfilling INS-NS rules and not to create datasets that are not compliant with INS-DS (i.e. shapefiles) but are served by services that are fulfilling the INS-NS rules (i.e ATOM) or datsets that are compliant with INS-DS (i.e. GML) but served by services that are not compliant with INS-NS rules (i.e. FTP). If we can clarify that according to INSPIRE IRs, by the end of 2021, a GML can be served via an FTP service and a shapefile can be served via an ATOM, than it will be more clear this incident as well.

[iuriemaxim]

@doemming As I see that you understand the difference between INS-DS and INS-NS, can you please have a look if you can reply at these questions as according to your explanation the present incident is related to them:

https://github.com/INSPIRE-MIF/helpdesk-validator/issues/410 - What is the difference between Invocable-Interoperable-Harmonized Network Spatial Data Services?

https://github.com/INSPIRE-MIF/helpdesk-validator/issues/362 - Question related 10 December 2021 milestone

https://github.com/INSPIRE-MIF/helpdesk-validator/issues/361 - Question related to 21 October 2020 milestone

[iuriemaxim]

@fabiovin

You mentioned that <<There are other reasons in support of this decision, in addition to those already expressed in previous comments, for example:

For spatial data theme “Population Distribution and Demography” no layers are defined by IR, so any layer can be defined by data providers.

For the spatial data theme “Area Management / Restriction / Regulation Zones and Reporting Units” the layers required by IR are all those following the rule AM.<'CodeListValue'> and the related codelist is ZoneTypeCode (https://inspire.ec.europa.eu/codelist/ZoneTypeCode) which is an “open” codelist. So, data providers may define additional values for this codelist and then provide the related WMS layers.>>

In this context, it is very easy to implement the test for harmonised layers that are starting with "AM." and with "PD." to be accepted without taking into consideration the characters that are followed after "AM." and "PD." instead of making a Manual Test that will not allow users to find that services such as https://geodata.nationaalgeoregister.nl/cbsprovincies/wms?&request=GetCapabilities&service=WMS are actually not compliant, because the names of the layers are not harmonised.

The explanation provided is not a reason for relaxing the test as very simple implementation exists to cover the above considerations: LIKE "AM.%" and LIKE "PD.%".

I executed the test on staging environment for https://geodata.nationaalgeoregister.nl/cbsprovincies/wms?&request=GetCapabilities&service=WMS

This is the result

The text is indicating that the layer names should be harmonised. This is inline only with the consideration made by @fabiovin, but is not at all inline with the considerations made by others. The layers from the tested service are clearly not harmonised and they can be easily verified that are not harmonised. Why a service that should fail the test is actualy not failing it as the test can very easy check this.

Neither the prefix "cbsprovincies:" is between the ones that should be used (To which data theme it corresponds?). Neither ":" is correct as the dot "." should be present. So everything is wrong, but still the user is required to manually check something that is clearly wrong and that can be automatically checked easy.

Indded this manual verification can be done if the layer names are starting with "AM." or with "PD.", otherwise the test should fail, but ... :

However the TG for AM is providing a full list of harmonised layer names, while @fabiovin just mentioned the IR. If the list is not complete, at least for the ones that are already defined no manual test should be triggered if the user is providing exactly those ones. How the code-listst should be extended is another story, but I will not open this pandora box on this topic.

Regarding "PD." the TG is actually not indicating a Portrayal as <<The unique object defined in the “Population Distributions – Demography” guidelines, StatisticalDataDistribution is not a spatial object so there is no direct portrayal of it.>> Therefore my understanding is that no view service should exist for PD. If I am not wrong and I rembember well the view service would be for Statistical Units in this case, so in this case "PD." should not even be accepted for harmonised names of layers.

I am starting realy to think that there are other interests for not triggering such errors and finding such workaround "solutions" that have no real basis.

From all issues that I saw related to the validator, and I saw quite many, this is by far the strangest explanation and the worst proposed implementation, which somehow denotes that the reason of not trigerring errors for non-harmonised layers is not the one that is presented as consideration for the chosen implementation.

I am asking to reconsider the decision as this is clearly not correct at all. Such solutions should never be implemented.

If manual tests should be implemented, then should be implemented only where is not possible to test automatically, However the text provided in the manual test is not indicating a test that cant be made automatically,

If separate Conformance Classes would solve the problem, then this is the way to go. If something simmilar to the linkage checker should be implemented, than this is the way to go.. But definitly the proposed implementation is not.

[hogredan]

Dear all,

let me step into the discussion to get some more clarity on the topic. I think there is a fundamental difference of understanding here about requirement 39 of the TG View Services:

Implementation Requirement 39: Name shall be mapped with the element. The harmonised name of a layer shall comply with the Layer requirements of the [INS DS, Article 14]

We in Germany interpret the requirement in a way that only IF a view service provides harmonized data sets, THEN the layer names shall be harmonized and shall comply with the requirements of INS DS, Article 14. This opens the possibility that a view service does not provide harmonized data sets (or both) and is still compliant to the TG View Services. From our point of view this interpretation is in line with the INSPIRE Directive as @doemming already explained before.

If I understand you @iuriemaxim correctly, you interpret the requirement in a way that ALL view services only provides harmonized data sets and therefore ALL layer names shall be harmonized and shall comply with the requirements of INS DS, Article 14.

Thus, the requirement might be formulated more clearly.

However, the proposal of @doemming to have two separate confomance classes would be the best solution to go forward and to get more clarification on the "compliance level" of view services.

[iuriemaxim]

@hogredan First I would look at the INSPIRE Roadmap, here https://inspire.ec.europa.eu/inspire-roadmap/61 We are now at the begining of 2021, so there is still one milestone for December 2021. As time is short, I would asume that some Member States are already prepared to comply by that milestone, so I would asume for the current discussion that some data providers already comply with all the requirements of the IRs based on the INSPIRE Roadmap.

I am looking that for View services the deadline in 2011 was to have them operational and compliant with INS- NS. Of course that in 2011 there was no obligation regarding the data and of course that the INS-NS did not included any mention to this. The legislation is always interpreted in the time context and should be always interpreted in time context.

From 2011 other 10 years already passed with many other milestones, such as:

Or in graphic format here https://inspire.ec.europa.eu/road-map-graphic/32443

Therefore, I assume that in 2021, Data Providers from Member States are complying with some, if not even with all these and are even prepared for the 2021 milestone. If not, than my understanding is that they are 6 years back towards INSPIRE implementation.

Now, in 2021 ...

As the 2020 milestone passed, I assume that data providers from the Member States should have all the datasets compliant with provisions of INS-DS. If so, the datasets should be accessible trough view and download network services and discoverable in the European INSPIRE Geoportal. My understanding is that INSPIRE datasets should be also linked with their view and discovery services trough metadata and trough extended capabilities of the GetCapabilities requests in order to be discoverable and correctly indexed. This was/is checked by the INSPIRE Linkage Checker (https://inspire-geoportal.ec.europa.eu/linkagechecker.html).

The datasets should be composed by features from INSPIRE Data Themes. No other features are expected or allowed (INSPIRE Directive art. 4). Because of this, of course that the view services will serve these INSPIRE features from INSPIRE Data Themes (same article 4 of the INSPIRE Article states this) and they should be compliant with the Portrayal Section of the DS, so the layers should be harmonised.

In order to implement the 2020 milestone data providers have only one choice to create INSPIRE view services: the WMS should be used. And the WMS should be compliant to INS-NS.

Now assuming that somebody just have a WMS serving some features that do not comply with the INS-DS as it is the example from @thijsbrentjens. Clearly that service is ok for the 2011 milestone. But it is ok or not in 2021, as the 2021 milestone passed ?

As the data provider created that WMS, it means that it has a dataset. And according to the milestones, that dataset needed to comply with the INS-DS by 2020 milestone. So till October 2020 the data provider had no legal obligation to make that dataset compliant, so it was no problem just to index that WMS into the INSPIRE Geoportal.

But now, in 2021, I interpret that the data providers have the obligation to transform their data according to INS-DS. And if so, the layers from the WMS should be harmonised.

If I look now at the text that is written in the INSPIRE Validator for those WMS layers that are not passing the harmonisation text it is written "Please check manualy that EVERY layers have harmonised names":

If I missing something, or if I have a wrong understanding, please clarify. In any case the text in the Validator is clearly indicating that ALL LAYERS SHOULD BE HARMONISED. If this is not the requirement of the INSPIRE Directive and the subsequent Implementing Rules and Technical Guidelines, than the text in the validator should first of all be changed or as I mentioned, this pseudo-fix should not be implemented as it is just producing more confusion to both INSPIRE data providers and INSPIRE users.

[iuriemaxim]

Now looking into the legislation at the root, in the INSPIRE Directive.

Article 4 states that the Directive cover spatial data themes that relate to one or more of the themes listed in Annex I, II or III and also covers the spatial data services RELATING to the data contained in the spatial datasets reffered above.

I think than that my interpretation is legally correct, that if a service is not related to the spatial data themes listed in Annex I, II or III, then that service is not covered by the INSPIRE Directive. And if so, it shuld not be validated against the INSPIRE Validator as it should not be indexed in the INSPIRE Geoportal.

Paragraph 3 of the article 4 is clear enough in relation to services such as the one from @thijsbrentjens. Is that view service with non-harmonised layers related to spatial data sets related to one or more data themes from Annex I, II , or III ? Suposing that the answer is no. Than, according to paragraph 3 of the article 3 that service is not covered by the directive. Suposing that the answer is yes. Then the dataset/datasets served by that service should comply with IR-ISDSS by October 2020 and subsequently the data should be rendered in the view service according to the Portrayal section of the DS and the layer names should be harmonised.

Paragraph 3 of article 7 of the INSPIRE Directive has provisions not only for spatial datasets but also for their CORRESPONDING services

The Directive is explicitly mentioning that the corresponding services should be compliant with the provisions that should be adopted no later then 15 May 2012 as the 2020 milestone comes from point (b) of article 9 of the INSPIRE Directive:

Ok, this means that it is not related to the Commision Regulation 976/2009 regarding network services, as this was adopted three years prior to May 2012 and it is refered in another article. Also the articles 7 to 9 are part of INTEROPERABILITY OF SPATIAL DATA SETS AND SERVICES.

So the Directive asked for the adoption of provisions for the interoperability of the spatial data sets and for their corresponding services. And suplementary provisions for ensuring interoperability of the services corresponding to the spatial data sets were included in the Data Specifications, as for the view services, this is covered by the Portrayal section.

And thats why the Network services, both the download and view services were suplemented with more provisions trough the IR for INTEROPERABILITY OF SPATIAL DATA SETS AND SERVICES.

The text of the Directive did not mandated explicitly the European Commsion to issue an update of the Network Services Regulation, but rather to issue a new regulation for INTEROPERABILITY OF SPATIAL DATA SETS AND SERVICES. And according to the provisions of the INSPIRE Directive, this is extending the provisions of the Network Services Regulation in order to ensure their interoperability. Interoperability between WMS is made trough harmonised layer names and styles that are defined in the new IR.

The mandate of the European Commission for Network Services is written in the Article 16 of the INSPIRE Directive. Once the mandate was fullfiled, the Regulation for Network Services was not anymore updated as new rules were set in another regulation.

The fact that a view or download service should either comply with the Network Services Regulation or with the INTEROPERABILITY OF SPATIAL DATA SETS AND SERVICES Regulation had some sense according to the Directive only until October 2020. From that point, as the obligation entered into force for all datasets related to one or more themes from any annex, this cant be sustained legally anymore. INSPIRE Directive is not allowing data providers from Member States to provide view or download services after October 2020 if they are not RELATED to interoperable spatial data sets.

Also relevant to this topic is the Article 3 point 8 that is stating:

<<‘Inspire geo-portal’ means an Internet site, or equivalent, providing access to the SERVICES referred to in Article 11(1);>>

According to article 11(1) and according to article 4, those services should be related to data related to one or more of the themes listed in Annex I, II or III.

No subsequent legislation, such as Commision Regulations should have articles that are contradicting, restricting or enlarging the provisions of the Directive. If any exist, then they are null.

The preambul of the Directive is also important as it describes the intention of the legislator and why the Directive was issued. Altrough there are many relevant, here is one of them

And neither the validator should contradict the INSPIRE Directive. Currently the proposed implementation is just playing around, admitting that only harmonised layers should be provided trough WMS, but making manual a test that can be automated, just in order to allow WMS services that are not compliant with TG, IR and Directive, to pass the tests. I cant figure why so much effort was put in order to obey the rules, but I can just guess and this is not ok.

[kodebaets]

At the moment we (Digitaal Vlaanderen - Flanders, Belgium) publish harmonised datasets by WMS containing only harmonised layer names. An exception is made for Priority Datasets, which are reported as-is.

However, we do presume that it should be allowed for a WMS to contain both INSPIRE datasets and non-INSPIRE datasets. Associated non-INSPIRE data could prove to be beneficial to the end user.

[fabiovin]

Dear all, thank you for your comments.

I think the main question is if, according to Article 14 of “COMMISSION REGULATION (EU) No 1089/2010” and the related “Implementation Requirement 39” of the “Technical Guidance for the implementation of INSPIRE View Services”, a view service shall contain ONLY harmonized layer names OR it could contain ALSO additional layers (e.g. those recommended by TGs or layers related to the not-harmonized dataset).

It seems that most of you are agree with the second option.

As the last milestone passed (21/10/2020 - All spatial data sets shall be conformant to IR-ISDSS and available through network services) it could be assumed that at least one layer, with its harmonised name, shall be present in the WMS.

According to this assumption, the validator shouldn't raise an error if at least an harmonised layer is present and skip the check about the others. If there is no harmonised layer an error will be raised.

For layers whose name depends on open/empty codelist (e.g. AM.<'CodeListValue'>), the validator could check that at least one layer starts with the two-letter code (e.g. AM.). The involved data themes are AM, GE, NZ, PD, PF, SO, US.

We are going to implement this solution in staging in order to test it.

[iuriemaxim]

@fabiovin Thank you for understanding and for mitigating the incident.

Regarding non-harmonised layer names that will not start with the "XX" followed by a dot ".", where the "XX" is the prefix used for the Data Theme, I assume they will not be accepted, as it will mean that the daatset that is viewed trough that layer is not in the scope of INSPIRE, isnt't it? This is because the features from the dataset for which the view service is created will appear not to be part of a data theme listed in the annexes of the Directive. And this would be against article 4, paragraph 1, letter d) of the Directive, which I already listed in previous posts.

I do not expect a non-harmonised layer entitled "cbsprovincies” and stiles such as "cbsprovincies:ziekenhuisopnamen_dag_per_10000_inwoners" too pass the test if the WMS will also serve harmonised layer names like for example ”PS.ProtectedSites”.

If the ”cbsprovincies” is actually falling in the scope of one data theme, namely I could guess it is related to Administrative units, at least the data provider should present the layer name as ”AU.cbsprovincies” and the styles as ”AU.cbsprovincies.ziekenhuisopnamen_dag_per_10000_inwoners” with dots ”.” in between (there are two dots at least), not with semicoln ”:”. In this way at least the minimal rules are checked and the users will be also able to figure to which data theme that layer coresponds (as it should corespond to a data theme).

But if layers such as ”PS.MyNationalProtectedSitesCategory” should be present toghether with the ”PS.ProtectedSites”, could be a good compromise.

[hogredan]

Dear @fabiovin ,

this solution doesn't correspond to our (DE) legal understanding of the implementation of the INSPIRE Directive.

In our opinion a dataset can relate to one or more themes of Annex I, II or III, but can't be made available according to the INSPIRE data model as this would require the collection of new data which is not required by INSPIRE according to Article 4 No. 4. Furthermore, after harmonisation data providers in Germany partly continue to provide as-is data sets in addition to INSPIRE-compliant data sets, because the as-is data sets often contain more information related to INSPIRE Annex themes that could be more suitable for one or another use case than the use of INSPIRE-compliant data sets.

Thus, a test for testing requirements of an INSPIRE view service should not contain test cases based on requirements of the interoperability regulation resp. data specifications.

We, in Germany so far have used the tests of the INSPIRE validator 1:1 in our national validator. For the current test of INSPIRE view services we have already considered to use a from our point of view corrected test in Germany, but we decided to wait for this discussion.

If the test is implemented like suggested,

• we will probably use a different test in Germany to check INSPIRE view service compliance.
• it would be not acceptable from our point of view to use it for INSPIRE monitoring to calculate the indicator regarding the conformity of view services.
• we are concerned that many data providers in Germany will mark their data sets as no longer INSPIRE-relevant and fewer data sets will be available in the European SDI.

[iuriemaxim]

@hogredan @fabiovin Exactly this is the subject.

The INSPIRE Directive clearly states that datasets that are not INSPIRE relevant should not be in the INSPIRE Geoportal. From the user perspective that is searching in the INSPIRE Geoportal is more difficult to find INSPIRE related datasets and services in a Geoportal that stores also non-INSPIRE related datasets and services.

This picture from TG is saying the same

There is no single sentence in the INSPIRE Directive which could indicate that datasets or services that are not relevant to INSPIRE Directive should be in the Geoportal or that they should be validated with the validator. As the validator is an INSPIRE Validator and not an OGC validator, it should not contradict the text of the INSPIRE Directive.

If users want to test their WMS against the OGC WMS tests, they can use the OGC validators.

INSPIRE Geoportal should not be just a collection of OGC WMS services and OGC WFS services that serves data that is not relevant according to INSPIRE Directive

So each member state should actually implement the INSPIRE road-map and not just to comply with the requirements that were set for the 2016 milestone. Otherwise we should be prepared for NGOs making claims to the EC and subsequently to the European Court of Justice, as it happened in case of many other European Directives.

But if the dataset is INSPIRE Relevant, then ...

@hogredan wrote: <<In our opinion a dataset can relate to one or more themes of Annex I, II or III, but can't be made available according to the INSPIRE data model as this would require the collection of NEW DATA which is not required by INSPIRE according to Article 4 No. 4.>>,

First the text of the article 4.4 is not about NEW DATA, but about NEW SPATIAL DATA. It states "4.4. This Directive does not require collection of NEW SPATIAL DATA In other words no other SPATIAL DATA should be collected. The text is not making any reference that the attributes of the spatial data should not be collected, adapted or transformed. (I wrote in capital letters just to be more visible, is not about the tone). And even ifd the attributes are missing the data models allows data providers to indicate the "NILREASON"/

Simplified it can be interpreted that no new geometries should be collected. Even attributes could be missing as the data models allows to provide the nil reason, The article 4.4 should be read in conjunction with the article 7.3 which provides more details regarding how articke 4.4 should be interpreted.

<<Member States shall ensure that all newly collected and extensively restructured spatial data sets and the corresponding spatial data services are available in conformity with the implementing rules referred to in paragraph 1 within two years of their adoption, >> ... this is related to 2015 milestone

<<AND that OTHER SPATIAL DATA SETS AND SERVICES STILL IN USE are available in conformity with the implementing rules within SEVEN YEARS of their adoption. Spatial data sets shall be made available in conformity with the implementing rules either through the ADAPTATION of existing spatial data sets or through the TRANSFORMATION services referred to point (d) of Article 11(1).>> this is related to 2020 milestone.

At the end of 2020 the deadline of 7 years expired. And exactly thats why the Directive alowed a 7 years interval, in order for the data providers to make their datasets and the coresponding services in conformity with the implementing rules EITHER TROUGH THE ADAPTATION OF EXISTING SPATIAL DATA SETS OR TROUGH THE TRANSFORMATION SERVICES.

And thats why the proposed implementation is just contradicting the legal text of the Directive, including, but not limited to the article 7, paragraph 3.