Testbed-14 Call for Participation (CFP)

In general, Bidders should propose specifically against the list of deliverables described under the Summary of Testbed Deliverables section below. But Bidders may go beyond funded deliverables to propose in-kind contributions that will address unfunded requirements as well. Participants should note, however, that Sponsors have committed to fund only those deliverables identified as being funded.

This Testbed provides a business opportunity for stakeholders to mutually define, refine, and evolve service interfaces and protocols in the context of hands-on experience and feedback. The outcomes are expected to shape the future of geospatial software development and data publication. The Sponsors are supporting this vision with cost-sharing funds to partially offset the costs associated with development, engineering, and demonstration of these outcomes. This offers selected Participants a unique opportunity to recoup a portion of their Testbed expenses.

This CFP incorporates the following additional documents:

This Testbed will be conducted in accordance with OGC Innovation Program Policies and Procedures.

OGC Principles of Conduct will govern all personal and public interactions in this initiative.

One Testbed objective is to support the OGC Standards Program in the development and publication of open standards. Each Participant will be required to allow OGC to copyright and publish documents based in whole or in part upon intellectual property contributed by the Participant during Testbed performance. Specific requirements are described under the "Copyrights" clauses of the OGC Intellectual Property Rights Policy.

The roles generally played in any OCG Innovation Program initiative are defined in the OGC Innovation Program Policies and Procedures, including Sponsors, Bidders, Participants, Observers, and the Innovation Program Team ("IP Team").

Additional explanations of the roles of Sponsors, Bidders, Participants, and Observers are provided in the Tips for New Bidders.

The IP Team for this Testbed will include an Initiative Director, an Initiative Architect, and multiple Thread Architects. Unless otherwise stated, the Initiative Director will serve as the primary point of contact (POC) for the OGC.

Thread Architects will work with Participants, Sponsors, and each other to ensure that Testbed activities and deliverables are properly assigned and performed. They are responsible for scope and schedule control, as well as for within-thread and cross-thread communications. They will also provide timely escalation to the Initiative Director regarding any severe issues or risks that happen to arise.

Once the original CFP has been published, ongoing authoritative updates and answers to questions can be tracked by monitoring the CFP Clarifications page. Instructions for accessing this page are included under Proposal Submission Procedures.

Bidders may submit questions via timely submission of email(s) to the OGC Technology Desk (techdesk@opengeospatial.org). Question submitters will remain anonymous, and answers will be regularly compiled and published on the CFP clarifications page.

OGC may also choose to conduct a Bidder’s question-and-answer webinar to review the clarifications and invite follow-on questions.

The following diagram provides a notional schedule of major Testbed events and milestones, and their approximate sequence of occurrence. The Testbed will use rolling-wave project management whereby more detailed scheduling will take place as each milestone draws near.

Participant Selection and Agreements:

Once the original CFP has been published, ongoing authoritative updates and answers to questions can be tracked by monitoring the CFP Clarifications page. Instructions for accessing this page are included under Proposal Submission Procedures.

Bidders may submit questions via timely submission of email(s) to the OGC Technology Desk (techdesk@opengeospatial.org). Question submitters will remain anonymous, and answers will be regularly compiled and published in the CFP clarifications document.

OGC may also choose to conduct a Bidder’s question-and-answer webinar to review the clarifications and invite follow-on questions.

Following the closing date for submission of proposals, OGC will evaluate received proposals, review recommendations with Sponsors, and negotiate Participation Agreement (PA) contracts, including statements of work (SOWs), with selected Bidders. Participant selection will be complete once PA contracts have been signed with all Participants.

Kickoff Workshop: A Kickoff Workshop ("Kickoff") is a face-to-face meeting where Participants, guided by thread architects, will refine the Testbed architecture and settle upon specific interface models to be used as a baseline for prototype component interoperability. Participants will be required to attend the Kickoff, including the breakout sessions of each thread for which they were selected. Participants will be expected to use these breakouts to collaborate with other Participants and confirm intended Component Interface Designs.

After the face-to-face Kickoff, most Testbed activities will be conducted remotely via web meetings and teleconferences until the Demonstration Event near the end of Testbed execution.

Development of Engineering Reports, Change Requests, and Other Document Deliverables: Development of Engineering Reports (ERs), Change Requests (CRs) and other document deliverables will commence during or immediately after Kickoff. Participants will deliver an Initial Engineering Report (IER) plus several iterations of a Draft Engineering Report (DER). Full process details can be found in the OGC ER Process.

Under the Participation Agreement (PA) contracts to be formed with selected Bidders, ALL Participants will be responsible for contributing content to the ERs. But the ER Editor role will assume the duty of being the primary ER author.

Component Design, Development, and Preliminary Testing: Participants will continue documenting detailed and final Component Interface Designs in the Testbed wiki. This documentation will allow task Participants to confirm a mutual understanding of each other’s interfaces so that subsequent interoperability testing can take place. A preliminary Technology Integration Experiment ("TIE", sometimes also referred to as a "Technology Interoperability Experiment") Connectivity Test milestone will be used to ensure that Testbed service endpoints can be reached by Testbed clients.

TIE Readiness Review: A TIE Readiness Review will be conducted with a Thread Architect to confirm that each TIE Participant is prepared to start conducting TIE testing with counterpart Participants.

Component Interoperability Testing, and Acceptance: Participants should deliver completed and fully TIE-tested component implementations no later than the 30 September milestone (unless an earlier milestone is identified in Appendix B Technical Architecture). The primary acceptance criterion for a component implementation deliverable is the conduct and recording of the TIE test. This test can also prove useful in accelerating the development of Demonstration Event assets such as video recordings.

Draft Engineering Reports: Participants should also deliver complete and clean Draft Engineering Report (DERs) by the 30 September milestone. A complete DER is one for which all major clauses have been populated with meaningful content. A clean is one where all known editorial defects have been repaired. This milestone will impact ALL Testbed Participants, even component implementers, who will be responsible for making necessary documentation material available to the ER Editor for use in authoring the ER. Testbed Sponsors and Thread Architects will review these DERs in the weeks following delivery.

DER Rework and SWG/DWG Reviews: Participants will be required to perform rework based on the reviews from Sponsors and Thread Architects. The ER editor will then make a request to the selected OGC SWG or DWG to perform its review and to consider making a request that the DER be voted on by the OGC Technical Committee (TC) for publication. The OGC 3-week rule must be followed if the DER is to receive a vote at a TC Meeting. The DER must be posted to the members-only OGC Pending Documents directory to enable this TC vote. Participants will likely have to perform one final round of rework based on SWG/DWG feedback. The further along the DER is when submitted to the WG, the less rework will be required.

Final Summary Reports and Demonstration Event: Participants Final Summary Reports will constitute the close of funded activity. Further development work might take place to prepare and refine assets to be shown at the Demonstration Event.

Assurance of Service Availability: Participants selected to implement service components must maintain availability for a period of no less than one year after the Final Delivery Milestone. OGC might be willing to entertain exceptions to this requirement on a case-by-case basis.

Detailed requirements for meeting all these milestones are provided in Appendix A Management Requirements.

Additional technical details can be found in Appendix B Technical Architecture.

< end of main body >

The process for completing a Testbed 14 proposal is essentially embodied in the online Bid Submission Form. A summary is provided here for the reader’s convenience.

Once an online account has been created, the user will be taken to a home page indicating the "Status of Your Proposal." If any defects in the form are discovered, this page includes a link for notifying OGC. The user can return to this page at any time by clicking the OGC logo in the upper left corner.

Clicking on the Clarifications link will navigate to the CFP clarifications page.

On the far right, the Review link navigates to a page summarizing all the deliverables the Bidder is proposing.

Once the final version of the information for all the proposed deliverables has been entered, the Bidder can submit the completed proposal to OGC by clicking the Submit button at the bottom.

The user is provided an opportunity under Attached Documentation at the bottom of this page to attach collateral documentation (one document per proposal). 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 testbed) may provide a description of their organization. It also contains a click-through check box where each Bidder will 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 deliverable of interest.

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, and demonstration of Testbed outcomes 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, etc.

Finally, a Bidder proposing to deliver a Service Component Implementation should use the Proposed Contribution (Please include any proposed datasets) field to identify what suitable datasets would be contributed (or what data should be acquired from another identified source) to support the proposed service. Full details of this requirement can be found under Data Requirements.

This field Proposed Contribution (Please include any proposed datasets) could 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 Appendix B Technical Architecture. This language could potentially include a brief elaboration on how the proposed deliverable will contribute to advancing the OGC technical baseline, or how implementations enabled by the specification embodied in this deliverable could add specific value to end-user experiences.

However, to help maintain a manageable process, Bidders are advised to avoid attempts to use the Testbed as a platform for introducing new requirements not included in Appendix B Technical Architecture. Any additional in-kind scope should be offered outside the formal bidding process, where an independent determination can be made as to whether it should be included in Testbed scope or not. Items deemed out-of-Testbed-scope might be more appropriate for inclusion in another OGC Innovation Program initiative.

The statements of work (SOWs) in the Participation Agreement (PA) contracts will ultimately require performance during testbed execution against the deliverables as described in Appendix B Technical Architecture plus any subsequent Corrigenda.

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

A selected Bidder will become a Testbed Participant by executing a Participation Agreement (PA) contract with OGC, which will require the following conditions:

Specific proposal evaluation criteria were presented earlier. Several process steps to be conducted by the IP Team are presented below to aid readers in understanding the overall process.

Soon after the proposal submission deadline, the IP Team and Sponsors will begin reviewing proposals, examining suitability of the proposed deliverables in light of the CFP requirements. During this analysis, the IP Team might need to contact Bidders to obtain clarifications and better understand what is being proposed.

At the Decision Technical Evaluation Meeting I (TEM I), the IP Team will present Sponsors with draft recommendations regarding which parts of which proposals should be offered cost-share funding. Sponsors will use this opportunity to suggest modifications.

The IP Team will notify each Bidder of their selection, including a description of the particular deliverables being offered, and OGC’s intent to enter into a Participation Agreement (PA) with them. Selected Bidders must be available for these contacts to be made to enable confirmation of continued interest. Bidder acceptance of the offer essentially locks in the scope that will be used to form the SOW to be attached to the forthcoming PA. A Bidder may reject the offer (for example, if the offer is to deliver only a small subset of its proposed deliverables).

A Decision Technical Evaluation Meeting II (TEM II) meeting will be conducted to review the outcomes of initial offers to selected Bidders, and any modifications that were needed due to Bidder rejections.

Following TEM II, the IP Team will develop the formal SOW and attach it to the full PA for each selected Bidder. Selected Bidders must be available to enable finalization of their PA contract.

Each PA will include a final identification of all assigned deliverables. The specific requirements that these deliverables must meet will be those documented in Appendix B Technical Architecture (plus any subsequent corrigenda).

Because Testbeds tend to deal with the lowest maturity level of OGC standards technology, they operate under the principle that “interoperable running code wins” (based loosely on an Internet Engineering Task Force founding belief).

In contrast with ordinary commercial contracts, which often focus on delivering a single-customer solution, the Participation Agreement contracts will encourage Participants to work in the broader interests of the OGC community. These interests are generally represented in the OGC Standards Working Groups (SWGs) and Domain Working Groups (DWGs). Testbed sponsorship enables a selected subset of these interests to be brought to bear on the production of interoperable running code and the reporting back of findings and recommendations as Change Requests (CRs) and document deliverables under the OGC Engineering Report Process.

In general, at least one Participant will be assigned for each client-server pair as an Engineering Report (ER) Editor, who will be responsible for authoring the ER, though there might be exceptions. See General Requirements for Proposing Deliverables for details. An ER Template will be provided to assist in the breakdown of content into multiple chapters describing specific findings and recommendations, a summary chapter, and supporting chapters (e.g., containing references and revision history).

OGC members who who are not selected to make any deliverables may still observe all Testbed activities by visiting the (members-only) OGC Observer Agreements page and registering to become a Testbed-14 Observer. The Observer Agreement will require that Observers follow the same intellectual property protection rules as apply to other Testbed stakeholders (e.g., to avoid sharing other stakeholder’s confidential information with individuals outside the Testbed).

Testbed stakeholders should also avoid making any representations that any of the intermediate technical decisions made internally during Testbed execution reflect any sort of endorsed position of the OGC. Formal Testbed recommendations will become "official" once the containing ER has received approval to be made public.

Testbed execution will commence with a Kickoff Workshop event ("Kickoff"). In general, the Kickoff ensures a common Participant understanding of the overall Testbed architecture and of all interfaces relevant to their assigned deliverables. Under the Testbed’s rapid pace, and guided by the Thread Architect, periods of development will be followed by synchronization among component developers, so that the likelihood of interoperation is maximized at each iteration. To maintain interoperability, each Participant should diligently adhere to the latest agreed specifications so that other Participants may rely on the anticipated interfaces in subsequent TIE testing.

Since Participants will be relying on one another to deliver interoperable components, all Participation Agreement (PA) contracts should be settled by the start of Kickoff. Any Participant that has not yet executed a PA by start of Kickoff will be required to attest to its commitment to a PA Statement of Work (SOW). The full PA must then be executed with OGC no later than Kickoff completion (two days after Kickoff start).

The Kickoff will include both plenary and thread-based breakout sessions. Thread breakouts will be used to ensure a mutual understanding of the detailed interfaces that will support component interoperability. The Kickoff will also present an opportunity to finalize regularly scheduled thread and subthread teleconferences ("telecons").

All selected Participants must send at least one technical representative per assigned thread to the Kickoff Workshop, and a representative should be present at the breakout sessions for every thread for which the Participant has been assigned a deliverable.

These requirements will also apply to Participants not requesting any cost-share funding (i.e., purely in-kind contribution) since their deliverables are still being relied upon by other Participants.

In general, Participants will be required to make deliverables meeting the requirements stated in CFP Appendix B Technical Architecture.

Under the Participation Agreement (PA) contracts to be formed with selected Bidders, all Participants will be responsible for contributing content to the ERs.

But the ER Editor role will assume the duty of being the primary ER author. As compared to the ER Editor role in Testbed-13, ER Editors in Testbed-14 must adopt a more proactive approach to consuming and documenting the knowledge being generated during component implementation. In other words, ER Editors serve as primary authors in addition to their editor role. All other participants are required to support the editors by making necessary documentation material available.

In addition, component implementers (Participants selected to deliver component implementations) will be responsible for contributing completed technical artifacts for inclusion as ER annexes. These include UML diagrams, XML schemas and instances, and abstract test suites, all of which have their own specialized clauses in the ER Template. Component implementers will also be responsible for contributing demo assets such as video recordings of component operation.

ER Editors will be responsible for observing the component implementation work and documenting (in the assigned ER) all findings and recommendations (except the technical artifacts identified above). They will also be responsible for ensuring the document’s overall integrity, authoring summary material and ensuring that global sections (e.g., References, Terms, Revision History, Bibliography) have all been completed.

ER Editors will also be responsible for enabling all required ER reviews (and subsequent rework), including internal reviews by Thread Architects and Sponsors, as well as requests for reviews by an appropriate OGC Standard Working Group (SWG) or Domain Working Group (DWG).

ER Editors will also be responsible for creating (and referencing) any Change Requests (CRs) arising from the work described in the assigned ER. CRs can be created using the OGC CR system.

The primary acceptance criterion for a document deliverable (e.g., an ER) will be approval from a Thread Architect to post the document to an OGC (members-only) folder called the OGC Pending directory. Permission to post will not be granted until the full OGC Engineering Report Process has been followed, including the step to request a review from an OGC SWG or DWG. All appropriate tooling should also have been utilized (ER Template, Asciidoc, GitHub), and the document should have achieved a satisfactory level of consensus among all assigned Participants.

In general, prototype component implementation deliverables (including services, clients, datasets, and tools) will be provided by methods suitable to its type and stated requirements. A service (e.g. a WFS instance or even an intermediary component) will be delivered by deployment for use in the Testbed via an accessible URL. A client will be used to exercise a service to test and demonstrate interoperability. Components will be developed and deployed in all threads for integration and interoperability testing in support of agreed-upon thread scenario(s) and technical architecture. The Kickoff will provide the opportunity to establish many of the agreed-upon details. These technical artifacts could also be utilized for cross-thread scenarios in demonstration events.

More specifically, the first acceptance criterion for any component implementation deliverable will be a successful demonstration of capability in a Technology Integration Experiment ("TIE") test.

The next acceptance criterion will be assurance that the work-package ER Editor has access to sufficient documentation material to record all findings and recommendations in the ER and associated CRs.

Another criterion will be evidence that the implementer has directly authored full ER content for any relevant Abstract Test Suite (ER Template Annex A), XML Schema Document (ER Template Annex B), or UML Model (ER Template Annex C).

A Participant assigned to deliver a client component implementation should, in addition, record TIE test execution (as evidence of delivery) and create demo assets, brief (several-minute) video recordings of client operation reflecting the newly enabled capabilities. These assets will become candidates for incorporation into executive-level briefings to be shown at the Demonstration Event near the end of the Testbed.

A Participant assigned to deliver a service component implementation should, in addition, provide assurance that the service endpoint will remain available to OGC and Sponsors for a period of no less than one year after Testbed execution. OGC might be willing to entertain exceptions to this requirement on a case-by-case basis.

A Participant assigned to deliver a service component implementation should, in addition, identify of one or more particular datasets that would be suitable for the proposed service. Details are provided under Data Requirements for Proposing Service Component Implementation Deliverables.

Some requirements might request delivery of a packaged prototype component (e.g., using a virtual machine or container). Consult the specific language in the Appendix B Technical Architecture for details regarding these requirements.

Testbed execution monitoring and control will follow an encapsulation principle. As long as a Participant continues [1] supporting activities on which other Testbed stakeholders are relying (e.g., telecons, TIEs, ER inputs) and [2] making timely delivery of their own deliverables, the question of what’s "going on" inside the Participant organization will likely not be raised.

Otherwise, any issues (or risks) that block (or threaten to block) timely delivery will enter a remediation status requiring the following responses:

The following definitions will be used to communicate and track deliverable status:

In general, risks and issues that are contained within a particular thread will be monitored and managed by the assigned Thread Architect, who will report ongoing status to other stakeholders. Any risks or issues that cross threads should be brought to the attention of all relevant Thread Architects and the Initiative Director.

Bidders who are new to OGC Testbeds are encouraged to review the following tips, extracted and updated from the Testbed-13 Clarifications document.

< end of appendix >

This Annex B provides background information on the OGC baseline, describes the Testbed-14 architecture and thread-based organization, and identifies all requirements and corresponding work items. For general information on Testbed-14, including deadlines, funding requirements and opportunities, please be referred to the Testbed-14 CFP Main Body.

Each thread aggregates a number of tasks. Each task specifies a number of requirements that need to be fulfilled by work items. The work items are funded by different sponsors.

An overview of all threads and assigned tasks is provided further below.

Testbed-14 is organized in a number of threads. Each thread combines a number of tasks that are further defined in the following chapters. The threads integrate both an architectural and a thematic view, which allows to keep related work items closely together and to remove dependencies across threads.

Each of the following sections provides a detailed description of a particular task.

One of the most interesting recent developments in Machine Learning (ML) has been in Deep Learning, a specialization of Artificial Neural Networks.

Deep Learning (DL) can be defined as a neural network approach that involves a large number of parameters and layers in one of four fundamental network architectures: unsupervised pre-trained networks, convolutional neural networks, recurrent neural networks and recursive neural networks. Automatic feature extraction is one of the areas where DL has shown great promise.

OGC Web services play a pivotal role in many geospatial work flows. Facading any type of geospatial data store and processing system, they can be used to support Machine Learning, Deep Learning & Artificial Intelligence systems. The goal of this task is to develop a holistic understanding and to derive best practices for integrating Machine Learning, Deep Learning, and Artificial Intelligence tools and principles into OGC Web service contexts. Even though an image analysis workflow is used here to describe interactions between components and interface requirements, it is emphasized that this task is not constraint to image analysis but should work with all types of data including vector information!

Essentially, the following two questions shall be answered:

To some extent, these questions can build on previous work, which allows to integrate machine learning tools behind OGC Web service interfaces by revising OGC Web Image Classification Service Discussion Paper (OGC 05-017) to support image classification using Machine Learning and Artificial Intelligence.

Previous Work OGC previously prototyped a Web Image Classification Service (WICS) interface (OGC 05-017) that defines these operations:

Using these operations, the WICS provides three types of classifications:

The previous work was not done with a Deep Learning Classifier and with focus on gridded imagery data, but that may not affect the Interface operations that are independent of algorithm type. The WICS operations directly match the functions shown in Figure 3 of the CFP.

Implementation of Components and Services

On the implementation side, this task shall support an image analysis and processing scenario. Imagine satellite imagery is stored in an image archive that is available to human image analysts and Machine Learning tools. An image analyst identifies a set of feature types on the images and makes this data available to the data store. These annotated data are available to both consumers and Machine Learning tools that use that data for training purposes. Depending on the type of available imagery data, Testbed-14 may differentiate two scenarios. In the first scenario, the image analyst uses prior- and post event data to identify for example areas destroyed by a natural disaster such as a hurricane. In the second scenario, the image analyst identifies feature types that do not take any change detection into account. The identified features could be compliant with Geography Mark-up Language (GML) application schemas such as the e.g. Multinational Geospatial Co-production Program (MGCP) Application Schema and the NSG Application Schema (NAS).

The Image Analyst queries image data (or is informed about new data by push notifications), identifies specific feature types, and provides the results of the analysis back to the system. These data include the identified feature types, the associated snippets (set of pixels in an image), as well as additional metadata as defined in Testbed-14.

A Machine Learning tool uses the Image Analysts' results as input training data to improve its learning algorithm. Rather than concentrating on the quality of the feature identification results, Testbed-14 shall explore the best workflows, service interaction patterns, an application schemata to express both analysis results and associated metadata such as trust levels and confidence, associated body of evidence, associated imagery, and optimized learning capabilities. The general workflow is illustrated in the figure below. The "Learning" box in the lower right corner shall illustrate the iterative nature of the workflow that uses results from the "Machine Learning and Artificial Intelligence" box to further train the model (e.g. by using external processes or data).

All data shall be made available at OGC data access services (e.g. WFS, WCS, SOS) as identified in responses to this Call for Participation. Additional catalog services might become part of the overall scenarios if necessary. This Call for Participation does not specify details on the involved service technology (i.e. participants can identify services types), but provides suggestions for possible implementations in the figure below.

Concept Study and Engineering Report

The Testbed-14 Machine Learning Engineering Report shall describe all experiences and lessons learned of the Machine Learning, Deep Learning & Artificial Intelligence implementations. In addition, it shall includes the results of a concept study that provides a truly holistic approach on the integration of machine learning and OGC Web services. This holistic approach may require some experimentation and shall include the following items:

In addition, the concept study shall analyze a geospatial feature extraction workflow that is slightly more complex than what can be realized in the implementation scenario described above. For simplicity, the process is outlined here in the form of Input-Process-Output stages. Issues that affect the Input stage include:

Some of the issues that affect the Process stage of a geospatial feature extraction workflow include:

Some of the issues that affect the Output stage of a geospatial feature extraction workflow include:

In the last decade, a technological framework known as SWIM (System Wide Information Management) has been developed in the FAA, EUROCONTROL, and more recently the Asia-Pacific Region as a viable model for Air Traffic Management (ATM) applications. "SWIM is a Federal Aviation Administration (FAA) advanced technology program designed to facilitate greater sharing of Air Traffic Management (ATM) system information, such as airport operational status, weather information, flight data, status of special use airspace, and National Airspace System (NAS) restrictions. SWIM will support current and future NAS programs by providing a flexible and secure information management architecture for sharing NAS information. SWIM will use commercial off-the-shelf hardware and software to support a Service Oriented Architecture (SOA) that will facilitate the addition of new systems and data exchanges and increase common situational awareness." (wikipedia)

SWIM addresses the communications and interoperability requirements of highly-distributed, loosely-coupled, and platform-independent components by consistently applying the principals of Service-Oriented Architecture (SOA). The major goal of SWIM is providing information to members of the civil aviation community. This information includes (but is not limited to) aeronautical, meteorological, and flight information, and it is rendered in a formal language such as XML.

The work in Testbed-14 is primarily motivated by the following aspects:

These aspects are subject of the following, simplified but realistic use case:

Testbed-14 shall address the following requirements:

This task combines a number of OGC technologies. It addresses both new capabilities at the service level as well as complex interaction patterns between services. In addition to the components described in this chapter, it makes use of WPS instances developed as part of the Exploitation Platform task.

The task consists of the four main topics WFS3.0, Federated Clouds, Security, and Workflows that make use of components provided by the Exploitation Platform task. The following figure provides an overview.

The following diagram provides an overview of all work items of this task. Elements from this diagram are used repeatedly further below to emphasize the various foci of the different topics.

This task completes the Next Generation OGC Web Services, Federated Clouds, Security & Workflows task’s section on WFS3.0. It is organized as a dedicated task because it reviews the work around WFS3.0 from a different angle. Here, focus is on complex 3D data or complex data schemas. The goal is to identify the best service solution for these particular needs as opposed to assuming they should be added to WFS 3.0 right away; which is a legitimate outcome of this task, but a full evaluation of options needs to precede.

The current work for a complete revision of WFS has focused on simple features and interaction, interrogation and extraction of these. However there are more complex use cases that require 3D data and/or more complex data schemas to achieve a users desired outcome. Some examples of these include:

To ensure that appropriate support is given to these use cases within the wider area of next-generation OGC Web services, Testbed-14 shall run a concept study addressing the following aspects:

OGC Testbed-14 supports the NASA Earth Science Data System (ESDS) Vision to

It contributes directly to ESDS mission to develop

Historically, less emphasis at NASA was placed on getting swath data into desktop GIS clients than the level 3 and level 4 gridded data. Testbed-14 will address this aspect - taking the Climate Forecast (CF) Conventions for remote sensing data into account - and will conduct activities in the following categories:

Improving access to NASA data in Swath structure is a key objective in Testbed-14. A first step is to understand Swath Data in the context of OGC Coverages Implementation Schema (CIS). The second step is to select a WCS Profile for a CIS defined CF-compliant Swath Data structure, before making swath coverage data available at WCS with visualization in GIS clients.

1. Modeling Swath Data that Use the Climate Forecast Conventions as Coverages

The Encoding of Swath Data in the Climate and Forecast Convention provides a proposal for an extension of the Climate and Forecast Metadata Convention (CF) to standardize the encodings of Earth Science swath data in the original instrument viewing geometry. The aim is that some form of the proposal be included in a future version of the CF convention. The proposal is based on the CF version 1.7 (current release) although backward compatibility is not necessarily an objective.

In addition, the Draft Extension for Group Hierarchies proposes enhancements called CF2-Group to support files with groups. Group files are those which utilize the "group" features of the Common Data Model (CDM) as implemented in NetCDF4. Such files can contain hierarchical, directory-like structures not possible with the single, flat namespace described by the current convention.

The referenced documents should be taken as a starting point, though exploring possible mechanisms to express swath data compliant with the currently approved CF conventions version 1.7 and the latest working draft 1.8 should be part of Testbed-14 as well.

When modeling swath data, different scanning methods resulting in different geometries shall be considered. The following graphic illustrates some typical situations, but is not exhaustive.

Others scanning modes that shall be addressed in Testbed-14 include for example vertical curtains. The Cloud-Aerosol LiDAR and Infrared Pathfinder Satellite Observations (CALIPSO) satellite mission provides vertical, curtain-like images of the atmosphere on a global scale using LiDAR. Probing the atmosphere with short pulses of laser light, CALIPSO allows scientists to determine precisely the altitudes of clouds and aerosol layers and the extent of layer overlap. In addition, it allows to identify the composition of clouds and to estimate the abundance and sizes of aerosols.

Another example for curtain-like scans are produced by the Cloud Profiling Radar (CPR), a 94-GHz nadir-looking radar which measures the power backscattered by clouds as a function of distance from the radar on board of CloudSat. The following figure shows the resulting scanning profile.

In summary, swath data from the following instruments and satellites shall be supported:

To support access to swath data using WCS, the swath data structure needs to be analyzed with respect to the OGC Coverage Implementation Schema (CIS) version 1.1. CIS specifies a coverage model for concrete, interoperable, conformance-testable coverage structures. CIS is based on the abstract concepts of OGC Abstract Topic 6 (which is identical to ISO 19123). CIS is interoperable in the sense that coverages can be conformance tested, regardless of their data format encoding, down to the level of single “pixels” or “voxels”. A key element of the Swath Coverage Engineering Report is a CIS Profile for CF-compliant Swath Data. Particular emphasis needs to be on the grid-irregular conformance class as described in section 8 of the OGC Coverage Implementation Schema (CIS) specification 09-146r6.

Additional requirements may arise from the mandatory use of the OGC Web Coverage Service (WCS) Application Profile - Earth Observation v1.1, as described in the next sections.

2. Encodings for Swath Coverages

Coverages can be encoded in any suitable format (such as GML, JSON, GeoTIFF or NetCDF) and can be partitioned, e.g., for a time-interleaved representation. Encoding(s) of the swath coverages defined above need to be defined for access using WCS.

3. Provide Swath Data at WCSs Hosting NASA Data

OGC Web Coverage Service (WCS) is a family of standards for Web service access to coverages. The recently developed OGC Web Coverage Service (WCS) Application Profile - Earth Observation v1.1, short EO-WCS v1.1 (OGC 10-140r2), defines a profile of WCS 2.0 (OGC 09-110r4) for use on Earth Observation data. Version 1.1 of the EO-WCS profile now supports 3D Datasets. A Dataset is an EO Coverage, which can represent, for example, a hyperspectral 2D satellite scene or a 3D atmospheric model.

Further background information on the latest EO profile updates is given in the Testbed-12 WCS Profile Update Engineering Report (OGC 16-033), which suggested the necessary extensions to the existing Web Coverage Service profiles, particularly the WCS Earth Observation Application Profile version 1.0 (OGC 10-140r1) to support multi-dimensional subsetting of 3D space and 1D time. The updated EO-WCS v1.1 dropped the 2D constraint and now explicitly allows coverages with more dimensions as long as they have a geographic footprint.

Testbed-14 shall analyse the EO-WCS profile version 1.1 and implement and describe two EO-WCS with the necessary extensions to cover the Swath Coverage modeling and encoding activities of the two prior steps. The two WCSs will be deployed for interoperability testing. Variations of the two WCS implementations will be determined based on evaluation of the responses to this Testbed-14 Call for Participation. Ideally, the first WCS supports the EO-profile v1.1 and offers an additional RESTful binding. This RESTful binding shall be described compliant to the OpenAPI specification. The OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface description for REST APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. The second implementation needs to be compliant to the EO profile version 1.1 with CF-compliant Swath Data support.

The WCSs will host NASA swath data. The Level 1 and Level 2 data to be hosted in the WCS are non-composited L1-L2 data for surface reflectance, surface temperature, soil moisture, fires, and aerosols.

4. Access and Use CF-Compliant Swath Data with GIS clients

To demonstrate access to the swath coverages, commonly available GIS clients will be used to access the WCS hosting NASA swath data. The clients will combine the swath coverages with other commonly available GIS data. The swath data will be visualized in the clients and combined with other data to demonstrate data integration with geospatial accuracy. These additional data sets need to be provided by the client developers.

A demonstration will be conducted that shows the value of WCS access to swath coverages. The demonstration will be scripted based on a scenario that will be defined at the Testbed-14 kick-off meeting. Responders to this call are encouraged to describe potential scenarios and relevant datasets in their proposals.

The National System for Geospatial-Intelligence (NSG) Application Schema (NAS) is an ISO 19109 compliant application schema that defines the conceptual model for identifying and encoding feature data in the U.S. National System for Geospatial-Intelligence (NSG). NGA utilizes the open source software tool ShapeChange as an integral piece in NAS development. This tool is used to take NAS-based UML models and create XML and RDF based schemas. Testbed-12 began development of capabilities for extracting profiles supporting specific mission functions from the full NAS content. Testbed-13 further refined the approach to NAS Profiling by investigating how a specific profile ("Urban Military Profile") can be processed in an automated way and used to derive implementation schemas for the OGC standards CDB and CityGML.

Testbed-14 shall further extend the capabilities of ShapeChange in the following ways:

1. Modeling extensions

The following modeling aspects shall be addressed:

2. JSON Support

This task seeks to extend the ShapeChange tool to support the use of JSON Schema, JSON, and JSON-LD:

3. RDF, JSON, and JSON-LD Conversion

4. Enhancements as recommended in Testbed-13

Testbed 14 shall address enhancements recommended in OGC Testbed-13: NAS Profiling ER; specifically, Section 7.3.

5. NAS Profiling Users of the NAS have described it as too complex for mission-specific implementations. This task for ShapeChage development is to improve on the methodology developed/demonstrated in Testbed-13 for Profiling the NAS to achieve smaller, more narrowly-focused, profile outcomes.

Natural Resources Canada’s responsibility is to foster an environment for the development and use of Spatial Data Infrastructures (SDI) both within Canada and internationally. This task is specifically concerned with improving SDI basemap and applications empowered by LiDAR point cloud data.

GeoBase is a federal, provincial and territorial government initiative that is overseen by the Canadian Council on Geomatics (CCOG). It is undertaken to ensure the provision of, and access to, a common, up-to-date and maintained base of quality geospatial data for Canada.

One of GeoBase’s current priorities is the National Elevation Strategy that consists in providing LiDAR point cloud and LiDAR-derived Digital Elevation Models (DEMs) for the southern part of Canada. These data products offer great potential for Canadians through a wide range of field, such as flood mapping, forestry and infrastructure. Considering the extent of the Canadian territory and the volume of such data, it is a large-scale project with potential complexities.

Point Clouds, in particular resulting from LiDAR and other sources of scanning that result in sets of vertices in multi-dimensional coordinate systems, play an important role in geospatial processes and applications. Currently, there is no consistent Point Cloud Ecosystem defined in the context of standardized geospatial services and encodings as defined by the Open Geospatial Consortium. The approach would need to be multi-faceted, including aspects such as point cloud data processing, storage, indexing, streaming, visualization, or indexing. Point cloud data would need to be served in a scalable way as raw data as well as in product form, ideally with links between the two.

On an abstract level, this work item shall address three key aspects:

Testbed-14 shall conduct a feasibility study that addresses the following aspects:

To ensure a maximum quality Engineering Report, the participant shall foresee and document extensive consultations with OGC activities and other related activities, working groups (such as e.g. Land and Infrastructure DWG and SWG and Marine DWG) and personnel. The participant with the support of the thread architect shall invite other OGC members to join this project on an in-kind basis.

The Architecture, CAD, and Geospatial industries have been converging on a body of standards to support an integrated view of urban spaces. This view covers the geography and topography, infrastructure and utilities, indoor spaces, and detailed building models. The Future City Pilot project was one of the collaborative efforts to advance this convergence. An example of what is possible can be obtained from the Future City Pilot project video that is available online.

This type of information would be very valuable for urban warfighters. This thread seeks to build on industrial capabilities to provide the highly detailed, fully integrated view of urban spaces required for the planning and execution of modern urban missions.

Testbed-14 shall evaluate the possible methods for integrating Augmented Reality (AR) content into CityGML content. The effort shall include an analysis of whether Augmented Reality content should be integrated into the CityGML data or whether the data content (features) should be linked for visualization purposes.

Testbed-14 shall demonstrate client side support for visualization of streamed CityGML with Augmented Reality (AR) content. Bidders shall include suggestions for suitable AR data in their proposals and shall investigate the role and applicability of OGC Augmented Reality Markup Language 2.0 (ARML 2.0), the proposed Community Standard 3D Tiles, and OGC Community Standard I3S.

Style Layer Descriptors (SLD) were introduced in OWS-1.2 (2002). The currently available version 1.1 of the OpenGIS Styled Layer Descriptor Profile of the Web Map Service Implementation Specification was published in 2007.

Over the past 10 years we have not seen an enthusiastic adoption of this technology, however it is still the underlying method to style layers in GeoServer. Furthermore, the common availability of 2.5 and 3-D visualization tools have taken symbology requirements far beyond those envisioned in 2002.

Testbed-14 shall investigate other renderer outputs such as JSON encoding of the portrayal information, so they can be handled on the client side in HTML5.x Canvas or other rendering libraries such as D3.js. Participants in this task shall perform an Analysis of Alternatives, e.g., Cascading Style Sheets (CSS), YAML SLD, MBStyle, and CartoDB, to identify and assess alternatives to the OGC Style Layered Descriptions/Symbol Encoding (SLD/SE) standard as implemented in OGC GeoPackage and OGC WMS/WMTS. Participants shall recommend a path forward and if a revision of SLD/SE is the best alternative or if there are better options available, such as a GeoCSS standard. Standardized portrayal continues to be an issue for the end user as proprietary implementations are inconsistent between vendors.

So far, the emphasis on developing the portrayal ontologies (Testbeds-12/13) has been on modeling and representing portrayal information for feature data.

The Testbed-12 Semantic Portrayal, Registry and Mediation Engineering Report specifies semantic information models and REST APIs for Semantic Registry, Semantic Mediation and Semantic Portrayal Services. It introduces the Semantic Registry Information Model (SRIM), a superset of the W3C DCAT ontology. SRIM can accommodate registry items other than dcat:Dataset, such as Service description, Schema and Schema Mapping description, and Portrayal Information (Styles, Portrayal Rules, Graphics and Portrayal Catalog), Layer, and Map Context. The Semantic Registry Service is used as an integration solution for federating and unifying information produced by different OGC Catalog Service information by providing a simplified access through hypermedia-driven API, using JSON-LD, Linked Data and HAL-JSON. During the Testbed, the Semantic Registry was used to store information about geospatial datasets and services, schemas and portrayal information. The Semantic Mediation Service was used to validate and perform transformation between schemas, including transformation chaining. The Semantic Portrayal Service was used as a convenience API to access Portrayal Registry information and perform rendering of geospatial data to different graphic representation (SVG, Raster and other pluggable formats).

The Testbed-12 GeoPackage Routing and Symbology Engineering Report describes the results of experiments to perform routing and styling on a GeoPackage. It includes a proposed approach for persisting static and dynamic styling information inside a GeoPackage.

The OGC Testbed-13: Portrayal ER captures the requirements, solutions, models and implementations of the Testbed-13 Portrayal Package. This effort leverages the work on Portrayal Ontology development and Semantic Portrayal Service conducted during Testbed-10, -11 and -12. The objective of Testbed-13 was to identify and complete the gaps in the latest version of the portrayal ontology defined in Testbed-12, complete the implementation of the Semantic Portrayal Service by adding rendering capabilities and perform a demonstration of the portrayal service that showcases the benefits of the proposed semantic-based approach.

This Testbed-14 task should extend the ontology to accommodate more complex symbols such as composite symbols and symbol templates to describe more advanced symbology standards such as the family of MIL-2525 symbols.

Natural Resources Canada’s responsibility is to foster an environment for the development and use of Spatial Data Infrastructures (SDI) both within Canada and internationally. This task is specifically concerned with improving SDI usability by non-traditional geospatial content users and producers including mainstream geospatial users, Web developers and Web browsers’ trunk.

Standards are the backbone of every important technology in society. Maps and spatial data are no different. The central challenge for standards-makers is to develop standards which are suitable for the target ‘audience’. As an example, consider electricity. While electricity, and the scientific and technical concepts behind its safe and effective generation, transmission and usage is beyond the knowledge of most people, it is also true that most people benefit from being able to easily use electricity. Most electrical appliances are built to consume electricity which conforms to standards at many levels, right up to use by consumer appliances via plugs and sockets. Information is not substantially different from electricity in many respects, in particular with respect to the need for standards.

Today, there exists a global network of hardware and software devices which produce and consume information of virtually any type: Hyper Text Transfer Protocol (HTTP) servers and Hyper Text Markup Language (HTML) browsers. Further, a huge supply of map and spatial content, in the form of Spatial Data Infrastructures (SDIs) already exists, created through the sustained and substantial investments of taxpayers across the globe. The objective of designing Map Markup Language is to improve integration of SDIs with the global HTTP application network (aka the “World Wide Web”, or just “the Web”) by strategically applying the architectural style with which the Web was designed: hypertext and media types. Enabling existing Spatial Data Infrastructures to be used with Map Markup Language will facilitate maps and spatial information to more readily fulfill their essential role in addressing society’s problems and issues both large and small, from global to local, through the ubiquitous and standard information medium of the Web. Natural Resources Canada believes that better integration of these two global information management resources will result in optimal spatial information use and re-use, and consequent improved return on investment for global SDIs.

The OGC Testbed-13: MapML Engineering Report discusses the approach of Map Markup Language (MapML) and Map for HyperText Markup Language (Map4HTML) described in: https://github.com/Maps4HTML and supported by the community in https://www.w3.org/community/maps4html/. The objective of this Engineering Report is to explore how MapML can be harmonized with the OGC standards mainstream and contribute to the progress of the specification avoiding unnecessary duplication. In particular, the ER proposes Web Map Service (WMS) or Web Map Tile Service (WMTS) as services that can be used to deliver MapML documents with small modifications. Another consideration on the ER is the inclusion of the time dimension and directions operation in MapML.

Testbed-14 shall address the following topics:

All aspects shall be explored in a MapML Extension Study that shall be documented in the MapML Engineering Report (D012).

On the implementation side,

Natural Resources Canada’s responsibility is to foster an environment for the development and use of Spatial Data Infrastructures (SDI) both within Canada and internationally. This task is specifically concerned with improving SDI Web Mapping Services.

Natural Resources Canada leads a Government of Canada initiative called the Federal Geospatial Platform (FGP). The FGP is the online environment for Government of Canada employees to find, combine and view Canada’s geospatial data on a map, to support evidence-based decision making. The FGP provides proactive, whole-of-government leadership in geomatics and Earth observations to better support government priorities and presents a collaborative partnership of 21 federal government departments. The FGP is part of Canada’s Open Government Action Plan; as such the public-facing version of FGP is the Open Government Portal Open Maps web site.

The ability to combine and visualize location-based data using web mapping services is a key value proposition of the Federal Geospatial Platform. The FGP includes the capability of selecting datasets with OGC web mapping services to view individually or combined with other services in the FGP viewer. This functionality is provided to allow users to immediately visualize and analyze geospatial data. Unfortunately, user feedback has proven that these geospatial web services are not always easy or intuitive to navigate, combine or understand. Because the FGP’s primary end users are government policy analysts who are not always highly familiar with mapping and web mapping technologies, it is important to make web mapping services, and the content they make available, as user-friendly as possible.

In 2016, to help alleviate this issue, the FGP developed a web map service quality assessment methodology, ran an assessment and developed recommendations and best practices to support a user friendly experience for all employees and citizens using web map services. Assessments to date have shown that key considerations are often very simple, but very impactful on quality of experience. The results of this study were used as the primary input into an OGC Discussion Paper created by the Quality of Service Experience Domain Working Group (QoSE-DWG).

The OGC QoSE-DWG have developed a discussion paper (OGC 17-049) entitled "Ensuring Quality of User Experience with OGC Web Mapping Services" that identifies and describes issues often encountered by users of OGC web mapping services that affect the quality of their experience, and also provides an assessment framework for identifying issues and measuring quality, along with potential solutions and guidance to improve the usability of services.

The assessment framework for measuring quality of experience and the associated recommendations for improving service quality are intended to benefit human end-users who need to rapidly assimilate and use web mapping visualizations to answer questions or input into analysis. In other words, they need to be able to make sense of the information OGC web mapping service provides them.

In addition, Testbed-13 addressed Quality of Service aspects in the aviation domain. Though specific to a particular domain, The Testbed13: Data Quality Specification Engineering Report addressed a number of general aspects that apply to this task nevertheless.

Testbed-14 shall address the following Web Mapping Services Usability aspects:

An OGC Concept Development Study is about to be kicked off December 2017 with results expected in March 2017. The study will address concerns raised that cartography suffers in distributed Web services environments and the poor presentation of data creates a negative perception of the data quality, spatial data infrastructures and Web standards.

The current domain of Web based map driven display often ignores the fundamental concepts of basic cartography. The developers of the Web based map tools are often programmers with little cartographic experience, training or guidance. A major problem exists: A haphazard use of colors, symbols, patterns, shapes and sizes are used to represent similar features. One attempt to help resolve the “cartography gap” was the development of an Open Geospatial Consortium standard that developers could use, called Styled Layered Descriptor (SLD) with a library of styles that web developers could use. The OGC Architecture Board (OAB) recently identified the renewal of SLD as a key priority. The OAB took an action to promote a Portrayal ad‐hoc meeting during the June 2017 Technical Committee meetings. The agenda included a range of use cases simple to complex; community efforts. The need for a conceptual model was identified as a method to move forward.

The proposed work for this Concept Development Study is in three major phases:

Testbed-14 shall consider this report as an additional resource in the context of Quality of Service & Experience of Web mapping.

The OGC Compliance Program provides the resources, procedures, and policies for improving software implementations' compliance with OGC standards. The Compliance Program provides an online free testing facility, a process for certification and branding of compliant products, and coordination of a vibrant community that develops and supports test scripts.

To further enhance the CITE tests and compliance analysis engine, Testbed-14 shall address topics illustrated in the figure below.

The following list identifies all deliverables that are part of this work item. Additional requirements may be stated above. Thread assignment and funding status are defined in section Summary of Testbed Deliverables.