CDRP base image



Climate and Disaster Resilience Pilot 2024: Call for Participation (CFP)

1. Introduction

Organizations and individuals worldwide are striving to address the challenges created by climate change and increasingly frequent and severe disasters. While the links between increasing climate resilience and managing disasters and emergencies are widely acknowledged, in practice the geospatial data, services and systems used in applications across these domains are not well integrated. There is a critical need to build the capacity to create products, services and platforms that are informed by Climate Resilience work, provide actionable information during emergency and disaster management, and feed lessons learned from emergency and disaster management back into Climate Resilience planning. The Open Geospatial Consortium (OGC) Climate and Disaster Resilience Pilot 24 (CDRP24) assembles a consortium of partners to address these shared challenges and bridge the use of geospatial data and technologies in Climate Resilience and Emergency and Disaster Management.

This Initiative aims to engage a broad cross-section of stakeholders including data and service providers and users, researchers, responders, and community members to shape a connected ecosystem of data, technologies, and practices. We encourage anyone interested in improving understanding and increasing capacity for informed action by integrating spatial information and technologies across climate, disaster, and emergency management related domains to bid to participate. Different ways to participate are described below.

CDRP fig1
Figure 1. The CDRP24 Pilot aims to create added value for users of spatial data by linking information systems for climate resilience and emergency management. Bridging these systems will enable tighter links and create feedback loops between information underpinning long term planning in the face of climate change, such as planning for resilient energy infrastructures, transport network infrastructures, and community services, and supporting rapid response to emergencies and enhanced proactive planning for responses.



2. Background

Past OGC Disaster and Climate Resilience pilots have re-emphasized the critical roles of spatial information and spatial data infrastructures (SDI) in enabling communities and organizations to plan for and respond to disasters, from hurricaines to oil spills, and increase their overall resilience, co-desiging and deploying solutions to enhance infrastructures impacted by climate change and disasters across energy, transport, community services, security, water management, and beyond. Past pilots have developed and implemented OGC API standards to support a variety of applications to facilitate use of spatial data in Climate Resilience and Disaster and Emergency Management. Prior work through these pilots provides the foundation for the work planned in CDRP24. The processes developed to enable remote operations on climate simulations using open community-backed technologies like OGC API processes, helping teams in locations around the world to access the data and computing power they need to model the impacts of climate change for their own applications, forms part of this foundation. Implementations of OGC STAC to enable metadata and data handling, Good Practices developed within the OGC Earth Observation Exploitation Platform, OGC Disaster Pilots collaborations with the Committee on Earth Observation Satellites (CEOS) to standardize Analysis Ready Data (ARD) and provide the basis for Decision Ready Indicators (DRI), alongside the creation of OGC Disaster Readiness Guides are core elements on which the CDRP24 can be built.

Recent OGC Pilots identified priorities which help shape the CDRP24 plan. The last Climate Resilience Pilot (CR23) identified the enhancement of more complex climate impact assessments within FAIR and open infrastructures as a priority, together with developing international recommendations on the use of existing API standards within diverse Climate Resilience Information Systems (CRIS). CR23 highlighted the need to continue to develop the concept of FAIR Climate Services and collaborative solutions that address the data requirements created by UN policy frameworks, specifically addressing the Subsidiary Body for Scientific and Technological Advice (SBSTA) of the United Nations Framework Convention on Climate Change (UNFCCC) and creating links to UNCCD GEO-LDN. The most recent Disaster and Emergency Management Pilot (DP23) developed workflows for linear and non-linear dependencies, simultaneous and sequential impacts, and modeling effects of cascading disaster events related to the requirements of diverse stakeholders.

All COSI Program Engineering Reports (ER) resulting from this work are available from the OGC public engineering reports webpage. The OGC Testbed-18 Engineering Report (ER) documents the results and recommendations of the Identifiers for Reproducible Science Summary and the Reproducible FAIR Best Practices. The 2023 Climate Pilot and Disaster Pilot reports provide additional insights into requirements and use cases. The OGC ERs define draft specifications for interoperability leveraging OGC APIs, building blocks, and details implementation of items including draft APIs, data retrieval and discovery, cloud computing, and Machine Learning. Implementations of OGC’s draft GDC API have been demonstrated with use cases including the integration of terrestrial and marine elevation data and forestry information for Canadian wetlands, providing practical examples of relevant work. The OGC Testbed-16: Data Access and Processing Engineering Report (20-016) summarizes the results of work to develop methods and apparatus to simplify access to, processing of, and exchange of environmental and Earth Observation (EO) data from an end-user perspective, as exemplified by the openEO initiative’s work to develop an open API to connect R, Python, JavaScript and other clients to big Earth observation cloud back-ends. This prior work, related initiatives to develop and implement CRIS and disaster and emergency response information systems, and the FAIR principles provide the framework for the CDRP24.

3. Objectives

The CDRP24 aims to enable the stakeholder community to take impactful action to increase Climate Resilience and improve Emergency and Disaster Management by making our collective research, data, models, and services toward more Findable, Accessible, Interoperable, and Reusable (FAIR). Through this work, OGC’s CDRP2024 supports the UN’s Agenda 2023 global Sustainable Development Goals and the goals of the United Nations Office for Disaster Risk Reduction.

The CDRP24 objectives are to:

  1. Create practical technology demonstrators and working prototypes that:

    1. Connect climate resilience and disaster and emergency management information systems, services, or applications and make them more FAIR.

    2. Transform raw data into information valuable to the stakeholder communities for decision making and promoting sustainability through mitigation and adaptation.

    3. Create and document reproducible workflows that enable users to innovate by building on the OGC CDRP24’s work.

  2. Produce effective visualizations and simulations that:

    1. Communicate through visualization the value of absorbing information quickly; reviewing what-if scenarios; optimizing climate, extreme event, and disaster systems decision making details.

    2. Communicate the value of interoperable systems for climate and disaster applications to public communities and non-technical decision makers.

    3. Provide added value through narrative of the impacts and public benefits of the CDRP24’s outcomes.

  3. Publish documentation of technical materials that:

    1. Explains how the technology can be used to meet stakeholder needs

    2. Supports the reuse of demonstrators and prototypes to enable uptake by the wider stakeholder community

    3. Facilitates incorporation of CDRP24 outputs into learning materials.

  4. Author a publicly available Engineering Report (ER) that:

    1. Provides critical information of the composition of the stakeholder community.

    2. Captures stakeholder needs based on workshops and co-design activities.

    3. Provides a Gap Analysis based on prototyping of workflows and discussions of participants, identifying interoperability issues and data integration challenges present in current system designs.

3.1. Benefits to the stakeholder community

The outcomes of the CDRP24 initiative will benefit not only its sponsors and direct Participants, but the broader stakeholder community through:

  • The creation of a shared forum for technical experts, domain experts, and users of geospatial data and systems across the Climate Resilience and Emergency and Disaster Management communities.

  • Building an integrated source of information on key technologies, standards, and data critical for geospatially-enabled applications across both climate and disaster resilience.

  • Providing insights into where the geospatial data and infrastructure needs of Climate and Disaster and Emergency Management stakeholders intersect and diverge.

  • Making connections between the Climate, Disaster, and Emergency Management communities and the communities engaged in related OGC initiatives to seed future collaborations and create opportunities for new partnerships.

3.2. Benefits to participants

This initiative provides an outstanding opportunity to connect with stakeholders across the Climate, Disaster, and Emergency Management ecosystem, engage with the latest research on geospatial system design, concept development, and rapid prototyping with organizations (Sponsors & Participants) across the globe. The initiative provides a business opportunity for stakeholders to mutually define, refine, and evolve service interfaces and protocols in the context of hands-on experience and feedback. The OGC Climate and Disaster Resilience Pilot will contribute towards an open, multi-level infrastructure that integrates data spaces, open science, and local-to-international requirements and objectives. It will contribute to the technology and governance stack that enables the integration of data including historical observations, real time sensing data, reanalyses, forecasts and future projections. It addresses data-to-decision pipelines, data analysis and representation, and bundles everything in climate and disaster resilience building blocks. These building blocks will be complemented by Good Practices, guidelines, and cook-books that enable multi–stakeholder decision-making, creating public benefits in a changing natural environment. The Sponsors are supporting this vision with cost-sharing funds to partially offset the costs associated with development, engineering, and demonstration of these outcomes. This offers selected Participants a unique opportunity to recoup a portion of their initiative expenses. OGC COSI Program Participants benefit from:

  • Access to funded research & development

  • Reduced development costs, risks, and lead-time of new products or solutions

  • Close relationships with potential customers

  • First-to-market competitive advantage on the latest geospatial innovations

  • Influence on the development of global solutions and standards

  • Partnership opportunities within our community of experts

  • Broader market reach via the recognition that OGC standards bring.

4. Master Schedule

The following table details the major Initiative milestones and events for the Climate and Disaster Resilience Pilot 2024. Dates are subject to change.

Table 1. Master Schedule
Milestones Project Month Description

M01

20 November 2023

Public Release: Call for Participation

M02a

8 December 2023

Questions due for Bidders Q&A Webinar

M02b

11 December 2023 11:00am - 12:00 noon Eastern

Bidders Q&A Webinar - Recording
Bidders Q&A Webinar - Slides
Bidders Q&A Webinar - Transcript
See Appendix D for written Questions and Answers

M03

30 January 2024

Proposals Due

M04

28-29 February 2024

2-day Kick-off workshop for implementation

M05

10 May 2024

Use Cases Due and Initial Engineering Reports (IERs)

M06

29 May 2024

Preliminary Virtual Demo

M07

17 June 2024

Aggregated Demo at Closing Workshop at OGC Member Meeting Montreal, Canaday

M08

28 June 2024

Engineering Report draft submission read

M09

26 July 2024

Pilot report submitted for evaluation by the Climate Resilience DWG / Emergency Response DWG

M10

19 August 2024

Development of call for participation for 2025 CDRP Pilot

During the pilot, virtual weekly check-ins will be held for participants to discuss progress, highlight challenges, and share views on key issues. Participants in meetings will contribute to the pilot’s final report by providing quick comments after each meeting, capturing discussion and lessons learned which will complement the technical outcomes included in the report.

5. Participation

5.1. Who can participate

The OGC welcomes proposals to participate in its Initiatives from organizations and individuals active in the development, management, and use of geospatial data, technologies and systems. Proposers may be active in industry, government (national, regional, local), research, non-profit, community, or other sectors. Past participants have included providers of services and platforms, modelers, end users of platforms and data, researchers, and other stakeholders in relevant domains.

You do not need to be a member of the Open Geospatial Consortium to propose to participate. If your organization’s proposal is selected, you or your organization must become an OGC member if not already one. This is to ensure all participants have equal access to the tools and documentation developed and shared throughout the project phase.

5.2. How to participate

The CDRP24 is designed to enable interested organizations to participate in a range of ways, from simply engaging in the co-design process without committing any resources other than the participant’s time, to providing funding, in-kind or paid services, or providing a resource such as a dataset or access to infrastructure. Key mechanisms for engagement include:

  • Provide technical expertise Commit staff time to the Pilot to regularly join meetings, develop data and software components, test and evaluate implementations, or produce documentation. Contribute your organization or community’s perspective on how tools should be designed and what would meet your needs as a user by actively participating in workshops and co-design exercises. Add your perspective as a technical or domain expert by providing feedback on the design and implementation of the architecture.

  • Provide a use case Share a real world case study which can be used to inform the development of the OSPD architecture and demonstrate how it can be used to create more FAIR processes and workflows, leading to better outcomes for users. Sample use cases may be provided when you make your proposal with the expectation that these would be refined in consultation with other OSPD Pilot team members.

  • Provide data or tools Make an contribution of existing data, platforms, research or other resources (e.g. models, digital infrastructure components) to support the Pilot.

6. Technical Objectives

This section identifies the technical objectives of the CDRP24 Initiative and the corresponding activities and deliverables participants make a proposal (bid) to undertake in order to help achieve the Initiative’s aims. These activities and deliverables constitute the major part of each participant’s contribution to the CDRP24 Initiative, together with their contribution to Engineering Reports and other materials capturing the process.

It is expected that proposals to achieve these technical objectives will build on and refer to the OGC standards baseline, i.e. the complete set of member approved Abstract Specifications, Standards including Profiles and Extensions, and Community Practices, where relevant.

Technical Objectives are organized under two tasks:

  • Task 1: Stakeholder and Decision-Maker Needs for Linked Climate and Disaster Resilience Information Systems

  • Task 2: Interoperable Climate and Disaster Resilience Capabilities to Address Landslides

These outputs of these tasks may be combined into common use cases, workflows, learning materials or other deliverables. The tasks will be reported on in a single collective Engineering Report (D001) which summarizes key findings and provides connections to other outputs and products.

It is anticipated that a third task focused on European use cases will be added in a future stage of the CDRP24.

All participants in the CDRP are expected to actively participate in the OGC member meeting in Montreal in 2024.

Deliverable D001 Engineering Report – Co-editorship of an Engineering Report capturing key results and experiences from this project. The Engineering Report will contain a plain language executive summary to clearly outline the motivations, goals, and critical outcomes of this Initiative. It will include sections on the Interoperability gap analysis; Usability of data products for specific use cases (e.g. in support of the IPCC, natural and weather related disasters); and Integration of complementary data (e.g. statistics on human population, health, species distributions, global biodiversity, data from INSPIRE). The report will be produced in collaboration with OGC staff.

6.1. Stakeholder and Decision-Maker Needs for Linked Climate and Disaster Resilience Information Systems

This task focuses on refining the OGC community’s shared understanding of stakeholder needs, the modernization of Spatial Data Infrastructures (SDIs) to support increased transparency and reproducibility, and the development of use cases for future integrated Climate Resilience Information Systems (CRIS) and Disaster Resilience Information Systems, building on OGC API process-based modules and OGC Climate Building blocks and including the following focus areas:

6.1.1. Task Specific Objectives

  • Understanding the user community and their requirements e.g. mapping the target users or performing a gap analysis of how information products meet the needs generated by policy frameworks for Strategy Development, Monitoring, Reporting, and Validation.

    • Central to this objective is identifying key components, workflows, as well as stakeholder-identified gaps in the value chain from data to Analysis Ready Data to Decision Ready Indicators that supports timely decision making and Federal, State, regional and international data more relevant to decision maker needs.

  • Building the value chain from raw data to climate information e.g. designing an interoperable data pipeline to move an existing set of systems towards being FAIR Climate Resilience Information Systems and deployment of Artificial Intelligence capabilities for greater efficiencies (building on the outcomes of the OGC CLINT and Disaster 2023 Pilots)

    • Value chains including data and information relevant to the following are of particular interest:

      • Flooding and Inundation, e.g. connecting lidar data and weather models to flood risk maps using data sources such as SWOT or data from 3DHP

      • Extreme Heat and Cold Events, e.g. linking data on planned urban development with models of urban heat islands

      • Droughts, desertification, and land degradation, e.g. combining SAR and spectral data with soil maps to model potential agricultural erosion

      • Landslides and Debris Flows, e.g. integrating landslide risk models into reforestation planning models

      • Wildfires, e.g. integrating species richness and forest age data into response planning models or integrating climate change-aware models of vulnerability into applications that support risk assessment for insurance

      • Compounding Risks, e.g. connecting models of natural disasters or species ranges with data on increasing or emerging disease

  • Creating Climate and disaster resilience application packages e.g. creating packages that contain well organized and documented suites of data, software tools, parameters, and metadata (an ‘application package’) for modeling extreme weather events or assessments of climate change impacts under the IPCC projected climate Shared Socio-economic Pathways (SSP) scenarios.

    • Application packages leveraging the following are of particular interest:

    • A broader priority area is demonstrating the integration of open architectures and standards (e.g. Geopackage, Tile, SensorThings, Modeling and Simulation, etc.) and technologies such as Artificial Intelligence, Cloud, etc. and how OGC API suite can improve access and adoption.

    • A technical focus area is the development of Decision Ready Indicators and product specifications that will emphasize the use of models and generative ML / AI to improve disaster prediction, fill in data gaps, provide actionable. summarization of large data flows, and support improved discovery and access for the wildly diverse federal, state, regional, commercial, academic, and international data sources which could be leveraged for improved decision making.

    • Support of public-private partnerships and use of public data and open standards and technologies to drive socially responsible innovation in commercial and private sector applications is essential to address the impacts of climate change at scale. Applications in clean energy, energy resilience, GHG emissions reduction, mitigation and sequestration, insurance, landscape and infrastructure planning and management are all encouraged. Leveraging of data that provides insights into the social and economic dimensions of climate and disaster resilience efforts, such as US Census data, are actively encouraged.

  • Visualization and Simulation e.g. developing a 3D visualization leveraging interoperable climate and disaster resilience data systems or generating simulations on demand.

CDRP fig2
Figure 2. Data, Metadata, Parameters and Code are bundled into Application Packages, which may be connected to one another and reuse components. This example schematic shows how a climate application package might connect to one used in emergency management.



6.1.2. Task Specific Work Items and Deliverables

The following list identifies all deliverables that are part of this task. In addition to producing the deliverables against which they bid, all participants are required to participate in all technical discussions and support the development of the Engineering Report (D001) with their contributions. Several instances of each deliverable may be funded.

  • D118 - ARD to DRI Report Section: Produce an Engineering Report section that identifies needs and key components, workflows, as well as stakeholder-identified gaps in the value chain from data to Analysis Ready Data to Decision Ready Indicators that support timely decision making.

  • D119 - Health Impact Workflows: Implemented workflows to produce indicators of health impacts of extreme events. This deliverable should take the form of a working prototype (software packages or scripts) provided as a package.

  • D121 - Weather Event Workflows: Implemented workflows of suites of data, software tools, and sensor data for a digital twin of weather events and /or assessments of climate change impacts creating a digital twin for urban scenario development. This deliverable should take the form of a working prototype (software packages or scripts).

  • D123 - AI Advances of SDIs Report Section: Produce an Engineering Report section that identifies and evaluates metadata and SDI advances and efficiencies through the use of Artificial Intelligence capabilities. This section could be informed by assessments of user needs as well as technical assessments of potential advances and efficiencies.

  • D124 - 3D Viz of CDRP Data System: Provide a 3D visualization capability leveraging interoperable climate and disaster resilience data systems or related simulations to communicate the value of outputs of this task to the wider stakeholder community.

CDRP fig3
Figure 3. CDRP Task 2.2 Deliverables and Activities



6.2. Interoperable Climate and Disaster Capabilities to Predict and Resist Landslides

Understanding and clarifying current and historical factors resulting in landslides, debris flows and flooding is critical for hazard prevention. While realizing climate, weather events, and geologic data can be combined to increase model accuracy of where and who may be at risk of landslides and flooding, reducing the uncertainty and creating digital twins to run differing scenarios would advance understanding and mitigation considerably. This work includes the use of interoperability to link data and analytical modeling processes across climate, digital twins, and disaster planning applications.

This task focuses on refining the OGC community’s shared understanding of stakeholder needs and the development of use cases for future integrated Climate Resilience Information Systems (CRIS) and disaster resilience frameworks, building on OGC API process-based modules and OGC Climate Building blocks and including the following specific objectives:

6.2.1. Task Specific Objectives

  • Combining Climate and Standard Services Methods e.g. evaluate methods of combining climate and standard data and services to improve landslide prediction and mitigation through climate data usage.

    • A central effort will be to identify key components, and workflows in the value chain. Current estimation data from the International Panel on Climate Change (IPCC) database does not provide sufficient detail and accuracy. The objective is to assess the gap between the applications’ requirements and current data sources’ properties and subsequently to identify data sources and workflows that decrease uncertainty.

  • Implementation of a Digital Twin (DT) for Landslides e.g. creating a DT with current data products such as typhoon data, sensor data, etc. to enable forecast sequences that could improve prediction and mitigation of landslides.

    • Any relevant data may be used to meet this objective. Value chains including data and information relevant to the following are of particular interest:

      • Flooding and Inundation, e.g. connecting lidar data and weather models to flood risk maps

      • Droughts, typhoons, and land degradation, e.g. combining SAR and spectral data with soil maps to model potential agricultural erosion

      • Landslides and Debris Flows, e.g. integrating landslide risk models into reforestation planning models

  • Evaluate Early Warning System for Flooding, e.g. use data and workflows to evaluate using a similar system to the Agency of Rural Development and Soil and Water Conservation (ARDSWC) Yellow and Red warning mechanism.

    • Identifying key components and workflows in the value chain from Analysis Ready Data to Decision Ready Indicators that support timely decision making is a central part of this work.

    • Building a value chain from raw data to climate information and designing interoperable pipelines to move existing systems towards being FAIR and deployment of AI capabilities for improved warning systems are priorities.

      • Flooding and Inundation, e.g. connecting lidar data and weather models to flood risk maps; combining SAR and spectral data with soil maps to model potential erosion

    • Evaluation of the possibilities to modify, enhance accuracy and simulation of the early warning mechanism is important for this work.

6.2.2. Task Specific Work Items and Deliverables:

The following list identifies all deliverables that are part of this task. In addition to producing the deliverables against which they bid, all participants are required to participate in all technical discussions and support the development of the Engineering Report (D001) with their contributions. Several instances of each deliverable may be funded.

  • D130 - Typhoons and Atmospherics Report Section: An Engineering Report section that identifies key components and workflows for typhoons, atmospheric rivers, and any other related extreme atmospheric conditions to interoperate with the climate data being used in the current system.

  • D131 - Landslide Demonstrators: Working demonstrators which implement workflows to produce indicators of landslide with improved typhoon and/or atmospheric data. These should be delivered as a package of components e.g. software applications and scripted workflows or user interfaces and scripts. More than one instance of this deliverable may be funded.

  • D132 - Early Warning Flood Demonstrators: A prototype workflow or operational prototype system (software or script) demonstrating an early warning system for flooding compatible with the ARDSWC Yellow / Red Landslide system and documentation of an implementable workflow. The prototype should be based on an evaluation of the possibilities to modify, enhance accuracy and simulation of the early warning mechanism.

  • D133 - Mountain Context Visualization: Provide a 3D visualization of underground assets, leveraging interoperable climate and disaster resilience data systems or related simulations, for a mountain context.

CDRP fig4
Figure 4. CDRP Task 2.3 Deliverables and Activities



7. Deliverables Summary

The following list identifies all document and component deliverables that are being sought to support the Pilot. All participants are required to participate in all technical discussions, support the development and testing of the overall Pilot ecosystem, and contribute appropriately to reports, videos, demonstrators, and other outreach activities.

Table 2. Deliverables
CFP Section Deliveable # Description

2

D101

Engineering Report – Co-editorship of an Engineering Report capturing key results and experiences from this project. The Engineering Report will contain a plain language executive summary to clearly outline the motivations, goals, and critical outcomes of this Initiative. It will include sections on the Interoperability gap analysis; Usability of data products for specific use cases (e.g. in support of the IPCC, natural disasters); and Integration of complementary data (e.g. statistics on human population, health, species distributions). The report will be produced in collaboration with OGC staff.

2.2

D118

Produce an Engineering Report section that identifies needs and key components, workflows, as well as stakeholder-identified gaps in the value chain from data to Analysis Ready Data to Decision Ready Indicators that support timely decision making. This section should include information on the character of the stakeholder community engaged in its production.

D119

Implemented workflows to produce indicators of health impacts of extreme events. This deliverable should take the form of a working prototype (software packages or scripts) provided as a package.

D121

Implemented workflows of suites of data, software tools, and sensor data for a digital twin of weather events and /or assessments of climate change impacts creating a digital twin for urban scenario development. This deliverable should take the form of a working prototype (software packages or scripts).

D123

Produce an Engineering Report section that identifies and evaluates metadata and SDI advances and efficiencies through the use of Artificial Intelligence capabilities. This section could be informed by assessments of user needs as well as technical assessments of potential advances and efficiencies.

D124

Provide a 3D visualization capability leveraging interoperable climate and disaster resilience data systems or related simulations to communicate the value of outputs of this task to the wider stakeholder community.

2.3

D130

An Engineering Report section that identifies key components and workflows for typhoons, atmospheric rivers, and any other related extreme atmospheric conditions to interoperate with the climate data being used in the current system.

D131

Working demonstrators which implement workflows to produce indicators of landslide with improved typhoon and/or atmospheric data. These should be delivered as a package of components e.g. software applications and scripted workflows or user interfaces and scripts. More than one instance of this deliverable may be funded.

D132

A prototype workflow or operational prototype system (software or script) demonstrating an early warning system for flooding compatible with the ARDSWC Yellow / Red Landslide system and documentation of an implementable workflow. The prototype should be based on an evaluation of the possibilities to modify, enhance accuracy and simulation of the early warning mechanism.

D133

Provide a 3D visualization of underground assets, leveraging interoperable climate and disaster resilience data systems or related simulations, for a mountain context.

7.1. Collective Engineering Report

Each participant in the CDRP24 will contribute to a collective Engineering Report (D001) documenting their contributions to the collaborative solutions developed during the pilot. The report will reflect the main threads of the discussions held during the weekly meetings. In their contributions to the report, participants will be asked to describe the implemented process, report about successes and failures, and provide an overview of additional data, processing capacities, or other currently missing elements that would improve the use case implementation in future. An important element of this pilot is the documentation of what does not work.

Participant(s) co-leading editorial work will:

  • Maintain and regularly update drafts of the report in a github repository, using a metanorma template

  • Integrate contributions from all participants into the report and help synthesize the main discussion points regularly after each meeting.

  • Format text and graphic files according to the metanorma template to produce the final report.

  • Collaborate closely with the coordinator of the pilot (OGC staff) to produce the final report.

8. OGC COSI Program Initiatives

This initiative is being conducted under the OGC Collaborative Solutions and Innovation (COSI) Program. The OGC COSI Program aims to solve the biggest challenges in location. Together with OGC-members, the COSI Team is exploring the future of climate, disasters, autonomy and robots, outer space systems interoperability, defense and intelligence, and more.

The OGC COSI Program is a forum for OGC members to solve the latest and hardest geospatial challenges via a collaborative and agile process. OGC members (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 100 funded initiatives have been executed - from small interoperability experiments run by an OGC working group to multi-million dollar testbeds with more than three hundred OGC-member participants.

OGC COSI initiatives promote rapid prototyping, testing, and validation of technologies, such as location standards or architectures. Within an initiative, OGC Members test and validate draft specifications to address geospatial interoperability requirements in real-world scenarios, business cases, and applied research topics. This approach not only encourages rapid technology development, but also determines the technology maturity of potential solutions and increases the technology adoption in the marketplace.

The OSPD is beginning to create a persistent platform whose core components include a workflow building application which connects multiple open science platforms, an experimentation environment for trialing platforms and workflows, a training and education area, and result visualization environments. The aim is not to develop another analytical or research platform, but to improve the experience of users of multiple platforms, leverage the power of existing platforms, provide training on workflows across multiple platforms, and experiment with advanced visualization across whole workflows, as depicted below.

OSPD architecture diagram
Figure 5. Open Science Persistent Demonstrator Technical Architecture Overview



Participants in the CDRP24 pilot are encouraged to consider engaging in future phases of the Open Science Persistent Demonstrator (OSPD) to integrate platforms, services and other technologies developed through the CDRP24 into the OSPD.

9.1. Information on bidding, selection, and key requirements

Responding to the Call For Participation (CFP):

To respond to the CFP as a bidder, you will submit an Online Form in which you describe your proposal. This proposal should include your (the bidder’s) technical solution(s) for each deliverable, cost sharing request(s) for funding, and proposed in-kind contribution(s) to the initiative.

The CFP includes a description of the deliverables against which bidders may submit proposals. Bidders may address technical deliverables, such as implementing a component of an infrastructure, or participatory deliverables, such as contributing to meetings and to writing documents. The timeline for completion of the deliverables is set out in the Master Schedule.

Proposal Evaluations will take place on a per-deliverable basis. Therefore, it is important that all proposals should all be entered into the form on a per-deliverable basis.

Proposals in response to the CFP should be submitted by the deadline listed in the Master Schedule.

Questions and Requests for clarification: Bidders have the opportunity to submit questions about the CFP for an initial Q&A Webinar. Questions can be submitted using this Form. Bidders who cannot access the Form should send an email to cdrp-questions@ogc.org. The Bidders Q&A Webinar will be held on the date listed in the Master Schedule. The webinar is open to the public, but anyone wishing to attend must register using the provided link. Questions are due on the date listed in the Master Schedule Question submitters will remain anonymous, and answers will be compiled and published in the CFP clarifications.

After the initial Q&A Webinar bidders may submit further questions using the same Form. Again, question submitters will remain anonymous. Ongoing updates and answers to questions will be added to the CFP Corrigenda Table and the CFP Clarifications Table. The HTML version of the CFP will be updated automatically and appear at the same URL as the original version. The PDF file online will be updated following each revision. You should download a new copy for offline work regularly to ensure you are referring to the latest version.

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

Required attendance at the Kickoff: The Kickoff is a meeting where Participants, guided by the Initiative Architect, will refine the Initiative architecture and settle on specifics 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 interface Designs.

Required attendance at Regular Telecons and Meetings: After the Kickoff, participants will meet frequently via weekly telecons (videoconferencing) and in person at OGC Member Meetings. As a minimum, participants are required to attend virtual meetings regularly.

Requirements for Development of Deliverables: Development of Components, Engineering Reports, Change Requests, and other deliverables will commence during or immediately after the Kickoff meeting.

Under the Participation Agreement contracts, ALL Participants will be responsible for contributing content to the documents / ERs, particularly regarding their component implementation experiences, findings, and future recommendations. Each participant will be required to provide at least one bullet point per week to the ER on work, progress, technical conversations and decisions, etc., while the ER Editor will be the primary compiler and author on the shared sections such as the Executive Summary. The ER editor is further responsible for capturing all design decisions and lessons learned during the whole initiative execution phase. Compiling the whole report at the end of the initiative does not work!

More detailed deliverable descriptions appear under Types of Deliverables.

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 webinars, demonstration events, and other meetings.

Assurance of Service Availability: Participants selected to implement service components must maintain availability for a period of no less than twelve months after the Participant Final Summary Report milestone.

Appendix A: Pilot Organization and Execution

A.1. Initiative Policies and Procedures

This initiative will be conducted within the policy framework of OGC’s Bylaws and Intellectual Property Rights Policy ("IPR Policy"), as agreed to in the OGC Membership Agreement, and in accordance with the OGC COSI Program Policies and Procedures and the OGC Principles of Conduct, the latter governing all related personal and public interactions. Specifically:

Several key requirements are summarized below for ready reference:

  • Each selected Participant will agree to notify OGC staff if it is aware of any claims under any issued patents (or patent applications) which would likely impact an implementation of the specification or other work product which is the subject of the initiative. Participant need not be the inventor of such patent (or patent application) in order to provide notice, nor will Participant be held responsible for expressing a belief which turns out to be inaccurate. Specific requirements are described under the "Necessary Claims" clause of the IPR Policy.

  • Each selected Participant will agree to refrain from making any public representations that draft Engineering Report (ER) content has been endorsed by OGC before the ER has been approved in an OGC Technical Committee (TC) vote.

  • Each selected Participant will agree to provide more detailed requirements for its assigned deliverables, and to coordinate with other initiative Participants, at the Kickoff event.

A.2. Initiative Roles

The roles generally played in any OGC COSI Program initiative include Sponsors, Bidders, Participants, Observers, and the COSI Program Team. Explanations of the roles are provided in Tips for New Bidders.

The COSI 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 high-impact issues or risks that might arise during execution.

A.3. Types of Deliverables

All activities in this pilot will result in a Deliverable. These Deliverables generally take the form of a persistent demonstrator capability, Documents or Component Implementations.

A.4. 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 COSI Program to Sponsors and to the OGC Standards Program for consideration by way of Standards Working Groups and Domain Working Groups.

Tip

A common ER Template will be used as the starting point for each document. Various template files will contain requirements such as the following (from the 1-summary.adoc file):

The Executive Summary shall contain a business value statement that should describe the value of this Engineering Report to improve interoperability, advance location-based technologies or realize innovations.

Ideas for meeting this particular requirement can be found in the CFP Background as well as in previous ER content such as the business case in the Executive Summary.

Document content should follow this OGC Document Editorial Guidance (scroll down to view PDF file content). File names for documents posted to Pending should follow this pattern (replacing the document name and deliverable ID): OGC CDRP24 DocumentName (D001). For ERs, the words Engineering Report should be spelled out in full.

A.4.1. Component Implementations

Component Implementations include services, clients, datasets, and tools. A service component is typically delivered by deploying an endpoint via an accessible URL. A client component typically exercises a service interface to demonstrate interoperability. Implementations should be developed and deployed in all threads for integration testing in support of the technical architecture.

IMPORTANT

Under the Participation Agreement contracts, ALL Participants will be responsible for contributing content to the ERs, particularly regarding their component implementation experiences, findings, and future recommendations. The ER Editor will be the primary author on shared sections such as the Executive Summary.

Component implementations are often used as part of outreach demonstrations near the end of the timeline. To support these demonstrations, component implementations are required to include Demo Assets. For clients, the most common approach to meet this requirement is to create a video recording of a user interaction with the client. These video recordings may optionally be included in a new YouTube Playlist on the OGC YouTube channel.

Tip

Videos to be included in a new YouTube Playlist should follow these instructions: Upload the video recording to the designated Portal directory (to be provided), and include the following metadata in the Description field of the upload dialog box:

  • A Title that starts with "OGC CDRP:", keeping in mind that there is a 100-character limit [if no title is provided, we’ll insert the file name],

  • Abstract: [1-2 sentence high-level description of the content],

  • Author(s): [organization and/or individuals], and

  • Keywords: [for example, OGC, CDRP24, machine learning, analysis ready data, etc.].

Since server components often do not have end-user interfaces, participants may instead support outreach by delivering static UML diagrams, wiring diagrams, screenshots, etc. In many cases, the images created for an ER will be sufficient as long as they are suitable for showing in outreach activities such as Member Meetings and public presentations. A server implementer may still choose to create a video recording to feature their organization more prominently in the new YouTube playlist. Another reason to record a video might be to show interactions with a "developer user" (since these interactions might not appear in a client recording for an "end user").

Tip

Demo-asset deliverables are slightly different from Technology Interoperability Experiment (TIE) testing deliverables. The latter don’t necessarily need to be recorded (though they often appear in a recording if the TIE testing is demonstrated as part of one of the recorded weekly telecons).

A.5. Proposals & Proposal Evaluation

Proposals are expected to be brief, broken down by deliverable, and precisely addressing the work items of interest to the bidder. Details of the proposal submission process are provided under the General Proposal Submission Guidelines.

Proposals will be evaluated based on criteria in two areas: technical and management/cost.

A.5.1. Technical Evaluation Criteria

  • Concise description of each proposed solution and how it contributes to achievement of the particular deliverable requirements described in the Technical Architecture,

  • Overall quality and suitability of each proposed solution, and

  • Where applicable, whether the proposed solution is OGC-compliant.

Management/Cost Evaluation Criteria
  • Willingness to share information and work in a collaborative environment, Contribution toward Sponsor goals of enhancing availability of standards-based offerings in the marketplace,

  • Feasibility of each proposed solution using proposed resources, and

  • Proposed in-kind contribution in relation to proposed cost-share funding request.

Note that all Participants are required to provide some level of in-kind contribution (i.e. costs for which no cost-share compensation has been requested). As a rough guideline, a proposal should include at least one dollar of in-kind contribution for every dollar of cost-share compensation requested. All else being equal, higher levels of in-kind contributions will be considered more favorably during evaluation. Participation may also take place by purely in-kind contributions (no cost-share request at all).

Once the proposals have been evaluated and cost-share funding decisions have been made, the COSI Team will begin notifying Bidders of their selection to enter negotiations to become and initiative Participant. Each selected bidder will enter into a Participation Agreement (PA), which will include a Statement of Work (SOW) describing the assigned deliverables.

A.5.2. Reporting

Participants will be required to report the progress and status of their work; details will be provided during contract negotiation. Additional administrative details such as invoicing procedures will also be included in the contract.

Monthly Reporting

The COSI Team will provide monthly progress reports to Sponsors. Ad hoc notifications may also occasionally be provided for urgent matters. To support this reporting, each testbed participant must submit (1) a Monthly Technical Report and (2) a Monthly Business Report by the first working day on or after the 3rd of each month. Templates and instructions for both of these report types will be provided.

The purpose of the Monthly Business Report is to provide initiative management with a quick indicator of project health from each participant’s perspective. The COSI Team will review action item status on a weekly basis with assigned participants. Initiative participants must remain available for the duration of the timeline so these contacts can be made.

Participant Final Summary Reports

Each Participant should submit a Final Summary Report by the milestone indicated in the Master Schedule. These reports should include the following information:

  1. Briefly summarize Participant’s overall contribution to the Initiative (for an executive audience),

  2. Describe, in detail, the work completed to fulfill the Participation Agreement Statement of Work (SOW) items (for a more technical audience), and

  3. Present recommendations on how we can better manage future OGC COSI Program initiatives.

This report may be in the form of email text or an attached document (at the Participant’s discretion).

Appendix B: Proposal Submission

B.1. General Proposal Submission Guidelines

This section presents general guidelines for submitting a CFP proposal. Detailed instructions for submitting a response proposal using the Bid Submission Form web page can be found in the Step-by-Step Instructions below.

Important

Please note that the content of the "Proposed Contribution" text box in the Bid Submission Form will be accessible to all Stakeholders and should contain no confidential information such as labor rates.

Similarly, no sensitive information should be included in the Attached Document of Explanation.

Proposals must be submitted before the deadline indicated in the Master Schedule.

Tip

Non-members or individual members should make a note regarding their intent to join OGC on the Organizational Background page of the Bid Submission Form and include their actual Letter of Intent as part of an Attached Document of Explanation.

Information submitted in response to this CFP will be accessible to OGC and Sponsor staff members. 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 a Participant, they will be required to release proposal content (excluding financial information) to all initiative stakeholders. Sensitive information other than labor-hour and cost-share estimates should not be submitted.

Bidders will be selected for cost share funds on the basis of adherence to the CFP requirements and the overall proposal quality. The general initiative objective is to inform future OGC standards development with findings and recommendations surrounding potential new specifications. Each proposed deliverable should formulate a path for (1) producing executable interoperable prototype implementations meeting the stated CFP requirements and (2) documenting the associated findings and recommendations. Bidders not selected for cost share funds may still request to participate on a purely in-kind basis.

Bidders should avoid attempts to use the initiative as a platform for introducing new requirements not included in 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. Out-of-scope items could potentially be included in another OGC COSI initiative.

Each selected Participant (even one not requesting any funding) will be required to enter into a Participation Agreement contract ("PA") with the OGC. The reason this requirement applies to purely in-kind Participants is that other Participants will likely be relying upon the delivery of their work. Each PA will include a Statement of Work ("SOW") identifying specific Participant roles and responsibilities.

B.2. Questions and Clarifications

Once the original CFP has been published, ongoing updates and answers to questions can be found in the CFP Corrigenda Table and the CFP Clarifications Table

Bidders may submit questions using the Questions Form or by emailing cdrp-questions@ogc.org. When using the form, bidders should check ‘COSI (Innovation)’ from the list of ‘Interests’ and write the Initiative for which they are bidding and their question in the ‘Message’ box. Question submitters will remain anonymous, and answers will be regularly compiled and published in the CFP clarifications.

A Bidders Q&A Webinar will be held on the date listed in the Master Schedule. The webinar is open to the public, but anyone wishing to attend must register using the provided link. Questions are due on the date listed in the Master Schedule.

B.3. Proposal Submission Procedures

The process for a Bidder to complete a proposal is set out in the online Bid Submission Form.

The Bid Submission form will be made available shortly after the CFP release. It will include a series of web forms, one for each deliverable of interest. Bidders should remember to submit one form for each deliverable for which they wish to submit a proposal.

New users must create an account before completing a form.

Once an account is established, the user may log in and will be taken to a home page indicating the "Status of Your Proposal." The user can return to this page at any time by clicking the OGC logo in the upper left corner.

Any submitted bids will be treated as earnest submissions, even those submitted well before the response deadline. Be certain that you intend to submit your proposal before you click the Submit button on the Review page.

Important

Please consider making local backup copies of all text you are entering into the form in case anything needs to be re-entered. If you encounter any technical problems, please contact the OGC.

B.3.1. High-Level Overview

Clicking on the “Propose” link will bring you to the Bid Submission Form.

To complete the form, new users should start by providing organizational information on the “Organizational Background” Page and click “Update” and “Continue”. Existing users should check and confirm the information on the “Organizational Background” Page is correct and click “Continue”.

This will navigate to an "Add Deliverable" page. The user should complete this form for each proposed deliverable.

Tip

For component implementations having multiple identical instances of the same deliverable, the bidder only needs to propose just one instance. For simplicity, each bidder should just submit against the lowest-numbered deliverable ID. OGC will assign a unique deliverable ID to each selected Participant later (during negotiations).

A “Review” link, located on the far right of the screen, navigates to a page summarizing all the deliverables the Bidder is proposing. This Review tab won’t appear until the user has actually submitted at least one deliverable under the Propose tab first.

Tip

Consider regularly creating backup copies of this Review page at various points during proposal creation.

Once the “Submit” button is clicked, the user will receive an immediate confirmation on the website that their proposal has been received. The system will also send an email to the Bidder and to OGC staff.

Tip

In general, up until the time that the user clicks this Submit button, the proposal may be edited as many times as the user wishes. However, this initial version of the form contains no "undo" capability, so please use caution in over-writing existing information.

Under the “Done Adding Deliverables” section at the bottom of this page, a user may attach an additional document with further information and explanations. This document is optional.

Important

No sensitive information (such as labor rates) should be included in the Attached Document.

If this attachment is provided, it is limited to one per proposal and must be less than 5Mb.

This document could conceivably contain any specialized information that wasn’t suitable for entry into a Proposed Contribution field under an individual deliverable. It should be noted, however, that this additional documentation will only be read on a best-effort basis. There is no guarantee it will be used during evaluation to make selection decisions; rather, it could optionally be examined if the evaluation team feels that it might help in understanding any specialized (and particularly promising) contributions.

B.3.2. Step-by-Step Instructions

The “Propose” link takes the user to the first page of the proposal entry form. This form contains fields to be completed once per proposal such as names and contact information.

It also contains an optional Organizational Background field where Bidders (particularly those with no experience participating in an OGC initiative) may provide a description of their organization. It also contains a click-through check box where each Bidder will be required (before entering any data for individual deliverables) to acknowledge its understanding and acceptance of the requirements described in this appendix.

Clicking the Update and Continue button then navigates to the form for submitting deliverable by deliverable bids. On this page, existing deliverable bids can be modified or deleted by clicking the appropriate icon next to the deliverable name. Any attempt to delete a proposed deliverable will require scrolling down to click a Confirm Deletion button.

To add a new deliverable, the user would scroll down to the Add Deliverable section and click the Deliverable drop-down list to select the particular item.

The user would then enter the required information for each of the following fields (for this deliverable only). Required fields are indicated by an asterisk: * Estimated Projected Labor Hours* for this deliverable, * Funding Request*: total U.S. dollar cost-share amount being requested for this deliverable (to cover burdened labor only), * Estimated In-kind Labor Hours* to be contributed for this deliverable, and * Estimated In-Kind Contribution: total U.S. dollar estimate of the in-kind amount to be contributed for this deliverable (including all cost categories).

Tip

There’s no separate text box to enter a global in-kind contribution. Instead, please provide an approximate estimate on a per-deliverable basis.

Cost-sharing funds may only be used for the purpose of offsetting burdened labor costs of development, engineering, documentation, and demonstration related to the Participant’s assigned deliverables. By contrast, the costs used to formulate the Bidder’s in-kind contribution may be much broader, including supporting labor, travel, software licenses, data, IT infrastructure, and so on.

Theoretically there is no limit on the size of the Proposed Contribution for each deliverable (beyond the raw capacity of the underlying hardware and software). But bidders are encouraged to incorporate content by making reference or linking to external materials where possible (rather than inline copying and pasting). There is also a textbox on a separate page of the submission form for inclusion of Organizational Background information, so there is no need to repeat this information for each deliverable.

Important
  • A breakdown (by cost category) of the "In Kind Contribution" may be included in the Proposed Contribution text box for each deliverable.

  • However, please note that the content of this text box will be accessible to all Stakeholders and should contain no confidential information such as labor rates.

  • Similarly, no sensitive information should be included in the Attached Document of Explanation.

The “Proposed Contribution (Please include any proposed datasets)” field can be used to provide a succinct description of what the Bidder intends to deliver for this work item to meet the requirements expressed in the Technical Architecture. This could potentially include a brief elaboration on how the proposed deliverable will contribute to advancing the OGC standards baseline, or how implementations enabled by the specification embodied in this deliverable could add specific value to end-user experiences.

A Bidder proposing to deliver a Service Component Implementation can also use this field to identify what suitable datasets would be contributed (or what data should be acquired from another identified source) to support the proposed service.

Tip
  • In general, please try to limit the length of each Proposed Contribution to about one text page per deliverable.

  • Note that images cannot be pasted into the field Proposed Contribution textbox. Bidders should instead provide a link to a publicly available image.

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

B.3.3. 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 COSI Program initiative are defined in the OGC COSI 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 COSI Team has the authority to table any of these contributions if there’s a risk of interfering with any primary Initiative activities.

    • Supporters are OGC member organizations who make in-kind contributions aside from the technical deliverables. For example, a member could donate the use of their facility for the Kickoff event.

    • The COSI 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 COSI Team communicates with Participants and other stakeholders during Initiative execution, provides Initiative scope and schedule control, and assist 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 COSI Team.

    • Suppliers are organizations (not necessarily OGC members) who have offered to supply specialized resources such as 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.

  • Proposals from non-members or individual members will be considered provided that a completed application for organizational membership (or a letter of intent) is submitted prior to or with the proposal.

    • Non-members or individual members should make a note regarding their intent to join OGC on the Organizational Background page of the Bid Submission Form and include their actual Letter of Intent as part of an Attached Document of Explanation.

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

  • Individuals from any OGC member organization that does not become an initiative Sponsor or Participant may still (as a benefit of membership) observe 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 these obligations are met in a timely manner (whether a 3rd-party subcontractor provides assistance is up to the Participant).

  • 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 required, reliable contributions from the assigned Participants.

  • A Bidder may propose against one, several, or all deliverables. In past projects, more participants were assigned one deliverable, and fewer were assigned multiple deliverables.

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

    • What is delivered to OGC is the behavior of the component installed on the Participant’s machine, and the corresponding documentation of findings, recommendations, and technical artifacts contributed to the 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.

AI

Artifical Intelligence

API

Application Programming Interface

ARD

Analysis Ready Data

CADs

Climate and Atmosphere Data Store

CAMS

Climate and Atmosphere Monitoring Service

C3S

Climate Change Service

CDRP

Climate and Disaster Resilience Pilot

CEOS

Commitee on Earth Observation Satellites

CFP

Call for Participation

COSI

Collaborative Solutions and Innovation Program

CR

Change Request

CRIS

Climate Resilience Information System

DER

Draft Engineering Report

DRI

Decision Ready Indicators

DWG

Domain Working Group

EO

Earth Observation

ER

Engineering Report

FAIR

FAIR Findable Accessible Interoperable Reusable

GPKG

GeoPackage

GDDS

Green Deal Data Service

IPPC

Intergovernmental Panel on Climate Change

OGC

Open Geospatial Consortium

ORM

OGC Reference Model

OSPD

Open Science Persistent Demonstrator

OWS

OGC Web Services

NSG

National System for Geospatial Intelligence

PA

Participation Agreement

POC

Point of Contact

Q&A

Questions and Answers

RM-ODP

Reference Model for Open Distributed Processing

SDI

Spatial Data Infrastructure

SIF

Sensor Integration Framework

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

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

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

Is the Collective engineering report assumed to be related to the other deliverables offered?

Yes, the Collective Engineering Report is basically a collective documents, one person leads on editing it, everyone helps to write it, and it is reporting on all of the work and the technical work that is done in the pilot, So, it is entirely dependent on that. Then, the information is therefore, contributed by all of the participants, So if you’ve ever been involved in writing an edited book, it’s a bit like that, where you are really pulling things together from lots of different chapter authors.

Can you clarify whether D101 and D001 are separate deliverables? Only one instance of D101 appears in the Call For Participation and seems to be the same thing as D001

They are seperate, D001 is the engineering report and D101 is the first deliverable of secion 2.

Will any representative data be provided for deliverables, or do you source data yourselves and document the availability and pipeline for acquiring?

When you are bidding for participation in an OGC pilot, you come with an in kind item that you are bringing and that is often data. As an individual organization might not have the sources of the data yourself, you might be able to leverage data that is being sourced by someone else within the pilot. There is the expectation that some participants in the pilot will be contributing data that they already hold, or that they are already providing via their services that is held by someone else. if you are planning to work on a deliverable and you don’t have the data available yourself to work on it, certainly note that in your proposal, we can take it into consideration and we can try and do some matching between participants. It is part of the collaborative process that one participant might come with the data source that that helps support another participant to demonstrate a software tool, so these things can be negotiated as part of the contracting process.

If AWS or Google Cloud computing will be available during the pilot to test,

The answer is TBC, to be confirmed, in past pilots, including the disaster pilot, we have been able to make available AWS credits and cloud computing resources. We will certainly be re-opening the conversation with AWS and Google about providing those resources. But I can not yet given a definitive answer at this time. We will hope to come back to you as soon as possible and let everyone know certainly by the kick off meeting.

Is the call meant to select the best (just ONE) candidate to cover all the CDRP24’s objectives or can an applicant focus on a sub-set of specific goals among those listed and be selected in tandem with other teams to complete the whole work required?

Hopefully, it is clear, from my emphasis on collaborative innovation, that we’re not looking for one candidate to do every single deliverable. We’re looking for a wonderful consortium of candidates of different organizations who will come together to cover the different objectives. Some objectives may be led by one participants. Some objectives may be funded more than once. So, multiple instances or we may bring together more than one participant to work on something. It is certainly a multiple candidate situation.

What are the OGC intellectual property requirements for software prototypes developed as part of this pilot?

OGC Intellectual Property Rights

D119 - Health related: Should we focus on a single extreme event or multiple storms events or is the expectation that we work with participants to understand which use case would be the best?

The expectation is that use cases will be co-designed, you can describe the use case(s) you would pursue in broad terms. .

Availability of data from sponsors

We can check on availability of specific datasets and services - please get in touch with us.

What is the role of ER editor?

The ER editor will lead high level discussion in weekly meetings. They should distill insights, set out lessons learned, and create a focused document and inform creation of impact and advocacy documents.

Digital Twins: given complexity of digital twins… may be twin itself, vizualization, ingest, dissemination. Whole twin or various offers?

Various offers will be considered under the bid.

Who are the sponsors?

NGA, NOAA, DHS, ARDSWC