The Pilot has completed. The Open Routing API Pilot developed new capabilities to easily share routes and prototype APIs able to use routing data from any source – based on the next generation of OGC APIs.
Road network data, routing and navigation algorithms, as well as implementations for route calculation, are available from many providers and sources. While diversity in the marketplace is generally beneficial to consumers of route information, it makes the integration, overlay, or comparison of routes from different routing services a complex process. Consumers are offered route assistance derived from different road and network characteristics, based on different information models and served in different formats. Further, the routing services themselves offer non-standard interfaces with varying query models and parameter options.
This pilot addressed these interoperability issues and expanded the ability of routing services to incorporate diverse data, routing algorithms, and planning parameters in a standardized way. The pilot generated a JSON-based route model for route exchange, comparison, and integration.
This Pilot demonstrated a standards-based solution for a variety of online and offline routing situations. Consumers were able to request and share routes using desktop clients, browser-based apps, and mobile apps. These clients could interact with online services, local routing engines that work on route network data stored in local GeoPackages, or hybrid combinations of both.
All results of this pilot were forwarded to the OGC Standards Program for consideration as input into new or existing standardization efforts.
Why are the WPS interfaces and Routing Engines separate?
The goal here is to separate the refinement of the WPS 3.0 interface (and variations between implementations) from the variation in routes derived from different source datasets and routing algorithms. The testing API’s for each routing engine (process – dataset combination) allow each route to be compared before and after passing through the WPS component. This could in fact be a WPS, but it is generally the case with existing engines and WPS components that the former already have bespoke API’s to invoke them and the latter have (bespoke) pluggable architectures to connect with processes.
In addition, there is the opportunity to compare in one application a route from a local routing engine calculation (absent a WPS interface) versus one obtained through a remote WPS request.
Can you clarify the expectations around the interaction between the WPS interfaces (D102, D102, D110) and the Routing Engines (D104, D105, D106)? Specifically, the Routing Engines are required to provide a testing API accessible through the web (with curl). Is the expectation that this testing API may be bespoke for D104, D105, and D106? I am unclear why this interface wouldn’t be WPS.
Since a WFS3.0 compatible WPS 3.0 and a routing profile have yet to be developed, these are unlikely to be available, but the testing API’s could be forms of earlier or preliminary WPS interfaces.
Is the expectation that the WPS interface will receive well-formed WPS 3.0 requests, and recast that request up to three times to interact with each Routing Engine?
Yes, through negotiation between the WPS backend API and the Routing Engine bespoke API.
Is the response from the Routing Engines expected to be a GeoJSON-formatted Route that is simply passed through directly to the consumer, or is there an expectation that the WPS interface will need to understand potentially three different bespoke responses and craft the appropriate WPS response?
The latter — since a common exchange format does not yet exist, different (existing) routing engines are unlikely to support it.
Is the WPS interface expected to perform brokering and down-selection of responses from issuing parallel queries to all Routing Engines, or is that left as a consumer-side application-level assessment?
The latter – WPS components return routes according to the requested parameters. Client applications visualize and present for selection alternate route results.
Do the mobile Routing Applications interface with GeoPackage vector data or directly with source data (OSM, HERE, NSG)?
The routing applications +/- mobile route engines draw source data from GeoPackage storage.
It sounds like the Routing Applications are building routes from transformed source data stored as GeoPackage, rather than native formats (OSM/HERE/NSG). This is likely just my own ignorance, but is there a canonical way of describing routing source data in GeoPackage (for instance, the various schema representations, direction of travel, overhead obstructions, etc.)? The Previous Work section of the CFP referenced TB-12 GeoPackage Routing and Symbology ER, but this doesn’t seem to detail the capture of routing source data in a GeoPackage, but instead the portrayal of pre-existing routes from GeoPackage – maybe I’m overlooking something? Is there additional Previous Work that’s relevant here, or is agreeing such a schema part of the scope for D111, D112, and D113?
There is no canonical representation yet agreed for routing source data in GeoPackage and creating one is not a requirement of this Pilot. It is expected that the GeoPackage format for each source dataset will be agreed between the data providers and the routing engine providers.
The text for D111, D112, and D113 all read “GeoPackage with all routing source data type OSM”; I think that’s just a copy-paste typo where it should be OSM/HERE/NSG
Correct.
Do the mobile Routing Applications duplicate the Routing Engine functionality?
They incorporate or connect to it (“Ideally, route app and route engine are decoupled and made available as separate elements on the mobile device.”).
In addition to providing a user interface and formulating the proper requests (analogous to browser/desktop clients D100 and D101), do work items D108 and D109 also have to implement all functionality of D104, D105, or D106?
Yes
Do {D108, D109} and {D104, D105, D106} support all of B.2.4 Route Types and Elements?
Ideally. Note that B.2.4 merely maps one schema representation, one route optimization criterion, and 5 route parameters onto each of the three dataset types.
Will the Here source data be provided in GDF format?
The Here source format has not been determined at this time. GDF is a possibility.
Our partners
We represent over 500 businesses, government agencies, research organizations, and universities united with a desire to make location information FAIR – Findable, Accessible, Interoperable, and Reusable.
