OGC Routing Pilot Sprint

Registration: 
Start: 
Monday, 22 November 2021 08:00 EST
End: 
Friday, 3 December 2021 17:00 EST
Event Description: 

 

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

M01

October 20, 2021

Release of Call for Participation (CFP)

M02

November 5, 2021

CFP Proposal Submission Deadline (11:59pm EDT)

M03

November 12, 2021

All Participation Agreements signed

M04

November 18 - 19

Half-day Kickoff Workshop (virtual)

M05

November 22 - December 3

2 week sprint to develop implementations and demos

M06

December 6 - December 14

OGC Member Meeting

M07

December 6 - December 31

Routes - Part 1: Core and Route Exchange Model Documentation

M08

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.