Seitenhistorie

• 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 the structure and semantics of the data that is provided (ideally also in English and/or some machine-readable format).
• Also, the use of well-established vocabularies for category-based attributes and common approaches for the encoding of identifiers and coordinate information is crucial.

Responses (Brandenburg):

• Simplification of INSPIRE data structures: Creation and central provision of mandatory core data models in simplified data structures to ensure user-friendliness and applicability. The core data models should based on the existing complex INSPIRE data models. The complex data models remain in place.
• Scalability: Differentiation between local, regional, national, and international needs in the creation of core data models. It has to be ensured that the data structures are uniformly designed across the different (administrative) levels to enable data aggregation across levels.
• Specification: A clear position from the EU on whether national datasets are required for a given data theme.
• Mandatory implementation: All responsible data-holding entities are obliged to provide INSPIRE geodata in a uniform data structure and, if necessary, retroactively align existing data with the standardized structures to ensure comprehensive data coverage for each country.
• Multilingualism: Mandatory implementation of multilingualism in the creation of data schemas and data content (e.g. code lists) (for example, English is mandatory, while the national language is non-obligatory).
• Validation: Provision of test classes and validators to verify the accuracy of data schemas and data content (e.g., code lists).
• International standards: Binding requirements and mandatory implementation of international standards (e.g., OGC, ISO, W3C). The following requirements have to be considered:
• Provision of metadata (ISO, DCAT-AP, etc.)
• Machine-readable formats (GML, GeoJSON)
• Open licenses (definitive list; CC-0, CC-BY, Data License Germany, etc.)
• Provision through standardized interfaces (OGC API, WFS, WCS, Sensor Things API, etc.)
• Bulk download
• Resources and access: Provision of the necessary resources to the national point of contact to collect and centrally publish uniform geodata. Additionally, the EU should formulate requirements for the national points of contact to determine the appropriate resource needs.
• Sanctions: Sanctioning in case of non-compliance with the binding requirements.

 Optional:

• Best practice implementations / Example implementations before publication / resolution, as a guide for the affected entities.

• 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 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 could potentially also remove the duplicate implementations in some (most?) MS, 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.

Responses (Brandenburg):
If this approach were abandoned, it would

• be impossible to achieve interoperability of data content and integrate data from various sources.
• make a cross-border/cross-jurisdictional evaluation and analysis of geodata impossible, preventing answers to international questions.
• fail to fulfill the objectives of INSPIRE.

 Notes/Follow-up questions:

• It would be helpful to know which questions arise from the EU that have to be answered by using the distributed data.
• If the goal is to unlock economic potential, it would also be interesting to know the specific requirements for data content.
• It should be explored which other approaches to data harmonization are necessary and what is needed therefore. The use of IoT, ontologies in combination with ML, LLM, and AI could potentially be a target.

• 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 (e.g. including a mapping to well-established vocabularies) would be crucial.

Responses (Brandenburg):

• Significant regional/national differences in the required data content could be expected.
• In the process of standardization, relevant data content might get lost. Therefore, local, regional, national, and international differentiation have to be considered when creating core data models (see above).
• Monetary and personnel efforts might complicate the implementation of simplified INSPIRE data structures in member states.

• Dropping the obligation to harmonise all data sets within the scope of the INSPIRE Directive upfront would mean considerable cost reductions for data providers, 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. 

Responses (Brandenburg):

• Implementing simplified INSPIRE data structures and mandatory requirements could initially incur costs.
• However, cost reductions could be expected after implementation, as the aggregation of cross-border, simplified, and harmonized INSPIRE data will require less time. Time-intensive preparation of INSPIRE data could be eliminated.

• 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.

Responses (Brandenburg):

• The INSPIRE Directive should adopt the approach of MIMs (Minimal Interoperability Mechanisms) and continue this by using international standards. Simplifying and converting the previously complex INSPIRE data structures into flat data structures is recommended in this context.
• We support the introduction of MIMs because they focus on data relevant and specific subject-oriented questions.
• It is questionable whether all institutions responsible for this data are involved in the process and whether they are aware of the specific MIMs.

Notes/Follow-up questions:

• Will the MIMs be adopted as mandatory?
• MIMs have to be designed by considering future developments and requirements.

• The question is not really clear. What is meant by OPD? The impact of what precisely?
• 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. the Green Deal dataspace).