Understanding OSRM Routing with AWS

Introduction

I hope you are all doing well. In today's article, let's have a look at the Open Street Routing Machine, also called OSRM in short form. It is a high-performance routing engine designed to compute at street level using an OSM provider. The use cases of this OSRM are Navigation System, Logistics and Delivery, and Geospatial Analysis.

The agenda of this article.

What is OSRM, why is it required, and why is it faster
Initial Setup
Maintenance
Integration with Third-party Service
- Real-time Traffic
- EV Charging Station
High-level Architecture
Cost Comparision between another provider with OSRM
Use cases example
Conclusion

What is OSRM, why is it required, and why is it faster?

As everyone in today's trend, we don't know the exact location, and we used to plan our journey through a navigation system. We used to do this to avoid congestion and understand our timebound to reach the location. The same applies to commercial purposes. If we used to do commercial, it costs, that's where we need to see lots of pros and cons. and its benefits quick response, and others like (IaaS) or will it be PaaS.

Technically, OSRM uses a precomputed graph, which makes an extremely fast response engine. Also, it is primarily written in C++.

OSRM Routing Endpoints

To get the routing durations
- Request
  - Source and Destination co-ordinates
  - Sample input request: https://router.project-osrm.org/table/v1/driving/xx.xx,yy.yy(source); xx. xx, yy. yy(destination)
- Response: waypoints and durations
To get the route planner, for eg., step-by-step
- sample input request: https://router.project-osrm.org/route/v1/driving/xx.xx,yy.yy(source); xx. xx, yy. yy(destination)
- this endpoint will result in the distance between two endpoints and give directions like left turn, right turn, etc.,

Setup OSRM Environment

To set up an environment, we could classify it into two sections: one for development or lower environment, and the second is the higher or live environment.

Steps to follow

#	Environment	Ubuntu
1	Clone the OSRM Backend Repository	git clone https://github.com/Project-OSRM/osrm-backend.git cd osrm-backend
2	Install Dependencies	sudo apt update sudo apt install build-essential cmake git g++ libboost-all-dev libprotobuf-dev protobuf-compiler libosmpbf-dev libluajit-5.1-dev libtbb-dev libstxxl-dev libstxxl1v5 libxml2-dev libzip-dev libbz2-dev zlib1g-dev pkg-config libgdal-dev python3 python3-pip
3	Build OSRM	mkdir build cd build cmake .. cmake --build.
4	Download the required map location from this link. https://download.geofabrik.de/. Use the below format to download country or continent data	wget -O https://download.geofabrik.de//.osm.pbf
5	Configure STXXL	cd ~/osrm nano .stxxl Paste the following line and save the file. disk=/tmp/stxxl,10G,syscall reference link : https://stxxl.org/tags/master/install_config.html
6	Extract the Map	osrm-extract -p /path/to/your/profile.lua /path/to/your/map.osm.pbf -p profiles/.lua: This specifies the profile (e.g., car.lua, bike.lua, foot.lua). Profiles define how different routes (e.g., car, bicycle) are handled.
7	Partition the Graph	osrm-partition /path/to/your/map.osrm This step divides the road network into regions, which helps to make routing queries more efficient.
8	Contract the Graph	osrm-customize /path/to/your/map.osrm This step reduces the number of nodes by creating shortcut edges, speeding up long-distance routing queries
9	Finally, start the Routing Engine	osrm-routed /path/to/map.osrm

Environment Setup or guidance

To set a proof of concept, you could set it up using the docker desktop itself in a Windows machine, which runs in localhost:5000
If you would like to set it up in the cloud, for example, I used EC2 with 16GB RAM in one of the European countries, which used only approximately 30% of the memory and disk, which won't be the same for all the countries and production-grade cases.
To set the production-grade environment, it's based on the use case where you are going to use this routing service. however, I would like to add a few recommendations here
- Memory
  - 64GB–128GB RAM for large region maps (e.g., Europe).
- CPU
  - 8 to 16 cores for medium traffic, with the ability to scale as traffic grows.
  - High clock speed (3.0 GHz or higher) for fast query processing.
- Disk Storage
  - Recommended SSD Storage since disk performance plays an important role while doing data processing. for eg., extracting, partitioning, and contracting.
  - At least 256GB for OSRM data storage and logs.
- LoadBalancer
  - Nginx or HAProxy. Assume already exists or following in a live environment.
The cost required to set up is approximately $12K- 18K per instance and $20-30K for a couple of instances per year basis. This is a ballpark calculation. It might increase or decrease.
Please note that,
- Simple Routing Queries (Local, Short Distance)
  - For routing within a city or a relatively small area, an 8-core machine with 64GB RAM running OSRM can handle 100 to 200 requests per second (RPS) under typical conditions. This number assumes
  - The machine is well-optimized.
  - The requests are for relatively short routes.
  - The OSRM graph has been properly preprocessed (partitioned and contracted).
  - Complex Routing Queries (Long Distance, Continental)
  - If you are calculating more complex, long-distance routes (e.g., inter-city or across countries), the number of requests per second will drop, potentially to 30 to 100 RPS, depending on the complexity of the queries.
The key difference between simple, complex, and long routes in OSRM terminology
- Simple Route: A short, straightforward route, often within a small region or city. OSRM can calculate these very quickly because it involves fewer nodes and roads.
  - Example: Routing within a small neighborhood or from one point to another within a small city.
- Complex Route: A route that involves many decision points (intersections, waypoints), routing rules (turn restrictions, traffic), and dense networks.
  - Example: Routing through a densely populated city with many restrictions or many stops.
- Long Route: A route that spans a large geographic distance, possibly over hundreds or thousands of kilometers.
  - Example: Cross-country or intercity routes covering a vast area.
Performance factor
- Simple routes are quick to compute because the search space is small, and the routing graph is limited to a smaller geographic area.
- Complex routes take longer because OSRM must evaluate a larger number of potential paths, especially in dense, complicated networks.
- Long routes take longer because the search space grows significantly with the distance, even though OSRM optimizes performance using partitioning and contraction hierarchies.

Maintenance

We need to consider a few things in the maintenance phase, such as data updates regularly, which we could bring automation to do this mechanical process, and this should be done during business offline hours.

Typically these are the following things involved in maintenance phases are

Map Data Updates: Regularly update OSM data and handle downtime during preprocessing.
Preprocessing Challenges: Long and resource-intensive contraction and partitioning steps.
High Traffic Load: Scaling OSRM to handle many requests and avoid performance bottlenecks.
Disk and Memory Management: Ensuring enough memory and proper STXXL disk management.
Load Balancing and Redundancy: Ensuring fault tolerance with load balancing and multiple instances.
Real-Time Data Integration: Integrating real-time traffic data with OSRM and managing frequent updates.
API Management: Setting up rate limits, securing endpoints, and managing traffic.
Hardware Failures: Handling potential hardware issues and ensuring data redundancy.
Software Maintenance: Regular upgrades, bug fixes, and ensuring compatibility with existing setups.
Monitoring and Logging: Setting up proper monitoring and managing logs to detect issues early.

Integration with Third-party Service and High-level Architecture

Integrating OSRM (Open Source Routing Machine) with a third-party service like OpenEVCharge (a service that provides data on Electric Vehicle (EV) charging stations) can enhance routing services by allowing users to find optimized routes based on both road networks and the availability of charging points. This type of integration can be particularly useful for Electric Vehicle (EV) route planning, where charging stations must be factored into the route.

OpenEVCharge

Integration workflow

The integration can be broken down into several key steps.

Step 1. Initial Route Calculation (OSRM)

The system begins with a start location (origin) and an end location (destination).
OSRM calculates the base route between these two points using its core routing engine. This is done without considering real-time traffic or charging stations yet.
The result will be a set of waypoints, distances, and estimated travel time.

Step 2. Determine EV Charging Needs (OpenEVCharge)

Based on the total distance of the route and the battery range of the EV, determine whether the vehicle will need to stop for charging.
If the vehicle’s range is shorter than the total route, determine when and where to stop based on charging station availability.
Query OpenEVCharge API for charging stations near specific waypoints or along the route. For instance, querying stations near a waypoint:
Once you find relevant charging stations, modify the route by inserting the charging station as a waypoint. If more than one stop is needed, the process repeats.

Step 3. Incorporating Real-Time Traffic Data (TomTom)

After finding the optimal route with charging stops, integrate TomTom real-time traffic data to enhance the route with real-time traffic conditions.
TomTom provides real-time traffic data via API.
- Traffic delays
- Congestion levels
- Accidents and road closures
- Alternative route suggestions
The data will be returned with traffic congestion, road closures, and delay times for the specified area. You can use this information to:
Adjust travel time estimates.
Reroute the user to avoid congested areas or blocked roads.

Step 4. Final Route Calculation and Adjustments

OSRM Final Route Calculation: Combine the data from OpenEVCharge and TomTom to adjust the route.
If charging stops are required, modify the route to include the charging station(s) as waypoints.
If traffic congestion is detected, reroute the user by avoiding the affected areas. OSRM can use alternative routes to bypass traffic jams.

Example API call for a route with waypoints

http://router.project-osrm.org/route/v1/driving/start_lat,start_lon;charging_station_lat,charging_station_lon;end_lat,end_lon?alternatives=true&overview=full
Rerouting: If TomTom’s real-time traffic data indicates heavy congestion or accidents on the initial route, you can request OSRM to provide alternative routes using the alternatives=true parameter.

Step 5. Return the Final Route to the User

The final route should include.
It has optimized travel time that accounts for real-time traffic conditions from TomTom.
Charging stops along the way, based on the vehicle’s range and the availability of charging stations from OpenEVCharge.
Alternate route suggestions if traffic conditions change en route.

Cost Comparision between another provider with OSRM

Provider	Estimated Latency	Cost Structure	Hosting & Maintenance
OSRM	0-50ms (short distance) 50-200ms (complex/long distance)	Hosting Cost: One-time setup cost for computing and storage (EBS, S3, etc.). Monthly maintenance cost: $50–$200, depending on server size, storage needs, and data update frequency.	Self-hosted on a cloud provider (AWS) Requires regular OSM data updates (e.g., monthly).
TomTom	30-100ms	Pay-as-you-go: - Free tier: 2,500 requests/month Paid: $0.50 per 1,000 requests (up to 100K); $0.20 per 1,000 requests (beyond 100K)	Hosted and managed by TomTom. No maintenance is needed from the user side. Real-time traffic and updates are included.
HERE	20-100ms	Usage-based pricing: - Free tier: 250,000 transactions/month. Paid: starts at $1 per 1,000 transactions.	Hosted and managed by HERE. Advanced features (e.g., live traffic, route optimization). Automatic data updates.
Loqate	50-100ms	Subscription and Pay-as-you-go: - Starts at $100/month with a set number of requests. Pay-as-you-go options are available for higher volumes.	Hosted by Loqate. Geocoding and address validation. Regularly updated without user intervention.
Google Maps API	20-200ms	Pay-as-you-go: - Free tier: $200 monthly credit (about 28,000 requests) Paid: $5–$10 per 1,000 requests (depending on API used)	Fully managed by Google. Regular data updates and traffic data. No maintenance is required on the user end.

Use cases example

Ride-Sharing and Taxi Services
- Use Case: A ride-hailing service requires quick route calculations to pair drivers with riders and to determine ETA (estimated time of arrival).
- Solution with OSRM: OSRM provides low-latency routing, helping assign drivers to passengers with minimal delay and ensuring that routes are updated in real-time.
- Benefits: Faster response times for drivers, accurate ETAs for passengers, and improved overall system efficiency.
Delivery Route Optimization for E-commerce
- Use Case: E-commerce companies need efficient routing for daily deliveries to multiple destinations, minimizing both distance and time.
- Solution with OSRM: By using OSRM’s multi-point routing, companies can create optimized delivery routes, taking constraints like delivery time windows and truck capacities into account.
- Benefits: Reduced delivery costs, shorter delivery times, and increased delivery volumes per day.
Tourism Applications
- Use Case: A tourism app needs routing information for hiking, biking, or walking trails rather than car-based routes.
- Solution with OSRM: OSRM can be customized with different routing profiles (e.g., for hiking trails and biking paths) to support outdoor activities.
- Benefits: Accurate routing for specific activities, customized routes that match terrain type, and enhanced experience for users exploring new areas.
Smart City Traffic Management ( let me create a separate article about this use case architecture and implementation part)
- Use Case: Real-time traffic flow monitoring and congestion management.
- Example: A city’s traffic management system could integrate OSRM to dynamically adjust traffic signals or provide detours, improving traffic flow and reducing congestion.
- Benefit: Supports efficient city operations, reduces congestion, and helps citizens navigate more smoothly through urban areas

Limitations

OSRM doesn’t support real-time traffic data; however, we could integrate with third-party providers to get the same.
OSRM relies on OpenStreetMap (OSM) data, which varies in quality and completeness depending on the region.
Scaling OSRM to support millions of requests per day requires a robust server setup, possibly with multiple instances, load balancers, and caching strategies. High availability and fault tolerance require advanced deployment management and infrastructure skills.

Conclusion

In summary, the Open Source Routing Machine (OSRM) presents a powerful and efficient solution for routing needs, particularly for applications requiring speed and flexibility. While OSRM excels in performance and is cost-effective as an open-source solution, it has certain limitations when compared to proprietary routing providers like Google Maps, TomTom, and HERE. Despite these limitations, OSRM can be a valuable tool, particularly in scenarios where cost and open-source flexibility are paramount. For applications requiring real-time responsiveness and extensive routing features, integrating OSRM with middleware that utilizes dynamic traffic data can bridge the gap, enhancing the routing capabilities of OSRM without extensive overhead.

In conclusion, the choice between OSRM and proprietary routing solutions ultimately depends on the specific needs of the application, including factors like budget, required features, scalability, and real-time data integration. Each approach has its strengths and weaknesses, so careful consideration is essential for optimal routing solutions.

Note. Let me create another article for full deployment infra architecture and CI/CD pipeline for the same.

Reference link