OGC Testbed-18: Call for Participation (CFP)

Currently, most OGC standards focus on data that is observed on ground or directly above planet Earth. Other standards, such as GeoSciML, look into the planet and provide a data model and transfer standards for geological data. In addition, recent citizen-science-driven projects have looked into the seas and oceans.

The extra-terrestrial space and the exact location of the remote sensors has been less in focus. This Testbed task shall start with a status quo evaluation of current standards and then stepwise expand or create new standards in order to

Earth-centered inertial (ECI) coordinate frames have their origins at the center of mass of Earth and are fixed with respect to the stars."I" in "ECI" stands for inertial (i.e., "not accelerating"), in contrast to the "Earth-centered - Earth-fixed" (ECEF) frames, which remain fixed with respect to Earth’s surface in its rotation, and then rotate with respect to stars.

For objects in space, the equations of motion that describe orbital motion are simpler in a non-rotating frame such as ECI. The ECI frame is also useful for specifying the direction toward celestial objects. To represent the positions and velocities of terrestrial objects, it is convenient to use ECEF coordinates or latitude, longitude, and altitude. Expressed in a nutshell:

The extent to which an ECI frame is inertial is limited by the non-uniformity of the surrounding gravitational field. For example, the Moon’s gravitational influence on a high-Earth orbiting satellite is significantly different than its influence on Earth, so observers in an ECI frame would have to account for this acceleration difference in their laws of motion. The closer the observed object is to the ECI-origin, the less significant the effect of the gravitational disparity is.

In this context, the following research topics should be explored:

The OGC Temporal DWG has begun development of a discussion paper on Dynamic Features. Dynamic Features are 3-D Moving Features that can change location, shape, and state as a function of time. This discussion paper will also explore temporal and spatial reference systems applicable to Features moving at relativistic velocities. Special relativity of Features is to be based on Minkowski spacetime. Participants in this work item are expected to support the OGC Temporal DWG in development of this Discussion Paper and to incorporate its findings in the Testbed-18 work program.

This task aims to identify an architecture framework and corresponding standards that will allow for the description of a comprehensive set of orbital and non-orbital space-based assets, objects and observations as well as terrestrial observations.

This work shall lay the foundation for modeling, representation, and serialization from space-based assets operating at any location in our solar system. This type of data is referred to here as 3D+ data. The task shall further evaluate the ability to stream 3D+ data to visualization devices (screen, Augmented Reality, Virtual Reality) for presentation. This presentation may require the ability to query for additional metadata supporting feature identification and/or targeting.

The OGC Abstract Specification Topic 2: Referencing by coordinates defines the conceptual schema for the description of referencing by coordinates. In addition, it describes the minimum data required to define coordinate reference systems.

3D data streaming community standards I3S and 3D Tiles are available on the OGC website.

The OGC Testbed-13: 3D Tiles and I3S Interoperability and Performance Engineering Report coming out of OGC Testbed-13 evaluated the 3D data streaming capabilities of different community standards. This work represents important preliminary work for the 3D Data Container and Tiles API Pilot, with results described in the 3D Data Container and Tiles API Pilot Summary Engineering Report.

Portrayal in general and the development of a portrayal framework were subject to several OGC Testbeds. The OGC Testbed-15: Open Portrayal Framework Engineering Report and the OGC Testbed-15: Portrayal Portrayal Summary Engineering Report describe the Open Portrayal Framework, a set of emerging specifications that support interoperable portrayal of heterogeneous geospatial data. The Open Portrayal Framework facilitates the rendering of geospatial data in a uniform way, according to specific user requirements. The primary topics addressed in Testbed-15 covered supporting style sharing and updates, client- and server-side rendering of both vector- and raster data, and converting styles from one encoding to another; all following a single conceptual style model.

Portrayal was further explored in the OGC Portrayal Concept Development Study, with results summarized in the OGC Portrayal Concept Development Study Engineering Report. The study assessed the current state of feature portrayal. This was done through a high-level overview (Strengths, Weaknesses, Opportunities and Threats (SWOT) Analysis), a review of existing portrayal workflows and relevant technologies, standards, and research papers, and by conducting two case studies.

Testbed-13 consolidates the work done in previous OGC Testbeds with a focus on portrayal semantics. The OGC Testbed-13: Portrayal Engineering Report captures all requirements, solutions, models and implementations of the Testbed-13 Portrayal Package. This effort leveraged the work on Portrayal Ontology development and Semantic Portrayal Service conducted during Testbed-10, -11 and -12. Testbed-13 work identified and completed the gaps in the latest version of the portrayal ontology defined in Testbed-12, implemented the Semantic Portrayal Service by adding rendering capabilities, and demonstrated the portrayal service that showcased the benefits of the proposed semantic-based approach.

The following figure illustrates the high-level software architecture with all 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.

D023 3D+ Standards Framework Engineering Report – An Engineering Report which captures the work done to identify existing capabilities and propose future work required to develop a suite of 3D+ standards.

D024 3D+ Data Space Object Engineering Report – An Engineering Report which captures the specific work done to improve describing objects in orbit of a celestial object or in free flight in our solar system.

D025 Reference Frame Transformation Engineering Report – An Engineering Report which describes the standards-based mechanisms to transform location within a reference frame to a location in another reference frame.

D026 3D+ Data Streaming Engineering Report – An Engineering Report which describes how the testbed effort improves multi dimensional data streaming to multiple device types.

Training datasets are crucial for ML and AI applications, but they are becoming a significant bottleneck in EO’s more widespread and systematic application of AI/ML. The issues include:

This task shall tackle primarily the following research questions:

The objective of this task is to document current approaches and possible alternatives to lay out a path for future standardization of training datasets for Earth Observation applications.

The OGC Testbed-16: Machine Learning Training Data Engineering Report documented the OGC Testbed-16 work that focused on understanding the potential of existing and emerging OGC standards for supporting ML applications in the context of wildland fire safety and response. In this context, integrating ML models into standards-based data infrastructures, the handling of ML training data, and the integrated visualization of ML data with other source data was explored. Emphasis was on the integration of data from the Canadian Geospatial Data Infrastructure (CGDI), the handling of externally provided training data, and the provisioning of results to end-users without specialized software.

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.

D027 Machine Learning Training Data Engineering Report - This Engineering Report captures all results of the ML TDS task and can serve as a baseline for future standardization.

This task shall explore catalogs, asynchronous communication, and data centric security in a single scenario. Depending on the level of CRUD support at the time Testbed-18 kicks off, the goal is at least that subscribers can register their queries at a catalog and be informed about changes to the catalog. Ideally, publishers can send new or updated data to an OGC API-Records instance with encrypted content that fulfills DCS principles.

Catalog APIs and resources models are currently emerging in the context of RESTful web APIs. OGC API-Records and STAC are both under development and will be available soon for data discovery and catalog management. Both are not fully aligned yet, though STAC is making good progress towards full OGC API-Records support. OGC API-Records has defined three building blocks, but no support for classical metadata models such as ISO 19115. This task shall develop the necessary extensions for ISO 19115 support.

This scenario will address the following research questions:

It is emphasized that these research questions shall be addressed in close collaboration with the OGC API-Records Standard Working Group (SWG). Participants of this task are expected to be aware of ongoing discussions within the OGC API-Records SWG. Testbed-18 and the SWG will enter into agreements on how to best organize the workload on OGC-API Records at the Testbed-18 kickoff meeting.

The task aims at developing ISO 19115 support for OGC API-Records. It shall explore DCS in the context of OGC API-Records and develop a candidate standard for a Key Management Service API. The work shall further explore asynchronous communication with OGC API-Records instances.

The OGC API-Records core specification is still in development at the time of the Testbed-18 Call for Participation release. The current timeline anticipates the release of the initial, tagged 1.0-draft version towards the end of Q1/2022. Followed by a series of feedback rounds, sprints, and implementation work, the final 1.0 version shall be available in Q4/2022 with a subsequent submission to ISO in 2023. The core specification as well as extensions are available in their most recent version in this Github repository. The OGC Innovation Program conducted some research on catalogs in previous years, though most of the work originates before the major shift towards web APIs and RESTful architectures was conducted. Therefore, this task needs to build on the latest discussions taking place in the OGC API-Records and related working groups.

The following figure illustrates the high-level architecture with all 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.

D112 OGC CSW - OGC CSW service instance with support for ISO 19115 (CSW-ebRIM profile is of particular interest)

D113 OGC API-Records - OGC API-Records (draft) service instance

D114 Catalog Client - The Catalog supports two interaction patterns. First, the client explores data from both catalog instance types (CSW and OGC API-Records) to compare functionality and ease-of-use. Second, the client serves as a subscriber to Catalog data updates. The client needs to fulfill the following requirements:

D115 Authorization and Identity Management System and Key Management Server - A software environment consisting of an authorization and identity management system with support for OpenID Connect. The Key Management Service shall support the Key Management Service API developed as D008. D115 is the only unfunded work item. OGC expects in-kind contributions to be made available based on services available during previous testbeds.

D007 Secure Asynchronous Catalog Engineering Report - This Engineering Report captures all results, experiences, and lessons learned from this task.

D008 Key Management Service API Engineering Report - This Engineering Report describes an OGC candidate standard for a Key Management Service API.

This Testbed task addresses two main challenges: First, the harmonization of sensor integration approaches across the existing and emerging OGC and external standards. Second, the maturation of the Moving Features architecture and its integration with the harmonized OGC sensor architecture. Both challenges build on previous work done in Testbed-17.

Sensor systems are built using many different standards, formats, and protocols. This is a significant barrier to sensor integration. Yet there are good reasons why this should be so. Sensors must be deployed where they will best measure a physical phenomenon. That imposes non-negotiable constraints on their size, weight, power consumption, and communications capabilities. These constraints limit the options available to the designer. They must select the best option that will work within their technical constraints. Thus, successful sensor integration must embrace sensor diversity. What is required is not a one-size-fits-all solution, but a framework of standards that enables the integration of a wide range of sensors. The OGC has addressed the sensor integration challenge as part of its Sensor Web Enablement (SWE) initiative. SWE includes both data models and APIs. The suite of SWE standards have been developed over 20 years and therefore reflects various state-of-the-art approaches, including different data serialization models, interface types, and communication patterns. The first objective of this task is to consolidate and harmonize SWE standards with modern OGC APIs as well as externally developed standards as necessary, while embracing diversity among sensors and sensing systems.

Testbed-17 continued the work started in Testbed-16 on moving features. There are several systems available to detect and report moving features. Most work as stove-piped systems that cannot work collaboratively to improve detection rates or moving object characteristics determination. Therefore, the second objective of this task is to mature the moving feature architecture developed in Testbed-17 and explore multi-source/multi-system moving object detection and attribution. The second objective shall build on the architecture framework and corresponding standards to integrate several sensors’ observations into a common analytic environment. To achieve these objectives, the following research topics shall be explored:

Note: Moving Features include movement in location as well as changes in shape and property values. The overall architecture is illustrated in the following figure.

Sensor standards must embrace sensor diversity. The aim is not to develop a one-fits-all solution, but a harmonized framework of standards, which enables sensor integration regardless of technical constraints. The goal of this task is to develop a framework for interoperable sensor (data) integration and to demonstrate its capabilities in the context of moving features from multiple sources into a common analytic environment.

The OGC Testbed-17 had two work items: Sensor Integration and Moving Feature. The Sensor Integration task focused on demonstrating the feasibility of implementing concepts described in the Sensor Integration Framework (SIF) standard developed by the National System for Geospatial Intelligence (NSG) and United States MASINT System (USMS). The SIF provides a standard framework for the integrating of sensor systems regardless of their technical constraints and deployment environment. Thus SIF targets systems that could be deployed on enterprise networks as well as in Denied, Degraded, Intermittent, or Limited Bandwidth (DDIL) environments. A thorough assessment of the SIF standard documents and data models is provided in the OGC Testbed-17: Sensor Integration Framework Assessment Engineering Report. In Testbed-17 it became clear that OGC should continue to promote the SIF vision of integrated sensor systems as it is entirely in line with the vision behind the OGC SWE standards. Therefore, it is recommended to further refine/develop the SIF at OGC by defining Best Practices based on existing OGC SWE standards, not by developing new data models. Testbed-18 shall build on these experiences and further enhance sensor integration frameworks by emphasizing semantic interoperability. These tasks will include an assessment and possible integration of the OGC Definition Server. To further complete the SWE-based SIF, Testbed-18 shall develop a fully harmonized conceptual model that encompasses not only sensor observations but also command and control aspects. In this context, work needs to be coordinated with the ongoing UxS Command and Control Interoperability Experiment.

The OGC Testbed-17 Moving Features task addressed the exchange of moving object detections between software components, shared processing of detections for correlation and analysis, and visualization of moving objects within common operational pictures. The OGC Moving Features Engineering Report documents the developed architecture for collaborative distributed object detection and analysis of multi-source motion imagery. Testbed-17 produced a powerful Application Programming Interface (API) for discovery, access, and exchange of moving features and their corresponding tracks and exercised this API in a near real-time scenario. The API has been handed over to the Moving Features Standard Working Group for further development.

An additional goal of Testbed-17 was to investigate how moving object information can be made accessible through HTML in a web browser using Web Video Map Tracks (WebVMT) as part of the ongoing Web Platform Incubator Community Group (WICG) DataCue activity at W3C. This aims to facilitate access to geotagged media online and leverage web technologies with seamless integration of timed metadata, including spatial data.

The complete Testbed-17 work on moving features is documented in the two Engineering Reports: OGC Testbed-17: OGC API - Moving Features Engineering Report and OGC Testbed-17: Moving Features Engineering Report. In addition, Testbed-16 results are available here.

The following figure illustrates the high-level architecture with all 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.

D140 Moving Feature Collection - In this deliverable, a collection of Moving Features will be deployed for two experiments: First, to link moving features to a shared (with D141) collection of features (that are not moving). The output of this task is developing a Best Practice for extending existing Feature dataset with Moving Features data. Second, to serve as an ingestion system that ingests moving feature detections into the Sensor Hub (D142). Ideally, different ingestion protocols can be explored. The participant contributes in particular to the Best Practice Engineering Report (see D020).

D141 Moving Feature Collection - similar to D140.

D142 Sensor Hub - A software system that can enable any sensor, actuator, process, forecast model, robot, or system to be discovered, accessed, and controlled through OGC/SWE standard services and APIs. The Sensor Hub receives moving feature detections from the ingestion systems (i.e., D140/141), integrates these into a persistent data store, and provides an OGC API-Moving Features to the client. The participant serves as the lead author for the sensor integration architecture.

D143 Client - A client application that uses AI technology to improve and enhance moving feature data taking advantage of multi-sensor input. The client connects to the Sensor Hub, retrieves data from both moving feature ingestion systems, and enhances track data and moving feature data by multi-sensor fusion. If possible, the client shall connect to additional synthesized data sources.

D020 Moving Features ER - The Engineering Report captures the proposed architecture, identifies the necessary standards, describes all developed components, and reports on the results of all Technology Integration Experiments (TIEs) conducted between participants. This Engineering Report consists of three parts: First, the Moving Features summary, addressing the initially outlined research questions 1-3. Second, a Dataset Extension part that proposes Best Practices for extending an existing Feature dataset to support Moving Features. Third, the Quality Metrics part that presents a set of quality metrics for Moving Feature data. For formal reasons, all three parts need to be delivered as individual Engineering Reports, but redundancies shall be avoided where possible.

Earth observation (EO) workflows typically use a combination of pre-processed data, fusion, and analytical functions. To achieve reproducible results, each step in a scientific workflow needs to be described in sufficient detail. Once defined, these descriptions need to be made available to other scientists. Describing the various stages is not a simple task. Data is available in multiple formats and served at different interfaces, including static files and APIs. Data might change due to changes in the sampling regime, due to corrections, modified distribution policies, or many other reasons. APIs may provide access to changing data sets without necessarily notifying the user.

This task shall develop best practices to describe all steps of a scientific workflow, including

Several mechanisms exist to provide identifiers for resource types like data, applications, and workflows. Digital Object Identifiers (DOI) are a widespread mechanism to identify resources on the Internet. These identifiers are often based on a syntax definition that allows the compact representation of what is a complex query. ISO 26324:2012, Information and documentation — Digital object identifier system, defines such a syntax for digital objects identifier names, which is used for the identification of an object of any material form (digital or physical) or an abstraction (such as a textual work) where there is a functional need to distinguish it from other objects.

The International DOI Foundation (IDF) is the governance and management body for the federation of Registration Agencies providing Digital Object Identifier (DOI) services and registration, and is the registration authority for the ISO standard (ISO 26324) for the DOI system. The DOI system provides a technical and social infrastructure for the registration and use of persistent interoperable identifiers, called DOIs, for use on digital networks. The list of registration agencies - the members of IDF offering the system to customers who wish to assign DOI names - includes CrossRef and DataCite. Both are used intensively to make research objects easy to find, cite, link, assess, and reuse. Combined, the topics described above can be summarized in the following research questions. All research questions shall be answered in the context of Earth observation research.

The task shall develop best practices to identify the essential ingredients of scientific Earth observation workflows and demonstrate these best practices with a selected set of Earth observation workflows. The task shall further show the role of standards and describe which set of standards form a solid, scalable foundation for reproducible Earth observation science.

https://wholetale.org/index.html is an NSF-funded Data Infrastructure Building Block (DIBBS) initiative to build a scalable, open source, web-based, multi-user platform for reproducible research enabling the creation, publication, and execution of tales - executable research objects that capture data, code, and the complete software environment used to produce research findings. This task shall explore Whole Tale results and ideally work collaboratively with the Whole Tale team in this task.

The Earth Observation Applications Pilot looked closely at the topic of input, results, and parameterization descriptions. The Pilot built on previous OGC Innovation Program initiatives, with the OGC Testbed-15: Catalogue and Discovery Engineering Report of particular interest here. The report documents how to expose applications and related services through a Catalogue service.

The following figure illustrates the high-level architecture with all 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 Engineering Report(s) development with their contributions.

D165-169 Reproducible FAIR Workflows - Each workflow shall describe all essential resources with the necessary details to ensure reproducibility. Participants are invited to identify and use existing data and applications or set up their data services or applications. In the latter case, it shall be ensured that all components are available for at least six months after the end of Testbed-18 and all pertinent data service/application details (configurations, settings, libraries, versions, etc.) are documented within or alongside the produced notebooks/workflows. In addition, participants are invited to make use of exploitation platforms, Jupyter Notebooks, or other scientific workflow environments. In any case, reproducibility shall be demonstrated.

D040 Reproducible FAIR Best Practices Engineering Report - Best Practices Engineering Report enhances FAIR to reproducible FAIR. These Best Practices shall respond to the challenges and research questions documented above and provide clear guidance for future use and enhancements.

D041 Reproducible FAIR Summary Engineering Report - This Engineering Report captures all results, experiences, and lessons learned from this task. The report shall describe the various components used in each workflow, elaborate on issues experienced, and recommend solutions for each reproducible workflow generated in this task.

Testbed-18 will feature “Housing Retrofit Program Planning” and “Utility Hosting Capacity Analysis” as use cases to explore the use of OGC geospatial standards, in particular OGC APIs, to support an Energy SDI. This will be achieved either through a) using the current OGC APIs; b) an extension of existing OGC APIs; or c) recommending development of new OGC APIs to meet building energy interoperability requirements. It is expected that outcomes of this task will support multiple uses within the CGDI, NRCan, nationally, and internationally. Additional objectives include:

This task shall address the following two main challenges for establishing an Energy SDI:

Additionally, the following overarching research questions shall further help guide the work for each task:

The following sections provide additional context as well as detailed task descriptions for the two challenges:

Task 1: Data Models

This task shall explore the development of data models and associated schemas to enable interoperability for key building energy datasets. These efforts will leverage the characteristics of existing building energy data to determine data model requirements for interoperability, and to explore if existing data models can be adapted for the Energy SDI vision. The application could include extracting information from building energy models for map attribution or conversely, extracting available attributes from a map for a number of dwellings in the stock to feed into building energy simulations. This task shall also explore how existing geospatial datasets related to buildings (e.g., 3D building representations) can be enhanced using building energy data provided through the data model.

The key outcome from this task shall be the creation of at least one draft model for a category of building energy data. The draft model shall be sufficiently complete such that it can be implemented with minimal further modification required. This work shall build on and extend previous work in the domain, potentially including but not limited to the National Building Layer data model, and data models relating to EnerGuide for Houses and the Housing Technology Assessment Platform (HTAP). HTAP supports data input via JSON formatted 'options' files, which are described here. The options file defines the attributes of a HOT2000 house model that can be changed within HTAP, the options that they can be changed to, and the data values that will be changed within the target .h2k file. A partial list of attributes in EnerGuide and a partial mapping of HTAP attributes to the Energy ADE specification will be made available prior to the kick-off meeting. Other relevant data sources required to develop 3D rendered models such as LiDAR and earth observation imagery can also be considered.

The task shall demonstrate the ability of the data model to support interoperability through reference implementations of the data model within at least two client applications. This demonstration shall include an example of geospatial analysis applied using data described by the data model.

The task shall demonstrate that the data model can enhance at least one existing geospatial building dataset, using building energy data (modeled or measured) described by the data model. Relevant existing building data to be used for this requirement will be determined in consultation with the sponsor and participants during the testbed execution.

Task 2: Geospatial Standards

Building on task 1, this task no. 2 will explore how existing or new API standards can support building energy data interoperability. Building energy data encoded using the data model(s) will act as an input to this task, providing the information that will be exchanged with multiple users and technologies over the internet through standard-based APIs.

Task 2 shall evaluate the potential of existing geospatial standard-based APIs to support the interoperability requirements for building energy data. If existing API solutions are identified, the task shall evaluate the potential of the API approach through a two-part demonstration:

If existing API solutions are deemed to be inappropriate for supporting building energy interoperability requirements, the task shall propose a new geospatial standard-based API framework for building energy data. This framework shall be sufficiently complete such that it can be incorporated into existing international standards development processes for future recognition as an official international geospatial standard.

Development of the API solution shall also consider how to support access to building energy data through cloud-based infrastructure. This task shall also explore cross-cloud interoperability of building energy data through the API in order to ensure building energy information can be shared between clouds, and that data access can be maintained if changes to a building energy data 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 building energy data through the API framework. Potential linkages with recent, similar efforts completed as part of the OGC’s Earth Observation Applications Pilot, OGC Testbed-16’s Data Access and Processing API for Geospatial Data, and OGC Testbed-17 Geospatial Data Cube API shall be explored and leveraged to the greatest extent possible to maximize API use and interoperability.

Outcomes from this task shall demonstrate the ability of the proposed API solution to enable cloud access to building energy information, support building energy data interoperability between clouds, and allow building energy cloud solutions to be modified with no changes to interoperability. The work shall also demonstrate how the proposed API will support analysis and processing of building energy information in an interoperable way. These outcomes shall be incorporated into the implementation plan as outlined for the API development task to ensure this functionality is incorporated into the final standard.

While cloud-based interoperability is a key consideration for this effort, the work shall also consider how the 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-building energy data systems represents an important aspect of ensuring building energy data can be seamlessly used on different forms of infrastructure.

Finally, this task shall result in creation of a best practice document that summarizes how geospatial standard-based APIs can enable building energy data interoperability. Findings for the three project use cases will be incorporated into the best practice as case studies.

Major Steps

This task consists of the following major steps to complete the above tasks:

This task shall undertake initial research towards the development of an Energy SDI. This will include:

The Building Energy Mapping and Analytics: Concept Development Study Report documents the research conducted in the context of mapping and analysis of the energy consumption of buildings, which is currently undertaken in Canada by local municipalities, energy utilities, and federal agencies independently and for various purposes and across different scales. These groups derive energy usage using many different sources and methods, yet fundamentally the data are the same: understanding of the building stock–the numbers, floor areas, and other characteristics of various building archetypes and how they impact energy usage. Despite this commonality, there is little to no coordination between these groups, resulting in differing methodologies, duplication of effort, lost energy savings, and lost opportunities for decarbonization, climate change mitigation, and climate resilience.

OGC’s 3D IoT Platform for Smart Cities Pilot advanced the use of open standards for integrating environmental, building, and IoT data in Smart Cities. The pilot investigated the capabilities to be supported by a 3D IoT Smart City Platform under CityGML, IndoorGML, and SensorThings API.

The following figure illustrates the high-level architecture with all work items and deliverables of this task.

The following list identifies all deliverables that are part of this task. Two client applications will be developed to allow multiple TIEs with two building energy data services and various external geospatial data services. The Building Energy Processing Service is an interface for at least two applications that make use of the various data services. All results, lessons learned, and experiences will be documented with Best Practices for Building Energy SDIs in a single Engineering Report. Further detailed requirements are stated above. All participants are required to participate in all technical discussions and support the Engineering Report(s) development with their contributions.

D122 Building Energy Data Service - Web API instance serving Building Energy data according to the data model defined in D012, and the mapping defined through D013. This instance is implemented as a profile of a current, emerging, or newly defined OGC Web API. The Web API instance shall support the cloud portability requirements as described above.

D123 Building Energy Data Service - Similar to D122.

D124 Building Energy Client - Client application that accesses building energy data at web interfaces that implement current, emerging, or newly defined OGC Web APIs; external geospatial data services, and processing applications available at the Building Energy Processing Service web interface.

D125 Building Energy Client - Similar to D124.

D126 Building Energy Processing Service - Web API instance providing access to applications that make use of the components D122, D123, D127, and D128. The Web API instance shall support the cloud-portability requirements as defined above.

D127 External Geospatial Data Service - Web API instance providing access to geospatial data that is required for the applications offered at D126.

D128 External Geospatial Data Service - Similar to D127.

D012 Building Energy Data Interoperability Engineering Report and Best Practice - This Engineering Report captures all results and experiences from this task. It shall respond to all the requirements listed above. The Engineering Report shall contain a plain language executive summary to outline the motivations, goals clearly, and critical outcomes of this task, taking into account the mandates of the OGC and NRCan. The report shall be made available to the public. Best Practice will recommend approaches to leverage geospatial standard-based APIs to enable building energy data interoperability. Findings from project use cases can be included as case studies.

D013 Building Energy Data Model Engineering Report - This Engineering Report describes the mapping to/from the data model(s) and geospatial building datasets. In addition, the report shall include diagrams illustrating how data model(s) from the energy domain relate to at least one existing geospatial building dataset.

OGC API-Features endpoints define their filtering capabilities. Filtering is standardized across different parts of OGC API-Features (see section Previous Work), with two parts still in draft status. Advanced filtering capabilities require sophisticated server software. Not all data providers will be able to operate such a powerful service endpoint. The following research questions shall be answered and solutions be developed in the context of FAA SWIM:

The following two figures illustrate the intended interactions between the components described in the Work Items & Deliverables section of this document. The two figures illustrate the workflows for using the filtering service for data subsetting (Figure 10) from the perspective of a business client; and for configuring the filtering service at runtime (Figure 11) from the perspective of the filtering rules developer.

An OGC API-Features façade to SWIM Data Service data service offers insufficient filtering capabilities to its customers. The Business User Client does not want to access large data sets and then perform filtering itself. Instead, the client wants to make use of a Filtering Service that can handle the filtering of the data and provide the subset of the data that the client is interested in. If the filtering service receives a data request from the client, it connects to the data service to access the necessary data, filters out everything that is not requested by the client, and eventually delivers the result to the client.

The second workflow is illustrated in Figure 11 below. This workflow demonstrates how a filtering service can be configured at run time. It is assumed that the Developer Client is aware of the API characteristics of the data service as well as the content schema of the data served by the data server. Based on both, the client supports the user with a GUI in the definition of the filtering rules. The user can then register these rules with the filtering service, which is now configured to run the data service specific filtering. In this Testbed, we will assume a 1:1 relationship between Filtering Services and Data Services. Though Filtering Services can support more than on Data Service, Filtering Services shall not combine data from multiple Data Services.

This task shall experiment with OGC API-Features filtering mechanisms and explore if best practices for advertising filtering capabilities are required beyond what is already defined in the various OGC API-Features parts. If so, these best practices shall be documented.

In addition, this task shall demonstrate advanced filtering in situations where the data endpoints support only rudimentary filtering by introducing a new service type “Filtering Service”. This service assumes that the content schema of a resource being queried is available for inspection. Clients to the filtering service shall make use of this knowledge and instruct the Filtering Service with schema-specific information.

The filtering service shall be configurable at runtime. This requires that the filtering rules for a specific data service are provided at runtime in a machine-readable manner. This task shall define how these filtering rules can be serialized and exchanged between rule developing clients and the filtering service.

OGC API - Features - Part 1: Core (and the draft OGC API - Common - Part 2: Geospatial Data standard) define two filtering parameters on the resource at path /collections/{collectionId}/items: bbox and datetime. OGC API - Features - Part 1: Core also adds support for simple equality predicates logically joined using the AND operator. These capabilities offer simple resource filtering for HTTP requests.

The Filter requirements class defined in OGC API - Features - Part 3: Filtering and the Common Query Language (CQL) defines additional query parameters that allow more complex filtering expressions to be specified when querying server resources.

The Filtering service does not need to be a new service type necessarily. It should be explored if for example defining a profile of the OGC API-Processes would be a possible solution.

The following figure illustrates the software architecture with all 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.

D001 Features Filtering Summary Engineering Report - The Engineering Report captures the proposed architecture, identifies the necessary standards, describes all developed components, and reports on the results of all Technology Integration Experiments (TIEs) conducted between participants. It is the goal of this task to get a good understanding on the current filtering capabilities and limitations around OGC API-Features and how filtering can be decoupled from the data services. The Engineering Report editor shall organize appropriate test scenarios with the participants D100/101/102/103. The report shall recommend future activities with respect to a generally enhanced SWIM architecture.

D002 Filtering Service and Rule Set Engineering Report - The Engineering Report shall document any best practices identified for features filtering and describe in detail how filtering can be decoupled from data services, how filtering rules can be provided to Filtering Services at runtime, and the describes the API of the Filtering Service.

D100 OGC API-Features Façade to SWIM Data Service - SWIM data service based on OGC API-Features with support for different filtering capabilities (the service shall allow activating/deactivating filtering capabilities as defined in the various OGC API-Features parts. The service may serve synthetic SWIM data or act as a façade to a native SWIM service. Optionally, the published data is the result of some fusion process.

D101 OGC API-Features Façade to SWIM Data Service - SWIM data service similar to D100.

D102 Filtering Service - RESTful Web API instance that supports advanced filtering for services that do not offer these capabilities themselves (D100/D101). Participants shall experiment with this service type. Ideally, the service allows filter statements sent together with data requests. The filter statements could even support filter statements that are based on a-priori knowledge of the content-schema of the offered resources.

The filtering service shall support configuration at run time by providing a transactional interface. The interface allows the registration of rule sets serialized in a format to be defined in this Testbed between D102/103/D002 participants.

The filtering service shall support filtering for both D100 and D101 individually. It does not need to support filter statements that require combining data from both data services.

D103 Filtering Service - RESTful Web API instance similar to D102

D104 Business User Client - The client shall execute Technical Interoperability Experiments (TIEs) with the filter services D102/D103 and the data services D100/101. The testing of the services can be very basic by simply sending requests and evaluating the responses. Emphasis is on interacting with the filter services D102/D103. This client does not need to provide a graphical user interface.

D105 Developer Client - Client application that supports the customer to define filter statements that can be expressed in a machine-readable way and exchanged with the filtering service. These filter statements should support insights into the content schema of the offered resources at the data server and the API characteristics of the data service. A-priori knowledge of all data service specifics can be assumed. The client shall provide a graphical user interface.

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-18: 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.