Getting Started with OSRM: A Guide

OSRM Backend Image from Github

Introduction

OSRM stands for Open Source Routing Machine, it is an open-source routing engine that provides fast, accurate, and customizable routing services.

Dennis Luxen initially developed it at the Karlsruhe Institute of Technology in Germany, and many organizations and communities around the world have adopted it.

💡 One of those organizations also happens to be Ula where I work as a Senior Software Engineer.

OSRM is built on top of OpenStreetMap (OSM), which is a collaborative mapping project that provides free and open geographic data.

It combines sophisticated routing algorithms and uses speed-up techniques called Contraction Hierarchies or Multi-level Dijkstra to compute and output the shortest path between any origin and destination within a few milliseconds on a continental-sized network.

Benefits

1. Fast and Efficient Routing: Designed to handle large amounts of data and provide fast routing services, making it ideal for applications that require real-time routing information.
2. Open-Source: Open-sourced, which means it’s free to use and can be modified to suit your needs. It also has a large and active community of developers who contribute to its development and support.
3. Integrated with Other Tools: It is integrated with other tools and platforms, such as web mapping libraries like Leaflet and Mapbox, making it easy to use in different contexts.
4. Accurate and Up-to-date: Built on top of OpenStreetMap, which is a collaborative mapping project that provides free and open geographic data. This means OSRM routing data is often more accurate and up-to-date than proprietary mapping services.
5. Customizable Routing Profiles: Added support for creating custom routing profiles based on your specific needs, such as routing for cars, bicycles, or pedestrians, and customizing the routing algorithms and weights.
6. Wide Range of Use Case: It can be used in a variety of contexts, such as transportation planning for cities, logistics optimization for businesses, and outdoor recreation mapping.

💡 Based on my experience implementing a production-grade Routing Platform using OSRM for our B2B e-commerce, OSRM being open-source and customizable is a proven boon.

⚠️ You will need experience with docker and terminal to follow this section

Setup

There are several ways of starting your own OSRM server, but we’ll discuss the docker container way which is the easiest to follow:

Commands

1. Pull the latest OpenStreetMap data from the website geofabrik.de. We are downloading northeast India’s data.
2. Pull the docker image for the osrm-backend.
3. Extract routing rules and conditions from the .osm.pbf data based on the transportation mode specified using osrm-extract.
   sudo docker run: Creates a container.
   -t: Creates a pseudo-tty.
   -v “${PWD}:/data”: Creates a new volume in a directory called “data” inside the container linked to PWD, the current directory.
   osrm/osrm-backend osrm-extract / partition / customize / routed: OSRM docker modules being used.
   -p /opt/car.lua: The -p flag specifies the transport mode profile to be used. Here we’re using the profile for a car. The available options are car, bicycle, and foot which each have unique routing characteristics.
   /data/north-eastern-zone-latest.osm.pbf: This specifies the .osm.pbf file to be used.
4. Partition the graph recursively into cells using osrm-partition.
5. Customize these cells by calculating routing weights for all cells this is also where we can add routing information using osrm-customize.
6. Start the server on port 5000 using osrm-routed and Multi-level Dijkstra’s Algorithm.
   -d: Start the container in detached mode, i.e. have it run in the background.
   -p 5000:5000: This publishes the ports that we can query OSRM via later on.
   --rm: Removes the container once we stop it running.
   --name osrm: Calls this container OSRM.
   --algorithm mld: Specifies that OSRM should use the MultiLevel Dijkstra (mld) algorithm, discussed here. The other option is the Contraction Hierarchy (ch) algorithm, but beware that the docker commands are different if you want to set up OSRM to use the latter.
7. Optionally, start osrm-frontend to play around with your service. Or use the below cURL to check the successful setup
   curl --location 'localhost:5000/nearest/v1/driving/92.9376,26.2006'

This is how the file structure would look post-successful setup.

Gist of the commands discussed above.

Services

OSRM provides six API details which can be found here.

Short Description of OSRM Services

Nearest: Snaps given coordinates to a list of “known” coordinates in the road network. Similar to how Uber / Ola snaps to a location that is most recognized and closest to you as a pickup point.

Route: Given a set of coordinates A, B, C, D returns the fastest way to reach B from A, C from B, and D from C. See how in the below image fastest way from Hanoi to Da Nang is taking the direct route but since we added Phnom Penh route considers that. This is an image from google but this is how the route service works.

Use Case of Route API

Table: A bit technical, this service returns an array of distance and/or duration between all given points. Useful in optimization engines 😉.

Match: Matches/Snaps given GPS points to the road in the most plausible way. Mostly used in apps like Nike Run.

Trip: Solves the traveling salesman problem, i.e given a set of coordinates A, B, C, D and starting position as S it will return the most optimal path from S to S while covering all coordinates A, B, C, D.

Tile: Tile service can be used to debug the road network at any point.

Future

The future of OSRM is promising, as ongoing developments and improvements are being made to the software. Here are some possible future directions for OSRM:

1. Improved Performance: One of the ongoing goals for OSRM is to improve its performance, both in terms of routing speed and memory usage. There are several open issues related to performance improvements, such as optimizing the use of RAM and CPU resources.
2. Enhanced Customization Options: OSRM’s routing profiles can already be customized to a certain extent, but there are ongoing efforts to make this customization even more flexible such as https://github.com/Project-OSRM/osrm-backend/issues/5785.
3. Integration with other Services and Platforms: OSRM is already integrated with several web mapping libraries and platforms, but there are ongoing efforts to improve this integration and make it even easier to use OSRM in different contexts.
4. Improved Data Quality and Coverage: OSRM’s routing data is built on top of OpenStreetMap, which is a community-driven mapping project. There are ongoing efforts to improve the quality and coverage of OpenStreetMap data, which will in turn improve the accuracy and usefulness of OSRM’s routing services. There are several open/closed issues related to improving data quality, such as identifying and fixing routing errors and improving the tagging of road network features
5. Support for new modes of Transportation: OSRM currently supports routing for cars, bicycles, and pedestrians, but there are ongoing efforts to add support for new modes of transportation, such as public transit and micro-mobility (e.g. scooters and e-bikes). There are several open issues related to adding support for new modes of transportation, such as integrating with GTFS feeds for public transit routing and adding support for shared micro-mobility (cycles, etc) vehicles.
6. Other: More such efforts and open requests can be found or can be made here.

Limitations and Alternatives

While OSRM is jam-packed with features it’s not perfect, here are some limitations for OSRM and possible alternatives.

1. No support for Request Body: As seen earlier every request to OSRM consists of either path params or query params which often leads to huge URLs (more than 16–32K characters) which isn’t supported by AWS load balancers. A possible resolution is using an outgoing call interceptor in the client to convert to request body and another interceptor in the routing engine to convert to path param.
2. Large Memory Footprint: OSRM’s fast response comes with a trade-off that it can take up upwards of 16 GB of RAM and 1 hour to just extract, partition, and customize data which makes deployment and maintenance trickier and increases cost. A possible resolution is using something like EFS Volume in AWS.
3. Limited routing data: OSRM’s routing data is based on OpenStreetMap, which is a community-driven mapping project. While OpenStreetMap is a rich source of geographic data, it may not be as comprehensive or accurate in some regions compared to commercial mapping services like Google Maps.
4. Limited support for non-car modes of transportation: While OSRM does support routing for bicycles and pedestrians, its support for other modes of transportation like public transit and micro-mobility (e.g. scooters and e-bikes) is limited.
5. Limited customization options: While OSRM’s routing profiles can be customized to a certain extent, the customization options may not be sufficient for some use cases.
6. Limited real-time traffic data: OSRM does not currently incorporate real-time traffic data into its routing algorithms, which may lead to less efficient routing in some cases.

Alternatives: Google Maps, MapBox, GraphHopper, and OpenRouteService.

That’s been my two cents on OSRM and its setup. I’m a new writer and would love to hear feedback and suggestions. Thanks for reading this far.