OGC Testbed-17: Call for Participation (CFP)

Evaluate previous work in this area and propose a way forward toward a standards-based solution.

The Sensor Integration Framework The Sensor Integration Framework (SIF) provides a standards framework for the integration of sensor systems regardless of their technical constraints. The SIF proposes a set of Technical Views (TV). Each Technical View is representative of a typical deployment environment and its associated constraints. A TV defines the standards and provides guidance for the development of sensor systems within the constraints of that deployment environment. The set of TVs forms a taxonomy of the known deployment environments. The designer of a sensor system can select the TV appropriate to their requirements, and design to the standards and guidance provided by that TV.

In addition to the Technical Views, the SIF provides a framework for information flow between the Technical Views. This framework defines a mediation service (or services) which assures that a sensor, no matter where deployed, is accessible to the whole federation.

Mediation between TVs takes place on three levels; protocol, format, and information.

MASBUS

The Measures and Signatures Intelligence Enterprise Service Bus (MASBUS) is a pilot implementation of the SIF developed by the U.S. Defense MASINT Office (DMO). It provides a Sensor Observation Service which is capable of mediating content from tactical sensors. MASBUS has been exercised and validated in a number of Enterprise Challenge events. The DMO plans to make MASBUS available to Testbed-17 participants as an Open Source project.

SIF Semantic Model

The SIF Semantic Model addresses the information mediation requirement. It is based on the Semantic Sensor Network Ontology developed by the W3C and OGC. Additional concepts are identified and defined through examination of the data models of existing sensor systems and standards. While it resembles an ontology, some deviations from strict orthodoxy have been taken in the interest of accuracy and usability. This is a work in progress that shall be supported with this Testbed-17 task.

The following sub-work items will be performed under the Sensor Integration Work Item:

The following figure illustrates the work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions and support the development of the Engineering Report(s) with their contributions.

Engineering Reports

Components

There are a number of ways that systems detect and report on moving objects. These systems exist in “stovepipes of excellence”. As a result, users of these systems do not have access to information generated through other means. The ability to combine multiple sources of moving object data would greatly improve the quality of the data and the analytics which could be applied.

To identify an architecture framework and corresponding standards which will allow multiple sources of moving object detections to be integrated into a common analytic environment.

Testbed 16 explored technologies to transform detections of moving objects reported using motion imagery standards (MISB Std. 0903) into OGC Moving Features (OGC 18-075).

That work suggests a notional workflow:

This work is documented in the Testbed-16 Full Motion Video to Moving Features Engineering Report (OGC 20-036).

The OGC Moving Features Standards Working Group (SWG) is currently planning to add a new activity related to OGC APIs to the working group charter. It is expected that this process will be completed at the time of Testbed-17 kick-off. The IP team will watch this process closely to ensure both activities are aligned properly. In any case, Testbed-17 participants will be required to work closely with the SWG and coordinate all efforts.

Testbed 16 demonstrated that Motion Imagery derived Video Moving Target Indicators (VMTI) can be extracted from an MPEG-2 motion imagery stream and represented as OGC Moving Features. This Sub-Work Item shall formalize an architecture for integrating moving object detections, propose standards for the required APIs and content encodings, expand the sources of moving object detection that can be supported, and explore exploitation and enhancement capabilities which would leverage the resulting store of moving features.

The architecture shall include the following components:

This list of components and their definitions serve as a starting point. Participants in this task are free to modify them as conditions require. This work shall be demonstrated using a real-time situational awareness scenario. Ideally, participants experiment with both subscription models as well as data streams to trigger prompt updates in the analytics components based on Moving Feature behavior. Two scenario suggestions are:

Participants are free to devise their own scenario if necessary.

The following figure illustrates the work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions and support the development of the Engineering Report(s) with their contributions.

Engineering Reports

Components

The OGC API family of standards are being developed to make it easy for anyone to provide geospatial data to the web. These standards define resource-centric APIs that take advantage of modern web development practices. The OGC APIs are being constructed as "building blocks" that can be used to assemble novel APIs for web access to geospatial content. The building blocks are defined not only by the requirements of the specific standards, but also through interoperability prototyping and testing in OGC’s Innovation Program.

The emerging OGC API standards allow developers to fully leverage web technologies and principles for setting up service instances. Leveraging the OpenAPI specification, the OGC APIs will enable cost-efficient setup of new services. Instead of months, new service instances can become operational within weeks. This effect is primarily based on a fundamental revision of the customer/provider relationship. The previous generation of OGC Web Services was based on the principle of providing full explorative support to the data consumer (customer/end-user). In consequence, the service provider offered all data at the interface and supported a rich query language. It was up to the data consumer to build the correct queries to access required subsets. This approach was cumbersome to both parties. Instead of offering customer tailored products, the data provider had to support a rich and complex query language that allowed the data consumer to "build their own products". The data consumer had to build complex filter statements to get to the required data. Often enough, it was difficult for the data consumer to find out what query options actually existed.

The new OGC API-based approach now turns this principle around. The service provider now builds tailored products. These products are accessible by calling a specific URL that takes the consumer to a general landing page in the simplest case. From there, the customer can follow links to specific products. Thus, instead of building complex filter queries, the customer can explore all offerings and learn about available products, similar to following hyperlinks on websites. The data consumer only filters if further refinement is required, with support for building filter queries being part of the API definition. The new API paradigm fully leverages web technologies and is built entirely on HTTP operations and principles, which has the great advantage that web developers can code against the new OGC APIs like any other resource-oriented Web API.

The new OGC API principles have enormous potential in the context of data integration across several data providers. Because the data is served in a custom-made fashion, data fusion can be implemented quickly and cost efficiently. The OpenAPI-based Web API definitions and the HTML-encoded landing pages allow customers to understand what is offered at a service instance. The support for multiple encodings (JSON, JSON-LD, XML, RDF flavors, etc.) and the encoding negotiation at runtime allow customers to access data in their preferred model and encoding. The general OGC API support for links allows for integration of strong semantics, which is essential to ensure a common understanding of all data offered at an interface. It is an essential prerequisite for data fusion, where several data sets are combined in order to generate higher level knowledge and information.

Explore the potential of OGC Web APIs in the context of SWIM. Develop an OGC API -Aviation (Aviation API) based on OGC Web API building blocks that enables convenient access to existing SWIM services. Then, demonstrate the capabilities of the new Aviation API in a data fusion scenario.

The following non-exhaustive list identifies previous work that shall be considered in the context of this activity:

The aviation scenario is illustrated in Figure 4. Testbed-17 will exercise the Aviation API with traditional SWIM services (Figure 4: 4a/b) that will be made accessible via the new Aviation API by means of a façade service (Figure 4: 3a/b). Data from these services will be fused and offered as a new product at the fusion service (Figure 4: 2). Two clients shall be developed (Figure 4: 1a/b) as part of this scenario. One with focus on ease-of-use for end-users, one with focus on functionality for developers.

The first client shall be optimized for use by domain experts, but not developers. This client focuses on discovery, access, and visualization of SWIM and fusion resources. The client shall convey a sense of an end-user friendly client that interacts with future Web API-enabled SWIM services. The client shall support both raw and fusion products. The client may hide complexity behind the graphical user interface as necessary. As an example, the end-user in the scenario described below shall be able to see airports that are sensitive to bad weather with some statistics in an attractive way, but certainly not as JSON or other raw format.

The second client shall be developed from a developer’s perspective. Here, the focus is less on visualization and ease-of-use, but on functionality and experimentation. The client shall allow exploring all capabilities of Aviation-API service instances, shall support following links, and help the developer with creation of queries and result analysis. In this case, delivering JSON to the user is a valid option, though other forms of quick result inspection shall be supported as well.

Both clients shall demonstrate the use of the Aviation API with both raw as well as fused SWIM data.

One important element in the context of Aviation data is semantic interoperability. Therefore, Testbed-17 shall build on and stress-test previous Testbed results for operational use. The following diagram shows logical setup for the envisioned Testbed-17 scenario.

In more detail, Testbed-17 will develop two clients, two fusion services, and two SWIM service façades. The fusion services use two or more other services to produce a higher level product. They shall not only orchestrate data, but add value to the data and the resulting product. A possible use case is two services, one for weather data and one for arrival/departure time data that are fused. Using the data from both services, the fusion process identifies airports that are sensitive to "bad weather". That is, the fusion service identifies airports that experience more delays than others on average in bad weather situations. The fusion service needs to load data from the two services, but needs to add intelligence to make sure it produces meaningful results. Alternative scenarios are possible and depend on both service/data availability and possible extensions as suggested by Testbed participants. Bidders are invited to suggest concrete use cases. The final decision on the use cases will be made at the kick-off meeting. It is required that the capabilities of the new Aviation API are demonstrated for both fused and raw data.

The Aviation API will be developed similar to the other OGC Web APIs. It shall adhere to the requirements set forth by the OGC Standards Program and shall make use of OpenAPI and SwaggerHub. An OpenAPI definition shall be delivered together with the API Engineering Report.

The following figure illustrates the work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions and support the development of the Engineering Report(s) with their contributions.

Engineering Reports

Components

This Work Item shall investigate and prototype techniques to protect resources in a globally distributed environment ranging from federated clouds down to the smallest IoT device. The work shall integrate previous efforts executed in the parallel tasks Federated Security and Data Centric Security into a single common security infrastructure. It shall further mature the federated infrastructure required to support security controls regardless of where a resource resides. It shall mature the data centric security technologies and integrate them into the federated security infrastructure.

DCS has been demonstrated in the past with vector data exclusively. Now, the challenge is to apply DCS concepts to any type of binary data. The goal is to analyse DCS in the context of OGC APIs that deliver binary resource representations with confidentiality and integrity built in. The client that has been used in previous Testbeds does not provide full support for all emerging OGC APIs. Testbed-17 shall develop such a client or the necessary extensions to existing clients respectively. These clients shall support at least OGC API - Maps/Tiles/Coverages and GeoPackage. Further on, it shall be explored how DCS can be achieved using different formats such as the Trusted Data Format (TDF) instead of STANAG.

Integrate the Federated Security and Data Centric Security efforts into a single framework and advance the maturity of that framework. Demonstrate Data Centric Security for various binary data objects that are served by (emerging) OGC APIs with a set of client-server implementations. Ideally, a wide variety of data objects is supported, such as:

The list of exercised OGC APIs should not be limited to the corresponding APIs such as OGC API – Maps, - Tiles, or -Coverages, but shall include additional APIs such as EDR (OGC API - Environmental Data Retrieval) or the emerging DAPA (OGC API - Data Access and Processing, see Previous Work).

Two scenarios have been used previously in both Testbed-15 and -16 to advance understanding of DCS. The Desktop/Client/Server scenario assumes connectivity between servers and clients at all times and does not put any specific constraints on the implementation setup. The Cellphone scenario on the other side foresees intermittent connectivity and support for strong encryption, as keys need to be taken on a mission of unknown duration.

Testbed-17 shall look at the application of DCS within Federated Cloud Environments and demonstrate that a DCS package created in one federation still enforces proper security controls when used in another federation. Participants are welcome to suggest alternative use cases to better represent the work within Testbed-17. On a high level, the Testbed-17 scenario(s) shall address the following aspects:

Federated Security

Data Centric Security

The following figure illustrates the work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions and support the development of the Engineering Report(s) with their contributions.

Engineering Reports

Components

The OGC explored the "Applications-to-the-Data" problem in the Data Access and Processing thread of Testbed-16. This work was part of a larger, well-coordinated body of work which includes prior OGC initiatives such as previous Testbeds and in particular the OGC Earth Observations Applications Pilot.

Another Work Item performed under Testbed-16 explored the concept of Analysis Ready Data. Analysis Ready Data is “data that have been processed to a minimum set of requirements and organized into a form that allows immediate analysis”. Software analytics need more than data if they are to do “immediate analysis”. They need to exchange information. This requires common formats (syntax) as well as a common understanding of what the data elements mean (semantics). Analysis Ready Data defines discipline-specific data standards which address both data syntax and semantics. Within limits, they provide the information exchange required when processing moves to the data.

This Work Item shall integrate Analysis Ready Data into the “processing to the data” workflows and evaluate:

Mature the federated cloud analytics model to include “processing to the data” design patterns and content normalization based on Analysis Ready Data (the term content normalization combines the various normalization techniques applied to data). Validate that this addition simplifies the business logic underlying the Testbed-16 DAPA API and makes the results more useful for the analytic.

The following documents describe previous work relevant to this Work Item. This list is not comprehensive. All of these efforts built on previous work which is identified in the respective documents. Participants shall consider that prior art as well.

The following figure illustrates the work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions and support the development of the Engineering Report(s) with their contributions.

Engineering Reports

Components

none

In recent years the OGC has seen the emergence of new encoding formats, data models, and service architectures. The result has been a proliferation of standards which should form a coherent body of work. The tools required to achieve and guarantee this coherence are lacking. This Work Item shall investigate application of Model Driven Architecture (MDA) tools and techniques to manage the development and maintenance of a portfolio of related standards.

This subtask shall evaluate and prototype MDA as both a framework and toolset for managing OGC standards.

Model Driven Architecture (MDA) was introduced by the Object Management Group (OMG) in 2001. MDA techniques have been used sporadically to develop OGC and ISO TC211 standards. The ShapeChange open source toolset (https://shapechange.net/) has been instrumental to those efforts. Participants in this Work Item shall build on this body of work. Efforts of particular relevance include:

Engineering Reports documenting OGC ShapeChange initiatives can be found at https://shapechange.net/about/background-documents/

MDA defines two types of models: Platform Independent Models (PIM) and Platform-Specific Models (PSMs). A PIM provides the definition of a data and/or computing capability which is independent of the implementing technology. A PSM defines how the PIM capability is realized using a specific implementing technology. The corresponding OGC and ISO terms are:

Participants in this Work Item shall explore MDA to manage both service and data standards. Of particular interest are the following formats and OGC Standards or elements:

Specific Sub-Work Items are:

Develop a draft Best Practices document for representing an OGC Platform Independent Model in UML. This document provides guidance to the developers of OGC Conceptual Model Standards so that those models can be used to generate valid Implementation Specifications using MDA tools.

The following figure illustrates the work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions and support the development of the conceptual models as well as the Engineering Report(s) with their contributions.

Engineering Reports

Components

The COG specification is not fully developed. Zarr has been developed as a generic container and needs to be evaluated for its capabilities to store geospatial data. Other container formats, such as CIS, NetCDF, or HDF5 can often be used interchangeably. A common metadata model is missing. In this context, the following research questions shall be addressed:

Develop a COG specification that complies with the requirements set by the OGC Standards Program. Develop a specification that can be directly considered by the GeoTIFF SWG to be put forward as an OGC Standard.

Compare COG with other solutions for multi-dimensional data in the cloud context with focus on Zarr. Support the Zarr integration into the OGC as a Community Standard as much as possible and provide feedback to the Zarr community for the next version of the specification.

The current versions of COG and Zarr are documented online. OGC did investigate Common Object Container solutions some time back. This work may be revitalized in this context with the goal to align more than just the metadata structures.

This task shall develop the COG specification from its current version into a draft OGC specification that complies with the OGC Standards Program requirements for standards. The work shall take the current discussion within the OGC GeoTIFF SWG as a starting point, which includes examination of COG, BigTIFF and STAC for common metadata.

The COG spec shall then be evaluated as a container specification in the context of other containers with focus on Zarr. The list of additional container formats that should be part of this task includes NetCDF, HDF5, and OGC CIS.

Both the COG and Zarr implementations shall be demonstrated within a typical scenario. The scenario shall highlight commonalties and differences with respect to metadata, discovery, and understanding of container contents.

The following figure illustrates the work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions and support the development of the Engineering Report(s) with their contributions. All participants will jointly develop the use cases and demonstration scenarios.

Engineering Reports

Components

It is hard to attract new developers to implement standards that are written in a specific language that meticulously defines all formal elements. Though being necessary to minimize room for interpretation and in consequence maximize interoperability between two components implementing the same standard, official standards are rarely a good read. Many developers favor a different approach, which starts with simple documentation and examples. From there, additional features are explored stepwise, with the actual standard often the last resource being consulted. This task shall accommodate for developers who prefer the starting-and-learning-by-example approach. This task shall serve as a starting point for further development and exploration. It shall deliver all knowledge necessary to develop, deploy, and execute standards-based Web APIs to Web developers. The task shall follow a "How-To" philosophy with lots of hands-on experiments, examples, and instructions, rather than lecturing about the standards.

This task shall lower the entry hurdle to OGC Web APIs by providing a set tools and guidelines on how to develop, deploy, and operate an OGC Web API-based service instance in a modern cloud environment. Three items are in focus:

This task shall take the latest versions of OGC API-Features as well as the Environmental Data Retrieval (EDR) API into account. The EDR API is specified in the OGC API – Environmental Data Retrieval candidate standard.

OGC Web API instances are usually implemented as microservices with an standards-based front-end API and a custom-made back-end. The microservice core acts as a controller and implements a set of functions that translate between Web API calls and data backend. These translations can have any level of complexity. The figure below illustrates the envisioned Testbed-17 scenario. A client with a dedicated Web API interaction software library (1) interacts with a data service that exposes an OGC Web API (2) at the front-end and includes a cloud native data storage software library (3) at the backend that interacts with cloud native storage, e.g., cloud databases, cloud object storage, or existing OGC Web service instances such as WFS.

Challenges often arise when a server instance shall be deployed in a cloud environment, where the developer is confronted with a number of additional features and design decisions. Therefore, all elements developed in this task can be deployed on infrastructure provided by various cloud providers. The necessary setup and installation scripts are explicit work items that will allow anyone to experiment with OGC API instances in the cloud. The figure below illustrates the envisioned deployment scenario. Each data service will be deployed twice in different cloud environments (A, B). The client application can be deployed anywhere.

This task shall develop implementations of the OGC APIs -Features and -EDR (Environmental Data Retrieval) with backend access to data stored in cloud databases, cloud object storage, and existing OGC Web Feature Service (WFS) instances. Participants are welcome to reuse existing WFS instances, independently of their location.

The full implementation scenario is illustrated further below. It is emphasized that this task has the goal to deliver guiding material and best practices for server- and client-side API development and deployment. As such, all implementations shall support typical user scenarios and shall be documented in detail. The functionality and richness of the implementation as well as data products will be mutually agreed between participants, sponsors, and the IP-Team in the first phase of the testbed. No development needs to support every possible feature, but a reasonable subset as mutually agreed upon at the kick-off meeting. To test all components and guidance material, the work in this task shall be shared by participants acting as ‘client developers’, ‘server developers’, or ‘deployment testers and data providers’:

In summary, organizations O1 and O2 develop a client demo and client API implementation, organizations O3 and O4 develop a server demo and API implementation together with usage and deployment information and scripts, and organizations O5 and O6 test the deployment in various cloud environments with their own data (which is made available to others for testing as well). As such, organizations O5 and O6 act as external players that want to start exploring OGC Web APIs in action for their own data.

The focus of the task is on repeatable steps and tangible results. All organizations are required to document the usage of their components as detailed as necessary to allow external parties to start their own experiments with the provided implementations and deployments. Thus, focus is not on full support for each API and data backend detail, but on practical examples that showcase typical use cases of data discovery and access.

The data service will be deployed on various cloud environments using a set of scripts and user guides to make this process a smooth experience. For deployment, various options shall be supported. These include deployment and operation on a cloud-based virtual machine or deployment as a container-based solution (e.g. Docker, Kubernetes, or OpenShift).

All bidders shall define their preferred cloud environment as well as supported functionalities and deployment strategies in their proposals. Bidders may bid for multiple roles as described above (i.e., client developer, service developer, or deployment tester and data provider). Bidders doing so are required to allow selection of individual roles. The IP Team is working with various cloud providers to obtain free cloud resources.

DevOps and CI/CD

As the three roles described above have dependencies between each other, all participants in this task are required to follow a DevOps approach. DevOps as used here is about establishing a culture of continuous learning and experimentation so that all participants can start their work early and continuously refine and extend both functionality and quality during the Testbed-17 implementation phase. One of the most common blockers of the value stream from engineering to end-users is inter-team dependencies. If a team is unable to independently release their software, whether to internal or external customers, they will lose motivation and the ability to react to user feedback. Thus, sufficient team autonomy is one of the cornerstones of this task. This does not mean that teams will not be aligned. Rather, it requires a very clear definition of intermediate and final goals and responsibilities early in the process, so that all teams are able to pull in the same direction. To support this work, a Continuous Integration (CI) and Continuous Delivery/Deployment (CD) model will be developed at the kickoff meeting and refined as necessary. As a key principle of continuous delivery, all software and scripts shall be kept in a deployable state continuously.

Milestones

The following timeline broadly defines key milestones for this task. The milestones serve as orientation points to allow bidders to estimate required resources at the time of proposal development.

The following figure illustrates the work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions and support the development of the Engineering Report(s) with their contributions. For all work items and as emphasized above, the term “document” shall be interpreted more in the sense of “how-to”, i.e. more instructive, less documentary; components shall be implemented and documented accordingly.

Engineering Reports

Components

Important: As the goal of this task is to provide a robust and easy to understand starting point for Web developers to explore standards-based APIs, all software and installation scripts shall be delivered under a permissive software license (e.g. GNU All-permissive License or MIT License). The various work items may depend on commercial software as long as the essential functionality is properly documented and available as part of the open source software libraries.

With JSON often being favored over XML these days, the demand for GeoJSON with support for coordinate reference systems (CRS) is growing. Given that GeoJSON in its current form does not provide sufficient CRS support, Testbed-17 shall investigate the development of a CRS extension or within a profile of GeoJSON that could take the form of an OGC-version of GeoJSON.

Further on, the definition of lightweight profiles of GeoJSON shall be possible to allow communities to constrain allowed geometry types as well as feature attributes and values in a machine-readable form. This part shall focus on the aviation domain, where participants shall investigate challenges associated with the implementation of GeoJSON in emerging aviation, defense, and other applicable use-cases (including, but not limited to Unmanned Aerial Systems (UAS) / UAS Traffic Management (UTM)). Common needs across multiple use-cases shall be highlighted before developing a set of draft recommendations for core enhancements or within a profile of GeoJSON to address those common needs. In addition, it shall be explored what is possible in terms of extensibility and work with other domain-specific standards organizations to develop and test a set of extensions off the core in order to accommodate additional unique implementation requirements and reduce adoption risk / interoperability issues.

Investigate and define a solution that enables GeoJSON to support different Coordinate Reference Systems (CRS) as an extension or within a profile of GeoJSON. Further on, allow for communities to build and formally define profiles of the fully CRS-enabled GeoJSON with limited sets of supported geometry types and with clear constraints for feature type definitions.

The scenario requires the ability to use data from many different sources. Data may include material from different Earth Observation sources as well as aviation data (e.g., from UAVs), which may be using different CRSs, provided as GeoJSON metadata. The scenario requires CRS-enabled data to be loaded in offline data containers, as internet connectivity is only available intermittently. The scenario shall evaluate aviation specific requirements such as geometry constraints and profiles. The scenario may be broken into a number of sub-scenarios, but in total shall support the following requirements:

This work is seeking to deliver and define a specification to GeoJSON that allows different CRSs to be defined and profiles to be generated that reduce the possible serialization options (e.g., by limiting the number of allowed geometry types). This work should include client and server implementations across the OGC API family of (emerging) standards.

The following figure illustrates the work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions and support the development of the Engineering Report(s) with their contributions.

Engineering Reports

Components

Testbed-17 shall explore development of an API that is able to support access to and evaluation of GDCs in a uniform, standardized way from multiple environments (e.g., other GDCs, platforms, various file systems, etc.). The support of discovery, access, sharing, and use of GDC data should enable workflows involving distributed computing resources and algorithms. This effort will specifically explore the use of OGC APIs as building blocks to support GDC interoperability and evaluation. It is expected that outcomes of the project will support multiple uses within regional to international spatial data infrastructures. Therefore, additional objectives from this project include:

The following overarching research questions shall further help guide the work for the GDC task and shall be discussed during the Testbed-17 implementation phase:

The activities executed in Testbed-17 will be part of the larger OGC innovation and standardization activities umbrella. As such, they will inform future OGC activities. All work on OGC Web APIs shall be executed in close cooperation between the Innovation Program and the Standards Program to ensure consistent and coordinated development of all Web APIs and Web API building blocks. It is expected that results from this task will form the basis for future initiatives to fully enable interoperable GDCs through an OGC Implementation Standard. All developments shall be based on exiting OGC Web API building blocks as much as possible.

Develop an OGC API - Geospatial Data Cubes draft specification with the goal to standardize use, discovery, and access to GDCs. This task shall demonstrate and evaluate the capabilities of GDCs in various use-cases. The API shall be accessed by consumer clients as well as machine learning models to evaluate GDC usability in the context of machine learning.

The task shall operate in the context of terrestrial and marine elevation, and forestry data scenarios. At a high level, the current scenario envisions a client application to request result sets of Digital Elevation Model (DEM) operations such as elevation profile, viewshed analysis, and computing of elevation statistics (min/max/mean values for elevation, slope, aspect) inside a user-defined polygon. In addition, a forestry scenario shall be developed that illustrates usage of GDCs in the forestry domain, specifically to enable access, processing, fusion, and extraction of diverse forestry datasets. Detailed scenarios will be developed during the first stage of the Testbed-17 implementation phase. Participants are invited to suggest appropriate use-cases. Ideally, these include Canadian territory and waters.

To support project completion, the following data sets will be provided (participants are invited to add additional data sets):

All implementations of the proposed API shall be designed to meet needs and requirements for GDC elevation information interoperability between the land and marine domains. The key outcome from this task shall be the creation of a draft GDC API specification for using existing OGC APIs (as-is or through extensions), or for developing a new OGC API to enable GDC interoperability and evaluation. The draft specification shall be sufficiently complete such as to enable timely integration with the OGC’s Standards Program for further development of the API to an OGC standard.

This task shall also highlight how a GDC API can support use and interoperability of multiple standardized geospatial data formats such as STAC, COG, W*S, and OGC APIs and systems such as existing registries and catalogues.

Cloud-Based Access, Analytics, and Processing, and Relationships to Other File Systems

Development of the GDC API shall also consider how to support access to GDCs through cloud-based infrastructure. This task shall also explore cross-cloud interoperability of GDCs through the API in order to ensure GDC information can be shared between clouds, and that GDC access can be maintained if changes to a GDC cloud-service are required (e.g. changing to a new cloud provider).

This cloud-oriented task shall also investigate implementing analysis and processing capabilities for GDC data through the API framework. Potential linkages with recent, similar efforts completed as part of the OGC’s Earth Observation Applications Pilot and OGC Testbed-16’s Data Access and Processing API for Geospatial Data shall be explored and leveraged to the greatest extent possible to maximize API use and interoperability.

While cloud-based interoperability is a key consideration for this effort, the work shall also consider how the GDC API can support interoperability with other forms of infrastructure (e.g. data lakes, workstation-based file systems, high performance computing systems, etc.). Demonstrating an ability to link with non-GDC systems represents an important aspect of ensuring GDCs can make use of and support different forms of infrastructure.

Overall, the following major work items have been identified:

With respect to machine learning (ML), this task shall explore and demonstrate how ML can interact with a data cube through the API and how this may differ from how a human would interact with the API. This could lead to design considerations (e.g., how can the API be optimized to best enable ML and human interactions with a data cube?). The use case may be simple and ideally relates to the elevation or forestry use cases. As an example, it could be explored how ML could access forestry datasets to complete analysis related to harvest planning.

The following figure illustrates the work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions and support the development of the Engineering Report(s) with their contributions.

Engineering Reports

Components

Traditionally, OGC CITE uses TEAM Engine (Test, Evaluation, And Measurement Engine), a Java-based application for testing web services and other information resources. It executes test suites developed using the TestNG framework, OGC Compliance Test Language (CTL) scripts, and possibly other JVM-friendly languages. TEAM Engine can be used to test almost any type of service or information resource. It is the official test harness used by the Open Geospatial Consortium’s (OGC) compliance program.

With the changing landscape moving away from the Service Oriented Architecture with its remote procedure calls over HTTP towards a modern, resource-based Web architecture, the question is if TEAM Engine is still the best tool for the OGC Compliance Program. To test this aspect and to deliver an additional test suite, Testbed-17 will develop tests for OGC API-Processes. The tests will be implemented for TEAM Engine and for an additional, yet to be identified testing environment.

The task shall address the following research questions:

Develop a test suite for OGC API-Processes for TEAM Engine. Explore alternative test environments and provide recommendations for the way forward. Develop a test suite for OGC API-Processes with the recommended test environment and evaluate to which extent tests may be auto-generated from the standards directly.

Develop a test suite for OGC API-Processes for TEAM Engine and an alternative test environment. Compare both broadly and provide recommendations for the future.

The following figure illustrates the work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Detailed requirements are stated above. All participants are required to participate in all technical discussions and support the development of the Engineering Report(s) with their contributions.

Engineering Reports

Components

Engineering Reports (ER) and Change Requests (CR) will be prepared in accordance with OGC published templates. Engineering Reports will be delivered by posting on the (members-only) OGC Pending directory when complete and the document has achieved a satisfactory level of consensus among interested participants, contributors and editors. Engineering Reports are the formal mechanism used to deliver results of the Innovation Program to Sponsors and to the OGC Standards Program for consideration by way of Standards Working Groups and Domain Working Groups.

Document content should follow this OGC Document Editorial Guidance (scroll down to view PDF file content). File names for documents posted to Pending should follow this pattern (replacing the document name and deliverable ID): OGC Testbed-17: Aviation Engineering Report (D001). For ERs, the words Engineering Report should be spelled out in full.

Component Implementations include services, clients, datasets, and tools. A service component is typically delivered by deploying an endpoint via an accessible URL. A client component typically exercises a service interface to demonstrate interoperability. Implementations should be developed and deployed in all threads for integration testing in support of the technical architecture.

Component implementations are often used as part of outreach demonstrations near the end of the timeline. To support these demos, component implementations are required to include Demo Assets. For clients, the most common approach to meet this requirement is to create a video recording of a user interaction with the client. These video recordings may optionally be included in a new YouTube Playlist such as this one for Testbed-15.

Since server components often do not have end-user interfaces, participants may instead support outreach by delivering static UML diagrams, wiring diagrams, screenshots, etc. In many cases, the images created for an ER will be sufficient as long as they are suitable for showing in outreach activities such as Member Meetings and public presentations. A server implementer may still choose to create a video recording to feature their organization more prominently in the new YouTube playlist. Another reason to record a video might be to show interactions with a "developer user" (since these interactions might not appear in a client recording for an "end user").

Note that all Participants are required to provide at least some level of in-kind contribution (costs for which no cost-share compensation has been requested). As a rough guideline, a proposal should include at least one dollar of in-kind contribution for every dollar of cost-share compensation requested. All else being equal, higher levels of in-kind contributions will be considered more favorably during evaluation. Participation may also take place by purely in-kind contributions (no cost-share request at all).

Once the proposals have been evaluated and cost-share funding decisions have been made, the IP Team will begin notifying Bidders of their selection to enter negotiations to become and initiative Participant. Each selected bidder will enter into a Participation Agreement (PA), which will include a Statement of Work (SOW) describing the assigned deliverables.

The IP Team will provide monthly progress reports to Sponsors. Ad hoc notifications may also occasionally be provided for urgent matters. To support this reporting, each testbed participant must submit (1) a Monthly Technical Report and (2) a Monthly Business Report by the first working day on or after the 3rd of each month. Templates and instructions for both of these report types will be provided.

The purpose of the Monthly Business Report is to provide initiative management with a quick indicator of project health from each participant’s perspective. The IP Team will review action item status on a weekly basis with assigned participants. Initiative participants must remain available for the duration of the timeline so these contacts can be made.

Each Participant should submit a Final Summary Report by the milestone indicated in the Master Schedule. These reports should include the following information:

This report may be in the form of email text or a more formal attachment (at the Participant’s discretion).

Clicking on the Propose link will navigate to the Bid Submission Form. The first time through, the user should provide organizational information on the Organizational Background Page and click Update and Continue.

This will navigate to an "Add Deliverable" page that will resemble the following:

The user should complete this form for each proposed deliverable.

On the far right, the Review link navigates to a page summarizing all the deliverables the Bidder is proposing. This Review tab won’t appear until the user has actually submitted at least one deliverable under the Propose tab first.

Once the Submit button is clicked, the user will receive an immediate confirmation on the website that their proposal has been received. The system will also send an email to the bidder and to OGC staff.

The user is afforded an opportunity under Done Adding Deliverables at the bottom of this page to attach an optional Attached Document of Explanation.

If this attachment is provided, it is limited to one per proposal and must be less than 5Mb.

This document could conceivably contain any specialized information that wasn’t suitable for entry into a Proposed Contribution field under an individual deliverable. It should be noted, however, that this additional documentation will only be read on a best-effort basis. There is no guarantee it will be used during evaluation to make selection decisions; rather, it could optionally be examined if the evaluation team feels that it might help in understanding any specialized (and particularly promising) contributions.

The Propose link takes the user to the first page of the proposal entry form. This form contains fields to be completed once per proposal such as names and contact information.

It also contains an optional Organizational Background field where Bidders (particularly those with no experience participating in an OGC initiative) may provide a description of their organization. It also contains a click-through check box where each Bidder will be required (before entering any data for individual deliverables) to acknowledge its understanding and acceptance of the requirements described in this appendix.

Clicking the Update and Continue button then navigates to the form for submitting deliverable-by-deliverable bids. On this page, existing deliverable bids can be modified or deleted by clicking the appropriate icon next to the deliverable name. Any attempt to delete a proposed deliverable will require scrolling down to click a Confirm Deletion button.

To add a new deliverable, the user would scroll down to the Add Deliverable section and click the Deliverable drop-down list to select the particular item.

The user would then enter the required information for each of the following fields (for this deliverable only). Required fields are indicated by an asterisk ("*"):

Cost-sharing funds may only be used for the purpose of offsetting burdened labor costs of development, engineering, documentation, and demonstration related to the Participant’s assigned deliverables. By contrast, the costs used to formulate the Bidder’s in-kind contribution may be much broader, including supporting labor, travel, software licenses, data, IT infrastructure, and so on.

Theoretically there is no limit on the size of the Proposed Contribution for each deliverable (beyond the raw capacity of the underlying hardware and software). But bidders are encouraged to incorporate content by reference where possible (rather than inline copying and pasting) to avoid overloading the amount of material to be read in each proposal. There is also a textbox on a separate page of the submission form for inclusion of Organizational Background information, so there is no need to repeat this information for each deliverable.

This field Proposed Contribution (Please include any proposed datasets) should also be used to provide a succinct description of what the Bidder intends to deliver for this work item to meet the requirements expressed in the Technical Architecture. This language could potentially include a brief elaboration on how the proposed deliverable will contribute to advancing the OGC standards baseline, or how implementations enabled by the specification embodied in this deliverable could add specific value to end-user experiences.

A Bidder proposing to deliver a Service Component Implementation can also use this field to identify what suitable datasets would be contributed (or what data should be acquired from another identified source) to support the proposed service.

A single bid may propose deliverables arising from any number of threads or tasks. To ensure that the full set of sponsored deliverables are made, OGC might negotiate with individual Bidders to drop and/or add selected deliverables from their proposals.