INSPIRE Environmental Monitoring Facilities: Observations and Measurements
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.