AI DGGS CFS alt



Artificial Intelligence Discrete Global Grid System (DGGS) for Disaster Management: Call for Participation (CFP)

1. Introduction

For historical reasons, Geographic Information Systems (GIS) rely on a projected, scale-dependent representation of the Earth that was developed for navigation with paper maps, resulting in distortions. In contrast, Discrete Global Grid Systems (DGGS) provide a natively digital, cell-based approach that accurately represents the Earth as a spheroid. DGGS divide the planet into hierarchically tessellated cells across all scales, functioning as a “spreadsheet for Earth” that supports efficient analysis and integration of large datasets. With fixed-area cells, data related to a phenomenon at a specific location can be directly linked to its corresponding cell(s). This allows for quick integration with cell values from various datasets and efficient analysis to produce valid summaries for any selection of cells. DGGS simplify the ingestion of statistical and other gridded data into broader geospatial systems, thereby unlocking significant potential for enhanced contextual analysis and insights.  DGGS can be developed in various ways to fulfill different objectives. Ensuring interoperability among diverse DGGS is essential for users and software employing different DGGS methods to collaborate effectively. This DGGS-oreinted Pilot aims to explore and demonstrate this interoperability. 

DGGS represent locations as cells, moving beyond traditional geographic reference systems. DGGS are ideal for data integration, efficient querying, and serving as authoritative content stores for Artificial Intelligence (AI) powered natural language queries. The “AI-DGGS for Disaster Management Pilot” initiative explores how different DGGS grid designs can use OGC Standards for automatic data exchange, focusing on disaster management. It will also investigate enhancing DGGS with AI/Machine Learning (ML) tools, such as chatbots for natural language queries and AI-driven insights, using a Retrieval-Augmented Generation (RAG) approach for accurate, authoritative responses. RAG is a hybrid architecture that integrates a retriever model to fetch pertinent documents from an external knowledge base and a generator model to create answers based on the retrieved documents. Unlike traditional language models, RAG accesses external data during inference. It enhances factual accuracy and reduces hallucination by grounding responses in retrieved content, making it useful for knowledge-intensive tasks like open-domain question answering. DGGS serve as a localization identifier system for real-world objects, organizing space with nested cells. A list of cell IDs describes the geometries, with accuracy depending on cell size. DGGS can integrate data described at different zoom levels, making them suitable for various domains like finance, disaster management, and environmental analysis. They can replace postal addresses, eliminating the need for descriptive addresses or landmarks, accurately identifying areas without traditional infrastructure, and adapting to dynamic urban growth. 

The "AI-DGGS for Disaster Management Pilot" aims to prototype the potential of OGC standards to facilitate the interoperable use of DGGS combined with AI for disaster management applications. This project will include assessing the suitability of existing OGC standards for enabling AI-DGGS data integration, analysis, and visualization, while identifying further steps needed for OGC standards to fully support AI-DGGS interoperability requirements within disaster management systems. Key deliverables will include the clients, servers, and the visualization platform, which will demonstrate this interoperability. The results will be documented in the final report. Furthermore, all demonstrators will be maintained by the participants for an additional year after the pilot’s completion to showcase the AI-DGGS interoperability capabilities.

2. Background

Consultation with emergency management professionals, industry professionals, and other government department officials indicates that current mapping software packages are limited in scope and lack AI integration, limiting their ability to support complex disaster management requirements. Disasters are global and so should be the mapping platforms that integrate data needed to inform planning and preparedness, response and recovery activities.

The Canadian Geospatial Data Infrastructure (CGDI), led by Natural Resources Canada’s (NRCan) GeoConnections Program, enables Canadians to find, access, and share location information to support decision-making, enhance analysis, and inform policy development across various sectors. As climate change intensifies disasters, geospatial data becomes increasingly crucial for disaster planning, response and recovery. NRCan aims to ensure that CGDI’s geospatial standards meet the needs of Canada’s emergency professionals.

The French Space Agency (CNES) and the European Space Agency (ESA) are actively engaged in advancing the application of Discrete Global Grid Systems (DGGS) to enhance geospatial data analysis and integration. These efforts align with their broader goals of improving Earth observation capabilities and supporting global environmental monitoring. The adoption of DGGS allows for scalable, uniform coverage of the Earth’s surface, enhancing the precision and interoperability of geospatial datasets. For example, ESA’s "Big Data from Space" (BiDS) initiative has been a key driver in the development of XDGGS, which integrates DGGS into Python’s Xarray library, facilitating the handling of multi-dimensional geospatial datasets.

The United States Geological Survey (USGS) maintains and distributes vast geospatial datasets—such as topographic maps, satellite imagery, and elevation models—and continues to explore and support various data-management standards to facilitate integration, analysis, and sharing of information. In alignment with its mandate to ‘describe and understand the Earth; minimize loss of life and property from natural disasters; manage water, biological, energy, and mineral resources; and enhance and protect our quality of life,’ the USGS also provides the reliable scientific information needed to advance research, inform policy, and protect the public. By refining data collection and analysis efforts, the USGS ensures its expanding repository of geospatial information can effectively guide decision-making on environmental issues, resource management, and hazard mitigation—ultimately strengthening the United States of America’s ability to understand and safeguard its natural landscapes and resources.

The global leader in geographic information standards, the Open Geospatial Consortium (OGC), is developing standards to enhance interoperability. As DGGS advances, standards will be key for ensuring diverse types of data can be easily incorporated, and that independently operated DGGS can communicate. NRCan is committed to advancing early DGGS interoperability to increase the benefits of this technology for all who live in Canada. The advancements in DGGS are also fostering considerable interest within the USGS.

Artificial Intelligence (AI) is evolving at a pace that is challenging traditional mapping products. Traditional mapping interfaces and software are cumbersome to operate and integrate new and real-time data, still requiring a level of mapping and technical expertise. Web mapping products lack intuitive AI based interfaces that use natural language to generate visuals and answer questions. DGGS, combined with AI, presents an opportunity to revolutionize how mapping is undertaken by making mapping analyses easier for existing and new users. Standards development will be critical for ensuring sufficient data and system interoperability is in place to maximize the broad use of DGGS and AI approaches.

This pilot will explore how disaster management can be improved by relying on OGC standards for AI and DGGS.

3. Eligibility Criteria

Please consider the following tips regarding the eligibility criteria for this pilot.

  • This pilot will not have any allocated funding for hosting the deliverables and demonstrators.

  • In cases where proposals are evaluated and determined to be of equal merit based on the established evaluation criteria, preference will be given to proposals submitted by OGC members legally incorporated in Canada, France, Germany, or other Member States of the European Space Agency (ESA).

  • Bidders should anticipate that the funding allocated for each work item will typically range between $5,000 USD and $30,000 USD. While this range reflects the standard funding envelope, exceptions may be made in rare and well-justified cases, either above or below this range, subject to the specific scope and strategic importance of the proposed contributions.

4. Objectives

  1. Suitability and Interoperability:

    1. Understand the suitability of OGC standards for supporting interoperability between DGGS grid designs for various disaster management requirements.

    2. Demonstrate the ability of OGC standards to enable interoperable application of AI solutions between independently operated DGGS.

  2. Data Integration and Management:

    1. Demonstrate how OGC standards enable integration of diverse forms of geospatial data (e.g. climate, weather, statistical) using DGGS.

    2. Demonstrate the ability of OGC standards to enable the use of AI to support DGGS data integration and management.

  3. Analysis and Visualization:

    1. Prototype the use of OGC standards for enabling AI geospatial analysis and visualization of data stored in a DGGS. Demonstrated analysis and visualization shall support disaster management requirements.

    2. Demonstrate use of OGC standards for applying two AI approaches with DGGS for disaster response:

      1. Enabling an AI chatbot interface to ask questions of DGGS data;

      2. Execution of geospatial analysis within DGGS using AI chatbot prompts with results output to the chatbot and mapping user interface.

  4. Maintenance:

    1. Create and maintain availability of web accessible prototype(s) beyond the project end date for access by all stakeholders and the Canadian public.

5. Master Schedule

The following table details the major Initiative milestones and events for the AI DGGS Disaster Management Pilot. Dates are subject to change.

Table 1. Master Schedule
Milestones Date Description

M01

6 May 2025

Public Release: Call for Participation

M02

27 May 2025

Questions due for Bidders Q&A Webinar 01:00 AM EDT Submit questions using the Questions Form.

M02a

27 May 2025

Bidders Q&A Webinar 9:00 AM EDT Please join the meeting here, Tuesday May 27th 9:00 AM EDT

M03

20 June 2025

Proposals Due at 23:59 EDT

M04

14 July 2025

Virtual Kick-off workshop, Virtual session, only online attendance possible.

M05

10 October 2025

Initial report (IER) due, All the scenarios and related data has been defined.

M06

21 November 2025

Initial results available, Drafts of general and technical materials for Report is due (DER). Initial Visualization Platform and initial demonstrations are due.

M07

14 January 2025

Virtual Workshop - Engineering Report draft submission

M08

30 January 2026

Pilot report submitted for evaluation by OGC working group

During the pilot, weekly or biweekly check-ins will be held for participants to discuss progress, highlight challenges, and share perspectives on key issues through video conferences.

6. General Requirements

Objectives will be delivered by tasks described in Technical Requirements The following general requirements apply to all tasks:

  • For technical tasks, the technological solution(s) to enable the required standards-based approaches will be determined through consultations between the OGC, Participants, Sponsors, and its partners during the project. Participants are expected to use OGC API frameworks for all developed solutions; however, the Sponsors wish to be informed of all possible options before final approaches are chosen. The participants shall ensure alignment with Government of Canada Standards on APIs as required. All API tasks shall also consider how to support multilingual requirements (English and French at a minimum).

  • Where user interfaces are developed (e.g., a delivery endpoint), compliance with Web Content Accessibility Guidelines (WCAG) 2.1 is required.

7. Project Scenario

All aspects of the project will be based on the following hypothetical disaster scenario to focus activities. Over a period of several months, the Province of Manitoba has experienced severe weather which led to the following hazard events:

  • Record snowfall and severe weather in the Red River basin could raise the likelihood of flooding in southern Manitoba.

Emergency managers aim to better respond to these hazard events by understanding:

  • The likelihood of flooding in specific areas.

  • The potential impacts, based on key indicators, including:

    • Elevation data and forecasted flood volumes to trigger evacuation warnings.

    • Indicators of potential dam breaches.

    • Ground saturation to assess overland flooding risk.

    • The ground’s ability to absorb rainfall.

    • Precipitation levels above critical thresholds.

  • Basic demographic details of affected individuals (e.g. population, housing, and age).

  • Expected economic impacts in the affected areas.

To support this understanding, emergency managers wish to integrate multiple sources of geographic and statistical information together to create a “common operating picture” – a single view of information available to support decision making. DGGS and AI will be used to provide this common operating picture. Emergency managers are also interested in understanding potential impacts of climate change on future floods. They wish to understand the potential of DGGS to assist with this, including:

  • Analyzing climate projection data from sources like the Climate Atlas of Canada.

  • DGGS enabling climate data aggregation at various spatial levels (local, regional, provincial, national, international).

  • DGGS supporting the integration of climate projections with geospatial, non-geospatial, and statistical data for scenario analysis.

  • Developing climate indicators with visualizations to highlight potential impacts across different geographic levels (local, regional, provincial, national).

Project activities completed in the context of this scenario must consider NRCan requirements for the Emergency Geomatics Service (EGS) and Manitoba’s emergency management approaches, which are both well-defined and fully operational. Project activities must include application over the Red River of Manitoba at minimum (i.e. portion of the Red River from the border to Lake Winnipeg). Work shall also consider portions of the contributing Red River watershed in the United States. Developed DGGS approaches must show how this technology can facilitate improved interoperability to complement EGS’ and the province’s existing emergency management framework for floods and EGS products as input.

All project activities shall consider the following persona. Deliverables shall be constructed so that they allow the requirements of the persona to be met within the context of the project scenario.

Emergency Response Coordinator

  • Role: Manages disaster response, coordinates agencies, uses geospatial data for decisions.

  • Needs: Real-time data integration, predictive modelling, resource optimization, and interoperable visualization tools.

To this end, developed prototypes must possess the following key features:

  • AI chatbot:

    • Users ask questions in plain language (e.g., "Which areas are at flood risk?", “Identify neighbourhoods that will likely be impacted by flooding.”) and receive data-driven answers (e.g., regions x, y, and z are at heightened risk of flood as is shown in the user interface DGGS mapped locations of increased flood risk).

  • Interactive Interface:

    • Intuitive web-based DGGS allows users to visualize and interact with disaster data in real-time and visualize the AI provided answers in combination with AI chatbot responses.

  • AI-Driven Insights:

    • Automated analysis detects patterns, forecasts disaster scenarios, and generates insights from large datasets (elevation, weather, demographics).

8. Technical Requirements

This section identifies the technical objectives of the AI DGGS for Disaster Management Pilot initiative and the corresponding activities and deliverables. All deliverables are identified by the identifier Dxxx, with "xxx" being a three-digit number.

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 Standards, where relevant.

The following task descriptions outline the requirements to meet the project’s objectives.

Task 1: Demonstrate the interoperability of DGGS using the draft OGC API – DGGS standard

The participant shall demonstrate how independent DGGS can interoperate through the draft OGC API – DGGS standard. This shall include:

  • Demonstration of interoperability between at least two independent DGGS by means of the draft OGC API – DGGS standard. Other OGC standards are to be used as needed.

  • Demonstration of all components of OGC API – DGGS.

Task 2: Demonstrate the ability of different OGC standards to enable integration of forms of geospatial and statistical data using DGGS.

Within the context of the project’s scenario, the participant shall demonstrate how DGGS can support the integration of different forms of geospatial and statistical information using interoperable, OGC standards-based approaches. This shall include:

  • Integration of geographic and statistical data (i.e. at least three datasets total). The following datasets shall be used as part of this component:

    • RADARSAT Constellation Mission (RCM) satellite imagery provided by NRCan in an analysis ready data format shall be used. RCM data products are in the CEOS-defined ARD SAR format (developed with NRCan’s input). This includes SAR-NRB and POL data (v1.1) for RCM-1/2/3, optimized for accurate and scalable geospatial applications.

    • Historical National Air Photo Library (NAPL) air photos, provided by NRCan shall be used.

    • Additional datasets are to be proposed by the participants in consultation with Sponsors and their partners. Considerations include NRCan’s Floodsin Canada – Archive” dataset, which shows the extent of past flooding events across Canada. The participant should strongly consider incorporating this data into a DGGS format as part of the integration process, but it is not a requirement.

  • Demonstration of the use of OGC standards in addition to OGC API – DGGS to enable integration.

Task 3: Evaluate the ability of OGC standards to enable DGGS analysis for emergency management decisions

The participant shall demonstrate how DGGS, using OGC standards-based approaches, can support analysis of geospatial and statistical data to inform emergency management decision making. This shall include:

  • Use of all datasets integrated DGGS during Task 1.

  • Development of at least two workflows to complete processing and analysis of the integrated datasets. Characteristics of these workflows are to be developed collaboratively between the participants, OGC, Sponsors and their partners. Execution of workflows must be accomplished using OGC standards-based approaches.

  • Developed workflows shall be based on the project’s scenario. Analysis completed through the workflows shall be designed to meet scenario goals.

  • At minimum, workflows shall produce at least a total of two indicators to support emergency management decision making. The participant shall work with OGC, Sponsors and their partners to define the indicators to be created.

  • Workflows shall be of sufficient complexity to exercise all applicable aspects of OGC API – DGGS.

Task 4: AI in Depth. Explore the ability of OGC standards to enable use of AI approaches with DGGS

AI approaches are increasingly important as a mechanism for completing geospatial analysis and for obtaining insights from geographic and other forms of information. AI approaches will be applied in the context of DGGS; it is thus necessary that OGC standards used to enable DGGS interoperability be designed to support the application of AI to DGGS. In this context, this task shall include:

  • Demonstration of how OGC API – DGGS and/or other OGC standards can facilitate the application of AI approaches for completing geospatial analysis and visualization within a DGGS environment. At a minimum, this shall include demonstration of the use of AI techniques for geospatial pattern analysis and recognition (e.g. detecting landscape changes related to a specific event or over a period), as well as visualization of analysis results within at least one DGGS. The specific type(s) of analysis to perform shall be determined collaboratively between the participants, Sponsors, and theris partners after project start.

  • Demonstration of how OGC API – DGGS and/or other OGC standards can allow application of Large Language Model (LLM) and AI approaches to DGGS to allow users to submit plain language queries to DGGS and obtain responses through an AI chatbot. In the context of the project’s scenario, an example question could be:

Identify neighbourhoods that will likely be impacted by flooding.”

The participant shall demonstrate linkages between the use of LLM and the AI requirements for geospatial analysis and/or predictive modelling listed above (e.g. demonstrate how submission of a question through an AI chatbot can invoke geospatial analysis and/or predictive modelling approaches to return an answer in both text and visual formats).

  • If possible, the participant shall aim to link the workflows created in Task 3 with the Task 4 AI approaches.

  • Based on outcomes of these demonstrations, identify any considerations around the use of OGC standards to support use of AI with DGGS. For example, identify aspects of OGC standards that can be improved in the future to better allow interoperable use of AI with DGGS. These considerations shall be documented within the technically focused report deliverable.

Task 5: Prototype the use of OGC standards for enabling interoperable visualization within DGGS in a disaster management context

The participant shall demonstrate how DGGS approaches, through OGC API – DGGS as well as other OGC standards, can support visualization of geographic and statistical information. The visualization methods used must align with and support the project’s scenario. This shall include:

  • Visualization of all results produced by Tasks 3 and 4.

  • Demonstration use of AI to enable visualization (e.g. submission of a question to an AI chatbot results in a visualization being created within the DGGS).

  • Visualization methods must support both near-term and future-oriented disaster management requirements. For example, near-term requirements include the creation and display of indicators needed to make immediate decisions in the context of flooding.

  • Demonstrate how OGC API - DGGS or other OGC standards can enable visualization through MapML viewer capabilities.

Task 6: Create and maintain availability of prototypes and demonstrations beyond the project end date

Execution of the project will result in the creation of a prototype accessible via the web and demonstrations of the use of OGC approaches for delivering interoperable AI-DGGS solutions in a disaster management context. There is a need for these materials to be made available beyond the end date of this contract. This shall include:

  • Maintaining access to the prototype and demonstration for at least one year after project completion at no additional cost to Sponsors.

  • Access to the prototype and demonstration must be granted in such a way that they are either open to the public or through restricted-access mechanisms that will support use by Sponsors and any of their partners.

  • Simple documentation must be provided with the prototype and demonstration describing its characteristics and how to make use of it.

  • To the greatest degree possible, prototypes and demonstrations shall be designed according to principles developed within the OGC Open Science Persistent Demonstrator Pilot. If possible, all prototypes and demonstrations should be made available through the OGC Persistent Demonstrator environment.

9. Deliverables

Figure 1 depicts the architecture and deliverables of the AI-DGGS Disaster Management Pilot.

The complete set of deliverables namely: D001, D100 and D102, cover all the requirements defined in the Technical Requirements and implement them according to the requirements described in Project Scenario and General Requirements.

Initiative architecture and its deliverables (with numbered identifiers)
Figure 1. Initiative architecture and its deliverables (with numbered identifiers)

9.1. Reporting AND Website Deliverables

Deliverable D001: DGGS Report & Website

Website with all project results, persistent demonstrators, guides, and project summary. The website will be made available in English with the option to translate to French. Translation costs are not included in this proposal.

9.2. Technical Deliverables

Deliverable D100: OGC API endpoint

Instance of an OGC DGGS API implementation. The instance supports various types of data, as illustrated in Figure 1. Together, the OGC API endpoint instances support at least two different grid structures. Each instance offers transactional functions for adding or changing data. Data can be provided in several formats, including tabular geographical and non-geographical data. The individual instances vary in the data provided and collectively support the disaster scenario. A minimum of two instances has been foreseen.

Deliverable D102: AI-enabled DGGS Client

Client tool to interact with DGGS-enabled data, supporting AI functionality such as pattern recognition and analysis, predictive modeling, large language models, and mapping and reporting features with conversational chatbot support. A minimum of two instances has been foreseen.

9.3. Technical Requirements vs Deliverables

The following table maps the tasks defined in Technical Requirements and the Deliverables.

Table 2. Mapping between Technical Requirements tasks and the Deliverables
Task # Content Deliverables

1

Demonstrate the interoperability of DGGS using the draft OGC API – DGGS standard

D100 and D102

2

Interoperability between OGC DGGS-API instances

Servers: D100

Clients: D102

3

OGC API serving DGGS data, support for at least three data sets in total, including RADARSAT data and the Historical National Air Photo Library (NAPL)

Data Servers: D100

Workflow execution clients: D102

4

AI-powered data analytics

D102

5

Demonstration scenario, including tasks 1-4; support for 2D and 3D data, support of MapML

D102

6

AI demonstration and operational support

D100 and D102

10. OGC COSI Program Initiatives

This initiative is being conducted under the OGC Collaborative Solutions and Innovation (COSI) Program, which 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 most complex 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 125 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 technology adoption in the marketplace.

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

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.

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 / Engineering Reports (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.

10.2. Q&A option before the call closes

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 Q&A Form. 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 Q&A 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.

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:

  • Participants are defined in section Participants of the OGC COSI Policies and Procedures

  • 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 Team. Explanations of the roles are provided in Tips for New Bidders.

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

Initiative Architect(s) 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 documents, websites, or component implementations.

A.3.1. Documents

Engineering Reports (ER) or in short Reports, 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

OGC Reports are produced by using a production pipeline. The base format is asciidoc. The asciidoc is eventually compiled to an OGC Report using the Metanorma production pipeline. The OGC team is available to help with that process. The easiest installation and execution requires a Docker environment. Once installed, it is very simple to use.

A typical (Engineering Report) shall not exceed 40 pages excluding annexes.

Document content should follow this OGC Document Editorial Guidance. File names for documents posted to Pending should follow this pattern "OGC <Initiative Name>: <Deliverable Name>". Example: "OGC Testbed-20: Integrity, Provenance, and Trust (IPT) Report".

A.3.2. 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. If required in the Call for Participation, Participants shall either keep the component operational for at least 12 months after the end of the initiative, or deliver the component to OGC with the necessary license to operate the component on behalf of the participant. The concrete modalities for component delivery will be agreed during the initiative.

IMPORTANT

Under the Participation Agreement contracts, ALL Participants will be responsible for contributing content to the ERs, including 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 will be published on the OGC YouTube channel. The videos 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 <Initiative Name>", 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, <Initiative Name>, machine learning, analysis ready data].

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 OGC YouTube channel.

A.3.3. Websites

Websites shall be developed so that they can easily be redeployed on OGC servers. Technical details will be discussed with the OGC Team. The proposals should ideally state requirements for the execution environment. Please be aware that OGC does not allocate any funding or resources to the website during the implementation of this pilot, and hosting responsibilities fall on the proponent.

A.4. 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 four areas: technical, compliance, experience, and management/cost. ==== Technical Evaluation Criteria * Technical Approach & Methodology: Clarity, feasibility, innovation, and appropriateness of the proposed approach are needed to effectively meet the objectives outlined in the tender.

A.4.1. Compliance Evaluation Criteria

  • Compliance with Requirements: Extent to which the proposal meets the functional and technical requirements specified in the tender documentation.

A.4.2. Experience Evaluation Criteria

  • Experience & Expertise: Demonstrated expertise, skills, and relevant experience of the team in handling similar projects or technologies, ensuring the team’s capability to deliver the solution.

A.4.3. Management/Cost Evaluation Criteria

  • Cost-Share Contribution: The proposed contribution and suggested in-kind contribution regarding the requested cost-share funding ensure alignment with financial expectations and the project’s goals.

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 an 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.4.4. Reporting

Participants will be required to report the progress and status of their work regularly via phone conference; details will be discussed at the kick-off meeting. 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 Sponsors and should contain no confidential information such as labor rates. All financial information will not be shared beyond the OGC Team.

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.

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 Question form. 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 at techdesk@ogc.org.

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 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). Example: If the CFP requests two clients with IDs D100 and D101, it is sufficient to submit a proposal against D100. The bid will automatically be considered for both deliverables.

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 to describe 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.

    • Bidder is an OGC organizational member that holds membership in good standing and submits a proposal in response to a COSI CFP. For "Extra Small Explorer" members, a funding cap of US$10,000 per initiative applies. If this limit is exceeded, a higher-level membership is required. All higher-level memberships have no cap. OGC Individual and Developer members can participate in initiatives but are not eligible for funding. 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 in good standing 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 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 is submitted prior to or with the proposal.

  • Any individual wishing to gain access to the Initiative’s intermediate work products in the restricted area of the tools used in the initiative (or attend private working meetings / telecons) must be a member approved user of the OGC 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) 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 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 completed initiatives list.

Appendix C: Abbreviations

The following table lists all abbreviations used in this CFP.

AI

Artifical Intelligence

API

Application Programming Interface

ARD

Analysis Ready Data

BiDS

Big Data from Space

CEOS

Committee on Earth Observation Satellites

CGDI

Canadian Geospatial Data Infrastructure

CNES

Centre National d’Études Spatiales

COSI

Collaborative Solutions and Innovation Program

CR

Change Request

DER

Draft Engineering Report

DGGS

Discrete Global Grid System

DWG

Domain Working Group

EGS

Emergency Geomatics Service

ER

Engineering Report

ESA

European Space Agency

FAIR

FAIR Findable Accessible Interoperable Reusable

IER

Initial Engineering Report

LLM

Large Language Model

ML

Machine Learning

NAPL

National Air Photo Library

NRB

Normalized Radar Backscatter

NRCan

Natural Resources Canada

OGC

Open Geospatial Consortium

PA

Participation Agreement

POL

Polarimetric

POC

Point of Contact

Q&A

Questions and Answers

RAG

Retrieval-Augmented Generation

RCM

RADARSAT Constellation Mission

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

USGS

United States Geological Survey

WCAG

Web Content Accessibility Guidelines

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

Tips for New Bidders

Instead of "Bidders are OGC member organizations in good standing who submit proposals in response to this CFP," the following sentance describe the bidders: "A bidder is an OGC organizational member that holds membership in good standing and submits a proposal in response to a COSI CFP. For "Extra Small Explorer" members, a funding cap of US$10,000 per initiative applies. If this limit is exceeded, a higher-level membership is required. All higher-level memberships have no cap. OGC Individual and Developer members can participate in initiatives but are not eligible for funding."

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

Question Clarification

Will you be looking for someone to lead the engineering report for this project?

Yes, we are certainly looking for an ER editor who is familiar with the concepts of DGGS and AI.

What level of AI model explainability and transparency is expected in the AI-enabled DGGS client? Are there specific standards or guidelines for generating AI-driven insights?

- Although there is no set requirement defined for this Pilot except what is mentioned in the CFP, we would certainly appreciate it if provenance is provided. The AI system should offer clear, understandable reasons or evidence for its outputs and processes. Stakeholders and Users must be able to access explanations about how insights or recommendations were generated.

- In OGC, the FAIR (Findable, Accessible, Interoperable, and Reusable) principles hold significant importance. Therefore, please ensure that AI transparency adheres to these principles. Any elements failing to meet the FAIR principles should not be included in this pilot. In summary, open documentation of the model, data, and logic is encouraged. It is crucial to avoid proprietary or IP-restricted components that do not follow open standards or are not open source. If such components are present, kindly mention them in your proposal.

- As for guidelines, we suggest the Guide on the use of generative artificial intelligence by the Government of Canada for this Pilot: https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/responsible-use-ai/guide-use-generative-ai.html

Is there a recommended approach for integrating LLMs for AI-driven analysis within the DGGS environment, or are participants free to propose their own architecture?

Although RAG has been mentioned in the CFP, creativity and novelty are appreciated. The approach and architecture are open to participants as long as they satisfy the requirements mentioned in the CFP.

On the technical requirements for task 1, all the mandatory endpoints need to be shown for the OGC DGGS API?

Yes, but as far as the OGC DGGS API spec supports. If we can advance the API, that would be great as well.

How to see the entire proposal submission outline and the progress of the submisson? It seems I have to submit company details first?

Yes, I believe that is the case.

The proposal states that bidders are evaluated per-deliverable. For clarification, a bidder can submit to only a single deliverable, without this affecting the chances of approval? Or is a proposal covering all deliverables prone to higher succes rates?

Applying for all the deliverables would not affect the success rate. Each deliverable will be assessed independently. For interoperability reasons, we prefer that clients and servers be provided by separate entities.

On task 3, it says that we need to use the integrated dataset from task 1? Shouldn’t it be task 2?

Task 1 includes at least two DGGS implementations, each supporting different datasets, so Task 3 should support all of those datasets and not just one implementation. If the proponent is only applying for a D100 (Server) instance, then yes, it will be Task 2.

Given the tight funding and timelines, how will the scope of the pilot be managed to ensure realistic deliverables?

The goal is to achieve as much as possible. Proposals are reviewed and the most promising ones are selected. After the kickoff, there is a period to refine and agree on the detailed architecture and scope with participants, sponsors, and OGC. The final scope is defined collaboratively, based on what is reasonable and achievable within the constraints

Is OGC membership required to submit a proposal, especially for organizations based in India?

Any organization can submit a proposal, regardless of country. However, if selected as a participant, the organization must become an OGC member.

Are consortiums allowed to respond, and how should they submit?

Consortiums are allowed and have participated in past pilots and testbeds. However, it is preferred that even within a consortium, each party submits independent proposals for their respective pieces. This is the usual approach, but consortium applications are still accepted.

Are there recommendations for OGC membership levels for participating organizations?

The only membership level that cannot apply for the pilot is the individual level. Any higher membership level (explorer, Catalyst, Principan and Stategic) are eligible. For specific recommendations, participants are encouraged to email restephan@ogc.org[Richard Estephan] for further clarification from the membership team.

Clarification on the role of AI: Is the AI in the client only, or does the DGGS server also perform analysis (e.g., pattern detection)?

The original intent is for AI-driven analysis (such as pattern detection) to be performed on the client side. If participants can propose solutions where the server also performs such analysis, that is considered a positive addition. Both client and server need to work closely together to address interoperability and analysis challenges.

Is it mandatory to use technologies like MapML for visualization?

MapML is preferred for visualization, but the requirement is not strict. The project is open to alternative or innovative technologies that may better address the visualization needs.

Can multiple non-member organizations submit a proposal together, and do all need to become OGC members if selected?

Multiple organizations can collaborate on a proposal, but if selected, all must become OGC members. Having only some members in a consortium can be a challenge and is generally discouraged. Competing bids from all-member teams may have an advantage due to reduced administrative complexity.