WMS Validation

[grigoriouelena]

Let's collect here all the issues that arise as regards the validation of the wms capabilities response.

The first one I am reporting is that the test failsfor the /Layer/Style/LegendURL/Format. The test requires the format to be application/xml when geoserver responds with format image/png. I have already asked the INSPIRE validator helpdesk here INSPIRE-MIF/helpdesk-validator#618, by replying to an existing issue.

[grigoriouelena]

Validation of the wms using the staging instance of the INSPIRE Validator

Resource that was tested:
http://beta.geoportal.ypen.gr/geoserver/aqd-wms/ows?service=WMS&request=GetCapabilities

• at47-getcapabilities-layer-style-legend-url:
  The test fails because the validator is expecting 'application/xml', but the defined legend format is 'image/png'.
  Looking at the test method, we can see that the rsponse should be a valid omage and not a specific format.
  To solve this issue, we can ask the inspire validation helpdesk for clarification or for correction to the test. Alternatively, we could check wheather we can make geoserver not publish the legend usl in the capabilities, since it is optional.

• at56-getmap-width-height-parameter:
  The test fails because the validator is expecting an ows exception when the request is sent withour width and heigh parameters. Our service thows a service exception instead, which we consider as valid. Other users have reported this to the validation helpdesk here. we are expecting this to be fixed.

• at69-language-default:
  The test fails because when a getcapabilities request is sent with invalid language parameter, the service does not respond with the default values of title and abstract.

• at70-language-response
  See details for the test here.

The failure of tests at69 & at70 are caused by geoserver's behavior. I have asked the community here for input.

[grigoriouelena]

Check if Geoserver 2.19.1 would pass the missing parameters test for GetMap operation

The idea of going back to geoserver 2.19.1 would be a solution, since the internationalization is not enabled, so the language tests would be succesful.

Remembering that version 2.15.0 that is used in the production geoportal today, failed only in the tests regarding the behavior of geoserver when some parameters of the getmap request are missing, I manualy checked the getmap response of a local instance of geoserver 2.19.1, in order to find out if its behavior - as regards the missing parameters in getmap operation - would be INSPIRE compliant.

If the "Strict CITE compliance" is checked, Geoserver throws a service exception when style and crs parameters are missing and also when the transparent parameter is invalid (eg transparent=zzz). If the version parameter is missing, Geoserver responds with an empty map. I am not sure if this responce is accepted by the validator as valid.

We should try it.

[kalxas]

Lets downgrade to 2.19.x to test

[grigoriouelena]

Using a recommendation we got from a colleague who has tested 2.19.x versions of geoserver, it seems that there is a bug in 2.19.2 so we could try 2.19.3.

@kalxas

[kalxas]

Option 1: Downgrade to 2.19.x from 2.20.x
Option 2: Rollback to 2.18.x and upgrade to 2.19.x

[kalxas]

GeoServer downgraded to 2.19.4 for testing

[grigoriouelena]

Version 2.19.4 does not seem to be suitable for our INSPIRE implementation, since it does not implement the WMS standard, as regards the missing VERSION parameter.
According to the WMS standard (and the INSPIRE view service TG) , when a getmap request is sent without the version parameter, the service should throw an exception. Geoserver responds with a map, so the service does not pass the validator test.

Let's test version 2.19.3.

[kalxas]

GeoServer downgraded to 2.19.3 for testing

[kalxas]

GeoServer downgraded to 2.19.1 for testing

[grigoriouelena]

Testing of the WMS Capabilities response (Geoserver 2.19.2 on beta.geoportal.ypen.gr)

Request tested: http://beta.geoportal.ypen.gr/geoserver/aqd-wms/ows?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetCapabilities

Tests that fail:
1. at04-getcapabilities-xml-schema-validation

Might be related to this but I am not sure.
I tried to validate the xml document using some free online tool (like https://www.freeformatter.com/xml-validator-xsd.html) It seems the schema is invalid. Its the first time this test fails for geoserver.

2. at50-getmap-version-parameter
The test fails because the service is receiving a GetMap request without the VERSION parameter and it responds with a map, while this parameter is mandatory, according to the standard. So the validator would consider this test succesful if the server returned an exception. Instead Geoserver's behavior is the following:

WMS 1.3.0 GetMap request WITH version parameter:
http://beta.geoportal.ypen.gr/geoserver/aqd-wms/wms?service=WMS&version=1.3.0&request=GetMap&layers=aqd-wms%3AAM.AirQualityManagementZone&bbox=33.2602917992464%2C18.2594706955248%2C41.7465936245625%2C30.1030588882255&width=768&height=550&crs=EPSG%3A4258&styles=&format=image/png

WMS 1.3.0 GetMap request WITHOUT version parameter:
http://beta.geoportal.ypen.gr/geoserver/aqd-wms/wms?service=WMS&request=GetMap&layers=aqd-wms%3AAM.AirQualityManagementZone&bbox=33.2602917992464%2C18.2594706955248%2C41.7465936245625%2C30.1030588882255&width=768&height=550&crs=EPSG%3A4258&styles=&format=image/png

When the version parameter is missing Geoserver responds by default with a WMS 1.1.1 response, but due to the difference in the axis ordering (see here for details), the browser shows a different part of the planet.

There is one more difference between the two versions of the WMS standard (1.1.1 and 1.3.0), the name of the parameter for the coordinate reference system. For WMS 1.1.1 it should be "srs" and for WMS 1.3.0 it is "crs". When Geoserver is requested using the WMS 1.1.1 version of the std, it responds with a map whether the parameter srs or crs is used. And to prove the above, check the following request and response:

http://beta.geoportal.ypen.gr/geoserver/aqd-wms/wms?service=WMS&version=1.1.1&request=GetMap&layers=aqd-wms%3AAM.AirQualityManagementZone&bbox=33.2602917992464%2C18.2594706955248%2C41.7465936245625%2C30.1030588882255&width=768&height=550&crs=EPSG%3A4258&styles=&format=image/png

the response is:

It responds with a map, but the bbox order is wrong.

If we change the bbox order, without changing the crc to srs,
http://beta.geoportal.ypen.gr/geoserver/aqd-wms/wms?service=WMS&version=1.1.1&request=GetMap&layers=aqd-wms%3AAM.AirQualityManagementZone&bbox=18.2594706955248%2C33.2602917992464%2C30.1030588882255%2C41.7465936245625&width=768&height=550&crs=EPSG%3A4258&styles=&format=image/png

the response is THE map (!)

So Geoserver, in order to provide a response to the user, even if the version parameter is missing when the WMS 1.3.0 is requested, it responds with the map in version 1.1.1. But it does not correct the bbox, so the map is empty because it shows another part of the globe.

I guess the above problem cannot be solved by reconfiguration.
Can we take a look on the xml schema issue?

[kalxas]

Just deployed GeoServer 2.20.1 with inspire plugin 2.19.1 for testing

[grigoriouelena]

New deployment testing

resource: http://beta.geoportal.ypen.gr/geoserver/aqd-wms/ows?service=wms&version=1.3.0&request=GetCapabilities

1. tool: INSPIRE validator (PROD) https://inspire.ec.europa.eu/validator/test-selection/index.html
validation report: wms_validation_production.html

Failed tests:

at04-getcapabilities-xml-schema-validation

related issues on the INSPIRE validator helpdesk:
• INSPIRE-MIF/helpdesk-validator#598
proposal for solution: This seems to be a problem of the geoserver 2.19.x inspire extension. I tried the following:
o found the relevant file WMSExtendedCapabilitiesProvider.class in the INSPIRE extension .jar file (..\org\geoserver\inspire\wms)
o used an online java decompiler (http://www.javadecompilers.com/ ) and got the following

Is it possible to edit this file and then put it back in the .jar package? If not, I could ask our colleague who reported the issue above.

at47-getcapabilities-layer-style-legend-url
Please see the attached validation report. There is no human-readable message.

2. tool: INSPIRE validator (STAGING) http://staging-inspire-validator.eu-west-1.elasticbeanstalk.com/etf-webapp/test-selection/index.html
validation report: wms_validation_staging.html

Failed tests:

at04-getcapabilities-xml-schema-validation
same message

at47-getcapabilities-layer-style-legend-url
There is a human-readable message

The issue was reported upstream here: INSPIRE-MIF/helpdesk-validator#680
I do not have any proposal to fix that
NOTE: The staging validator also tests GetMap operation, Link View Service Operation and the Language requirements.

3. tool: INSPIRE validator: local instance http://beta.geoportal.ypen.gr/validator/
validation report: wms_validation_beta.html
same as INSPIRE validator (PROD)

I propose to keep this deployment and try to fix whatever is possible.

Att:
validationReports.zip

[kalxas]

Switched to default configuration of GeoServer just to confirm the above is not a configuration issue.

[kalxas]

Updated to GeoServer 2.20.2 with 2.19.1 inspire plugin

[grigoriouelena]

New deployment testing with default configuration

resource tested: http://beta.geoportal.ypen.gr/geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities

Minimum configuration:

• check Strict CITE compliance
• limit SRS list (4258) in order to minimise the extend of the capabilities document
• enable the INSPIRE extension

INSPIRE validator (PROD)

Tests that fail:
at04-getcapabilities-xml-schema-validation
the test fails again, since the url of the schema location is not accepted, according to this.

I tried the following:

• saved a local copy of the capabilities response with correct schema location urls (http instead of https).
• Moved it to beta.geoportal.ypen.gr/atom/, so that the validator can access the file.
• Tested the resource
  Several tests fail, because of the fact that the validator is sending requests to a file (!), but the xml schema seems to pass the test.
  Validation report:
  localCapsValidation.zip

at39-getcapabilities-layer-name
Expected to fail, since the resource tested does not publish INSPIRE layers

at47-getcapabilities-layer-style-legend-url
same old behaviour

INSPIRE validator (STAGING)

As commented before, the staging instance of the validator tests other operations also (GetMap Operation, LinkViewService Operation, Language requirements). There are no fails with these extra tests.

As for the GetCapabilities Operation tests, the same tests fail (at04 for the xml schema and at47 for the legend url). The weird thing is that the layer name test passes (!).

[kalxas]

Updated InspireMetadata.class file in inspire jar, replacing https with http

[kalxas]

The file we need to change is https://github.com/geoserver/geoserver/blob/main/src/extension/inspire/src/main/java/org/geoserver/inspire/InspireSchema.java

[kalxas]

https://github.com/geoserver/geoserver/blob/main/doc/en/user/source/extensions/inspire/using.rst

"At the time of writing the INSPIRE Schemas only allow 23 choices for :guilabel:DefaultLanguage. The GeoServer INSPIRE extension allows some other languages to be chosen. If you choose one of these your capabilities document won't be Schema valid but, as discussed in :geos:issue 7388 <7388>, the INSPIRE Schemas seem to be at fault."

[grigoriouelena]

The file we need to change is https://github.com/geoserver/geoserver/blob/main/src/extension/inspire/src/main/java/org/geoserver/inspire/InspireSchema.java

Is it possible to give it a try?

[grigoriouelena]

https://github.com/geoserver/geoserver/blob/main/doc/en/user/source/extensions/inspire/using.rst

"At the time of writing the INSPIRE Schemas only allow 23 choices for :guilabel:DefaultLanguage. The GeoServer INSPIRE extension allows some other languages to be chosen. If you choose one of these your capabilities document won't be Schema valid but, as discussed in :geos:issue 7388 <7388>, the INSPIRE Schemas seem to be at fault."

Too bad that 2 of the EU official languages are left off of the extended capabilities schema. Fortunately, greek is not one of them, so choosing it, it wouldn' t cause a schema validation issue. Nevertheless, the reason why we did not use the internationalization is not the missing language code. The reason is that the extended capabilities section Geoserver adds to the capabilities response is wrong.

Correct Extended Capabilities (View Service TG v3.11)

Geoserver Extended Capabilities Section (https://github.com/geoserver/geoserver/blob/main/doc/en/user/source/extensions/inspire/using.rst#id71)

noted the wrong SupportedLanguage element.

[grigoriouelena]

New deployment testing with default configuration

resource tested: http://beta.geoportal.ypen.gr/geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities

Minimum configuration:

• check Strict CITE compliance
• limit SRS list (4258) in order to minimise the extend of the capabilities document
• enable the INSPIRE extension

INSPIRE validator (PROD)

Tests that fail: at04-getcapabilities-xml-schema-validation the test fails again, since the url of the schema location is not accepted, according to this.

I tried the following:

• saved a local copy of the capabilities response with correct schema location urls (http instead of https).
• Moved it to beta.geoportal.ypen.gr/atom/, so that the validator can access the file.
• Tested the resource
  Several tests fail, because of the fact that the validator is sending requests to a file (!), but the xml schema seems to pass the test.
  Validation report:
  localCapsValidation.zip

at39-getcapabilities-layer-name Expected to fail, since the resource tested does not publish INSPIRE layers

at47-getcapabilities-layer-style-legend-url same old behaviour

INSPIRE validator (STAGING)

As commented before, the staging instance of the validator tests other operations also (GetMap Operation, LinkViewService Operation, Language requirements). There are no fails with these extra tests.

As for the GetCapabilities Operation tests, the same tests fail (at04 for the xml schema and at47 for the legend url). The weird thing is that the layer name test passes (!).

requested other implementers' feedback as regards the failure of test at04, here

[grigoriouelena]

After revisiting the wms validation issue, I came accross the following, as regards the fixing of the missing &VERSION= parameter in the GetLegendGraphic request.

• https://osgeo-org.atlassian.net/browse/GEOS-10336
• [GEOS-10336]-INSPIRE failure: version not propagated in GetCapabilities LegendURL geoserver/geoserver#5572

@kalxas are we using the latest version of Geoserver? If yes, I should check if the inspire extension is causing the problem...

[kalxas]

Pull request merged on 2.20.x branch on Jan 27th:
geoserver/geoserver#5595
GeoServer 2.20.3 was released Feb 23
https://github.com/geoserver/geoserver/releases/tag/2.20.3

We have currently 2.20.2 in beta with 2.19.1 inspire extension.

We need to update GeoServer and the INSPIRE extension to 2.20.3

[kalxas]

GeoServer 2.20.3 now available in beta geoportal

[grigoriouelena]

Tested the new geoserver using the staging instance of the INSPIRE validator.
The problem ith the missing version parameter in the GetLegendGraphic url is fixed in the new version.

The use of the 2.20.3 inspire extension brings back the languages problem.

• If NO internationalisation functionality is used in the configuration of the WMS, 3/4 language tests fail (3/138 test steps in total)
• If the internationalisation functionality IS used, the tests that fail are 2.

We could probably try to solve the language requirements issues by using an older version of inspire extension, like we did before. I propose though to keep the current set up in order to avoid compatibility issues. Additionaly, the use of the older extension might cause other mulfunction.