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:

• 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

• 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

• 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 wms:Name 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.

[fabiovin]

Dear all,

the status of the issue is the following (many thanks to @hogredan for the explanation):

A proposed amendment to the TG View Service has been submitted into the governance process, which has already been approved by MIG-T and MIG, see INSPIRE-MIF/technical-guidelines#2.

In addition, another proposal has been submitted to add a new requirement to the TG for layer names for harmonised datasets, see INSPIRE-MIF/technical-guidelines#12.

Both changes are planned for the release 2022.2 (July 31), see https://github.com/INSPIRE-MIF/technical-guidelines/milestone/2.

Once the TG has been amended, the tests can be updated accordingly. The test related to the IR-ISDSS requirement could be added as a separated conformance class to the ETS for view services (similar to the way that this is being done for the metadata requirements for interoperability based on requirements in the IR-ISDSS).

In addition, the test had already been relaxed in the staging instance, but the change was not included in production due to the change required to the TG.

[fabiovinci]

Dear all,

the changes to the WMS TG have been released in the 2022.2 TG release.

The related changes have been introduced in the ATSs (see Abstract Test Suite: INSPIRE View Services Technical Guidance) and they will be implemented in the next release of the Validator.

[dperezBM]

Dear @thijsbrentjens,

The solution is available in staging instance. Could you check that it is correct?

Regards

PS: @fabiovinci Could you also check that it is correct?

[fabiovinci]

The solution is correct.
We can include the fix in the next release.