Routing SWG


Harrison, Jeff (US Army Geospatial Center) - Group Chair

Group Charter:

Download Charter document

Group Description:

1.    Purpose of the Routing Standards Working Group


The purpose of this Standards Working Group is to:


       Develop and maintain an OGC API - Routes[1] core standard;

       Develop and maintain extensions of the OGC API - Routes core standard; and

       Develop and maintain a route exchange model.


The formal proposed name of the new standard is "OGC API - Routes - Part 1: Core." The short name “Routing SWG” or ‘Routing API” may also be used to refer to this effort in the charter and work products.


2.    Business Value Proposition

Routing is one of the most widely used geospatial operations in the world today. However, OGC does not currently have a modern API and methods for routing.


Open frameworks have made defining a common interface to support routing attainable. The capability for a client to request routes from a Routing API provider, retrieve routes, and share routes between applications will improve interoperability for many users, communities, and enterprises.


The proposed API will provide methods and apparatus to support:


       Executing basic commands to GET, PUT, PATCH, POST, and DELETE route resources; and

       Interface with other resources using OGC API capabilities.


The proposed route exchange model will provide a method to share routes, regardless of the underlying proprietary data, routing engine software, and algorithms.


For providers of routes, the API and route exchange model will provide a simple model to publish and offer those routes as resources for use by other systems.


For developers building infrastructures, the API provides common methods to describe and leverage existing routing engines and algorithms using modern APIs - saving development and deployment time and costs.


For users, applications, and enterprises, the capability to get routes across a common API, regardless of the underlying routing data, engines, or algorithms, represents a significant step forward in geospatial interoperability.


Finally, it is recognized there are many environments for implementing open routing including on road, off road, air, sea, and many others. In addition, some communities may require specialized parameters in their Routing API.


Accordingly, the proposed API will accept starting and ending positions that may be in many environments, return paths and waypoints between those positions, and be extensible to support parameters required by diverse implementation communities.

3.    Scope of Work


OpenAPI frameworks have helped to make both description and sharing of API definitions more suitable for standardization than previous solutions. For this reason, OpenAPI will be used for OGC API - Routes. The concept of a Routing API was demonstrated in the OGC Open Routing API Pilot and OGC SCIRA Pilot.


The Routing SWG will build on those preliminary efforts to more fully develop and document a Routing API candidate standard that will provide a modernized, common, and consistent interface to services that aligns with the current architecture of the Web and the Spatial Data on the Web Best Practices ( ). The Routing SWG work will be coordinated with the Joint W3C/OGC SDWIG. It is anticipated that the primary point of discussion in W3C will be with the W3C Automotive and Transportation Business Group.

The Routing SWG will develop a Routing API candidate standard which is informed by emerging OGC API best practices and prior API standards examples (e.g., OGC API - Features) to define core API functions of GET, PUT, PATCH, POST, DELETE applied to routes as resources. The Routing API will also document requirements for routing to enhance exchange of routes.


• Architecture:


The OGC API - Routes standard will specify an implementation specification aligned with prior work in OGC for Web APIs. The proposed standard will define API building blocks for routes in a Web API. OGC API - Routes will be consistent with HTTP and HTTPS.


• Encodings:


The first version of the Routing API will support JSON and HTML as encodings of the resources in the API. No encoding will be mandatory and other encodings may be used as well. The HTTP focus is designed to support the use of multiple formats and defines rules about how servers can return the encoding that the client can best handle (“content negotiation”). The SWG will consider requirements and conformance classes for supporting route resources in multiple encodings in the design of the Routing API.


• Basic information model:


The Routing API standard will conform to OpenAPI models and OGC API best practices. Additionally, the API will align with the emerging conceptual model and route model efforts.


• Reuse:


The use of unique Routing API resources or components will be minimized and, where available, existing industry-standards or patterns that are commonly used by developers will be used instead. The most important example for this is the use of an OpenAPI definition instead of OGC-specific "Capabilities" documents and the use of OGC API - Common components to the maximum extent practicable.


• Modularization:


OGC API - Routes - Part 1: Core will define a basic set of capabilities organized in multiple conformance classes building on each other. The minimal conformance class will specify a simple interface to access route resources. The conformance class is sufficient for interfaces to exchange and perform basic web functions with the route resources. Additional conformance classes will define additional capabilities based on the requirements and requirements classes defined in the core to meet the needs of use cases that require such capabilities.


Identified extensions to be worked within the initial scope of the SWG charter include extensions for community specific parameters. Other extensions may be proposed and addressed in revisions to this charter. The primary goal of the Routing SWG is to develop the core of "OGC API - Routes" as quickly as possible and work on extensions after that, driven by community interest. An important aspect is to ensure that implementing the standard will lead to efficient implementations, happy developers of both server and client components, and satisfied users of such components.


Before finalizing parts of the future versions of the "OGC API - Routes," completion of goals should be verified:

       Working implementations of all capabilities must be available and tested; and

       Implementation feedback must be taken into account.


A consequence of this verification is that the period between the availability of what is considered a mature draft and the finalization of the candidate standard may be longer than in the past, depending on the availability of evidence about the suitability of the candidate standard based on implementations.


Developers should be encouraged as early as possible to implement the draft API specification and provide feedback. An aspect of this is public access to drafts from the beginning. To this end, the SWG intends to use GitHub in the development of this standard, as this is the environment many developers are familiar with and use on a daily basis.

3.1    Statement of relationship of planned work to the current OGC standards baseline

This proposed standard is intended to be a major component of the OGC API framework. The proposed standard will take advantage of Web API patterns identified in OGC API standards (e.g., OGC API – Features) and consider ongoing API efforts (e.g., OGC API - Common development within the OWS Common SWG and OGC API – Processes, within the WPS 2.0 SWG) to better align with current and emerging IT practices. 

3.2    What is Out of Scope?

Standards are important for interoperability. At the same time, it is important that standards only state requirements that are important for a significantly large group of users. Proposals for new parts of OGC API - Routes or change requests to existing parts must identify the user group that will benefit from the proposal and for each proposed conformance class; otherwise the proposal will be considered out-of-scope.

OGC API - Routes is envisioned to be a modular, multi-part standard. Extensions and profiles not identified as in scope in the previous section will require addition of Tasks to the SWG charter prior to commencement of work. If a community has a need to develop a profile, the profile should be specified and governed by that community.

3.3    Specific Contribution of Existing Work as a Starting Point


The starting point for the work will be the OGC 19-041r3: Routing Pilot Engineering Report and OGC 19-040: WPS Routing API (draft specification) Engineering Report. The work shall also be informed by the following specifications and by recommendations found in:

      OGC/W3C Spatial Data Working Group on the Web Best Practices ( bp/);

      OGC Geospatial API White Paper [OGC 16-019r4];

      OGC API - Features - Part 1: Core standard, [OGC 17-069r3]; and

      OGC API – Processes (Draft).


Each of these documents recommends an emphasis on resource-oriented APIs in future OGC standards development including use of tools such as OpenAPI.


4.    Description of Deliverables

4.1    Initial Deliverables

The following deliverables will result from the initial work of this SWG:

     A final version of the “OGC API - Routes - Part 1: Core” document for submission to the TC;

     A final version of a Route Exchange Model document for submission to the TC;

     Identification of at least three prototype implementations of the core based on the standard; and

     Zero or more additional parts as time and community interest permits.

“OGC API - Routes - Part 1: Core” will cover basic capabilities to GET, PUT, PATCH, POST, and DELETE routes and define route metadata. Capabilities for richer routing interfaces or extension for unique geospatial resource considerations will be specified in additional parts.

Once this charter is approved, the targeted start date of this SWG is in July 2020. Initial candidate route exchange model and API specifications are anticipated by the end of calendar year 2020 with demonstrated implementations and formal approval of the core Routing API in 2021.

4.2    Additional SWG Tasks

To be completed as SWG takes on new tasks. For example, a routing conceptual model that may provide an abstract construct to encompass multiple routing modes, constraints and considerations.


5.    Anticipated Participants

Geospatial resource providers.

Developers implementing routing services and applications.

Users of geospatial resources.

6.    Other Informative Remarks about this SWG


a.      Similar or Applicable Standards Work (OGC and Elsewhere).

The following standards work may be applicable to the work of the proposed SWG:

     17-069, OGC API - Features

     16-120r3, OGC Moving Feature Access

     16-140, OGC Moving Feature Encoding Extension – JSON (Best Practice document includes API, being updated in 19-045r2, OGC Moving Features Encoding Extension – JSON (candidate standard)


Additionally, the proposed SWG will monitor other OGC API work ongoing in various Standards and Innovation Program activities (e.g., OGC API - Common and API work on Processing, Coverages, Tiles, Moving Features SWG, etc.).

[1] The general naming pattern that is agreed to in OGC is "OGC API - {resource type}" and the term "Routes" is assessed to be a better fit than "Routing." For example, other APIs are "Tiles" and "Maps", not "Tiling" or "Mapping."