1. Overview

The Open Geospatial Consortium (OGC) is releasing this Call for Participation (CFP) to solicit proposals for the OGC Routing Pilot Sprint. This initiative builds on what was accomplished in the Routing Pilot concluded in September 2019.

The goal is to finalize the OGC API - Routes - Part 1: Core (hereafter, Routes - Part 1: Core) and the OGC Route Exchange Model (hereafter, Route Exchange Model) candidate standards and develop 3 implementations of each standard. These should prove out the existing documentation from the Routing SWG, and address issues and future works. Everything in the Sprint should be documented in the GitHub repository.

This initiative is being conducted under the OGC Innovation Program. A PDF version of this CFP can be Downloaded Here.

2. Master Schedule

Table 1. Master Schedule
Milestone Date  Event


October 20, 2021

Release of Call for Participation (CFP)


November 5, 2021

CFP Proposal Submission Deadline (11:59pm EDT)


November 12, 2021

All Participation Agreements signed


November 18 - 19

Half-day Kickoff Workshop (virtual)


November 22 - December 3

2 week sprint to develop implementations and demos


December 6 - December 14

OGC Member Meeting


December 6 - December 31

Routes - Part 1: Core and Route Exchange Model Documentation


December 31

Routes - Part 1: Core and Route Exchange Model submitted to OAB

3. Scope

3.1. Overview

Routes - Part 1: Core and the Route Exchange Model candidate specifications are currently in draft form, and while they are close to finalization, they need to be tested, issues need to be resolved, and future work needs to be documented. To bring these candidate specificatinos to completion they need to be tested through the development of 3 implementations for each candidate standard. These should prove out the existing documentation from the Routing SWG, resolve minor issues that are not projected as future works, and develop or enhance existing future works. All issues should be documented in the GitHub repository, as should the new future works or enhancements to existing items in the GitHub repository labeled as future works.

The initiative will focus solely on the implementations that are needed to complete the candidate specification and documenting the outcomes of those implementations. Minor issue corrections and general editorial corrections are encouraged, as well as documenting conflicts with existing OGC APIs. However, major additions that greatly expand the current scope of the existing documentation should be added to the issues list as a potential future work.

3.1.1. Scenario

The main data to be utilized in this initiative will be OpenStreetMap. A couple initial scenarios are outlined below for consideration. We, the OGC, the Sponsor, and the chosen participants will discuss and determine the appropriate scope in the kick-off workshop. The final scenario could be one of the below or something new brought to the workshop by the sponsor or a participant.

  1. A surge of goods has been received in the Port of Los Angeles. These goods will need to be distributed to various distribution centers throughout the United States for further deployment to retail distributors.

  2. A natural disaster (Katrina on New Orlean, Harvey on Houston) or man-made disaster (9/11, Texas Power Grid Outage) has affected a major city in the United States. A mobilization from across the country is needed to get manpower and resources to ground zero.

The key questions to answer through these scenarios; what routes can be utilized to accomplish this through the quickest routes, shortest routes, or with consideration to vehicle height or weight restrictions?

3.1.2. Routes - Part 1: Core

The Routes - Part 1: Core is a modular API building block which looks to create efficiencies in computing new routes, specify additional or new endpoints, communicate routes synchronously or asynchronously, delete stored routes on a server, swap profiles of routes, etc. Much of this documentation utilizes OpenAPI definitions in YAML, requires servers to be based upon an OGC Schema, and will borrow some notation from OGC API - Processes to align building blocks in the OGC API ecosystem. This standard defines a set of conformance classes which is tested under the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing website

The bare minimum requirement for a Routing API is to compute a route based on a start and end point. The API interacts with HTTP methods GET, POST, DELETE. The resulting route is encoded using the Route Exchange Model. These requirements enable implementations to work in all types of connectivity situations, including Denied, Disrupted, Intermittent, and Limited (DDIL) bandwidth communications networks.

3.1.3. Route Exchange Model

The Route Exchange Model focuses on transforming the Routes API outputs into 3 scenarios: online, intermittent, and offline.

The online scenario uses a routing client to request a route from a Routing API provider, which in turn retrieves the route from an online routing engine. In this scenario all components have consistent connections between them and out to the wider internet. OGC API Routes would be utilized from all requests and responses between the client and infrastructure.

The intermittent scenario is where components have connectivity, but it is not necessarily consistent, stable, reliable, or high-speed. Thus, the network cannot be relied upon to provide adequate connectivity for all interactions needed. Intermittent connectivity is unpredictable and therefore might be treated as no connectivity for certain real-world scenarios. In other scenarios one client may have sufficient connectivity to the Routes service and can communicate results to other clients via some other connection method (Bluetooth, P2P, etc.), so the clients could share pre-defined routes – a routing operation that was completed when connected to the routing engine, but that connection has now been lost.

The offline scenario assumes that there is no connectivity outside of a devices local network. For this instance, the operator uses the routing functionality provided by the client to create a route. To enable this functionality, all the capabilities need to be tightly coupled to the location, this would normally involve installing components on the local machine to remove the communication dependencies.

These are accomplished through utilization of a GeoJSON encoding of the data output from the Routes API. The Route Exchange Model also supports three variants to display the data stream. A full view which incorporates all route information encoded in a GeoJSON feature collection. An overview variant which is a single GeoJSON feature stream detailing the route geometry along the network and the main properties along the route. The third variant is segments in which the first segment of a route which links to a second segment, which links to the next segment and so on, where each segment is it’s own GeoJSON feature set.

4. Guidelines and Stipends

4.1. Submission Guidelines

  • Proposals must be submitted by November 5, 2021 by 11:59pm EDT in accordance with the Master Schedule.

  • Proposals from non-members or individual members will be considered provided OGC Membership (or a letter of intent) is provided with Proposal Submission

  • Each selected proposing organization will be required to enter into a Participant Agreement (PA) contract with OGC, regardless of receipt of cost-share funds

  • Proposals should be submitted in PDF format and should contain an overview of planned implementations and documentation goals, requested payment stipends, in-kind contributions (if any), stretch goals (if any)

  • It should be clear how each planned implementation relates to the core scope

4.2. Cost-share Stipends

  • Stipends in the amount of $4,000 USD are available

  • A maximum of 2 stipends can be requested per participant for a total of $8,000

  • Each stipend should be directly related to an implementation or editing/completing documentation of the candidate standard

4.3. How to Submit

Email Rollin Phillips <rphillips@ogc.org> the PDF Proposal prior to November 6, 2021


5. Corrigenda & Clarifications

5.1. Corrigenda Table

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.

Table 2. Corrigenda Table
Section Description

4.1 Submission Guidelines and 4.2 Cost-share Stipends

Inclusion of documentation as an expected deliverable and availability of cost-share stipend

1 Overview

Clarification of reference to OGC API - Routes - Part 1: Core and OGC Route Exchange Model

5.2. Clarifications Table

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

Table 3. Clarifications Table
Question Clarification

Is the initiative about validating the standards and demoing them in the OGC meeting or about making a stress test on the standards trying to find errors, ambiguities, or deficiencies during the sprint?

To validate and demo the standard in order to best move from a candidate standard to an OGC-API Building Block. Errors, ambiguities, deficiencies should be noted if they are not critical, critical items should be resolved

What is considered an implementation; a server implementing the Routes - Part 1: Core, a client reading the Route Exchange Model, or a fully working ecosystem?

An implementation would be either a server or a client, developing both would be 2 implementations

Are all participants focusing on one single common scenario?

Yes, the final scenario will be discussed in the kick-off

Is there an expectation to keep the implementations online for a period of time?

No, this is not within the scope

Is cost-sharing available for documentation

Yes, this was neglected in the original drafting, Corrigenda Item 1 rectifies this issue

( end of document )