OSRM is a lightning fast open source routing engine for OpenStreetMap data. We are now using it in all the websites managed by our Django-powered GeoRouter platform.
The routing engine
Recently we have upgraded our multi-site Django-based platform (see: MapSlow) to support OpenStreetMap routing with OSRM.
OSRM is a lightning fast routing server that uses OpenStreetMap data to calculate routes based on different routing profiles, the system is very flexible and configurable, you can setup profiles for car, foot, and bicycle and decide every detail about where the different users (pedestrian, cyclists etc.) can pass trough or cross.
The process of preparing OSM data for routing requires high CPU and RAM resources and quite a lot of time, we are using a 16 cores and 32 GB RAM virtual instance and the full update takes about 90′ for each profile (for Italy only!!), of course we are running this process (weekly) in the background, at night while server load is typically low.
Since we are using three different profiles, we need three independant OSRM server instances, each running instance requires a huge amount or RAM, for this reason we chose such a powerful server.
We are really satisfied with OSRM, the performances are very good and response is ligthning fast, allowing for a richful UX: while the user drags a waypoint the routes are immediately updated on the screen.
The only missing piece is the ability to use altitude data, this can be a problem when calculating routes for bicycle and foot profiles because they should really take altitude into account to calculate the shortest paths in terms of time.
Driving directions are also processed to build a road-book composed by detailed maps and waypoints, with turn-by-turn routing instructions.
OSRM is a very good and robust project, well suited for fast routing applications. It has fully configurable profiles but each server instance support only one profile at a time, leading to increasing resources requirements as the number of needed profiles grows up.
The only important missing feature is the ability to use a DTM (Digital Terrain Model) to ajust driving speeds in not-flat areas, this obviously leads to wrong shortest (timewise and lengthwise) path calculations in most mountain and hill areas.