Extending INSPIRE to the Internet of Things through SensorThings API
2.1. INSPIRE in a Nutshell
2.1.1. Observation Data
- Environmental Monitoring FacilitiesThe INSPIRE EF model can be broken down into three interdependent parts (Figure 2) as follows:
- A description of the Environmental Monitoring Facility (blue classes)
- A description of the measurement methodology, referenced by both the Environmental Monitoring Facility and the Observations (green classes)
- Observations providing the actual spatio-temporal data (red class)
- Observation ModelIn addition to the data specification detailing what information related to an Environmental Monitoring Facility is to be provided, the Observation Model provides specifications for concepts that go beyond the EF Theme. The observation model is based on the ISO 19156:2011 (Geographic information—observations and measurements) standard .Structurally, the Observation model is subdivided into four sub-packages (Figure 3):
- Package 1. Specialised Observations. Specialisations of the base O&M Observation have been defined through the application of constraints. Specialised observations provide an approach that is tailored to the needs of a multitude of environmental use cases. The following types of observations are defined in :
- Profile observation: Observation representing the measurement of a property along a vertical profile in space at a single time instant.
- Trajectory observation: Observation representing the measurement of a property along a meandering curve in time and space.
- Point observation: Observation that represents a measurement of a property at a single point in time and space.
- MultiPointObservation: Observation that represents a set of measurements all made at exactly the same time but at different locations.
- Specimen observation: Observation that represents a measurement of a property of a Specimen at a single point in time.
- GridObservation: Observation representing a gridded field at a single time instant.
- GridSeriesObservation: Observation representing an evolving gridded field at a succession of time instants.
- Package 2. Observable Properties. The INSPIRE Observable Properties model allows for the specification of complex properties. The complex properties enable the creation of composite properties, for the joint provision of strongly linked properties, e.g., wind speed and direction. Further options provided by the INSPIRE Observable Properties model include the description of various statistical aggregates being provided, as well as the provision of constraints on the types of result values that may be provided.
- Package 3. Processes. Within the OGC SWE, SensorML  is the preferred method for the provision of information on the measurement process. However, this model is quite abstract and not easy to understand and use. Thus, within INSPIRE, a simple feature type has been defined for the provision of information on the measurement process. This feature type is integrated within the EF model, and is presented in Figure 3.
- Package 4. Observation References. The Observation References section of the Observation Model provides the mechanisms required for linking between features and OM_Observation object. Thus, an Environmental Monitoring Facility can provide association references to observations stemming from this facility. In the same manner, an OM_Observation can provide a reference to the facility at which the observation was made.
2.1.2. Download Services
- A pre-defined data set shall have a metadata record, and be discoverable through an INSPIRE conformant discovery service.
- A resolvable link (URL) must be provided, allowing that the dataset be immediately downloaded through a simple HTTP-protocol GET-request.
2.2. The OGC SensorThings API
2.2.1. The Data Model
2.2.2. RESTful Interface
3. SensorThings API for INSPIRE
3.1. Alignment of Data Specifications
- Point observation: Datastream with one Observation pertaining to a single FeatureOfInterest.
- Point Time Series Observation: Datastream with multiple Observations over time pertaining to a single FeatureOfInterest.
- Multi Point Observation: Datastream with multiple Observations pertaining to different FeaturesOfInterest. Some additional grouping of the FeaturesOfInterest may be required.
- Grid Observation: Datastream with one Observation providing a complex result, FeatureOfInterest is a Grid. The Coverage Implementation Schema (CIS 1.1) should be explored for the provision of gridded coverages, as GeneralGridCoverage seems well suited for this purpose, and a JSON encoding is provided.
- Grid Series Observation: Datastream with multiple Observations providing complex results, FeatureOfInterest is a Grid. CIS 1.1  should be explored for the provision of gridded coverages, as GeneralGridCoverage seems well suited for this purpose, and a JSON encoding is provided.
- Profile Observation: Depending on the type of Profile, various options exist for encoding via the SensorThings API. These range from the model sketched for Multi Point Observation, whereby all FeaturesOfInterest must share the same values for Lat/Long, over the use of a MultiDatastream providing a depth indicator (depth in m or pressure) as a second ObservedProperty to the utilization of grid types as specified within the constraints on the INSPIRE model.
- Trajectory Observation: Datastream with multiple Observations with a varying FeatureOfInterest. Some additional grouping of the FeaturesOfInterest may be required in order to expose the trajectory to client applications.
3.2. Download Service Operations
3.2.1. Pre-Defined Dataset
- Capabilities for SensorThings API services. The standard provides a RESTful API for access to data. This is a convenient approach which allows easy uptake and immediate use by mainstream developers. The GetCapabilities operation included in the majority of OGC standards is not available. A solution for INSPIRE might be to use the OpenAPI standard (former Swagger)  to document the service, considering the required, mostly static, elements of the Get Download Service Metadata and Describe Spatial Dataset operations.
- Dataset in SensorThings API. The concept of a “dataset” does not exist in the SensorThings API standard. If following our proposal to equalise a dataset to a “Datastream”, it should represent a logically consistent grouping of individual observations.
- Support for request parameters. Request parameters are defined in  for the Get Spatial Dataset operation. Users should be able to request their datasets or spatial objects in any of the: (i) offered coordinate reference systems (CRS); and (ii) natural languages; and (iii) through their spatial data set identifier. The REST-like interface of SensorThings API does not support the first two parameters.
3.2.2. Direct Access
4. Discussion and Conclusions
- Definition of a dataset. Datasets in INSPIRE should include observations for a predefined period of time and for logically consistent geographical entities usually observed by the same procedure. Similar to SOS, the concept of a dataset is unknown to the SensorThings API. This we see as a broader issue that should be addressed within INSPIRE.
- SensorThings API Extension Points. The data model of the SensorThings API has been concisely tailored to the requirements of sensors within the IoT while the INSPIRE data specifications require the provision of additional contextual information as required within an SDI. While some attributes required by INSPIRE can be directly aligned with attributes from the SensorThings API, additional attributes are required. For this purpose, we utilized the currently proposed extension (Appendix A) to the SensorThings API 1.1, whereby a properties attribute of type JSON_Object, as presently provided by the class Thing, is appended to the classes Datastream and Sensor. All additional requirements stemming from INSPIRE can be supported by providing this within the JSON properties structure; for FeatureOfInterest, the feature attribute serves the same purpose.
- Metadata for services. The SensorThings API provides a RESTful API for simultaneous access to both data and metadata, thus the API does not require a separate operation to request metadata. However, the INSPIRE Directive mandates such an operation. Considering the fact that the vast majority of required metadata elements are static, it would be fairly easy to document STA services through the OpenAPI specification . Technical guidance should be released to describe such an approach.
- Request for CRS and Language. As outlined in Section 3.2, requesting datasets or individual observations in a particular natural language or coordinate reference system is not supported by SensorThings API. Satisfying this requirement would require a workaround that goes beyond the current version of the standard. When addressing the issue of CRS in particular, two aspects should be considered. Firstly, the provision of functionality for requesting CRS would add complexity to the service interface which might be conflicting with the overarching objective of the standard to be as developer friendly as possible. Secondly, the SensorThings API suggests GeoJSON for data encoding, and the conformance tests only test with it. This requirement poses a limitation, as all coordinates shall be provided in a geographic coordinate reference system, using the World Geodetic System 1984 datum .
- Comparison with other download services. Thus far, we analysed the SensorThings API from a legislative and technical perspective without going deeper into the analysis of how our proposed solution would fit with the rest of the implementations in the pan-European spatial data infrastructure. This deserves to be further investigated from at least two angles: (i) comparison with other possible solutions such as SOS and WFS; and (ii) approaches combining two or more solutions, e.g., where static data are handled through a WFS, and SensorThings API handles the spatio-temporal data.
- Specialised observation types. INSPIRE defines a set of specialised observation types (Section 3). For some, such as the Point observation and Point Time Series Observation, implementation options are quite straightforward. Others, foremost those pertaining to grids such as the Grid Observation and Grid Series observation, but also Profile observation and Trajectory observation, would require additional attention. For the provision of observations pertaining to grids (Grid Observation and Grid Series observation), available grid encoding standards must be analysed for suitability. CIS 1.1  seems promising in this regard. For the encoding of Multi Point Observation, Profile Observation and Trajectory Observation methods for grouping a set of FeaturesOfInterest should be explored, as such a mechanism would provide easier handling for client applications. For the provision Profile Observation, alternatives utilising MultiDatastreams or Grids should also be taken into consideration.
- Asynchronous transactions for INSPIRE download services. The SensorThings API offers out-of-the-box functionality for publish–subscribe-based messaging through the use of MQTT . At the same time, INSPIRE is, legislatively, bound to the request–response paradigm for data exchange. Given the rapid development of the IoT with its constraint devices where the latency of networks is challenging, the use of publish–subscribe services should be further investigated.
- Sensor Tasking. The possibility to assign tasks to environmental sensors in a standardised manner goes beyond the legal requirements of INSPIRE. However, considering the rapid growth of the number of connected IoT devices, this would be a very interesting, particularly for the planning and implementation of measurement campaigns. Within this context, the “SensorThings API, Part 2—Tasking Core” Candidate Standard  is to be investigated.
- Other standards. From our perspective, the approach, demonstrated in this paper, for analysing possible technological solutions for INSPIRE is applicable for other standards as well. Most prominent from that perspective would be to investigate the emerging Web Feature Service 3.0 (WFS 3.0)  as a potential INSPIRE solution.
Conflicts of Interest
|API||Application Programming Interface|
|CIS||Coverage Implementation Schema|
|CRS||Coordinate Reference System|
|CSW||Catalogue Service for the Web|
|EF||Environmental Monitoring Facilities|
|GNU||GNU General Public License|
|IoT||Internet of Things|
|ISO||International Organization for Standardization|
|MQTT||Message Queuing Telemetry Transport|
|OData||Open Data Protocol|
|RDBMS||Relational Database Management System|
|SDI||Spatial Data Infrastructure|
|SDK||Software Development Kit|
|SWE||OGC Sensor Web Enablement Suite|
|WFS||Web Feature Service|
|XML||Extensible Markup Language|
Appendix A. Alignment of INSPIRE EF Requirements to SensorThings API
Appendix A.1. EF SamplingPoint
|Environmental Monitoring Facility||Class||Attribute||CR on ST Part 1 for Properties Extension|
|operational Activity Period||THINGS||PROPERTIES||X|
Appendix A.2. Process
|Type||Class||Attribute||CR on ST Part 1 for Properties Extension|
Appendix A.3. Feature of Interest
|Type||Class||Attribute||CR on ST Part 1 for Properties Extension|
Appendix A.4. Observation
Appendix B. Sample requests to SensorThings API Services
Appendix B.1. Request of an Air Temperature and Humidity Dataset
Appendix B.2. Request of a Water Level Dataset
- European Commission. Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 Establishing an Infrastructure for Spatial Information in the European Community (INSPIRE); European Parliament and of the Council of the European Union: Brussels, Belgium, 2007. [Google Scholar]
- European Commission. Building a European Data Economy. Communication from the Commission 2017. Available online: https://eur-lex.europa.eu/content/news/building_EU_data_economy.html (accessed on 22 February 2018).
- Botts, M.; Percivall, G.; Reed, C.; Davidson, J. OGC® sensor web enablement: Overview and high level architecture. In GeoSensor Networks; Springer: Berlin/Heidelberg, Germany, 2008; pp. 175–190. [Google Scholar]
- Bröring, A.; Jirka, S.; Kotsev, A.; Spinsanti, L. Making the sensor observation service INSPIRE compliant. In Proceedings of the INSPIRE Conference 2013, Florence, Italy, 23–27 June 2013. [Google Scholar]
- Technical Guidance for Implementing INSPIRE Download Services Using the OGC Sensor Observation Service and ISO 19143 Filter Encoding. Available online: https://inspire.ec.europa.eu/id/document/tg/download-sos (accessed on 1 June 2018).
- Eric Schmidt: Every 2 Days We Create As Much Information As We Did Up To 2003. Available online: https://techcrunch.com/2010/08/04/schmidt-data/?guccounter=1 (accessed on 1 June 2018).
- Lutz, M.; Bernard, L.; Portele, C.; Hansen, T.; Tiainen, E.; Lucchi, R. INSPIRE – What if? Summary report from the What if…? sessions at the 2017 INSPIRE Conference. Available online: https://ec.europa.eu/jrc/en/publication/inspire-what-if-summary-report-what-if-sessions-2017-inspire-conference (accessed on 30 April 2018).
- Liang, S.; Huang, C.Y.; Khalafbeigi, T. OGC SensorThings API-Part 1: Sensing. OGC® Implementation Standard. 2016. Available online: http://docs.opengeospatial.org/is/15-078r6/15-078r6. html (accessed on 14 June 2018).
- Cetl, V.; Tomas, R.; Kotsev, A.; de Lima, V.N.; Smith, R.S.; Jobst, M. Establishing Common Ground through INSPIRE: The Legally-Driven European Spatial Data Infra-Structure; Springer Lecture Notes in Geoinformation and Cartography; Springer: Cham, Germany, 2018. [Google Scholar]
- Guidelines for the use of Observations and Measurements and Sensor Web Enablement-related standards in INSPIRE. Available online: inspire.ec.europa.eu/id/document/tg/d2.9-o&m-swe/3.0 (accessed on 14 June 2018).
- Open Geospatial Consortium (OGC). Sensor Observation Service Interface Standard; Open Geospatial Consortium Interface Standard; Open Geospatial Consortium (OGC): Wayland, MA, USA, 2012; 12-006. [Google Scholar]
- INSPIRE Data Specification on Environmental Monitoring Facilities—Technical Guidelines. Available online: https://inspire.ec.europa.eu/id/document/tg/ef (accessed on 10 April 2018).
- ISO/TC211. ISO 19156: 2011-Geographic Information–Observations and Measurements-International Standard; International Organization for Standardization: Geneva, Switzerland, 2011. [Google Scholar]
- Botts, M.; Robin, A. OpenGIS Sensor Model Language (SensorML) Implementation Specification; OpenGIS Implementation Specification OGC: Wayland, MA, USA, 2007. [Google Scholar]
- European Commission. COMMISSION REGULATION (EU) No 1088/2010 of 23 November 2010 Amending Regulation (EC) No 976/2009 as Regards Download Services and Transformation; European Parliament and of the Council of the European Union: Brussels, Belgium, 2010. [Google Scholar]
- ISO/IEC 20922:2016, Information Technology—Message Queuing Telemetry Transport (MQTT) v3.1.1. Available online: https://www.iso.org/standard/69466.html (accessed on 10 February 2018).
- Grothe, M.; Broecke, J.V.; Carton, L.; Volten, H.; Kieboom, R. Smart Emission: Building A Spatial Data Infrastructure for aN Environmental Citizen Sensor Network. In Proceedings of the Geospatial Sensor Webs Conference 2016 (GSW 2016), Münster, Germany, 29–31 August 2016. [Google Scholar]
- Soto, J.A.; Werner-Kytölä, O.; Jahn, M.; Pullmann, J.; Bonino, D.; Pastrone, C.; Spirito, M. Towards a federation of smart city services. In Proceedings of the International Conference on Recent Advances in Computer Systems (RACS 2015), Hail, Saudi Arabia, 30 November–1 December 2015; pp. 163–168. [Google Scholar]
- Trilles, S.; Luján, A.; Belmonte, Ó.; Montoliu, R.; Torres-Sospedra, J.; Huerta, J. SEnviro: A sensorized platform proposal using open hardware and open standards. Sensors 2015, 15, 5555–5582. [Google Scholar] [CrossRef] [PubMed][Green Version]
- Huang, C.Y.; Wu, C.H. A Web Service Protocol Realizing Interoperable Internet of Things Tasking Capability. Sensors 2016, 16, 1395. [Google Scholar] [CrossRef] [PubMed]
- SensorThings API Part 2—Tasking. Available online: http://www.opengeospatial.org/pressroom/pressreleases/2739 (accessed on 24 April 2018).
- ISO/IEC 20802-1:2016. Open Data Protocol (OData). Available online: https://www.iso.org/standard/69208.html (accessed on 24 April 2018).
- INSPIRE Generic Conceptual Model. Available online: https://inspire.ec.europa.eu/documents/Data_Specifications/D2.5_v3.4rc3.pdf (accessed on 24 April 2018).
- OGC Coverage Implementation Schema (CIS) v1.1. Available online: http://docs.opengeospatial.org/is/09-146r6/09-146r6.html (accessed on 24 April 2018).
- OGC Naming Authority. Available online: http://www.opengis.net/def/observationType/OGC-OM/2.0/ (accessed on 24 April 2018).
- Nogueras-Iso, J.; Zarazaga-Soria, F.J.; Béjar, R.; Álvarez, P.; Muro-Medrano, P.R. OGC Catalog Services: A key element for the development of Spatial Data Infrastructures. Computers & Geosciences 2005, 31, 199–209. [Google Scholar]
- OpenAPI Specification. Available online: https://github.com/OAI/OpenAPI-Specification (accessed on 10 March 2018).
- Butler, H.; Daly, M.; Doyle, A.; Gillies, S.; Hagen, S.; Schaub, T. The Geojson Format; Technical report; Internet Engineering Task Force (IETF): Fremont, CA, USA, 2016. [Google Scholar]
- Web Feature Service 3.0 and Filter Encoding Standards. Available online: https://github.com/opengeospatial/WFS_FES (accessed on 10 March 2018).
|Name||Service type||Type of data|
|1. ATOM Syndication Format||Pre-defined||Whole datasets|
|2. WCS 2.0 (Web Coverage Service)||Pre-defined and direct access||Coverages (including multidimensional)|
|3. WFS 2.0 (Web Feature Service)||Pre-defined and direct access||Spatial features (vector)|
|4. SOS 2.0 (Sensor Observation System)||Pre-defined and direct access||Spatio-temporal observations|
|INSPIRE Feature Type||Definition||SensorThings API Entity||Comments|
|1. Environmental Monitoring Facility||A georeferenced object directly collecting or processing data about objects whose properties (e.g., physical, chemical, biological or other aspects of environmental conditions) are repeatedly observed or measured. Can also host other environmental monitoring facilities.||“Thing’ and “Location’||The ObservingCapability FeatureType associated to the Environmental Monitoring Facility via composition corresponds to a “Datastream’.|
|2. Feature Of Interest||Feature that is the subject of the observation, and carries the observed property being investigated.||“FeatureOfInterest’|
|3. Observed Property||The Property Type for which the OM_Observation:result provides an estimate of its value.|
|4. Process||Process used to generate the result.||“Sensor’|
|5. OM_Observation||Links the domain and range of the observation being described, together with all relevant metadata required for the interpretation of this observation.||“Datastream’ and “Observation’|
|Service operation||Definition||Mapping to SensorThings API|
|1. Get Download Service Metadata||Provides all necessary information about the service, the available Spatial Data Sets, and describes the service capabilities.||OpenAPI  document. This would require a mapping of the relevant (mostly static) contents of OGC GetCapabilities responses to OpenAPI.|
|2. Get Spatial Dataset||Retrieval a dataset as a whole, as defined by the data provider||The simplest option would be to map this operation to “Datastreams”, i.e., each datastream to deliver an INSPIRE dataset that is described separately through metadata. As a difference to the SOS offering concept , the datasets defined by the SensorThings API are restricted to one observed property. Thus, “MultiDatastreams” shall be used if the dataset contains more than one “ObservedProperty’. Alternatively, the powerful query mechanism of SensorThings API can be used to request information spread into multiple “Datastreams”, including “Observations’, “Observed Properties”, “Thing”, “Locations” and “FoI”, all filtered by time interval, area, or other criteria. Sample requests are provided in Appendix B.|
|3. Describe Spatial Dataset||Description of metadata about a dataset and all types of Spatial Objects contained in the Spatial Dataset.||This can be mapped to: (i) “Datastream” if the dataset consists of a single ObservedProperty; and (ii) “MultiDatastream” if the dataset contains more than one ObservedProperty.|
|4. Link Download Service||Allows the declaration of the availability of a Download Service while maintaining the downloading capability at the Public Authority or a Third Party location.|
|Service operation||Definition||Mapping to SensorThings API|
|1. Get Spatial Object||Retrieval of Spatial Objects based upon a query.||Request that resolves to an Observation entity in a collection together with its id.|
|2. Describe Spatial Object Type||Description of the specified Spatial Objects types.||Metadata provided as part of the Datastreams or Observations downloaded from a SensorThings API endpoint.|
|3. Link Download Service||Allows the declaration of the availability of a Download Service while maintaining the downloading capability at the Public Authority or a Third Party location.|
© 2018 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
Share and Cite
Kotsev, A.; Schleidt, K.; Liang, S.; Van der Schaaf, H.; Khalafbeigi, T.; Grellet, S.; Lutz, M.; Jirka, S.; Beaufils, M. Extending INSPIRE to the Internet of Things through SensorThings API. Geosciences 2018, 8, 221. https://doi.org/10.3390/geosciences8060221
Kotsev A, Schleidt K, Liang S, Van der Schaaf H, Khalafbeigi T, Grellet S, Lutz M, Jirka S, Beaufils M. Extending INSPIRE to the Internet of Things through SensorThings API. Geosciences. 2018; 8(6):221. https://doi.org/10.3390/geosciences8060221Chicago/Turabian Style
Kotsev, Alexander, Katharina Schleidt, Steve Liang, Hylke Van der Schaaf, Tania Khalafbeigi, Sylvain Grellet, Michael Lutz, Simon Jirka, and Mickaël Beaufils. 2018. "Extending INSPIRE to the Internet of Things through SensorThings API" Geosciences 8, no. 6: 221. https://doi.org/10.3390/geosciences8060221