Test View Service, GetCapabilities_Operation AT04

[LarsAll]

Hi!

I'm running into an error with the schema validation for a View Service capabilities.

The error is as following:

""
Schema not valid: [org.xml.sax.SAXException: Fatal error: org.xml.sax.SAXParseException; lineNumber: 99; columnNumber: 40; cvc-complex-type.2.4.a: Invalid content was found starting with element 'inspire_vs:ExtendedCapabilities'. One of '{"http://www.opengis.net/wms":_ExtendedCapabilities, "http://www.opengis.net/wms":Layer}' is expected. Response did not validate against schema 'http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd'.]
""

And this is the service in question: https://testgeodata.naturvardsverket.se/geoserver/EURegistry/ows?REQUEST=GetCapabilities&SERVICE=WMS&VERSION=1.3.0

I am a little lost here, this is an new error that appeared after upgrading the Geoserver to a newer version (2.19.1), and to me it seems like the capabilities is OK. It is the exact same as an View Service on an older version of Geoserver, which validates OK for AT04.

Any suggestions?

[fabiovin]

Dear @LarsAll,

I had a look at your service and it seems that the namespaces related to the INSPIRE schemas are wrong, the URIs are in https and not in http.

xmlns:inspire_vs="https://inspire.ec.europa.eu/schemas/inspire_vs/1.0" xmlns:inspire_common="https://inspire.ec.europa.eu/schemas/common/1.0"

I validated a local copy of the WMS GetCapabilities Response substituting https with http and there are no schema validation errors.

[LarsAll]

Hi @fabiovin !

Thanks for the feedback. Easy as that then :-), I thought I did try that with a local copy of my own but probably missed something.

I'll get back with a reply here after sorting it out.

[grigoriouelena]

Dear @LarsAll ,

We came across the same fault with Geoserver INSPIRE extension v 2.19.x.
Did you manage to fix this? Would it be possible to share any experience?

Thanks a lot in advance!

Elena

[LarsAll]

Dear @LarsAll ,

We came across the same fault with Geoserver INSPIRE extension v 2.19.x. Did you manage to fix this? Would it be possible to share any experience?

Thanks a lot in advance!

Elena

Hi @grigoriouelena!

We never did get it to work with that particular version of Geoserver. However, the release of a stable 2.20.x came shortly after this and that fixed it (among other know validation issues so I strongly recommend if possible to move up to 2.20.x) so we moved on.

[grigoriouelena]

Dear @LarsAll ,
We came across the same fault with Geoserver INSPIRE extension v 2.19.x. Did you manage to fix this? Would it be possible to share any experience?
Thanks a lot in advance!
Elena

Hi @grigoriouelena!

We never did get it to work with that particular version of Geoserver. However, the release of a stable 2.20.x came shortly after this and that fixed it (among other know validation issues so I strongly recommend if possible to move up to 2.20.x) so we moved on.

Hi @LarsAll,

Thanks for replying!

We did upgrade to 2.20.x but unfortunately the new internationalization functionality is not compliant with the language requirements (tested with the staging validator instance).

We have documented all our testing here and here, if someone would like to have a look.

We also tried a workaround in order to be able to use the correct geoserver behaviour as regards the missing parameters responses using the 2.20.x version, and we installed the 2.19.1 inspire extension, where the language configuration is simpler and more correct (with no internationalization functionality). Unfortunately we came across the schema location problem.

Anyhow, I mentioned all the above in case someone finds it useful.

Thanks a lot for the feedback:-)