April 2015 - GraphHopper Directions API

Elevation data and OpenStreetMap

Handling elevation data and combine it with OpenStreetMap can be a pain. And indeed it was when we implemented this for GraphHopper roughly one year ago. But we really wanted to make it easy for our users. And it is very easy – you just need to set:

graph.elevation.provider=srtm

in the config.properties and GraphHopper will include elevation automatically! For the full elevation documentation please read this.

In GraphHopper Maps you can try it and see the elevation widget for every route for bike&foot:

So GraphHopper will include elevation then automatically in

the import process and therefor also calculate more precise distances
the API where it adds three dimensional points (GHPoint3D) instead of just GHPoint
the web API where it uses a third dimension. As we also use a compact form called encoded polyline for this, you need the adapted decoding procedure when consuming the route and not using GeoJSON.

But to make a vehicle (e.g. bike) actually using the height information you need to tell it that uphill its slower than downhill via bike2. So you need a flag encoder with two weights per edge. But it is easy to enable:

graph.flagEncoders=bike2

With this logic in place it should be easy to improve our mountain bike profile to prefer up and down hill. It is important to note that for ‘preferring’ a specific feature it is not necessary to increase the speed. You can just tune this behavior via the priority implemented for bike and foot. Read more about how to write your own flag encoder here.

Other providers and more configurations

The nice thing about our modular approach is also that you can use a complete different provider like we do with CGIAR (improved SRTM data) or even inject your elevation data into the OSM. You just need to change this in the config

graph.elevation.provider=cgiar

Also you can have an in-memory or on-disc storage for this elevation data. E.g. to reduce RAM usage you use the default setting, but to speed up the import and not having SSD discs you set

graph.elevation.dataaccess=RAM_STORE

The nice thing is that you also can use our ElevationProvider implementations for you own Java application. Is it currently not separated from GraphHopper but it is relative separated and GraphHopper core is not big 🙂

Visualize and Handle Traffic Information with GraphHopper in Real-time for Cologne (Germany, Köln)

As our Directions API currently does not include traffic data we still show you that it is possible to integrate traffic data into GraphHopper if you have the data. A few days ago I’ve blogged about a simple way to feed GraphHopper with generic traffic data from elsewhere. Today we look into one specific example: Cologne.

This German city has a nice open data community and an open data portal. There I found the traffic data and it is noted that the update is done every 5-10 minutes so we have rough real time traffic information. For other open data or other cities have a look into codefor.de

The source repository for the necessary changes is also at github. The most important change was to visualize the traffic information directly in the browser, this helps a lot when debugging things – still lots of room for you to improve it. Using leaflet.canvas is a bit complex as we would need to separate the traffic information into the tiles structure. Instead I’m using the big canvas solution from CartoDB making everything really simple.

Three further simple steps are necessary when extending the old example:

Fetch data periodically
Parse and interpret the data correctly
Locking when writing the data and locking when routing

Fetching the data and parsing it is a simple procedure done within DataUpdater.fetch. Also surrounding the data feeding method with a write-lock is easy:

public void feed(RoadData data) {
writeLock.lock();
try {
lockedFeed(data);
} finally {
writeLock.unlock();
}
}

And finally we need to surround every route request with a read-lock:

GraphHopper tmp = new GraphHopper() {
@Override public GHResponse route(GHRequest request) {
lock.readLock().lock();
try {
return super.route(request);
} finally {
lock.readLock().unlock();
}
}
}.forServer().init(args);

Now we just need to fetch the road network for this area and start the server:

wget http://download.geofabrik.de/europe/germany/nordrhein-westfalen/koeln-regbez-latest.osm.pbf
./td.sh datasource=koeln-regbez-latest.osm.pbf
Visit http://localhost:8989 to try the routing and see the traffic infos

And you’ll see regularly updates of the speed where routing should be influenced, at least the duration for the route:

Speed change at 50.94432295851602, 7.057916495227443. Old: 30.0, new:5.0
Speed change at 50.944496505815735, 7.057842025768907. Old: 60.0, new:45.0
Speed change at 50.94422920435813, 6.982818132995898. Old: 65.0, new:45.0
Speed change at 50.96702284992454, 7.03188984955171. Old: 45.0, new:20.0
Speed change at 50.90650702086146, 7.0605028341376235. Old: 70.0, new:45.0
Updated 86 street elements. Errors:0

To start from scratch you can remove the graph-cache folder and the old speed values will be used. Still this is only a rough prototype. For example:

Map matching not yet integrated
Fallback to old values -> either store within RoadData or separate GH instance
UI: artifact when zooming. No concrete info is shown on mouse over
Use two directions for speed if no one-way street
Of course it is best to try the system in German-early times and hope that many traffic jams events are there 😉

This is only one city, but we collect more here! Now have fun to test and tweak the system!

Elevation data and OpenStreetMap

See how Falk, Ride with GPS and Volo benefit from using GraphHopper

Route.nl

Ride with GPS

Volo

Let us know if you have more interesting use cases of GraphHopper!

Visualize and Handle Traffic Information with GraphHopper in Real-time for Cologne (Germany, Köln)