Wind turbines, helipads, industrial plants, and campsites - wondering what’s common among these?
According to §21 of Germany’s Air Traffic Regulations and the EU Drone Regulation of 2021 they are recognized as drone flight prohibition zones. However, not all such drone no-fly zones have been formally identified and communicated to the public.
In 2018, drones caused 158 disruptions to air traffic in Germany - almost double the amount from the previous year. Drone flight clearly comes with safety and security risks, and not all no-fly zones are formally defined. The expected growth in drone usage (between 2020 and 2025, commercial drone usage is expected to increase by 200%) will worsen the situation and lead to more similar instances - unless no-fly zones are identified, monitored and communicated actively.
https://www.bdl.aero/wp-content/uploads/2021/03/VUL-Markststudie_2021.pdf
Moreover, precise and safe drone navigation will expand possible drone mobility uses and add value to society. For example, drones will reduce efforts and costs of supply lines and operational execution. They could be used to transport vaccines or medical equipment such as oxygen cannisters more effectively. Robotic camera drones could be used for high-voltage pipelines inspections or gas line maintenance. The applications of safe drone mobility are vast and diverse.
Eliminating the current drone navigation problems and making the most out of drone transport is no small feat. Germany has 357,386 km² of terrain that need to be analysed, branded, and visualized as fly or no-fly zones. Some of these terrain features have not yet been mapped. These problems are a part of a sphere of innovation that needs further strategic development.
Deutsche Flugsicherung (DFS), Fraunhofer IGD, and wetransform have joined forces to tackle these problems through the fAIRport (Flight Area Artificial Intelligence Retrieval Portal) project. The three-year long (2020 – 2023) and 1.2 million EUR project is supported by the Federal Ministry of Transport and Digital Infrastructure (BMVI) as a part of the mFUND (Modernity Fund) research initiative.
The main aim of fAIRport is to provide a comprehensive high-precision geodatabase for no-fly zones in Germany by merging existing datasets and creating new information through Fraunhofer IGD’s AI-based methods for orthoimage object detection.
wetransform is developing the centrepiece of the project- the fAIRport municipal portal and creating the dataflows for the establishment of the portal. The portal will collate static data, dynamic data, local information, and real-time information. Fraunhofer IGD is creating the 2D and 3D visualisations of no-fly zones that will make the portal more intuitive and easier to use. The portal will allow local authorities to access, upload, maintain, and manage no-fly zones within their jurisdictions.
The project is in its initial stages, and recently we hosted the second user workshop on the functionalities of the portal for the City of Langen, and important project stakeholder. The goal of the workshop was to get a deeper understanding of the required workflows and the portal requirements. The first draft of the portal based on user requirements is shown below:
This draft received positive feedback, but there’s still a long way to go. Nationwide data must be collected and branded as fly or no-fly zones, and then this data needs to be made accessible at scale and visualized effectively.
After project completion in early 2023, there will be clear rules about where drones can fly in all of Germany and all no-fly zones will be visualized and maintained with ease. Moreover, community members will be able to add in zones themselves, thus any spontaneous activities that lead to temporary no-fly zones can also easily be added to the fAIRport portal. These initiatives will open more flight corridors as only dedicated areas will be restricted. The improved definition of zones will also let local authorities across Germany effectively manage no-fly zones in their jurisdictions.
We’re excited to see how this project will cause disruption across industries. If you’re interested in other similar initiatives, you can also read our article about how wetransform is harnessing the power of open data to save Germany’s forests.
Interested in staying updated about the latest happenings in the world of data interoperability? Sign up for our newsletter here.
Wind turbines, helipads, industrial plants, and campsites - wondering what’s common among these?
According to §21 of Germany’s Air Traffic Regulations and the EU Drone Regulation of 2021 they are recognized as drone flight prohibition zones. However, not all such drone no-fly zones have been formally identified and communicated to the public.
In 2018, drones caused 158 disruptions to air traffic in Germany - almost double the amount from the previous year. Drone flight clearly comes with safety and security risks, and not all no-fly zones are formally defined. The expected growth in drone usage (between 2020 and 2025, commercial drone usage is expected to increase by 200%) will worsen the situation and lead to more similar instances - unless no-fly zones are identified, monitored and communicated actively.
https://www.bdl.aero/wp-content/uploads/2021/03/VUL-Markststudie_2021.pdf
Moreover, precise and safe drone navigation will expand possible drone mobility uses and add value to society. For example, drones will reduce efforts and costs of supply lines and operational execution. They could be used to transport vaccines or medical equipment such as oxygen cannisters more effectively. Robotic camera drones could be used for high-voltage pipelines inspections or gas line maintenance. The applications of safe drone mobility are vast and diverse.
Eliminating the current drone navigation problems and making the most out of drone transport is no small feat. Germany has 357,386 km² of terrain that need to be analysed, branded, and visualized as fly or no-fly zones. Some of these terrain features have not yet been mapped. These problems are a part of a sphere of innovation that needs further strategic development.
Deutsche Flugsicherung (DFS), Fraunhofer IGD, and wetransform have joined forces to tackle these problems through the fAIRport (Flight Area Artificial Intelligence Retrieval Portal) project. The three-year long (2020 – 2023) and 1.2 million EUR project is supported by the Federal Ministry of Transport and Digital Infrastructure (BMVI) as a part of the mFUND (Modernity Fund) research initiative.
The main aim of fAIRport is to provide a comprehensive high-precision geodatabase for no-fly zones in Germany by merging existing datasets and creating new information through Fraunhofer IGD’s AI-based methods for orthoimage object detection.
wetransform is developing the centrepiece of the project- the fAIRport municipal portal and creating the dataflows for the establishment of the portal. The portal will collate static data, dynamic data, local information, and real-time information. Fraunhofer IGD is creating the 2D and 3D visualisations of no-fly zones that will make the portal more intuitive and easier to use. The portal will allow local authorities to access, upload, maintain, and manage no-fly zones within their jurisdictions.
The project is in its initial stages, and recently we hosted the second user workshop on the functionalities of the portal for the City of Langen, and important project stakeholder. The goal of the workshop was to get a deeper understanding of the required workflows and the portal requirements. The first draft of the portal based on user requirements is shown below:
This draft received positive feedback, but there’s still a long way to go. Nationwide data must be collected and branded as fly or no-fly zones, and then this data needs to be made accessible at scale and visualized effectively.
After project completion in early 2023, there will be clear rules about where drones can fly in all of Germany and all no-fly zones will be visualized and maintained with ease. Moreover, community members will be able to add in zones themselves, thus any spontaneous activities that lead to temporary no-fly zones can also easily be added to the fAIRport portal. These initiatives will open more flight corridors as only dedicated areas will be restricted. The improved definition of zones will also let local authorities across Germany effectively manage no-fly zones in their jurisdictions.
We’re excited to see how this project will cause disruption across industries. If you’re interested in other similar initiatives, you can also read our article about how wetransform is harnessing the power of open data to save Germany’s forests.
Interested in staying updated about the latest happenings in the world of data interoperability? Sign up for our newsletter here.
(more)
Based on our work with 1000+ public organizations across the EU, we have found that the Environmental Monitoring Facilities theme poses challenges for many organizations. Through this blog post, you will learn more about:
- What is the INSPIRE Environmental Monitoring Facilities theme and the related Observations and Measurements specification, and what are some of its use cases?
- Why is the theme challenging to implement?
- How can you deal with this complexity?
INSPIRE Environmental Monitoring Facilities (EMF) and Observations and Measurements (OM)
The environmental monitoring facilities data specification is a generic model that has been developed for environmental monitoring of any kind, across any domain. The scope of EF is defined in the INSPIRE directive as “Location and operation of environmental monitoring facilities includes observation and measurement of emissions, of the state of environmental media and of other ecosystem parameters (biodiversity, ecological conditions of vegetation, etc.) by or on behalf of public authorities.”
This scope definition includes two aspects:
- The environmental monitoring facility as a spatial object in the context of INSPIRE (location)
- Data obtained through observations and measurements linked to the environmental monitoring facility (operation).
The EMF data specification re-uses the OGC Observations and Measurements specification for the actual observations. Again, this is a generic data model that can be used to encode data from a very wide range of sensors. Observed properties recorded at environmental monitoring facilities include particulate matter concentrations in ppm, air temperature in degrees Celsius, precipitation in millimeters or water pressure in PSI.
Due to this open scope, data encoded according to the EMF specification has many use cases, such as monitoring water or air quality, noise monitoring, or detection of specific emissions. Such data is often mission-critical for businesses and organizations. For example, due to the Icelandic volcanic eruptions of 2014, air traffic routes over Iceland were severely disrupted due to significant amounts of ash. These routes were used by many airline carriers that had heterogenous data on air quality and weather patterns. As a result of this heterogeneity, coordination of navigation through the Icelandic airspace became increasingly complex and resulted in large costs for the airline carriers.
Why is this theme challenging to implement?
The EMF and OM specifications form a powerful, generic model, with a wide range of different measurements and use cases. What this leads to is a very flexible model, i.e. one that doesn’t just prescribe one way to encode things. Different implementers may thus arrive at different ways how to structure their EMF data, even for the same type of measurement. As an example, you can decide to reference observation data from the EnvironmentalMonitoringFacility either inLine or byReference, using the property hasObservation.
Both the option to nest OM_Observations in the EnvironmentalMonitoringFacility.hasObservation property and the option to create top-level OM_Observation features and reference them via href in EnvironmentalMonitoringFacility.hasObservation are equally valid in INSPIRE. If users want to primarily request OM_Observation features from the WFS (independent of EnvironmentalMonitoringFacility features), modelling them as top-level (byReference) is better. If users primarily want to request EnvironmentalMonitoringFacility features with all details (including the OM_Observation under the hasObservation property), then nesting (inLine) would be better. The decision to provide features inLine or byReference should be made before your project begins.
Example: modelling features inLine
Another decision you will need to make is to define what structure the actual measurements in OM_Observationshould have. By default, the OM_Observation.result property is of type anyType in the Environmental Monitoring Facility INSPIRE schema.
In the XML Schema Definition Language (XSD), the data type anyType is at the root of the type definition hierarchy. An element with type anyType defines no constraints regarding the type of data it can contain. This does not mean, that the contained data should not or cannot have a type defined in a schema. In INSPIRE, type anyType does not always mean that we can add whatever data type we want. In some INSPIRE schemas, there are constraints documented in the INSPIRE UML models which describe the types that are acceptable. In the Environmental Monitoring Facilities schema, the constraint documented in the UML states: “{result type shall be suitable for observedProperty}”. As the property is mandatory in the INSPIRE data model, implementers need to provide a value in the result property. To be able to populate this property, a type definition must be added to the schema.
The data types Quantity and Range are common choices. For the following example, we selected the data type Quantity, found in this schema. Using Quantity, we can add the measurement value, the unit of measurement, and the allowed value range of the measurements.
To further clarify this topic and to train INSPIRE implementers on how to transform data to the INSPIRE Environmental Monitoring Facilities theme, we will host an online training from 25th May 2021-27th May 2021. This training will cover:
- Learn how to analyse your source data and determine the structure of your EMF dataset(s)
- Learn how to combine and edit schemas for use in hale studio
- Interactively create an INSPIRE compliant EMF dataset through detailed, guided mapping instruction
You can learn more about this training, costs, and the registration process here.
Based on our work with 1000+ public organizations across the EU, we have found that the Environmental Monitoring Facilities theme poses challenges for many organizations. Through this blog post, you will learn more about:
- What is the INSPIRE Environmental Monitoring Facilities theme and the related Observations and Measurements specification, and what are some of its use cases?
- Why is the theme challenging to implement?
- How can you deal with this complexity?
INSPIRE Environmental Monitoring Facilities (EMF) and Observations and Measurements (OM)
The environmental monitoring facilities data specification is a generic model that has been developed for environmental monitoring of any kind, across any domain. The scope of EF is defined in the INSPIRE directive as “Location and operation of environmental monitoring facilities includes observation and measurement of emissions, of the state of environmental media and of other ecosystem parameters (biodiversity, ecological conditions of vegetation, etc.) by or on behalf of public authorities.”
This scope definition includes two aspects:
- The environmental monitoring facility as a spatial object in the context of INSPIRE (location)
- Data obtained through observations and measurements linked to the environmental monitoring facility (operation).
The EMF data specification re-uses the OGC Observations and Measurements specification for the actual observations. Again, this is a generic data model that can be used to encode data from a very wide range of sensors. Observed properties recorded at environmental monitoring facilities include particulate matter concentrations in ppm, air temperature in degrees Celsius, precipitation in millimeters or water pressure in PSI.
Due to this open scope, data encoded according to the EMF specification has many use cases, such as monitoring water or air quality, noise monitoring, or detection of specific emissions. Such data is often mission-critical for businesses and organizations. For example, due to the Icelandic volcanic eruptions of 2014, air traffic routes over Iceland were severely disrupted due to significant amounts of ash. These routes were used by many airline carriers that had heterogenous data on air quality and weather patterns. As a result of this heterogeneity, coordination of navigation through the Icelandic airspace became increasingly complex and resulted in large costs for the airline carriers.
Why is this theme challenging to implement?
The EMF and OM specifications form a powerful, generic model, with a wide range of different measurements and use cases. What this leads to is a very flexible model, i.e. one that doesn’t just prescribe one way to encode things. Different implementers may thus arrive at different ways how to structure their EMF data, even for the same type of measurement. As an example, you can decide to reference observation data from the EnvironmentalMonitoringFacility either inLine or byReference, using the property hasObservation.
Both the option to nest OM_Observations in the EnvironmentalMonitoringFacility.hasObservation property and the option to create top-level OM_Observation features and reference them via href in EnvironmentalMonitoringFacility.hasObservation are equally valid in INSPIRE. If users want to primarily request OM_Observation features from the WFS (independent of EnvironmentalMonitoringFacility features), modelling them as top-level (byReference) is better. If users primarily want to request EnvironmentalMonitoringFacility features with all details (including the OM_Observation under the hasObservation property), then nesting (inLine) would be better. The decision to provide features inLine or byReference should be made before your project begins.
Example: modelling features inLine
Another decision you will need to make is to define what structure the actual measurements in OM_Observationshould have. By default, the OM_Observation.result property is of type anyType in the Environmental Monitoring Facility INSPIRE schema.
In the XML Schema Definition Language (XSD), the data type anyType is at the root of the type definition hierarchy. An element with type anyType defines no constraints regarding the type of data it can contain. This does not mean, that the contained data should not or cannot have a type defined in a schema. In INSPIRE, type anyType does not always mean that we can add whatever data type we want. In some INSPIRE schemas, there are constraints documented in the INSPIRE UML models which describe the types that are acceptable. In the Environmental Monitoring Facilities schema, the constraint documented in the UML states: “{result type shall be suitable for observedProperty}”. As the property is mandatory in the INSPIRE data model, implementers need to provide a value in the result property. To be able to populate this property, a type definition must be added to the schema.
The data types Quantity and Range are common choices. For the following example, we selected the data type Quantity, found in this schema. Using Quantity, we can add the measurement value, the unit of measurement, and the allowed value range of the measurements.
To further clarify this topic and to train INSPIRE implementers on how to transform data to the INSPIRE Environmental Monitoring Facilities theme, we will host an online training from 25th May 2021-27th May 2021. This training will cover:
- Learn how to analyse your source data and determine the structure of your EMF dataset(s)
- Learn how to combine and edit schemas for use in hale studio
- Interactively create an INSPIRE compliant EMF dataset through detailed, guided mapping instruction
You can learn more about this training, costs, and the registration process here.
(more)
From April 2021 to June 2021, we will provide tutorials, trainings, and 1:1 sessions on identifying and fixing INSPIRE compliance gaps. Here’s the schedule:
Webinars and Sessions
| Description | Date | Price | Registration |
|---|---|---|---|
 INSPIRE Solutions for Municipal Service Companies |
April 20 | free | Closed |
| GeoPackage: An alternative encoding for INSPIRE |
May 18 | free | Register here |
 Kommunale Lösungen für INSPIRE und XPlanung |
June 1 | free | Register here |
| INSPIRE Monitoring 2021: Identify Compliance Gaps |
April 1-30 | free | E-mail us |
| INSPIRE Monitoring 2021: Fix Compliance Gaps |
May 2-31 | free | E-mail us |
INSPIRE Online Trainings
| Format | Description | Audience | Date | Price |
|---|---|---|---|---|
| 15 Std. | Datentransformation nach INSPIRE mit hale»studio |
Beginners | June 14-18 | 800€ |
| 15 hrs | Transforming Data to INSPIRE with hale»studio |
Beginners | July 6–10 | 800€ |
| 8 hrs | Transformation for Environmental Monitoring Facilities |
Advanced | May 25-27 | 400€ |
| 8 hrs | Transformation for Geology and Mineral Resources |
Advanced | June 21-23 | 400€ |
| 8 hrs | Mastering complex INSPIRE transformations with Scripts |
Advanced | June 8–10 | 400€ |
XPlanung Online Trainings
| Format | Description | Audience | Date | Price |
|---|---|---|---|---|
| 1 Std. | Einführung in XPlanung und XPlanGML |
All | April 7 | free |
| 15 Std. | Datentransformation nach XPlanung mit hale»studio |
Beginners | April 26-30 | 800€ |
To sign up for other events, e-mail us at info@wetransform.to with the list of events you want to attend and your name and organization. To learn more about the trainings, visit our workshops webpage.
From April 2021 to June 2021, we will provide tutorials, trainings, and 1:1 sessions on identifying and fixing INSPIRE compliance gaps. Here’s the schedule:
Webinars and Sessions
| Description | Date | Price | Registration |
|---|---|---|---|
| INSPIRE Solutions for Municipal Service Companies |
April 20 | free | Closed |
| GeoPackage: An alternative encoding for INSPIRE |
May 18 | free | Register here |
| Kommunale Lösungen für INSPIRE und XPlanung |
June 1 | free | Register here |
| INSPIRE Monitoring 2021: Identify Compliance Gaps |
April 1-30 | free | E-mail us |
| INSPIRE Monitoring 2021: Fix Compliance Gaps |
May 2-31 | free | E-mail us |
INSPIRE Online Trainings
| Format | Description | Audience | Date | Price |
|---|---|---|---|---|
| 15 Std. | Datentransformation nach INSPIRE mit hale»studio |
Beginners | June 14-18 | 800€ |
| 15 hrs | Transforming Data to INSPIRE with hale»studio |
Beginners | July 6–10 | 800€ |
| 8 hrs | Transformation for Environmental Monitoring Facilities |
Advanced | May 25-27 | 400€ |
| 8 hrs | Transformation for Geology and Mineral Resources |
Advanced | June 21-23 | 400€ |
| 8 hrs | Mastering complex INSPIRE transformations with Scripts |
Advanced | June 8–10 | 400€ |
XPlanung Online Trainings
| Format | Description | Audience | Date | Price |
|---|---|---|---|---|
| 1 Std. | Einführung in XPlanung und XPlanGML |
All | April 7 | free |
| 15 Std. | Datentransformation nach XPlanung mit hale»studio |
Beginners | April 26-30 | 800€ |
To sign up for other events, e-mail us at info@wetransform.to with the list of events you want to attend and your name and organization. To learn more about the trainings, visit our workshops webpage.
(more)
As for many of you, 2020 wasn’t exactly easy for the team at wetransform. It would have been a challenging year even without COVID-19, given the big INSPIRE deadline in October.
In the end, the hard work and resilience paid off though: We were able to help make more than 20.000 data sets compliant with INSPIRE metadata, service, and data specifications. We almost doubled the number of customers, increased the number of user organisations by more than 180%, increased the data volume on our platform by 600%, and also doubled our annualized recurring revenue.
With this background and with the goal to enable further growth and the execution of important strategic initiatives, we decided to discuss a potential funding round with investors. As a result, we are very happy to welcome CADFEM International AG as a new investor and shareholder at Wetransform. CADFEM International AG is the international branch of CADFEM, one of the leading providers of industrial simulation solutions worldwide. CADFEM has made more than 25 investments in start-ups in various stages.
CADFEM has invested in this round together with the HTGF, Germany’s leading early-stage venture fund.
Here are some of the key initiatives that we will now execute:
- Help customers to retain optimal digital sovereignty by making hale connect compatible with GAIA-X
- Found and build up an Environmental Data Spaces community under the IDSA
- Implement ecosystem Data Spaces, e.g. for forestry, as part of the FutureForest project
Reach out to us if you are interested in being part of any of these initiatives – as a community member, pilot user, or as an employee at wetransform - we are hiring!
For now, we are looking forward to work together with all of you and with our shareholders to make sure that spatial and environmental data become more accessible, useable, and useful, and really contribute to us becoming a more sustainable society!
As for many of you, 2020 wasn’t exactly easy for the team at wetransform. It would have been a challenging year even without COVID-19, given the big INSPIRE deadline in October.
In the end, the hard work and resilience paid off though: We were able to help make more than 20.000 data sets compliant with INSPIRE metadata, service, and data specifications. We almost doubled the number of customers, increased the number of user organisations by more than 180%, increased the data volume on our platform by 600%, and also doubled our annualized recurring revenue.
With this background and with the goal to enable further growth and the execution of important strategic initiatives, we decided to discuss a potential funding round with investors. As a result, we are very happy to welcome CADFEM International AG as a new investor and shareholder at Wetransform. CADFEM International AG is the international branch of CADFEM, one of the leading providers of industrial simulation solutions worldwide. CADFEM has made more than 25 investments in start-ups in various stages.
CADFEM has invested in this round together with the HTGF, Germany’s leading early-stage venture fund.
Here are some of the key initiatives that we will now execute:
- Help customers to retain optimal digital sovereignty by making hale connect compatible with GAIA-X
- Found and build up an Environmental Data Spaces community under the IDSA
- Implement ecosystem Data Spaces, e.g. for forestry, as part of the FutureForest project
Reach out to us if you are interested in being part of any of these initiatives – as a community member, pilot user, or as an employee at wetransform - we are hiring!
For now, we are looking forward to work together with all of you and with our shareholders to make sure that spatial and environmental data become more accessible, useable, and useful, and really contribute to us becoming a more sustainable society!
(more)
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:
- Substitution of complex types through simpler types (Simple Citation, Simple Codelist Reference, Simple Geographical Name, Simplified Localized Character String…)
- Usage of related tables for elements where the allowed cardinality is greater 1
- 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:
- Keep the attribute name, but change the type to string
- In that string, write the local part of the value
- 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:
- Substitution of complex types through simpler types (Simple Citation, Simple Codelist Reference, Simple Geographical Name, Simplified Localized Character String…)
- Usage of related tables for elements where the allowed cardinality is greater 1
- 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:
- Keep the attribute name, but change the type to string
- In that string, write the local part of the value
- 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.
(more)