1. Introduction

The Open Geospatial Consortium (OGC®) is releasing this Call for Participation ("CFP") to solicit proposals for the OGC 3D Data Container and Tiles API Pilot (also called "Pilot"). The goal of this Pilot is to explore an integrated suite of draft specifications for 2D and 3D tiled geospatial resources. This suite will support smooth transitions between 2D and 3D environments, allow applications working with 2D tiled resources to get 3D tiled resources and enable 3D tile bounding volumes to support multiple data containers. These requirements recognize 2D tile resources are often provided in regular grids, while 3D tile resources may be provided in variable grids.

pilotLogo

To achieve these goals, the OGC 3D Data Container and Tiles API Pilot will develop a draft API (OGC API - Tiles-3D) that is compatible with the OGC API group of standards and candidate standards and which allows access to attributed 3D geospatial resources and a corresponding data container format for (streamed) data delivery compatible with glTF. Both work items should be embedded in the context of existing OGC work on 2D and 3D tiled geospatial resources.

The Sponsor is interested in developing an OGC API - Tiles-3D that defines query options for retrieving 3D tiled resources in a manner independent of the underlying data store. 3D tiled resources are inclusive of feature geometries, feature attribute values, and texture data. The OGC Tiled 3D Data API should align with OGC Web API Guidelines and support multiple 3D geospatial standards included in the OGC portfolio, such as 3D Tiles, I3S, CDB, and CityGML.

The Pilot funds a number of server and client component implementations to test the OGC API - Tiles-3D and data container format. Further work items include an analysis of characteristics and capabilities of the new API in comparison with existing or emerging 2D standards. Section Evaluation Aspects defines a non-exhaustive list of aspects that shall be subject of the analysis.

1.1. Background

OGC Testbed activities in Testbed-13, Testbed-14, and the ongoing Testbed-15, together with OGC Innovation Program Pilot activities such as Vector Tiles Pilot Phase 1+2, have developed a series of Engineering Reports that outline possible future OGC standardization efforts in the context of 3D and 2D tiled geospatial resource handling.

In addition, specifications dealing with 3D data, such as the OGC Community standards 3D Tiles and I3S, have been developed outside of the OGC community. In the future, 2D and 3D content will be integrated and available through a set of standards that allow smooth transitions between 2D and 3D data. It is the overall goal of this Pilot to develop the first milestone towards this vision.

At the same time, significant progress towards Web-oriented interfaces has been made in the OGC with the (partly emerging) OGC APIs: -Features, -Tiles, -Styles, -Maps, -Images, -Routing, -Coverages, and -Processes. All of these APIs are built on the OpenAPI framework. These developments represent a major evolution from the established Service Oriented Architecture (SOA) paradigm that, until recently, was the methodology of web-oriented interface that OGC championed. The OGC 3D Data Container and Tiles API Pilot will take these developments into account as well.

1.2. OGC Innovation Program Initiative

This Pilot is being conducted under the OGC Innovation Program. The OGC Innovation Program provides a collaborative agile process for solving geospatial challenges. Organizations (sponsors and technology implementers) come together to solve problems, produce prototypes, develop demonstrations, provide best practices, and advance the future of standards. Since 1999 more than 120 initiatives have been conducted.

1.3. Benefits of Participation

This Pilot provides a unique opportunity towards advancing solutions that realize a smooth 3D and 2D tiled geospatial resource environment based on open standards. The focus of this Pilot is on the exchange and visualization of 3D tiled geospatial resources using open standards from the context of both existing and emerging 3D and 2D standards. Participants become part of the standards development process and influence future standard design and content for 3D tiled geospatial resource access and management in distributed Web environments. Participants can optimize their products for 3D resource handling both on the client and the server side. Participants can interact with sponsoring organizations and explore their products in multi-vendor environments to test interoperability between the various components.

This Pilot addresses a number of technical challenges and interoperability issues, such as web-ready tile data containers and access and management of web APIs optimized for rendering and streaming, compression for mesh-data exchanged in tile-payloads and efficient handling of both attribute streams and geometry buffers, integration of hierarchical level-of-detail approaches with 2D tile concepts and support for multiple Coordinate Reference Systems (CRSs), general alignment between 3D spaces and 2D tiled geospatial resources solutions, and many other challenges and/or issues.

In today’s landscape of rich 3D and 2D geospatial content, different technologies are intersecting (e.g., Tiles-3D and OpenAPI, glTF and WebGL, clouds and dynamically deployed hosted services). Participants have the opportunity to be part of the dialogue with other participants and sponsors. The initiative enables the opportunity to advance participant’s applications. It creates new business opportunities while exploring the market readiness of the technologies used in the initiative.

The outcomes are expected to advance open standard approaches for delivering 3D content using state of the art interface models and description languages based on the OpenAPI framework; and a data container optimized for streaming and rendering. The sponsorship supports this vision with cost-sharing funds to partially offset the costs associated with development, engineering, and demonstration activities that are part of this Pilot. The cost-sharing offers selected participants a unique opportunity to recoup a portion of their initiative expenses.

1.4. Master Schedule

The following table details the major Initiative milestones and events. Dates are subject to change.

Table 1. Master schedule
Milestone Date Activity

M01

24 October 2019

Release of Call for Participation (CFP)

M02

09 December 2019

Responses due

M03

20 December 2019

Participant selection and agreements

M04

7 January 2020

Virtual Kick-off meeting

M05

31 March 2020

Draft Recommendations for Tiles-3D Container

M06

31 March 2020

Draft Recommendations for OGC API - Tiles-3D

M07

30 June 2020

TIEs Completed

M08

30 June 2020

Draft Engineering Report(s)

M09

8-9 June TC 2020

Final demonstration of results (attendance recommended but not required)

M10

30 June 2020

Documentation and Engineering Report(s) due

M11

15 July 2020

Participant(s) Summary Report(s) due

2. Technical Architecture

This section provides the draft technical architecture and identifies all requirements and corresponding work items. It references the OGC Standards Baseline, i.e., the complete set of member approved Abstract Specifications, Standards including Profiles and Extensions, and Community Standards. Further information on the OGC standards baseline can be found online.

In light of the existing OGC 2D and 3D tiled geospatial resources work, this Pilot shall develop OGC APIs to support transitions between 2D and 3D environments, allow applications working with 2D tiled resources to get 3D tiled resources and enable 3D tile bounding volumes to support a corresponding tile content model (a.k.a. 3D data container). In this context, it is emphasized that emerging standards, draft specifications, as well as Community standards such as 3D Tiles and I3S shall serve as baselines that may be adopted with or without changes.

The overall goal of this initiative is to design, implement, and test a 2D/3D environment that allows smooth integration of both 2D tiled and 3D tiled geospatial data. Significant work has been conducted in independent efforts for 2D as well as for 3D tiled geospatial resources. These efforts shall be considered in this Pilot with a 3D tiled geospatial resources focus.

2.1. Architecture Components and Requirements

The OGC 3D Data Container and Tiles API Pilot architecture consists of a set of server instances providing 3D and 2D tiled geospatial resources. These servers interact with a set of client applications that can render and possibly analyze (streamed) 3D and 2D data. These components, APIs and encodings include:

componentsOverview
Figure 1. OGC 3D Data Container and Tiles API Pilot architecture components
  1. CLIENTS - Client application running in a Web browser or desktop application that can query, render, and potentially analyze the tiled 3D resources served by the 3D Server via the OGC API - Tiles-3D. Ideally, clients access and visualize 2D tiled geospatial resources as well. Clients shall support the 3D Data Container format.

  2. OGC API - Tiles-3D - Web API for tiled 3D resources that is consistent with the emerging OGC API family of standards. This document shall use the OpenAPI 3.0 framework to specify the building blocks of the API. Examples shall be made available via SwaggerHub.

  3. 3D SERVER - Server side implementation of OGC API - Tiles-3D and 3D Data Container.

  4. OGC API - MAPS AND TILES - Web API for 2D Tile resources that is consistent with the emerging OGC API family of standards (specifically OGC API – Tiles). Depending on available resources, the current draft OGC API Maps and Tiles as developed in Testbed-15 may be used without changes. This document shall use the OpenAPI 3.0 framework to specify the building blocks of the API. Examples shall be made available via Swagger Hub.

  5. 2D SERVER - Server side implementation of OGC API - 2D Tiles. Ideally, this server supports 3D data as well.

  6. 3D and 2D DATA - 3D and 2D data made available by the sponsor or by participants to be used in this initiative. The exact type and content will be discussed and mutually agreed upon by the sponsors and participants at the kick-off meeting.

2.1.1. Requirements for 3D Data Container

The following requirements have been identified for the 3D Data Container. The Data Container shall:

  1. Represent features with both geo-located geometry and polygon-level attribution to describe the features.

  2. Support multiple resolutions of geospatial data, from worldwide representation to dense urban environments.

  3. Be optimized for ingestion and processing by computer software in distributed environments.

  4. Support a World Geodetic System (WGS) 1984 (EPSG:4979) geographic coordinate reference system.

  5. Be able to store well-formed 3D data.

  6. Be capable of providing information for use by:

    1. Computational queries such as line of sight tracing, path planning, or destructivity / deformation of features;

    2. Mission Command Information Systems (MCIS) capable of representing content in a layered approach;

    3. Visual simulations designed for rendering scenes, such as a globe representation or flight simulator; and

    4. Constructive simulations that require significant information at the polygon-level of the environment to support the full range of physics and simulation reasoning.

2.1.2. Requirements OGC API - Tiles-3D

The following requirements have been identified for the OGC API - Tiles-3D. The API shall:

  1. Provide API access to tiled 3D resources.

  2. Allow exchange of content compliant with the 3D Data Container developed in this Pilot.

  3. Align with existing and emerging OGC APIs, standards, and candidate standards (e.g. OGC API - Features and OGC API - Common).

2.2. Previous Work

This Pilot builds on previous work from other OGC Innovation Program initiatives as well as OGC Standards Program efforts. The following documents serve as foundational references for this Pilot activity. Some items listed below are not yet released to the public. Draft versions of these documents have been made available. The final versions of these documents may change from the currently provided versions. Participants are advised to check the OGC website for updates on these documents.

  • Tiles-3D Community Standard - 3D Tiles Community Standard 1.0 (18-053r2) - An OGC standard for streaming and rendering massive 3D geospatial content such as Photogrammetry, 3D Buildings, BIM/CAD, Instanced Features, and Point Clouds. The standard defines a hierarchical data structure and a set of tile formats which deliver renderable content. Of specific interest to this initiative is glTF. The standard document also describes 3D Tile Styles, a declarative styling specification which may be applied to tilesets.

  • I3S Community Standard - OGC Indexed 3d Scene Layer (I3S) and Scene Layer Package Format Specification (OGC 17-014r5) - An OGC Community standard which provides the delivery format and persistence model for Scene Layers. A Scene Layer is a container for arbitrarily large amounts of heterogeneously distributed 3D geographic content, supporting coordinate reference systems and height models in conjunction with a rich set of layer types.

  • Testbed 13 Engineering Report - OGC Testbed-13: 3D Tiles and I3S Interoperability and Performance Engineering Report (OGC 17-046) - The report captures the lessons learned from prototyping interoperability of 3D Tiles and I3S using: a 3D Portrayal Service, performance studies of 3D tiling algorithms, and a proof-of-concept of the use of 3D Tiles and I3S as data delivery formats for the OGC 3D Portrayal Service interface standard.

  • 3D Portrayal Service Standard - OGC 3D Portrayal Service 1.0 Standard (OGC 15-001r4) - The OGC standard specifies how geospatial 3D content is described, selected, and delivered. The standard provides a framework to determine whether 3D content is interoperable at the content representation level.

  • OpenAPI (v3.0) - OpenAPI is a freely-available API description framework that provides a developer with programmatic access to a software application or service. These APIs use sets of technologies that enable websites and/or client applications to interact with each other by using REST, SOAP, JavaScript, and other web technologies. These APIs have allowed web communities to create an open architecture for sharing content and data between communities and applications. A very typical application for an Open API is to access data: Tweets, geolocation(s), maps, stock quotes, weather sensors, and so forth.

    OGC members and staff have actively been investigating OpenAPI (and its commercial equivalent, Swagger) since 2016. It was recognized that the existing web service standards were in effect web APIs, but that modernizing their means of providing content to the web required a fundamental change in underlying design. Two documents advanced further the idea: 1) the OGC Open Geospatial APIs White Paper and the Spatial Data on the Web Best Practices, jointly developed by OGC and W3C. These documents highlighted how geospatial data should be more native to the web. Further, OGC staff were working on “implementer-friendly” views of our standards and experimented with an OpenAPI definition for the Web Map Tile Service (WMTS) and became aware of work by the United Kingdom Hydrographic Office (UKHO) to publish OpenAPI definitions for OGC Web Map Service (WMS) of Electronic Navigational Charts.

  • OGC API Features - The OGC API - Features - Part 1: Core provides API building blocks to create, modify and query features on the Web. This standard specifies the fundamental API building blocks for interacting with features. The spatial data community uses the term 'feature' for things in the real world that are of interest. The standard is part of the OGC API family of standards. OGC API standards define modular API building blocks to spatially enable Web APIs in a consistent way.

    Most recently, the OGC Web Feature Service (WFS) and Filter Encoding Service (FES) Standards Working Group rebuilt the WFS standard to the new OGC API - Features standard with an integrated OpenAPI definition as core to describe how to build against the standard. The results are being taken by others working to advance other OGC standards as OpenAPI definitions. This work can be reviewed on the OGC API - Features standard webpage.

  • OGC API - Maps & Tiles Engineering Report (draft) - The OGC API - Maps and Tiles Engineering Report has been developed as part of Testbed-15. It is not a standard, but reflects the latest work on Web APIs to access and manage maps and 2D tiled data.

  • OGC API - Styles Engineering Report (draft) - The OGC API Styles Engineering Report has been developed as part of Testbed-15. It is not a standard, but reflects the latest work done in OGC on styles for 2D data. The Styles API is a Web API that enables map servers and clients as well as visual style editors to manage and fetch styles. The API is consistent with the emerging OGC API family of standards. The API complements the Features, Maps and Tiles APIs and builds on the conceptual model for styles developed in OGC Testbed-15. This report specifies the API using OpenAPI, specifies how the same styles should be represented in a GeoPackage and documents the lessons learned during the implementation.

  • OGC API Routing Engineering Report (draft) - The OGC API Routing Engineering Report was produced by the OGC Routing Pilot. The Pilot assessed an abstract baseline suite of functions, capabilities, and encodings to address a common standard interface for network routing functionality. This includes guidance for extending the Routing API to account for various routing data models and support for network routing engine configuration via the Routing API. The OGC API - Routing is not an OGC standard, but it was delivered to the OGC Standards Program for further consideration.

2.3. Pilot Scenario

The Pilot shall implement a demonstration scenario that highlights the key features of the new OGC API - Tiles-3D and the 3D Data Container format. 3D data will be made available from the sponsor, though participants are invited to provide additional data sets. These data sets can be of any commonly used 3D data format.

2.4. 2D/3D Evaluation Aspects

There are many common aspects when dealing with 2D and 3D tiled geospatial resources, such as dealing with massive, heterogeneous and non-uniform datasets with a variety of spatial data structures. Interaction and styling of data is often performed on a per-feature level based on feature properties, attributes, or metadata.

The Pilot will further understanding of aspects needed to ensure efficient transition between 2D and 3D content. The following aspects define a non-exhaustive list of items that shall be analyzed and compared between relevant 2D and 3D specifications, APIs, and standards. Participants are invited to evaluate additional aspects. All results shall be documented in the OGC 3D Data Container and Tiles API Pilot Engineering Report.

  • File extensions and MIME types: Tiles-3D uses specific file extensions and MIME types. Usually, tile content files use the file type and MIME format specific to their tile format specification.

  • JSON encoding: All JSON based encodings apply restrictions on JSON formatting and encoding, such as the usage of UTF-8 encoding without BOM, string values using only ASCII charset, and Names (keys) within JSON objects being unique. In particular the latter aspect is of particular interest. This Pilot will identify possible overlaps and non-matching definitions used in 2D and 3D resources.

  • Styles: Styles are supported in OGC Tiles-3D. Additionally, Testbed-15 developed a web API for styles that enables map servers and clients as well as visual style editors to manage and fetch styles. The OGC Tiles-3D and the Testbed-15 developed web API approaches should be compared and homogenization paths defined.

  • URIs: Many specifications use URIs to reference tile content. These URIs may point to relative external references (RFC3986) or be data URIs that embed resources in the JSON. Embedded resources often use the "data" URI scheme (RFC2397). When the URI is relative, its base is commonly relative to the referring tileset JSON file.

  • Units of Measurement: The unit for all linear distances and angles need to be compared.

  • Coordinate reference system (CRS): OGC Tiles-3D uses a right-handed Cartesian coordinate system; that is, the cross product of x and y yields z. A tileset’s global coordinate system will often be in a WGS 84 earth-centered, earth-fixed (ECEF) reference frame, but it doesn’t have to be, e.g., a power plant may be defined fully in its local coordinate system for use with a modeling tool without a geospatial context. Further aspects of CRS complexity include tile transforms from a tile’s local coordinate system to the parent tile’s coordinate system.

  • Bounding Box/Bounding Volume: In 3D, a bounding volume defines the spatial extent enclosing a tile or a tile’s content. To support tight fitting volumes for a variety of datasets such as regularly divided terrain, cities not aligned with a line of latitude or longitude, or arbitrary point clouds, the bounding volume types often include an oriented bounding box, a bounding sphere, or a geographic region defined by minimum and maximum latitudes, longitudes, and heights. 2D approaches commonly use bounding boxes.

  • Level of Detail: In 2D, all tiles have typically the same level of detail. The situation is different for 3D data, where there are multiple hierarchical levels of detail in the same view with error matrices required to decide which tiles are displayed in which order to the client.

2.4.1. Work Items & Corresponding Deliverables

The following figure illustrates the work items and deliverables of this initiative. The Pilot is designed to fund three Engineering Report and at least three client and three server implementations. All participants are requested to contribute to the API and data container concept and API development and to provide lessons learned and implementation descriptions for the Pilot Summary Engineering Report.

deliverables
Figure 2. Deliverables of the OGC 3D Data Container and Tiles API Pilot

The following list identifies all deliverables that are part of this Pilot. Detailed requirements are stated above. All participants are required to participate in all technical discussions.

Videos

It is emphasized that each participant shall develop and deliver or participate in the production of a short video that can be used in outreach activities on a royalty-free basis. The video shall illustrate the initial challenge(s) and developed solutions. The video can be done using screen capturing of clients or slides with voice over. Good examples for videos are available from previous initiatives, such as Arctic Spatial Data Pilot (video 1, video 2), Vector Tiles Pilot (video), or Testbed-13 (video 1, video 2).

Engineering Reports

  • D001 - 3D Data Container Engineering Report - This Engineering Report will document a 3D tiled data container that fulfills all requirements stated above. This work item includes possible Change Requests against existing Standards or Community Standards, which have to be submitted via the Standards Program Standards Tracker.

  • D002 - OGC API - Tiles-3D Engineering Report - The Engineering Report defines a Web API for Tiles-3D. This API enables servers and clients to manage and fetch 3D Tile resources as described above. The document shall also include any extensions to emerging OGC APIs needed to support smooth transitions between 2D and 3D environments. The Engineering Report shall be developed in a format that allows for consideration in standardization discussions in the OGC Standards Program. Ideally, this Engineering Report is complemented by an exemplary instance on Swagger Hub.

  • D003 - Pilot Summary Engineering Report - This Engineering Report provides a summary of the main outcomes of the Pilot. Particular emphasis shall be given to the evaluation aspects documented above. In addition, it shall provide lessons learned and implementation documentation from all participants and document future work items.

Components

  • D110 - Client for 3D Data Container and Tiles API - A client that interact with Servers via the proposed OGC API - Tiles-3D and is able to consume and process the data that follows the 3D Tiled Data Container specification. Participants developing clients will capture videos and screenshots of the client interfaces interacting with Tiles-3D for demonstration purposes.

  • D112 - Client for 3D Data Container and Tiles API and 2D Tiles - A client with support for 2D and 3D data. The client shall interact with 3D Servers via the proposed OGC API - Tiles-3D and is able to consume and process the data that follows the 3D Tiled Data Container specification for 3D data. In order to support 2D data, the client shall interact with the OGC draft API – Maps and Tiles as developed by Testbed-15. Participants developing clients will capture videos and screenshots of the client interfaces interacting Servers for demonstration purposes.

  • D100 - Tiles-3D Server - Server-side implementation of the OGC API - Tiles-3D with support for the 3D Tiled Data Container specification. Bidders are requested to identify the type of data that they will support. At the kickoff meeting, sponsors and participants will agree on the data to be used in the Pilot.

  • D102 – Tiles-2D & Tiles-3D Server - Server-side implementation of the draft OGC API – Maps and Tiles. Focus of this component implementation is on extensions to emerging 2D OGC APIs needed to deliver 2D tiles and support smooth transition to 3D environments. Ideally, this server implements the OGC API - Tiles-3D with support for the 3D Tiled Data Container specification additionally. Bidders are requested to identify the type of data that they will support. At the kickoff meeting, sponsors and participants will agree on the data to be used in the Pilot.

3. Deliverables Summary & Funding Status

The following table summarizes the full set of deliverables.

Table 2. CFP Deliverables and Funding Status
ID Document / Component Funding Status

D001

ER

funded

D002

ER

funded

D003

ER

funded

D100

Component

funded

D102

Component

funded

D110

Component

funded

D112

Component

funded

4. Miscellaneous

Call for Participation

The CFP consists of stakeholder role descriptions, proposal submission instructions and evaluation criteria, a master schedule and other project management artifacts, Sponsor requirements, and an initiative architecture. The responses to this CFP should include the proposing organization’s technical solution, cost-sharing requests for funding, and proposed in-kind contributions to the initiative.

Once the original CFP has been published, ongoing authoritative updates and answers to questions can be tracked by monitoring the CFP Corrigenda Table and the CFP Clarifications Table.

Participant Selection and Agreements:

Bidders may submit questions via timely submission of email(s) to the OGC Technology Desk. Question submitters will remain anonymous and answers will be regularly compiled and published in 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.

Following the closing date for submission of proposals, OGC will evaluate received proposals, review recommendations with the Sponsor, 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.

Kick-off: The Kickoff is a virtual meeting (using GoToMeeting) where Participants, guided by the Initiative Architect, will refine the Initiative architecture and settle upon specific use cases and interface models to be used as a baseline for prototype component interoperability. Participants will be required to attend the Kickoff, including breakout sessions, and will be expected to use these breakouts to collaborate with other Participants and confirm intended Component Interface Designs.

Regular Teleconference and Interim Meetings After the Kickoff, participants will meet on a frequent basis remotely via web meetings and teleconferences.

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.

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

Final Summary Reports, Demonstration Event, and Other Stakeholder Meetings: Participant 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 and other stakeholder meetings.

Assurance of Service Availability: Participants selected to implement service components must maintain availability for a period of no less than six months after the Participant Final Summary Reports milestone. OGC might be willing to entertain exceptions to this requirement on a case-by-case basis.

Appendix A: Pilot Organization and Execution

A.1. Initiative Policies and Procedures

This initiative will be conducted under the following OGC Policies and Procedures.

A.2. Initiative Roles

The roles generally played in any OGC Innovation Program initiative include Sponsors, Bidders, Participants, Observers, and the Innovation Program Team ("IP Team"). Explanations of the roles are provided in Annex: Tips for New Bidders.

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

The Initiative Architect will work with Participants and Sponsors to ensure that Initiative activities and deliverables are properly assigned and performed. The Initiative Architect is responsible for scope and schedule control and will provide timely escalation to the Initiative Director regarding any severe issues or risks that happen to arise.

A.3. Types of Deliverables

All activities in this Pilot will result in a Deliverable. These Deliverables can take the form of Documents, Implementations, or Videos.

A.3.1. 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 (members-only) OGC Pending directory when complete and the document has achieved a satisfactory level of consensus among interested participants, contributors, and editors. Engineering Reports are the formal mechanism used to deliver results of the Innovation Program to Sponsors and to the OGC Standards Program for consideration by way of Standards Working Groups and Domain Working Groups.

A.3.2. Implementations

Services, Clients, Datasets, and Tools will be provided by methods suitable to each type and stated requirements. For example, services and components (e.g., a WPS instance) are delivered by deployment of the service or component for use in the Initiative via an accessible URL. A Client software application or component may be used during the Initiative to exercise services and components to test and demonstrate interoperability; however, the client software is most often not delivered licensed 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.

A.3.3. Videos

Each participant shall develop and deliver or participate in the production of a short video that can be used in outreach activities on a royalty-free basis. The videos will be free and clear to be placed on the OGC YouTube Channel and Project page with no restrictions. The video shall illustrate the initial challenge(s) and developed solutions. The video can be done using screen-capturing of clients or slides with voice over. Good examples for videos are available from previous initiatives, such as Arctic Spatial Data Pilot (video 1, video 2), Vector Tiles Pilot (video), or Testbed-13 (video 1, video 2).

A.4. Proposals & Proposal Evaluation

Proposals are expected to be short and precisely addressing the work items a bidder is interested in. A proposal template will be made available. The proposal, including technical and financial details, has a page limit as defined in Appendix A. Details on the proposal submission process are provided in Appendix A: Proposal Submission Guidelines. The proposal evaluation process and criteria are described below.

A.4.1. Evaluation Process

Proposals will be evaluated according to criteria based on three areas: management, technical, and cost. Each review will commence by analyzing the proposed deliverables in the context of the Sponsor priorities, examining viability in light of the requirements and assessing feasibility against the use cases.

The review team will then create a draft Initiative System Architecture from tentatively selected proposals. This architecture will include the proposed components and relate them to available hardware, software, and data. Any candidate interface and protocol specification received from a Bidder will be included.

At the Technical Evaluation Meeting (TEM), the IP Team will present Sponsors with draft versions of the initiative system architecture and 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.

Immediately following TEM, the IP Team will begin to notify Bidders of their selection to enter negotiations for potentially becoming initiative Participants. The IP Team will develop for each selected bidder a Participant Agreement (PA) and a Statement of Work (SOW).

A.4.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.

  • Willingness to share information and work in a collaborative environment.

  • Contribution toward Sponsor goals of enhancing availability of standards-based offerings in the marketplace.

A.4.3. Technical Criteria

  • How well applicable requirements in this CFP are addressed by the proposed solution.

  • Proposed solutions can be executed within available resources.

  • Proposed solutions support and promote the initiative system architecture and demonstration concept.

  • Where applicable, proposed solutions are OGC-compliant.

A.4.4. Cost Criteria

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

  • All Participants are required to provide at least some level of in-kind contribution (i.e., activities or deliverables offered that do not request 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. Participation may be fully in-kind.

A.5. Reporting

Initiative participant business/contract representatives are required (per the terms 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 Pilot participant must submit (1) a Monthly Technical Progress Report and (2) a Monthly Business Progress Report by the first working day on or after the 4th of each month. Templates for both of these report types will be provided and must be followed.

The purpose of the Monthly Business Progress Report is to provide initiative management with a quick indicator of project health from the perspective of each Pilot participant. The IP Team will review action item status on a weekly basis with the Initiative participants assigned to complete those actions. Initiative participants must be available for these contacts to be made.

Appendix B: Proposal Submission Guidelines

B.1. General Requirements

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

  • Proposals must be submitted before the appropriate response due date indicated in the Master Schedule.

  • Proposing organizations must be an OGC member and familiar with the OGC Mission, Vision, and Goals. Proposals from non-members will be considered, if a completed application for OGC membership or a letter of intent to become a member if selected for funding is submitted prior to or along with the proposal. If you are in doubt about membership, please contact OGC at techdesk@opengeospatial.org.

  • Proposals may address selected portions of the initiative requirements as long as the solution ultimately fits into the overall initiative architecture. A single proposal may address multiple requirements and deliverables. To ensure that Sponsor priorities are met, the OGC may negotiate with individual Bidders to drop, add, or change some of the proposed work.

  • Participants selected to implement component deliverables will be expected to participate in the full course of interface and component development, Technical Interoperability Experiments, and demonstration support activities throughout Initiative execution.

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

  • Participants selected as Editors will also be expected to participate in the full course of activities throughout the Initiative, documenting implementation findings and recommendations and ensuring document delivery.

  • Participants should remain aware of the fact that the Initiative components will be developed across many organizations. To maintain interoperability, each Participant should diligently adhere to the latest technical specifications so that other Participants may rely on the anticipated interfaces during the TIEs.

  • All Selected Participants (both cost-share and pure in-kind) must attend with at least one technical representative to the Kickoff. Participants are also encouraged to attend at least with one technical representative the Demonstration Event.

  • No work facilities will be provided by OGC. Each Participant will be required to perform its PA obligations at its own provided facilities and to interact remotely with other Initiative stakeholders.

  • Information submitted in response to this CFP will be accessible to OGC staff members and to Sponsor representatives. This information will remain in the control of these stakeholders and will not be used for other purposes without prior written consent of the Bidder. Once a Bidder has agreed to become an Initiative Participant, it will be required to release proposal content (excluding financial information) to all Initiative stakeholders. Commercial confidential information should not be submitted in any proposal (and, in general, should not be disclosed during Initiative execution).

  • Bidders will be selected to receive cost sharing funds on the basis of adherence to the requirements (as stated in the CFP Appendix B Technical Architecture) and the overall quality of their proposal. The general Initiative 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 executable interoperable prototype implementations that meet the stated CFP requirements, and for documenting the findings and recommendations arising from those implementations. Bidders not selected for cost sharing funds may still be able to participate by addressing the stated CFP requirements on a purely in-kind basis.

  • Bidders are advised to avoid attempts to use the Initiative as a platform for introducing new requirements not included in the 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 Initiative scope or not. Items deemed out-of-scope might still be appropriate for inclusion in a later OGC Innovation Program initiative.

  • Each Participant (including pure in-kind Participants) that is assigned to make a deliverable will be required to enter into a Participation Agreement contract ("PA") with the OGC. The reason this requirement applies to pure in-kind Participants is that other Participants will be relying upon their delivery to show component interoperability. Each PA will include a statement of work ("SOW") identifying Participant roles and responsibilities.

B.2. What to Submit

The two documents that shall be submitted, with their respective templates are as follows: 1. Technical Proposal: https://portal.opengeospatial.org/files/?artifact_id=82493 2. Cost Proposal: https://portal.opengeospatial.org/files/?artifact_id=82494

A Technical Proposal should be based on the Response Template and must include the following:

  • Cover page

  • Overview (Not to exceed one page)

  • Proposed contribution (Basis for Technical Evaluation; not to exceed 1 page per work item)

  • Understanding of interoperability issues, understanding of technical requirements and architecture, and potential enhancements to OGC and related industry architectures and standards

  • Recommendations to enhance Information Interoperability through industry-proven best practices, or modifications to the software architecture defined in Appendix B: Technical Architecture

  • If applicable, knowledge of and access to geospatial data sets by providing references to data sets or data services

The Cost Proposal should be based on the two worksheets contained in the Cost Proposal Template and must include the following:

  • Completed Pilot Cost-Sharing Funds Request Form

  • Completed Pilot In-Kind Contribution Declaration Form

Additional instructions are contained in the templates themselves.

B.3. How to Transmit the Response

Guidelines:

  • Proposals shall be submitted to the OGC Technology Desk (techdesk@opengeospatial.org).

  • The format of the technical proposal shall be Microsoft Word or Portable Document Format (PDF).

  • The format of the cost proposal is a Microsoft Excel Spreadsheet.

  • Proposals must be submitted before the appropriate response due date indicated in the Master Schedule.

B.4. Questions and Clarifications

Once the original CFP has been published, ongoing authoritative updates and answers to questions can be tracked by monitoring this CFP.

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

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

Update to this CFP including questions and clarifications will be posted to the original URL of this CFP.

B.5. Tips for new bidders

Bidders who are new to OGC initiatives are encouraged to review the following tips:

  • In general, the term "activity" is used as a verb describing work to be performed in an initiative, and the term "deliverable" is used as a noun describing artifacts to be developed and delivered for inspection and use.

  • The roles generally played in any OGC Innovation Program initiative are defined in the OGC Innovation Program Policies and Procedures, from which the following definitions are derived and extended:

    • Sponsors are OGC member organizations that contribute financial resources to steer Initiative requirements toward rapid development and delivery of proven candidate specifications to the OGC Standards Program. These requirements take the form of the deliverables described herein. Sponsors representatives help serve as "customers" during Initiative execution, helping ensure that requirements are being addressed and broader OGC interests are being served.

    • Bidders are organizations who submit proposals in response to this CFP. A Bidder selected to participate will become a Participant through the execution of a Participation Agreement contract with OGC. Most Bidders are expected to propose a combination of cost-sharing request and in-kind contribution (though solely in-kind contributions are also welcomed).

    • Participants are selected OGC member organizations that generate empirical information through the definition of interfaces, implementation of prototype components, and documentation of all related findings and recommendations in Engineering Reports, Change Requests and other artifacts. They might be receiving cost-share funding, but they can also make purely in-kind contributions. Participants assign business and technical representatives to represent their interests throughout Initiative execution.

    • Observers are individuals from OGC member organizations that have agreed to OGC intellectual property requirements in exchange for the privilege to access Initiative communications and intermediate work products. They may contribute recommendations and comments, but the IP Team has the authority to table any of these contributions if there’s a risk of interfering with any primary Initiative activities.

    • The Innovation Program Team (IP Team) is the management team that will oversee and coordinate the Initiative. This team is comprised of OGC staff, representatives from member organizations, and OGC consultants. The IP Team communicates with Participants and other stakeholders during Initiative execution, provides Initiative scope and schedule control, and assists stakeholders in understanding OGC policies and procedures.

    • The term Stakeholders is a generic label that encompasses all Initiative actors, including representatives of Sponsors, Participants, and Observers, as well as the IP Team. Initiative wide email broadcasts will often be addressed to "Stakeholders".

    • Suppliers are organizations (not necessarily OGC members) who have offered to supply specialized resources such as capital or cloud credits. OGCs role is to assist in identifying an initial alignment of interests and performing introductions of potential consumers to these suppliers. Subsequent discussions would then take place directly between the parties.

  • Non-OGC member organizations must become members in order to be selected as Participants. Non-members are welcomed to submit proposals as long as the proposal is complemented by a letter of intent to become a member if selected for.

  • Any individual wishing to gain access to the Initiative’s intermediate work products in the restricted area of the Portal (or attend private working meetings / telecons) must be a member-approved user of the OGC Portal system. Intermediate work products that are intended to be shared publicly will be made available as draft ER content in a public GitHub repository.

  • Individuals from any OGC member organization that does not become an Initiative Sponsor or Participant may still (as a benefit of membership) quietly observe all Initiative activities by registering as an Observer.

  • Prior initiative participation is not a direct bid evaluation criterion. However, prior participation could accelerate and deepen a Bidder’s understanding of the information presented in the CFP.

  • All else being equal, preference will be given to proposals that include a larger proportion of in-kind contribution.

  • All else being equal, preference will be given to proposed components that are certified OGC-compliant.

  • All else being equal, a proposal addressing all of a deliverable’s requirements will be favored over one addressing only a subset. Each Bidder is at liberty to control its own proposal, of course. But if it does choose to propose only a subset for any particular deliverable, it might help if the Bidder prominently and unambiguously states precisely what subset of the deliverable requirements are being proposed.

  • The Sponsor(s) will be given an opportunity to review selection results and offer advice, but ultimately the Participation Agreement (PA) contracts will be formed bilaterally between OGC and each Participant organization. No multilateral contracts will be formed. Beyond this, there are no restrictions regarding how a Participant chooses to accomplish its deliverable obligations so long as the Participant’s obligations are met in a timely manner (e.g., with or without contributions from third party subcontractors).

  • In general, only one organization will be selected to receive cost-share funding per deliverable, and that organization will become the Assigned Participant upon which other Participants will rely for delivery. Optional in-kind contributions may be made provided that they don’t disrupt delivery of the required, reliable contributions from Assigned Participants.

  • A Bidder may propose against any or all deliverables. Participants in past initiatives have often been assigned to make only a single deliverable. At the other extreme, it’s theoretically possible that a single organization could be selected to make all available deliverables.

  • In general, the Participant Agreements will not require delivery any component source code to OGC.

    • What is delivered instead is the behavior of the component installed on the Participant’s machine, and the corresponding documentation of findings, recommendations, and technical artifacts as contributions to the initiative’s Engineering Report(s).

    • In some instances, a Sponsor might expressly require a component to be developed under open-source licensing, in which case the source code would become publicly accessible outside the Initiative as a by-product of implementation.

  • Results of other recent OGC initiatives can be found in the OGC Public Engineering Report Repository.

  • A Bidders Q&A Webinar will likely be conducted soon after CFP issuance. The webinar will be open to the public, but prior registration will be required.

Appendix C: Abbreviations

The following table lists all abbreviations used in this CFP.

API 

 Application Programming Interface

CFP

Call for Participation

CR

Change Request

DER

Draft Engineering Report

DWG

Domain Working Group

ER

Engineering Report

IP

Innovation Program

OGC

Open Geospatial Consortium

ORM

OGC Reference Model

OWS

OGC Web Services

PA

Participation Agreement

POC

Point of Contact

Q&A

Questions and Answers

SOW

Statement of Work

SWG

Standards Working Group

TBD

To Be Determined

TC

OGC Technical Committee

TEM

Technical Evaluation Meeting

TIE

Technology Integration / Technical Interoperability Experiment

URL

Uniform Resource Locator

WFS

Web Feature Service

WG

Working Group (SWG or DWG)

Appendix D: Corrigenda & Clarifications

The following table identifies all corrections that have been applied to this CFP compared to the original release. Minor editorial changes (spelling, grammar, etc.) are not included.

Section Description

All

"OGC API - 3D Tiles API" replaced by "OGC API - Tiles-3D"

Title

Title changed to 3D Data Container and Tiles API

All

Figures updated to reflect name changes

The following table identifies all clarifications that have been provided in response to questions received from organizations interested in this CFP.

Question Clarification

 — 

 —