The most recent feature of our Cyface Service is the integration of map-matching. Now road condition data is not only available as raw gps positions, but also matched to the road sections most likely causing the monitored vehicle vibrations. To achieve this we employed the Open Source Routing Machine (OSRM). The following sections describe how to use the OSRM map-matching service.
VISUALIZE OSRM map-matching results
The default source for understanding OSRM is the OSRM Wiki and documentation. If you can’t find detailed info on how the algorithms work you can ether crawl through the open source code or look closer at the matching results. The use of an online json formatter makes it much more fun to read the responses and interpret the behaviour.
In order to visualize the matching results you can decode the matching geometry with Google’s Online Decoder. By adjusting the request’s overview parameter you can tell OSRM how detailed the geometry overview should be.
For debugging, you probably need detailed information on resulting OSM node IDs (using annotation=true). OpenStreetMap.org helps you with this — their map service provides not only attributes of nodes but also list you the ways those nodes are part of.
For advanced analysis of the map matching in order to fine-tune the process, we found this tool which we’ll test soon.
How to PROCESS the OSRM response
After successfully setting up the OSRM service you can send matching requests to its API and receive zero, one or multiple matching responses of the following format:
- matchings (i.e. (sub)traces “route objects” of one or multiple matching alternatives)
- each subtrace contains “route legs” which represent the path between the OSM nodes lying on this trace.
- tracepoints (each gps point is mapped to a “waypoint” or “null” (for single outliers). This is the case for each matching alternative found by the service. These points are still in the same order as the gps point of your request.)
Unfortunately the official documentation does not mention too much about how these result points are ordered and structured. The following insights might save you some debugging time:
- “OSRM map matchings with different number of trace points then gps points entered?”
A request can not only return multiple matching alternatives but each of them can be sliced into multiple sub-traces (see OSRM Wiki: Response).
- “How to map a ‘null’ tracepoint of a OSRM matching response to a single ‘matching’?”
Fortunately, the trace points are ordered just like the matching alternatives and the original gps points. For example: If the response is
[matching_index, waypoint_index]: [0,0], [0,1], null, null, [0,2], [1_0], …
those two unmatched tracepoints (‘null’) are part of matching alternative with id 0.
Check out our demo to see the matching in action! We hope this new feature helps to make your application even cooler, using the Cyface road condition data.