1. OGC Vector Tiles Pilot Phase 2 (VTP-2)

pilotLogo

1.1. Introduction

The Open Geospatial Consortium (OGC®) is releasing this Call for Participation ("CFP") to solicit proposals for the OGC Vector Tiles Pilot Phase 2 (VTP-2) Initiative ("Pilot" or "Initiative"). The goal of the initiative is to advance the handling of tiled feature data, better known as vector tiles.

This initiative builds on previous Vector Tiles Pilot (VTP-1) efforts to access and style vector tiles from different services and client types, and on intermediate results stemming from the Testbed-15 Open Portrayal Framework (OPF) thread.

VTP-1, the first phase 1 of the Vector Tiles Pilot, has successfully developed and delivered Vector Tile (VT) extensions for the OGC API - Features specification (formerly named Web Feature Service 3.0), Web Map Tile Service (WMTS) and GeoPackage in collaboration with industry partners. These extensions delivered VTP-1 supported web clients, a desktop application clients, and mobile clients with support for offline situations. The effort also developed a draft WMTS Styles API and a prototype OGC API for Styles. In addition, VTP-1 developed a conceptual model for tiled feature data.

Testbed-15 OPF is developing a framework that allows applying styles to maps, raster, and vector tiles. The OPF Thread is also developing Web APIs that complement and upgrade existing OGC Web Services (e.g., WMTS and WMS)≠ with OGC APIs for Maps, Tiles, and Images. These APIs include style elements to request the application of specific styles to data, including vector tiles. The APIs are further complemented with an OGC API - Styles specification to allow posting and retrieval of styles from a style server, modification using visual style editors, and re-distribution for further sharing and use. Testbed-15 is developing a conceptual model for styles, metadata for styles, and elaborates linkages between rendering instructions and vector attributes of the corresponding data, including use with GeoPackages.

The objective of Vector Tiles Pilot Phase 2, is to deliver a consistent, interoperable online/offline architecture for vector tiles based on feature and tile servers, and GeoPackage. The feature and tile servers including WMTS, OGC API – Features, and OGC API – Tiles shall provide support for map projections other than Web Mercator. All APIs and service types shall further support the vector tile metadata model and filtering language, the two other essential work items of VTP-2.

The initiative shall test styled vector tiles with multiple data sources, perspective views, opacity, color backgrounds, imagery backgrounds and day/night display conditions. VTP-2 will conduct thorough testing of the OGC APIs for Maps and Tiles, as developed in Testbed-15, and further advance support for vector tiles.

1.2. Background

Vector Tiles Pilot Phase 1 (VTP-1) and Testbed-15 Open Portrayal Framework have provided the groundwork for this initiative. While VTP-1 finished in early 2019, it is emphasized that Testbed-15 is an ongoing activity with final reports expected November 2019. For this reason, it is essential for participants of this initiative to become familiar with Testbed-15 intermediate results and ongoing activities. This is possible by obtaining observer status. For further information, please see section Temporal and Thematic Overlap with Testbed-15.

The following Engineering Reports and videos describe the work accomplished in VTP-1 and the ongoing activities in Testbed-15:

At the same time, significant progress towards more Web-oriented interfaces has been made in OGC with the emerging OGC APIs -Core, -Features, -Maps, -Tiles, -Images, -Styles, -Coverages, -Routes and -Processes. All of these APIs are using OpenAPI. These APIs are described below:

1.3. OGC Innovation Program Initiative

This Initiative 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 taken place.

1.4. Benefits of Participation

This Initiative provides a unique opportunity towards implementing sophistically styled tiled feature data. As all results will be made available to the OGC Standards Program for further consideration, it allows participants to influence future standardization activities and thus competitive advantages in getting to the market early.

The sponsorship supports the vision of interoperable vector tile handling 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.5. Master Schedule

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

Table 1. Master schedule
Milestone Date  Event

M01

09 September 2019

Release of Call for Participation (CFP)

M02

18 October 2019

Proposals due

M03

31 October 2019

Participant selection and agreements

M04

12 November 2019

Virtual Kick-off meeting (Go-To-Meeting)

M05

24 January 2020

Draft Engineering Report(s) due

M06

25 March 2020

Final demonstration of results

M07

01 April 2020

Documentation and Engineering Report(s) due

M08

15 April 2020

Participant(s) Summary Report(s) due

2. Technical Architecture

This section provides the 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 where necessary. Further information on the OGC standards baseline can be found online.

OGC Vector Tiles Pilot Phase 2 (VTP-2) puts emphasize on providing a smooth online-offline experience for the user. In the ideal case, a user working with vector tiles experiences only minimal changes in performance, display, or interaction when transiting back and forth from online to offline situations. This allows handling disaster response, humanitarian relief and other scenarios, where network availability is limited to specific areas or time periods.

scenario
Figure 1. VTP-2 scenario

VTP-2 targets five major work items that shall be addressed: metadata, filter language support, GeoPackage, vector tile data representation (styling), and support for various projections and coordinate reference systems.

The technical architecture is illustrated in the figure below. Two client applications communicate with feature and tile servers through OGC API – Features, WMTS and OGC API - Tiles interfaces. To explore all styling options, the implementation of the OGC API - Styles is required at the feature and tile server instances as well. OGC API – Features, OGC API - Tiles, and OGC API - Styles are not standards yet, but are being advanced in Testbed-15. They need to be evaluated and possibly enhanced to fully support the metadata model for vector tiles and the vector tiles filtering language. Services and APIs shall support remote symbol handling and support for sprites.

architecture
Figure 2. VTP-2 architecture

To fully accommodate offline usage scenarios, VTP-2 shall develop robust online/offline solutions using GeoPackage. In addition to this general offline support architecture, VTP-2 shall investigate methods to associate vector tile tables in GeoPackages with attribute tables to allow for fine-grained filtering. Ideally, all GeoPackages in VTP-2 are built by accessing the tile and feature server instances through methods that are available online.

Two Engineering Reports capture the results of this initiative, including the metadata model for vector tiles, the vector tiles filtering language, as well as all lessons learned and technical experiences made in the implementation phase of the pilot.

2.1. Detailed Objectives

In detail, the following objectives will be targeted and need to be met by the various components:

A) Metadata: The overall goal is to describe stored tile caches in necessary detail to allow usage and updating of each tile cache without analyzing each tiles. The NSG Metadata foundation shall be extended. In detail, VTP-2 shall develop a metadata model for vector tiles and stored tile caches and implement and exercise the model meeting the following requirements:

  1. Metadata shall describe fundamental aspects of the tiles, such as date, creator, source, etc.

  2. Metadata elements shall describe the tiling scheme (tile matrix set)

  3. Define how space is partitioned into individual tiles, substitution variables to identify tiles using a three-part identifier such as {level} (zoom), {row} (vertical) and {col} (column: horizontal)

  4. Style names or identifiers and metadata to describe multi-layer vector tiles

  5. Other elements required to support the Vector Tiles Filter language described below

  6. A standard resource path structure to consistently present simple metadata for vector tiles as an extension to tile and feature servers, standalone tile caches and GeoPackage tables

The metadata model will be tested using all service and API endpoints, client applications, and GeoPackages. It will be documented in Engineering Report D001.

B) Filtering Language: VTP-2 shall develop a filtering language for vector tiles, and implement and exercise the filtering language meeting the following requirements:

  1. A Vector Tiles Filtering language for tile and feature servers outlined above, with filters similar to OGC Filter Encoding 2.0 or CQL (Common Query Language), a query language created by the OGC for Catalog Services.

  2. A Vector Tiles Filtering language for GeoPackage Vector Tiles. This language should differ from the tile and feature servers language only where required by the different underlying technology

  3. Client applications able to build filters for tile and feature servers, and to visualize received vector tiles.

  4. Tile and feature server instances that can process vector tile filters.

  5. GeoPackage implementations with Vector Tiles Filtering support.

The filtering language will be tested using all service and API endpoints, client applications, and GeoPackages. It will be documented in Engineering Report D002. It shall be tested for accuracy and completeness in applications which render vector tiles at local to regional scales.

C) GeoPackage: VTP-2 shall develop solutions for robust offline/online usage scenarios using GeoPackage technology. VTP-2 shall develop methods to associate vector tile tables in GeoPackages with attribute tables to allow applying similar filters to Geopackages as being applied to the OGC API Tiles. These shall be demonstrated in the GeoPackage implementations. Each GeoPackage shall be provided together with a simple client that can demonstrate the attribute table support.

D) Style Sharing: VTP-2 shall develop online/offline symbol and style sharing for vector tiles. I.e. a user shall request pre-rendered tiled vector data by defining a particular style while online. As network connectivity is lost, the user shall request data from the Geopackage and does client-side rendering. The Geopackage shall provide all style information. Further on, the following aspects shall be explored:

  1. Evaluation of the GeoPackages with vector tile data for the ability to support portrayal and attributes in an offline environment.

  2. Methods to store symbols in easily accessible online locations such as the Styles API and Amazon S3 ‘buckets’ and offline resource folders or GeoPackage tables.

  3. Methods to retrieve and apply style information based on the emerging OGC API - Styles specification. At minimum, the following styles shall be applied: Topo, Night and Satellite Styles defined in Phase 1 of the Vector Tiles Pilot, and a gray canvas background.

Style sharing and remote symbol handling will be implemented as part of each service endpoint. Further style handling experimentation will be conducted with the GeoPackage implementations. Style sharing will build on the results of Testbed-15 OGC API Styles.

E) Experimentation: Vector tiles shall be tested using the following Tile Matrix Sets delivered by tile and feature servers and implemented in GeoPackages:

MapBox Styles, i.e. MBStyles, uses Web Mercator by default. The participants shall explore how standards and best practices can be developed acknowledging industry best practices, as well as, satisfying particular needs set by specific communities. In particular, advancing open source translator libraries for vector tiles, (e.g. GDAL), able to read and write Mapbox Vector Tiles without assuming by default EPSG:3857 (Web Mercator) spatial reference system.

Vector tiles shall store geographic information in accordance with the Mapbox Vector Tile (MVT) Specification v 2.1 and the GeoJSON Format. See the MVT specification (https://www.mapbox.com/vector-tiles/specification/) version 2.1 (https://github.com/mapbox/vector-tile-spec/tree/master/2.1) and Internet Engineering Task Force (IETF), Request for Comments (RFC) 7946, The GeoJSON Format http://tools.ietf.org/rfc/rfc7946.txt for more details.

Vector tiles shall implement the Styled Layer Descriptor (SLD) style encoding and may implement the Mapbox Style (MBStyle) encoding.

2.2. Work Items & Deliverables

The following section defines all work items and deliverables of this initiative.

Engineering Reports

  • D001 Vector Tiles and Tile Metadata Engineering Report - This report contains all results of TIE experiments and lessons learned from the various software components. In addition, it defines a Metadata model for Vector Tiles to include Metadata elements for tiling scheme (‘tile matrix set’ to use WMTS terminology) to define how space is partitioned into individual tiles, substitution variables to identify tiles using a three-part identifier such as level (zoom), row (vertical) and col (column: horizontal), and style names or identifiers and metadata to describe multi-layer vector tiles.

  • D002 Vector Tiles Filtering Language Engineering Report - This report defines the Vector Tiles Filtering language for WFS and WMTS based Vector Tiles servers and for GeoPackage Vector Tiles. The work item further includes an assessment of filter languages, metadata, styles and online/offline symbol sharing for the GeoPackage, WMTS and WFS Vector Tiles implementations for accuracy and completeness in applications which render vector tiles at local to regional scales.

Components Some components are identical. It is sufficient if bidders reference the fully described work item in their proposal. Each bidder will be automatically considered for any of the similar work items.

  • D100 Vector Tiles Server 1 "Features" - Feature server implementing the OGC API - Features specification or the OGC API - Tiles specification with support for tile metadata and filtering. Server shall support handling of all style related components including symbols and sprites stored externally, e.g. in Amazon S3 buckets. Server needs to define a standard resource path structure to consistently present simple metadata for Vector Tiles as an extension to OGC API - Features and OGC WMTS based Vector Tile services, standalone tile caches and GeoPackage tables. Server shall support methods to store symbols in easily accessible online locations such as Amazon S3 ‘buckets’ and offline resource folders or GeoPackage tables based on the Vector Tiles Pilot and the emerging OGC Style API, the Topo, Night and Satellite Styles defined in Phase 1 of the Vector Tiles Pilot, and a gray canvas background. Server should extend and implement open source translator libraries for vector tiles able to read and write Mapbox Vector Tiles without assuming by default EPSG:3857 (Web Mercator) spatial reference system.

  • D101 Vector Tiles Server 2 "Features" - Server identical to D100.

  • D102 Vector Tiles Server 3 "Tiles" - Tile server implementing the OGC API - Tiles specification with support for tile metadata and filtering. Server shall support handling of all style related components including symbols or sprites stored externally, e.g. in Amazon S3 buckets. Server needs to define a standard resource path structure to consistently present simple metadata for Vector Tiles as an extension to OGC API - Features and OGC WMTS based Vector Tile services, standalone tile caches and GeoPackage tables. Server shall support methods to store symbols in easily accessible online locations such as Amazon S3 ‘buckets’ and offline resource folders or GeoPackage tables based on the Vector Tiles Pilot and the emerging OGC Style API, the Topo, Night and Satellite Styles defined in Phase 1 of the Vector Tiles Pilot, and a gray canvas background. Server should extend and implement open source translator libraries for vector tiles able to read and write Mapbox Vector Tiles without assuming by default EPSG:3857 (Web Mercator) spatial reference system.

  • D103 Vector Tiles Server 4 "Tiles" - Server identical to D102.

  • D104 Vector Tiles Client 1 - Client application capable of interacting with feature services implementing OGC API Tiles and OGC API Styles. Client supports the filtering language, including building filters, and can select tiles based on metadata. Client may support implement open source translator libraries for vector tiles.

  • D105 Vector Tiles Client 2 - Client identical to D104.

  • D106 GeoPackage 1 - Populated GeoPackage Vector Tiles implementations evaluated for the ability to support portrayal and attributes in an offline environment. One or more GeoPackage implementations with Vector Tiles Filtering support, one or more GeoPackage with Vector Tiles Styling and Symbols support and one or more GeoPackage with Vector Tiles Attributes support (components may be combined provided they implement required functions). The functionality shall be demonstrated with an appropriate simple client.

  • D107 GeoPackage 2 - GeoPackage identical with D106.

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 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).

3. Deliverables Summary & Funding Status

The following table summarizes the full set of Initiative deliverables. Technical details can be found in the Appendix B: Technical Architecture.

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

D001

Vector Tiles and Tile Metadata Engineering Report

funded

D002

Vector Tiles Filtering Language Engineering Report

funded

D100

Vector Tiles Server 1 "Features"

funded

D101

Vector Tiles Server 2 "Features"

funded

D102

Vector Tiles Server 3 "Tiles"

funded

D103

Vector Tiles Server 4 "Tiles"

funded

D104

Vector Tiles Client 1

funded

D105

Vector Tiles Client 2

funded

D106

GeoPackage 1

funded

D107

GeoPackage 2

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 should include the proposing organization’s technical solution, its cost-sharing requests for funding, and its 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 formed with selected Bidders, ALL Participants will be responsible for contributing content to the ERs. But the ER Editor role will assume the duty of being the primary ER author.

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. Temporal and Thematic Overlap with Testbed-15

Vector Tiles Pilot Phase 1 (VTP-1) and Testbed-15 have provided the groundwork for this initiative. While VTP-1 was finished in early 2019, it is emphasized that Testbed-15 is an ongoing activity with final reports expected November 2019. These reports will not be publicly available before the end of the year.

It is essential for participants of this initiative to become familiar with Testbed-15 intermediate results and ongoing activities. This is possible by receiving observer status. Observer status can be requested at any point in time and obtained following this link https://portal.opengeospatial.org/files/?artifact_id=82652

A.2. Initiative Policies and Procedures

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

A.3. 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. They are 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.4. Types of Deliverables

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

A.4.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 Documents 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.4.2. Implementations

Services, Clients, Datasets and Tools will be provided by methods suitable to their type and stated requirements. For example, services and components (e.g. a Web Processing Service instance) are delivered by deployment of the service or component for use in the Initiative via an accessible Uniform Resource Locator (URL). A Client software application or component may be used during the Initiative 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.

A.5. 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.5.1. Evaluation Process

Proposals will be evaluated according to criteria based on three areas: Technical, management, 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.5.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.5.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.5.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.6. 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 10th 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, Technology Interoperability Experiments (TIEs), 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 thirdparty 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.

CFP

Call for Participation

CR

Change Request

DER

Draft Engineering Report

DWG

Domain Working Group

ER

Engineering Report

GPKG

GeoPackage

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

RM-ODP

Reference Model for Open Distributed Processing

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

WPS

Web Processing 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

 — 

 — 

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

Question Clarification

 — 

 —