The default encodings for INSPIRE, as per INSPIRE Data Specifications, are usually GML for vector data and GeoTIFF for raster coverages. However, since a single encoding is not optimal for all use cases, alternative encodings can also be used. In our previous blog post about alternate encodings, we already explained how alternative encodings can help to improve the data usability.

The GML default encoding works very well for system-to-system interoperability. But visualizing and analyzing large complex INSPIRE GML files in a GIS can be challenging. Thus, we have been working on supporting Geopackage, an alternative INSPIRE encoding that can be used directly on desktop.

How does this help me?

In our view GeoPackage is the optimal, open format for delivering medium to large sized data sets to GIS users. It is a single file that can store tables, vector geometries and rasters. It is extensible and fast to access. It can deal with simple and more detailed data models well. There is even the option to store views and styles. And GeoPackage does not have some of the shortcomings of GML such as 11-character attribute limits, unknown encodings, and missing or incomplete projection files.

Like INSPIRE GML datasets, GeoPackages are interoperable. In addition, GeoPackages can be used across all enterprise and personal computing environments. GeoPackages work much better even in environments with limited connectivity and bandwidth, such as mobile devices. Below you can find a comparison of GeoPackage and GML, and see how they complement each other:

How can I implement GeoPackage effectively, and what transformation rules should I consider?

There were always requests to add GeoPackage to the list of supported formats for hale»studio. To this end, we added a GeoPackage Reader and a Writer that was released with hale»studio 4.0. The Writer can create GeoPackages from scratch, including the schema and the metadata. This work was possible thanks to funding from Umweltbundesamt Austria and Rijkswaterstaat Netherlands, and support from the European Environmental Agency.

You can load data such as a shapefile, a FileGeodatabase, or simple GML. Then you map that data to a GeoPackage-specific schema or even an XML schema. Finally, you export your transformed data. If you already have GeoPackage source data, you can load it directly into hale»studio and use it in a transformation project.

The UML to Geopackage (U2G) rule was developed by UNIZAR, and has two parts:

• Compliance encoding rule: This rule is focused on INSPIRE compliance and helps to streamline data-validation procedures.
• Flattened dataset encoding rule: When encoded as GML, type aggregation in INSPIRE models can lead to a nesting depth of properties of up to 11 levels. Often, this leads to unnecessary structural overhead. The flattening of these structures significantly improves data usability in desktop software.

More information about the issues that GeoPackage addresses via encoding rules can be found here.

Schema Conversion Rules

The GeoPackage encoding takes a two-step approach. The first step occurs at the conceptual level, when INSPIRE constructs are transformed into GeoPackage constructs. These constructs are then turned into a Geopackage template. This template varies according to INSPIRE theme.

The mapping from the UML model to the GeoPackage, as per the original creators, can be found below:

The correspondence tables for other standards (for e.g. ISO 19115, ISO 19139, etc.) can be found here.

A Brief Case Study: Core Conformance Classes for the GeoPackage Encoding Rule for European Noise Directive data

Between 2020 and now, wetransform supported the EEA to provide a GeoPackage Encoding for European Noise directive data.

Conformance Classes

The END consists of multiple application schemas that inherit from different INSPIRE themes. This specific encoding rule defines several conformance classes:

• Noise Sources
• Noise Exposure including Noise Contours
• Quiet Areas
• Noise Action plans

A core conformance class describes common rules that are applied to all the aforementioned conformance classes. Additionally, there are also conformance-class specific rules.

The rules applied in this case to streamline the models were:

• Flattening hierarchical structures and data types: To make this data more useable in the GeoPackage encoding, the following strategies were applied:
  1. Substitution of complex types through simpler types (Simple Citation, Simple Codelist Reference, Simple Geographical Name, Simplified Localized Character String…)
  2. Usage of related tables for elements where the allowed cardinality is greater 1
  3. Flattening of properties
• Dealing with INSPIRE voidable attributes: To avoid clutter in the primary feature table whilst maintaining compatibility with INSPIRE conceptual model, a companion table to the actual primary feature table was created. Such properties could be stored in the companion table if required. Both the primary feature table and companion table are shown below:

• Setting default dataset properties: In INSPIRE data models, there are some properties that usually have the same value for every object in a data set, such as the voidReason attributes. Such attributes may be encoded into a DatasetDefaultProperties table and are removed as separate columns from the primary feature table. This results in streamlined GeoPackage primary feature table structure. The structure of the DatasetDefaultProperties is as follows:

• Handling code list values and titles: In INSPIRE GML, codelist values are encoded as xlinks that point to a fully qualified URL. Since these URLs contain special characters and are quite long, they are often harder to interpret, to use as labels and to use as filters for symbology. As a result, we use a specific model transformation rule:
  1. Keep the attribute name, but change the type to string
  2. In that string, write the local part of the value
  3. In an extra table called CodelistProperties, store a mapping of the table and property to the fully qualified URL of the codelist.

• Handling attributes with 1:n cardinality: In INSPIRE, many attributes of a feature type can have more than one value. This is used both to represent associations and composition relationships in the conceptual model, but often presents a challenge in other encodings than GML. As Geopackages can contain many tables with foreign key relationships, such compositions and associations are handled by introducing related tables. This is only done when a property type is complex and when the maximum multiplicity of the property is > 1.

• Handling of associations with 1:n and n:m multiplicity: In INSPIRE, features can have a many-to-many relationship. Such relationships can be represented in GeoPackage using a relationship table. In a relationship table, there is a primary key, as well as two foreign keys. As in the composition case, the foreign key columns are named _FID in the related table.

If you are interested in knowing more about the conformance class specific rules, just reach out to us at info@wetransform.to!

Want to start transforming data to GeoPackage? Try out our open-source tool, hale»studio today!

The required model transformations for complex GML cases are still under development, and you can expect to see them in the next hale»studio release later this year.

The default encodings for INSPIRE, as per INSPIRE Data Specifications, are usually GML for vector data and GeoTIFF for raster coverages. However, since a single encoding is not optimal for all use cases, alternative encodings can also be used. In our previous blog post about alternate encodings, we already explained how alternative encodings can help to improve the data usability.

The GML default encoding works very well for system-to-system interoperability. But visualizing and analyzing large complex INSPIRE GML files in a GIS can be challenging. Thus, we have been working on supporting Geopackage, an alternative INSPIRE encoding that can be used directly on desktop.

How does this help me?

In our view GeoPackage is the optimal, open format for delivering medium to large sized data sets to GIS users. It is a single file that can store tables, vector geometries and rasters. It is extensible and fast to access. It can deal with simple and more detailed data models well. There is even the option to store views and styles. And GeoPackage does not have some of the shortcomings of GML such as 11-character attribute limits, unknown encodings, and missing or incomplete projection files.

Like INSPIRE GML datasets, GeoPackages are interoperable. In addition, GeoPackages can be used across all enterprise and personal computing environments. GeoPackages work much better even in environments with limited connectivity and bandwidth, such as mobile devices. Below you can find a comparison of GeoPackage and GML, and see how they complement each other:

How can I implement GeoPackage effectively, and what transformation rules should I consider?

There were always requests to add GeoPackage to the list of supported formats for hale»studio. To this end, we added a GeoPackage Reader and a Writer that was released with hale»studio 4.0. The Writer can create GeoPackages from scratch, including the schema and the metadata. This work was possible thanks to funding from Umweltbundesamt Austria and Rijkswaterstaat Netherlands, and support from the European Environmental Agency.

You can load data such as a shapefile, a FileGeodatabase, or simple GML. Then you map that data to a GeoPackage-specific schema or even an XML schema. Finally, you export your transformed data. If you already have GeoPackage source data, you can load it directly into hale»studio and use it in a transformation project.

The UML to Geopackage (U2G) rule was developed by UNIZAR, and has two parts:

• Compliance encoding rule: This rule is focused on INSPIRE compliance and helps to streamline data-validation procedures.
• Flattened dataset encoding rule: When encoded as GML, type aggregation in INSPIRE models can lead to a nesting depth of properties of up to 11 levels. Often, this leads to unnecessary structural overhead. The flattening of these structures significantly improves data usability in desktop software.

More information about the issues that GeoPackage addresses via encoding rules can be found here.

Schema Conversion Rules

The GeoPackage encoding takes a two-step approach. The first step occurs at the conceptual level, when INSPIRE constructs are transformed into GeoPackage constructs. These constructs are then turned into a Geopackage template. This template varies according to INSPIRE theme.

The mapping from the UML model to the GeoPackage, as per the original creators, can be found below:

The correspondence tables for other standards (for e.g. ISO 19115, ISO 19139, etc.) can be found here.

A Brief Case Study: Core Conformance Classes for the GeoPackage Encoding Rule for European Noise Directive data

Between 2020 and now, wetransform supported the EEA to provide a GeoPackage Encoding for European Noise directive data.

Conformance Classes

The END consists of multiple application schemas that inherit from different INSPIRE themes. This specific encoding rule defines several conformance classes:

• Noise Sources
• Noise Exposure including Noise Contours
• Quiet Areas
• Noise Action plans

A core conformance class describes common rules that are applied to all the aforementioned conformance classes. Additionally, there are also conformance-class specific rules.

The rules applied in this case to streamline the models were:

• Flattening hierarchical structures and data types: To make this data more useable in the GeoPackage encoding, the following strategies were applied:
  1. Substitution of complex types through simpler types (Simple Citation, Simple Codelist Reference, Simple Geographical Name, Simplified Localized Character String…)
  2. Usage of related tables for elements where the allowed cardinality is greater 1
  3. Flattening of properties
• Dealing with INSPIRE voidable attributes: To avoid clutter in the primary feature table whilst maintaining compatibility with INSPIRE conceptual model, a companion table to the actual primary feature table was created. Such properties could be stored in the companion table if required. Both the primary feature table and companion table are shown below:

• Setting default dataset properties: In INSPIRE data models, there are some properties that usually have the same value for every object in a data set, such as the voidReason attributes. Such attributes may be encoded into a DatasetDefaultProperties table and are removed as separate columns from the primary feature table. This results in streamlined GeoPackage primary feature table structure. The structure of the DatasetDefaultProperties is as follows:

• Handling code list values and titles: In INSPIRE GML, codelist values are encoded as xlinks that point to a fully qualified URL. Since these URLs contain special characters and are quite long, they are often harder to interpret, to use as labels and to use as filters for symbology. As a result, we use a specific model transformation rule:
  1. Keep the attribute name, but change the type to string
  2. In that string, write the local part of the value
  3. In an extra table called CodelistProperties, store a mapping of the table and property to the fully qualified URL of the codelist.

• Handling attributes with 1:n cardinality: In INSPIRE, many attributes of a feature type can have more than one value. This is used both to represent associations and composition relationships in the conceptual model, but often presents a challenge in other encodings than GML. As Geopackages can contain many tables with foreign key relationships, such compositions and associations are handled by introducing related tables. This is only done when a property type is complex and when the maximum multiplicity of the property is > 1.

• Handling of associations with 1:n and n:m multiplicity: In INSPIRE, features can have a many-to-many relationship. Such relationships can be represented in GeoPackage using a relationship table. In a relationship table, there is a primary key, as well as two foreign keys. As in the composition case, the foreign key columns are named _FID in the related table.

If you are interested in knowing more about the conformance class specific rules, just reach out to us at info@wetransform.to!

Want to start transforming data to GeoPackage? Try out our open-source tool, hale»studio today!

The required model transformations for complex GML cases are still under development, and you can expect to see them in the next hale»studio release later this year.

Each data format is made with a specific purpose. The data stored in the format, however, may be consumed by a multitude of different applications and users. Since the data format was designed with certain use cases in mind, it may not be well-suited for other functions. As such, it’s important to bridge the gap between a certain format and the needs of end users who want to work with the data.

To enhance data usability, other formats or encodings can be used to complement the default encoding. In the context of INSPIRE, this can be an alternative encoding, i.e. one that fulfills all requirements of the INSPIRE Implementing Rule and thus be used instead of the default encdoing, or it can be an additional encoding.

The goal of such encodings is to act as a link between the default encoding and a use case that is not addressed sufficiently by the default encoding. There are a few questions that must be answered while chosing or developing an encoding, such as:

• Which kind of themes and use cases are you building the alternative encoding for?
• What model transformation rules need to be applied to match the conceptual model to the capabilities of the format’s logical model?
• How can this encoding be implemented?

Thorsten Reitz, CEO of wetransform, presented a webinar that answered these questions. The webinar also presented GeoJSON alternative encodings that are targeted at making INSPIRE data easily usable.

The default encoding for INSPIRE data is complex GML, which is well suited for the interchange of data. Since it has been made with the purpose of interoperability, it does well in terms of providing easy exchange of complex data. Common web applications and web APIs can perform standard operations on data formats that are not nested, however, and have difficulties doing so with nested data formats such as complex GML. According to the MIG Working group, “While INSPIRE data encoded according to the current schemas can be downloaded and viewed, simple use (visualisation, simple joins, visual overlays, spatial search, …) is difficult in standard GIS clients.”

The webinar described how the GeoJSON encoding can help you gain maximum value from your INSPIRE data by making the data more compatible with GIS clients. The GeoJSON alternative encoding can be used instead of the nested INSPIRE GML data. GeoJSON is designed from the ground up to easily be consumed by web applications and web service APIs, thus providing for a use case that is not well-suited to INSPIRE GML. The webinar also covered the most common issues faced while trying to create an alternative encoding, the structure of GeoJSON encoding rules and model transformation rules. It mentioned how to measure the success of alternative encoding and looked at whether the GeoJSON alternative encoding succeeded in making INSPIRE data more usable in a specific target environment.

You can find a link to the webinar here.

Each data format is made with a specific purpose. The data stored in the format, however, may be consumed by a multitude of different applications and users. Since the data format was designed with certain use cases in mind, it may not be well-suited for other functions. As such, it’s important to bridge the gap between a certain format and the needs of end users who want to work with the data.

To enhance data usability, other formats or encodings can be used to complement the default encoding. In the context of INSPIRE, this can be an alternative encoding, i.e. one that fulfills all requirements of the INSPIRE Implementing Rule and thus be used instead of the default encdoing, or it can be an additional encoding.

The goal of such encodings is to act as a link between the default encoding and a use case that is not addressed sufficiently by the default encoding. There are a few questions that must be answered while chosing or developing an encoding, such as:

• Which kind of themes and use cases are you building the alternative encoding for?
• What model transformation rules need to be applied to match the conceptual model to the capabilities of the format’s logical model?
• How can this encoding be implemented?

Thorsten Reitz, CEO of wetransform, presented a webinar that answered these questions. The webinar also presented GeoJSON alternative encodings that are targeted at making INSPIRE data easily usable.

The default encoding for INSPIRE data is complex GML, which is well suited for the interchange of data. Since it has been made with the purpose of interoperability, it does well in terms of providing easy exchange of complex data. Common web applications and web APIs can perform standard operations on data formats that are not nested, however, and have difficulties doing so with nested data formats such as complex GML. According to the MIG Working group, “While INSPIRE data encoded according to the current schemas can be downloaded and viewed, simple use (visualisation, simple joins, visual overlays, spatial search, …) is difficult in standard GIS clients.”

The webinar described how the GeoJSON encoding can help you gain maximum value from your INSPIRE data by making the data more compatible with GIS clients. The GeoJSON alternative encoding can be used instead of the nested INSPIRE GML data. GeoJSON is designed from the ground up to easily be consumed by web applications and web service APIs, thus providing for a use case that is not well-suited to INSPIRE GML. The webinar also covered the most common issues faced while trying to create an alternative encoding, the structure of GeoJSON encoding rules and model transformation rules. It mentioned how to measure the success of alternative encoding and looked at whether the GeoJSON alternative encoding succeeded in making INSPIRE data more usable in a specific target environment.

You can find a link to the webinar here.