i. Abstract

The Incident Management Information Sharing (IMIS) Internet of Things (IoT) Pilot established the following objectives:

•        Apply OGC principles and practices for collaborative development to existing standards and technology to prototype an IoT approach to sensor use for incident management;

•        Employ an agile methodology for collaborative development of system designs, specifications, software and hardware components of an IoT-inspired IMIS sensor capability;

•        Develop profiles and extensions of existing Sensor Web Enablement (SWE) and other distributed computing standards to provide a basis for future IMIS sensor and observation interoperability; and

•        Prototype capabilities documented in engineering reports and demonstrated in a realistic incident management scenario.

Based on the findings gathered during the implementation and work on these objectives, this Engineering Report describes recommendations on profiles for OGC Web services that shall be used to build IMIS systems.

ii. Business Value

The IMIS IoT Pilot aimed to develop, test and demonstrate the use of networked sensor technologies in a real-world scenario developed in collaboration with the Department of Homeland Security and first responder stakeholders. This pilot demonstrated an IoT approach to sensor use for incident management. Prototype capabilities include ad hoc, nearly automatic deployment, discovery and access to sensor information feeds, as well as derivation of actionable information in common formats for use in computer aided dispatch, emergency operations centers and geographic information systems, as well as mobile devices.

Within this Engineering Report, guidance and recommendations on profiles for OGC Web services in IMIS systems are provided. These recommendations shall help to further advance the applicability of OGC Web services in incident management and thus increase interoperability within this domain.

iii. Keywords

ogcdocs, imis iot pilot, sensor web

1       Introduction

This Engineering Report (ER) provides findings of the Open Geospatial Consortium (OGC) Incident Management Information Sharing (IMIS) Internet of Things (IoT) Pilot on profile recommendations for OGC standards. During the IMIS IoT Pilot several OGC standards were implemented and applied with the aim to develop, test and demonstrate the use of networked sensor technologies in a real-world scenario.

One important result of these implementation and testing activities was a set of experiences and ideas for improvements for applying the selected OGC standard in emergency management scenarios. This ER documents these findings. For each standard applied within the IMIS IoT Pilot the different implementations and resulting experiences are introduced. From these finding this document derives several recommendations for optimizing future versions of the used OGC standards or defining profiles for increasing interoperability.

1.1           Scope

This OGC® document gives guidelines and recommendations on the development of profiles for OGC standards to support IMIS based on IoT and Sensor Web technology. It summarizes the corresponding findings of the OGC IMIS IoT Pilot.

1.2           Document Contributor Contact Points

All questions regarding this document should be directed to the editor or the following contributors:

1.3           Revision History

1.4           Future Work

This ER is intended to provide recommendations on the development of IMIS profiles of different OGC standards. Thus, the recommendations on future work can be found at the end of each section.

1.5           Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The OGC shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

2       References

The following documents are referenced in this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

OGC 06-121r3, OGC^® Web Services Common Standard

OGC 06-042, OGC^®Web Map Service (WMS)

OGC 07-006r1, OGC^®Catalog Services

OGC 08-094r1, OGC^®SWE Common Data Model

OGC 09-001, OGC^®SWE Service Model

OGC 09-025r2, OGC^®Web Feature Service (WFS)

OGC 10-025r1, OGC^®Observations and Measurements (O&M) - XML Implementation

OGC 12-000, OGC^®Sensor Model Language (SensorML)

OGC 12-006, OGC^®Sensor Observation Service (SOS)

OGC 14-065, OGC^®Web Processing Service (WPS)

NOTE            This OWS Common Standard contains a list of normative references that are also applicable to this Implementation Standard.

In addition to this document, this report includes several Extensible Markup Language (XML) files as specified in Annex A.

3       Terms and Definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard [OGC 06-121r3] shall apply.

4       Conventions

4.1           Abbreviated Terms

API                 Application Program Interface

AVL                Automated Vehicle Location

AWS               Amazon Web Services

CSW                Catalog Service for the Web

EML               Event Pattern Markup Language

ER                   Engineering Report

GML               Geography Markup Language

IMIS               Incident Management Information Sharing

IoT                  Internet of Things

JSON              Java Script Object Notation

KVP                Key-Value Pair

MQTT            Message Queue Telemetry Transport

O&M              Observation & Measurements

OSH                OpenSensorHub

OWS               OGC Web Services

POX                Plain Old XML

PTZ                Pan–Tilt–Zoom

SAS                 Sensor Alert Service

SES                  Sensor Event Service

SensorML       Sensor Model Language

SLD                 Styled Layer Descriptor

SOS                 Sensor Observation Service

STA                Sensor Things API

SWE                Sensor Web Enablement

UAS                Unmanned Aerial Sensor

URI                 Uniform Resource Identifier

URL                Uniform Resource Locator

UUID              Universally Unique Identifier

WEPS              Web Event Processing Service

WFS                Web Feature Service

WMS              Web Map Service

WPS                Web Processing Service

XML               Extensible Markup Language

4.2           Unified Modeling Language Notation

Most diagrams that appear in this ER are presented using the Unified Modeling Language (UML) static structure diagram, as described in Subclause 5.2 of [OGC 06-121r3].

5       Overview of Existing Standards

This section provides an overview on the existing standards that have been applied in the IMIS IoT Pilot (for an overview on the architecture see the OGC IoT Architecture ER (OGC 16-014)). The overview is divided into two subsections: Section 5.1 gives an overview on the standards for data models and encodings and Section 5.2 introduces the different standards specifying the service interfaces.

5.1           Overview on Data Models and Encoding Standards

The Geography Markup Language (GML) Encoding Standard (OGC 07-036) defines a modelling language for geographic information and XML encoding for transferring geographic information between applications. While GML defines the models and encodings for geometries of geographic features such as points, lines and polygons, it does not prescribe the attributes of these features. Therefore, domain-specific application profiles should be defined.

One such profile is the Observations & Measurements (O&M) standard, which has been defined within the Sensor Web Enablement (SWE) initiative for exchanging observation data. It consists of two specifications: the conceptual model (OGC 10-004r3/ISO 19156) is based on the general feature model and defines basic properties of observations, e.g., temporal attributes, information about the procedure used to generate the observation result, or the observed property. It also defines a model for sampling features. XML encodings for basic observation types defined in the conceptual model are specified in the O&M XML Implementation Standard (OGC 10-025r1).

Observations encoded in O&M contain a reference to the procedure used to generate the observation result. The description of this procedure is usually provided using the Sensor Model Language (SensorML, OGC 12-000). SensorML defines a model and XML encoding for processes associated with the measurement and post-transformation of measured values. These processes may be implemented as sensors, actuators or computational processes. Both, O&M and SensorML, rely on a common model for describing and encoding sensor data (streams), the SWE Common Data Model (SWE Common, OGC 08-094r1).

Finally, for transferring data from the low-level devices to OGC services and vice versa and for sending tasking information to such devices, the Message Queue Telemetry Transport (MQTT) protocol has been used. It has become an OASIS standard in v3.1.1[1]. MQTT defines a lightweight publish/subscribe messaging protocol for Machine to Machine (M2M) communication and is hence in particular used for IoT applications.

5.2           Overview on Service Interface Standards

The OGC Web Service Common (OWS Common) Standard (OGC 06-121r9) specifies aspects that are common to all OGC interface standards. These include the definition of the GetCapabilities operation and the Capabilities response structure as well as the definition of XML and Key-Value Pair (KVP) encodings of operation requests and responses. Each service described below builds upon these common aspects specified in OWS Common.

The OGC Catalog ServiceImplementation Specification (OGC 07-006r1) has been defined to enable clients to publish and/or discover geospatial datasets and services and to provide the metadata needed to decide whether clients could use these datasets and services. The standard specifies interfaces and bindings for publishing and accessing digital catalogs of metadata for geospatial data, services and related resource information. The interface provides operations for managing the metadata records, e.g., for harvesting records, as well as operations for discovering the metadata records, e.g., for describing record types or querying certain records.

For publishing and retrieving maps as images, e.g., for providing background maps or pre-rendered satellite data, the OGC has defined the OpenGIS Web Map Server (WMS) Implementation Specification (OGC 06-042). A WMS lists its available map layers in the Capabilities document and allows retrieving these layers with several query parameters, e.g., BoundingBox, using the GetMap operation. The optional GetFeatureInfo operation allows providing additional information for a certain pixel.

The Web Feature Service (WFS, OGC 09-025r1/ISO 19142) specifies a service interface for retrieving geographic features (vector data) encoded in GML. The supported feature types are listed in the Capabilities document. A description of a certain feature type can be retrieved using the DescribeFeatureType operation. The central operation is the GetFeature operation that allows querying features from a WFS server. Further optional operation are specified, for example the Transaction operation for inserting, updating or deleting features.

While the WFS specifies a general interface for access to geographic features, the Sensor Observation Service (SOS, OGC 12-006) defines an interface for the pull-based retrieval of sensor observations and sensor descriptions. It thereby utilizes the models and encodings defined by the O&M, SWE Common Data, and SensorML standards (see above). Available observation datasets are described with spatial and temporal extents, generating procedures (usually sensors) and observed properties in the capabilities document of the service. Using the DescribeSensor operation, clients can retrieve relevant metadata about sensors encoded in SensorML.[2] The GetObservation operation is the core operation for retrieving observations using several optional filters for different observation properties. Several extensions exist for transactional retrieval or result handling in case the same request and response metadata should not be repeated in each request and response message. For example, results from sensors and processes can also be retrieved in a highly efficient data stream, using the GetResultTemplate and GetResult requests. The GetResultTemplate is usually called once by a client to get a SWE Common-based data description of the data structure and encoding for a particular offering. Subsequent GetResult requests return only the values of the observations according to the record structure and encoding described in the GetResultTemplate response. The GetResult request can also support continuous data streaming.

Similar to SOS, the Sensor Things API (STA)[3]provides an interface for the retrieval of observation data relying on the Observations and Measurements (O&M) model of sensor information. In contrast to SOS, the STA interface relies fundamentally on Representational State Transfer (REST) principles and specifies Java Script Object Notation (JSON) as encoding for the observations. As such, it is lightweight and eases the development of browser-based client applications for developers who favor REST and JSON approaches.

6       Catalog Service for the Web

6.1           Implemented Solution (HubCat) for Dynamic Registration and Discovery of Things

6.1.1      Compusult Implementation

The Compusult Catalog Service for the Web (CSW) is an implementation of the HTTP binding defined in OGC’s OpenGIS Catalog Services 2.0.2 specification (OGC 07-006r1). As its data store, it uses the OASIS ebXML Registry Information Model (ebRIM 3.0).

As a service-oriented registry, it carefully catalogs each supported OGC service (i.e., WMS, WFS, SOS, WMTS, etc.) using the suggested guidelines set forth in both CSW-ebRIM Registry Service - Part 1: ebRIM profile of CSW (OGC 07-110r4) and CSW-ebRIM Registry Service - Part 2: Basic extension package (OGC 07-144r2). This not only enables the Compusult CSW to store information about the various service types in an adaptable and manageable manner, but also enables it to be interoperable with other 2.0.2 CSW clients.

As part of the publishing process, Compusult’s CSW creates an ISO 19119 or ISO 19115 document from each OGC service or document it processes and associates it with the item being published. This helps the registry to support querying records using the ISO core queryables. CSW clients can then choose to return the matching record or its associated ISO document.

Another feature of Compusult’s CSW is its ability to return various output formats. Using the outputSchema parameter, 2.0.2 CSW clients can choose between the following metadata formats:

• ebRIM (urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0);
• 2.0.2 CSW Core (http://www.opengis.net/cat/csw/2..2);
• ISO (http://www.isotc211.org/2005/gmd);
• FGDC (http://www.fgdc.gov);
• MARC21 (http://www.loc.gov/MARC21); and
• DIF (http://gcmd.gsfc.nasa.gov/Aboutus/xml/dif/).

To dynamically register a SensorThings service, Compusult used guidelines similar to those outlined in part 1 and 2 of the ebRIM basic extension package (see Section 7.0).

The sections below detail how each SensorThings service is currently represented in the Compusult CSW registry. The terms used are part of the OASIS ebXML Registry Information Model (ebRIM 3.0).

6.1.1.1     The Service Object

Each SensorThing service is represented by an ebRIM Service object. This Service object is the top level object for each registered SensorThing. It is associated with the Thing objects (see Section 6.1.1.2) that are accessible through the SensorThing service Uniform Resource Locator (URL) (i.e., http://TheSensorThingURL/Things).

Each Service object has the following attributes:

• Name = “http://TheSensorThingURL”
• Description = “OGC Sensor Things”

Its associated ebRIM Slots include:

• Slot [Name = “Service URL”, Value = “http://TheSensorThingURL”]

To support spatial searching for the service, we create a spatial slot using the maximum bounding area of all the Thing objects.

• Slot [Name = http://purl.org/dc/terms/spatial, Value = “maximum bounding area of all the Thing objects.”]

Each Service object is then classified as: urn:ogc:serviceType:SensorThing

6.1.1.2     The Thing Object

Each Thing object is represented by an ebRIM ExtrinsicObject. It is associated with the DataStream objects (see Section 6.1.1.3) that are accessible through each Thing URL (i.e., http://TheSensorThingURL/Things(11)/Datastreams).

Each Thing object has the following attributes:

• Name = value of @iot.selfLink
• Description = value of description
• Type = urn:ogc:def:ebRIM-ObjectType:OGC:Dataset

Its associated ebRIM Slots include:

• Slot [Name = “@iot.id”, Value = (value of @iot.id)]
• Slot [Name = “@iot.selfLink”, Value = (value of @iot.selfLink)]
• Slot [Name = “Locations@iot.navigationLink”, Value = (value of Locations@iot.navigationLink)]
• Slot [Name = “Datastreams@iot.navigationLink”, Value = (value of Datastreams@iot.navigationLink)]

To support spatial searching for each Thing object, we store its last location in a spatial slot:

Slot [Name = “http://purl.org/dc/terms/spatial”, Value = gml:Envelope info]

To get this information, we use the last entry in the Thing’s Locations link using the top parameter on the REST URL.

Sample URL: http://TheSensorThingURL/Things(11)/Locations?$top=1

Each Thing object is then classified as:

• urn:ogc:def:ebRIM-ObjectType:OGC:Dataset
• urn:ogc:def:ebRIM-ObjectType:OGC:Dataset:SensorThing

To associate the Thing with its parent Service object, an ebRIM Association object is used with the following attributes:

• associationType = urn:ogc:def:ebRIM-AssociationType:OGC:OperatesOn
• sourceObject = id of Service object.
• targetObject = id of Thing object.

6.1.1.3     The Datastream Object

Each Datastream object is represented by an ebRIM ExtrinsicObject with the following attributes:

• Name = value of unitOfMeasurement -> name
• Description = value of description
• Type = urn:ogc:def:ebRIM-ObjectType:OGC:Dataset:OGC-OM:2_0:OM_Measurement

Its associated ebRIM Slots include:

• Slot [Name = “@iot.id”, Value = (value of @iot.id)]
• Slot [Name = “@iot.selfLink”, Value = (value of @iot.selfLink)]
• Slot [Name = “Thing@iot.navigationLink”, Value = (value of Thing@iot.navigationLink]
• Slot [Name = “Sensor@iot.navigationLink”, Value = (value of Sensor@iot.navigationLink]
• Slot [Name = “Observations@iot.navigationLink”, Value = (value of Observations@iot.navigationLink]
• Slot [Name = “ObservedProperty@iot.navigationLink”, Value = (value of ObservedProperty@iot.navigationLink]

To support the ability to search by date and time, we use the Datastream’s Observations link to get the last phenomenonTime entry to create the phenomenonTime slot:

• Slot [Name = “phenomenonDate”, Value = $phenomenonTime]

This is accomplished using the orderby and top attributes on the REST URL.

Sample URL: http://TheServiceThingURL/Things(11)/Datastreams(12)/Observations?$orderby=phenomenonTime desc&$top=1

Each Datastream object is then classified as:

• urn:ogc:def:ebRIM-ObjectType:OGC:Dataset
• urn:ogc:def:ebRIM-ObjectType:OGC:Dataset:OGC-OM:2_0:OM_Measurement

To associate each Datastream object with its parent Thing object, an ebRIM Association object is used with the following attributes:

• associationType = “urn:ogc:def:ST-AssociationType:OGC:HasDataStream”
• sourceObject = id of Thing object.
• targetObject = id of Datastream object.

6.2           Pros/Cons

6.2.1      Compusult

6.2.1.1     Pros

• Flexibility: One of the real benefits of using Compusult’s CSW is that it is flexible enough to store just about any type of information. This feature allowed us to consume SensorThing services relatively easily.

6.2.1.2     Cons

• No Profile: The specification is flexible and therefore, it allows us to name and associate objects however we want. Without an official profile to follow, continuing with this approach would leave us unable to be semantically interoperable.
• Complicated Queries: Another downfall is that sometimes the data that need to be represented in the ebRIM information model can have a multiple layers of association. For example, the SensorThings service is associated with multiple Thing objects and each Thing object is associated with multiple Datastream objects. Unfortunately, this can sometimes lead to fairly lengthy and complicated CSW queries that are hard to implement.

6.2.2      Envitia

6.2.2.1     Comments on Using the Compusult Registry (Registry Client)

Envitia were, to the knowledge of the authors, the only client provider to directly access the HubCat. The following are comments from the perspective of a provider of CSW-ebRIM clients and servers provider as well as a developer of registry information models and extension packages.

The Compusult CSW-ebRIM implementation exhibits a high degree of compliance with the standard; this is not always true for OGC standards and therefore should be applauded. In that respect, there were no particular interoperability issues and the standard seems sufficiently tight that the Envitia client was able to interact with the Compusult HubCat with little difficulty. Interoperability issues do arise through the choice of HubCat configuration, or ebRIM Registry Extension Package (eREP), since these packages define specializations of the general record types that a generic client may not deal with efficiently.

6.3           Recommended Changes

6.3.1      CSW SensorThings API Profile

Although ebRIM Slots, Classifications and Associations were selected with names and IDs that seemed appropriate, the most important recommendation at this point would be to implement a CSW STA profile so that official guidelines can be followed to ensure proper interoperability with other 2.0.2 CSW clients.

6.3.2      Service Object Model

The current HubCaT implementation focuses to a large degree on cataloging service instances, with service being the primary record type. This is contrary to the approach used in general by the OGC in cataloguing other data. The core OGC model and the model implemented in ISO 19115/19119 as well as in ISO 19139 treat dataset and service as two separate but linked artifacts. This has been embodied in the 115 extension package for the CSW-ebRIM standard that declares datasets and then associate services with it. This would allow a client to present a user with available data and then allow them to discover relevant services that could deliver it. This latter negotiation could go on automatically in the client. With the current model, the Envitia client could list all services available but would represent STA, SOS, and WMS services visualizing an SOS or SensorThings endpoint as separate artifacts even if they serve the same data. 

A model closer to that used in I15 would be helpful in resolving this. This is represented in Figure 1 below.

6.3.3      Catalog WMS Service

Using ebRIM classification schemes to classify objects would also be helpful, but as pointed out by Compusult there is a need to standardize on the taxonomies. To some degree, the above model was played out in the Compusult CSW-WMS which implemented form of the classification scheme shown on the left, but in a somewhat limited way, for example linking all sorts of temperature together. This made it useful for discovery but less useful for visualization as it mixed concepts.

In general terms, the availability of the CSW-WMS did allow the discovery of classes of sensors in the Envitia Horizon Geo-portal and also the transition from this to accessing SOS services, which could be accomplished through GetCapabilities requests to the CSW-WMS. But the recommendation is still that a more formal route within the registry would be valuable.

6.3.3.1     Sensor Harvesting WPS

The authors see real value in the Sensor Registration Processing Service (WRPS) provided by Compusult. Evitia provides a very similar interface in practice, although it relies on a separate REST invocation rather than the WPS interface. There is also value in formalizing the rules for mapping metadata from specific sources such as SOS capabilities documents into eREP elements so that the mappings can be implemented the same way in different technologies.  

6.3.3.2     OWS Context Document Alignment

The model described here not only maps to CSW-ISO and the CSW-ebRIM I15 profile, but also to OWS Context document which allows for a given (‘Layer’ or ‘Resource’ as it is called) to be offered in various forms. Therefore, an OWS Document could define a ‘Layer’ of ‘Body Temperature’ and offer an SOS and a WMS endpoint to clients so they can access the most appropriate form of this content.

6.3.3.3     Overall Recommendation with Regards to Data Modelling

Overall, the recommendation is that significantly more work is needed to formalize both the SWE-IoT eREP’s and the mapping rules from S-Hub service metadata into the HubCat in order to ensure consistent sensor discovery and exploitation. Envitia consider it to be worth developing a standard profile specification for this. It would have been impossible to effectively perform such work in the first IMIS IoT Pilot, but it would be valuable to carry out in the near future.  

6.3.3.4     Stored Queries in CSW-ebXML

If such a standard profile is developed, there may be real value in developing CSW-ebRIM stored queries. These would allow specific questions (such as find human-deployed temperature sensors) that might require fairly complex queries to be executed by relatively simple clients. The value of this feature of CSW-ebRIM in making clients easier to implement is underestimated by many. Envitia has used it extensively in the past and suggest it would fit here well too. 

6.3.3.5     Catalog/Registry for Sensor Parameter Classification

An issue in using the various sensors was the lack of metadata to allow them to be discovered without a-priori knowledge. Sensors were in many cases characterized by ‘Sensor_1’ and ‘Parameter_1’ rather than anything identifiable. If there was a sensor issue in providing this, the Catalog would provide a route for administrators to register dictionaries to translate ‘Parameter_1’ to ‘Temperature’ and also add critical metadata such as ‘Deg F or Deg C’ as this is obviously critical.

6.3.3.6     Catalog Federation

Consideration should be given to demonstrating a HubCat federation. Envitia’s client itself actually made use of two HubCat’s for the Pilot demonstration. It accessed the Compusult HubCaT as well as Envitia’s cloud-deployed HubCat2 which had maps and implemented an extension package to store OWS Context documents against communities of interest.

The authors would have preferred to access a single federated registry which issued queries to the HubCat and to the authoritative data. Envitia’s CSW-ebRIM service is capable of supporting this (and most likely that of Compusult, too), and in most urban incident situations there will be more than one HubCat. Envitia’s view is that it might be best to deploy a separate federating catalog service that would not have its own holdings, but simply federate out queries to the HubCat’s serving a particular incident and aggregate the results for the client. Such models are common and efficient if a high degree of interoperability between HubCat’s can be maintained.  

6.3.3.7     Dynamic Registration of Sensors

The practice adopted for the IMIS IoT Pilot was to register sensors when they came online and drop them out when they went offline. This caused problems in client implementation; it was hard to obtain a view of the potentially versus actually available sensors. In some cases, sensor placements were ad hoc but in others the sensors were predictably positioned, for example on fire trucks. Two approaches may address this. The first is to catalog every potential sensor, but provide an ‘online/offline’ flag. The other is to model ‘Sensor Class’ so that a sensor’s interface is clear when it comes online (i.e., Is it going to be sensor things or SOS? If it is SOS what profile will it support?).

7       Web Feature Service (WFS)

A WFS was deployed for the Pilot that provided access to the features of interest (FoI’s) of observations that had been published through SOS.

7.1           Implemented Solution

7.1.1      52°North

An overview on the components of the implemented solution for WFS is given in Figure 2. 52°North has implemented a WFS based on its Web Service framework Iceland[4] that acts as a proxy to a SOS. The component offers the mandatory operations of a WFS, i.e., the GetCapabilities operation, the DescribeFeatureType and the GetFeature operation. Besides general operations metadata, the Capabilities document lists the FeatureTypes that are served by the WFS (the document is listed in Annex A.2). As the WFS is serving both the observations as well as the sampling features, the types OM_Observation and SF_SamplingFeature are listed in the Capabilities and the corresponding XML schemas can be retrieved using the DescribeFeatureType operation.

A sequence diagram of interactions between WFS and SOS is given in Figure 3. First, a client can query the Capabilities and available feature types from the WFS using the GetCapabilities and DescribeFeatureType operations. As core functionality, the client can retrieve the observations and features of interest from the WFS using the GetFeature operation. As the WFS implementation acts as a proxy for SOS servers, it needs to map the GetFeature requests to GetObservation and/or GetFeatureOfInterest requests and can then forward these requests to the SOS. Once the WFS has received the features, it can then forward them to the client. In case of observations that are requested, the observation features need to be extracted from the GetObservationResponse and put into a FeatureCollection.

7.2           Pros/Cons

7.2.1      52°North

Serving observations and features of interest through a WFS server allows WFS clients to retrieve this information without having to support SOS servers. The WFS lacks metadata about the observations and sensors available in the Capabilities document, however. For example, it is not possible to obtain information for which time period, observed properties and from which sensor observations are available. Furthermore, the WFS also lacks pre-defined filters for temporal attributes as well as other observation properties, e.g., for the observed property that points to a description of the observed phenomenon or for the procedure that points to a description of how the result of an observation has been taken (usually a sensor description).

Due to these gaps, the SOS may be seen as a specialization of WFS. The SOS supports one basic feature schema for observations (the O&M model) and provides dedicated operations for retrieving sensor metadata (DescribeSensor), features of interest (GetFeatureOfInterest), observations (GetObservation). For each operation, pre-defined filters are available. For example, the Request schema for GetObservation defines filters for procedures, observed properties, samplingTime and resultTime.

7.3           Recommended Changes

No specific changes to the specification are recommended. The Pilot implementation experience suggests, however, that there is some value in devoting SOS to providing sensor metadata and observations, and otherwise using WFS to provide information about spatial features such as the features of interest linked to the SOS observations. This practice is illustrated in Figure 4. The SOS provides, in essence, dynamic property values for the features served by the WFS.

8       Web Maps Service (WMS)

WMS have been developed to provide applicable basemap data for the incident response area along with IoT features as a layer. The WMS functions both as an integral map server and as a Feature Portrayal Server (FPS) to render map images from remote WFS feature collections and SOS observations.

8.1           Implemented Solution

8.1.1      52°North

52°North has implemented a WMS that can harvest features of interest from SOS servers and visualize information about the features and related observations in map layers. Figure 5 provides an overview of the components.

The GeoServer WMS is used to provide the basic WMS operations GetCapabilities, GetMap and GetFeatureInfo. The GeoServer software can be configured to serve feature layers from a WFS server as map layers in a WMS. Hence, the 52°North WFS described in Section 7.1 is utilized to provide the base data used for rendering the map layer displaying the features of interest. The GeoServer WMS then renders a map layer for these features of interest using pre-defined symbols. Without supporting information about the sensors that are observing the features and observations about the features, however, the WMS layer is of limited use.

52°North thus implemented the FeatureInfo extension. GeoServer utilizes Apache FreeMarker[5], a Java-based template engine, to generate HyperText Markup Language (HTML) templates. 52°North’s FeatureInfo extension configures these templates by injecting into them URLs that link to the 52°North’s Sensor Web REST API. The API encapsulates the business logic for accessing SOS servers as a client, provides RESTful access to observations and sensor descriptions, and returns those observations encoded in JSON that can easily be integrated into Web sites. Figure 6 shows a sequence diagram of typical interactions between clients, the WMS implementation and the components utilized for the implementation. Once a GetFeatureInfo request is sent to the GeoServer WMS, the WMS searches for a FeatureInfo template using the ID of the feature for which information has been requested. The FeatureInfo extension generates the HTML template by injecting relevant URLs to resources such as observations, sensor description, etc., served by the Sensor Web REST API. The prepared HTML template is then used by the GeoServer WMS and returned to the client. Once the HTML template is loaded on the client side, the URLs are resolved and the information is displayed in the FeatureInfo HTML representation.

8.1.2      Compusult

The Compusult WMS was implemented to provide visualization of all the sensor data available in the Compusult HubCat. Sensor data is currently available from both SOS and STA services, however the WMS consolidates the data such that a user does not need to know what type of service the data came through, only the type of the sensor the data comes from. The data are then grouped by type into separate map layers. If more than one layer is active and a device or Thing has sensors in multiple layers, the symbol is changed to represent a device instead of a sensor type. The user can hover over a sensor symbol to see the current values. This is visualized in Figure 7.

The layers in the GetCapabilities request are organized by sensor data types, allowing a user to see all data of the same type within a single layer. A configurable mapping of data types was used to perform semantic mediation on the data because, typically, services use different names for the same data. A user can simply add layers for the data he or she is interested in, as illustrated in Figure 8 below.

Data is retrieved and cached from external services using a system of multiple threads to ensure that slow or problematic services do not slow down the WMS. The WMS stores a configurable amount of historic data for each service as well. Historic locations for a device are displayed as dots with a path connecting them to the current reading. The GetFeatureInfo operation is also available from the Compusult WMS. The feature information page shown in Figure 9 visualizes the recent observations with the associated locations and timestamps. It also shows the data type of the observations and the service the observations were retrieved from.