Kommentar:
Überarbeitung nach dem Feedback des AK INSPIRE
...
Kommentare und Ergänzungen können bis zum über diese Seite abgegeben werden.
Fragenkatalog & Antwort-Vorschlag
Disclaimer
Many of the questions are rather vague and do not explicitly state the underlying assumptions or related policy options. Furthermore, it was not possible for us to collect and consolidate feedback from all relevant stakeholders in the short period given for feedback. We therefore focus on trying to sharpen the questions and teasing out some of the underlying assumptions or policy options.
Question 1: Simplify technical provisions
...
#
Question
Comments
1.1
What would be a minimum level of harmonization/standardization?
Does this question refer only to legal provisions (in the IRs) or also the technical provisions (in the TGs and Good Practice documents)?
Does this question refer only to the provisions on data interoperability or also on the technical provisions on network services and metadata?
For data interoperability, there will always be the need for some processing (ETL) steps before being able to use data from different sources in an application or integrate it in a (pan-European/cross-border) data set. The main question here is how this necessary transformation is performed – by requiring all providers to transform their data to a common (exchange) model (the current obligation) upfront, from which a user/application developer can then transform the data to their application needs, or whether to put more burden for the transformation from the source format (data “as-is”) on the user/application developer.
It should be considered that even with the current approach, harmonised INSPIRE data can usually not be used in an application/integrated in a dataset “off-the-shelf” (i.e. with minimum extra effort), but that there is still considerable effort involved at the application developer side, as illustrated e.g. by the work of ESTAT on building pan-EU data sets.
For any transformation to a target application/data set, the user/application developer will need as a minimum a clear documentation of
This always depends on the use case.
I assume the question means “minimum level of harmonisation done by the data provider. In that case, I would say “none”, because the necessary ETL steps needed to use data in an application will need to be done by the application developer (i.e. the data user) anyway.
What is necessary as a minimum of course is that enough information on the structure and semantics of the data that is well documented provided (ideally also in English and/or some machine-readable format), so that the application developer is able to do that transformation easily.
Also, the use of well-established vocabularies for category-based attributes is helpful.Rules for identifiers, location information (CRS etc.)and common approaches for the encoding of identifiers and coordinate information is crucial.
1.2
What would be the consequence of abandoning the one-size-fits-all approach to harmonization of data?
A simplification could still What exactly is meant by “abandoning the one-size-fits-all approach to harmonization of data”? Do you mean the obligation to transform all data sets under the scope of INSPIRE to the defined common data models upfront? What would this obligation be replaced with? For example, simplification of obligations or a reduction of the burden on data providers could also mean a common approach/common requirements for all data sets, but at a much lower level of ambition (documentation up-front or even only on-demand rather than harmonisation up-front – see comment above)The consequence would be a shift of the burden from the data provider to the application developer (but e.g. the attempts of ESTAT to build pan-EU data sets has already shown that even now there is considerable effort involved at the application developer side)with fewer ex-ante obligations or focusing obligations on documentation of “as-is” data rather than transformation.
Removing the obligation to harmonise all data upfront would could potentially also remove the duplicate implementations in some (most?) MSthat , where “as is” data are used in national applications and use cases, that is done only to meet the INSPIRE requirements, i.e. the same “as-is” data that is available in the national SDI would also be made available under INSPIRE(together with documentation on how to use it).
1.3
What issues do you see related to interoperability when simplifying the technical provisions?
It would also mean that more effort would need to be spent on documenting The fewer technical provisions for upfront harmonisation exist, the more labour-intensive will be the transformation to a target application/data set. Therefore, if requirements for upfront harmonisation were to be reduced/abolished, sufficient documentation of data structures and semantics .Potentially, data providers would use well-established vocabularies (unless INSPIRE put a requirement that part of the documentation would be (e.g. including a mapping to well-established vocabularieswhen sharing data) would be crucial.
1.4
What would this mean in terms of cost reductions for data providers?
This could Dropping the obligation to harmonise all data sets within the scope of the INSPIRE Directive upfront would mean considerable cost reductions for data providers, if data no longer has to be harmonised upfront.This would (partly) be compensated by additional cost if instead the data structure and semantics would have to be documented for all data sets. If this has to be provided only on demand, costs would be lower.especially if duplicate implementations could be avoided through this.
Of course, additional costs for implementing alternative measures (e.g. an obligation for thorough documentation) would need to be considered when calculating cost reductions.
1.5
Would MIMs (Minimal Interoperability Mechanisms) be the solutions as used in Open and Agile Smart Cities and Communities (OASC)?
Some OASC MIMs (e.g. MIM-2, MIM-7) could be good sources for inspiration for alternative obligations,but they seem to still be at an early stage in their development, so should not be taken up 1:1.
1.6
How do you assess the impact of the alignment with HVD, OPD, Green Data Space?
Question The question is not really clear. What is meant by OPD? The impact of what precisely?
On the relation with HVD: if requirements on harmonisation are to be reduced drastically, INSPIRE could limit itself on adding a few provisions Generally, the overall future vision for the provision, sharing and use of geospatial and environmental data should be defined first. Then it should be discussed how this vision can be achieved and which (parts of which) existing legislation should be changed how and which aspects can be covered through soft measures (e.g. on documenting data models, the use of common vocabularies of use of identifiers) on top of the HVD provisions.the Green Deal dataspace).
Question 2: Establishment of a feedback mechanism (user feedback on data)
...
#
Question
Comments
4.1
What will be the needs for capacity building for green and digital skills to capture evolving data needs in the field of the environment on the side of the:
Data providers (share data as-is)
Data Intermediaries* (harmonization, additional processing, product development)
Users (data product requirements)
* A data intermediary under the DGA is an entity that facilitates the sharing of data between various parties while ensuring neutrality, transparency, and compliance with strict regulatory requirements to protect the interests of both data subjects (individuals) and data holders (providers, intermediaries).
Is it planned to include capacity building in the scope of the revised INSPIRE Directive? If so, in which form – setting obligations on Member States, setting up a funding programme for capacity building, developing common skills frameworks/certificates?
In general, all roles need to have an understanding of metadata
I assume this question mainly aims on the needs for capacity building a revised INSPIRE Directive should (somehow) support.
Data providers: Metadata, APIs, licences, shared vocabularies, data models, identifiers, versioning/archivingData intermediaries: , data harmonisation/ETL, business models, privacy enhancing technologiesUsers: Metadata, APIs, licences, shared vocabularies, data models, identifiers, versioning/archivingbut from slightly different perspectives – why is the distinction between the roles relevant (at this stage)?
4.2
What are the costs/efforts that will be transferred?
Unclear It is unclear what is meant by "cost/effort transfer" here.
...
#
Question
Comments
5.1
Would you prefer one common data sharing regime under horizontal legislation?
Generally, the overall future vision for the provision, sharing and use of (geospatial and environmental) data should be defined first. Then it should be discussed how this vision can be achieved and which (parts of which) existing legislation should be changed how. In the second step, it would of course be welcome if obligations are streamlined and relationship between legal acts were clear and consistent.
5.2
What would be the possible future role of the INSPIRE Directive? Is it still needed? For what?
INSPIRE has been and still is the main driver of sharing spatial data in Europe.
In the future, INSPIRE should ensure that all spatial data in Europe is made accessible in such a flexible way that it fulfils the requirements of data-using environments and applications such as data spaces, digital twins, etc. in terms of interfaces, formats, etc.
The INSPIRE Directive Annexes as they stand are an open-ended obligation to harmonize almost everything upfront and offer this to everybody, while there is no easy way to see EU-wide use-cases like maps or so based on the data provided by all Member States that prove the added value of INSPIRE beyond the good idea of sharing data. The now existing High Value Datasets may serve as the focus of EU activity in the future while for all other datasets a reasonable documentation on Member State level would be sufficent (see comments above).