Publication Date: 2017-06-29
Approval Date: 2017-06-29
Posted Date: 2017-01-23
Reference number of this document: OGC 16-080
Reference URL for this document: http://www.opengis.net/doc/PER/t12-A063
Category: User Guide
Editor: Roger Brackin
Title: Testbed-12 OWS Context User Guide
Copyright © 2017 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium 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.
This document is a user guide created as a deliverable in the OGC Innovation Program (formerly OGC Interoperability Program) as a user guide to the work of that initiative and is not an official position of the OGC membership. There may be additional valid approaches beyond what is described in this user guide.
POINTS OF CONTACT
While over the last 10 years use of open standards compliant geospatial web services such as WMS, WMTS, WFS, WCS and CSW has grown massively, there has not been an effective open standards mechanism to assemble a collection of information such that it can be exchanged easily among a community. While some GIS vendors support such a capability the solution is typically not portable between vendors. The OGC did develop the Web Map Context standard (05-005) but this only supported WMS and so was relatively limited. The OWS Context Standard (OWC) was developed to allow advanced sharing of geospatial ‘Context’ or 'view' between users across a wide range of application types (browser, desktop applications, apps) and technologies (desktop, mobile, embedded etc). The standard is modular and easily implemented, and supports a wide range of OGC service standards as well as in-line or local content.
OWS Context offers a solution to a wide range of sharing requirements. Chapter 1 describes a list of use case examples. Chapter 2 will provide a detailed description of each of these examples.
1.1. Usage Example - Shared Situational Awareness
Users in a range of environments have access to the central services, but typically wish to collaborate using a range of information. In a collaboration built on for example an emergency response there is typically a wide range of stakeholders and a need to provide them with relevant common information.
1.2. Usage Example - Sharing Catalogue Searches
A users wishes to save or exchange the query and results from various catalogue searches to avoid duplication of effort. In this case a user would execute one or more searches and retain each search request and possibly results set and be able to exchange the search and results set with others so that they could review the results or modify and re-execute the search.
1.3. Usage Example - Processing Services Management
A user wishes to save and/or exchange the configuration and/or results of an analysis or processing activity. The process to be executed will be stored in the context document as well as inline or referenced results.
1.4. Usage Example - Index or Catalogue of Data Collections
A user wishes to create a collection of datasets, for example OGC GeoPackages which are split geospatially (tiled) and/or based on themes. The OWS Context document can provide a catalogue or inventory of these.
1.5. Benefits of OWS Context Documents
Some of the key benefits of OWS Context are:
OWC is open standards compliant allowing sharing between different system technologies.
OWC documents are easily created, exchanged, catalogued and read.
OWC documents can be encoded in XML/ATOM or GeoJSON. The two formats are interchangable.
OWC supports not only WMS but a wide range of other OGC Services (CSW, WFS, WCS, WPS, WMTS etc)
OWC Supports inline content in well known encodings such as GML and KML.
OWS Context Documents can reference local files in for example GeoTIFF.
OWC is easily extensible to include new service types, inline content and file = formats (OGC and non-OGC) without the need for a change in the standard.
An OWS Context Document primarily contains references to information and so is itself relatively small in size. It therefore is easy to exchange and access.
1.6. Normative References
The following normative references are used in this document.
OGC 12-080r2, OGC OWS Context Conceptual Model, 2013-09-01, https://portal.opengeospatial.org/files/?artifact_id=55182
OGC 12-084r2, OGC OWS Context Atom Encoding Standard, 2014-01-14, https://portal.opengeospatial.org/files/?artifact_id=55183 or online at http://docs.opengeospatial.org/is/12-084r2/12-084r2.html
OGC 14-055r2, OGC OWS Context GeoJSON Encoding Standard 2016-10-08. This document has now been approved as an OGC Standard but has yet to be published to the OGC Standards registry.
OGC 15-113r2, OGC CDB Core Standard. This document has now been approved as an OGC Standard but has yet to be published to the OGC Standards registry.
GeoRSS Geographically Encoded Objects for RSS Feeds. (http://www.georss.org/)
2. Common Use Cases
The Context Document goal is to support the exchange of a set of information elements between human users or application programs for a range of purposes such that the Area of Interest, time range, resources and their configuration is unambiguously exchanged between applications.
2.1. Use Cases
The OWS Context document is aimed at meeting a range of user context exchange requirements around sharing information. This section provides more detail on the primary use cases described in section 1 including a definition ofcommon sub use-cases.
2.1.1. Shared Situational Awareness/COP Exchange
Users in a range of environments have access to the central services, but typically wish to collaborate using a shared set of information of information. In a collaboration built on for example an emergency response there is typically a wide range of stakeholders and a need to provide them with relevant common information. Often one person or group (typically geo-support) has the responsibility to provide a set of information to other users (in this case commanders and on-scene responders) in time sensitive situations to allow them to deal with the evolving situation; given that they do not have time to assemble information themselves. The OWS Context Document standard allows the geo-support personnel to assemble a set of relevant information, accessible via web services, and pass it to other users (by email message, file transfer or by storing it within an OGC catalogue).
On-Line COP Use Case
The exchange of a common operating picture or view of information is recognized as one of the most important uses of the OWS Context Document. Often a COP defines a geographic Area of Interest and a set of information layers and queries to specific points of interest. The content of a COP may be made up of both web services and local content, and the OWS Context document allows this to be supported. It also allows the inclusion of alternatives for a given layers.
A critical element of a shared situational awareness environment, whether used in a military, civil incident management or any other situational awareness context is the ability to exchange COPs between systems based on different technology. There are many equivilent approaches to OWS Context, but none which offer a vendor agnostic approach. This hetrogeneous model means COPs can be shared in a number of environments, for example between command centers and deployed users in vehicles or on foot, and using everything from laptops in mobile vehicles through to tablets, mobile devices or wearable technology (see figure 2.1).
Figure 2.1 - OWS Context SSA Use Case
A COP may take many forms and have many uses, it may represent a 2D map display, a 3D map display, an augmented reality view, or a textual representation of geospatial information.
The COP exchanged is not simply a graphic but a 'live' view. When loaded it should show the latest state of the information referenced. This is a capability of OWS Context.
In this basic COP use case, OWS Contexts are simply exchanged between systems using a file system or via a messaging system such as email. More advanced exchanges are possible via a catalogue where users can identify groups of context documents relevant to them directly or incidentially. In addition it is possible that users could be notified on new contexts using a subscription scheme (potentially based on the OGC PubSub Standard).
Figure 2.2 - OWS Context SSA Use Case
On-Line COP Exchange Via Catalogue
OGC Compliant catalogue services provide a useful way to manage OWS Context Documents.
Figure 2.2 - OWS Context Catalogue Storage Use Case
Off-Line COP Exchange
As part of this there is the recognition that in some cases the services referenced may not be available, and therefore some information (for example overlays or thumbnails) may need to be carried in the context document itself or alongside it. The context document layers may need to support both an on-line and an off-line alternative. One delivery model for a range of geospatial information is the GeoPackage standard. One specific model is to use the OWS Context document to provide a defintion of the services to be harvested into a GeoPackage so that the content can then be used off-line. Either a WPS service (GeoPackager) or the client itself can use the context document to load the GeoPackage with data and potentially update a GeoPackage which was already created. The context document allows the layers (WMS or WMTS) and feature types (WFS) required to be defined but also the geo-extent of data to be harvested.
Of course GeoPackage is not the only carrier encoding that could be used in this way, and evolving standards such as CDB [Ref 4] could potentially be created from an OWS Context defintion. Alternatively completely proprietary caches could be created on a client, once again using OWS Context to define the content of a cache. The attractive element of this overall workflow is that a client can see what will be cached using the normal on-line access, before executing the process to cache the data.
Figure 2.4 - OWS Context Off-line Use Case
2.1.2. Exchange of a Catalogue Query and Results
This use case relates to the exchange of discovery results from various catalogue searches, to avoid duplication of effort. In this case a user would execute one or more searches and retain each search request and possibly results set and be able to exchange the search and results set with others so that they could review the results or modify and re-execute the search. To do this primarily CSW requests and optionally results will be stored in the context document. This allows the retrieved results to be reviewed but also allows the query used to obtain the results to be re-run or modified and rerun.
2.1.3. Exchange of the Configuration and Results of a Process
A user wishes to save and/or exchange the configuration and/or results of an analysis or processing activity. The process to be executed will be stored in the context document as well as inline or referenced results. This type of context document might use WPS to define the processing, with results returned by the WPS, inline in the Context document in GML, in a referenced image, or available via another OGC service (WMS, WMTS etc).
The above use cases lead to the following general requirements for an OWS Context document.
The Context Document shall provide the capability to identify the temporal extent of the COP (one or more time envelopes). (See Chapter 5 - Time Interval of Interest Metadata)
The Context Document shall provide the capability to define a series of configured resources together which provide relevant information to the COP User. (See Chapter 5 - Resources)
The Context Document shall define the order of precedence of the resources included (this could be interpreted as, for example, the order of display by visualization clients) (See Chapter 5 - Ordering of Resources)
The Context Document shall allow any service type to be specified and any rules to be specified. (See Chapter 5 - Offering)
The Context Document shall provide information to allow clients to test if a service matches a supported profile in order to understand if they can interpret it. (See Chapter 5 - Telling if an XML/GeoJSON Document is a Context Document)
The Context Document shall allow information targeted at different representations to be included (i.e. not just targeted at geographic visualization or just visualization). (See Chapter 6 - Terradue - Using OWS Context to store Searches)
The Context Document shall allow information to be marked as enabled or disabled, i.e. it is to be presented to the user when the context is opened or isn’t. Source: WMC Specification: which has and on/off option (layer not displayed or not when loaded). (See Chapter 5 - Visibility Attribute)
It shall be possible to associate information with embedded graphics information. (See Chapter 5 - Content Offerings)
The Context Document should allow the in-line inclusion of a resource (literal value of a resource) in the context document. (See Chapter 5 - Content Offerings)
The Context Document should allow the parameters which define the resource or processing service steps to be captured. (See Chapter 5 - Envitia_TB12_OWC.xml and Envitia_TB12_OWC.json)
3. The OWS Context Document Structure
An OWS Context (OWC) document consists of a number of key elements. These are shown in figure 3.1.
Figure 3.1 - Structure of OWS Context Document
The overall information includes a name, abstract and creation date as well as a range of high level metadata. It also includes an Area of Interest and a time range of interest (all optional). When using OWC for visualization the Area of Interest is typically the area displayed on screen when the context document is loaded. Similarly the time-range of interest is the time range that any time slider in the application will be set to. The core of the OWC document is an ordered list of resources. Again for visualization purposes the application should load the resources in the list such that the first resource is at the top (i.e. reverse draw order).
Each layer in a context document is known as a ‘Resource’ which in the Atom encoding is mapped to a ‘Entry’ XML element. In reality a resource can be realised in a number of different ways, and so an OWC document allows various options to be specified. These are known as offerings. The intention is that these are, as far as is possible by the format used, equivalent and no priority is assigned to their order in the standard. They are intended to be alternatives that the client can use to allow it to visualise or use the resource. This structure is shown in Figure 3.2.
Figure 3.2 - OWS Context Document Offering
An example of two equivalent offerings is a WMS for a resource and then a WMTS request retrieving equivalent data. The client can read either and be reasonably certain that the result presented to the user is the same. Another example is a resource which might offer a WFS and also in-line GML which is the equivalent of the request.
There are two types of offering, service offerings and data offerings. A service offering has a service request (in the form of a capabilities request and a data request) and optional content and styling elements. A data offering has a content element and optional styling elements.
4. OWS Context for Users
The goal of this section is to give end users of OWS Context documents and idea or how they can be used. To do this a two existing applications are exploited to show the typical workflow. As can be seen in section 6 (Applications and Tools) there are a number of other applications which support OWS context with a range of use cases, so the following example is purely one method of exploiting it.
The example in this section use the Envitia Horizon Web Client which was used during testbed 12. The functionality described is for guidance only. OWS Context does not mandate client behavior, and other implentors may design the functionality in a different way.
4.1. Building the View to be Shared
Firstly the user uses a browser based client to create an OWS Context Document. This process follows a fairly normal GIS Workflow.
4.1.1. Catalogue Search
The creation of most geospatial views begins with a discovery process. Typically geospatial information users define an area of interest, and categories of information they are interested and perform some form of search. The figure below shows an example of just such a search. In this case the user was looking for data in the area of ??? and after executing the search can see a range of data sources.