OGC Routing Pilot Sprint: Call for Participation (CFP)

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.

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?

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.

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.