INSPIRE data model and data transformation

When it comes to organizing and sharing environmental and geographical data across Europe, there’s a specific set of rules to follow. One key part of this set is the INSPIRE Data Model.

The INSPIRE Data Model is a blueprint for how to structure geospatial data so that everyone is using the same format. This makes it easier to share and use data across different countries and organizations. The technical details for how to structure this data are outlined in the INSPIRE Technical Guidance documents that define XML schema files as the default way in which geospatial data should be structured. XML schemas are like templates that show how to organize data in a consistent way. You can find these templates for all 34 types of spatial data themes at

Turning existing data into a format that fits these templates involves a few key steps:

1. Analyzing the data you have: This means looking at the existing data to understand its format and how it’s organized.

2. Transforming the data: This is the technical part where data is reshaped to fit the INSPIRE standards. It’s like translating a book into a new language, where the original data is the book, the INSPIRE standards are the new language, and the translation process is divided into three parts:

  • Identifying the original format of your data (source data),
  • Figuring out how it should look in the end (destination model),
  • And deciding how to get from the original to the final format (mapping functions).

3. Creating harmonized datasets: Once the data is transformed, it’s put into a format called GML (Geography Markup Language), which is a type of XML designed specifically for geographical data. This makes the data easy to use and share.

4. Making metadata: Metadata is like a summary that explains what the data is about, how it was created, and other important details. For INSPIRE, there are specific rules about what this metadata needs to include.

Making sense of discovery services for spatial data

Discovery Services are like the search engines of the geospatial world, designed to help you find specific sets of spatial data and services. Think of them as a specialized Google for maps and geographic information, where the search is based on detailed summaries of what each dataset or service contains.

Here’s a simpler breakdown of what Discovery Services do:

1. Search for data and services: You can look up spatial datasets and services using specific details mentioned in their metadata, which is like a data ID card that describes what the data is, who made it, and other essential details.

2. Standardized search protocol: The way these searches work is based on a set of rules defined by the Open Geospatial Consortium (OGC). This group decides how search services should operate, making sure they work smoothly like other web services we use every day. The rules for this are laid out in something called the Catalogue Service for the Web (CSW) standard, which anyone can access online(

The CSW standard covers a few key actions:

  • Understanding what the server offers: You can ask the server to list the types of information it has and how you can access its features. (GetCapabilities)
  • Getting details on formats: It lets you find out in what formats the data or service descriptions are available. (DescribeRecord)
  • Finding out what searches you can do: You can learn about the different search parameters available. (GetDomain)
  • Fetching data by ID: If you know the exact ID of a dataset, you can get its metadata directly. (GetRecordById)
  • Searching with filters: You can search for metadata based on various criteria and download it in different standard formats. (GetRecords)
  • Incorporating external metadata: It allows the integration of metadata from other compliant search services. (Harvest)
  • Managing Metadata: You can add, update, or delete metadata listed by the server. (Transaction)

The results of these actions are provided in XML files, which are essentially digital documents that contain all the detailed information about datasets and services. These files can be used by software applications for further processing or displayed in a more user-friendly way for people to easily understand. This system also allows for organizing metadata into categories (like data themes or geographic extent), making it easier to find datasets and services that match specific criteria.

Using view services

Let’s say you have a map or a collection of data about places, and you want to see this information visually on a computer or mobile device. This is where “View Services” come into play. These services let you do more than just look at a static map. They allow you to interact with it. You can zoom in to see more details, zoom out to get the bigger picture, move around to explore different areas, or even layer different types of information on top of each other. Plus, they can show you a legend explaining the symbols on the map and give you details about the data you’re seeing.

The rules for how these services should work are set by OGC. They have a specific set of guidelines called the Web Map Service (WMS) standards. And can be downloaded from

Here’s what the WMS standards cover:

  • Finding out what’s available: You can ask the service what types of maps and data it has. (GetCapabilities)
  • Seeing the map: You can request a specific map or data set to be shown. (GetMap)
  • LearningLearning more about what you see: If you’re curious about a specific part of the map or a piece of data, you can get more detailed information about it. (GetFeatureInfo)

WMS services can show maps in different formats. Some formats are like pictures (PNG, GIF, JPEG) and others are more like drawings (SVG). Depending on the format, you might be able to see through layers to the maps underneath or combine several data sets to create a custom map that meets your needs.

Making the most of download services

If you need specific map data, like the layout of roads or the boundaries of lakes, directly on your computer or online platform, “Download Services” come in handy. These services let you grab copies of the map data you need and, if possible, use them right away without any middle steps.

The magic behind this capability is something called the Web Feature Service (WFS) standard. This is like a super-specific post office for geographical information system data. But unlike its cousin, the Web Map Service (WMS), which sends you a map picture (like a PNG or JPG image) that you can look at but not change, WFS lets you download and interact with the actual data points that make up the map. This means you can analyze this data in detail or mix it into other projects you’re working on.

The WFS standard is set by OGC. It defines operations for web interfaces for querying and editing vector geographic elements, such as roads or lake boundaries and can be accessed here:

Here’s what you can do with WFS:

  • Find what’s available: You can ask the service to list all the types of geographical data it has. (GetCapabilities)
  • Learn about the data: You can get detailed descriptions of what each piece of data represents, like what attributes a road or lake boundary has. (DescribeFeatureType)
  • Search for specific data: You can look for just the data you need, using filters to narrow down your search. (GetFeature)

For the data to fit the INSPIRE project’s rules, it needs to be formatted in a specific way, using text/XML files in the GML format, following the 3.2.1 specification of this data standard. This ensures that the data you download can be used seamlessly in GIS applications and meets Europe’s standards for sharing spatial information.

Understanding INSPIRE Metadata

After all the hard work of getting your dataset just right, transforming it to fit specific standards, and making it available online, there’s one more important step: making sure others can find and understand what you’ve done. This is where INSPIRE Metadata is useful. It’s like creating a detailed catalog card for your dataset, ensuring it can be easily discovered and used within the European network of resources.

INSPIRE Metadata is a set of detailed descriptions about your dataset, created following specific guidelines (ISO 19115 and INSPIRE standards). These descriptions are crafted in XML format, making the information machine-readable and widely accessible. Creating metadata might seem straightforward, but it’s a task reserved for the end of the dataset implementation process. The reason? Many details required in the metadata, such as specifics about the dataset’s final form and how it’s accessed, can only be nailed down after the dataset is fully prepped and published.

For each dataset transformed to align with INSPIRE standards, you’ll need to generate at least three XML metadata files. Plus, you’ll need to tweak the GetCapabilities documents of both the visualization (WMS) and download (WFS) services to include links back to these metadata files:

  • One URL for the GetCapabilities request of the WMS;
  • One URL for the GetCapabilities request of the WFS.

Metadata files connect to web-GIS services via two “Resource Locator” instances, each containing URLs for the WMS and WFS GetCapabilities requests. Metadata for WMS and WFS services should link back to the dataset’s metadata, for a seamless web of information.

Here’s how it works:

Linking Services to Datasets:

  • CoupledResource instances are specific references used to connect the metadata of visualization (WMS) and download (WFS) services back to the dataset’s metadata file. They act like bridges making sure that users navigating from a service can trace back to the original dataset’s metadata.
    • For WMS, a link points to the dataset’s metadata XML file.
    • For WFS, a similar link connects to the same dataset’s metadata, providing coherence and navigability between services and datasets.

Enhanced Service Responses:

  • ExtendedCapabilities in GetCapabilities are included when a service (WMS or WFS) responds to a GetCapabilities request. These are special sections within the XML response that provide URLs to:
    • The metadata file of the dataset, whichoffers a direct link to the detailed metadata of the dataset in question.
    • The metadata file of the service itself whichconnects to a detailed description of the service, whether it’s for visualization (WMS) or download (WFS).

This intricate web of links and references is not just for show. These metadata files have a lot of details, from who owns the data and how to contact them to a concise history of the dataset’s creation and key characteristics. They even include specific keywords to make searching for this data in the INSPIRE geoportal much easier.

While filling out the metadata might seem like filling out a comprehensive online form, the real challenge lies in following all the INSPIRE specifications. It’s not just about inputting data, it’s about making sure it aligns with a broad set of standards designed to make spatial data universally accessible and usable. There are numerous metadata editors to help with creating XML files, but when it comes to implementing all the constraints and recommendations specified in INSPIRE assistance is lacking.

Validating of data, services, and metadata

Making sure everything is up to par is more important than you might think. When working under the guidelines of the INSPIRE directive validation is very, very important. Institutions must take a close look at their geospatial data, the services they offer, and the metadata to make sure everything meets the INSPIRE standards. This isn’t just a one-time task but an ongoing step to make sure all data is accurate, reliable, and can be easily used across different systems and borders.

The European Commission has got you covered with a special tool designed just for this very purpose. It acts like a virtual inspector, helping institutions check everything against the set criteria. Maybe there’s missing information, or maybe something isn’t formatted correctly. Whatever the issue, the validator helps pinpoint what needs fixing. It can be accessed at


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.