Question related 10 December 2021 milestone #785
Replies: 8 comments
-
|
Dear @iuriemaxim , the last deadline applies only if you have Invocable Spatial Data Services and you need to make them compliant with the relevant IR (1312/2014). |
Beta Was this translation helpful? Give feedback.
-
|
Dear @fabiovin Thank you for clarification, but I would appreciate a more detailed explanation. If for example a data provider has view and download services that are providing access to a dataset, and corresponding metadata files for the dataset, view and download services, and both, the metdata files and the services are passing their respective conformance tests, and the application schema, Data consistency, Information accessibility, Reference systems and GML application schema tests are passed for each corresponding data theme in the dataset, then the October 2020 milestone is reached. If no other service is available (non network service: view and download), then I understand that nothing should be done by December 2021 and there is no obligation to create other services than view and download network service. But these view and download network services that should be validated with the validator, should be in place also by December 2021, as creation/existance of Invocable Spatial Data Services are not replacing the obligation to deliver view and download Network Services. Is this correct?
Supposing a data provider would like to create also an Invocable Spatial Data Service that is not a view or download network service, what kind of service should that be and what tests should be passed by that service? For example if it would be a WFS, I suppose that it should not be compliant with Download Service: Direct-WFS, as this test was designed for network services and not for Invocable/Interoperable/Harmonised Spatial Data Services. Same if it would be a WMS, WMTS, WCS ... It is clear what tests should be passed by the metadata of an Invocable/Interoperable/Harmonised Spatial Data Service, but is not clear at all what tests in the validator should be passed by the Invocable Spatial Data Service, nor by the data served by that service. It can be confirmed that that neither the service and neither the data served by the service, or anything else should not be checked against the validator and no tests should exist for Invocable Spatial data Services, except for its metadata that describes the service? Or would be created other separate ETS tests in the validator for the Invocable/Interoperable/Harmonised Spatial Data Services, besides those that exist for View and Download Network Services? My understanding is that if a data provider wants to provide access to a dataset that is not corresponding to an INSPIRE data theme, then that dataset is not in the scope of INSPIRE and therefore neither network services, neither Invocable Spatial Data Services should be delivered to be harvested by the EC INSPIRE Geoportal. It is not clear also what is the reason of creating Invocable/Interoperable/Harmonised Spatial Data Services as there is an obligation to create view and download services by October 2020. One reason could be that besides providing data in GML format, someone would like to deliver the dataset in a personal geodatabase or as a geopackage, or other format. But this would be just an Interoperable Spatial Data Service and it should be supplementary to the dataset that should be delivered in GML format. So how a Harmonised Spatial Data Service should look like, if it would not be a download network service? Or less probably, by December 2021, data providers will be allowed to provide Interoperable Spatial Data Services instead of Download Network Services (October 2020 milestone). |
Beta Was this translation helpful? Give feedback.
-
|
Dear @iuriemaxim , I will try to reply to your questions, but probably this kind of discussion could be moved to the Community Forum.
It is correct, the COMMISSION REGULATION (EU) No 1312/2014 does not apply to the network services falling within the scope of Commission Regulation (EC) No 976/2009.
It could be a WPS, for instance, but the related IR does not foresee any specific test.
It cannot be a WFS, because a WFS is a network service and it falls under the Commission Regulation (EC) No 976/2009
An additional requirement, not related to metadata, is on the "output encoding" of a harmonised spatial data service (COMMISSION REGULATION (EU) No 1312/2014 - Annex III - Part A - Point 2), i.e. "A harmonised spatial data service returning spatial objects in the scope of the Directive 2007/2/EC shall encode those spatial objects according to this regulation.". |
Beta Was this translation helpful? Give feedback.
-
|
Dear @fabiovin I am raising these questions in relation with the validator, to be clear how data providers should test their services against the 2020 and 2021 deadlines, as it is not too clear, and as I see tests that are relaxed for network services, probably in order to accommodate invocable spatial data services that are not harmonised. That's why these questions are raised here, for the validator, in order to understand if certain relaxed tests are legitimate or not and in order to understand how to use the validator in order to test if the metadata, services and spatial data served by those services meets the 2020 and 2021 deadlines requirements. Can it than be clear that all tests that are in the validator for services are for network services and that invocable/interoperable/harmonised spatial data services should not be checked against conformance classes that exist in the validator as only the metadata of that service should be tested? There is a clear understanding that WMS, WFS, WCS, SOS and ATOM are network services and cant be used for invocable/interoperable.harmonised spatial data services? You mentioned that they are network services and should not be treated as invocable/interoperable/harmonised spatial data services. Here I am not sure, and that is why data providers are testing some services that are probably just invocable, against WMS, WFS and ATOM and asking for relaxation of tests. But of course this can be clarified and will be really useful. I completely agree that a Harmonised Spatial Data Service could be a WPS, but there are comments provided in the inspire-eu-validation community issues, claiming that WPS is not an INSPIRE Spatial Data Service (see https://github.com/inspire-eu-validation/community/issues/39) mentioning quite correct that ”Invoke service finally appeared as not really useful at the end in the INSPIRE infrastructure.” This is because within the "Technical Guidance for INSPIRE Spatial Data Services and services allowing spatial data services to be invoked", in section 3 - Terms and abbreviations the following definition exist: In section "4.2.2 Requirements for services allowing spatial data services to be invoked" is written: I think that the 1312/2014 Regulation created confusion between invoke (WPS) and invocable services (other services than network services) and probably played with words from the directive that is listing in article 11 at point (e) ”services allowing spatial data services to be invoked.”
So, reading it legally any service, including a WMS, WFS and ATOM could be a an ”Invocable spatial data service” as far as it has metadata according to Regulation 1205/2008, as points b) and c) are fulfilled by WMS, WFS, WCS, ATOM, etc, (except maybe that the word "execution" is a little bit strange for services). And exactly the “services allowing spatial data services to be invoked” that were defined in this position paper as WPS were considered by this TG as discovery services and still both documents are listed as Technical Guidelines for Spatial Data Services here. So I am confused and I do not think I am the only one, as I am not understanding what are these services described in 1312/2014 regulation that should be delivered by December 2021 milestone, as you mentioned, ”only if they exist”. In order to know if they exist, it should be understood what are they: ESRI REST services qualifies as invocable, interoperable, non harmonised spatial data services? But a web service providing a file containing spatial data at a certain http/https address? But if these services allows spatial data to be downloaded, then aren't they download network services, other than those that are already agreed (i.e. ATOM, WFS, WCS, SOS, ...)? Could a invocable data service have a download, view, discovery or transformation functionality, as these were already classified as network services? Or they should have other functionalities? Or network services are just a subset of the invocable spatial data services and other download services than ATOM, WFS, WCS, SOS, WMS, WMTS.... are "other" spatial data services (as indicated in the metadata) and they are listed as invocable spatial data services? I am not sure as well, if a data provider could claim that if invocable spatial data services (interoperable but not harmonised) were delivered, than it could be no obligation to deliver download newtork services providing access to harmonised spatial data sets, but this at least is more obvious that it should not be done, and network services with spatial data sets conformant with GML application schemas should be delivered by milestone 2020, even if invocable (at least interoperable or harmonised where practicable) services are delivered or not by milestone 2021. Regarding the ”output encoding” mentioned in Regulation 1312/2014 - Annex III - Part A - Point 2), which is that one (looking at the validator)? Should those spatial objects be encoded in GML and pass the corresponding GML application schema Conformance Class in the validator for the corresponding data theme? As the 2021 deadline is approaching, there is any example of an Harmonised Spatial Data Service? But of an Interoperable Spatial Data Service? How can one be found with the https://inspire-geoportal.ec.europa.eu/proxybrowser |
Beta Was this translation helpful? Give feedback.
-
|
Dear @iuriemaxim, |
Beta Was this translation helpful? Give feedback.
-
|
@fabiovin Thank you very much for the clarification. So even it is not so clear what an Invocable Spatial Data Service is, at least it is clear that the Validator is treating only Network Services and not Invocable Spatial Data Services for which the validaor only checks their metadata. I am also understanding then taht neither the content provided by the Invocable Spatial Data Services is not tested bybthe validator and will not be tested by the validator. Is that correct? |
Beta Was this translation helpful? Give feedback.
-
|
@MarcoMinghini My question is in relation to the validator and how Invocable Spatial Data Services should be tested, not only testing their metadata, but especially the spatial data that they are suposed to be providing. However I undertand that the validator is testing only the Network Services and the spatial data provided by download Network Services as the spatial data provided by Invocable Spatial Data Services, harmonised or not, is not tested bybthe valudator. As it is clear or not what are the Invocable Spatial Data Services, I understand that is not something to be clarified by the validator helpdesk, as the validator is just checking the metadata of these services, not the services themeself and nor the spatial data services served by them, harmonised or not. |
Beta Was this translation helpful? Give feedback.
-
|
Dear all, Since this issue had no interaction time ago, we decided to close it. Please feel free to open a new one if needed. Thank you and best regards. |
Beta Was this translation helpful? Give feedback.
-
In relation to previous question, for the next and last INSPIRE milestone, please help me to correctly understand what else should be done and tested in the validator in order to comply with the last deadline from 10 December 2021.
Beta Was this translation helpful? Give feedback.
All reactions