Testbed-13 Call for Participation

Testbed-13 Call for Participation

Version 1.2 - Jan 31, 2017

This version is informational. The normative version of this CFP is always available at:
http://www.opengeospatial.org/standards/request/154.

Corrigenda

The following table identifies all corrections that have been applied to this CFP compared to the original release. Pure editorial changes are not listed.

Section Description

4

Master Schedule updated

5.2

Work items added and changed

B3

Figure 3 updated, new work packages "Enhanced Web Services" and "Point Cloud Streaming" added

B6

Section B6 merged with section B21 to form new section B6 "Semantic Registry"

B12

Requirements eased on AB105 and AB106

B16

Profile information added to NG102, NG103

B16

NG113 added to figure 23 and deliverables section

B21

Section B21 merged with section B6 to form new section B6 "Semantic Registry".

B22

Profile information added to NG119, NG120

B22

NG011 added to deliverables

B23

B23.1 & B23.6 "Event-driven automatic analytics workflow" deleted

B23

B23.2 requirements dropped

B23

Figure 31 updated to reflect new requirements

B23

Clarification added to B23.4 "Building Workflows"

B23

Clarification added to B23.5 "Cataloguing Workflows"

B23

Fit-for-Purpose Workflow numbering changed in B23.7

B23

"Automatic Analytics" removed in figure 34 and "Workflows" requirements section

B23

Figure 32 deleted

B23

Figure 33 updated to reflect changes in figure 31

B25

New section added "Enhanced Web Services"

B26

New section added "Point Cloud Streaming"

Table of Contents

Abbreviations

The following table lists all abbreviations used in this Call for Proposals

ABI

Activity Based Intelligence

AOI

Area of Interest

AMQP

Advanced Message Queuing Protocol

AtomPub

Atom Publishing Protocol

AVI

Aviation

BBOX

Bounding Box

CDR

Content Discovery and Retrieval

CITE

Compliance Interoperability and Testing

CFP

Call for Proposals

CMD

Command Center

CSMW

Community Sensor Model Working Group

CSW

Catalog Service Web

CTL

Compliance Testing Language

DAP

Data Access Protocol

DCAT

Data Catalog Vocabulary

DDIL

Denied, Degraded, Intermittent, or Limited Bandwidth

DGIWG

Defense Geospatial Information Working Group

DISA

Defense Information System Agency

DWG

Domain Working Group

EO

Earth Observation

EOWCS

Earth Observation Profile Web Coverage Service

ER

 Engineering Report

EXI

Efficient XML Interchange format

FGDC

Federal Geographic Data Committee

FIXM

Flight Information Exchange Model

FO

Field Operations

GDAL

Geospatial Data Abstraction Library

GEOINT

Geospatial intelligence

GeoXACML

Geospatial XACML

GIBS

Global Imagery Browse Services

GML

Geography Markup Language

HDF

Hierarchical Data Format

HTTP

Hypertext Transfer Protocol

HTTPS

Hypertext transfer protocol secure

ISO

International Organization for Standardization

JSON

JavaScript Object Notation

JSON-LD

JSON Linked Data

KML

Keyhole Markup Language

LiDAR

Light detection and ranging

MEP

Mission Exploitation Platform

MTOM

Message Transmission Optimization Mechanism

NASA

National Aeronautics and Space Administration

netCDF

network Common Data Form

NetCDF-CF

NETCDF Climate Forecasting

NSG

National System for Geospatial Intelligence

OAuth

Open Authorization

OBP

Object Based Production

OGC

Open Geospatial Consortium

OPeNDAP

Open-source Project for a Network Data Access Protocol

PKI

Public Key Infrastructure

POI

Points-of-interest

PubSub

Publication Subscription

RDF

Resource Description Framework

SAML

Security Assertion Markup Language

SOS

Sensor Observation Service

SPARQL

SPARQL Protocol and RDF Query Language

SSO

Single Sign On

SWAP

Size, Weight, and Power

SWE

Sensor Web Enablement

SWG

Standards Working Group

T13

Testbed-13

TEAM

Test, Evaluation, And Measurement Engine

TEP

Thematic Exploitation Platform

TSPI

Time-Space-Position-Information Standard

TWMS

Tiled Web Mapping Service

US

United States

UML

Unified Modeling Language

USGS

U.S. Geological Survey

W3C

World Wide Web Consortium

WCPS

Web Coverage Processing Service

WCS

Web Coverage Service

WFS

Web Feature Service

WIS

Web Integration Service

WKT

Well Known Text

WMS

Web Mapping Service

WMTS

Web Mapping Tile Service

WPS

Web Processing Service

WS

Web Service

WSDL

Web Services Description Language

XACML

eXtensible Access Control Markup Language

XOP

XML-binary Optimized Packaging

XXE

XML External Entity Injection

1. Introduction

The Open Geospatial Consortium (OGC®) is releasing this Call for Participation ("CFP") to solicit proposals for the OGC Testbed 13 ("T13") initiative. The CFP is in two parts due to specialized sponsor procurement requirements:

  • Part 1 - this CFP document ("Part 1 CFP" or "CFP")

  • Part 2 - an Invitation To Tender pack ("Part 2 ITT") ref: AO320105 Thematic Exploitation Platform (TEP) Thread, released via the European Space Agency (ESA) Electronic Mailing Invitation to Tender System (EMITS).

Important Part 2 ITT is described separately from this document and has distinct response requirements that can be found at the link provided above. So any Bidder wishing to respond to both Part 2 ITT (described externally) and the Part 1 CFP (described herein) must deliver two separate proposals, one conforming to each set of response requirements. A Bidder wishing to respond to one or the other (but not both) would submit only one proposal (conforming to the relevant part’s requirements).

Under Part 1 CFP, the OGC, on behalf of initiative-sponsoring organizations ("Sponsors"), will provide cost-sharing funds to partially offset expenses uniquely associated with T13. Thus this solicitation requests proposals from bidding organizations ("Bidders") wishing to receive cost-sharing funds. However, not all proposals are expected to request cost-sharing funds. OGC intends to involve as many technology developers and providers ("Participants", to be selected from among all the bidders) as possible to the extent that each Participant can contribute to and benefit from initiative outcomes. So this solicitation also seeks responses offering solely in-kind contributions (i.e., no cost-sharing funds whatsoever). The majority of responses are expected to include a combination of a cost-sharing request along with a proposal for an in-kind contribution.

Note

Once the CFP has been published, ongoing updates can be tracked by monitoring the Testbed 13 CFP web page.

1.1. Background

The OGC Interoperability Program ("IP") provides global, hands-on, collaborative prototyping for rapid development and delivery of proven candidate specifications to the OGC Standards Program, where these candidates can then be considered for further action. In IP initiatives, Participants collaborate to examine specific geo-processing interoperability questions posed by the initiative’s Sponsors. These initiatives include testbeds, experiments, pilots, and plugfests – all designed to foster the rapid development and adoption of open, consensus-based standards. Additional information can be found in the OGC IP policies and procedures documentation.

The OGC recently reached out to potential initiative sponsors to review the OGC technical baseline, discuss results of prior initiatives, and identify current testbed requirements. After analyzing these inputs, the OGC recommended that the content of the testbed be organized around two parts, Part 1 CFP and Part 2 ITT.

A complete list of all testbed deliverables (including both Part 1 CFP and Part 2 ITT) is provided in the Summary of Testbed Deliverables section below.

Tip

In addition to the funding opportunities provided by the sponsors, Testbed 13 will provide a new opportunity for selected participants to seek additional venture capital investment in technical areas associated with their Testbed 13 assigned work areas. For more information, see additional information here.

1.2. Participant Roles and Benefits

Participants may play any of several possible roles:

  • Developer of one or more software components implementing interfaces and protocols for one or more of the testbed services,

  • Developer of one or more tools to assist in the testing and demonstration of implemented software components,

  • Editor of one or more Engineering Reports or User Guides that documents findings and recommendations, and/or

  • Provider of general-purpose resources such as labor hours and infrastructure assets (e.g., data, software, hardware, facilities).

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 are committed to funding only those deliverables identified as being funded.

This testbed provides a business opportunity for stakeholders to mutually define, refine, and evolve services, 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.

1.3. CFP Documents

This Part 1 CFP incorporates the following additional documents:

Any Bidder interested in participating in this testbed should respond by submitting a proposal per the instructions provided herein. Limited cost-sharing funds are available to partially offset costs incurred by Participants in support of this initiative.

1.4. Intellectual Property in the Testbed

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 IPR document identified above.

1.5. Principles of Conduct

The OGC Principles of Conduct document identified above will govern all personal and public interactions in this initiative.

2. Proposal Submission Instructions

Important The instructions described in this section pertain specifically to proposals in response to the Part 1 CFP. Full instructions for responding to the Part 2 ITT solicitation can be found in the ITT pack referenced above. Part 2 ITT has specific requirements on the proposal format and submission process and has funding restrictions applied to ESA member states, associated member states, and states with cooperation agreements (Canada).

Bidders must be OGC members and must be familiar with the OGC mission, organization, and process. Proposals from non-members will be considered provided that a completed application for OGC membership (or a letter of intent to become a member) is submitted prior to or with the proposal.

Documentation submitted in response to this CFP will be distributed to OGC and Sponsor staff members. Submissions will remain in the control of these stakeholders and will not be used for other purposes without prior written consent of the Bidder. Please note that each Bidder will be requested to release the content of its proposal (excluding financial details) to all testbed stakeholders (including other Participants) once it has agreed to participate in the testbed initiative. Confidential information must not be submitted under this request and should not be disclosed at any time during testbed solicitation or execution.

Part 1 CFP Participants will be selected to receive cost sharing funds on the basis of adherence to the requirements stipulated in this CFP and the overall quality of their proposal. The general testbed objective is for the work to inform future OGC standards development with findings and recommendations surrounding potential new specifications. Bidders are asked to formulate a path for producing running, interoperable prototype solutions. Bidders not selected for cost sharing funds are encouraged to participate in the initiative on an in-kind basis.

Each selected Part 1 CFP Participant will be required to enter into a Participation Agreement ("PA") with the OGC. The PA will include a statement of work (SOW) identifying Participant roles and responsibilities. The purpose of the PA is to encourage and enable Participants to work together to realize testbed goals for the benefit of the broader OGC community.

2.1. How to Transmit Your Response Proposal

To submit a response proposal, complete the two Response Templates (narrative and financial) and email them as attachments to the OGC Technology Desk at . Any of the following attachment output formats is acceptable:

  • Microsoft Office (.DOCX, .XLSX),

  • Open Document Format (.ODT, .ODS),

  • Portable Document Format (.PDF).

Part 1 CFP proposals must be received at OGC before the appropriate response due date indicated in the Master Schedule.

2.2. Proposal Format and Content

For a Bidder’s response to qualify for consideration, the response must provide all required information in accordance with Part 1 CFP instructions, including those contained in appendices and the two templates. Please note that the Financial Response Template contains one worksheet for a cost-sharing request and another for in-kind contributions. Bidders must use these templates in preparing their proposals.

Note that proposal reviewers will be instructed to avoid reading or evaluating any material in excess of stated page limits.

2.2.1. Technical Proposal

The Part 1 CFP Technical Proposal should be based on the Narrative Response Template and must include the following:

  • Completed Title Page

  • Table of Contents

  • Overview, not to exceed two pages (this section will not be considered in making the evaluation of the proposal)

  • Proposed contribution(s) in each thread or work package (this section will form the basis for the technical evaluation of the proposal)

  • Proposed work organized by technical activity type (this section will be considered in making the management evaluation of the proposal)

Additional detailed instructions for each template can be found in the template itself.

2.2.2. Cost Proposal

The Part 1 CFP Cost Proposal should be based on the two worksheet templates contained in the Financial Response Template and must include the following:

  • Completed Testbed Cost-Sharing Funds Request Form

  • Completed Testbed In-Kind Contribution Declaration Form

Additional detailed instructions are contained in the template itself.

2.3. Questions and Clarifications

Once the Part 1 CFP is issued, potential Bidders will be permitted to submit questions to support their proposal development and submission. Questions should be emailed by the Bidder-question due date (indicated in the Master Schedule) to the OGC Technology Desk (). Question submitters will remain anonymous, and answers will be compiled and published in a regularly updated CFP clarifications document. OGC may also choose to conduct a Bidder’s question-and-answer webinar to review clarifications and invite follow-on questions.

2.4. Reimbursement Restrictions

Selected Participants will not be reimbursed for any of the following:

  • Costs incurred in procuring any hardware or software

  • Costs incurred in connection with preparing proposals in response to this CFP

  • Costs incurred for travel to or from the Kickoff or demonstration events

2.5. Venture Capital Coordination Opportunity

Organizations responding to this CFP, are invited to express their interest in being considered by select venture capital investment firms (VCs) regarding elements in their testbed proposal. OGC has teamed with the venture capital firm Data Tribe. OGCs role is to assist in the alignment of interests. After identification of common interests, OGC will introduce the VC and the Participant, and subsequent discussions should take place directly between these two parties.

If your organization is interested in coordinating with a VC, include a statement in your response to that effect, including an identification of the specific technology areas that should be considered by the VC. An outline of testbed technology areas appears below. Additional technical details can be found in Appendix B, including an overview of thread allocations for all work packages.

  • Cloud Computing Environment for Earth Observation Data

  • USGS Topo Combined Vector Product data to GeoPackage

  • Map Markup Language & Web-Map HTML

  • Climate Data Accessibility for Adaptation Planning

  • Vector Tiling

  • CDB

3. Proposal Evaluation Criteria

Proposals will be evaluated according to criteria that can be divided into two areas: Technical and Management.

3.1. Technical Criteria

  • Understanding of and compliance with requirements;

  • Quality and suitability of proposed design;

  • Where applicable, proposed solutions are OGC-compliant.

3.2. Management Criteria

  • Adequate, concise descriptions of all proposed activities, including how each activity contributes to achievement of particular requirements and deliverables. To the extent possible, it is recommended that Bidders utilize the language from the CFP itself to help trace these descriptions back to requirements and deliverables.

  • Costing and planning:

    • Proposed solutions are feasible (can be delivered using proposed resources),

    • Cost-share compensation request is reasonable for proposed effort;

    • In-kind contribution is of value to the initiative, manpower deployment, experience and capacity of the tenderer, and compliance with substantive tender and contract conditions;

  • Experience and capacity of the tenderer with OGC initiatives.

4. Master Schedule

The following table details the major events and milestones associated with the testbed and this CFP:

Table 1. Master schedule
Milestone Event

3 February 2017

Final Bidder Questions Due

7 February 2017

Bidders Q&A Webinar

20 February 2017

Part 1 CFP Proposal Submission Deadline

1 March 2017

First Round of Bidder Notifications Started

8 March 2017

Second Round of Bidder Notifications Started

31 March 2017

All Part 1 CFP Participation Agreements Signed

4-6 April 2017

Kickoff Workshop Event

30 June 2017

Preliminary Design and Implementations Milestone

30 September 2017

Delivery of Preliminary Clean, Full DERs and TIE-tested Component Implementations

31 October 2017

DERs Posted to Pending and WG Review Requested

15 November 2017

Demo Assets

30 November 2017

Participant Final Summary Reports

[date in December 2017 TBD]

Demonstration Event

Sequence of Events, Phases, and Milestones

The following diagram provides a notional schedule of major testbed events, phases, 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.

Milestones

Figure 1. Overview of events, phases, and milestones

Participant Selection and Agreements: Once the Part 1 CFP is issued, potential Bidders will be permitted to submit questions to support their proposal development and submission. Questions should be emailed by the Bidder-question due date (indicated in the Master Schedule) to the OGC Technology Desk (). Question submitters will remain anonymous, and answers will be compiled and published in a regularly updated CFP clarifications document. OGC will also conduct a Bidder’s question-and-answer webinar to review clarifications and invite follow-on questions.

Following the closing date for submission of proposals, OGC will evaluate received proposals, negotiate with selected Bidders, and communicate testbed status to the OGC Technical and Planning Committees. Participant selection will be complete once PA contracts, including statements of work (SOWs), 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 (including generic interfaces and protocols to be used as a baseline for software components) and the demonstration concept. Participants will be required to attend the Kickoff, including thread activities of each thread for which they were selected.

Component Development, Test, and Refinement: After the Kickoff, Participants will develop components based on the interface designs for insertion into the testbed, and integrate selected components for support of TIEs and demonstration deliverables. These activities will be conducted remotely via web meetings and teleconferences.

Preliminary Design and Implementations Milestone: Development work leads up to the Preliminary Design and Implementations milestone. This is a critical milestone to complete draft documents based on collaboration among participants in thread teams during Kickoff (e.g., design documents or preliminary service implementations). These draft documents should confirm each Participant’s understanding of its requirements, components to be delivered, and remaining delivery schedule.

Final Delivery Milestone: Participants will be required to make final delivery of all items no later than the Final Delivery milestone, which will constitute the close of funded activity. Further development may take place to refine demonstration assets.

Final Activities and Demonstration Event: A testbed Demonstration will be conducted to highlight findings and recommendations to the TC, Sponsors, and the broader community of interest. This event could entail multiple demonstrations to highlight particular capabilities. Participants selected to deploy demonstration assets may do so after the Final Delivery Milestone, but they must provide a technical representative to participate in or support the development of the integrated demonstration.

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. Some Sponsors may be willing to entertain exceptions to this requirement on a case-by-case basis.

Participant requirements for proposing activities to support these phases can be found in Appendix A.

5. Summary of Testbed Deliverables

The following tables show the full set of testbed deliverables, including ID, deliverable name, work package, and funding status.

A deliverable’s funding status can funded ("F"), unfunded ("U"), or under negotiation ("Un-Neg"), depending on the current state of sponsor funding.

  • For a deliverable with a funding status of "F", sponsor funding has already been confirmed.

  • A deliverable with a funding status of "U" is within CFP scope, but has a lower priority and does not have any sponsor funding.

  • A deliverable with a funding status of "Un-Neg" is one for which a sponsor intends to provide funding, but a final commitment of this funding is still pending.

Please note that each deliverable indicated as "F" or "Un-Neg" would be funded at most once. No deliverable should be interpreted as offering multiple instances. For any deliverable still under negotiation ("Un-Neg"), if funding for that deliverable ends up not being committed, any bid for cost-sharing on that deliverable will be dismissed.

All deliverables have been assigned to work packages, which will be organized into larger threads before Kickoff. A preliminary set of threads has been provided in Appendix B.

All Participants are required to provide at least some level of in-kind contribution (i.e., activities requesting no cost-share compensation). As a rough guideline, a proposal should include at least one dollar of in-kind contribution for every dollar of cost-sharing compensation requested. All else being equal, higher levels of in-kind contributions will be considered more favorably during evaluation.

Some participation may be fully in-kind. Any item proposed as a fully in-kind contribution will likely be accepted if it meets all the other evaluation criteria (i.e., other than the Management Criterion "Cost-share compensation request").

Important The following requirements pertain to all all web service implementation deliverables prefixed by "NG…​".

Please note that the following additional requirements apply to all web service implementation deliverables prefixed by "NG…​":

  • All web service implementation deliverables with prefix “NG…​” must, in addition to meeting that deliverable’s unique requirements, implement either a DGIWG or NSG Profile of that service if one exists.

  • All web service deliverables implementing either a DGIWG or NSG Profile must execute and pass any corresponding profile compliance test if one exists.

  • All web service implementation deliverables under the Workflows work package below must implement the requirements of a security architecture for service chaining.

  • Preference will be given to web service implementation deliverables that are proposed to be implemented in a cloud-based environment.

In the tables below, document deliverables are numbered ..001 and increasing, and implementation deliverables are numbered ..101 and increasing.

5.1. Part 2 ITT Thematic Exploitation Platform (TEP) Deliverables and Funding Status

Important The Part 2 ITT Thematic Exploitation Platform (TEP) Deliverables are listed here to provide a complete overview of all T13 work items. Full instructions for responding to the Part 2 ITT solicitation can be found in the ITT pack referenced above.

Additional technical details can be found in Appendix B, including an overview of thread allocations for all work packages.

Table 2. Part 2 ITT Thematic Exploitation Platform (TEP) Deliverables and Funding Status
ID Document / Component Work Package Thread Funding Status

ES001

EP Application Package ER

TEP

EOC

F

ES002

Application deployment & execution service ER

TEP

EOC

F

ES101

EP Application package implementation 1

TEP

EOC

F

ES102

EP Application package implementation 2

TEP

EOC

F

ES103

ES103: TEP client 1

TEP

EOC

F

ES104

ES103: TEP client 2

TEP

EOC

F

ES105

Application deployment service implementation 1

TEP

EOC

F

ES106

Application deployment service implementation 1

TEP

EOC

F

ES107

EP Application for Forestry TEP implementation

TEP

EOC

U

5.2. Part 1 CFP Deliverables and Funding Status

Additional technical details can be found in Appendix B, including an overview of thread allocations for all work packages.

Table 3. Part 1 CFP Deliverables and Funding Status
ID Document / Component Work Package Thread Funding Status

NR001

Cloud ER

Cloud

EOC

F

NR101

Cloud WPS 1

Cloud

EOC

F

NR102

Cloud WPS 2

Cloud

EOC

F

 — 

 — 

 — 

 — 

 — 

UG002

DCAT/SRIM ER

Semantic Registry

CCI

F

UG101

DCAT/SRIM Server

Semantic Registry

CCI

F

NG124

PubSub CSW

Semantic Registry

CCI

Un-Neg

 — 

 — 

 — 

 — 

 — 

NG006

Point Cloud Streaming ER

Point Cloud Streaming

CCI

Unfunded

NG117

Point Cloud Streaming Server

Point Cloud Streaming

CCI

Unfunded

NG118

Point Cloud Streaming Client

Point Cloud Streaming

CCI

Unfunded

 — 

 — 

 — 

 — 

 — 

FA001

Abstract Quality Model ER

Aviation QoS

CCI

F

FA002

Data Quality Specification ER

Aviation QoS

CCI

F

FA003

Quality Assessment Service ER

Aviation QoS

CCI

F

 — 

 — 

 — 

 — 

 — 

FA004

Geospatial Taxonomies ER

Aviation Taxonomies

CCI

F

 — 

 — 

 — 

 — 

 — 

DG001

Fit-for-Purpose ER

Fit for Purpose

FO

F

DG101

CSW or WPS with fit-for-purpose support

Fit for Purpose

FO

F

AB103

WFS Data service with fit-for-purpose support

Fit for Purpose

FO

F

AB104

Client with fit-for-purpose support

Fit for Purpose

FO

F

 — 

 — 

 — 

 — 

 — 

UG001

US Topo GeoPackage ER

Geopackage

FO

F

UG102

USGS Topo GeoPackage

Geopackage

FO

F

AB102

GeoPackage Client

Geopackage

FO

F

 — 

 — 

 — 

 — 

 — 

NR002

MapML ER

MapML

CCI

F

NR103

MapML Server

MapML

CCI

F

 — 

 — 

 — 

 — 

 — 

AB001

Concepts of Data and Standards for Mass Migration ER

Mass Migration

DSI

F

AB002

Security ER

Mass Migration

DSI

F

PM001

NIEM IEPD Engineering Report (ER)

Mass Migration

DSI

Un-Neg

AB101

OAuth-enabled Web Service

Mass Migration

DSI

F

AB105

Security-enabled Desktop client (EOC Desktop Client)

Mass Migration

DSI

F

AB106

Security-enabled Mobile client (EOC Mobile Client) (GeoPackage & Web Service)

Mass Migration

DSI

F

PM101

Messages and Schemas or CVISR (+ POS-IAN-VINFO-NOA) IEPDs

Mass Migration

DSI

Un-Neg

PM102

AIS Vessel Info Data Service (WFS)

Mass Migration

DSI

Un-Neg

PM103

SAML-enabled Web Feature Service with Transactions (WFS-T)

Mass Migration

DSI

Un-Neg

PM104

NIEM-GML Integration Component (WPS)

Mass Migration

DSI

Un-Neg

PM105

Security Component - SAML Authentication Service

Mass Migration

DSI

Un-Neg

PM106

Security Component - Federated ID Management Service

Mass Migration

DSI

Un-Neg

 — 

 — 

 — 

 — 

 — 

GE101

QGIS Security Client

Security

DSI

F

 — 

 — 

 — 

 — 

 — 

DS001

Vector Tiles ER

Vector Tiling

S3D

F

OS101

Vector Tiles implementation

Vector Tiling

S3D

F

OS102

Vector Tiles client implementation

Vector Tiling

S3D

F

NG116

WFS for Vector Tiling

Vector Tiling

S3D

Un-Neg

DS101

Vector Map Tiling Service

Vector Tiling

S3D

F

 — 

 — 

 — 

 — 

 — 

NA001

Climate Data Accessibility for Adaptation Planning ER

Modeling

DSI

F

NA101

Agriculture Scientist Client

Modeling

DSI

F

NA102

Non-Scientist or Analyst Client

Modeling

DSI

F

NA103

Prediction WPS

Modeling

DSI

F

NA104

WCS access to climate data

Modeling

DSI

F

 — 

 — 

 — 

 — 

 — 

NG001

CDB ER

CDB

S3D

Un-Neg

NG101

Feasibility Study

CDB

S3D

Un-Neg

NG102

CDB WFS

CDB

S3D

Un-Neg

NG103

CDB WCS

CDB

S3D

Un-Neg

NG104

CDB WFS (3D)

CDB

S3D

Un-Neg

NG105

CDB Client

CDB

S3D

Un-Neg

 — 

 — 

 — 

 — 

 — 

NG002

3D Tiles & i3s Interoperability & Performance ER

3DTiles and i3s

S3D

Un-Neg

NG106

CDB Implementation

3DTiles and i3s

S3D

Un-Neg

NG107

CityGML Datastore

3DTiles and i3s

S3D

Un-Neg

NG108

Streaming Engine-1

3DTiles and i3s

S3D

Un-Neg

NG109

Streaming Engine-2

3DTiles and i3s

S3D

Un-Neg

NG110

3D Performance Client

3DTiles and i3s

S3D

Un-Neg

NG111

CDB Performance Client

3DTiles and i3s

S3D

Un-Neg

 — 

 — 

 — 

 — 

 — 

NG003

NAS Profiling ER

NAS Profiling

S3D

Un-Neg

NG112

ShapeChange Enhancements

NAS Profiling

S3D

Un-Neg

NG113

Data Models

NAS Profiling

S3D

Un-Neg

 — 

 — 

 — 

 — 

 — 

NG004

Disconnected Network ER

DDIL

FO

Un-Neg

NG005

SWAP ER

DDIL

FO

Un-Neg

NG114

Compression Test Server

DDIL

FO

Un-Neg

NG115

Compression Test Client

DDIL

FO

Un-Neg

 — 

 — 

 — 

 — 

 — 

NG008

Portrayal ER

Portrayal

DSI

Un-Neg

NG122

Portrayal Demonstration

Portrayal

DSI

Un-Neg

 — 

 — 

 — 

 — 

 — 

NG125

Enhanced WMTS

WxS

DSI

Unfunded

NG126

Enhanced WMS

WxS

DSI

Unfunded

NG127

Tile-handling WPS-1

WxS

DSI

Unfunded

NG128

Tile-handling WPS-2

WxS

DSI

Unfunded

 — 

 — 

 — 

 — 

 — 

NG007

Asynchronous Services ER

Asynchronous Services

FO

Un-Neg

NG119

Asynchronous WFS-1

Asynchronous Services

FO

Un-Neg

NG120

Asynchronous WFS-2

Asynchronous Services

FO

Un-Neg

NG121

GeoSynchronization Service

Asynchronous Services

FO

Un-Neg

NG011

GeoSynchronization Service Best Practice ER

Asynchronous Services

FO

Un-Neg

 — 

 — 

 — 

 — 

 — 

NG009

Workflow ER

Workflows

FO

Un-Neg

NG130

Workflow WPS-1

Workflows

FO

Un-Neg

NG131

Workflow PubSub Server

Workflows

FO

Un-Neg

NG132

Workflow Data Server-1

Workflows

FO

Un-Neg

NG135

Workflow Catalog Server

Workflows

FO

Un-Neg

NG136

WPS Client

Workflows

FO

Un-Neg

 — 

 — 

 — 

 — 

 — 

NG010

CITE ER

Compliance

COT

Un-Neg

NG137

CITE NSG WFS Suite

Compliance

COT

Un-Neg

NG138

CITE NSG WMTS Suite

Compliance

COT

Un-Neg

Appendix A: Management Requirements

A.1. Initiative Activities and Roles

A.1.1. Roles

The roles generally played in any OCG Interoperability Program initiative are defined in the OGC Interoperability Program (05-127r8). The following role definitions are derived from that document with added detail to clarify how the roles will be played in this particular testbed initiative.

  • Sponsors are OGC member organizations that contribute financial resources in support of the testbed. They drive testbed requirements, technical scope & agenda, and demonstration form & content. Sponsor Representatives are assigned by the Sponsor to represent the Sponsor’s interests and position to OGC throughout the testbed duration.

  • Participants are OGC member organizations that contribute to the definition of interfaces, prototypical implementations, and other engineering support for testbed. Participants typically commit to making a substantial in-kind contribution to an initiative. Participants will be represented in the testbed by assigned business and technical representatives.

  • Observers are OGC member organizations that have agreed to the initiative’s intellectual property requirements. Observers do not have a vote in an initiative, but they are afforded the privilege of access to initiative email lists, web sites and periodic initiative-wide teleconferences. Observers may make recommendations and comments to the participants via any of these forums. The Initiative Manager has the authority to table any comments, recommendations or other discussions raised by observers at any point without prior warning. Failure of an observer to comply may result in suspension of privileges.

  • The IP Team is the engineering and management team that will oversee and coordinate the initiative. This team is comprised of OGC staff, representatives from member organizations, and OGC consultants. It facilitates architectural discussions, synopsizes technology threads, and supports the specification editorial process.

The IP Team for this testbed will include an Initiative Manager, an Initiative Architect, and multiple thread architects. Unless otherwise stated, the Initiative Manager will serve as the OGC primary point of contact ("OGC POC").

The thread architects will work with the IP Team, other thread Participants, and Sponsors to ensure that testbed work (activities and deliverables) is properly assigned and performed. The thread architects are responsible for work and schedule control, as well as for within-thread communication. They will also provide timely notice to the full IP Team on important issues or risks that could impact initiative success.

A.1.2. Activities

Testbed program management activity requirements on Bidders and Participants are presented below. These requirements govern what obligations Bidders must meet to properly propose and what obligations selected Participants must meet to properly perform during testbed execution. The order of topics roughly parallels the Master Schedule.

In general, these requirements are expressed as various technical activities that may be proposed in a bid. Additional activities may be considered during bid evaluation based on cost (i.e., in-kind vs. cost-share) and the extent to which the proposed activity meets testbed requirements and conforms to the testbed architecture. However, Bidders are advised to avoid attempts to use the testbed as a platform for introducing new requirements not included in the Summary of Testbed Deliverables.

In the material that follows, the term "activity" describes work to be performed and "deliverable" describes work to be memorialized and delivered for inspetion and use. This appendix focuses primarily on activities, while the Summary of Testbed Deliverables focuses on deliverables.

In the requirements listed below, bold italic text indicates that the work described is mandatory. Just as a Bidder is not required to propose all deliverables in the Summary of Testbed Deliverables, a Bidder is not required to propose to perform all listed activities. For example, a Bidder that is already a member of the OGC should forego the activity of submitting a membership application with its proposal. Some activities are absolutely required, however, and a Bidder has no choice but to propose performing it. For example, every Bidder must use the supplied templates in its proposal.

A.2. Proposal Development Requirements

The following requirements apply to the proposal development process and activities.

  • Selected Participants must be OGC members. Any Bidder who is not already a member of the OGC must submit an application for membership with its proposal.

  • Bidders should identify any relationships between the proposed work and relevant OGC standards.

  • Bidders should identify any relationships between the proposed work and related international standards (including specific sections) being developed by ISO, OASIS, IEEE, IETF, IAI or other standards development organizations.

  • No work facilities will be provided by OGC. Selected Participants will perform all awarded work at their own facilities. Some work, particularly servers in Technology Integration Experiments ("TIEs", sometimes also referred to as Technical Interoperability Experiments), will require Participants to provide access via the public Internet.

  • Proposals may address selected portions of the testbed requirements and architecture as long as the solution ultimately fits into the overall testbed architecture.

  • A single proposal may address requirements arising from multiple threads. To ensure that all work items in the Summary of Testbed Deliverables are delivered, the OGC may negotiate with individual Bidders to drop, add, or modify some of the proposed work.

  • Bidders proposing to build interoperable components must be prepared to test and demonstrate interoperability with components supplied by other Participants.

  • Components proposed as in-kind contributions should be publicly or commercially available products or services or prototype/pre-release versions intended to be made available. Exceptions may include products/services which are internally used by government/sponsor agencies.

  • Participants selected to implement component deliverables must participate in the full course of interface and component development, TIEs, and demonstration support activities throughout the initiative. Participants selected to edit and/or author document deliverables that depend on these implemented components must also participate in the full course of activities throughout the initiative.

  • Bidders are welcome to suggest alternatives to the initial testbed architecture. However, it should be noted that proposals will be selected on the basis of how successfully the various components from all Participants interoperate. A radically divergent architecture that would require intensive rework on the part of a significant number of other Participants would have to be supported by rationale showing a substantial benefit-to-cost ratio. In such a case, advance coordination with other potential Participants to present a coherent, realistic, and reasonable approach acceptable to all involved Participants could improve the likelihood of acceptance.

  • In general, a proposed component deliverable that has earned OGC Certification will be evaluated more favorably than one which has not.

  • All Bidders must use the supplied templates in their proposals. All Selected Participants receiving cost-sharing funding must send at least one technical representative to the Kickoff Workshop. Participants providing only in-kind contributions may forego this requirement with prior permission. Participants are also encouraged to send at least one technical representative to the Demonstration event.

A.3. Proposal Evaluation Process

Proposal evaluation criteria are listed in the main body of this document. Several steps conducted solely by the IP Team are presented below to aid readers in understanding the overall process. The IP Team and Sponsors will begin reviewing proposals soon after the proposal submission deadline. During this analysis, the IP Team may need to contact Bidders to obtain clarifications and better understand what is being proposed.

A.3.1. IP Team Review of Proposals

Each review will commence by analyzing the proposed deliverables in the context of the Summary of Testbed Deliverables, examining viability in light of the requirements and assessing feasibility against the use cases. The review team will analyze (1) proposed specification refinement or development and (2) proposed testing methodologies.

The IP Team will take the opportunity to potentially modify the testbed architecture in light of new ideas tentatively selected Proposals. Any candidate interface or protocol specification received from a Bidder will be added to the architecture and presented at the Kickoff.

The IP Team will also create a draft demonstration concept explaining how the tentatively selected software components will work together in a demonstration context. It will also identify any remaining gaps. The demonstration concept might include references to existing and emerging resources on OGC Network, including those expected to be under development in this testbed. Testbed execution will eventually culminate in one or more Demonstrations, which could be a combination of virtual and physical events (depending on Sponsor constraints and preferences).

A.3.2. Decision Technical Evaluation Meeting I

At the Decision Technical Evaluation Meeting I (TEM I), the IP Team will present Sponsors with the updated testbed architecture and demonstration concept, along with the proposed program management approach. The team will also present draft recommendations regarding which parts of which proposals should be offered cost-sharing funding (and at what level). Sponsors will decide whether and how draft recommendations in all these areas should be modified.

A.3.3. Initial Notification of Potential Participants

Immediately following TEM I, the IP Team will begin to notify Bidders of their selection to enter negotiations for potentially becoming Participants. Selected Bidders must be available for these contacts to be made to enable confirmation of continued interest.

A.3.4. Decision Technical Evaluation Meeting II

A Decision Technical Evaluation Meeting II (TEM II) meeting will be conducted where the IP Team will present to Sponsors the revised artifacts and Participant recommendations. In addition to confirming the modifications decided in TEM I, Sponsors will have a final opportunity to review proposed Participant recommendations.

A.3.5. Second Notification of Potential Participants

Following TEM II, the IP Team will finalize the testbed architecture, demonstration concept, and program management approach. It will also develop the SOW and full Participant Agreement (PA) for each selected Bidder and notify this organization of its selection to enter final negotiations for becoming an initiative Participant. Selected Bidders must be available for these contacts to be made to enable ongoing negotiation of each PA contract.

A.4. Kickoff Workshop Requirements

Testbed execution will commence with a Kickoff Workshop event ("Kickoff"). Refer to the Master Schedule for the target date(s). Each Participant must attend the Kickoff of any thread for which it was selected.

Prior to Kickoff, each Participant should have executed a Participation Agreement (PA) contract with OGC. Each PA will include a final description of all assigned deliverables (potentially including any mutually agreed modifications to the CFP requirements).

By the commencement of Kickoff, any Participant which has not yet executed a PA will be required to attest to its commitment to a preliminary PA Statement of Work (SOW). The PA must then be executed with OGC no later than Kickoff completion.

The Kickoff itself will address two interdependent and iterative development activities: (1) component interface and protocol definitions, and (2) demonstration scenario development. The scenarios used in the testbed will be derived from those presented in the CFP and other candidates provided by OGC and the sponsors.

Kickoff activities might include any or all of the following (note that there could be multiple iterations of interface definition and scenario development breakouts, and these may be interleaved):

  • Interface definition technical breakouts: Participants assigned to deliver components must have technical representatives in attendance to assist in the initial assessment and interaction of the interfaces. Participants assigned to work on interface definitions should consider in their analyses any use cases developed during demonstration scenario development.

  • Demonstration scenario technical breakouts: assigned Participants will begin demonstration scenario design and creation. The activity will include the development of use cases to record their decisions and to enable other Participants to explore the impact of Scenario design decisions on other parts of the testbed. Participants assigned to work on demonstration scenario development should consider in their analysis any use cases developed during interface definition activities. Participants in this activity must understand that various data sources will be proposed, and should receive consideration, as part of demonstration scenario design. The design must also account for the requirements and dependencies of the overall testbed system, including any client/tool designs, any server designs, and service interfaces.

  • Technical plenary sessions: these meetings will enable collaboration across breakout topics (e.g., Participants working on interface definitions can interact with those working on demonstration scenario development).

One of the Kickoff work products will be a development schedule that includes more detailed milestones for subsequent activities.

A.5. Communication and Reporting Requirements

A.5.1. Participant Points of Contact

Each selected Participant, regardless of any teaming arrangement, must designate a primary point of contact ("Primary POC") who shall remain available throughout testbed execution for communications regarding status. The POC must identify at least one alternative point of contact to support the Primary POC as needed. The POCs shall provide contact information including their e-mail addresses and phone numbers.

All proposals must include a statement attesting to the POCs’ understanding and acceptance of the duties described herein.

A.5.2. Kickoff Status Report

Selected Participants must provide a one-time Kickoff status report that includes a list of personnel assigned to support the initiative. This report must be submitted in electronic form to the testbed Initiative Manager no later than the last day of the Kickoff event.

A.5.3. Monthly Progress Reporting

Participant business/contract representatives are required (per a term in the Participation Agreement contract) to report the progress and status of the Participant’s work. Detailed requirements for this reporting will be provided during contract negotiation. Initiative accounting requirements (e.g., invoicing) will also be described in the contract.

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 Participant must submit (1) a Monthly Technical Report and (2) a Monthly Business Report by the 3rd of the following month (or the first working day thereafter).

Any Participant who has a reliable forecast of what will take place in the remaining days of any particular reported month may submit its report early and subsequently report any urgent, last-minute updates to the Initiative Manager via a follow-on email.

The purpose of these reports is to provide initiative management with high-quality, summary-level indicators of project technical and financial performance from the perspective of each Participant. Templates for both of these report types will be provided.

The IP Team may also provide an occasional status report to an OGC governance body such as the Technical Committee or Planning Committee. Participants may be invited to present preliminary findings in these reports.

The IP Team will review action item status on a weekly basis with assigned Participants, who must be available for these contacts to be made.

A.5.4. Regular and Ad Hoc Web Meetings and Teleconferences

At least one of the Participants POCs must be available for both regularly scheduled and ad hoc teleconferences for each thread in which it is participating.

In particular, weekly (biweekly at IP Team discretion) thread telecons will be conducted and recorded in minutes posted on the portal. These meetings are intended to accelerate understanding and action regarding relevant testbed activities, particularly Participant work assignments and responses to requests for additional status by the IP Team.

In addition to the Participant POC, a knowledgeable Participant or Sponsor engineer who has been (or will be) working on an activity to be discussed on a telecon could also be a valuable attendee. Such individuals would have to either be a Participant or Sponsor employee, or must have signed a testbed Observer Agreement before they would be permitted to join the telecon.

A.5.5. Email Correspondence and Wiki Collaboration

At least one of the Participants POCs must be available to participate in specification and prototype component development via the testbed email lists and wiki website.

A.5.6. Action Item Status Reporting

At least one of the Participants POCs must be available to report the status of assigned Participant actions to the relevant thread architect.

A.5.7. Communication Tools

The following tools will be implemented for use during the testbed:

  • A testbed-wide email list reflector, primarily for non-technical communication and accessible via the email address

  • A thread email reflector for each testbed thread, primarily for technical discussions. The reflectors are not intended for exchanging files. Instead, the Portal should be used to upload files, followed by notification via reflector to others

  • A public project web site

  • A Wiki sites for collaboration

  • Web meeting tools such as GoToMeeting, and teleconferences

  • The OGC web-based Portal with modules for calendaring, contact lists, file upload (with version control), timeline, action items, and meeting scheduling

A.6. Requirements for Proposing Technical Activities

Each work item in a labor funding request or in-kind labor contribution declaration (1) must identify the particular Deliverable from the Summary of Testbed Deliverables to which the work item applies and (2) must identify the particular Technical Activity Type for the proposed activity to perform the work item. The mandatory narrative and financial response templates will assist Bidders in meeting these requirements.

An extended outline of predefined Technical Activity Types is provided below. Each work item that a Bidder proposes or declares must either match (approximately) one of these types or provide an explanation and justification for why the proposed work item does not match anything from the list.

Adopting predefined activity types will help maintain consistency across Participants during testbed execution.

Under the testbed’s rapid pace, exposed issues can drive requirements for subsequent rounds of specification refinement, coding, and test. Guided by the thread architect, each cycle will proceed incrementally but rapidly, with focus on a bounded scope at each turn of the cycle. Periods of development will be followed by periods of synchronization between various component developers, enabling issue resolution before divergence can occur between the various components that must interoperate.

A.6.1. Specification Development Activity Types

This type of activity would define and develop models, schemas, encodings, and/or interfaces necessary to realize the testbed architecture. This type of activity may include coordination with the OGC Standards Program. Particular Specification Development Activity Types that may be specified in the Proposal include the following:

  • Model Development: representing a service, interface, operation, message, or encoding that is being developed for the initiative

  • Schema Development: specifying a representation of a model as an XML Schema that is being developed for the initiative

  • Encoding Development: specifying an encoding that is being developed for the initiative

  • Interface Development: specifying operations, encodings or messages that are being developed for the initiative_

  • Standards Program Coordination: submitting Engineering Reports (ERs) developed in the testbed to the OGC Technical Committee for review and presenting reports to relevant OGC TC groups and working with members to resolve issues that the members may raise with regard to the ER

A.6.2. Component Development Activity Types

This type of activity would develop prototype interoperable software components based on draft candidate implementation specifications or adopted specifications necessary to realize the testbed architecture. Particular Component Development Activity Types that may be specified in the Proposal include the following:

  • Prototype Server Software Development: development of new server software or modification of existing server software to exercise the interfaces developed under Specification Development activities. Selected Participants must be able to demonstrate operation to Sponsors for review and input during the initiative and must make their findings available (to editors) for inclusion in any relevant ERs in the same work package. (Note that the development of prototype server software intended primarily for use in the OGC Compliance Program would fall under one of the Compliance Test Development Activity Types (described below).

  • Prototype Client Software Development: development of new client software or modification of existing client software to exercise the servers being developed. Participants who develop server software must also develop client software (or make arrangements with other Participants to utilize their client software) to exercise this server software during the course of the initiative. Use of another Participant’s client is subject to approval by the IP Team to ensure that the third-party client is appropriate for exercising the functionality of the relevant server.

  • Special Adaptations: adaptations of client or server software to exercise relevant mainstream IT technology and standards such as PKI and e-commerce technologies.

A.7. Testing and Integration Activity Types

This type of activity would integrate, document, and test functioning interoperable components that execute operational elements, assigned tasks, and information flows required to fulfill a set of testbed requirements. Particular Testing and Integration Activity Types that may be specified in the Proposal include the following:

  • Component Interface Tests: Participants selected to deploy any testbed components must conduct one or more formal TIEs that exercise each server and client component’s ability to properly implement the interfaces, operations, encodings, and messages developed during the testbed. Multiple TIEs and multiple iterations of a particular TIE will be conducted during the testbed.

  • Test Result Analysis: Participants required to participate in TIEs must report the outcomes and relevant software reporting messages to the IP Team and in Monthly Technical Reports.

  • Configuration Management: communication of the location (URLs) of the server and other components, provision of any updates about the location and operational status of the components, and provision of information about the interface implemented by the servers.

A.7.1. Solution Transfer Activity Types

This type of activity would prepare prototype interoperable components to enable them to be assembled at another site. Particular Solution Transfer Activity Types that may be specified in the Proposal include the following:

  • Software Installation: Participants implementing testbed components may provide a licensed copy of testbed-relevant software components or data for integration onto the OGC Network. This could be accomplished by making the software components available from an open site on their network OR by installing it (and ensuring stability) on a sponsor or other host machine on the OGC Network. If the latter option is taken, then the Participant must provide a technical representative to support installation of the software components.

    • Virtualization and Containerization: Participants implementing testbed components may optionally package and distribute these components using virtual machines (VMs) or containers. The purpose of this option is to experiment with these technologies and provide recommendations for their potential use in future initiatives.

A.7.2. Demonstration Activity Types

The testbed Demonstration will build upon the initiative characteristics developed during Kickoff demonstration scenario design and creation discussions. The goal is for Participants to build and implement prototypes that clearly demonstrate the capabilities of the components by exercising Sponsor scenarios. All Demonstration assets (e.g., video recordings) must delivered to OGC where these assets will be available to Sponsors via the Internet, either for presentation purposes, or for use in their internal labs.

Demonstration activities (instances of the Activity Types listed below) would define, develop, and deploy functioning interoperable components that execute operational elements, assigned tasks, and information flows required to fulfill a set of testbed requirements. In contrast to Testing and Integration activities, Demonstration activities are intended primarily to support demonstration of enabled end-user capabilities. Particular Demonstration Activity Types that may be specified in the Proposal include the following:

  • Demonstration Use Case Development: provision of a technical representative to develop or support the development of use cases that define and explain the utility of the interfaces and encodings developed during the testbed. These use cases will be used to provide a basis for Demonstration storyboards and for the Demonstration itself.

  • Demonstration Storyboard Development: provision of a technical representative to develop or support the development of the storyboards that will define the structure and content of the Demonstration.

  • Demonstration Preparation and Delivery: Participants selected to deploy any testbed components must provide a technical representative to develop or support the development of the Demonstration that will exercise the functionality of the interfaces developed during the testbed. A representative must also be available to support the Demonstration event itself. Participants must perform four sub-activities: design, build, and test the Participant’s demonstrated components, and then package these for public sharing. This activity could also include the identification of other relevant data providers and incorporation of their data sources.

  • Assurance of One Year of Availability: Participants selected to deploy any server testbed component must maintain this software and make the service endpoint available to OGC for a period of no less than one year after the completion of the first Demonstration. Some sponsors may be willing to entertain exceptions to this requirement on a case-by-case basis.

A.7.3. Documentation Activity Types

This type of activity would ensure development and maintenance of the pre-specification, pre-conformant interoperable OGC technologies (including draft and final Engineering Reports) and the system-level documentation (sample user documentation, etc.) necessary to execute the testbed. This type of activity may include coordination with the OGC Standards Program.

Important The three requirements described in the first bullet below are substantially different from those in prior testbeds. These requirements should be examined carefully and included in any bid proposing document deliverables such as ERs.

Particular Documentation Activity Types that may be specified in the Proposal include the following:

  • Engineering Report Development: Participants selected to perform engineering report development must provide a technical representative to serve as editor of, or contributing author to the relevant Engineering Report (ER) (or subsection thereof). ER editors will be required to carry out three additional activities in this testbed:

    1. To consult the most relevant SWG/DWG regarding its current status and latest discussions on the ER subject matter

    2. To join the relevant email list to observe ongoing WG discussions, and

    3. To provide language in the initial ER describing how the testbed work aligns with WG discussions.

  • ERs must also include all relevant items from the following list as applicable:

    • Findings

    • Recommendations

    • Change Request(s)

    • Use Case(s)

    • Architectural Overview

    • Relevant UML Model(s)

    • XML Schema Document(s)

    • Abstract Test Suite(s)

  • Independent Change Request Development (not included as part of an ER): Participants selected to perform independent change request development (not included as part of an ER) must provide a technical representative to serve as editor of, reviewer of, or contributor to the relevant Change Request (CR) to an existing OGC standard. All developed CRs must be entered into the CR system at http://ogc.standardstracker.org/.

  • Independent Use Case Development (not included as part of an ER): Participants selected to deploy any (server or client) testbed components must provide a technical representative to develop use cases to show the functionality of their software components in the context of the testbed architecture.

  • Independent Architectural Overview Development (not included as part of an ER): Participants selected to deploy any (server or client) testbed components must provide a technical representative to develop an architectural overview of their software components as relevant to the testbed architecture.

  • System Configuration Development: Participants selected to deploy any testbed components to be installed at sponsor or other host sites connected to the OGC Network must provide a technical representative to develop a detailed document describing the combined environment of hardware and software components that compose their contribution to the testbed.

  • Installation Guide Development: Participants selected to deploy any testbed components to be installed at sponsor or other host sites connected to the OGC Network must provide a technical representative to develop an installation guide for their software components.

  • Training Material & User Guide: Participants selected to deploy any testbed components to be installed at sponsor or other host sites connected to the OGC Network must provide a technical representative to develop a User Guide and Training Materials pertaining to their software components developed or modified for the testbed.

A.8. Compliance Test Development Activity Types

This type of activity involves the development of draft compliance test guidelines (at a minimum) and test suites for engineering specifications detailed in Engineering Reports. This type of activity would likely include coordination with the OGC Compliance Program. Particular Compliance Test Development Activity Types that may be specified in the Proposal include the following:

  • Summarization of TIEs, Demo Results, and Data Issues: provision of a summary of information detailing progress pertaining to the implementation of the interface by including TIE results, lessons-learned from the demo, and particular data issues.

  • Full Compliance Test: provision of an outline of all of the necessary information to conduct a valid compliance test of the interface, including the sub-activities below.

    • Compliance Test Cases: provision of an outline of a valid compliance tests for the software component, including identification of all required and optional server requests in the interface, the acceptable results for testing servers, the syntax checks to perform for testing client requests, an explanation of an acceptable verification of the results (machine, human, etc.), a list of expected/valid warnings or exceptions to interface behavior, and a matrix of test dependencies and explanation of ordering tests appropriately for inherent tests and dependencies.

    • Compliance Test Data: identification of appropriate data sets for use in conducting a compliance test for an interface(server or client) or encoding.

    • Compliance Test Recommendations: documentation of recommendations to resolve issues with the current state of the interface or with the compliance tests. For candidate specifications, this documentation must, at a minimum, consist of test guidelines that would form the basis for development of more detailed and complete test scripts as the specification matures toward an approved specification. For mature candidate specifications, Participants must evolve existing or prepare test scripts to form a complete set of tests to fully test an implementation of a specification for compliance with its requirements. This documentation must be embodied in an Engineering Report as well as any GitHub repository that exists for a particular standard.

Appendix B: Technical Architecture

B.1. Introduction

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

Each thread aggregates a number of requirements, work items and corresponding deliverables, which are funded by different sponsors. The work items are organized in work packages that correspond to one or more related requirements. The work packages have then been assigned to 6 Threads:

  • Thread 1: Dynamic Source Integration (DSI)

  • Thread 2: Earth Observation Clouds (EOC)

  • Thread 3: Cross Community Interoperability (CCI)

  • Thread 4: Field Operations (FO)

  • Thread 5: Streaming & 3D Data (S3D)

  • Thread 6: Compliance Testing (COT)

B.2. Testbed Baseline

B.2.1. Types of Deliverables

The OGC Testbed 12 threads require several types of deliverables. It is emphasized that deliverable indications "funded" or "unfunded" in this Annex B are informative only. Please be referred to Testbed-13 CFP Main Body for binding definitions and make sure your deliverables are made available after the final demonstration of the testbed according to the requirements defined in section Annex A: Solution Transfer Activity and Demonstration Activity.

Documents

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 OGC Portal Pending Documents list 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 and OGC Standard Working Group or Domain Working Groups for consideration. It is emphasized that participants delivering engineering reports must also deliver Change Requests that arise from the documented work.

Implementations

Services, Clients, Datasets and Tools will be provided by methods suitable to its type and stated requirements. For example, services and components (e.g. a WFS instance) are delivered by deployment of the service or component for use in the testbed via an accessible URL. A Client software application or component may be used during the testbed to exercise services and components to test and demonstrate interoperability; however, it is most often not delivered as a license for follow-on usage. Implementations of services, clients and data instances will be developed and deployed in all threads for integration and interoperability testing in support of the agreed-up thread scenario(s) and technical architecture. The services, clients, and tools may be invoked for cross-thread scenarios in demonstration events.

B.2.2. OGC Reference Model

The OGC Reference Model (ORM) version 2.1, provides an architecture framework for the ongoing work of the OGC. Further, the ORM provides a framework for the OGC Standards Baseline. The OGC Standards Baseline consists of the member-approved Implementation/Abstract Specifications as well as for a number of candidate specifications that are currently in progress.

The structure of the ORM is based on the Reference Model for Open Distributed Processing (RM-ODP), also identified as ISO 10746. This is a multi-dimensional approach well suited to describing complex information systems.

The ORM is a living document that is revised on a regular basis to continually and accurately reflect the ongoing work of the Consortium. We encourage respondents to this RFQ to learn and understand the concepts that are presented in the ORM.

This Annex B refers to the RM-ODP approach and will provide information on some of the viewpoints, in particular the Enterprise Viewpoint, which is used here to provide the general characterization of work items in the context of the OGC Standards portfolio and standardization process, i.e. the enterprise perspective from an OGC insider.

The Information Viewpoint considers the information models and encodings that will make up the content of the services and exchanges to be extended or developed to support this testbed. Here, we mainly refer to the OGC Standards Baseline, see section Standards Baseline.

The Computational Viewpoint is concerned with the functional decomposition of the system into a set of objects that interact at interfaces – enabling system distribution. It captures component and interface details without regard to distribution and describes an interaction framework including application objects, service support objects and infrastructure objects. The development of the computational viewpoint models is one of the first tasks of the testbed, usually addressed at the kick-off meeting.

rmodp

Figure 2. Reference Model for Open Distributed Computing

The Engineering Viewpoint is concerned with the infrastructure required to support system distribution. It focuses on the mechanisms and functions required to:

  1. support distributed interaction between objects in the system, and

  2. hides the complexities of those interactions.

It exposes the distributed nature of the system, describing the infrastructure, mechanisms and functions for object distribution, distribution transparency and constraints, bindings and interactions. The engineering viewpoint will be developed during the testbed, usually in the form of TIEs (Technical Interaction Experiments), where testbed participants define the communication infrastructure and assign elements from the computational viewpoint to physical machines used for demonstrating the testbed results.

B.2.3. OGC Standards Baseline

The OCG Standards Baseline is the currently approved set of OGC standards and other approved supporting documents, such as the OGC abstract specifications and Best Practice Documents. OGC also maintains other documents relevant to the Interoperability Program including Engineering Reports, Discussion Papers, and White Papers.

OGC standards are technical documents that detail interfaces or encodings. Software developers use these documents to build open interfaces and encodings into their products and services. These standards are the main "products" of the Open Geospatial Consortium and have been developed by the membership to address specific interoperability challenges. Ideally, when OGC standards are implemented in products or online services by two different software engineers working independently, the resulting components plug and play, that is, they work together without further debugging. OGC standards and supporting documents are available to the public at no cost. OGC Web Services (OWS) are OGC standards created for use in World Wide Web applications. For this testbed, it is emphasized that all OGC members have access to the latest versions of all standards. If not otherwise agreed with the testbed architects, these shall be used in conjunction with - in particular - engineering reports resulting from previous testbeds.

Any documents and Schemas (xsd, xslt, etc.) that support an approved (that is, approved by the OGC membership) OGC standard can be found in the official OGC Schema Repository.

The OGC Testing Facility web page provides online executable tests for some OGC standards. The facility helps organizations better implement service interfaces, encodings and clients that adhere to OGC standards.

B.2.4. Data

All participants are encouraged to provide data that can used to implement the various scenarios that will be developed during the testbed. A number of testbed sponsors will provide data, but it might be necessary to complement these with additional data sets. Please provide detailed information if you plan to contribute data to this testbed.

B.2.5. Services in the Cloud

Participants are encouraged to provide data or services hosted in the cloud. There is an overarching work item to provide cloud-hosting capabilities to al- low thread participants to move services and/or data to the cloud.

B.3. Testbed Threads

Testbed-13 is organized in a number of threads. Each thread combines a number of work packages 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. The following figures illustrates the allocation of work packages to threads.