Skymantics has a long record of researching and developing new routing algorithms and technologies but it was in the Open Geospatial Consortium (OGC) Open Routing API Pilot when the team built its own routing engine. This is the first of a series of short articles that summarize Skymantics’ experiences and findings while building an interoperable routing engine using OGC standards.
The goal of the Open Routing API Pilot was to develop an API that allowed requests for routes from different users in an interoperable and standardized way via Web protocols. OpenLS is an older existing standard for Location Services. OpenLS was developed 20 years ago, which is aeons in terms of technology evolution. It was developed with carriers and second-generation mobile phones in mind, quite far from the emerging next generation of OGC Web Service interface definitions. Just to get an idea how old OpenLS is, consider that by the time it started development, Excite and Yahoo! were the most popular search engines on the Internet and the Wireless Application Protocol (WAP) was considered the future in mobility.
As hard as it is to believe, there is no standard for routing or navigation. There are many services for consumers but they all offer non-standard interfaces with different query models and parameter options. Routing is an important-enough topic to have a standard of its own!
The main focus of the Open Routing API Pilot was to define a JSON-based route model, called Route Exchange Model, for route exchange, comparison, and integration and demonstrate its interoperability in a variety of situations: online/offline routing; desktop clients, browser-based apps, and mobile apps; online services and/or local routing engines that work with GeoPackages.
The figure below shows the various participants in the Open Routing API Pilot which sought to develop routing engines using OGC Web Processing Service (WPS) for improved interoperability and the Route Exchange Model for modeling standard routes.
There were four main requirements for the definition of the Route Exchange Model:
- It must be consistent with current OGC API implementations
- It should use GeoJSON, to benefit from existing tooling
- It must provide support for fetching parts of a route in environments with low bandwidth or intermittent connectivity
- It must be modular and extensible
The figure below is an example of a JSON route following the above requirements displayed on a map.
A very important piece of the puzzle was the interface for the routing services, a WPS 3.0 based on OpenAPI, should be able to connect with any of the pilot’s routing engines. As these are a new generation of web service interface definitions, two different approaches were implemented in parallel in order to compare them and start a discussion: (1) Routing API (more specific to routing) (see Table A) vs (2) WPS Profile API (more generic, similar to other non-routing interfaces) (see TAble B). Both approaches worked well, but the Routing API was simpler and more intuitive, whereas the WPS Profile worked particularly well for those familiar with the WPS standard.
Table A. Routing API overview
Table B. WPS Profile API Overview
The pilot was successful in developing a proof of concept in record time (approximately three months). It defined a Route Exchange Model and a new API for routing that allowed several newly developed clients (desktop, web, or mobile) to make calls to any of the four different newly developed web interfaces which could in turn use any of three different routing engines – Truly Interoperable! Some routing engines also offered several possibilities in terms of routing algorithms or source datasets. In our next article, we will go explore the architecture of Skymantics routing engine developed during the Open Routing API Pilot.
Note: images provided by Clemens Portele (Interactive Instruments)
Would you like to learn more?
Feel free to Contact Us, we’ll be happy to help!
