OpenSensorHub Demo Links

These example links demonstrate how to access OpenSensorHub (OSH) web services directly from a browser or through apps. One should examine the structure of the URL request as well as the response. These web services are conformant with the Open Geospatial Consortium (OGC) Sensor Web Enablement (SWE 2.0) encoding and web service interface standards.

Accessing OSH through Apps or Browser Clients

As a user of OSH services, most of your interactions may be limited to using browser clients that have been built or customized to meet your specific needs. An example of such a client is provided in the following link which uses a browser-based client (written in JavaScript) to retrieve and replay previously captured dashcam video and GPS locations.

or perhaps this browser client showing streaming results from a simulated weather station.

Other example clients are showcased on the following page:

Accessing OSH directly using HTTP GET requests

If you desire to directly interact with the OSH web services or if YOU are the developer of one of these browser clients or apps, then you will need to learn to "speak SWE" or use one of the libraries designed to hide these details from you. Examples of the most used web request ("speaking SWE") include:

Service Metadata

Simulated GPS

Simulated Weather Station

UAV Navigation Data

Mastering Time

OpenSensorHub allows for a variety of temporal requests, including accessing the latest measurement, opening a data stream of real-time measurements, requesting archived measurements within a custom time range, and accessing archived data streamed at a particular playback speed. NOTE: Some of these examples suffer from the browser/javascript buffer delay discussed below in "HTTP vs. Web Sockets". Use web sockets for immediate access to streaming values.

HTTP vs. WebSockets

One can set up a datastream using either persistent HTTP or web sockets. In our experience, when one sets up data streaming using persistent HTTP in a web browser or JavaScript app, there is often a caching delay before the data values can be accessed by the app and displayed. The values have already been send and received, but are not yet made available to the application. It is also cumbersome to parse a never ending stream of data using the browser AJAX APIs. Using WebSockets solves both issues because it is designed for real-time bi-directional streaming between server and client.

Handling Video

The same SWE protocols can be used to stream real-time or archived video. The following requests allow you to query the video codec used in the stream and then request the video stream in exactly the same way it was done before for other types of data. Notice that the data description indicates that the stream is binary encoded with JPEG (MJPEG) codec this time.
(*) Video streamed from raw GetResult will only show in Firefox and Safari

Filtering by Feature Of Interest

The concept of features of interest (FOI) is used in SOS to identify a particular member of a sensor network. You can filter measurements using the ID of one more several FOIs. The following examples illustrate this with Automated Vehicle Location (AVL) data that was acquired for several emergency vehicles. One can first retrieve the list of vehicles (FOIs) available and then retrieve GPS data either for a single vehicle or for several vehicles at once. Notice that the vehicle ID is present in the output stream so that the data can be properly demultiplexed.

JSON Support

JSON format is supported since v1.2 of OpenSensorHub. It is now possible to retrieve both metadata and data streams as JSON. This is an extension to the SOS standard that is pending approval at OGC.

Result Streams vs. Observations

The SOS interface allows one to retrieve data as compact record streams or as complete observation objects. Although it is much more bandwidth intensive and verbose, in some use cases, retrieving complete observations is useful because it allows attaching advanced metadata with each observation. When advanced observation metadata is not used/needed, we clearly encourage you to use the GetResult operation at it is much more efficient on the wire and much faster/easier to parse.