search

INSPIRE-MIF / helpdesk-validator

Community discussion forum for INSPIRE validation issues
42 stars 23 forks source link

Conformance Class: Download Service WCS Core legit validator results ? #523

Closed apfelnymous closed 1 year ago

apfelnymous commented 3 years ago

Hello everyone, I tested my Inspire wcs and have got many failed tests which I cannot retrace. The most of them claim about wrong paths like:

The ExtendedCapabilities section shall be provided in the path: /Capabilities/OperationsMetadata/ExtendedCapabilities/ExtendedCapabilities

But if you look at my capabilities you can see that the path is there isnt it ? (wcs:Capabilities/ows:OperationsMetadata/ows:ExtendedCapabilities/inspire_dls:ExtendedCapabilities)

The used capabilities link is this one: https://geoportal.saarland.de/gdi-sl/inspirewcs?map=/home/lvgl/inspire_oi.map&SERVICE=WCS&VERSION=2.0.0&REQUEST=GetCapabilities

What am I missing ?

I added my tests results:

Test run on 13 40 - 11.03.2021 with test suite Conformance Class Download Service - WCS Core.html.zip

carlospzurita commented 3 years ago

Dear @apfelnymous

Thank your for opening the issue and providing all the info. We are taking a look at your WCS Capabilities. We will get back to you with more feedback.

apfelnymous commented 3 years ago

I got the same problem for the Conformance Class View Service WMS with the testurl:

https://geoportal.saarland.de/gdi-sl/inspirewcs?map=/home/lvgl/inspire_oi_wms.map&SERVICE=WMS&VERSION=2.0.0&REQUEST=GetCapabilities

All tests red, cant figure out why.

milanSch commented 2 years ago

Hello,
please, have you ever solved this problem?

I have similar situation. I am trying to publish WCS service using Geoserver 2.19.2 (and 2.20.0 too). Geoserver INSPIRE extension WCS service creates 'inspire_dls:ExtendedCapabilities' in different path compare to WFS service.

WCS; /wcs:Capabilities/wcs:Contents/wcs:Extension/ows:ExtendedCapabilities/inspire_dls:ExtendedCapabilities'

WFS: wfs:WFS_Capabilities/ows:OperationsMetadata/ows:ExtendedCapabilities

Validation of WFS is OK, but validation of WCS service using https://inspire.ec.europa.eu/validator/home/index.html - Download Service - Web Coverage Service (WCS) gives error:

'The ExtendedCapabilities section shall be provided in the path: /Capabilities/OperationsMetadata/ExtendedCapabilities/ExtendedCapabilities'

Is this problem of validator or Geoserver extension?

Thank you milan

KathiSchleidt commented 2 years ago

Hi Milan,

while I'm still chewing on other validation issues (AcceptLanguage), the following path utilized in the rasdaman implementation seems to fit what the validator expects: /wcs:Capabilities/ows:OperationsMetadata/ows:ExtendedCapabilities/inspire_dls:ExtendedCapabilities

Thus assuming that your issue is a glitch in GeoServer

milanSch commented 2 years ago

Kathi, thank you very much, I was happy to read your answer. I will wait for correction of Geoserver/inspire extension.

Geodeo commented 2 years ago

Hi, I'm having exactly the same problems as described by @milanSch .

If I look at the "Technical Guidance for the implementation of INSPIRE Download Services using Web Coverage Services (WCS)" the Geoserver Extension seems to be implementing "Example 10: inspire_dls:ExtendedCapabilities section in a scenario 1 response".
So I don't understand why the INSPIRE Validator would return "The ExtendedCapabilities section shall be provided in the path: /Capabilities/OperationsMetadata/ExtendedCapabilities/ExtendedCapabilities"

Any news or ideas by any chance?

KathiSchleidt commented 2 years ago

Hi all, sorry for forgetting to mention, we got the last kinks out of the rasdaman WCS implementation, I could validate the following service against the INSPIRE validator: https://inspire.rasdaman.org/rasdaman/ows#/services HTH! :) Kathi

milanSch commented 2 years ago

Hello,

@KathiSchleidt
Kathi, thank you for your notice. I see that your ExtendedCapabilities are placed in path /wcs:Capabilities/ows:OperationsMetadata/ows:ExtendedCapabilities so validator is satisfied and gives valid results. Your page looks very well and it is worth to think about using rasdaman definitely.

@Geodeo there is opened similar issue one year old, https://github.com/INSPIRE-MIF/helpdesk-validator/issues/660 and I asked about this problem here too https://gis.stackexchange.com/questions/415766/modify-replace-getcapabilities-response-geoserver-inspire-extension-wcs Problem is not solved yet.

milan

Geodeo commented 2 years ago

@KathiSchleidt @milanSch Ah, as I understand it correctly the INSPIRE validator expects the extension (the ows:ExtendedCapabilities element) as a child of /wcs:Capabilities/ows:OperationsMetadata. While Geoserver implements it as a child of /wcs:Capabilities/wcs:Contents/wcs:Extension.

Technically both seem possible and validate using e.g. XML Spy.

In the Technical Guidelines I cannot find anything about the correct 'location' of ows:ExtendedCapabilities, either as child of osw:OperationsMetadata or wcs:Extension. But to me it makes more sense if it would be a child of wcs:Contents/wcs:Extension as it describes among others information about the Metadata URL. That information doesn't seem to fit in a OperationsMetadata element (which describes the operations of a service).

I wonder if this is indeed a glitch of Geoserver, or it actually makes more sense to implements the extension as part of the wcs:Contents/wcs:Extension? So couldn't it also be a glitch of Rasdaman and the INSPIRE validator?

Anyway, as we are using Geoserver and not Rasmadan I might try to change the Geoserver extension implementation in order to have it validated.

KathiSchleidt commented 2 years ago

@Geodeo @milanSch If you look at the WCS TG page 32, 5.1.1.2 Publishing INSPIRE metadata in the GetCapabilities response (using ows:ExtendedCapabilities), you find the text

metadata is populated into the ows:ExtendedCapabilities section of the GetCapabilities response document.

It's also where the inspire_dls:ExtendedCapabilities is shown in Examples 10 & 11

Geodeo commented 2 years ago

@KathiSchleidt @milanSch Indeed the INSPIRE metadata is populated in ows:ExtendedCapabilities. However as I understand it, this ows:ExtendedCapabilities element can be a child of both wcs:Contents/wcs:Extension (implemented by Geoserver) and ows:OperationsMetadata (implemented by rasdaman and the validator). I didn't find any explicit choice between these two possibilities in the WCS TG.

KathiSchleidt commented 2 years ago

@Geodeo @milanSch when I looked in XML Spy, I was offered the wcs:Contents/wcs:Extension (implemented by Geoserver) option (in the WCS Schema, the type for both ), but based on the TG, ows:OperationsMetadata is where INSPIRE expects it (both options are of type ANY in the XSD)

To my understanding, the other option would be formally correct as all required information is contained, but if you don't follow the TG, you would have to prove correctness in a different manner than the validator (like if you're providing an alternative encoding)

It might be worthwhile getting in touch with GeoSolutions as I believe they're working on this

milanSch commented 2 years ago

Hello, @KathiSchleidt, @Geodeo, @dperezBM

I understand that people are busy these days. I hope there will be final answer for issue I mentioned earlier https://github.com/INSPIRE-MIF/helpdesk-validator/issues/660 and it will help to move forward.

milan

fabiovinci commented 2 years ago

Dear all,

as regards the correct position of the ExtendedCapabilities element, there is a discussion here, which is still open.

dperezBM commented 2 years ago

Dear @apfelnymous,

We have tested the https://geoportal.saarland.de/gdi-sl/inspirewcs?map=/home/lvgl/inspire_oi.map&SERVICE=WCS&VERSION=2.0.0&REQUEST=GetCapabilities WCS service in production. After analysing the response provided to the validator it looks that the problem is on the url provided in http-request test step (https://geoportal.saarland.de/gdi-sl/inspirewcs?ACCEPTVERSIONS=2.0.1%2C2.0.0&REQUEST=GetCapabilities&SERVICE=WCS).

imagen

This URL responses the following message "msCGILoadMap(): Web application error. CGI variable "map" is not set." imagen

As the response of this URL is used for the following validations, the validator displays errors as it can't properly get the content.

I attach the report in production environment: Test run on 13_54 - 28.06.2022 with test suite Conformance Class Download Service WCS Core.zip

dperezBM commented 2 years ago

Dear @apfelnymous, The validator takes the URL up to the question mark as the base URL and then it builds the url with the AcceptVersions, Request and Service parameters.

Is it possible to get the WCS service content without the "map" parameter?

Thanks.

KathiSchleidt commented 2 years ago

A short note that we've now solved all problems with validating rasdaman WCS, details at: https://www.geoconnexion.com/news/rasdaman-validated-as-inspire-compliant-wcs

apfelnymous commented 2 years ago

Dear @apfelnymous, The validator takes the URL up to the question mark as the base URL and then it builds the url with the AcceptVersions, Request and Service parameters.

Is it possible to get the WCS service content without the "map" parameter?

Thanks.

Hello @dperezBM , I made that happen for a testservice https://geoportaltest.saarland.de/gdi-sl/inspireoiwcstest?&SERVICE=WCS&REQUEST=GetCapabilities A lot times the validator would say "an error has occured" but eventually it would start running the tests and no test failed it seems. Cant tell why it worked at some point, seems hard to make it work again /:

fabiovinci commented 1 year ago

Dear @apfelnymous,

it seems your service validates without errors (https://inspire.ec.europa.eu/validator/test-run/index.html?id=EID28c6f0aa-ecc3-427c-b612-590249c0dadf).

I will close the issue, please reopen it or a new one if the error persists.

Test run on 17_26 - 14.02.2023 with test suite Conformance Class Download Service WCS Core - IOS 523.zip