Transformation Model

When we talk about the transformation model in the context of integrating different data systems to comply with the INSPIRE directive, we’re essentially addressing how to standardize various data into a format that meets specific requirements. This is necessary because data comes in many shapes and that don’t naturally fit INSPIRE’s fixed standards.

To make this transformation happen, we need tools that are both powerful and flexible that can handle any type of data we might come across. This involves a series of steps (or transformation functions) that might even include automated scripts to streamline the process. The goal is to have a system where we can plug in various data, and with as little tweaking as possible, transform it to align with INSPIRE’s guidelines.

In practice, this might mean setting up special sections within existing databases that are designed specifically for transforming and organizing data in an INSPIRE-friendly way. However, it’s also important to be mindful of the existing IT landscape in a company or institution. Sometimes, a “hybrid” approach is best, where the new setup works alongside the old one with minimal disruption.

Data Transformation

Data Transformation is a big step in making different datasets work together under the INSPIRE framework. To make them compatible, we need to reshape them without losing their essential details. This process is what we refer to as data transformation.

In the context of INSPIRE, this transformation is not a simple task. It often eats up a significant chunk of project time, between 50% to 80%. The process is technical, typically handled by ETL (Extract, Transform, Load) experts who understand how to take data from its original form (extract), change it to fit INSPIRE requirements (transform), and then place it into the INSPIRE framework (load).

However, most people who create data within organizations are experts in their specific field, not in data technology. They know their data inside out but might not be familiar with how to reshape it to meet INSPIRE’s standards. When these domain experts try to apply transformation techniques without the necessary tech skills, mistakes can happen. Data might end up in the wrong shape, so to speak, leading to issues with compatibility and interoperability within the INSPIRE network.

The purpose of INSPIRE data transformation is to make sure that all data, regardless of its original format or source, can work together seamlessly. This interoperability is essential for the network’s success and is a primary focus towards the end of the implementation process. Achieving this level of compatibility means that data from different sources can be used together, providing valuable insights and information that were not possible before.

Systems Integration

If you had a team where each member spoke a different language how would you get everyone to work together smoothly, despite their differences? This is more or less the challenge with systems integration in the context of the INSPIRE directive. These “team members” are various subsystems or components that an organization uses to manage and share geospatial data.

For INSPIRE, all these different subsystems (whether they’re databases, software applications, or data processing tools) must communicate and work together seamlessly. This means that each subsystem must follow a common set of rules or standards, much like adopting a common team language. When a new subsystem is added to the mix, it needs to understand and speak this language too.

Publication of Compliant Data

After transforming your source data to fit INSPIRE’s requirements, the next step is to share it through geospatial services. However, your data might need some adjustments to fully match INSPIRE’s harmonized data models. If your data isn’t fully harmonized before it’s published, you might need to go back, making corrections to the data itself, tweaking how it’s transformed, and adjusting the way it’s shared online.

This process of revising and republishing data can be uncomfortably time-consuming and expensive. It’s especially challenging if the company institution doesn’t have the in-house expertise to fine-tune these complex processes manually. If you get everything right the first time, you avoid the extra work and costs that come with fixing things after the fact. In short, your best bet is to make sure that the solution provided covers all published technical specifications and validations existing in INSPIRE.

Validation of Published data

In the final stages of implementation, validation is a step that cannot be skipped. This means a thorough inspection to ensure all components of the data project conform to specific guidelines and work together smoothly. The metadata should clear and informative, the datasets should be structured in GML according to INSPIRE’s requirements. The OGC services must meet standard requirements and the system should accurately respond to data requests, whether via KVP (Key-Value Pair) or POST methods.


Florin Iosub is Team Lead and GIS Solutions Architect at Essensys Software, member of board, the Romanian Local Chapter of OSGeo and OSGeo charter member. With over 15 years of professional experience in the GIS field gained as a result of participating in the implementation of numerous projects, he is very well acquainted with the best practice and state-of-the-art of GIS technologies in all related fields. At the same time, he is very determined in spreading the FOSS4G values and principles and involved in various volunteering initiatives.