D4.3 One-pager: Framework and Standards for Data Interoperability
This deliverable presents the first version of the EDIAQI framework and standards for data interoperability. Its purpose is to define a common technical and semantic approach so that indoor air quality (IAQ) data collected in different EDIAQI pilots can be shared, accessed and interpreted in a consistent way. The framework combines machine-readable vocabularies, agreed data categories, open standards and open-source software components. This helps EDIAQI partners organise pilot data in a way that supports comparison, reuse and later analysis across the project.
Why is this topic important?
Indoor air quality data are collected in different buildings, pilot sites and countries. These measurements may come from different sensors, monitoring units, sampling methods, software tools and data platforms. Without common data structures and shared terminology, it becomes difficult to compare results between pilot sites or to combine data for project-level analysis.
This deliverable addresses that challenge by defining a shared semantic and technical framework for EDIAQI data. In practice, this means agreeing on what is measured, how each parameter is described, which units are used, how often data are sampled and reported, and how measurements are linked to buildings, rooms, sensors and locations.
For pilot coordinators, technical partners and data users, interoperability makes the collected information easier to exchange, understand, validate and reuse. It also supports the wider EDIAQI goal of making project data more Findable, Accessible, Interoperable and Reusable.
Who is this information for?
This information is especially relevant for:
- EDIAQI pilot coordinators and technical partners who need to collect, structure and share pilot data.
- Sensor and monitoring technology partners who need to align device outputs with the EDIAQI data framework.
- Data platform developers and IT specialists who work with EDIAQI databases, APIs and data services.
- Researchers and analysts who need comparable data from different pilots and campaigns.
- Local municipalities and building stakeholders who may later benefit from more consistent indoor air quality information from public buildings.
Key messages
- A common data framework is essential: EDIAQI pilot data need shared rules so that measurements from different countries, buildings and sensor systems can be compared and reused.
- Semantic interoperability is based on agreed vocabularies: EDIAQI uses machine-readable vocabularies such as EIONET, ECHA and INSPIRE/GEMET references to describe air quality parameters, measurement methods, units and building use.
- Data are organised into three main groups: the framework distinguishes between metadata, measured data and auxiliary data describing the measurement context.
- SensorThings API is the main standard for dynamic sensor data: the OGC SensorThings API is recommended for sharing real-time or frequently updated monitoring data through a standard web interface.
- Open-source tools support implementation: FROST, PostgreSQL/PostGIS, GeoServer, QGIS and 3DCityDB are identified as reference software components for implementing the interoperability framework.
- This is a first version: further work is planned in D4.7, including discovery metadata, additional vocabularies and further mapping towards CityGML or INSPIRE building data models.
What did the EDIAQI project do?
The EDIAQI project team reviewed relevant open standards and technical specifications from international and European organisations, including OGC, ISO, CEN, W3C and INSPIRE. Based on this review, the project defined a first common approach for organising and sharing EDIAQI data.
The work covered both semantic interoperability and technical interoperability. Semantic interoperability focuses on the meaning of data: parameter names, units, measurement methods, reporting values and contextual information. Technical interoperability focuses on how data are exchanged between software components, databases and web services.
The project also mapped EDIAQI concepts to the SensorThings API data model. This included entities such as Things, Locations, Features of Interest, Sensors, Observed Properties, Observations and Datastreams. In addition, the project organised four training webinars between June and October 2023 to support partners in understanding and applying the selected standards and tools.
Main findings
Finding 1: EDIAQI data need both measurements and context
The deliverable does not only define air quality parameters. It also describes auxiliary information needed to interpret measurements, such as room use, occupancy, building type, ventilation type, sensor placement, floor area and glazed surface area.
This is important because indoor air quality values are more meaningful when they are linked to the room, building and monitoring setup where they were collected.
Finding 2: SensorThings API provides the core model for dynamic monitoring data
The OGC SensorThings API is identified as the reference standard for sharing dynamic EDIAQI sensor data in a formalised and interoperable way. It allows sensor data to be transmitted through RESTful web services using HTTP or HTTPS and JSON payloads.
In the EDIAQI mapping, a monitoring unit or sampler can be represented as a Thing, the measured room or building part as a FeatureOfInterest, the measured parameter as an ObservedProperty, and each measurement value as an Observation.
Finding 3: Open-source software can implement the framework
The deliverable recommends a reference open-source software stack. FROST-Server is recommended for implementing the SensorThings API. PostgreSQL and PostGIS are recommended for storing measurements and spatial data. GeoServer is recommended for WMS and WFS services, while QGIS and SensorThings-related plugins can support data browsing and desktop analysis.
This approach supports interoperability while reducing dependence on proprietary systems.
Finding 4: Spatial information is central to EDIAQI data
EDIAQI data are linked to specific locations, buildings, rooms and monitoring points. Therefore, the framework uses geospatial standards and tools to represent where observations are made.
The deliverable also considers CityGML and INSPIRE Buildings as future target models for representing building and room-level information, especially where 3D building models or indoor spaces need to be linked to monitoring data.
Finding 5: Further development is planned in D4.7
This deliverable is Version 1 of the interoperability framework. The next version, D4.7, is expected to extend the framework by addressing discovery metadata, additional vocabularies, biological and toxicological parameters, lifestyle metadata from questionnaires, and further mapping towards CityGML or INSPIRE building models.
What does this mean in practice?
The framework helps EDIAQI partners collect and share data in a consistent way across pilots and campaigns. It supports better comparison of measurements, clearer documentation of monitoring conditions and easier reuse of project data.
For non-technical users, the main practical value is that future indoor air quality information can be presented more consistently. For technical users, the value lies in having agreed standards, data models, vocabularies and software components for implementing interoperable data services.
| User group | Practical relevance |
|---|---|
| Homeowners and tenants | The deliverable is not aimed directly at household users, but it supports the future development of clearer and more consistent indoor air quality information. Standardised units and parameter names can help avoid confusion when results are shown in dashboards or reports. |
| Schools and kindergartens | The framework supports the structured collection of air quality data together with contextual information such as room type, occupancy and ventilation. This can make it easier to interpret IAQ monitoring results in educational buildings. |
| Commercial property owners | Building owners and facility managers may benefit from more consistent monitoring data, especially when measurements are linked to room characteristics, sensor placement and building information. |
| Local municipalities | Municipalities responsible for public buildings may benefit from standardised data structures when comparing measurements across schools, kindergartens, offices or other public facilities. |
| EDIAQI technical partners | The framework provides practical guidance on how to structure, encode, share and access EDIAQI pilot data using open standards and open-source tools. |
Recommendations
- Use the agreed EDIAQI data structure: Organise pilot data into metadata, measured data and auxiliary data so that measurements can be interpreted in context.
- Apply shared vocabularies: Use the identified EIONET, ECHA and INSPIRE/GEMET references where applicable to describe pollutants, units, measurement methods and building use.
- Use SensorThings API for dynamic sensor data: Dynamic measurements from monitoring systems should be mapped to the SensorThings API model wherever relevant.
- Document the measurement context: Air quality values should be accompanied by information about the room, building, occupancy, ventilation type and sensor placement.
- Follow EDIAQI naming conventions: Use consistent identifiers for Things, Locations, Sensors, Features of Interest and Datastreams to avoid ambiguity in the data platform.
- Prefer open-source components where possible: FROST, PostgreSQL/PostGIS, GeoServer and QGIS are recommended reference tools for implementing the framework.
- Prepare for later metadata and building-model integration: Pilot teams should consider how their data could later be connected to discovery metadata, CityGML or INSPIRE Buildings models.
Limitations
This deliverable represents the first version of the EDIAQI interoperability framework. At this stage, the semantic framework focuses mainly on physical and chemical air quality parameters.
Several elements are planned for later development. These include indoor biological parameters, indoor toxicological parameters, lifestyle metadata from questionnaires, additional outdoor air pollution semantics from external sources, discovery metadata for making data more findable, and further mapping towards CityGML or INSPIRE Buildings models.
The document is mainly technical and is intended to guide the organisation, exchange and reuse of data. It does not provide health-based threshold values, direct policy recommendations or detailed instructions for improving indoor air quality in buildings.
Related wiki pages
[+] View technical source and page metadata
Source deliverable
This one-pager is based on:
- Deliverable: D4.3 – Framework and standards for data interoperability – version 1
- Work Package: WP4 – Pilots, data and campaigns
- Lead partner: DEDA / DedaNext
- Original deliverable type: R – Document, report
- Dissemination level: PU – Public
- Official submission date: 30 November 2023
- Actual submission date: 15 December 2023
Page information
- One-pager prepared by: TalTech EDIAQI Wiki Team
- Checked against source deliverable: D4.3 – Framework and standards for data interoperability – version 1
- Last updated: May 2026
- Page status: Draft for wiki publication