OGC Testbed 12

For more information please contact innovation@ogc.org

The full set of Testbed 12 videos can be found on the OGC Testbed 12 YouTube page.

Published ERs can be found on the Testbed 12 Public Engineering Report Repository, and published User Guides can be found on the Testbed 12 Public User Guide Repository.

OGC Testbed-12 Results Engineering Report

Table of Contents

• 1. Introduction
• 2. Testbed-12
• 2.1. Clients
• 2.2. Improvements to Existing OGC Specifications
• 2.3. Architecture
• 2.4. Arctic Spatial Data Infrastructure
• 2.5. Aviation
• 2.6. Data Handling and Models
• 2.7. Big Data
• 2.8. Semantics
• 3. Testbed-13

Abstract

This report documents the results of OGC Testbed-12. The report has been compiled on the basis of all Testbed-12 Engineering Reports, direct conversations with participants and sponsors. Please provide any comments to isimonis (@) opengeospatial.org.

Please note that all references to Engineering Reports in this document point to Testbed-12 ER Overview page rather than directly to the Engineering Report (ER). The reason is that not all ERs have concluded the presentation, review, and voting procedure required to become a publicly available report. The Testbed-12 ER Overview page will be updated continuously to provide references to the reports as they are published. As long as the Engineering Reports are not publicly available, OGC members can access the latest version using the OGC portal.

1. Introduction

OGC Testbed-12 was the biggest OGC testbed ever in terms of funding and deliverables. Sponsorship funding in Testbed-12 totaled $3.6 million U.S. Dollars and attracted in-kind Participant contributions of $2.9 million, for a total testbed scale of $6.5 million. Seven sponsors from around the globe shared costs and contributed requirements across a range of subject areas. The deliverables to meet these requirements were broken into seven threads in which the technical work was carried out. This work was guided by thread architects, whose close cooperation ensured efficient and consistent testbed delivery, ultimately leading to a final, joint Demonstration.

Altogether 30 Participant organizations conducted technology integration experiments on 82 interoperable, running component implementations. Participants also delivered 51 documents, including engineering reports, user guides and summary-level artifacts, and 40 Change Requests, for a grand total of 173 technical deliverables. Over a hundred management deliverables (status reports, meeting minutes, etc.) were also made. Across all testbed roles, including Sponsors, Participants, IP staff, and observers, over 210 individuals were involved with Testbed-12, which started in January 2016 and finished with the final Demonstration event in November 2016.

An overview of further Testbed-12 statistics (number of participants, work items, sponsors etc.) and documentation on processes and stakeholders can be found online, OGC17-006, whereas this report concentrates on the technical achievements of Testbed-12.

Testbeds are fast-paced, multi-stakeholder collaborative efforts to define, design, develop, and test candidate interface and encoding specifications; to experiment with new architectural approaches and patterns; to develop guides on spatio-temporal information technologies; and to serve as rapid prototyping environments for general geospatial IT challenges.

Testbeds are executed as part of the OGC Innovation Program (IP), but receive requirements and definition of work items from all OGC programs, as illustrated in Overview of OGC programs (blue) and supported communities (green). Being integrated into the OGC organizational structure, testbeds serve the:

• Standards Program by developing draft specifications that are then reviewed, revised, and potentially approved in the OGC Standardization Program;

• Compliance Program by testing, developing, and improving compliance and interoperability tests for services and encodings;

• Communications & Outreach Program by bringing a huge number of organizations, both form the provider and consumer side, together to discuss technological challenges and strategic decisions;

Figure 1. Overview of OGC programs (blue) and supported communities (green)

By developing publicly available Engineering Reports, testbeds serve even the broader geospatial IT community. Testbeds produce user guides that help the engineering community to build optimized products, provide overview reports on new technologies and architectural approaches that help decision makers, and capture implementation experiences that are of great help to the developer community. More on information on the Innovation Program (formally known as Interoperability Program) are provided in this conference paper.

2. Testbed-12

Testbed-12 was executed in the time period April to November 2016 and produced outstanding results. The primary goal of Testbed-12 was two-fold: First, to experiment with and to develop new technologies to solve geospatial challenges; and second to develop user guides that help understanding and executing OGC key technologies in an efficient way. These two goals have been complemented by CITE improvements.

The goal of this document is to serve as a roadmap to find your way through all the Testbed-12 results, which are captured in Engineering Reports and have been demonstrated with prototype implementations. An overview of all the latter is given in OGC 16-027: Testbed-12 Web Service Implementation Engineering Report (OGC 16-027). This summary report provides OGC document identifiers, e.g. OGC 16-027. It is emphasized that this report provides the base numbers only, that is without any revision number. The published document may be indicated by a subsequent/higher revision number, which is added as “r”.

All Engineering Reports are publicly available (or will be made available once the voting procedures have been completed positively). Reading them all would mean you need to go through roughly 3300 pages in total, so this document helps finding what you are most interested in. The document is organized around the high level architecture as illustrated in Figure 1, which already includes a good portion of the geospatial IT domain.

Figure 2. High level architecture of Testbed-12

The high level architecture illustrated in Figure 1 builds around seven building blocks:

1. Clients include applications build on desktops or mobile devices as well as aspects related to intermitted connectivity, such as compression, generalization, or offline data packages;

2. OGC Web Service Interfaces represent the traditional OGC Web service specifications, which are continuously improved and extended;

3. Architecture as the integration block of all other blocks. It includes architectural patterns such as REST, SOAP, APIs and Web services, addresses integration and communication challenges such as quality of service, discovery of data, assets, collections, or missions, security, messaging or brokering.

4. Aviation & Arctic

   1. Arctic Spatial Data Infrastructure as a spatially defined domain with the goal to improve application profiles and service types to gain holistic insights into the Arctic.

   2. Aviation as a thematically defined domain with the goal to develop new approaches to optimize data discovery, exchange, and analytics in the aviation domain.

5. Dynamic Sources & Communities includes all data providers, specific formats, capturing and storing challenges, metadata, data encoding and serialization options, and data containers;

6. Big Data includes challenges and opportunities caused by volume, variety, velocity or veracity of data;

7. Semantics address the increasingly important semantic interoperability challenges;

The overarching architecture mainly serves as a mean to find your way through the geospatial IT world that has been addressed in Testbed-12. All work items have been assigned to one of these blocks. Testbed-13, the upcoming testbed that is already work in progress, adds a sevenths block to that list, clouds.

2.1. Clients

As part of the Clients block, Testbed-12 focused on:

• EXI Compression

• Generalization

2.1.1. EXI Compression

The Efficient XML Interchange (EXI) format is a way for one system to send to another system a highly compressed sequence of parse events. The recipient can build data structures directly from the parse events without having to reconstitute a textual representation (such as a JSON file, an XML file, JavaScript, HTML and so forth). Testbed-12 analyzed compression ratios using EXI for GML feature data provided at a WFS instance. EXI uses a grammar-driven approach designed to achieve efficient encodings using an encoding algorithm and a small set of datatype representations. EXI encodes XML data either in a schema-less or schema-informed mode. The latter allows to take information from the underlying XML Schema into account at encoding time to potentially improve compactness and performance. It turned out that Testbed-12 confirmed results produced in Testbed-8, where EXI was evaluated in the context of aviation data compression. In contrast to a number of published studies, Testbed-8: OWS-8 AIXM Compression Performance Benchmarking ER, OGC 11-097 and Testbed-12 have shown that the availability of a schema is not necessarily improving performance, and EXI does not provide much advantage over gzip. In some circumstances, EXI was performing even worse. Other results included issues with incorrectly decoded numbers, issues with Java/Javascript communication, and issues with the WFS specification being not clear about compression. All results and comparison with external studies is available in the OGC 16-055: Compression Techniques Engineering Report. Implementation details including DGIWG profile support for WFS are documented in OGC 16-021: Low Bandwidth and Generalization Engineering Report.

2.1.2. Generalization

In addition to compression, Testbed-12 tested Generalization approaches to reduce the amount of data being transported between communication partners. These approaches build on the assumption that features can be reduced in their level of detail without sacrificing essential detail. OGC 16-021: Low Bandwidth and Generalization Engineering Report discusses various approaches to generalize geometric point, line, and polygon properties and defines generalization process implementation profiles for WPS. In this context, the GeneProcessOnto ontology has been recommended to support automated generalization tasks. Temporal generalization has not been addressed.

2.2. Improvements to Existing OGC Specifications

Testbed-12 experimented with a set of existing specifications. Some of these specifications are released as standards, other, less mature specifications exist as Discussion Papers or have been discussed in other Engineering Reports. The list of Testbed-12 work items includes:

• WCS EO Profile

• Enhanced WMS & WMTS

• Web Integration Service

• Web Object Service

2.2.1. WCS EO Profile

The WCS Profile Update Engineering Report (OGC 16-033) captures the Testbed-12 work on WCS profiles, in particular the WCS Earth Observation Application Profile (OGC 10-140r2) to support multi-dimensional subsetting of 3+1D space and time datasets. The new version of the EO Profile therefore drops the constraint to be valid for 2D coverages only. Instead, it now explicitly allows coverages with more dimensions as long as they have a geographic footprint on Earth. Further on, the new version 1.1 of the EO Profile introduces extensions to the DescribeCoverage and DescribeEOCoverageSet operations to query the complete metadata and grid information for all related coverages more efficiently, and introduces a new operation GetEOCoverageSet to retrieve entire or subsetted coverages in their native or any other supported format with limited processing like subsetting or scaling applied. To request advanced processing, the established GetCoverage operation will be used.

Testbed-12 further analyzed the Data Access Protocol: DAP Version 4.0 (DAP4) as a valid WCS response format, performed a comparison of WCS and OPeNDAP, experimented with WCPS to test DAP4 server processing, and evaluated WCS and the WCS EO Profile from the client perspective in order to make the server-side more client friendly.

2.2.2. Enhanced WMS & WMTS

The WMS/WMTS Enhanced Engineering Report (OGC 16-042) describes requirements, challenges, and solutions to improve multidimensional Earth Observation (EO) discovery, data access, and visualization through WMS, WMTS, and corresponding extensions.

In the context of WMS, the Engineering Report provides solutions to better support NetCDF-CF data visualization and exploration, which is done by enhancing the GetMap operation to enrich map rendering options, and by improved Capabilities for long layer lists.

In the context of WMTS, enhancements have been developed to reduce semantic ambiguities when querying time-varying layers (i.e. layers with data that varies over time). This has been achieved by means of an enhanced time-query semantic and encoding model. Extensions to the Capabilities model now allow for more efficient data exploration even for long list of layers, and improvements to the WMTS client-server communication now reduce empty tile requests. These improvements are based on three operations to support efficient inspection of all layers and the discovery of relationships among multidimensional layers. The operation include DescribeDomain for compact domain inspection, GetHistogram for domain distribution inspection, and GetFeature for detailed value inspection.

2.2.3. Web Integration Service

For many years OGC has been developing a suite of standards defining web services interfaces and encodings for geospatial processing. The suite includes a Web Map Service (WMS), a Web Map Tiling Service (WMTS), a Web Feature Service (WFS), a Web Coverage Service (WCS), a Web Catalogue Service (CSW), the Sensor Web (SWE) suite of services, etc. These service interfaces and their implementations have, more or less, been developed independently of one another resulting in isolation and poor integration between them. For example, consider a map generated by a WMS. A client or user cannot easily determine which source data was used to create the map and how to download that source data though an OGC data service such as WFS or WCS. Furthermore when one considers the Publish-Find-Bind paradigm, OGC can only partially support the full potential of this paradigm. This is because OGC structured catalogues can only register services in isolation of other related services and cannot automatically determine the relationships among services and the resources they offer. In order to achieve better integration between OGC web services and enhance the publish-find-bind paradigm, the Web Integration Service Engineering Report (OGC 16-043) defines and discusses three key elements: First, defining a new service, called the Web Integration Service (WIS), which allows for the discovery and access to integrated sets of OGC web services deployed at an endpoint. Second, specifying a means of discovering and describing associations between web resources (both OGC and non-OGC); and third, defining extensions to the OGC catalogue to allow the service to harvest and make discoverable a rich set of linked OGC and non-OGC resources.

The Web Integration Service (WIS) is an aggregation service whose only purpose is to provide a list of references to a suite of other, perhaps related OGC services available at an endpoint.

A new operation, named GetAssociations, is defined as an extension such that existing OGC services (WMS, WFS, WCS, etc.) may implement this operation in order to support rich auto-discovery. This operation enables OGC Eeb services to externalize their internal association knowledge about their content and relationships to other OGC and external resources. For example, a WMS would know if the source data for a layer it offers is a Shapefile, or a WFS feature type, or another WMS layer (i.e. cascading), or if a WMTS layer exists that renders the same information more efficiently. This “internal knowledge” can now be externalized via the GetAssociations operation.

Currently, OGC Catalogues Service instances can harvest the capabilities document of an OGC web service, register that service, register the existence of the individual offerings that the service offers and also register the association between the service and the content it offers. Thus, the entire harvesting process is focused on a single OGC web service and consequently offers a limited scope of discovery. In order to support rich discovery, a catalogue needs to be able to automatically register services found at an endpoint as well as register all known associations among those services, their offerings and other OGC and non-OGC resources. This involves harvesting a service’s capabilities document to determine what content the service offers but it also involves further interrogating the service to determine of what (if any) other associations it is aware. Populated with this enhanced knowledge a client may now use a catalogue to, for example, find the description of feature data and then be able to find the WFS that offer that data, a WMS that renders those features into a map, a WMTS that has a tiled representation of that data, etc. In order to support this kind of rich discovery, a new CSW-ebRIM package is specified that defines ebRIM object types, associations, classifications and stored queries that support the description of integrated OGC web service and their artifacts within the catalogue.

2.2.4. Web Object Service

The semantic research performed in the context of the General Feature Model led to the definition of a new logic service type, the Web Object Service, which has been implemented as a profile of a WFS 2.5 and a ebRIM CSW.

2.3. Architecture

The Architecture work packages of Testbed-12 are categorized in four classes:

• User Guides: A set of guides written for users, decision makers, and developers who want to get guidance on the topics REST, SOAP, GeoJSON, OWS Context, TEAM Engine, and CITE.

• Model Conversion, Capabilities, and Conflation: Geospatial data and service modeling topics including automated UML-to-RDF model conversion and schema profiling, OWS Context and Capabilities improvements, data conflation, and TopoJSON.

• Communication between SDI Components: Topics that address communication aspects between infrastructure components such as asynchronous communication patterns and principles, synchronization, security, catalog integration, and REST.

• Compliance Program: Work items specific to the OGC Compliance Program.

2.3.1. User Guides

Testbed-12 responded to the demand for more practical introduction material into a number of OGC technologies and standards by developing a series of user guides. These guides help decision makers, developers, and the general audience to get a quick start into the various topic. The REST User Guide (OGC 16-057) provides user guidance on REST and Open Geospatial resources, principles and advantages of using REST over POX, and explains the key terms of REST. It further provides guidance to the implementer on how to use nouns and not verbs, well-known resource classes, HTTP status codes, well-known URL templates and access paths, JSON, and API management.

The SOAP User Guide (OGC 16-138) provides guidance for using SOAP in the context of OGC Web Services. Use is exemplified on three core services, Web Map Service (WMS), Web Feature Service (WFS), and Web Coverage Service (WCS). The guide starts with a brief overview on SOAP and addresses three parts: The interface or API part, the service part, and the client part.

The (Geo)JSON User Guide (OGC 16-122) discusses JSON as an alternative data serialization and encoding format to XML. It describes JSON as a format and highlights situations where JSON offers an advantage in terms of e.g. simplicity or flexibility over XML encodings, and vice versa describes situations where XML encodings are better solutions (e.g. by providing more expressivity and robustness). The guide discusses the potential role of JSON Schema and the general issue of data format validation aspects; the value and limitations of GeoJSON, and the role of JSON-LD as a lightweight syntax to serialize Linked Data in JSON.

The OWS Context User Guide (OGC 16-080) describes the role, structure, and application of OWS Context documents as a standardized mean to assemble a collection of information such that it can be exchanged easily among a community. Starting with the history of OWS Context, which was developed to allow advanced sharing of ‘Context’ between users across a wide range of application types, the guide introduces a number of use cases that cover the typical situations where a common perspective on data and services is required. This includes on- and offline situations as well as the integration of catalogs, or WPS for offline data packaging. The guide explains OWS Context documents from the user perspective in very good detail, provides examples encoded in XML/Atom and GeoJSON, describes the extension mechanisms, and provides an overview of currently available tools and applications.

The TEAM Engine Virtualization User Guide (OGC 16-075) addresses testing of implementations for standard-compliance, which is an important component of the OGC Compliance Program. For that reason, the Compliance Program provides an online free testing facility called TEAM Engine. The TEAM Engine (Test, Evaluation, And Measurement Engine) is a Java-based application for testing Web services and other information resources. It executes test suites developed using the popular TestNG framework, OGC Compliance Test Language (CTL) scripts, and possibly other JVM-friendly languages. The TEAM Engine Virtualization User Guide (OGC 16-075) describes how to generate a virtual machine (VM) or container image that provides a complete TEAM Engine installation along with the latest OGC conformance test suites. This can help install TEAM Engine and the suites in secure environments. The guide uses Packer, an open-source infrastructure definition tool used to create images for a variety of dynamic infrastructure platforms, to generate a complete, ready-to-run TEAM Engine installation that contains the desired set of OGC test suites. The output is a “virtual appliance” that can be imported into VirtualBox, a freely available virtualization product that runs on Windows, Linux, and Mac hosts. The guide concludes with setup instructions to run the TEAM Engine installation on the Amazon Elastic Compute Cloud (EC2).

The CITE User Guide – Profiles (OGC 16-076) complements the guides for the OGC Compliance Program. The User Guide offers guidance about how to develop and execute a test suite that verifies an implementation of some OGC application profile. With TestNG and CTL, it briefly describes the two mechanisms to encode tests. The guides concludes with a description on how to invoke test suites using a REST API and the use of the W3C EARL vocabulary.

2.3.2. Model Conversion, Capabilities, and Conflation

Testbed-12 enhanced a number of aspects addressing application profile handling, automated model conversions, context and capabilities, data conflation, and TopoJSON.

Application Schema Profiles & Model Conversion

The ShapeChange Engineering Report (OGC 16-020) documents enhancements for schema profiling and converting an ISO 19109 compliant application schema to an RDF/OWL/SKOS encoding. This has been achieved by enhancing the tool ShapeChange to support implementations that focus on a subset of the use cases in scope of the original application schema, and for deriving an ontology representation of the application schema (using RDF(S)/SKOS/OWL) – to support Semantic Web / Linked Data implementations.

The schema profiling work addresses situations where only subsets of large, all encompassing information models such as the National System for Geospatial-Intelligence (NSG) Application Schema (NAS), will be made available and potentially further constraint. Testbed-12 continued developments started in previous testbeds and now allows for providing constraints in external configuration files. Testbed-12 added support for overwriting multiplicity settings, adjustment of uniqueness and ordering, setting of association role navigability, marking of classes as abstract, adjustment of OCL constraints, and to parse/validate constraints after profiling.

To allow for conversion of UML to RDF/OWL/SKOS, Shape change was enhanced to support the final version of ISO 19150-2 and to support additional/alternative rules from those specified therein. In addition, Shape change now supports specification of controlled vocabularies and taxonomies, provides various configuration options that improve interoperability with, and reuse of, ontologies from outside the geospatial community, and supports among others N-triples format as output. The enhancements have been tested with the conversion of the NSG application schema to NEO (NSG Enterprise Ontology) and NTAX (NSG Taxonomy).

Converting UML models into JSON instances, schemas and JSON-LD @contexts

Testbed-12 build on previous work from Testbed-11 and Testbed-10 to further pursue JSON as a second major data encoding next to XML/XML-Schema. The Implementing JSON/GeoJSON in an OGC Standard Engineering Report (OGC 15-053) resulting from Testbed-11 enumerates a number of strategies for implementing JSON in OGC services and OGC encodings. In addition, a mechanism to migrate XML to JSON was proposed in Testbed-10 and documented in the Engineering Report Rules for JSON and GeoJSON Adoption: Focus on OWS-Context (OGC14-009).

Testbed-12 developed a proposal to derive a JSON or JSON-LD encoding directly from UML models without using XML/XML-Schema as an intermediate step. The proposed rules can be divided into two categories: rules for JSON instances and rules for JSON schemas. All work is documented in The Javascript-JSON-JSON-LD ER (OGC 16-051). Further information is provided in the Testbed-12 Engineering Report OWS Context / Capabilities (OGC 16-051).

OWS Context Encoding in HTML5

The OWS Context standard defines a core model that specifies a fully configured service set which can be exchanged (with a consistent interpretation) among clients as a “OWS Context document”. The goal is to support use cases such as the distribution of search results, the exchange of a set of resources such as OGC Web Feature Service (WFS), Web Map Service (WMS), Web Map Tile Service (WMTS), Web Coverage Service (WCS) and others in a ‘common operating picture’. Additionally OWS Context can deliver a set of configured processing services (Web Processing Service (WPS)) parameters to allow the processing to be reproduced on different nodes.

The core model defined in the OGC OWS Context Conceptual Model (OGC 12-080r2) can be serialized according to the OGC OWS Context Atom Encoding Standard (12-084r2), or, following the rules of OGC Testbed-10 Rules for JSON and GeoJSON Adoption: Focus on OWS-Context (OGC14-009r1), as (Geo)JSON. Testbed-12 developed a third alternative, which follows the recommendations developed by Schema.org, a collaborative, community activity with a mission to create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond. Schema.org provides vocabularies that can be encoded in RDFa, Microdata, or JSON-LD. The OWS Context: JSON, JSON-LD and HTML5 Engineering Report takes on the Schema.org approach and develops a HTML5 based encoding to implement OWS Context documents with the goal to make OWS Context documents easier to process, index, and eventually discoverable using search engines in the Web. The approach favors Microdata and RDFa encodings over JSON-LD to avoid, first, the decoupling of HTML from the embedded OWS Context information; and second, the potential overlap with the (Geo)JSON encoding already existing for OWS Context documents. The first was used to allow CSS selectors and JavaScript DOM document selectors to access parts of the semantic annotated HTML to e.g. change visualization styles or add behaviors (events) to the HTML code. The second was based on general considerations on the type and origin of the underlying models.

The Testbed-12 work maps OWS Context as closely as possible to Schema.org elements to maximize vocabulary reuse and to leverage already provided search-engine support for these widely used vocabularies. It turned out that it is not possible to make a perfect one-to-one mapping between the OWS Context and Schema.org elements, but most of the elements and attributes can easily be paired. Only a few properties needed some relaxed semantics of their actual definitions. Validation with no errors in the Google Structured Data Testing Tool was a condition in making the final proposed mapping.

Capabilities

The OWS Context / Capabilities Engineering Report (OGC 16-052) addresses important improvements in the context of service metadata. Traditionally, service metadata is provided in response to a GetCapabilities request. The response is often referred to as the Capabilities document, which describes the service and resources that the service exposes. Resources are listed in the service metadata document inside a section named Contents (following the guidelines provided in OWS Common). There are two main limitations to the current Contents section approach. First, OWS Common only prescribes a minimum set of metadata in figure 7 of OGC 06-121r9 called DatasetSummary. This element needs to be sub-classed (i.e. extended) by each OGC Web service specification. As a result, each specification proposes its own flavor and integrated client developers need to implement them separately. Second, if the number of resources is very large or the service is highly dynamic, the Contents section can be extremely long or rapidly outdated and neither the service nor the client can handle it efficiently. The proposed solution documented in the OGC 16-052 OWS Context / Capabilities Engineering Report includes two aspects: It suggests to encode the Contents section using the OWS Context model and encoding; and introduces OpenSearch to request a subset of the resource descriptions offered by the service and thus supports spatial and temporal filtering of resources following OGC 10-032r8 OpenSearchGeo. The Engineering Report concludes with a critical evaluation of the proposed solutions and a number of change requests to OWS Common.

Conflation

Previous testbeds (Testbed-9, Testbed-10) experimented with the WPS as front-end to conflation tasks. Testbed-12 built on these experiences and developed a RESTful interface to a WPS with focus on complex conflation tasks that require user interaction. The RESTful binding described in the WPS Conflation Service Profile Engineering Report (OGC 16-022) will serve as a blueprint for an additional binding to be added to WPS 2.0. In addition, the Engineering Report describes how a WPS 2.0 Conflation Profile could look like in the hierarchical profiling approach of WPS 2.0. The developed profiles developed belong to the first WPS 2.0 profiles ever created and serve serve as proof-of-concept and blue-prints for future profiling efforts. To be fully explored, client applications need to be developed that support the WPS profile approach. Testbed-12 experimented with the conflation tool Hootenanny, an open source conflation tool that features the automated and semi-automated conflation of polylines, polygons and points.

TopoJSON

The OGC WFS provides an interoperable method to access and update geodata across network-connected components. However, results from previous OGC activities and operational deployments indicate that transferring large volumes of geodata from a WFS over a network with poor or very low bandwidth can take a significant amount of time, and network capacity.

To help meet this challenge Testbed-12 developed prototype implementations and conducted Technology Integration Experiments to assess TopoJSON as an encoding that may be delivered across a common, standard OGC service interface such as WFS. Use of TopoJSON as an output format for WFS may reduce redundancy in feature data representations and decrease the geospatial data file size. The results of this work item are covered in the TopoJSON, GML Engineering Report (OGC 16-056).

TopoJSON is a JSON format for encoding geographic data structures in a shared topology. A TopoJSON topology represents one or geometries that share sequences of positions called arcs. TopoJSON, as an extension of GeoJSON, supports multiple geometry types: Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon, and GeometryCollection. Rather than representing geometries discretely, geometries in TopoJSON files are stitched together from shared line segments called arcs. Arcs are sequences of points, while line strings and polygons are defined as sequences of arcs. Each arc is defined only once, but can be referenced several times by different shapes, thus reducing redundancy and decreasing the geospatial data file size.

Given the struture of WFS operations, the WFS OutputFormat and BBox parameters of the GetFeature request may be potential “integration points” for TopoJSON, even though TopoJSON documents technically represent arcs, not features. The source data for TopoJSON WFS output formats may be common feature representations currently used on WFS including GML and GeoJSON.

2.3.3. Communication between SDI Components

Given the distributed nature of Spatial Data Infrastructures (SDI), communication aspects are of primary interest when exploring SDI architectures. This section explores Testbed-12 work packages on asynchronous communication patterns and principles, synchronization, security, catalog integration, and the handling of resources in OGC standards based infrastructures based on REST principles.

Asynchronous Communication

Most current OGC service specifications define synchronous communication patterns, i.e. after sending a request to an OGC service, clients need to wait for the response. But several applications, e.g. delivery of information about events or executing complex environmental models with long runtime, need asynchronous client-server interaction patterns that do not require clients to keep the connection to the server continuously open in order to wait for responses. At the moment, several approaches exist in OGC to implement asynchronous communication: WPS fac?ades, service-specific extensions, and OGC Pub-Sub. The first builds on the capabilities of the WPS, which offers asynchronous communication patterns and therefore can be used as fac?ade to any other service. The second develops an individual solution per service interface (in fact, the WPS fac?ade approach is such a solution), and the third option builds on the Publish/Subscribe Interface Standard, which defines publish/subscribe functionality independently of the binding technology (e.g., KVP, SOAP, REST).

The Implementing Asynchronous Services Response Engineering Report (OGC 16-023) summarizes and compares the results from asynchronous communication experiments executed in Testbed-12. Testbed-12 implemented the WPS fac?ade approach against WFS and WCS service instances, added support for asynchronous communication to a WFS using additional request parameters, and added Publish/Subscribe support to catalogs. Further details on the implementation of the Publish/Subscribe Interface Standard using catalogs are provided in PubSub / Catalog Engineering Report (OGC 16-137).

It can be summarized that all three solutions have been implemented successfully. The WPS fac?ades were successfully tested with WFS and WCS SOAP implementations, also including SOAP security. They add the burden of WPS support to the client, as the original service interfaces are now hidden.

The service-specific solution requires modifications to the service interface and subsequent modifications to the client code to make use of the new functionality. On the other side, the light-weight asynchronous request processing protocol described in the asynchronous request processing clause of the Implementing Asynchronous Services Response Engineering Report is sufficiently generic that it could easily be implemented in other OGC Web services as well. To that end, a change request has been posted (CR416) requesting that the description of the protocol be added to OGC Web Service Common Implementation Specification (OGC 06-121r9).

The third solution, based on the Publish/Subscribe Interface standard, turned out to be the most flexible of all three solutions (and can include the other two if necessary). Testbed-12 developed specific PubSub 1.0 extensions for CSW 2.0.2 and 3.0, leveraging on standard functionalities, data models, and semantics to enable sending notifications based on user-specified area of interest and/or keywords. The detailed extensions, implementation experiences as well as a proposal for a general, basic mechanism for enabling PubSub for the generic OGC Web Service over the existing request/reply OWS’s are documented in PubSub / Catalog Engineering Report (OGC 16-137). Testbed-12 contributed directly to the development of a Pub/Sub RESTful binding (OGC 13-132, OGC Publish/Subscribe Interface Standard 1.0 – RESTful Protocol Binding Extension; internal draft) by implementing a PubSub-enabled CSW with a RESTful interface.

Asynchronous messaging in the aviation domain is described in section Aviation Asynchronous Messaging.

Synchronization

The synchronization work performed in Testbed-12 continuous work done in Testbed-11 to develop a protocol for synchronizing data between two enterprise servers. While the protocol itself is generic, the Web Feature Service Synchronization Engineering Report (OGC 16-044) describes its application to Web Feature Servers. In the simplest terms, the protocol involves each synchronization peer accessing the other’s “Sync” resource to get the set of changed objects since the last time the “Sync” resource was accessed. In the case of web feature servers, the objects are features. The requesting peer then compares that list of changed features with the identically identified features in its data store and performs any necessary changes so that the feature states match. In addition to Testbed-11, Testbed-12 experimented with abstract query elements, extended the Sync operation with additional parameters, and invested proper handling of references as well as concurrency and consistency issues.

The Engineering Report further clarifies the relationship to the Geo Synchronization Service (GSS) (OGC 10-069r2). In contrast to the peer-to-peer lightweight sync in Testbed-12, the GSS behaves more like a solid pub-sub approach with controlled synchronization procedures including additional quality assurance or validation and approval processes.

Security

Testbed-12 did important ground work to ensure interoperability with and between secured components based on OGC interface standards, and reviewed the domain specific situation for the aviation domain. The OWS Common Security Extension Engineering Report (OGC 16-048) describes fundamental base work required by the OWS Common – Security SWG to define an extension to the existing OWS Common Standard that ensures interoperability between a secured service instance and client. This “OWS Common Security Extension” adds content to the standard regarding the implementation of security controls in such a way as to preserve interoperability. These additions will be in two areas. The first extension will provide more detail on the use of the HTTP protocol, particularly as it related to security controls. The second extension will address discovery and negotiation of security controls. This will provide an annotation model for the Capabilities document to enable a service provider to specify the security implemented at a service instance (endpoint). The described solutions have been implemented in a number of components developed for Testbed-12. All experiences made during the implementation work are described in the OWS Common Security Extension Engineering Report.

The Aviation Security Engineering Report (OGC 16-040) gives the readers an overview of the topic of cyber security in the aviation domain. See Aviation Security for further details.

Catalog Integration

The integration of different catalogs is documented in the Catalogue and SPARQL Engineering Report (OGC 16-062). The Engineering Report evaluates interoperability aspects and tests using a multi-catalog client in a heterogeneous environment with Catalogue Service for Web (CSW) version 2.0.2 and 3.0, including services based on the ebRIM profile of CSW 2.0.2 and an extension of CSW 3.0 with OpenSearch and SOAP. All catalog instances had the same datasets stored. The actual integration was implemented using a mediating catalog service with GeoSPARQL and DCAT support.

The Engineering Report also provides a comparison of CSW and services based on the Data Catalogue (DCAT) specification covering functionality, expressiveness and usability of CSW and DCAT. This work, which produced a crosswalk between ISO profiles and DCAT that was informed by work done by the European Commission on developing a geospatial profile for DCAT (known as GeoDCAT) complements the work done on SRIM, the Service Registry Information Model described in section Semantic Portrayal, Registry, and Mediation.

As already outlined in the REST User Guide, Testbed-12 investigated the realization of OGC interface standards following Representational state transfer (REST) patterns and guidelines to provide interoperability between computer systems on the Internet. REST-compliant Web services allow requesting systems to access and manipulate representations of Web resources using a uniform and predefined set of stateless operations. The REST Architecture Engineering Report (OGC 16-035) provides an overview on different REST service implementations in the Testbed-12 and in related activities.

The Engineering Report provides a general introduction in the concept of RESTful architectures and summarizes the advantages and disadvantages of using RESTful servers instead of e.g. POX-based Web Services. It also briefly sketches how existing OGC services may be mapped to RESTful APIs. It then investigates REST server implementations realized in Testbed-12 for WFS, WMS, WMTS, WCS and WPS; and discusses how they perform in terms of RMM levels (see below), complexity and implementation efforts, service capabilities, JSON encodings, associations, URL templates vs. HATEOAS, request parameters and filtering, as well as security.

The Richardson Maturity Model (RMM) is a way to grade an API according to the constraints of REST. The better an API adheres to these constraints, the higher its score is. The Richardson Maturity Model knows 4 levels (0-3), where level 3 designates a truly RESTful API. The REST Architecture Engineering Report investigates how different OGC service interfaces perform against this model. As a result, it became obvious that the massive use of hypermedia controls works only for some service types (e.g. WFS, WPS, WMTS returning TileJSON), but much less for others (e.g. WMS, WCS, or WMTS not returning TileJSON).

The Engineering Report concludes with a set of recommendations that help building interoperable solutions implementing REST, including identification of and associations between resources, API descriptions and discovery of resources, usage of HTTP verbs and status codes, and request parameterization and content negotiation.

2.3.4. Compliance

In addition to the TEAM Engine Virtualization User Guide (OGC 16-075) and the The CITE User Guide – Profiles (OGC 16-076), Testbed-12 developed the WFS 2.0 CITE and Reference Implementation (RI) (OGC 16-025). The Engineering Report documents the capabilities of the reference implementation, its installation procedure, and the integration and testing with CITE validation tools. The report further proposes best practices to implement a fully compliant WFS v2.0

2.4. Arctic Spatial Data Infrastructure

Testbed-12 addressed two domains to experiment with and to demonstrate the value of interoperability arrangements in specific domains. The arctic as a geographic domain, and aviation as a thematic domain. This chapter describes the results from experimenting with data and services used to generate a better understanding of the Arctic from multiple perspectives.

Testbed-12 supported the OGC Arctic Spatial Data Pilot by doing research on the current status of the Spatial Data Infrastructures for the Arctic and developed two scenarios that investigate the effects of melting sea ice and thawing permafrost. The scenarios focused on data handling aspects such as the provision of Arctic data using WCS, the implementation of a client application that can demonstrate the usage of ArcticSDI data, analysis of the current Earth Observation profile for serving ArcticSDI data needs and the integration of data served as OPeNDAP machines, and the efficient handling of netCDF data. All results are captured in the Arctic Spatial Data Infrastructure Engineering Report (OGC 16-063). Based on actual integration tests, the Arctic domain work developed recommendations on how to improve the https://portal.opengeospatial.org/files/?artifact_id=42722[WCS Earth Observation profile. The recommendations include MIME type support to specify profile versions and data models of netCDF; and support for netCDF data compression.

2.5. Aviation

Testbed-12 addressed two domains to experiment with and to demonstrate the value of interoperability arrangements in specific domains. The arctic as a geographic domain, and aviation as a thematic domain. This chapter describes the results from experimenting new approaches to optimize data discovery, exchange, and analytics in the aviation domain. In detail, the following aspects have been addressed:

• Aviation Architecture: (OGC 16-018)

• FIXM: (OGC 16-028)

• Aviation Security: (OGC 16-040)

• Aviation Semantics: (OGC 16-039)

• Catalog Services for Aviation: (OGC 16-024)

• Aviation Data Broker: (OGC 16-045)

• Aviation Asynchronous Messaging: (OGC 16-017)

• Semantics of Business Vocabulary and Business Rules (SBVR) for Aviation: (OGC 16-061)

The work achieved in Testbed-12 is an important contribution to the aviation community. It provides a set of recommendations on how to best use OGC standards in the context of System Wide Information Management (SWIM) and Air Traffic Management (ATM) information exchanges. The results are expected to be used by standardization organizations and governance bodies in charge of the development of ATM standards for SWIM.

2.5.1. Aviation Architecture

The entire aviation architecture as implemented in Testbed-12 is documented in the Aviation Architecture Engineering Report (OGC 16-018). The report puts all aforementioned work items into context and facilitates the understanding of the overall performed work. It documents the architecture with its components and re-iterates the key requirements and solutions. It is recommended to start with this Engineering Report to get an overview of the Testbed-12 aviation work items before enlarging upon other topics as described below.

Figure 3. Overview of the Aviation Architecture

2.5.2. Flight Information Exchange Model (FIXM)

The FAA and EUROCONTROL, in conjunction with multiple other international partners as well, are currently in the process of developing the Flight Information Exchange Model (FIXM). FIXM is an exchange model capturing Flight and Flow information that is globally standardized. The need for FIXM was identified by the International Civil Aviation Organization (ICAO) Air Traffic Management Requirements and Performance Panel (ATMRPP) in order to support the exchange of flight information as prescribed in Flight and Flow Information for a Collaborative Environment (FF-ICE). FIXM is the equivalent, for the Flight domain, of Aeronautical Information Exchange Model (AIXM) and Weather Information Exchange Model (WXXM), both of which were developed in order to achieve global interoperability for, respectively, Aeronautical Information Systems (AIS) and Meteorological Information (MET) exchange. FIXM is therefore part of a family of technology independent, harmonized and interoperable information exchange models designed to cover the information needs of Air Traffic Management.

Previous OGC IP initiatives developed an architecture that supports the exchange of AIXM and WXXM data. The FIXM GML Engineering Report (OGC 16-028) describes the integration of Geography Markup Language (GML) profile elements into FIXM, specifically, the Feature, Time, Geometries and Units of Measure (UOM), into FIXM version 3.0.1 and drafts of FIXM 4.0. The report further provides recommendations and change requests (CR) on the implementation of GML elements for use by the FIXM development community.

2.5.3. Aviation Security

The Aviation Security Engineering Report (OGC 16-040) gives the readers an overview of the topic of cyber security in the aviation domain. The focus has been on security aspects in conjunction with OGC compatible Web services and develops a secure Aviation Architecture based on brokered service access and asynchronous communication with message brokers as it is typically for the heterogenous SWIM environment.

2.5.4. Semantics in the Aviation Domain

Aviation semantics explores the usage of FAA Web Service Description Ontological Model (WSDOM) to improve service discovery within Spatial Data Infrastructures. WSDOM is a formal ontological model based on OWL-S and FAA Service Taxonomies that is intended to be a basis for model-driven implementation of SOA-related artifacts.

The results of this work are documented in Aviation Semantics Engineering Report (OGC 16-039). It starts giving a short introduction into the concept of semantic service description and discovery using the WSDOM ontology while considering OWS” characteristics and specific needs by aviation traffic management. An overall goal is to integrate OGC technologies with aviation semantic web technologies, in particular those related to service and data discovery. The Testbed-12 focus was on semantic aviation service description for OWS compatible aviation services. Goal was to understand interoperability implications for Web services implementing the traditional OGC GetCapabilities request-response-model while leveraging the power and expressiveness of query languages such as SPARQL and GeoSPARQL.

2.5.5. Catalog Services for Aviation

The Catalog Services for Aviation Engineering Report (OGC 16-024) presents guidance concerning the use of OGC catalog services in the aviation domain. A wide variety of metadata resources can be readily published and discovered using the OGC CSW-ebRIM application profile, which marries the CSW catalog interface to the OASIS ebXML registry information model (ebRIM). However, existing SWIM registries currently under development by the FAA and EUROCONTROL do not implement any OGC standards. The Engineering Report explores the prospects for enhancing SWIM registries by a) integrating OGC catalog functionality, and b) accommodating OGC service descriptions.

2.5.6. Aviation Data Broker

The Data Broker Engineering Report (OGC 16-045) describes the results of the service composition and brokering work accomplished as part of the aviation thread.

An important principle of a Service Oriented Architecture (SOA) is the notion of composing capabilities provided by individual services into complex behavior. A requester should be able to compose a solution using functionality or data offered by multiple services without worrying about underlying differences in those services. As already described in the Web Integration Service discussion, each OGC service is designed to offer a specific type of data product via a service-specific interface.

To achieve the required composition, Testbed-12 built on top of the Data Broker work accomplished in OGC Testbed 11, which at that time primarily focused on brokering of AIXM 5.1 data through OGC WFS. Now Testbed-12 added additional OGC Web service interface types to the list of data sources.

The work on service brokering lead to a number of recommendations, e.g. to extend WMS with increased support for OGC Filtering to enhance portrayal capabilities; addition of an ISO 19115 metadata property to AMXM 2.0 features, to be able to add lineage and other metadata information when brokering individual features; addition to add an ISO 19115 metadata property to a WFS FeatureCollection type, to allow describing portrayal and other metadata information (such as portrayal endpoints) to any type of data requested from a WFS service. Apart from these recommendations, a change request has also been identified for FIXM 4.0, i.e. the integration of an optional ISO 19115 / 19139 metadata property on a Flight feature (details described in FIXM GML Engineering Report (OGC 16-028)).

2.5.7. Aviation Asynchronous Messaging

The Asynchronous Messaging for Aviation Engineering Report (OGC 16-017) describes the results of the asynchronous messaging study and implementation applying OGC Publish Subscribe Interface Standard 1.0 (OGC PubSub 1.0) in the aviation domain. The goal was to develop an Publish/Subscribe messaging architecture between different aviation components such as clients, data provider instances, and Data Brokers. The architecture study took various messaging protocols such as AMQP 1.0, JMS and OASIS WS-Notification into consideration. Special attention was laid on the smooth integration of middleware solutions implementing the various messaging protocols and the OGC Publish Subscribe Interface Standard 1.0.

Specific service level integrations (i.e. FAA SWIM and SESAR SWIM) have been investigated but not implemented. In this context, an AMQP 1.0 delivery profile for OGC PubSub 1.0 has been defined. The profile allows for the management of subscriptions and the corresponding delivery of messages using the AMQP 1.0 protocol in an interoperable way. A proof of concept implementation has been realized to test the general applicability of the architecture. The implementation supports supports geospatial subscriptions using OGC Filter Encoding 2.0 in combination with data publications for AIXM 5.1 and FIXM 3.0.1 and integrates well with existing established systems such as Harris Data Exchange (DEX).

2.5.8. Semantics of Business Vocabulary and Business Rules (SBVR) for Aviation

Testbed-12 advanced previous work in the area of business rules for the Aeronautical Information Exchange Model AIXM 5 based on SBVR.

In the context of AIXM, business rules ensure the consistency of the data. Syntactic correctness is enforced by the XML Schema, whereas semantic correctness is described using SBVR rules. The SBVR Engineering Report http://docs.opengeospatial.org/per/[(OGC 16-061) evaluates the use of geo-spatial operators and constraints in SBVR, including a proof of concept for their automatic interpretation by software. It gives guidelines on how to deal with temporality aspects and how to extend the applicability of SBVR towards filtering expressions. Furthermore, the Engineering Report identifies limitations of the currently available SBVR vocabulary. It recommends to extend SBVR by geometry construction functions like spatial union for a set of geometries, to extend SBVR by geometry literals based on Well-Known Text (WKT), to introduce specialized operators to check advanced constraints such as the smoothed radius of a composed curve, the collinearity of a set of points, or the evaluation of a logical expression defined through objects of type ConditionCombination.

2.6. Data Handling and Models

The following work items are categorized as under Data Handling and Models in Testbed-12:

• GeoPackage

• Vector Tiling

• Data Quality

• LiDAR Streaming

• Persistent Data

2.6.1. GeoPackage

Testbed-12 did intensive research on GeoPackages. Static and dynamic rendering aspects of GeoPackage content is described in OGC 16-029, which discusses mechanisms for providing user-defined map symbology for features in a GeoPackage structured data store. The Geopackage US Topo ER describes the production of GeoPackages that contain both features and instructions for styling these features as well as ortho-imagery, shaded relief raster tilesets, national wetlands raster tilesets and elevation data derived from USGS provide 1/9 arc second elevation imagery. These GeoPackages combine the USGS Topo Map Vector Data Products and the Topo TNM Style Template to allow for geometry and feature styling and discuss necessary extensions, e.g. to display hierarchies.

Other work items focused on Routing based on GeoPackages, allowing users to perform route generation and evaluation in offline situations. The Engineering Report OGC 16-029 addresses aspects such as just-in-time loading of data, use of TINs, and necessary limitations caused when balancing flexibility vs. interoperability. Mechanisms to allow users to select pre-designated weighting rules or cost functions that influence route traversal provide additional functionality.

Integration of GeoPackages into mobile applications has been further researched by analyzing the Common Map API (CMAPI) as a mean to overcome challenges with map APIs such as Google Maps and OpenLayers in the context of GeoPackages. Both APIs do not support GeoPackages or even GeoPackage constructs like Well-Known Binary (WKB) and have no direct way to communicate with each other. In terms of performance, JavaScript APIs are not suitable for processing large volumes of data. The solution developed in Testbed-12 makes use of the standardized publish/subscribe model provided by CMAPI and used native implementations of the NGA JavaScript GeoPackage library. The solution is documented in OGC 16-030, the GeoPackage Mobile Apps Integration ER.

The implementation of GeoPackages that comply with externally provided application schemas was evaluated using the National System for Geospatial-Intelligence (NSG) GeoPackage Profile. The profile defines and tailors the implementable provisions prescribed for the NSG for a GeoPackage based on the OGC GeoPackage encoding standard. The NSG GeoPackage Profile Assessment ER assesses whether requirements as specified in the proposed profile are specific enough to allow for any two independent GeoPackage implementers to produce and consume interoperable NSG GeoPackages and to avoid misinterpretations, including aspects such as proper use of CRSs or extensions. Concerns with the profile are outlined and recommendations for improvement are provided. The report concludes with specific recommendations to support vector tiling in the NSG GeoPackage Profile.

All change requests resulting from the GeoPackage work described above have been captured in the GeoPackage Change Request Evaluations ER.

2.6.2. Vector Tiling

Two Engineering reports address Vector Tiling, OGC 16-068 and OGC 16-067. Vector tiling was developed to be the equivalent of image tiling but for vector data. Vector Tiling has the benefits of tiling, such as caching, scalability and quick retrieval while maintaining the benefits of vector data; the ability to perform analysis, editing and styling of the features directly in the client.

OGC 16-068: Vector and Raster Tiling Scheme ER introduces the topic of Vector Tiling and describes how client applications can access data stores such as Open Street Map that include over 30GB of vector data without memory shortages or unacceptable performance. It discusses the fundamental challenges such as data coherence, levels of detail, tile sectioning, or unique feature identification for the two principles types of Vector Tiling, i.e. render and feature-based tiling. It further describes the relationship of Vector Tiles to other OGC Standards, such as e.g. WMTS or CDB LINKS. The implementation of the recommendations given in OGC 16-068 using a specific tile encoding and storage format is documented in OGC 16-067: Vector Tiling ER, and OGC 16-038 provides specific recommendations to support vector tiling in the NSG GeoPackage Profile.

2.6.3. Quality

Data & Service Quality aspects are of overarching importance for the usability of data and services in distributed computing environments. Data & Service Quality pertains to a number of use cases, such as service advertising and service validation. Common to all use cases are shared preconditions, such as the existence of an unambiguous definition of the concept of data quality, and a set of measurable parameters that allow specifying data & service quality. Once provided, service infrastructure components allow for provisioning of quality parameter values based on reference data or threshold values. Testbed-12 addressed these aspects in two Engineering Reports. OGC 16-050: Imagery Quality and Accuracy ER addresses the concept of data quality for images, taking into account aspects such as completeness, logical consistency, positional accuracy, temporal accuracy and thematic accuracy. The work is based on Digital Globe’s A3C framework (A3C standing for Accuracy, Currency, Completeness, and Consistency), ISO 19157 and QualityML vocabularies, and proposes encodings compatible with common metadata standards.

Handling and assignment of quality parameters based on atomic WPS instances that allow quality assessment and metadata development is documented in OGC 16-041: WPS ISO Data Quality Service Profile ER. The report addresses the provisioning of quality parameters as defined in ISO 19157.

2.6.4. LiDAR Streaming

The OGC 16-034: LiDAR Streaming Engineering Report investigates the support of LiDAR data streaming using OGC SWE specifications analogue to JPIP streaming. Using OGC SWE, in particular the Sensor Observation Service (SOS) specification, has the advantage of getting a rich feature model for hierarchical subsetting of scenes in combination with rich metadata support.

As JPIP performance is partly based on caching mechanisms, whereas SOS is a stateless protocol, point cloud hierarchies have been implemented combined with Potree, an octree data format that supports hierarchical data generalization. This approach ensures that features such as loading LiDAR scenes in different resolutions for quick overviews or detailed views are enabled. The entire implementation approach including loading and storing point cloud data in PostgreSQL is described in OGC 16-034.

The list of recommendations for future work included, among other aspects, the amendment of the SOS specification for binary response support, more guidance on LiDAR streaming metadata at SOS instances, and streaming specific aspects such as compression.

2.6.5. Persistent Data

Testbed-12 made an effort on collecting data to be available for future Innovation Program initiatives. The data has been made persistently available on an FTP server. The data and corresponding styles and symbols are described in two Engineering Reports. The first focuses on the actual data, the second on accompanying symbols and styles. Given that some data sets have been made available exclusively to the testbed, you may have to login to the OGC portal in order to retrieve them. 2D Test Dataset Implementation with Documentation describes various data sets that have been made available on an FTP server for download, describes issues experienced with Feature Types in GML 3.2 and NAS Schema 7.2 and discusses transformation issues with OpenStreetMap (OSM) feature type datasets that have been collected over the San Francisco Bay area during Testbed-11. Transforming the OSM datasets to GML using GDAL, the resulting datasets ended up having a number of problems that made them unusable for exploitation for the testbed. Complementing the data, Testbed-12 produced 2D Datasets Symbols and two Styles associated with the OpenStreet Map Dataset, described in the 2D Test Dataset Symbols and Styles Implementation with Documentation. First the OpenStreetMap Style Set, which is based on the style used by the OSM web site that uses the Mapnik CSS; and second the LTDS Style Set, based on the symbologies defined for the Local Topographic Data Store (LTDS). The style sets have been produced using OGC Styled Layer Descriptors.

2.7. Big Data

As part of the Big Data block, Testbed-12 focused on:

• Large Tile Datasets

• Tile Access & Transport

Currently, there is no recommended approach in OGC to handle large raster tile data stores. Though GeoPackage has been defined to serve as a container for geospatial data including raster tiles, other approaches had not been investigated in further detail in the past. Testbed-13 investigated the application of the GeoPackage data model to PostgreSQL and tested its performance.

2.7.1. Large Tile Datasets

GeoPackage makes use of the SQLite database engine. To test alternative storage options, Testbed-12 experimented with PostgreSQL as an alternative database. Data has been extracted from a GeoPackage, stored in a PostgreSQL data base, and then compared in terms of database size and performance. PostGIS was briefly included in the analysis but quickly discarded due to the enormous increase in disk size to store the data. The detailed size and performance results are documented in OGC16-036: Testbed-12 Big Data Database Engineering Report.

The report further includes with a brief introduction of Array Databases as a mean to apply declarative query support for massive gridded/rasterized data and describes its path to standardization as ISO 9075 Part 15:SQL/MDA (Multi-Dimensional Arrays). Though the GeoPackage/PostgreSQL tests have been executed up to data bases loaded with several GB, array databases allow massive query parallelization and therefore processing of Terabytes within short time frames. The report concludes with a brief review of OGC SWE in the context of big data.

2.7.2. Tile Access & Transport

With the increased incidence of WMTS instances, the demand for an efficient access and exchange of tile collections is emerging. The OGC 16-049: Testbed-12 Multi-Tile Retrieval Engineering Report describes experiments with and extensions to WMTS and WPS to allow for efficient exchange of high number of tiles in container formats such as GeoPackage. OGC 16-049 suggests the implementation of the WMTS GetTiles operation and extensions to the WPS GetStatus and GetResult operations to provide partial outputs during process execution.

2.8. Semantics

As part of the Semantics block, Testbed-12 focused on:

• Semantic Enablement

• Semantic Portrayal, Registry, and Mediation

• General Feature Model and Web Object Service

• Semantics in the Aviation Domain

2.8.1. Semantic Enablement

The OGC 16-046: Evaluate Semantic Enablement Engineering Report highlights the key findings and discussions from Testbed-12 that enable semantic interoperability, including semantic mediation, schema registries, and SPARQL endpoints. It references key findings from the Semantic Portrayal ER and helps to understand the current OGC discussion on semantics in general. Readers interested in geospatial semantics in Testbed-12 should read this report first.

2.8.2. Semantic Portrayal, Registry, and Mediation

The OGC 16-059: Semantic Portrayal, Registry, Mediation Services Engineering Report documents the findings of the activities related to the Semantic Portrayal, Registry and Mediation components implemented during the OGC Testbed-12. This effort is a continuation of efforts initiated in the OGC Testbed-11.

Central component is the Semantic Registry, a registry that extends the DCAT standard with additional concepts to allow for services, schemas, schema mappings, or portrayal information to be registered. The Registry features the Semantic Registry Information Model (SRIM), implemented as a superset of DCAT, which defines the core reusable classes and properties, introduces the notion of releases and supports version tracking using the PAV ontology. To improve the discovery and understanding of service APIs, SRIM defines services as first class objects and has an API documents class to describe APIs using simplified descriptions rather than building on the complex ISO 19119 model. This work extends the crosswalk analysis of ISO 19115 metadata and the DCAT model as described in section Catalog Integration.

The Semantic registry can be accessed by a REST API using the Hypermedia Application Language (HAL) and is used by the Semantic Mediation Service as well as the Semantic Portrayal Service. It has been implemented as a integration engine for various catalog service types (CSW 2.0.2, CSW 3.0, CSW ebRIM) and features a SPARQL endpoint that allows querying the whole registry or given registers.

The Semantic Registry is used by the Semantic Mediation Service and the Semantic Portrayal Service. Both are implemented as clients to the Semantic Registry. The Semantic Mediation Service supports the transformation of a dataset from one schema to another. The service provides a REST API that allows for search and discovery of schemas and schema mappings and for performing transformations and validation.

The Semantic Portrayal Service builds on the work accomplished in Testbed-11, where a portrayal ontology was developed with support for point-based symbols on emergency management symbologies. Testbed-12 refined and extended the portrayal ontology to an style, symbol, symboloizer, and graphic ontology with support for a rich set of styles, text, point, line, and area symbols, as well as graphics. The ontology is now better aligned to OGC Styled Layer Descriptor (SLD) and OGC Symbology Encoding (SE).

2.8.3. General Feature Model and Web Object Service

With a growing requirement to carry out complex analysis in large multi-disciplinary, heterogeneous data collections, an approach is required to extract equivalent information from dissimilar content. The more information can be normalized, the easier it will be to correlate the content. Given that almost all data has a spatio-temporal component, Testbed-12 looked into the idea of defining a spatial-temporal service and analyze which collection of data types, operations and architecture patterns are necessary to spatial-temporal enable any content. This work, documented in the OGC 16-047: General Feature Model Engineering Report, resulted in the description of a new logic service type, the Web Object Service, which has been implemented as a profile of a WFS 2.5 and a ebRIM CSW.

The work has been complemented by a detailed review of the General Feature Model (GFM) as defined in ISO 19109/19101 and OGC Abstract Specification Topic 5: Features. As a result, it has been demonstrated that the GFM and it’s capabilities, which have long been regarded as being of interest to the OGC / the geospatial community only, can accommodate far more requirements than anticipated. Even rather abstract items such as a judgement, a decision or the related body of evidence can be expressed as features and associations. Given that almost all information can be attributed with some spatio-temporal tag, a GFM based approach can play an important role in the integration of geospatial and non-geospatial data and systems.

3. Testbed-13

Testbed-12 has developed over 50 Engineering Reports. These are currently integrated into the various Standards Working Groups (SWGs) of the Standards Program. At the same time, Testbed-13 is on the agenda. Watch the Testbed-13 Website closely for any updates. The figure below already highlights a number of topics that will be addressed.

Figure 4. Overview of Testbed-13

Last updated 2017-07-06 07:58 US EDT