The Sensor Observation Service ( SOS ) is a web service to query real-time sensor data and sensor data time series and is part of the Sensor Web . The offered sensor data consists of data directly from the sensors, which are encoded in the Sensor Model Language ( SensorML ), and the measured values in the Observations and Measurements (O & M) encoding format. The web service as well as both file formats are open standards and specifications of the same name defined by the Open Geospatial Consortium (OGC).
37-459: If the SOS supports the transactional profile (SOS-T), new sensors can be registered on the service interface and measuring values be inserted. A SOS implementation can be used both for data from in-situ as well as remote sensing sensors. Furthermore, the sensors can be either mobile or stationary. Since 2007, the SOS is an official OGC standard. The advantage of the SOS is that sensor data - of any kind -
74-493: A SensorThings API compatible server. SensorThings HcDT is a JavaScript charting library for the OGC SensorThings API. It is based on the open source Highcharts library and DataTables . It is a front-end charting library enable developers to connect to datastreams from any OGC SensorThings API service, and display the sensor observations in charts, tables, or dashboard widgets for web applications. Mozilla developed
111-452: A SensorThings service. SensorThings API Part I - Sensing defines the following resources. As SensorThings is a RESTful web service, each entity can be CREATE, READ, UPDATE, and DELETE with standard HTTP verbs ( POST , GET , PATCH, and DELETE): In addition to the above sensing resources, SensorThings API Part II - Tasking Core defines the following resources: http://example.org/v1.0/Datastream(id)/Observations In order to reduce
148-551: A close relationship with ISO/TC 211 (Geographic Information/Geomatics). Volumes from the ISO 19100 series under development by this committee progressively replace the OGC abstract specification. Further, the OGC standards Web Map Service, GML, Web Feature Service, Observations and Measurements , and Simple Features Access have become ISO standards. The OGC works with more than 20 international standards-bodies including W3C , OASIS , WfMC , and
185-444: A crowd-sourced air quality sensor network. All data are publicly available via OGC SensorThings API. This citizen sensing efforts increased the number of Calgary's air quality sensors from 3 to more than 50. Smart emission is an air quality monitoring project in the city of Nijmegen, NL. The project deployed multiple air quality sensors throughout the city. Data are published with open standards, including OGC SensorThings API. Part of
222-498: A node implementation of the OGC SensorThings API. 52N SensorThingsAPI is an open source implementation of the OGC SensorThings API. Its core features are the interoperability with the 52N SOS implementing the OGC Sensor Observation Service , customizable database mappings and several convenience extensions. It can be deployed as a Docker container, inside an Apache Tomcat or as a standalone application. In 2019
259-505: A service interface, but not an implementation. There are currently several open-source implementations of the service: Also, proprietary implementations exist. Open Geospatial Consortium The Open Geospatial Consortium ( OGC ) is an international voluntary consensus standards organization that develops and maintains international standards for geospatial content and location-based services , sensor web , Internet of Things , GIS data processing and data sharing . The OGC
296-488: Is available in a standardized format using standardized operations. Thus the web-based access to sensor data is simplified. It also allows easy integration into existing Spatial Data Infrastructures or Geographic Information Systems . In 2016 OGC approved the SensorThings API standard specification, a new RESTful and JSON-based standard provide functions similar to SOS. As both SensorThings API and SOS are based on
333-626: Is based on the ISO 19156 (ISO/OGC Observations and Measurements ), that defines a conceptual model for observations, and for features involved in sampling when making observations. In the context of the SensorThings, the features are modelled as Things , Sensors ( i.e. , Procedures in O&M), and Feature of Interests . As a result, the SensorThings API provides an interoperable Observation-focus view, that
370-550: Is designed specifically for resource-constrained IoT devices and the Web developer community. It follows REST principles, the JSON encoding, and the OASIS OData protocol and URL conventions. Also, it has an MQTT extension allowing users/devices to publish and subscribe updates from devices, and can use CoAP in addition to HTTP. The foundation of the SensorThings API is its data model that
407-441: Is particularly useful to reconcile the differences between heterogeneous sensing systems (e.g., in-situ sensors and remote sensors). An IoT device or system is modelled as a Thing . A Thing has an arbitrary number of Location s (including 0 Location s) and an arbitrary number of Datastreams (including 0 Datastream s). Each Datastream observes one ObservedProperty with one Sensor and has many Observations collected by
SECTION 10
#1732856188652444-451: Is probably the most important. It can be utilized to retrieve data for specific sensors. The DescribeSensor function returns detailed information about a sensor or a sensor system and the producing processes. The OGC has - not only for the SOS - its own well-defined terminology. For better understanding, here are some important terms: The SOS is a standard of the OGC and ultimately only defines
481-528: Is stored in a PostgreSQL database. FROST-Server is an Open Source server implementation of the OGC SensorThings API. FROST-Server implements the entire specification, including all extensions. It is written in Java and can run in Tomcat or Wildfly and is available as a Docker image. Among its many features is the ability to use String or UUID based entity IDs. FROST-Client is a Java client library for communicating with
518-689: The HTTP web services paradigm for message-based interactions in web-based systems were developed and approved. These are known as the OGC Web Service Standards. These include the Web Map Service Interface Standard and the OGC Web Feature Service Interface Standard. More recently, considerable progress has been made in defining and approving a suite of Web API Standards, such as OGC SensorThings API and
555-548: The IETF . SensorThings API SensorThings API is an Open Geospatial Consortium (OGC) standard providing an open and unified framework to interconnect IoT sensing devices, data, and applications over the Web. It is an open standard addressing the syntactic interoperability and semantic interoperability of the Internet of Things. It complements the existing IoT networking protocols such CoAP , MQTT , HTTP , 6LowPAN . While
592-519: The OGC/ISO 19156:2011 , the two specifications have been demonstrated in an OGC IoT pilot that they can interoperate with each other. The SOS has three so-called core operations that must be provided by each implementation. The GetCapabilities operation allows you to query a service for a description of the service interface and the available sensor data. For using the SOS, the GetObservation function
629-621: The Sensor . Each Observation observes one particular FeatureOfInterest . The O&M based model allows SensorThings to accommodate heterogeneous IoT devices and the data collected by the devices. SensorThings API provides two main functionalities, each handled by a part. The two profiles are the Sensing part and the Tasking part. The Sensing part provides a standard way to manage and retrieve observations and metadata from heterogeneous IoT sensor systems, and
666-486: The project page . https://github.com/SensorThings-Dashboard/SensorThings-Dashboard GOST Dashboard v2 is an open source library of custom HTML elements (web components) supporting SensorThings API. These elements facilitate the development of HTML applications integrating functionality and data from SensorThings API compatible services. The components are developed with Predix-UI and Polymer . The connector enables interoperability between OGC-compliant data sources and
703-476: The Abstract Specification members have developed and continue to develop a growing number of standards to serve specific needs for interoperable location and geospatial technology, including GIS. The OGC standards baseline comprises more than 80 Standards, including: Simple Features Access, first approved in 1999, was the first full OGC Standard. Shortly after, a series of standards based on
740-484: The Eclipse Foundation and has been approved. The project is called Whiskers . Whiskers is an OGC SensorThings API framework. It will have a JavaScript client and a light-weight server for IoT gateway devices (e.g., Raspberry Pi or BeagleBone). Whiskers aim to foster a healthy and open IoT ecosystem, as opposed to one dominated by proprietary information silos. Whiskers aims to make SensorThings development easy for
777-575: The OGC API - Features Standard. The OGC has several operational units: In the OGC Standards Program the Technical Committee and Planning Committee work in a formal consensus process to arrive at approved (or "adopted") OGC standards. Learn about the standards that have been approved so far, and see the lists of products that implement these standards. The OGC Compliance Program provides
SECTION 20
#1732856188652814-648: The OGC's open standards. Technical documents, training materials, test suites, reference implementations and other interoperability resources developed in OGC Interoperability Initiatives are available on our resources page. In addition, the OGC and its members support publications, workshops, seminars and conferences to help technology developers, integrators and procurement managers introduce OGC capabilities into their architectures. The OGC offers membership options for industry, government, academic, research and not-for-profit organizations. The OGC has
851-747: The Sensing part functions are similar to the OGC Sensor Observation Service . The Tasking part provides a standard way for parameterizing - also called tasking - of task-able IoT devices, such as sensors or actuators. The Tasking part functions are similar to the OGC Sensor Planning Service . The Sensing part is designed based on the ISO/OGC Observations and Measurements (O&M) model, and allows IoT devices and applications to CREATE, READ, UPDATE, and DELETE ( i.e. , HTTP POST, GET, PATCH, and DELETE) IoT data and metadata in
888-502: The SensorThings API is published in Jazayeri, Mohammad Ali, Steve HL Liang, and Chih-Yuan Huang. "Implementation and Evaluation of Four Interoperable Open Standards for the Internet of Things." Sensors 15.9 (2015): 24343-24373 . SensorThings API was demonstrated in a pilot project sponsored by the Department of Homeland Security Science and Technology Directorate . Dr. Reginald Brothers,
925-682: The Shaken Fury operational experiment for the DHS Next Generation First Responder program depicts a scenario of an earthquake causing partial structural collapse and HAZMAT leak at a stadium. OGC SensorThings API is used as the standard interface that interconnects multiple sensors and offers an IoT enabled real-time situational awareness. On Oct 8th 2016, a group of volunteers (smart citizens) in Calgary gathered together, assembled their own sensors, installed at their houses, and formed
962-636: The Undersecretary of the Homeland Security Science and Technology, was "impressed with the ‘state of the practical’ where these various industry sensors can be integrated today using open standards that remove the stovepipe limitations of one-off technologies. " In March 2016 SensorUp and the GeoSensorWeb Lab at the University of Calgary submitted an open source software project proposal to
999-516: The above-mentioned IoT networking protocols are addressing the ability for different IoT systems to exchange information, OGC SensorThings API is addressing the ability for different IoT systems to use and understand the exchanged information. As an OGC standard, SensorThings API also allows easy integration into existing Spatial Data Infrastructures or Geographic Information Systems . OGC SensorThings API has two parts: (1) Part I - Sensing and (2) Part II - Tasking. OGC SensorThings API Part I - Sensing
1036-646: The data size transmitted over the network, SensorThings API data array extension allows users to request for multiple Observation entities and format the entities in the dataArray format. When a SensorThings service returns a dataArray response, the service groups Observation entities by Datastream or MultiDatastream, which means the Observation entities that link to the same Datastream or the same MultiDatastream are aggregated in one dataArray. http://example.org/v1.0/Observations?$ resultFormat=dataArray Interoperability between OpenIoT and SensorThings " We believe that
1073-558: The implementation of the SensorThing API will be a major improvement for the OpenIoT middleware. It will give OpenIoT a standardized and truly easy to use interface to sensor values.This will complement the rich semantic reasoning services with a simple resource based interface. And the consistent data model mapping gives both a common context to describe the internet of things ". Efficiency of SensorThings API A comprehensive evaluation of
1110-522: The large and growing world of IoT developers. GOST is an open source implementation of the SensorThings API in the Go programming language initiated by Geodan. It contains easily deployable server software and a JavaScript client. Currently (June 2016) it is in development but a first version can already be downloaded and deployed. The software can be installed on any device supporting Docker or Go (e.g. Windows, Linux, Mac OS and Raspberry Pi). By default sensor data
1147-565: The organization used the name OpenGIS Consortium . The OGC website gives a detailed history of the OGC. Most of the OGC Standards depend on a generalized architecture captured in a set of documents collectively called the Abstract Specification . The topic volumes in the Abstract Specification describe conceptual and logical models for representing geographic features , coverage data , sensors and other geographic phenomena. Atop
Sensor Observation Service - Misplaced Pages Continue
1184-413: The project is an open source ETL engine to load the project sensor data into an OGC SensorThings API. This dashboard provides easy-to-use client-side visualisation of Internet-of-Things sensor data from OGC SensorThings API compatible servers. Various types of widgets can be arranged and configured on the dashboard. It is a web application and can be embedded into any website. A live demo is available on
1221-500: The resources, procedures, and policies for improving software implementations' compliance with OGC standards. The Compliance Program provides an online free testing facility, a process for certification and branding of compliant products, and community coordination. The Compliance Program also runs plugfests, which are short term events for increasing interoperability among vendors' products. The OGC and its members offer resources to help technology developers and users take advantage of
1258-594: The semantic middleware developed in the Horizon 2020 ECSEL project AFarCloud . It is a modular Java application with Docker-based deployment, implemented according to the 15-078r6 OGC SensorThings API 1.0 Implementation Standard. SensorThings API provides functions similar to the OGC Sensor Observation Service , an OGC specification approved in 2005. Both standard specifications are under the OGC Sensor Web Enablement standard suite. The following table summarizes
1295-530: Was incorporated as a not for profit in 1994. At that time, the official name was the OpenGIS Consortium. Currently, commercial, government, nonprofit, universities, and research organizations participate in a consensus process encouraging development, maintenance, and implementation of open standards. A predecessor organization, OGF, the Open GRASS Foundation, started in 1992. From 1994 to 2004
1332-641: Was released for public comment on February 20, 2018, and it passed the TC vote on June 1, 2018. The official OGC standard specification for the SensorThings API Part II - Tasking Core was published online on January 8, 2019. In order to offer a better developer experience, the SensorThings API Part II - Tasking Core Discussion Paper was published online on December 18, 2018. The Tasking Core Discussion paper provides 15 JSON examples showing how SensorThings API Part II - Tasking Core can be used. SensorThings API
1369-512: Was released for public comment on June 18, 2015. The OGC Technical Committee (TC) approves start of electronic vote on December 3, 2015, and the SensorThings API Part I - Sensing passed the TC vote on February 1, 2016. The official OGC standard specification was published online on July 26, 2016. In 2019 the SensorThings API was also published as a United Nation's ITU-T Technical Specification. OGC SensorThings API Part II - Tasking Core
#651348