EOFarm / geoportal.ypen.gr

0 stars 0 forks source link

Extended Capabilities in GeoServer 2.20.0 include an extra SupportedLanguade tag #9

Open kalxas opened 2 years ago

kalxas commented 2 years ago

image

kalxas commented 2 years ago

Fixed by adding eng as supported language in the inspire configuration: image

kalxas commented 2 years ago

Linked to #7

kalxas commented 2 years ago

Virtual WMS still affected:

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

kalxas commented 2 years ago

Also fixed for virtual WMS, same configuration on the amaqd-wms workspace

grigoriouelena commented 2 years ago

What happens when the default language is not english?

grigoriouelena commented 2 years ago

What happens when the default language is not english?

The problem is solved when the i18n configuration is used to provide capabilities information in some default and some other supported language. In our case the default language is greek and the supported language is english.

grigoriouelena commented 2 years ago

Correct INSPIRE extended caps schema (TechnicalGuidance_ViewServices_v3.0)

http://discoveryService.... < inspire_common:MediaType>application/vnd.ogc.csw…. dut eng dut 1. same default and supported language When the default and other supported language is the same, the capabilities document omits the element /../inspire_vs:ExtendedCapabilities/inspire_common:SupportedLanguages/inspire_common:SupportedLanguage. Since the element is not mandatory, the validation is successful (at least as regards the schema validation). ![image](https://user-images.githubusercontent.com/55238073/139808925-127efcac-199d-4879-ba60-88031f4a91b7.png) ![image](https://user-images.githubusercontent.com/55238073/139808938-d1875384-7651-4a68-8d1d-2613141c2aa5.png) Relevant validation report: 1. wmsCaps_SameDefaultSupportedLang.html.zip 2. no other supported language When no other supported language is selected, the element /../inspire_vs:ExtendedCapabilities/inspire_common:SupportedLanguages/inspire_common:SupportedLanguage is present in the capabilities document but it is not correctly encoded. ![image](https://user-images.githubusercontent.com/55238073/139810364-eb42d028-b6c0-4234-9f5c-98b73b41c713.png) ![image](https://user-images.githubusercontent.com/55238073/139809772-485a3996-cdd0-49b9-bd9b-bbefbe353d45.png) The child element /../inspire_vs:ExtendedCapabilities/inspire_common:SupportedLanguages/inspire_common:SupportedLanguage/inspire_common:Language is missing so the schema validation fails. The validator returns the following message: Schema not valid: [org.xml.sax.SAXException: Fatal error: org.xml.sax.SAXParseException; lineNumber: 110; columnNumber: 48; cvc-complex-type.2.4.b: The content of element 'inspire_common:SupportedLanguage' is not complete. One of '{"http://inspire.ec.europa.eu/schemas/common/1.0":Language}' is expected. Response did not validate against schema 'http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd'.] Relevant validation report: 2. wmsCaps_noOtherSupportedLang.html.zip 3. different default and other supported language The desired configuration in our case is to provide different default and supported languages, using the i18n configuration for the internationalization of the capabilities response. ![image](https://user-images.githubusercontent.com/55238073/139810330-0eab0fc1-11fc-44c4-a815-91786bb55fa6.png) When this configuration is present, the capabilities response is again not correctly encoded. ![image](https://user-images.githubusercontent.com/55238073/139809516-80da5327-c2d7-4236-af6f-4b729b2be3f5.png) The relevant test fails for the schema validation. The error is Schema not valid: [org.xml.sax.SAXException: Fatal error: org.xml.sax.SAXParseException; lineNumber: 110; columnNumber: 85; cvc-complex-type.2.3: Element 'inspire_common:SupportedLanguage' cannot have character [children], because the type's content type is element-only. Response did not validate against schema 'http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd'.] Relevant validation report: 3. wmsCaps_difDefaultSupportedLang.html.zip Note #1: The i18n configuration does not affect geoserver’s behavior regarding the inspire extended caps. Note #2: The above testing was made for the following virtual wms http://beta.geoportal.ypen.gr/geoserver/aqd-wms/ows?service=wms&version=1.3.0&request=GetCapabilities [1. wmsCaps_SameDefaultSupportedLang.html.zip](https://github.com/EOFarm/geoportal.ypen.gr/files/7458907/1.wmsCaps_SameDefaultSupportedLang.html.zip) [2. wmsCaps_noOtherSupportedLang.html.zip](https://github.com/EOFarm/geoportal.ypen.gr/files/7458908/2.wmsCaps_noOtherSupportedLang.html.zip) [3. wmsCaps_difDefaultSupportedLang.html.zip](https://github.com/EOFarm/geoportal.ypen.gr/files/7458906/3.wmsCaps_difDefaultSupportedLang.html.zip)
kalxas commented 2 years ago

This might be the source of this issue: https://github.com/geoserver/geoserver/pull/5123

kalxas commented 2 years ago

My suggestion is to raise this issue upstream

kalxas commented 2 years ago

Reported upstream: https://sourceforge.net/p/geoserver/mailman/message/37379044/

kalxas commented 2 years ago

Update 08-11-2021: We agreed to not add extra languages in version 2.20 since this triggers the validator bug. Waiting for bug to be resolved upstream.

kalxas commented 1 year ago

Related: https://osgeo-org.atlassian.net/browse/GEOS-10852

kalxas commented 1 year ago

Related: https://osgeo-org.atlassian.net/browse/GEOS-10557

kalxas commented 1 year ago

Related: https://osgeo-org.atlassian.net/browse/GEOS-10411 and fixed here: https://github.com/geoserver/geoserver/pull/5725

kalxas commented 1 year ago

The code used to encode the language: https://github.com/geoserver/geoserver/blob/1668c7ca5e2922978dfc930002f91062831eed57/src/extension/inspire/src/main/java/org/geoserver/inspire/ServicesUtils.java#L71