Routes computation in the Cantal French Department with OSRM

Nicolas Dumoulin, Irstea Lisc

This work take part of the European Project Prima. At the Lisc, we have developped a microsimulation model. In this model, we need to evaluate the distance from a municipality to another one. First, we was using the euclidian distances, but after some experimentations, the limits of these data has been confirmed as the area considered has a lot of topographic restrictions (mountains, gorges, …).

After some researches, computing the distances with OSRM was the most accessible solution. The first tests shows that this software is very fast and doesn't require a lot of computing resources (a laptop is enough for the concerned area). But, the distances computed by OSRM are the consequence of the routes network in the OpenStreetMap database. So, we need to be sure of the quality of this network.

In this document, we describe how we have built the matrix of distances between each municipalities of the Cantal, and how we have tried to validate the routing data from OpenStreetMap.

You can download the routing data computed under the license ODbL 1.0.

Warning: as the data are continously updated in OpenStreetMap, and as this dataset is quite old, it could be suitable to compute again these distances and check the results. Please, let me know if you encounter any issue about that.

Technical details

The source code of the developped tools can be retrieved on this svn directory and is distributed under the license AGPL 3.0.

OSRM Installation

sudo aptitude install build-essential git cmake pkg-config libprotoc-dev libprotobuf7 protobuf-compiler libprotobuf-dev libosmpbf-dev libpng12-dev libbz2-dev libstxxl-dev libstxxl-doc libstxxl1 libxml2-dev libzip-dev libboost-thread-dev libboost-system-dev libboost-regex-dev libboost-filesystem-dev lua5.1 liblua5.1-0-dev libluabind-dev libluajit-5.1-dev libboost-program-options-dev
git clone https://github.com/Project-OSRM/osrm-backend.git
cd Project-OSRM
mkdir -p build; cd build; cmake ..; make

Getting OpenStreetMap data for the Cantal

You need to install the osmosis software for manipulating the data extract

sudo aptitude install osmosis

We need to download the data for a larger area than the Cantal, because some routes can be outsides the boundary. So, we download the data for the france and clipping them with a bounding box.

cd Project-OSRM
wget -O france.osm.pbf http://download.geofabrik.de/europe/france-latest.osm.pbf
# about 45 minutes
osmosis --rb france.osm.pbf --bounding-box left=1.986 right=3.478 top=45.546 bottom=44.574 completeWays=yes --wb cantal-rectangle.osm.pbf

Warning: osmosis will use the java tmp directory for storing some data. If you don't have enough space on /tmp (about 2-3 Go), you can give an other place for this tmp directory with this command:

export JAVACMD_OPTIONS="-Djava.io.tmpdir=/home/dumoulin/tmp/osm"

OSM data loading in OSRM

For the following, I assume you have fixed this variable to the relative place from your working directory to where you have built OSRM:

OSRMPATH="../osrm-backend"

First, as mentioned in the OSRM documentation, you have to copy the speed profile:

ln -s ${OSRMPATH}/profiles/car.lua profile.lua

The import is quite fast for this set of data, about 1 minute.

PREFIX="cantal-rectangle"
rm ${PREFIX}.osrm*
${OSRMPATH}/build/osrm-extract ${PREFIX}.osm.pbf && ${OSRMPATH}/build/osrm-prepare ${PREFIX}.osrm

Now, you're ready to run the server (Ctrl+C for stopping):

${OSRMPATH}/build/osrm-routed ${PREFIX}.osrm --hsgrdata ${PREFIX}.osrm.hsgr --nodesdata ${PREFIX}.osrm.nodes --edgesdata ${PREFIX}.osrm.edges --ramindex ${PREFIX}.osrm.ramIndex --fileindex ${PREFIX}.osrm.fileIndex --namesdata ${PREFIX}.osrm.names --timestamp ${PREFIX}.osrm.timestamp

Updating the OpenStreetMap data (optional)

If you want follow an iterative process and fix the OpenStreetMap the data as you detect abberations in your result, or if you want just get always fresh data, here are the steps to get your OpenStreetMap up-to-date.

Create a directory and initialize it for diff processing of osmosis:

mkdir france-update
cd france-update
osmosis --rrii workingDirectory=.
echo 'baseUrl=http://download.openstreetmap.fr/redaction-period/minute-replicate-france' >> configuration.txt
echo 'maxInterval = 0' >> configuration.txt

Identify the file which has a date just before the date of your extract, and save it:

wget -O state.txt http://download.openstreetmap.fr/redaction-period/minute-replicate-france/***/***/***.state.txt

Run the update:

osmosis --rri --simc --rb ../Project-OSRM/cantal-rectangle.osm.pbf --ac --bounding-box left=1.986 right=3.478 top=45.546 bottom=44.574 --wb cantal-rectangle-up2date.osm.pbf && mv cantal-rectangle-up2date.osm.pbf ../Project-OSRM/cantal-rectangle.osm.pbf

After that, you can reload these data in OSRM (see previous section).

GeoFLA data import

GeoFLA is a database provided by the IGN (french geographic institute) under Open License, containing the description of all municipalities of France.

cf. buildRoutingInputFromGeoFLA.py

N.B.: when your using layers with python-ogr, you have to store in separate variable, the driver and the datasource, otherwise the layer can become unreachable and the process can crash (segfault).

The script buildRoutingInputFromGeoFLA.py read the datasource GeoFLA (ESRI Shapefile) and fetch for all the municipalities of the Cantal the polygon of the boundary, the coordinates of the admin centre (columns X_CHF_LIEU and Y_CHF_LIEU which are in hectometers), the INSEE code and the name. The geographic data are in projection system Lambert93 (EPSG:2154). The following files are wrotten by using the projection system EPSG:4326 (WGS84):

  • html/municipalities.json vectorial layer GeoJSON for displaying in a web page
  • municipalitiesIDs.csv INSEE code of the municipalities
  • Cantal-routingInput.csv departure/arrival instructions needed for the computing the routes

Routes computation and validation

The script distanceOSRM.py will compute all the routes from the file Cantal-routingInput.csv that has been previously written. Thus, the distances (in meters) and the duration (in seconds) will be written in a sequential file and in a matrix format.

For validating the route computed, I have used both automatic and manual solution. Some automatic test have been checked and have pointed the municipality where mapping data was missing. The automatic tests are:

  • does a route exist, is the distance not equals to zero?
  • are the start and the end points near the admin centers of the concerned municipalities? For our studied area, 150 meters was a good threshold.
  • is the distance shorter than the euclidian ones? This error has never been raised, good for OSRM.

For the manual tests, the routes that are 3 times greater than the euclidian ones are stored in geojson file. Then these routes are displayed on a commercial map (in our case from the IGN), for identifying a lack of data in OpenStreetMap that leads to a detour. When a route make a big detour although a shorter seems to exists on the commercial map, we should check in the aerial view if this route still exists and then we should map this route in OpenStreetMap.

From a legal point of view, this method is also correct. Indeed, we have used the commercial map only for identifying the lack of data in OpenStreetMap by data comparison. We have pay attention to not use the commercial map for identifying the classification of the roads.