Open Geospatial Consortium Testbed-16: système de grille mondial discret

ADVANCE CONTRACT AWARD NOTICE (ACAN)
1. Advance Contract Award Notice (ACAN)
An ACAN is a public notice indicating to the supplier community that a department or agency intends to award a contract for goods, services or construction to a pre-identified supplier, thereby allowing other suppliers to signal their interest in bidding, by submitting a statement of capabilities. If no supplier submits a statement of capabilities that meets the requirements set out in the ACAN, on or before the closing date stated in the ACAN, the contracting officer may then proceed with the award to the pre-identified supplier.
2. Definition of Requirements
The Department of Natural Resources Canada (NRCan) has the following requirement:
TITLE
Open Geospatial Consortium Testbed-16: Discrete Global Grid Systems
BACKGROUND
The Canadian Geospatial Data Infrastructure (CGDI) represents Canada’s national Spatial Data Infrastructure (SDI). Similar to traditional physical infrastructure that helps Canadians with their everyday lives (e.g. roads, utilities, telecommunications), CGDI is an infrastructure for geospatial (i.e. location) information. In short, CGDI helps Canadians find, access, use, and share geospatial information.
GeoConnections is a national program, led by Natural Resources Canada (NRCan), whose mandate is to advance the CGDI. Similar to physical infrastructure that is regularly improved through new technologies (e.g. upgrading analogue electrical meters with digital smart meters), CGDI’s digital infrastructure can consistently be upgraded to take advantage of new developments. This is commonly achieved through new and/or improved geospatial standards. Geospatial standards provide a vehicle for geospatial information to be described in a consistent, commonly understood, and agreed-upon way. Such standards enable interoperability: the ability to access, use, and understand information regardless of software or technology type.
Discrete Global Grid Systems (DGGS) represent a new geospatial management category designed to enable visualization, storage, and analytically processing of global phenomena rapidly and accurately. Based on a partitioning of the Earth’s surface into a spherical grid, DGGS allows geospatial information to be represented in a way that more intuitively reflects relationships between data and the Earth’s surface.
Applications of DGGS technology are proving to be useful for solving global-scale geospatial analysis problems on demand and in near real-time. Canadians and Canada’s geospatial and natural resources domains will significantly benefit from this new analytical technology as it progresses. At this early stage, it is important to continue to standardize the technology, in order to benefit all Canadians.
Currently, characteristics of DGGS have achieved initial standardization through an Abstract Specification of the Open Geospatial Consortium (OGC). To drive greater adoption of DGGS, movement towards a complete OGC Implementation Standard for DGGS. To begin this process, this project will develop an open source reference implementation DGGS server. The open, standards-based iterative development process applied by this project will result in concrete requirements for a future OGC Implementation Standard.
OBJECTIVES
The primary objective of this project the development of an open-source DGGS reference implementation, including a DGGS server and client. The server should support a proof-of-concept DGGS “driver”, as illustrated below (Figure 1). The driver shall support two core functions, specifically geographic location to cell-ID and cell-ID to geographic location. The purpose of this driver is to facilitate integration of DGGS with existing spatial data infrastructure code that serves geospatial information as OGC Web Services (OGC W*S). A secondary objective is to support presentation of the DGGS content via the driver as an “OGC DGGS Application Programming Interface (API)” implementation standard. The OGC DGGS API shall be conformant to the OGC OpenAPI family of standards.
Figure 1: Example DGGS storage, driver and server architecture.
Optionally, the reference server implementation should support interchangeable drivers, so that multiple, different back end DGGS can be supported (through installation of additional drivers) (Figure 2):
Figure 2: Example architecture illustrating interchangeable drivers supporting multiple DGGS implementations.
Additional objectives include engineering reports that document the results and lessons learned from the DGGS implementation work, which will inform future OGC DGGS implementation specifications, such as the OGC DGGS API.
All work aspects shall be carried out in a multi-vendor, co-development, international open standards consortium environment so that results can be easily accessed and acted upon by all Canadians. This approach is also required to ensure the solution may be adopted by others in geomatics communities in Canada and internationally, and to allow project outcomes to inform and contribute to future open geospatial standards developments and implementations.
PROJECT REQUIREMENTS
Challenges and Research Questions
DGGS presents an opportunity for the geospatial community to implement a representation of Earth that is vastly different from traditional coordinate system approaches. DGGS has the potential to enable storage, analysis and visualization of geospatial information in a way that more accurately reflects the relationship between data and the Earth. While the OGC abstract specification captures fundamental DGGS concepts, there is a need to implement DGGS to drive its adoption. This project shall contribute to this advancement through development of a DGGS reference implementation.
Key questions for this work include the following:
What DGGS structure would be best for developing a reference implementation? e.g. Uber’s Hexagonal Hierarchical Spatial Index, Open Equal Area Global Grid (OpenEAGGR).
What is a simple application that could be used to demonstrate the value of the reference implementation?
Can the reference implementation use existing OGC Web services code infrastructure, e.g. GeoServer or PyGeoAPI etc., and thereby demonstrate immediate value to the community?
What should be considered for future work oriented towards operational implementation of DGGS?
NRCan expects results from this project will form the basis for future initiatives to define DGGS as an OGC Implementation Standard.
Additionally, the following overarching research questions shall further help guide the work for each task:
The DGGS server-side implementation must be fully open source.
The DGGS server-side implementation shall include a library that encapsulates the actual DGGS functionality. That library should be usable for existing tools and services and shall support the geographic location to cell-ID(s) and reverse conversion.
All server-side development must be completed using open source tools, with all outputs made available in a public, freely accessible format.
All aspects of the implementation (e.g. underlying code) must be made available through an open license. An example is the Government of Canada’s Open Government License. Other licenses will be considered by the sponsor if they contain similar characteristics.
The client side demonstration application shall support features that highlight DGGS aspects and demonstrate the advantages a DGGS provides to the non-geospatial expert consumer type of user. The client shall be available as a browser-based solution. Open source is preferred for the client. The client shall visualize the DGGS at various zoom levels and interact with DGGS-enabled data services, i.e. OGC API endpoints that understand cell-IDs as spatial filters. Though appreciated, a globe-like visualization is not required. Simple visualizations (i.e. 2 dimensional) that demonstrate the capabilities of DGGS will be welcome.
Figure 3 illustrates possible implementation scenarios for this project:
Figure 3: Possible DGGS implementation scenarios.
In the first case (1), the web browser in the middle connects to the DGGS server through its DGGS API Client library to learn about DGGS cells provided by the DGGS reference library. The client illustrates cells by overlay with appropriate background material. The user selects cell-IDs and runs a query against a data server (OGC API or OGC W*S). The data service, not yet equipped with the DGGS reference library, queries the DGGS server to convert cell-IDs to geographic locations before returning data back to the client.
Deliverables
Deliverables for this project consist of project design, reporting, and technical requirements. Table 1 summarizes required deliverables, along with completion dates. Reporting and technical components are described in Table 2. Some of the project deliverables may be adjusted in consultation with NRCan and the contractor.
Table 1: Summary of Project Deliverables and Required Delivery Dates
Deliverable
Required Delivery Date
Initial Engineering Reports complete.
May 31, 2020
Component implementation design.
August 31, 2020
Components ready for first Technical Interoperability Experiments (TIEs).
September 30, 2020
TIEs completed, and preliminary draft Engineering Report ready for review.
October 31, 2020
Ad hoc TIE demonstrations and demonstration assets posted to the OGC portal for each technical component listed in Table 2. OGC working group reviews requested for near-final draft Engineering Reports.
November 15, 2020
Final draft Engineering Reports and all technical components delivered.
November 30, 2020
Final Engineering Reports available to the public.
December 31, 2020
Final demonstration event of project outcomes and outreach material available.
January 31, 2021
Table 2: Descriptions of Reporting and Technical Component Deliverables
Reporting Components
Component Name
Description
DGGS and DGGS API Engineering Report
A report capturing all results and experiences from this task. The report shall include the documentation of the DGGS API. It shall describe the analysis performed, design of the proof-of-concept, and validation of the results. The report shall also make recommendations for OGC standardization and extensions. The report must contain a plain language executive summary to clearly outline the motivations, goals, and critical outcomes of this task, considering the mandates of the OGC and NRCan.
Technical Components
Component Name
Description
DGGS Server Implementation
Open source server implementation with support for OGC DGGS
API. The implementation must be delivered as a Docker container or Virtual Machine with all source code. As a sub-component, the server-side implementation shall deliver a driver / library that encapsulates the actual DGGS interface functionality. That driver / library must be integrated into existing OGC tools and services and must support the geographic location to cell-ID(s) and reverse conversion.
DGGS Demo Client
A client application with DGGS API support and capable of demonstrating DGGS capabilities. The client must visualize the DGGS at various zoom levels and interact with DGGS-enabled data services, i.e. OGC API endpoints that understand cell-IDs as spatial filters.
DGGS Enabled Data Services
DGGS-enabled data services, i.e. either OGC API endpoints or OGC W*S services that understand cell-IDs as spatial filters. The services can use the DGGS reference implementation driver / library (from the DGGS Server Implementation component) dto convert cell-IDs to geographic filters; or implement the same DGGS to ensure consistent cell-IDs across the other components. Alternatively, the instances can make use of the DGGS server instance for cell-ID(s) to geographic location conversion.
3. Criteria for Assessment of the Statement of Capabilities
Any interested supplier must demonstrate by way of a statement of capabilities that it meets the following requirements:

The provider must be an authorized international standards organization committed to developing and maintaining collaborative geospatial standards that are freely available for anyone to use.
The provider must be a member of the Open Geospatial Consortium, therefore able to participate in OGC initiatives, including Testbed-16.
The provider must have experience developing and maintaining open, international geospatial standards that have achieved widespread adoption by the global geospatial community.
The provider will be able to continue its development, management, distribution and maintenance of the Open Geospatial Consortium (OGC) standards that have been implemented in the Canadian Geospatial Data Infrastructure (CGDI), which include but are not limited to Catalogue Service for the Web (CSW), Web Map Service (WMS), Web Feature Service (WFS), Web Map Tile Service (WMTS), GeoSciML, WaterML, GroundWaterML, Web Processing Service (WPS), Sensor Observation Service (SOS), Discrete Global Grid Systems (DGGS) and others, in a way which is officially authorized by the OGC.
The provider must have demonstrated that it has an official “Tier 1” formal relationship with other international standards development organizations, including at a minimum: the International Organization for Standardization (ISO), International Hydrographic Organization (IHO) and the World Wide Web Consortium (W3C). The provider must concretely show that its activities with these organizations have resulted in the development of standards.
The provider must concretely show that its activities within these organizations have resulted in the development of standards.
The provider must have at least 500 members representing government, commercial organizations, NGOs, academic and research organizations which:
Can participate in Testbed-16 in a capacity that is officially recognized by the OGC.
Includes amongst its leading members key NRCan collaborators, including the United States Geological Survey, the European Space Agency, the United Kingdom Ordnance Survey, The United States National Aeronautics and Space Administration, and GeoScience Australia.
Can have direct input into the current and future directions of the provider through binding voting rights.
Have rights within the organization that are equivalent to those provided by the OGC at an equivalent membership level (e.g. NRCan’s OGC strategic membership rights to be represented in an equivalent way).

The provider must have documented organizational structure, policies and procedures that govern open, international geospatial standards development, review, approval, publication, and maintenance. This must include the following (or equivalency):
A Planning Committee, with experience in exploring market and technology trends to ensure that its activities remain effective and agile in a changing technology environment. This committee must contain a mechanism where member organizations can voice their opinion on the direction of the organization through binding voting rights.
A Technical Committee with experience in managing international, open standards development processes. This committee must contain a mechanism where member organizations can voice their opinion on the direction of the standards development process through binding voting rights.
Documented and published policies and procedures that are collaboratively developed and maintained by the organization’s members though binding voting rights.
Intellectual Property provisions and processes in place that balance open standards development with commercialization.

The provider must be able to demonstrate that they can provide ongoing, long-term support to its members through the provision of the following services:
Provide member access to other international standards development organizations such as ISO and W3C.
Organize, manage and maintain a member web portal, wiki, mailing list, meeting minutes and online resource repositories for the proposed project, as well as all other initiatives the organization undertakes.
Provide pre-set dedicated staff hours to support NRCan CGDI development activities.

The provider must be able to demonstrate that they have in place an Innovation Program (or equivalent) that will enable future research to be completed that will build on outcomes of Testbed-16. This program must be capable of producing results that can be officially accepted and implemented by the OGC.
The provider must be able to demonstrate that they have in place a Standards Program (or equivalent) that will enable outcomes of Testbed-16 to be incorporated into official OGC standards. This program must be capable of producing results that can be officially accepted and implemented by the OGC.

4. Trade Agreements
This procurement is subject to the following trade agreement(s):

North America Free Trade Agreement (NAFTA);
Canada Free Trade Agreement (CFTA);
Canada-Chile Free Trade Agreement (CCFTA);
Canada-Columbia Free Trade Agreement (CCoFTA);
Canada-Honduras Free Trade Agreement (CHFTA);
Canada-Panama Free Trade Agreement (CPaFTA); and
Canada-Korea Free Trade Agreement (CKFTA)

5. Justification for the Pre-Identified Supplier
The supplier mentioned in section 11 below is the only known supplier that meets the mandatory criteria set out in section 3 above.
Should Canada receive a statement of capabilities from a supplier that contains sufficient information to indicate that it meets the requirements set forth in this ACAN, a competitive process will be triggered with a technical and financial evaluation methodology of the bids proposed by the potential bidders
6. Exception to the Government Contracts Regulations
The following exception to the Government Contracts Regulations is invoked for this procurement under subsection:
6(d) – only one person is capable of performing the work.
The identified provider identified in section 11, is the only one able to meet all of the criteria identified in paragraph 3 above.
7. Exclusions and/or Limited Tendering Reasons
The following exclusion(s) and/or limited tendering reasons are invoked under the:
Applicable Limited Tendering Provision under NAFTA (Article 1016.2)
1016.2(b) - where, for works of art, or for reasons connected with the protection of patents, copyrights or other exclusive rights, or proprietary information or where there is an absence of competition for technical reasons, the goods or services can be supplied only by a particular supplier and no reasonable alternative or substitute exists;
Applicable Limited Tendering Provision under Canada-Chile (Article Kbis-09)
Kbis-09 (b) - where, for works of art, or for reasons connected with the protection of patents, copyrights or other exclusive rights, or proprietary information or where there is an absence of competition for technical reasons, the goods or services can be supplied only by a particular supplier and no reasonable alternative or substitute exists;
Applicable Limited Tendering Provision under CFTA (Article 513.bi)
506.12(b) – where there is an absence of competition for technical reasons and the goods or services can be supplied only by a particular supplier and no alternative or substitute exists;
Applicable Limited Tendering Provision under Canada-Honduras (Article 17.11)
17.11.2 b) a good or service being procured can be supplied only by a particular supplier and a reasonable alternative or substitute does not exist because:
(i) the good or service is a work of art,
(ii) the good or service is protected by a patent, copyright or other exclusive intellectual property right, or
(iii) there is an absence of competition for technical reasons;
Applicable Limited Tendering Provision under Canada-Panama (Article 16.10)
16.10.1b) a good or service being procured can be supplied only by a particular supplier and a reasonable alternative or substitute does not exist because:
(i) the good or service is a work of art,
(ii) the good or service is protected by a patent, copyright or other exclusive intellectual property right, or
(iii) there is an absence of competition for technical reasons;
Applicable Limited Tendering Provision Canada-Colombia (Article 1409.b.ii
a good or service being procured can be supplied only by a particular supplier and a reasonable alternative or substitute does not exist because:
(i) the good or service is a work of art,
(ii) the good or service is protected by a patent, copyright or other exclusive intellectual property right, or
(iii) there is an absence of competition for technical reasons
8. Ownership of Intellectual Property
Ownership of any Foreground Intellectual Property arising out of the proposed contract will vest in the Contractor.
9. Contract Period
The contract period will be from Date of Contract Award to January 31, 2021.
10. Estimated Cost
The estimated maximum value of the contract is $129,950.00 CAD (taxes inclusive).
11. Name and Address of the Proposed Contractor
The Open Geospatial Consortium
35 Main Street
Wayland, Maryland, 01778
12. Suppliers’ right to submit a statement of capabilities
Suppliers who consider themselves fully qualified and available to provide the services/goods described herein, may submit a Statement of Capabilities in writing, preferably by e-mail, to the contact person identified in this Notice on or before the closing date and time of this Notice. The Statement of Capabilities must clearly demonstrate how the supplier meets the advertised requirements.
13. Closing Date
The closing date for a submission of a Statement of Capabilities is April 9, 2020 at 14:00pm (EDT).
14. Contract Authority
Name: Micheline Boucher
Address: 580 Booth Street, Ottawa, Ontario K1A 0E4
Telephone: 343-292-8372
Email: M••••••••@••••••.ca