1. Introduction

The OGC Climate Resilience Community brings decision makers, scientists, policy makers, data providers, software developers, and service providers together. The goal is to enable everyone to take the relevant actions to address climate change and make well informed decisions for climate change adaptation. This includes scientists, decision makers, city managers, politicians, and last but not least, it includes everyone of us. So what do we need? We need data from lots of organizations, available at different scales for large and small areas to be integrated with scientific processes, analytical models, and simulation environments. We need data visualization and communication tools to shape the message in the right way for any client. Many challenges can be met through resources that adhere to FAIR principles. FAIR as in: Findable, Accessible, Interoperable, and Reusable. No single organization has all the data we need to understand the consequences of climate change. The OGC Climate Resilience Community identifies, discusses, and develops these resources. The OGC community builds the guidebooks and Best Practices, it experiments with new technologies to share data and information, and collaboratively addresses shared challenges.

The OGC Climate Resilience Community has a vision to support efforts on climate actions and enable international partnerships (SDG 17), and move towards global interoperable open digital infrastructures providing climate resilience information on users demand. This pilot will contribute to establishing an OGC climate resilience concept store for the community where all appropriate climate information to build climate resilience information systems as open infrastructures can be found in one place, be it Information about data services, tools, software, handbooks, or a place to discuss experiences and needs. The concept store covers all phases of Climate Resilience, from initial hazards identification and mapping to vulnerability and risk analysis to options assessments, prioritization, and planning, and ends with implementation planning and monitoring capabilities. These major challenges can only be met through the combined efforts of many OGC members across government, industry, and academia.

This Call for Participation solicits interests from organizations to join the upcoming Climate Resilience Pilot, an OGC Collaborative Solution and Innovation Program activity. This six-months Pilot is setting the stage for a series of follow up activities. It therefore focuses on use-case development, implementation, and exploration. It answers questions such as

  • What use-cases can be realized with the current data, services, analytical functions, and visualization capabilities that we have?

  • How much effort is it to realize these use-cases?

  • What is missing, or needs to be improved, in order to transfer the use-cases developed in the pilot to other areas?

Interested organizations are invited to submit their use-case suggestions. During the pilot, these use-cases will be implemented and assessed collaboratively against a set of Research Questions defined further below. These questions allow aspects regarding data availability, integration, processing, and visualization to be evaluated consistently across all use cases. Together, the use cases will allow us to better understand and equip future Climate Resilience Information Systems (CRIS) and resilience frameworks. They allow us to identify interoperability issues and data integration challenges and pave the way for future collaborative solution development.

2. Objectives

The pilot has three objectives. First, to better understand what is currently possible with the available data and technology. Second, what additional data and technology needs to be developed in future to better meet the needs of the Climate Resilience Community; and third, to capture Best Practices, and to allow the Climate Community to copy and transform as many use-cases as possible to other locations or framework conditions.

3. Background

With growing local communities, an increase in climate-driven disasters, and an increasing risk of future natural hazards, the demand for National Resilience Frameworks and Climate Resilience Information Systems (CRIS) cannot be overstated. Climate Resilience Information Systems (CRIS) are enabling data-search, -fetch, -fusion, -processing and -visualization. They enable access, understanding, and use of federal data, facilitate integration of federal and state data with local data, and serve as local information hubs for climate resilience knowledge sharing.

CRIS are already existing and operational, like the Copernicus Climate Change Service with the Climate Data Store. CRIS architectures can be further enhanced by providing climate scientific methods and visualization capabilities as climate building blocks. Based on FAIR principles, these building blocks enable in particular the reusability of Climate Resilience Information Systems features and capabilities. Reusability is an essential component when goals, expertises, and resources are aligned from the national to the local level. Framework conditions differ across the country, but building blocks enable as much reuse of existing Best Practices, tools, data, and services as possible.

Goals and objectives of decision makers vary at different scales. At the municipal level, municipal leaders and citizens directly face climate-related hazards. Aspects thus come into focus such as reducing vulnerability and risk, building resilience through local measures, or enhancing emergency response. At the state level, the municipal efforts can be coordinated and supported by providing funding and enacting relevant policies. The national, federal, or international level provides funding, science data, and international coordination to enable the best analysis and decisions at the lower scales.

?artifact id=102215
Figure 1. Schematic synergies within different climate and science services due to FAIR and open Infrastructures

Productivity and decision making are enhanced when climate building blocks are exchangeable across countries, organizations, or administrative levels (see Figure below). This OGC Climate Resilience Pilot is a contribution towards an open, multi-level infrastructure that integrates data spaces, open science, and local-to-international requirements and objectives. It contributes to the technology and governance stack that enables the integration of data including historical observations, real time sensing data, reanalyses, forecasts or future projections. It addresses data-to-decision pipelines, data analysis and representation, and bundles everything in climate resilience building blocks. These building blocks are complemented by Best Practices, guidelines, and cook-books that enable multi–stakeholder decision making for the good of society in a changing natural environment.

The OGC Innovation Program brings all groups together: The various members of the stakeholder group define use cases and requirements, the technologists and data providers experiment with new tools and data products in an agile development process. The scientific community provides results in appropriate formats and enables open science by providing applications that can be parameterized and executed on demand.

?artifact id=102214
Figure 2. The OGC Climate Resilience DWG and Pilot brings the climate resilience community together with infrastructure providers, policy makers, commercial companies, and the scientific community

This OGC Climate Resilience Pilot is part of the OGC Climate Community Collaborative Solution and Innovation process, an open community process that uses the OGC as the governing body for collaborative activities among all members. A spiral approach is applied to connect technology enhancements, new data products, and scientific research with community needs and framework conditions at different scales. The spiral approach defines real world use cases, identifies gaps, produces new technology and data, and tests these against the real world use cases before entering the next iteration. Evaluation and validation cycles alternate and continuously define new work tasks. These tasks include documentation and toolbox descriptions on the consumer side, and data and service offerings, interoperability, and system architecture developments on the producer side. It is emphasized that research and development is not constrained to the data provider or infrastructure side. Many tasks need to be executed on the data consumer side in parallel and then merged with advancements on the provider side in regular intervals.

Good experiences have been made using OGC API standards in the past. For example, the remote operations on climate simulations (roocs) use OGC API Processes for subsetting data sets to reduce the data volume being transported. Other systems use OGC STAC for metadata and data handling or OGC Earth Observation Exploitation Platform Best Practices for the deployment of climate building blocks or applications into CRIS architectures. Still data handling regarding higher complex climate impact assessments within FAIR and open infrastructures needs to be enhanced. There is no international recommendation or best practice on usage of existing API standards within individual CRIS. It is the goal of this pilot to contribute to the development of such a recommendation, respecting existing operational CRIS that are serving heterogen user groups

?artifact id=102216
Figure 3. Schematic Architecture of a Climate Resilience Information System. By respecting FAIR principles for the Climate Building Blocks the architecture enables open infrastructures to produce and deliver information on demand of the users needs.

4. Master Schedule

The master schedule is given below. Organizations interested in sponsoring the activity are encouraged to contact innovation@ogc.org to discuss Pilot extensions and future initiative options.

Table 1. Master Schedule
Milestone Date  Event

M01

September 14, 2022

Public Release: Call for Participation

M02

November 18, 2022

Close of Call for Participation

M03

January 13, 2022

Kick-Off Workshop (virtual)

M04

February, 2023

Demonstration event at OGC Member Meeting Climate Resilience DWG (virtual or in person)

M05

May 31, 2023

Delivery of final Engineering Reports

M06

June 2023

Closing workshop (in person meeting, tentatively co-located with OGC Member Meeting in Huntsville, Alabama, USA); Official end of the project

M07

July 2023

Call for participation for next initiatives

5. Funding

This pilot initiative offers a cost-share for all participants. Bidders who wish to take advantage of the cost-share must document their planned costs in the cost-share template and submit this together with their proposal. Please see Submission Guidelines for further information. Cost-share of funds are to be negotiated upon receipt of the proposal if the proposal is chosen. Funding is determined based upon the work outlined in the proposal and dependent on the complexity of the deliverable.

6. Scope

This OGC Climate Resilience Community initiative focuses on current capabilities and gaps to address the following challenges. Geographic locations are just suggestions. Participants are invited to suggest alternative locations and additional use-cases.

  • Wildfires: Wildfires are a devastating and growing risk in many regions of our planet. Their occurrences are a result of climate change effects such as extreme heat, drought, and lightning storm severity, as well as a contributor in terms of carbon emissions, forest destruction, and airborne particulate release. For this reason, wildfire risk can be considered both an output and a factor in climate change services. This use-case shall evaluate the current regional / seasonal risk for wildfires and future risks based on climate change data. Participants shall demonstrate wild fire use-cases for the following areas: Southwest USA, Australia, or Greece.

  • Heat impact: Extreme heat can significantly impact on productivity and kill the vulnerable quickly. We have experienced an increase in heat wave events and their frequency. The total amount of heat in individual heatwaves and heatwave seasons has increased over the past 70 years and this is only expected to get worse with climate change. This use case shall demonstrate the required data discovery, processing, and visualization to enhance the data processing flow for user-friendly production of heat information to support adaptation planning in the UK, India or Pakistan.

  • Drought Impact: Beside Heat, droughts and other extreme events are increasing due to climate change and causing huge damage, costs, and loss of life. This use case shall demonstrate the required data discovery, processing, and visualization to enhance the data processing flow for user-friendly production of information concerning extreme events.

  • Flood Impact and Water Management: Managing hydro power plants requires a strong understanding of future water levels in both the water system used for power production and its catchment area. This use case shall demonstrate the data discovery, processing, and visualization for hydro power production in Canada, USA, or Austria.

  • Global Stocktake for Emissions: The global stocktake is a process of the Paris Agreement (GST) and corresponding National determined contributions to reduce Greenhouse gas emission. While national stocktakes should be used for national progress, the Global Stocktake is going to be established with the aim to assess the world’s collective progress towards achieving the purpose of the Paris Agreement and its long-term goals (Article 14). Currently no consistent approach exists on how information is going to be elaborated, and open infrastructures are dedicated to be established for this purpose. Participants are free to explore and suggest data and processes on a best intent basis.

  • Analysis Ready Data: This last use-case is slightly different to the first five. It does not address a specific thematic use-case, but calls for improved discovery and access to climate indices on a regional level. The work will build on and coordinate with OGC sponsored tasks to develop and promote standards for analysis ready EO datasets. Regional climate indices play an important role for long-term planning and decision-making at regional, national, and sub-national levels. The following areas shall be addressed: USA, Brazil, Turkmenistan, and Indonesia.

7. Research questions

The following questions shall be answered as part of the use-case documentation expected from each participant: Data Discovery

  1. What data was discovered?

    • How was it discovered?

    • What data sources have been explored?

    • What interfaces did you need/find/used for data discovery?

    • What data did you expect to find but didn’t?

    • What data did you discover being described or referenced on websites, but access to the actual data fails?

  2. Data Integration

    • Was it possible to integrate the data into the use-case software?

    • If successful, was it possible to load the data as it was discovered, or was further processing (e.g. reformatting, reprojection, etc.) necessary?

    • If not, why did it fail?

    • What interfaces did you need/find/used for data access and integration?

    • What software did you use?

  3. Data Processing

    • What data processing steps have been used?

    • Did you use local (which software?) or cloud-based processing (which service?)?

    • Did you find services that offered all required data processing?

    • What additional services would you like to have?

    • What interfaces did you need/find/used for data processing?

  4. Data Visualization and Result Rendering

    • Was it possible to render all data in a way that is easy to read/understand?

    • What challenges did you experience during data/result rendering and visualization?

    • How does information need to be provided tailoring to UNFCCC policy recommendations?

8. Deliverables

Each participant shall deliver a presentation using a climate application of their choice. The application shall show what data was discovered, processed, and visualized for the demonstration use-case. Each participant is free to choose the type of software used for data integration, analysis, and visualization. No software will be delivered. Instead, delivery is provided in the form of live demonstrations of the use-case during video conferences that will be recorded and used for future outreach activities. Bidders may use a mobile or desktop client to demonstrate their climate use-case. Bidders are free to connect to any number of available data sources available as Web services, though preference is given to use-cases using several standardized interfaces for data discovery and access. The client application does not need to support every step of the use-case. As an example, discovery and data access can be demonstrated using different clients.

In total, this pilot is expected to fund up to eight use-cases. The figure below identifies the corresponding work items. Each Bidder is requested to bid against D100 and contribute to the pilot result Engineering Report, D001. A single Participant will serve as lead editor on D001. Each bidder is invited to bid for this role.

deliverables
Figure 4. Overview of the Pilot Deliverables. Each Bidder needs to bid for the client application D100 and may bid for the lead editor role D001. Blue icons to the right illustrate publicly available web services serving data, catalog information, or processing capacities

D100 - Client instance: Climate use-case demonstrated through dedicated client instance. The client instance will be delivered in the form of a live demonstration that illustrates all elements of the use-case. Ideally, the client shall make use of several publicly available data servers. It is not expected that participants will deliver any software or data.

D001 - Climate Resilience Pilot Engineering Report: Engineering Report that captures all results and lessons learned of this pilot. One bidder will serve as lead editor for this report. All other Participants are required to contribute their results, experiences made, use-case descriptions, and lessons learned. All research questions stated above need to be addressed as part of this contribution.

9. Link to Disaster Pilot

A principal theme of the OGC Disaster Pilot 2022 will concern wildfire hazard resilience in medium time frames, and response awareness in shorter time frames, as well as consequential relationships with other hazards, such as drought, and impacts, such as health status. Climate resilience links to disaster awareness in the medium term on the planning and mitigation side as climate changes impact the risks of wildfire frequency and severity. There are also some connections on the shorter term disaster response side, to the extent that climate effects may complicate and constrain response resources such as water availability for fire fighting, or impact the vulnerability of people and assets to wildfire impacts.

10. Miscellaneous

10.1. Call for Participation

The Call for Participation (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.

10.2. Correspondence and Collaboration

Each Participant agrees to utilize the following correspondence and collaboration tools:

  • Participate in telecons using the GoToMeeting tool;

  • Edit Engineering Report source files in the Asciidoc format using the OGC Engineering Report template (to be provided);

  • Upload Engineering Report source files to the designated GitHub or Gitlab repository;

  • Use the designated GitHub/Gitlab repository for communication and reporting;

  • Utilize the OGC Web Portal, with modules for calendaring, contact lists, file storage, timeline, action items, and meeting scheduling; and

  • Send and receive emails to/from Initiative email broadcast list(s).

10.3. Reporting

Each Participant agrees to report the status of deliverables weekly to the initiative architect (Technical Status Reports) and monthly in business status reports.

Technical Status Reports: Each Participant agrees to use Github/Gitlab issues to report the status on each assigned deliverable on a weekly basis. These short reports shall include the following information:

  • Deliverable ID and Name,

  • Health: G, Y, R (green, yellow, red),

  • %complete (0%-100%),

  • Work accomplished in reporting period (last week),

  • Work anticipated in reporting period+1 (next week),

  • Any known risks or issues,

  • Response to mitigate the risk or remedy the issue.

Monthly Business Status Reports: Each Participant agrees to email monthly business status reports no later than the 3rd of each second month (or the first workday after if the 3rd is not a workday). This report should include the period and cumulative hours and cost expended for each assigned deliverable.

Appendix A: Pilot Organization and Participation Requirements

A.1. Initiative Policies and Procedures

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

A.2. Participation Requirements

  • Each Participant agrees to provide a detailed description and planned implementation of the assigned deliverables and to coordinate with other initiative Participants at the Kickoff Workshop ("Kickoff").

  • The Initiative will be conducted within the framework of OGC’s Bylaws and Intellectual Property Rights Policy ("IPR Policy"), as agreed to in the Participant’s Membership Agreement, and in accordance with the OGC Innovation Program Policies and Procedures and the OGC Principles of Conduct, the latter governing all related personal and public interactions. All information is available online.

  • Remote Teleconference Meetings: Regular telecons will be conducted to accelerate understanding and action, particularly the status of any risks (or issues) that might block (or are blocking) progress toward timely delivery of work item results.

  • Each Participant agrees to provide at least one Technical Point of Contact (POC) to attend both regularly scheduled and ad hoc telecons that involve an assigned deliverable.

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 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.4. Types of Deliverables

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

A.4.1. Documents

Engineering Reports (ER), Guides, 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.4.2. Implementations

Services, Clients, Datasets, Schemas, API documentation, and Tools will be provided by methods suitable to each type and stated requirements. For example, services and components (e.g., a OGC API-Processes or 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 activities for integration and interoperability testing in support of the agreed-up activity use-case(s) and technical architecture. The services, clients, and tools may be invoked for cross-activity use-cases in demonstration events.

A.4.3. Videos

If not otherwise stated in the definition of the deliverable, each participant should 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 should illustrate the initial challenge(s) and developed solutions. The video can be done using screen-capturing of clients or slides with (English) voice over. Participants should cooperate with OGC in translation of videos to additional languages (e.g. French, Spanish) as needed, as well as incorporation in sponsor-produced summary videos. 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.5. Proposals & Proposal Evaluation

Proposals are expected to be short and precisely addressing the work items a bidder is interested in. Proposal templates will be made available. The proposal, including technical and financial details, has a page limit as defined in Submission Guidelines. Details on the proposal submission process are provided in 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: 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 Master Participant Agreement (MPA) and a Statement of Work (SOW).

A.5.2. Evaluation Criteria

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.

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.

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.3. 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 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 Technical Progress Report and (2) a Business Progress Report. Both reports shall be delivered every second month by the first working day on or after the 4th of that month. Templates for both of these report types will be provided and must be followed.

The purpose of the 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.

Further details on reporting procedures are provided in section Reporting.

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 innovation@ogc.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.

  • 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 (i.e., being selected for Engineering Reports) will also be expected to participate in the full course of activities throughout the Initiative, documenting implementation findings and recommendations and ensuring document delivery.

  • If the initiative includes component development activities, then

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

    • 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 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 remains in the control of these actors and will not be used for any other purpose without the 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 defined in this CFP and the overall quality of their proposal. 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.

Each Participant (including pure in-kind Participants) that is assigned to make a deliverable will be required to enter into a Master Participation Agreement contract ("MPA") and Statement of Work ("SOW") 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.

B.2. What to Submit

The two documents that shall be submitted, with their respective templates are as follows:

  1. Technical Proposal Template

  2. Cost Proposal Template

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

  1. Cover page

  2. Overview (Not to exceed one page)

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

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

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

  1. Completed Pilot Cost-Sharing Funds Request Form

  2. Completed Pilot In-Kind Contribution Declaration Form

Additional instructions are contained in the templates themselves.

B.3. How to Transmit the Response

Guidelines:

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 innovation@ogc.org. 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 Master Participation Agreement and Statement of Work 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 Innovation Program Team (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 Git 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 Master Participation Agreement (MPA) and Statement of Work (SOW) 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 subParticipants).

  • 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 and Statements of Work will not require delivery of 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.

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

IER

Initial Engineering Report

IP

Innovation Program or Intellectual Property

MPA

Master Participation Agreement

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 (at a later date)

TC

OGC Technical Committee

TEM

Technical Evaluation Meeting

TIE

Technology Integration / Technical Interoperability Experiment

URL

Uniform Resource Locator

WFS

Web Feature Service

WMTS

Web Map Tile 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

no entries

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

Question Clarification

no entries

( end of document )